.NET 4 загружает сборки, отличные от .NET 3.5.

С переходом на .net 4 мы столкнулись с проблемой нашей библиотеки. Предположим, у нас есть библиотека MyLib.dll, и она ссылается на Interop-сборку Interop.dll. Interop.dll ссылается на MissingInterop.dll.

Таким образом, ссылки могут отображаться как: MyLib.dll -> Interop.dll -> MissingInterop.dll

В MyLib.dll мы используем только часть классов из Interop.dll, поэтому мы никогда не вызываем ничего, что требует MissingInterop.dll, а в .net 3.5 это прекрасно работает. Вот почему мы не поставляем MissingInterop.dll с MyLib.dll.

Когда мы используем MyLib.dll из процесса, работающего под .net 4, приложение завершается со следующим исключением:

FileNotFoundException: «Не удалось загрузить файл или сборку «MissingInterop.dll, версия = 1.0.0.0, культура = нейтральная, PublicKeyToken = null» или одна из ее зависимостей. Система не может найти указанный файл».

Также я заметил, что Interop.dll ссылается на другие отсутствующие dll, но .net не пытается их загрузить. И я нашел разницу. Некоторые типы из MissingInterop.dll используются в параметрах метода в Interop.dll, а типы из других отсутствующих библиотек используются только как типы возврата метода, т.е. в Interop.dll я вижу:

  Class C1
     MethodA : void (valuetype [MissingInterop]MissingAssembly.TypeA&)
  Class C2
     get_Status : valuetype[AnotherMissingInterop]AnotherMissingAssembly.TypeB()

и .NET 4 пытается загрузить MissingInterop.dll, но не пытается загрузить AnotherMissingInterop.dll.

.NET 3.5 не пытался загрузить ни MissingInterop.dll, ни AnotherMissingInterop, поскольку они не используются в пути выполнения.

Я знаю, что в .NET 4 есть новый Fusion, но я нигде не нашел такого критического изменения. Кто-нибудь знает, почему .NET 4 пытается загрузить что-то ненужное? Есть ли способ исправить это без перекомпиляции кода или добавления отсутствующего файла?


.net exception-handling assembly-resolution assemblyresolve
person Puterdo Borato    schedule 27.01.2012    source источник
comment
Да, большие изменения в .NET 4, чтобы включить функцию встраивания типов взаимодействия. Вы нарушили гарантию раньше, это сработало случайно. Используйте [ComImport] для предоставления отсутствующих типов.   -  person Hans Passant    schedule 27.01.2012
comment
Может быть, это потому, что одна из ссылок построена на базе 3.5. Вам следует попробовать добавить useLegacyV2RuntimeActivationPolicy=true, как описано здесь: stackoverflow.com/questions/1604663/   -  person Benoit Blanchon    schedule 03.02.2012
comment
Бенуа, спасибо за предложение, но оно не помогло.   -  person Puterdo Borato    schedule 12.02.2012
comment
Насколько я знаю, clr 4 имеет много отличий от предыдущих релизов. Если вы можете воспроизводить это постоянно, то это своего рода дизайн. Поскольку исправление простое и очевидное, я не думаю, что Microsoft должна его исправлять.   -  person Lex Li    schedule 14.02.2012

Ответы (2)


arrow_upward
0
arrow_downward

Когда вы переносите свое приложение с .NET 3.0, 3.5 на 4.0, вам необходимо включить эту mylib.dll в свой проект извне и скомпилировать их или, если возможно, у вас есть исходный код сборки, а затем изменить его на .net 4.0

person Udit Gupta    schedule 22.02.2012
comment
Мы сделали это. Но вопрос заключался в том, почему clr 2.0 подходит для этой ситуации, а clr 4.0 — нет. - person Puterdo Borato; 24.02.2012

arrow_upward
1
arrow_downward

Скорее всего нет (по опыту). Были похожие проблемы на более раннем этапе (не могу вспомнить, была ли это 2.0 -> 2.1 или 3.0 -> 3.1, но это было некоторое время назад). У нас были машины, сообщающие, что более ранняя версия была установлена, и произошел сбой. Когда мы очистили сетевые установки и фактически установили более низкую версию, а затем обновление, все заработало нормально. Microsoft может выпустить патч. Я был бы склонен поднять его с помощью MS. У вас есть, казалось бы, хорошо исследованная ошибка, и в таких обстоятельствах контракт на поддержку или нет, они очень неохотно в конечном итоге взимают с вас плату. (во всяком случае мой опыт)

person Ian P    schedule 14.02.2012