FileLoadException A InitializeComponent o x: Class =

Question

Ricevo un'eccezione di caricamento file (prima possibilità) al metodo InitializeComponent o il debugger si interrompe nell'attributo x:Class della xaml-root di più controlli utente WPF. Tutto funziona bene nonostante il fatto che le eccezioni rallentino molto la navigazione.

Questo è il messaggio di eccezione:

Impossibile caricare il file o l'assembly 'Company.Solution.UserInterface, Version = 0.1.5568.25577, Culture = neutral, PublicKeyToken = 45069ab0c15881ce' o una delle sue dipendenze. La definizione manifest di assembly individuato non corrisponde al riferimento all'assembly. (Eccezione da HRESULT: 0x80131040)

Questo è il log Fusion:

Assembly manager loaded from: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll 
Running under executable D:\Development\Product\Main\src\Company.Product \bin\Debug\Product.vshost.exe 
--- A detailed error log follows. 

=== Pre-bind state information === 
LOG: DisplayName = Company.Product .UserInterface, Version=0.1.5568.25577, Culture=neutral, PublicKeyToken=45069ab0c15881ce 
(Fully-specified) 
LOG: Appbase = file:///D:/Development/Product/Main/src/Company.Product/bin/Debug/ 
LOG: Initial PrivatePath = NULL 
Calling assembly : PresentationFramework, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35.  
LOG: This bind starts in default load context. 
LOG: Using application configuration file: D:\Development\Product \Main\src\Company.Product \bin\Debug\Product .vshost.exe.Config 
LOG: Using host configuration file: 
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config. 
LOG: Post-policy reference: Company.Product .UserInterface, Version=0.1.5568.25577, Culture=neutral, PublicKeyToken=45069ab0c15881ce 
LOG: Attempting download of new URL file:///D:/Development/Product/Main/src/Company.Product/bin/Debug/Company.Product.UserInterface.DLL. 
WRN: Comparing the assembly name resulted in the mismatch: Revision Number 
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated. 

