Вход на сайт
.Net - новая версия Dll heil
NEW 16.05.06 12:26
.Net - новая версия Dll heil...
Надеюсь, что те, кто работает с .Net, в курсе что там есть такая прелесть как GAP.
Для тех кто не знает - мелкософт пытается реализовать поддержку множественных вариантов библиотек, указывая системе какая именно версия должна использоваться с конкретной программой. Хранится, по идее, это все должно в этом самом GAPe...
Ну и как обычно - все хорошо, пока все хорошо... Но вот в пятницу пришлось попотеть до 22.00... а сегодня - снова та же проблема...
Суть. У меня, как вы знаете, код не пишется ручками, а генерится целиком приложение. Приложению нужна небольшая либа с враперами стандартных компонентов и тем что используется дополнительно. Кода там не много и он почти не меняется. Но все же иногда в систему вводится новые элементы и, соответственно, библиотека пополняется. Разумеется компилируется и используется новая версия. Разумеется, она прописывается в GAPe. Разумеется, там же в GAPe лежат и другие версии. И вот в пятницу это все слегка накрылось...
Накрылось элементарно - приложение начало валиться по ошибке. Детальное изучение показало, что где-то в недрах приложения не создается один из компонентов. Почему - не знаю. Решил все переделать, благо не занимает много времени - стандартным образом с нуля создал проект, перебросил конфигурацию (это пара XML-файлов), сгенерил проект, откомпилировал... Та же самая ошибка на том же самом месте.
Пробовал много чего и под конец решил прибить все либы связанные с проектом. Вычистил _всю_ систему от всех версий... А ошибка - никуда не делась. Еще раз акцептирую внимание - ошибка времени выполнения, т.е. .Net "видит" правильную либу с нужным компонентом на этапе трансляции, но в ран-тайме использует что-то другое... при том, что в системе присутствует только _одна_ версия либы...
Вообщем - настоящий DLL-heil от мелкомягких, только в новой обертке с версиями.
Если кто сталкивался с подобным - напишите, плс, как выходили из ситуации, бо проблемма хотя и решается шаманством - разовой заменой проекта с другой машины, но хотелось бы найти отколь ноги растут...
Надеюсь, что те, кто работает с .Net, в курсе что там есть такая прелесть как GAP.
Для тех кто не знает - мелкософт пытается реализовать поддержку множественных вариантов библиотек, указывая системе какая именно версия должна использоваться с конкретной программой. Хранится, по идее, это все должно в этом самом GAPe...
Ну и как обычно - все хорошо, пока все хорошо... Но вот в пятницу пришлось попотеть до 22.00... а сегодня - снова та же проблема...
Суть. У меня, как вы знаете, код не пишется ручками, а генерится целиком приложение. Приложению нужна небольшая либа с враперами стандартных компонентов и тем что используется дополнительно. Кода там не много и он почти не меняется. Но все же иногда в систему вводится новые элементы и, соответственно, библиотека пополняется. Разумеется компилируется и используется новая версия. Разумеется, она прописывается в GAPe. Разумеется, там же в GAPe лежат и другие версии. И вот в пятницу это все слегка накрылось...
Накрылось элементарно - приложение начало валиться по ошибке. Детальное изучение показало, что где-то в недрах приложения не создается один из компонентов. Почему - не знаю. Решил все переделать, благо не занимает много времени - стандартным образом с нуля создал проект, перебросил конфигурацию (это пара XML-файлов), сгенерил проект, откомпилировал... Та же самая ошибка на том же самом месте.
Пробовал много чего и под конец решил прибить все либы связанные с проектом. Вычистил _всю_ систему от всех версий... А ошибка - никуда не делась. Еще раз акцептирую внимание - ошибка времени выполнения, т.е. .Net "видит" правильную либу с нужным компонентом на этапе трансляции, но в ран-тайме использует что-то другое... при том, что в системе присутствует только _одна_ версия либы...
Вообщем - настоящий DLL-heil от мелкомягких, только в новой обертке с версиями.
Если кто сталкивался с подобным - напишите, плс, как выходили из ситуации, бо проблемма хотя и решается шаманством - разовой заменой проекта с другой машины, но хотелось бы найти отколь ноги растут...
NEW 16.05.06 15:52
в ответ digital_pilot 16.05.06 13:29
Наверное. Последний раз доки по организации .Net'a смотрел пару лет назад. Подзабывается.
Что до глюков - оно понятно, что что-то глючит по-черному. Остается выяснить - Что и Как с ним справится? - Пока удается убить глюк перетаскиванием проекта с другой машины, но это - шаманство, а нужно - решение...
Что до глюков - оно понятно, что что-то глючит по-черному. Остается выяснить - Что и Как с ним справится? - Пока удается убить глюк перетаскиванием проекта с другой машины, но это - шаманство, а нужно - решение...
NEW 17.05.06 16:24
в ответ Murr 16.05.06 12:26
Что дядюшка Билли большой чудак, на буковку 'Эм', разумеется, известно давно.
Но вот чего он наворотил в .Net - это вообще ни в какие ворота не лезет.
Разобрался я с описанной выше проблемой проблемой. Если у кого есть интерес
- можете попробовать угадать где была причина... После десятка обоснованных
предположений расскажу в чем именно была проблема...
Но вот чего он наворотил в .Net - это вообще ни в какие ворота не лезет.
Разобрался я с описанной выше проблемой проблемой. Если у кого есть интерес
- можете попробовать угадать где была причина... После десятка обоснованных
предположений расскажу в чем именно была проблема...
NEW 18.05.06 08:39
в ответ Murr 17.05.06 16:24
Номер версии автогенерился студией и в GAC устанавливались все версии.
Хотя может были грабли при генерации strong name.
На более абстрактном уровне подозреваю, что у МС устанавливался какой-то параметер по-умолчанию, причем предположения о значении этого параметра у программера существенно отличались от представлений МС, что же программеру надо.
Хотелось бы услышать горячо-холодно.
Хотя может были грабли при генерации strong name.
На более абстрактном уровне подозреваю, что у МС устанавливался какой-то параметер по-умолчанию, причем предположения о значении этого параметра у программера существенно отличались от представлений МС, что же программеру надо.
Хотелось бы услышать горячо-холодно.

