FileLoadException At InitializeComponent or x:Class=

Question

I get a file loader exception (first chance) at the InitializeComponent-method or the debugger breaks at the x:Class attribute of the xaml-root of multiple WPF user controls. Everything works fine despite the fact that the exceptions slow down navigation by a lot.

This is the exception message:

Could not load file or assembly 'Company.Solution.UserInterface, Version=0.1.5568.25577, Culture=neutral, PublicKeyToken=45069ab0c15881ce' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

This is the 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 project structure has a root project that references a module project (in which the exception occurs). The module project itself references the project that is the target of the above mentioned probing "Company.Product.UserInterface.dll" which contains some resources / controls / styles / primitives / converters and so on.

How can I get rid of the FileLoadExceptions?

Another more complete 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.

At the moment the exception occurs the version of the assembly in the SolutionExplorer referenced is 0.1.5577.18123 (in all solutions that reference the ..UserInterface.dll. I have no idea who looks up 0.1.5577.18122, this version did never exist)

If I run a new rebuild all I get the same error, Fusion looks for (I never had this version number):

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

the version found is:

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

Visual Studio Version is 2013 Ultimate, and the project is build on .net4.5 and the assembly versions are auto generated in the build process. I uploaded the build log to tinyupload as it was too big. The full Fusion-log can be found here at pastebin.

Hatchery

Did you check your Fusion log? – Papaya

Is the UserInterface.dll referenced only by one project? – Tactful

No the UserInterface is used by 3 Projects, which are then all Put together by the dependency root. I can post the dependency graph if that helps – Hatchery

Could it be that one of the 3 projects is referencing an older version? – Tours

No the projects have the same Referenced Version – Hatchery

@Console dependency graph would be helpful indeed. However yet another thing you can do is to go through projects referencing UserInterface and inspect the reference path (I mean Project->References->SpecificReference->Properties). Perhaps one of the projects tries to load from different place ? – Tactful

How are you generating your version numbers? I am assuming it is auto generated as the version number is changing frequently from your logs. If this is the case it does look like one of your projects could be being built before your UserInterface project. I am fairly sure this is only possible if one of the projects is referencing the dll and not the project creating the dll. – Tours

Open each assembly with some IL tool (ILDasm or ILSpy would do) and check references - one should clearly show wrong reference to UserInterface and at that point you'll have a way to hunt down build issues. – Narcisanarcissism

Also it may help to specify version explicitly to rule out strange stale references - consider to try and update the post. – Narcisanarcissism

@Console did you ever find a solution to this? Im having the exact same problem. – Farris

@Farris no I did not find anything to solve this without setting the Versions hardcoded (which is awkward) – Hatchery

Answer 1

   Version=0.1.5577.18122

This auto-generated version number tells a tale, the last two parts of the version number are not arbitrary. They are based on the date and time the assembly was built. The build number is generated from the number of days since Jan 1st, 2000. The revision number is the number of seconds*2 since midnight without daylight savings correction.

So facts we know is that the 18122 assembly was built on March 30th at 2:12:34 in the afternoon. And then it got built again, 2 seconds later at 2:12:36 in the afternoon. After it was used as a reference assembly to build another project, that made the CLR spit bullets.

This should not happen, a project must be built only once in a single build session. Finding out why this happened requires digging through the MSBuild trace. You generate the one you need with Tools + Options, Projects and Solutions, Build and Run. Change the "MSBuild project build output verbosity" setting to Detailed. MSBuild now gets very chatty and tells you why it decided to build a project. If you get lost in the woods trying to decode its output (there's a lot of it) then copy/paste it in a paste-bin and link to it in your question.

There are otherwise not that many great explanations for a mishap like this. Older VS versions made it too easy to accidentally create a circular dependency between projects. You flush that out by using Build + Clean. Rebuilding the solution now fails and tells you which reference assembly is the troublemaker. You are using .NET 4 however, so at least VS2010. So not a fantastic lead, Microsoft added more checks to prevent this from happening without a warning. Not sure if it is reliable in all cases, it could be fooled if you don't depend on MSBuild alone for example. Not uncommon on build servers with "continuous integration" features.

We need the build trace to give you a reliable diagnostic.

Angadresma

I viewed through the MSBuild log, but could not find anything indicating a problem. the project only got build once. The references of all other Projects to the UserInterface.dll show the same version. – Hatchery

The version number very strongly hints that you are overlooking something. You'll need to come up with a way that this assembly got built twice within 2 seconds on your machine. Hitting Build + Build twice within 2 seconds is technically possible I suppose. There are just no leads if you don't show us something. Like that build trace. – Angadresma

I added the build trace to my question. – Hatchery

I see a fair number of mishaps but nothing yells loudly. There is one detail that's interesting, your projects are stored on the D: drive. What kind of drive is this? 2 seconds is a magic number for file systems, it is the timestamp resolution of a FAT32 drive. – Angadresma

its a NTFS formated SSD (nothing physical, just a partition) – Hatchery

I'm out of theories. The only thing I can recommend is that you don't rely on the auto-generated version. Edit the project's AssemblyInfo.cs file and change [assembly: AssemblyVersion("0.1.*")] to "0.1.0.0" – Angadresma

Changing the Assembly Version to a fixed Version is rather a workaround than a solution. But as I did not found any better way to get around the exceptions, I did actually change the AssemblyVersions to fixed numbers. – Hatchery

Answer 2

Suggestion 1

Is there a cyclic reference causing an old version of the dll to be loaded? (this was proven not to be the point but I have left in for historical reasons). Relating to this answer

Suggestion 2

Can you try creating a Publisher Policy? Here is an example that needs to be added to your app.config file.

<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

Suggestion 3

Has anything changed with regards to the key that is being used to sign your assemblies?

Suggestion 4

As a slight adaption of my initial suggestion. You have stated that there are 3 projects that reference Company.Solution.UserInterface. Can you confirm that all 3 projects are referencing the same version of that assembly?

Tours

I don't have cyclic references, a cyclic reference would fail, while my application does run as expected, it just is horrible slow on the Creation of UserControls / Pages – Hatchery

@Console It might not necessarily be a cyclic reference but from the error message it looks like you are loading a version that does not match what you project expects. If you check your reference in VS does it have Specific Version set to True? – Tours

@Console failing that have you tried setting up a Publisher Policy? msdn.microsoft.com/en-us/library/dz32563a(v=VS.90).aspx – Tours

The assembiels are all Strong named so yes the Versions must exact match. But they do. The version of the dll that my project generates does match the Version of the message. – Hatchery

Did you check that there isn't an old version in the GAC? – Tours

While this link may answer the question, it is better to include the essential parts of the answer here and provide the link for reference. Link-only answers can become invalid if the linked page changes. – Virtuous

There is no version of this dll at the GAC, The Project is Part of my Solution, I reference the Project not the dll itself – Hatchery

@Virtuous I have improved my answer – Tours

The binding redirection did not solve the problem, the key was never changed. – Hatchery