We Keep Coding

Function failed when called from other project due to assembly file c# [duplicate]

I am trying to run some unit tests in a C# Windows Forms application (Visual Studio 2005), and I get the following error:
System.IO.FileLoadException: Could not load file or assembly 'Utility, Version=1.2.0.200, Culture=neutral, PublicKeyToken=764d581291d764f7' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)**
at x.Foo.FooGO()
at x.Foo.Foo2(String groupName_) in Foo.cs:line 123
at x.Foo.UnitTests.FooTests.TestFoo() in FooTests.cs:line 98**
System.IO.FileLoadException: Could not load file or assembly 'Utility, Version=1.2.0.203, Culture=neutral, PublicKeyToken=764d581291d764f7' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
I look in my references, and I only have a reference to Utility version 1.2.0.203 (the other one is old).
Any suggestions on how I figure out what is trying to reference this old version of this DLL file?
Besides, I don't think I even have this old assembly on my hard drive.
Is there any tool to search for this old versioned assembly?

The .NET Assembly loader:
is unable to find 1.2.0.203
but did find a 1.2.0.200
This assembly does not match what was requested and therefore you get this error.
In simple words, it can't find the assembly that was referenced. Make sure it can find the right assembly by putting it in the GAC or in the application path.
run below command to add the assembly dll file to GAC:
gacutil /i "path/to/my.dll"
Also see https://learn.microsoft.com/archive/blogs/junfeng/the-located-assemblys-manifest-definition-with-name-xxx-dll-does-not-match-the-assembly-reference.

You can do a couple of things to troubleshoot this issue. First, use Windows file search to search your hard drive for your assembly (.dll). Once you have a list of results, do View->Choose Details... and then check "File Version". This will display the version number in the list of results, so you can see where the old version might be coming from.
Also, like Lars said, check your GAC to see what version is listed there. This Microsoft article states that assemblies found in the GAC are not copied locally during a build, so you might need to remove the old version before doing a rebuild all. (See my answer to this question for notes on creating a batch file to do this for you)
If you still can't figure out where the old version is coming from, you can use the fuslogvw.exe application that ships with Visual Studio to get more information about the binding failures. Microsoft has information about this tool here. Note that you'll have to enable logging by setting the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion\EnableLog registry key to 1.

I just ran into this problem myself, and I found that the issue was something different than what the others have run into.
I had two DLLs that my main project was referencing: CompanyClasses.dll and CompanyControls.dll. I was getting a run-time error saying:
Could not load file or assembly
'CompanyClasses, Version=1.4.1.0,
Culture=neutral,
PublicKeyToken=045746ba8544160c' or
one of its dependencies. The located
assembly's manifest definition does
not match the assembly reference
Trouble was, I didn't have any CompanyClasses.dll files on my system with a version number of 1.4.1. None in the GAC, none in the app folders...none anywhere. I searched my entire hard drive. All the CompanyClasses.dll files I had were 1.4.2.
The real problem, I found, was that CompanyControls.dll referenced version 1.4.1 of CompanyClasses.dll. I just recompiled CompanyControls.dll (after having it reference CompanyClasses.dll 1.4.2) and this error went away for me.

The following redirects any assembly version to version 3.1.0.0. We have a script that will always update this reference in the App.config so we never have to deal with this issue again.
Through reflection you can get the assembly publicKeyToken and generate this block from the .dll file itself.
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Castle.Core" publicKeyToken="407dd0808d44fbdc" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-65535.65535.65535.65535" newVersion="3.1.0.0" />
</dependentAssembly>
</assemblyBinding>
Note that without an XML namespace attribute (xmlns) this will not work.

If you are using Visual Studio, try "clean solution" and then rebuild your project.

I am going to blow everyone's mind right now . . .
Delete all the <assemblyBinding> references from your .config file, and then run this command from the NuGet Package Manager console:
Get-Project -All | Add-BindingRedirect

The other answers wouldn't work for me. If you don't care about the version and you just want your app to run then right click on the reference and set 'specific version' to false...This worked for me.

In my case, this error occurred while running an ASP.NET application.
The solution was to:
Delete the obj and bin folders in the project folder
Clean didn't work, rebuild didn't work, all references were fine, but it wasn't writing one of the libraries. After deleting those directories, everything worked perfectly.

