L'aggiornamento dell'applicazione con una nuova .net dll mi dà FileLoadException?

Question

Ho un'applicazione .net 3.5 con molte DLL, ho provato a ricostruire la dll specifica senza creare l'intera applicazione, ma dopo aver sostituito quella vecchia con la nuova, l'applicazione genera un'eccezione in quanto non può caricare la nuova eccezione dll : System.IO.FileLoadException: Impossibile caricare file o assembly .... Capisco che cerchi assembly con versione specifica e token pubblico, come posso risolvere questo problema senza creare nuovamente l'applicazione? anche l'applicazione è firmata ma non registrata in GAC. P.S: Come posso saltare di nuovo a costruire l'app, o è obbligatorio come la dll viene ricostruita?

Answer 1

Il motivo per cui si verifica l'errore è dovuto al fatto che l'assembly è stato firmato e molto probabilmente il riferimento ad esso ha la proprietà Versione specifica impostata su True e il numero di versione dell'assembly in cui è stata apportata la modifica è cambiato. Ho provato molti scenari e questo era l'unico scenario in cui sono riuscito a ottenere FileLoadException. Se avessi cambiato Target Framework in una versione più recente come 4.0, avresti invece una BadImageFormatException. Anche se dici di non aver cambiato il numero di versione, controllalo comunque, o imposta Versione specifica su Falso selezionando il tuo riferimento e facendo clic con il tasto destro e selezionando le proprietà.

tuo eccezione probabilmente si presentava così:

Could not load file or assembly 'LoadedAssembly, Version=1.0.0.0, Culture=neutral, 
PublicKeyToken=889080b75eb3bad2' or one of its dependencies. The located assembly's manifest 
definition does not match the assembly reference. (Exception from HRESULT: 0x80131040) 

Ma la tua versione compilata se l'assembly che viene fatto riferimento non è più 1.0.0.0 (o qualsiasi versione, per esempio). Nell'immagine qui sotto (beit small), puoi vedere che la proprietà reference sta cercando la versione 1.0.0.0, Versione specifica è impostata su True e l'assembly di riferimento è firmato ed è in realtà la versione 2.0.0.0, risultando in FileLoadException.

Risolvere questo problema modificando il numero di versione indietro e ricompilando oppure impostando Versione specifica su Falso e ricostruendo solo quella DLL. Non è necessario ricostruire l'intera applicazione.

Answer 2

È necessario ricreare gli assembly che fanno riferimento a questa nuova dll.

Answer 3

EventLog di Windows dovrebbe fornire ulteriori informazioni su ciò che non è stato possibile caricare. Hai introdotto un'altra dipendenza nella nuova DLL? Ho riscontrato qualcosa di simile, in cui una DLL di terze parti richiedeva l'installazione di C++ Runtime 2005 (che è il caso della maggior parte delle macchine di sviluppo e anche della maggior parte dei desktop, dato che è molto comune).

Answer 4

Wild guess ... puoi verificare se la cartella in cui risiede la DLL è contrassegnata come ReadOnly.

Fare clic con il tasto destro del mouse sulla cartella> Proprietà>deselezionare ReadOnly> fare clic su Applica> selezionare tutte le sottocartelle e i file> OK.

Ricostruisci la tua soluzione.

Answer 5

Hai provato a utilizzare la variabile di ambiente DEVPATH? Questa variabile di ambiente consente di definire una directory che funga da "GAC durante lo sviluppo". Tutto quello che dovete fare è:

1) Aggiungere il seguente elemento al vostro machine.config (doppio controllo quale posizione del vostro machine.config sta per essere usato)

• C: \ Windows \ Microsoft.NET \ Framework64 \ v2.0.50727 \ CONFIG O

• C: \ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ CONFIG *

2) Aggiungere una nuova variabile d'ambiente con il nome DEVPATH

set devpath="e:\temp\Message_DLL\bin\Debug"  /// manually, console 
/// or open windows config form - see below 

3) In seguito andare al vostro UI App/Progetto e aggiungere un riferimento alla DLL in la directory DEVPATH.

Assicurarsi di aver configurato "copia locale = false, versione specifica = false". Come potresti vedere Nome sicuro (nome Starker) è true.

4) Ora è necessario compilare una sola domanda di interfaccia utente! Dopodiché puoi scegliere di cambiare la tua fonte nella tua DLL come desideri. A causa della variabile DEVPATH, l'applicazione UI sceglierà sempre l'ultima build della tua DLL!

NOTA! Ho provato ad avviare l'applicazione dell'interfaccia utente da VS ma non sono riuscito con l'eccezione di caricamento. MA avviandolo dalle finestre di explorer - riuscito. Sembra che l'avvio dell'applicazione UI da VS induca il CLR a cercare altrove la DLL indicata.

---

Inoltre si può dare un'occhiata a MSDN e MSDN2.

Note: Utilizzare questa impostazione solo in fase di sviluppo. Il runtime non controlla le versioni sugli assiemi con nome sicuro trovati in DEVPATH. Semplicemente usa il primo assemblaggio che trova.

Si può dare un'occhiata ai seguenti articoli/pagine Web, anche.

CodeProject - Assembly location, binding, deploying

Social MSDN Questions about DEVPATH

Penso che questo dovrebbe fare il trucco!