Ошибка could not load file or assembly

I’m having another of these «Could not load file or assembly or one of its dependencies» problems.

Additional information: Could not load
file or assembly
‘Microsoft.Practices.Unity,
Version=1.2.0.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35’ or
one of its dependencies. The located
assembly’s manifest definition does
not match the assembly reference.
(Exception from HRESULT: 0x80131040)

I have no idea what is causing this or how I could debug it to find the cause.

I’ve done a search in my solution catalogs .csproj files, and every where I have Unity I have:

Reference
Include=»Microsoft.Practices.Unity,
Version=2.0.414.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35,
processorArchitecture=MSIL»

Can’t find any reference anywhere which goes against 1.2.0.0 in any of my projects.

Any ideas how I should go about solving this?

Try to clean Debug and Release folders in your solution. Then remove and add unity again.

Microsoft Enterprise Library (referenced by .NetTiers) was our problem, which was in turn referencing an older version of Unity. In order to solve the problem we used the following binding redirection in the web.config:

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

Alternatively, you may want to just update the Enterprise Library to the latest version.

answered Jul 3, 2012 at 10:03

In solution explorer right click on project (not solution), in build tab choose Platform target : «Any CPU».

Juntos answer is correct but you should also consider:

For the unity v2.1.505.2 different AssemblyVersion and AssemblyFileVersion attributes are specified:

AssemblyFileVersion is used by the NuGet but CLR does not care about it!
CLR is going to use only AssemblyVersion!

So your redirects should be applied to a version that specified in AssemblyVersion attribute. So 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>

See also:
What are differences between AssemblyVersion, AssemblyFileVersion and AssemblyInformationalVersion?

answered Nov 26, 2014 at 11:15

I also got this terrible error and found a solution for this…

1. Right Click on the Solution name
2. Click Clean Solution
3. Restart Visual Studio
4. Goto project Properties >> Build
5. Change Configuration to Release
6. Start Debugging (F5)

1) , 2)

4) , 5)

Hope this will help you also.

answered Sep 17, 2015 at 18:24

answered Jan 5, 2016 at 0:00

You say you have a lot of projects in your solution … well, start with one near the top of the build order. Get that one to build and once you figure it out you can apply the same fix to the rest of them.

Honestly, you probably just need to refresh your reference. It sounds like you either updated your version and didn’t update the references, or it’s a relative path issue if you keep your solution in source control. Just verify your assumptions, and re-add the reference.

answered Dec 17, 2010 at 11:30

if you are getting this error message by opening an application on you windows xp it mean first you have installed that app due to its not working without net framework 4 and service pack 3 . you installed both and again you are getting this error so you should reinstall that app again but first uninstall from add and remove

if this not work please dont abuse me . i am also a junior

answered Nov 16, 2013 at 8:14

Following worked for me.

• Remove Temporary Files C:WindowsMicrosoft.NETFrameworkv4.0.30319Temporary ASP.NET Files
  • then right click on Temporary Asp.net Files>properties>security
    and give total control access to IIS and to all user runing my project

answered Mar 6, 2015 at 15:38

This issue happened to me where one of my dependent libraries was compiling a DLL with «Any CPU» when the parent library was expecting a compilation of «x64».

I had this today, and in my case the issue was very odd:

  <dependentAssembly>
    <assemblyIdentity name="Microsoft.Owin.Host.SystemWeb" publicKeyToken="31bf3856ad364e35" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-3.1.0" newVersion="3.1.0.0" />
  </dependentAssembly>0.

Note the stray characters at the end of the XML — somehow those had been moved from the version number to the end of this block of XML!

  <dependentAssembly>
    <assemblyIdentity name="Microsoft.Owin.Host.SystemWeb" publicKeyToken="31bf3856ad364e35" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-3.1.0.0" newVersion="3.1.0.0" />
  </dependentAssembly>

Changed to the above and voila! Everything worked again.

answered May 12, 2017 at 9:16

answered May 15, 2013 at 7:44

I «Set as Startup Project» the unloaded/unfound library/project.

Then deployed it.

It worked!

I think it couldn’t found the .dll because it was not in the assembly at first.

answered Jul 16, 2013 at 5:08

Another possible cause: make sure you haven’t accidentally given both of the projects the same assembly name in project properties.

My solution for .NET 4.0, using Enterprise Library 5, was to add a reference to:

Microsoft.Practices.Unity.Interception.dll

answered Jun 5, 2015 at 19:44

answered Mar 25, 2016 at 19:05

In my case, none of the proposed answer worked.

Here is what worked for me:

1. Remove the reference
2. Rename the DLL
3. Import the reference again

The second step was important apparently as it did not work without it.

answered Jun 23, 2016 at 8:38

answered Jul 6, 2016 at 15:33