I added a NuGet package, only to realize a black-box portion of my application was referencing an older version of the library.
I removed the package and referenced the older version's static DLL file, but the web.config file was never updated from:
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" />
<bindingRedirect oldVersion="0.0.0.0-4.5.0.0" newVersion="6.0.0.0" />
</dependentAssembly>
to what it should have reverted to when I uninstalled the package:
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" />
<bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="4.5.0.0" />
</dependentAssembly>

I just ran across this issue and the problem was I had an old copy of the .dll in my application debug directory. You might want to also check there (instead of the GAC) to see if you see it.

In my case it was an old version of the DLL in C:\WINDOWS\Microsoft.NET\Framework\~\Temporary ASP.NET Files\ directory. You can either delete or replace the old version, or you can remove and add back the reference to the DLL in your project. Basically, either way will create a new pointer to the temporary ASP.NET Files.

Is possible you have a wrong nugget versions in assemblyBinding try:
Remove all assembly binding content in web.config / app.config:
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Microsoft.Extensions.Logging.Abstractions" publicKeyToken="adb9793829ddae60" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-3.1.3.0" newVersion="3.1.3.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Microsoft.Extensions.DependencyInjection" publicKeyToken="adb9793829ddae60" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-3.1.3.0" newVersion="3.1.3.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="System.ComponentModel.Annotations" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-4.2.1.0" newVersion="4.2.1.0" />
</dependentAssembly>
</assemblyBinding>
Type in Package Manager Console: Add-BindingRedirect
All necessary binding redirects are generated
Run your application and see if it works properly. If not, add any missing binding redirects that the package console missed.

For us, the problem was caused by something else. The license file for the DevExpress components included two lines, one for an old version of the components that was not installed on this particular computer. Removing the older version from the license file solved the issue.
The annoying part is that the error message gave no indication to what reference was causing the problems.

I would like to just add that I was creating a basic ASP.NET MVC 4 project and added DotNetOpenAuth.AspNet via NuGet. This resulted in the same error after I referenced a mismatching DLL file for Microsoft.Web.WebPages.OAuth.
To fix it I did a Update-Package and cleaned the solution for a full rebuild.
That worked for me and is kind of a lazy way, but time is money:-P

This exact same error is thrown if you try to late bind using reflection, if the assembly you are binding to gets strong-named or has its public-key token changed. The error is the same even though there is not actually any assembly found with the specified public key token.
You need to add the correct public key token (you can get it using sn -T on the dll) to resolve the error. Hope this helps.

I got this error while building on Team Foundation Server's build-service. It turned out I had multiple projects in my solution using different versions of the same library added with NuGet. I removed all old versions with NuGet and added the new one as reference for all.
Team Foundation Server puts all DLL files in one directory, and there can only be one DLL file of a certain name at a time of course.

My issue was copying source code to a new machine without pulling over any of the referenced assemblies.
Nothing that I did fixed the error, so in haste, I deleted the BIN directory altogether. Rebuilt my source code, and it worked from then on out.

Mine was a very similar situation to the post by Nathan Bedford but with a slight twist. My project too referenced the changed dll in two ways. 1) Directly and 2) Indirectly by referencing a component (class library) that itself had a reference to the changed dll. Now my Visual studio project for the component(2) referenced the correct version of the changed dll. However the version number of the compnent itself was NOT changed. And as a result the install of the new version of the project failed to replace that component on the client machine.
End result: Direct reference (1) and Indirect reference(2) were pointing to different versions of the changed dll at the client machine. On my dev machine it worked fine.
Resolution: Remove application; Delete all the DLLS from application folder; Re-install.Simple as that in my case.

After trying many of the above solutions with no fix, it came down to making sure 'Auto-generate binding redirects' was turned on within your application in Visual Studio.
More information on enabling automatic binding redirection can be found here: https://learn.microsoft.com/en-us/dotnet/framework/configure-apps/how-to-enable-and-disable-automatic-binding-redirection

