FileLoadException bei InitializeComponent oder X: Class =

Question

Ich bekomme eine Dateilader-Ausnahme (erste Chance) bei der InitializeComponent -Methode oder der Debugger bricht bei der x:Class Attribut der XAML-Root von mehreren WPF-Benutzersteuerelementen. Alles funktioniert gut, trotz der Tatsache, dass die Ausnahmen die Navigation sehr verlangsamen.

Dies ist die Ausnahmemeldung:

konnte nicht Datei oder Assembly 'Company.Solution.UserInterface, Version = 0.1.5568.25577, Culture = neutral, PublicKeyToken = 45069ab0c15881ce' laden oder eine ihrer Abhängigkeiten. Die Manifestdefinition der lokalisierten Assembly stimmt nicht mit der Assemblyreferenz überein. (Ausnahme von HRESULT: 0x80131040)

Dies ist die Fusion log:

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. 

My Projektstruktur hat eine Wurzel-Projekt, das ein Modul Projekt verweist (in dem die Ausnahme auftritt). Das Modulprojekt selbst verweist auf das Projekt, das Ziel der oben genannten Sondierung "Company.Product.UserInterface.dll" ist, die einige Ressourcen/Steuerelemente/Stile/Primitive/Konverter usw. enthält. Wie kann ich die FileLoadExceptions loswerden?

Eine weitere vollständigere 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. 

Im Moment ist die Ausnahme, die Version der Assembly in der SolutionExplorer verwiesen auftritt, ist 0.1.5577.18123 (in allen Lösungen, die die ..UserInterface.dll verweisen. ich habe keine Ahnung, wer 0.1.5577.18122 nachschlägt, ist diese Version gab es nie)

Wenn ich ein neues laufen wieder aufzubauen alles, was ich den gleichen Fehler, sieht Fusion für (ich nie diese Versionsnummer hatte):

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

die Version gefunden ist:

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

Visual Studio Version ist 2013 Ultimate und das Projekt ist auf .net4.5 bauen und die Montage Versionen werden automatisch in den Build-Prozess erzeugt. Ich habe das Build Log to tinyupload hochgeladen, da es zu groß war. Das vollständige Fusionsprotokoll finden Sie unter here at pastebin.

Answer 1

Vorschlag 1

Gibt es eine zyklische Referenz eine alte Version der DLL verursacht geladen werden? (Dies war nachweislich nicht der Punkt, aber ich bin aus historischen Gründen gegangen). Relating to this answer

Anregung 2

Können Sie eine Publisher-Politik versuchen zu schaffen? Hier ist ein Beispiel, das Ihrer app.config-Datei hinzugefügt werden muss.

<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

Vorschlag 3

etwas mit Bezug auf den Schlüssel geändert, dass Ihre Baugruppen zu unterzeichnen benutzt wird?

Anregung 4

Als leichte Anpassung meiner ursprünglichen Vorschlag. Sie haben angegeben, dass 3 Projekte auf Company.Solution.UserInterface verweisen. Können Sie bestätigen, dass alle 3 Projekte auf dieselbe Version der Assembly verweisen?

Answer 2

Version=0.1.5577.18122 

Diese automatisch generierte Versionsnummer sagt eine Geschichte, die letzten beiden Teile der Versionsnummer sind nicht willkürlich. Sie basieren auf dem Datum und der Uhrzeit, zu der die Baugruppe gebaut wurde. Die Build-Nummer wird aus der Anzahl der Tage seit dem 1. Januar 2000 generiert. Die Revisionsnummer ist die Anzahl der Sekunden * 2 seit Mitternacht ohne Sommerzeitkorrektur.

So wissen wir, dass die 18122 Versammlung am 30. März um 2:12:34 am Nachmittag gebaut wurde. Und dann wurde es wieder gebaut, 2 Sekunden später um 2:12:36 am Nachmittag. Nachdem es als eine Referenz-Assembly verwendet wurde, um ein anderes Projekt zu erstellen, spuckte das CLR Kugeln aus.

Dies sollte nicht passieren, ein Projekt muss nur einmal in einer einzigen Build-Sitzung erstellt werden. Um herauszufinden, warum dies passiert ist, müssen Sie den MSBuild-Trace durchsuchen. Sie erzeugen das, was Sie brauchen, mit Tools + Optionen, Projekte und Lösungen, Erstellen und Ausführen. Ändern Sie die Einstellung "MSBuild-Projekt Build-Ausgabe Ausführlichkeit" auf Detailliert. MSBuild wird jetzt sehr gesprächig und sagt Ihnen, warum es sich entschieden hat, ein Projekt zu erstellen. Wenn Sie sich im Wald verirren und versuchen, seine Ausgabe zu dekodieren (es gibt eine Menge davon), dann kopieren Sie sie in einen Papierkorb und fügen Sie sie in Ihre Frage ein.

Es gibt sonst nicht so viele großartige Erklärungen für ein Missgeschick wie dieses. Bei älteren VS-Versionen war es zu einfach, versehentlich eine zirkuläre Abhängigkeit zwischen Projekten zu erstellen. Sie spülen das aus, indem Sie Build + Clean verwenden. Der Neuaufbau der Lösung schlägt fehl und sagt Ihnen, welche Referenzbaugruppe der Unruhestifter ist. Sie verwenden jedoch .NET 4, also mindestens VS2010. Also kein fantastischer Vorsprung, Microsoft hat weitere Prüfungen hinzugefügt, um zu verhindern, dass dies ohne Warnung geschieht. Nicht sicher, ob es in allen Fällen zuverlässig ist, könnte es täuschen, wenn Sie beispielsweise nicht auf MSBuild angewiesen sind. Nicht ungewöhnlich auf Build-Servern mit "Continuous Integration" -Funktionen.

Wir benötigen die Build-Trace, um Ihnen eine zuverlässige Diagnose zu geben.