16

Al migrar a .net 4 comenzamos a enfrentar el problema con nuestra biblioteca. Supongamos que tenemos nuestra biblioteca MyLib.dll y hace referencia al ensamblado de interoperabilidad Interop.dll. Interop.dll hace referencia a MissingInterop.dll..NET 4 carga ensamblajes diferentes de .NET 3.5

Así que las referencias se puede mostrar como: MyLib.dll -> Interop.dll -> MissingInterop.dll

En MyLib.dll que utilizar sólo una parte de las clases de Interop.dll por lo que nunca llamamos cualquier cosa que necesita MissingInterop.dll y en .NET 3.5 funciona bien Es por eso que no enviamos MissingInterop.dll con MyLib.dll.

Cuando usamos MyLib.dll del proceso que se ejecuta bajo .NET 4 aplicación falla con la siguiente excepción:

FileNotFoundException: "No se pudo cargar el archivo o ensamblado 'MissingInterop.dll, Version = 1.0.0.0, Culture = neutral, PublicKeyToken = null' o uno de sus dependencias. el sistema no puede encontrar el archivo especificado. "`

también me he dado cuenta que las referencias Interop.dll otros falta de DLL, pero .NET no tratar de cargarlos Y he encontrado la diferencia. Algunos tipos de MissingInterop.dll se utilizan en los parámetros del método en Interop.dll mientras que los tipos de otras bibliotecas que faltan sólo se utilizan como tipos de retorno método, es decir en Interop.dll i puedo ver:

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

y .NET 4 intentos cargar MissingInterop.dll pero no intenta cargar AnotherMissingInterop.dll.

.NET 3.5 no intentó cargar ni MissingInterop.dll ni AnotherMissingInterop porque no se utilizan en la ruta de ejecución.

Sé que .NET 4 tiene un nuevo Fusion pero no he encontrado cambios de rotura descritos en ninguna parte. ¿Alguien sabe por qué .NET 4 intenta cargar algo que no es necesario? ¿Hay alguna forma de arreglar esto sin volver a compilar el código ni agregar el archivo que falta?

+7

Sí, grandes cambios en .NET 4 para habilitar la función "incrustar tipos de interoperabilidad". Usted rompió la garantía antes, funcionó por accidente. Use [Comport] para proporcionar los tipos faltantes. –

+0

Tal vez es porque una de las referencias es construir contra el marco 3.5. Debería intentar agregar useLegacyV2RuntimeActivationPolicy = "true" como se describe aquí: http://stackoverflow.com/questions/1604663/what-does-uselegacyv2runtimeactivationpolicy-do-in-the-net-4-config –

+0

Benoit, gracias por su sugerencia pero no ayudó. –

Respuesta

0

Cuando está migrando su aplicación de .NET 3.0, 3.5 a 4.0, entonces necesita incluir este mylib.dll en su proyecto externamente y compilarlos o, si es posible, tiene el código fuente de ensamblaje luego cámbielo en .net 4.0

+0

Lo hicimos. Pero la pregunta era por qué clr 2.0 está bien con esta situación y clr 4.0 no. –

1

Probablemente no (de la experiencia). Hubo problemas similares en un paso anterior (no recuerdo si fue 2.0 -> 2.1 o 3.0 -> 3.1. Pero fue hace un tiempo). Tuvimos máquinas que informaron que la versión anterior estaba instalada y se bloqueó. Cuando limpiamos las instalaciones de red y realmente instalamos la versión más baja, y luego la actualización, todo funcionó bien. Microsoft puede escaparse un parche. Me inclinaría a plantearlo con MS. Usted tiene un error aparentemente bien reasecado, y en tales condiciones de contrato de soporte o no, son muy reacios a terminar cobrándole. (Mi experiencia de todos modos)

+0

gracias, probablemente lo haremos. –

Cuestiones relacionadas