I'll let someone benefit from my shear stupidity. I have some dependencies to a completely separate application (let's call this App1). The dll's from that App1 are pulled into my new application (App2). Any time I do updates in APP1, I have to create new dll's and copy them into App2. Well. . .I got tired of copying and pasting between 2 different App1 versions, so I simply added a 'NEW_' prefix to the dll's.
Well. . . I'm guessing that the build process scans the /bin folder and when it matches something up incorrectly, it barfs with the same error message as noted above. I deleted my "new_" versions and it built just dandy.

My app.config contains a
<bindingRedirect oldVersion="1.0.0.0" newVersion="2.0.11.0"/>
for npgsql. Somehow on the user's machine, my app.exe.config went missing. I am not sure if it was a silly user, installer glitch, or wacked out anti-virus yet. Replacing the file solved the issue.

I just found another reason why to get this error. I cleaned my GAC from all versions of a specific library and built my project with reference to specific version deployed together with the executable. When I run the project I got this exception searching for a newer version of the library.
The reason was publisher policy. When I uninstalled library's versions from GAC I forgot to uninstall publisher policy assemblies as well so instead of using my locally deployed assembly the assembly loader found publisher policy in GAC which told it to search for a newer version.

To me the code coverage configuration in the "Local.testtesttings" file "caused" the problem. I forgot to update the files that were referenced there.

Just deleting contents of your project's bin folder and rebuild the solution solved my problem.

I faced the same problem while running my unit testcases.
The error clearly states the problem is: when we try to load assembly, the .NET assembly loader tries to load its referred assemblies based on its manifest data (referred assembly name, public key token, version).
To check manifest data:
Open the Visual Studio command prompt,
Type 'ildasm' and drag the required assembly to the ILDASM window and open MANIFEST view. Sometimes MANIFEST contains one assembly with two versions old version as well as new version(like Utility, Version=1.2.0.200 and Utility, Version=1.2.0.203). In reality, the referred assembly is Utility, Version=1.2.0.203(new version), but since the manifest contains even Utility, Version=1.2.0.200(old version), .NET assembly loader tries to find out this versioned DLL file, fails to find and so throws exception.
To solve this, just drag each of the project dependent assemblies to the ILDASM window separately and check which dependent assembly holds the manifest data with the old assembly version. Just rebuild this dependent assembly and refer it back to your project.

A general answer to this kind of issue is to use binding redirects as in other answers. However, that's only part of the problem - you need to know the correct version of the assembly file that you're using. Windows properties is not always accurate and nuget is also not always accurate.
The only way to get correct version info is to analyse the file itself. One useful tool is dotPeek. The assembly name listed in dotPeek is always accurate in my experience.
So for example, the correct binding for this file is the following:
<dependentAssembly>
<assemblyIdentity name="System.ComponentModel.Annotations" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
<bindingRedirect oldVersion="0.0.0.0-4.2.1.0" newVersion="4.2.1.0"/>
</dependentAssembly>
Windows explorer says the file is 4.6.26515.06, nuget says its a 5.0.0.0 file. dotPeek says it is 4.2.1.0 and that is the version that works correctly in our software. Also note that the public key and culture are important and dotPeek also show this information.

Here's my method of fixing this issue.
From the exception message, get the name of the "problem" library and the "expected" version number.
Find all copies of that .dll in your solution, right-click on them, and check which version of the .dll it is.
Okay, so in this example, my .dll is definitely 2.0.5022.0 (so the Exception version number is wrong).
Search for the version number which was shown in the Exception message in all of the .csproj files in your solution. Replace this version number with the actual number from the dll.
So, in this example, I would replace this...
<Reference Include="DocumentFormat.OpenXml, Version=2.5.5631.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL" />
... with this...
<Reference Include="DocumentFormat.OpenXml, Version=2.0.5022.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL" />
Job done !

The question has already an answer, but if the problem has occurred by NuGet package in different versions in the same solution, you can try the following.
Open NuGet Package Manager, as you see my service project version is different than others.
Then update projects that contain an old version of your package.

clean and rebuild the solution might not replace all the dll's from the output directory.
what i'll suggest is try renaming the folder from "bin" to "oldbin" or "obj" to "oldobj"
and then try build your silution again.
incase if you are using any third party dll's those you will need to copy into newly created "bin" or "obj" folder after successful build.
hope this will work for you.

