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

Answer 1

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 2

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.

Answer 3

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

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

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 6

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... :)