.NET 4 carica assemblee diverse da .NET 3.5

Con la migrazione a .net 4 abbiamo iniziato ad affrontare il problema con la nostra libreria. Supponiamo di avere la nostra libreria MyLib.dll e fa riferimento all'interop.dll dell'interop.dll. Interop.dll ha riferimento a MissingInterop.dll..NET 4 carica assemblee diverse da .NET 3.5

Così i riferimenti può essere indicato come: MyLib.dll -> Interop.dll -> MissingInterop.dll

In MyLib.dll usiamo solo una parte delle classi da Interop.dll quindi non abbiamo mai chiamiamo tutto ciò che ha bisogno di MissingInterop.dll ed in .net 3.5 funziona bene Ecco perché non spediamo MissingInterop.dll con MyLib.dll.

Quando usiamo MyLib.dll dal processo in esecuzione in .NET 4 applicazione non riesce con il seguente eccezione:

FileNotFoundException: "Impossibile caricare il file o l'assembly 'MissingInterop.dll, Version = 1.0.0.0, culture = neutral, PublicKeyToken = null' o una delle sue dipendenze. il sistema non trova il file specificato. "`

Inoltre ho notato che Interop.dll riferimenti altre mancante dll ma .NET non cercare di caricali. E ho trovato la differenza. Alcuni tipi di MissingInterop.dll sono utilizzati parametri di metodo in Interop.dll mentre i tipi da altre librerie mancanti sono usati solo come tipi metodo di ritorno, cioè in Interop.dll posso vedere:

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

e NET 4 tentativi caricare MissingInterop.dll ma non tenta di caricare AnotherMissingInterop.dll.

.NET 3.5 non ha provato a caricare né MissingInterop.dll né AnotherMissingInterop perché non vengono utilizzati nel percorso di esecuzione.

So che .NET 4 ha una nuova Fusion ma non ho trovato una tale modifica di rottura descritta da nessuna parte. Qualcuno sa perché .NET 4 tenta di caricare qualcosa che non è necessario? C'è un modo per risolvere questo problema senza ricompilare il codice o aggiungere il file mancante?

fonte

2012-01-27 Puterdo Borato

Sì, grandi cambiamenti in .NET 4 per abilitare la funzione "tipi di interoperabilità incorporata". Hai rotto la garanzia prima, ha funzionato per sbaglio. Utilizzare [ComImport] per fornire i tipi mancanti. –

Forse è perché uno dei riferimenti è costruito contro il framework 3.5. Dovresti provare ad aggiungere useLegacyV2RuntimeActivationPolicy = "true" come descritto qui: http://stackoverflow.com/questions/1604663/what-does-uselegacyv2runtimeactivationpolicy-do-in-the-net-4-config –

Benoit, grazie per il suggerimento ma non ha aiutato –

Quando si esegue la migrazione dell'applicazione da .NET 3.0, da 3.5 a 4.0, è necessario includere questo mylib.dll nel progetto esternamente e compilarli oppure, se possibile, si dispone del codice sorgente dell'assembly quindi cambiarlo in .net 4.0

fonte

2012-02-22 10:28:13

Lo abbiamo fatto. Ma la domanda era: perché clr 2.0 è ok con questa situazione e clr 4.0 no. –

Probabilmente no (per esperienza). Ci sono stati problemi simili in una fase precedente (non ricordo se fosse 2.0 -> 2.1 o 3.0 -> 3.1. Ma era un po 'di tempo fa) Avevamo delle macchine che riportavano che la versione precedente era installata e si bloccava. Quando abbiamo ripulito le installazioni nette e installato effettivamente la versione precedente, e poi l'aggiornamento, tutto ha funzionato bene. Microsoft può rimuovere una patch. Sarei propenso a sollevarlo con MS. Hai un bug apparentemente ben ripensato, e in tali contratti di supporto per le circumsatances o meno, sono molto riluttanti a finire per caricarti. (La mia esperienza comunque)

fonte

2012-02-14 11:49:13

grazie, probabilmente lo faremo. –

.NET 4 carica assemblee diverse da .NET 3.5

risposta

Problemi correlati