Could not load file or assembly 'Microsoft.Practices.Unity'

Question

I am trying to upgrade Unity to version (2.1.505.2), but when I run the application I get the following FileLoadException

Could not load file or assembly 'Microsoft.Practices.Unity, Version=2.0.414.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies.

We are upgrading from Unity 2.0.414.0 to 2.1.505.2.

• All project references in the solution that refer to Unity refer to the correct version of the dll
• There is no Unity dll referenced in the Gac. (double checked by checking gacutil -l)

• I removed all Unity dlls from the archive. Double checked with powershell

  PS C:\> ls -rec -inc Microsoft.Practices.Unity.dll | foreach-object { "{0}`t{1}" -f $_.FullName, [System.Diagnostics.FileVersionInfo]::GetVersionInfo($_).FileVersion }
  

How can I find out what / who still refers to the Unity 2.0.414.0?

FusionLogVw doesn't tell me which DLL is causing the problem.

Any help is much appreciated!

Answer 1

The problem was another Microsoft dll that refers to the old version of unity. I found this out be accident be checking the namespaces of every referenced dll, and found another dll that contained namespaces with "unity".

Updating:

• Microsoft.Practices.EnterpriseLibrary.Common
• Microsoft.Practices.EnterpriseLibrary.Validation

to latest released versions resolved the problem.

I hope I save the day for some lost soul out there who's also pulling his hair out over this issue... :)

Answer 2

The binding redirect should be pointed to a proper assembly version.

For your case version 2.1.505.0 should be used!

<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
    <assemblyIdentity name="Microsoft.Practices.Unity" publicKeyToken="31bf3856ad364e35" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-2.1.505.0" newVersion="2.1.505.0" />
  </dependentAssembly>
</assemblyBinding>

2.1.505.2 cannot be specified because of next reason:

Unity assembly 2.1.505.2 has different versions specified in the AssemblyFileVersion and AssemblyVersion.

CLR is working with the AssemblyVersion and AssemblyFileVersion is ignored but NuGet is working with the AssemblyFileVersion!

So that's why you have this difference!

Please use AssemblyVersion

Answer 3

I wasn't able to correct it by using the EnterpriseLibrary update in the accepted solution. I ended up just overriding the dependent assembly version in the app.config, you could do something similar to force any library that complains about the version to use another version.

App.config:

  <dependentAssembly>
    <assemblyIdentity name="Unity.Container" publicKeyToken="489B6ACCFAF20EF0" culture="neutral"/>
    <bindingRedirect oldVersion="0.0.0.0-5.8.11.0" newVersion="5.8.11.0"/>
  </dependentAssembly>

Answer 4

Since your new question is about finding existing dependencies on an assembly, you might refer to this question:

How to find what depends on a specific version of a specific dependency?

Which refers to using Fuslogvw.exe

Answer 5

Check your app.config/web.config and of course your project references.

Answer 6

If you have resharper, you can remove the problem reference, build, goto the class where it is used(there is an error) and get resharper to fix it for you.

Saves faffing around, but I appreciate not everyone has resharper :D

Answer 7

Overview: this was someone's code I had to fix a bug in code, so they provided me a zip file of application.

I had no Idea what was happening and why always for the first time my code was running and after restart the application (post any changes) it start throwing Exception. there are many possible solution provided in the forums and i was blaming my code & database and then started undo each step i did. But that doesn't help

Solution: As multiple troubleshoot can't fix this but when I restarted investigate each n every thing from beaning to find the actual reason which is causing the exception, I found is

For every new build, my application's bin folder deleting the dlls

then the solution is to paste these dlls into applications bin folder and rebuild the code (refer screenshot)

result: all sh*t gone.