No solution worked for me. I tried clean project solution, remove bin, update package, downgrade package and so on... After two hours I loaded default App.config from project with assemblies and there I changed wrong reference version from:
<dependentAssembly>
<assemblyIdentity name="Microsoft.IdentityModel.Logging" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-5.5.0.0" newVersion="5.5.0.0" />
</dependentAssembly>
to:
<dependentAssembly>
<assemblyIdentity name="Microsoft.IdentityModel.Logging" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-3.14.0.0" newVersion="5.5.0.0" />
</dependentAssembly>
After this I cleaned project, build it again and it worked. No warning no problem.

ASP.NET Website Project builds but errors on publish

We have a .NET 4 Website Project created using Visual Studio 2013, it references the System.Net.Http .dll.
This is the line in web.config that loads the .dll:
<add assembly="System.Net.Http, Version=1.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/>
The project builds fine but when we try to “Publish Web Site” it gives the following error:
The type or namespace name ‘Http’ does not exist in the namespace
‘System.Net’ (are you missing an assembly reference?)
It looks like the assembly might be loading from the GAC, we have tried putting the assembly in the application’s BIN folder but this makes no difference – it is still showing as a GAC reference on the project property pages.
We have also tried adding:
<runtime>
<assemblyBinding>
<dependentAssembly>
<assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
<codeBase version="1.0.0.0" href="/bin/System.Net.Http.dll"/>
</dependentAssembly>
</assemblyBinding>
As suggested here: Could not load file or assembly System.Web.Http.WebHost after published to Azure web site
But this does not seem to work either.
We have changed the Target Framework to 3.5 and 4.5 with no effect.
We have tried publishing from several different machines.
EDIT: We have tried the nuget package suggest in RobAda and it hasn't had the desired effect, we are still getting errors.

I have seen the same problem on a friends app, we needed to dig around quite a bit but eventually found that you need to install this nuget package:
https://www.nuget.org/packages/Microsoft.Net.Http
You will then need to add the reference to System.Net.Http for it to not produce the stated error.

Sound like you are trying to shoehorn something where it does not/cannot fit.
One possible architectural approach would be to separate the functionality out into a solution.
If time constraints are an issue and this is a possibility, it may be the solution to your problems.
Long term though: It would be worth ensuring that you keep up to date with the times as you will get more issues like this as time moves on, of course this must be approach pragmatically...

Microsoft.data.edm.dll being copied from "somewhere" on build in VS 2013

I am collaborating with another developer using VS2013 and VSO.
The solution runs fine on his machine but mine complains of:
"Could not load file or assembly 'Microsoft.Data.Edm' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)"
We've isolated this to the fact that 1 project within the solution is copying version 6.5.0 of this DLL into the bin folder upon build which is overwriting the 6.5.2 version required by other parts of the solution.
We aren't sure where it is finding this version of the DLL as it only happens on my build. We are using various nuget packages but all are up to date and identical between our machines.
Does VS pick up DLLs such as this from "standard locations" on the machine somwehere? I searched my hard drive and found various versions of the DLL going from 2.0 to 2.6.2. The most suspect of these seems to be:
C:\Program Files\Microsoft ASP.NET\ASP.NET MVC 4\Packages\Microsoft.Data.Edm.5.2.0\lib\net40
Is there anywhere I can tell VS not to get this DLL from some random location?
Thanks

Try to build it with detailed MSBuild information (Tools -> Options -> Projects and Solutions -> Build and Run) and then copy the output and search for Microsoft.Data.Edm.dll to find where it's copied and where does it come from.
To force the copy of the correct version, you can add an assembly redirect to the app.config file of the project (you may already have this section if you have used NuGet):
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Microsoft.Data.Edm" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-5.6.2.0" newVersion="5.6.2.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>
This will force the use of the correct version on compilation and will not try to get the other version from the GAC or the system PATH environment variable.

Could not load file or assembly 'Microsoft.Data.Edm'