NEW 18.05.06 23:53
в ответ Murr 16.05.06 12:26
Вообще то очень странно.
Я никогда не прописывал ничего в GAC, все всегдо локально.
в compile time должно собираться с #using "MyLib.Dll"
При исполнении тот же самы dll должен лежать в той же директории что и .exe и все.
Проблемы бывают только тогда, когда .dll по каким то причинам в памяти, и не дает себя периписать новой версией.
Какая у тебя версия .NET 2.0 или 1.1 ?
А какой эксепшн швыряется?
Я никогда не прописывал ничего в GAC, все всегдо локально.
в compile time должно собираться с #using "MyLib.Dll"
При исполнении тот же самы dll должен лежать в той же директории что и .exe и все.
Проблемы бывают только тогда, когда .dll по каким то причинам в памяти, и не дает себя периписать новой версией.
Какая у тебя версия .NET 2.0 или 1.1 ?
А какой эксепшн швыряется?
*Ъ...
NEW 19.05.06 01:22
в ответ AlterEgo 18.05.06 23:53
Не пользуюсь ссылками на конретную Dll в коде - вседа - референсе и усинг по наймспасу.
Фраймворк 1.1. Второй, говорят, глючит. Так что если будем пересаживаться - 2005+ с чем она там идет...
Ексептион, стандартный - объект не инстанцирован. Он действительно не инстансится...
У меня не ехе-шник. Собирается вэб-аппликатион - там только ДЛЛ...
Что странно - я и сам понимаю... Мало того - практически невоспроизводимо. По крайней мере - не получается повторить, после того вылечил...
Фраймворк 1.1. Второй, говорят, глючит. Так что если будем пересаживаться - 2005+ с чем она там идет...
Ексептион, стандартный - объект не инстанцирован. Он действительно не инстансится...
У меня не ехе-шник. Собирается вэб-аппликатион - там только ДЛЛ...
Что странно - я и сам понимаю... Мало того - практически невоспроизводимо. По крайней мере - не получается повторить, после того вылечил...