mia struttura del progetto ha un progetto principale che fa riferimento a un progetto di modulo (in cui si verifica l'eccezione). Il modulo stesso progetto fa riferimento al progetto che è l'obiettivo del suddetto sondaggio "Company.Product.UserInterface.dll" che contiene alcune risorse/controlli/stili/primitive/convertitori e così via.

Come posso liberare il FileLoadExceptions?

Un altro più completo Fusion-log:

=== Pre-bind state information === 
LOG: DisplayName = Company.Product.UserInterface, Version=0.1.5577.18122,  Culture=neutral, PublicKeyToken=45069ab0c15881ce 
(Fully-specified) 
LOG: Appbase = file:///D:/Development/Product/Main/src/Company.Product/bin/Debug/ 
LOG: Initial PrivatePath = NULL 
LOG: Dynamic Base = NULL 
LOG: Cache Base = NULL 
LOG: AppName = Product.vshost.exe 
Calling assembly : PresentationFramework, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35. 
LOG: This bind starts in default load context. 
LOG: Using application configuration file: D:\Development\Product\Main\src\Company.Product\bin\Debug\Product.vshost.exe.Config 
LOG: Using host configuration file: 
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config. 
LOG: Post-policy reference: Company.Product.UserInterface, Version=0.1.5577.18122, Culture=neutral, PublicKeyToken=45069ab0c15881ce 
LOG: GAC Lookup was unsuccessful. 
LOG: Attempting download of new URL file:///D:/Development/Product/Main/src/Company.Product/bin/Debug/Company.Product.UserInterface.DLL. 
LOG: Assembly download was successful. Attempting setup of file: D:\Development\Product\Main\src\Company.Product\bin\Debug\Company.Product.UserInterface.dll 
LOG: Entering run-from-source setup phase. 
LOG: Assembly Name is: Company.Product.UserInterface, Version=0.1.5577.18123, Culture=neutral, PublicKeyToken=45069ab0c15881ce 
WRN: Comparing the assembly name resulted in the mismatch: Revision Number 
ERR: The assembly reference did not match the assembly definition found. 
ERR: Run-from-source setup phase failed with hr = 0x80131040. 
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated. 

Al momento l'eccezione si verifica la versione dell'assembly nel SolutionExplorer riferimento è 0.1.5577.18123 (in tutte le soluzioni che fanno riferimento al ..UserInterface.dll. non ho idea di chi guarda in alto 0.1.5577.18122, questa versione ha mai esiste)

Se corro una nuova ricostruzione tutto quello che ottiene lo stesso errore, Fusion cerca la (non ho mai avuto questo numero di versione):

LOG: Post-policy reference: Company.Product.UserInterface, Version=0.1.5577.18465, Culture=neutral, PublicKeyToken=45069ab0c15881ce 

la versione trovata è:

LOG: Assembly Name is: Company.Product.UserInterface, Version=0.1.5577.18466, Culture=neutral, PublicKeyToken=45069ab0c15881ce 

Visual Studio Version è il 2013 Ultimate e il progetto è costruire sulle .net4.5 e le versioni di montaggio sono auto generato nel processo di generazione. Ho caricato il registro di build to tinyupload perché era troppo grande. È possibile trovare il registro Fusion completo here at pastebin.

Answer 1

Suggerimento 1

C'è un riferimento ciclico provocando una vecchia versione della DLL da caricare? (questo è stato dimostrato non essere il punto, ma ho lasciato in per motivi storici). Relating to this answer

Suggerimento 2

Puoi provare a creare una politica Publisher? Ecco un esempio che deve essere aggiunto al tuo file app.config.

<runtime> 
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> 
    <dependentAssembly> 
     <assemblyIdentity name="Company.Solution.UserInterface" 
         publicKeyToken="45069ab0c15881ce" 
         culture="en-us" /> 
     <!-- Redirecting to version 0.1.5568.25577 of the assembly. --> 
     <bindingRedirect oldVersion="0.0.0.0-0.1.5568.25577" 
         newVersion="0.1.5568.25577"/> 
    </dependentAssembly> 
    </assemblyBinding> 
</runtime> 

Explained in further detail here

Suggerimento 3

è cambiato qualcosa per quanto riguarda la chiave che viene utilizzato per firmare gli assembly?

Suggerimento 4

Come un leggero adattamento del mio suggerimento iniziale. Hai dichiarato che ci sono 3 progetti che fanno riferimento a Company.Solution.UserInterface. Puoi confermare che tutti e 3 i progetti fanno riferimento alla stessa versione di quell'assemblea?

Answer 2

Version=0.1.5577.18122 

Questo numero di versione generato automaticamente racconta una storia, le ultime due parti del numero di versione non sono arbitrarie. Si basano sulla data e l'ora in cui è stato creato l'assemblaggio. Il numero di build viene generato dal numero di giorni dal 1 ° gennaio 2000. Il numero di revisione è il numero di secondi * 2 dalla mezzanotte senza correzione dell'ora legale.

Quindi, sappiamo che l'assemblea del 18122 è stata costruita il 30 marzo alle 2:12:34 nel pomeriggio. E poi è stato creato di nuovo, 2 secondi dopo alle 2:12:36 del pomeriggio. Dopo che è stato usato come assembly di riferimento per costruire un altro progetto, questo ha fatto i proiettili sputo CLR.

Questo dovrebbe non, un progetto deve essere creato solo una volta in una singola sessione di generazione. Scoprire perché è successo richiede scavare nella traccia di MSBuild. Generai quello che ti serve con Strumenti + Opzioni, Progetti e Soluzioni, Costruisci ed Esegui. Modifica l'impostazione "Produzione verbosità output del progetto MSBuild" su Dettagliato. MSBuild ora diventa molto loquace e ti dice perché ha deciso di costruire un progetto. Se ti perdi nei boschi cercando di decodificare la sua uscita (ce n'è molta), copialo/incollalo in un contenitore di pasta e collegalo ad esso nella tua domanda.

Altrimenti non ci sono molte grandi spiegazioni per un contrattempo come questo. Le versioni precedenti di VS rendevano troppo facile creare accidentalmente una dipendenza circolare tra i progetti. Lo estrai utilizzando Build + Clean. La ricostruzione della soluzione non riesce e ti dice quale assembly di riferimento è il troublemaker. Si sta comunque utilizzando .NET 4, quindi almeno VS2010. Quindi, non un vantaggio eccezionale, Microsoft ha aggiunto ulteriori controlli per evitare che ciò accada senza un avvertimento. Non è sicuro se sia affidabile in tutti i casi, potrebbe essere ingannato se non si dipende da MSBuild da solo, ad esempio. Non raro nei server di build con funzionalità di "integrazione continua".

Abbiamo bisogno della traccia di costruzione per darvi una diagnosi affidabile.