We are using the Windows Azure Storage NuGet package version 4.1.0, this has a dependency on Microsoft.Data.OData and has added that package as well which has the Microsoft.Data.Edm dll. When we build and run the application we very occasionally get the following error:
Could not load file or assembly 'Microsoft.Data.Edm' or one of its dependencies. The
located assembly's manifest definition does not match the assembly reference. (Exception
from HRESULT: 0x80131040)
We have the following binding redirect in the web.config and also have checked and this is the only version of Microsoft.Data.Edm being referenced by any projects in the solution.
<dependentAssembly>
<assemblyIdentity name="Microsoft.Data.Edm" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-5.6.1.0" newVersion="5.6.1.0" />
</dependentAssembly>
Sometimes when I look in the bin folder I find the dll version of Microsoft.Data.Edm is v 5.6.0. I have been through all the projects and I cannot find a reference to Microsoft.Data.Edm except with the storage client and that is definitely 5.6.1.
What is the best way to try and work out where the 5.6.0 version is coming from? When we do get this error we delete the bin and obj folders and rebuild and then it works fine, the 5.6.1 version is there and everything works but eventually it happens again.
EDIT:
We have upgraded again to all the latest versions from NuGet and still no luck, I ran a tool which shows the following dependencies:
Possible conflicts for Microsoft.Data.Edm:
Microsoft.Data.OData references Microsoft.Data.Edm, Version=5.6.2.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35
Microsoft.Data.Services.Client references Microsoft.Data.Edm, Version=5.6.2.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35
Microsoft.WindowsAzure.Storage references Microsoft.Data.Edm, Version=5.6.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35
Possible conflicts for Microsoft.Data.OData:
Microsoft.Data.Services.Client references Microsoft.Data.OData, Version=5.6.2.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35
Microsoft.WindowsAzure.Storage references Microsoft.Data.OData, Version=5.6.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35
What I don't understand is we have the app binding redirects set but sometime the 2.6.0 version is copied in and sometimes the 2.6.2. Does anyone know why this would be happening, never had this problem before.

I had the same error message but my issue was unrelated to any Azure product. In my case, I updated OData from version 3 to 4 and it appears to me that Nuget left behind binding redirects for deprecated dll's. There were actually three in total, Microsoft.Data.Edm, Microsoft.Data.OData and System.Spatial.
My solution was to remove the deprecated binding redirects. You should also remove the old dll's sitting in your bin folder if your build process doesn't.

One thing that sometimes seems to resolve this issue for members of my team is to close all instances of Visual Studio, delete the contents of the packages directory, re-open Visual Studio, and then restore packages and rebuild. This doesn't always work though.
We were able to trace the issue on one of our machines by identifying the problematic project by increasing the Visual Studio build output verbosity:
Then, we searched the output and identified the target project that was problematic by searching for "Microsoft.Data.Edm". We noticed that it seemed to have an indirect dependency to Microsoft.Data.Edm, but we noticed that the assembly was not explicitly included as a package for that project. So, using the Nuget package console, we targeted the project and ran:
Install-Package Microsoft.Data.Edm
which resolved the issue.

Here's few things you can try:
Check your Post Build event to make sure no Microsoft.Data.Edm.dll file is being copied manually to bin folder.
Make sure other packages don't have dependency to Microsoft.Data.Edm 5.6.1. Easy way to do this is by looking at your package.config files.
If your code is in source control, make sure nobody check in bin folder. I am surprised by how many people don't know this basic rule.
Uninstall WindowsAzure.Storage and Microsoft.Data.Edm packages. Then install again and make sure you only install the stable version.
HTH.

I met a similar case today, in my situation, the build always copy a old version dll to debug folder, the reason is my project isn't reference this dll directly, it ref another project which refering this dll.
So when build, my project find a old version from GAC or other place.
I solved it by explicit reference this dll in project from the right location.
like this:
<Reference Include="Microsoft.Data.Services.Client, Version=5.6.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL">
<SpecificVersion>False</SpecificVersion>
<HintPath>..\packages\Microsoft.Data.Services.Client.5.6.1\lib\net40\Microsoft.Data.Services.Client.dll</HintPath>
</Reference>

I've just had this same issue on my build server and on checking the build output I noticed the following:
Copying file from "C:\Program Files (x86)\Microsoft WCF Data
Services\5.6\bin.NETFramework\Microsoft.Data.Edm.dll" to
"bin\Microsoft.Data.Edm.dll".
Seems that there is something installed on the build server that is not on my machine, so I need to track that down.

