c# - publickeytoken=null culture=neutral version=1.0.0.0 Could not load file or assembly or one of its dependencies



15 Answers

Open IIS Manager

Select Application Pools

then select the pool you are using

go to advanced settings (at right side)

Change the flag of Enable 32-bit application false to true.

could not load file or assembly visual studio

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?

I would also appreciate tips on how to debug problems like this in general.




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.




Despite the original question was posted 5 years ago the problem still persists and is rather annoying.

The general solution is thorough analysis of all referenced assemblies to understand what's going wrong. To make this task easier I made a tool (a Visual Studio extension) which allows selecting a .Net assembly (.ddl or .exe file) and get a graph of all referenced assemblies with hightlighted conflicting or missed references.

The tool is available in Visual Studio Gallery: https://marketplace.visualstudio.com/vsgallery/051172f3-4b30-4bbc-8da6-d55f70402734

Example of output:




I had similar problem. **Juntos answer is correct ** but you should note one important tip!

For unity 2.1.505.2 different AssemblyVersion and AssemblyFileVersion are specified:

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

So redirects should be applied to a version specified in AssemblyVersion: 2.1.505.0

<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?




  • Goto :Solution -> Package
  • Click on Advanced Tab (Find below the page)
  • Add your dll to additional assemblies(this way we can add external dlls in sharepoint).



Not sure if this might help.

Check that the Assembly name and the Default namespace in the Properies in your asemblies match. This resolved my issue which yielded the same error.




In my case in the bin folder was a non reference dll called Unity.MVC3 , i tried to search any reference to this in visual studio without success, so my solution was so easy as delete that dll from the bin folder.




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 "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.




Following worked for me.

  • Remove Temporary Files C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary 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



Look out for conflicting references. Even after a clean and rebuild, conflicting references will still cause a problem. My problem was between AForge and Accord. I removed both of the references, and re-added the references re-choosing the particular reference (particular to my case, just Accord).




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.




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.




Okay this may sound very stupid, but heres how I solved the issue after trying out every other solution and spending a night on this stupid thing.

I was getting the same error with some DLL missing from Bin Folder. I tried to delete , get back up everything from Team Foundation Server but didn't work. Got a copy of Bin folder from my office-matelocal machine, and replaced it. It didn't work either. At last, I manually FTPed server, got the copy of DLL which was showing up as missing, and then it started showing up that next file in the file list sequence is missing.

So I ftped server Got all Bin Folder, Manually replaced each file one by one. (Not Ctrl + All and replace.. I tried : it didn't work.) And somehow it worked...






Related