It's probably may be problem of virtual path on IIS (I think, this assembly loaded first on application start).
I got same problem when start two project from different locations on disk but with same virtual paths.
Resolution is delete this path from IIS, reset IIS process and create virtual path again from VS.

found it !!
inside your app.config file change the bindingredirect version. Make bindingredirect element refer to the version the exception complains about, and the exception will go away.
explanation:
Probably the app.config file and the project reference assembly got out of sync, causing the error.
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Microsoft.Data.Edm" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-5.6.4.0" newVersion="5.6.4.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>

I got this error after I had deleted my "packages" folder and re-installed the packages. I was being able to resolve the error by running "Clean Solution" and "Rebuild Solution".

For me I had to uninstall WindowsAzure.MobileServices.Backend.Entity NuGet package which removes a lot of assemblies, including Microsoft.Data.Edm. And then I just re-installed it and miraculously, it worked!
This was in my Azure Mobile Services WebApi project, so it needed to work, and thankfully it does now.
I hope this helps.

This was successfully solved for me by closing and re-opening Visual Studio.

1) Turn Build Verbosity to Detailed
2) Search for Microsoft.Data.Edm and compare the versions of other assemblies used in the project
3) Update to the Version used in other assemblies
Solved my problem

Add-BindingRedirect not resolving NuGet vs issue

So I am having a problem like I see other posters have had after using NuGet to install FluentNhibernate:
ERROR
Could not load file or assembly 'NHibernate, Version=3.0.0.2001, Culture=neutral,
PublicKeyToken=aa95f207798dfdb4' or one of its dependencies. The located assembly's
manifest definition does not match the assembly reference. (Exception from HRESULT:
0x80131040)
I saw that on stackOverflow answers and other blogs the answer was:
Add-BindingRedirect
However, this has not resolved my issue and all the results of running that command is:
PM> Add-BindingRedirect
Name OldVersion NewVersion
---- ---------- ----------
NHibernate 0.0.0.0-3.0.0.4000 3.0.0.4000
When I am installing Fluent Nhibernate from NuGet, it says its dependencies are Nhibernate 3.0.0.2001 but it installs Nhibernate 3.0.0.4000
What am I doing wrong?
UPDATE
I see that it adds the following section in the node:
<dependentAssembly>
<assemblyIdentity name="NHibernate" publicKeyToken="aa95f207798dfdb4" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-3.0.0.4000" newVersion="3.0.0.4000" />
</dependentAssembly>
However, I still get the same error. Which just doesn't look right. If Fluent is wanting 3.0.0.2001 and NHibernate 3.0.0.4000 was installed, this binding redirect, doesn't appear to me to be correct.
To be as specific as possible. I just used NuGet to install Fluent Nhibernate in both my Web Project and a C# library project for tests. Then ran a test using NUnit which continues to give me this error.

Add-BindingRedirect is the correct command to run, and the output you get is what's expected. After you run it, you should see some binding redirect entries in your web.config (or app.config). Can you confirm that?
That will then allow the assembly to be loaded even though FluentNH asks for an older build of NHibernate.
If that doesn't work for you, please include more details in your question about what you are doing. e.g. what is the complete sequence of steps that leads to seeing the error you report (starting with project creation).

I had the same problem with a different package running MSpec tests.
The solution for me was to manually add an app.config file to each web project with the same binding redirects as in the Web.config file.
The Add-BindingRedirect command had added the entries to the Web.config files correctly, but apparently the test runner evaluates only the generated Bla.Bla.dll.config file.

sounds stupid but check in your source files and your packages sources and check there's no references to the old version there - if there is remove all version and re download the version you want via package manager console.
Edit: make sure you check all files because of how the referencing and binding works it can get very muddled and a reference in any of your files could cause the binding to redirect or still be getting the wrong version.

I had the same problem, my webservice was running but the BindingRedirect was not working for my tests.
The solution was to copy the configuration added by the Add-BindingRedirect command from my 'project'.config file to the machine.config file of the computer
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="NHibernate" publicKeyToken="aa95f207798dfdb4" culture="neutral" />
<bindingRedirect newVersion="3.3.1.4000" oldVersion="0.0.0.0-3.3.1.4000" />
</dependentAssembly>
</assemblyBinding>
</runtime>
Once I copied that my tests started working