There are two projects in solution.One is API and other is for OrganizationServiceCall.
I have installed one nuget package called Microsoft.CrmSdk.XrmTooling.CoreAssembly it has installed default package Microsoft.IdentityModel.Clients.ActiveDirectory, Version=3.19.8.1660 with it.
But I have installed Microsoft.IdentityModel.Clients.ActiveDirectory, Version=2.22 in other project.While Call API I got this error :
{"Could not load file or assembly 'Microsoft.IdentityModel.Clients.ActiveDirectory, Version=3.19.8.16603"}.
How can i done work while same Solution have different version of nuget pacakge conflicts?
Some work arounds that you can try
If second project api has no issue with latest version ,Also try Upgrading it to Microsoft.IdentityModel.Clients.ActiveDirectory version 3.19.8
Or Update all NuGet packages to the latest if its ok.
Or one may need to edit your csproj manually to add that specific version in thart particular project.
Use a single assembly version with Binding Redirect in config file
i) NuGet won't handle the references in the program. It just
manages packages. We may have to force our project to use the
loaded assembly with binding redirect.
ii) This specifies which version of assembly to use instead of old
version. It is not necessarily requires later version be specified
in newVersion, earlier version can be provided as well in
newVersion. If there are different versions, try make them uniform
across projects. Issue should be solved.
Here oneproject is referred to ActiveDirectory versions > 3.0, other
project needs less version that that. Adding a binding redirect to
the app.config can help fix problem in some cases. But before that
please make sure that particular dlls are present in the
configuration file.
Note that the runtime section is the one to be added.
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<startup>
...
<runtime>
....
<dependentAssembly>
<assemblyIdentity
name="Microsoft.IdentityModel.Clients.ActiveDirectory" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="3.0.0.0-3.19.8.16603" newVersion="3.19.8.16603" />
</dependentAssembly>
.....
</runtime>
</configuration>
And try to explicitly set Specific Version for whatever DLL giving you version issues(Microsoft.IdentityModel.Clients.ActiveDirectory) to False from Visual Studio.
Other way, you can try is to auto-generate binding redirects.
<AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
<GenerateBindingRedirectsOutputType>true</GenerateBindingRedirectsOutputType>
References:
azure-sdk-for-media-services :issues(github)
How to resolve “Could not load file or assembly | by Chirag
Rupani | Medium
Troubleshooting NuGet Package Restore in Visual Studio | Microsoft
Docs
A client or ours is asking us to look at his application to fix a few bugs but his application references Telerik.Web.UI. I downloaded a trial version of Telerik on my machine hoping that that would work but I get the error: Could not load file or assembly 'Telerik.Web.UI, Version=2014.3.1024.35, Culture=neutral, PublicKeyToken=121fae78165ba3d4' or one of its dependencies
When I look at my version it's version 2015.1.225.40. How does one solve these types of situations, especially when you just want to help a client? I tried to do some binding redirect:
<runtime>
<dependentAssembly xmlns="urn:schemas-microsoft-com:asm.v1">
<assemblyIdentity name="Telerik.Web.UI" publicKeyToken="121fae78165ba3d4" culture="neutral"/>
<bindingRedirect oldVersion="2014.3.1024.35" newVersion="2015.1.225.40"/>
</dependentAssembly>
But that didn't work. Still get the same error.
Open a ticket with Telerik and ask for access to the version you need.
That aside, a bindingRedirect should usually work, but you should target the .NET 3.5 build (2015.1.225.35) you can get from the bin35 folder in the installation.
It turned out to be that the .aspx pages had a directive at the top that referenced the Telerik.Web.UI, including the version number. After I installed the trial version, and referencing it (even though it's a newer version), all I really had to do is rem out the directive at the top of the .aspx pages and the app was able to reference the assembly and the application worked. Hope this helps anyone that might go through the same path.
I am getting the Error
System.IO.FileLoadException : Could not load file or assembly
'Newtonsoft.Json, Version=4.5.0.0, Culture=neutral,
PublicKeyToken=30ad4fe6b2a6aeed' or one of its dependencies. The
located assembly's manifest definition does not match the assembly
reference. (Exception from HRESULT: 0x80131040)
for my CI build
Solution which I tried
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed"
culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="6.0.0.0" />
</dependentAssembly>
It also did not work
In package manager console execute: Update-Package –reinstall Newtonsoft.Json.
UPDATE
I originally posted this as a comment but as #OwenBlacker suggested I'll just put it here:
If you still get an error after doing this, then what worked for me eventually is that I deleted Json.Net's <dependentAssembly> section from my .config file. Reinstall brings it back if it's not there and apparently you need to delete it. Until there will be a normal solution in the package itself, I'm afraid this manual step is a must.
Note: Please read the comments below before doing this.
As per René's comment below BE AWARE that the command posted in the answer will reinstall the package in every project in your solution. So if you use the Newtonsoft.Json package in several projects and maybe use different versions, just executing the above command might have unwanted consequences.
To everyone having problems with Newtonsoft.Json v4.5 version try using this in web.config or app.config:
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json"
publicKeyToken="30AD4FE6B2A6AEED" culture="neutral"/>
<bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="6.0.0.0"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
IMPORTANT: Check that the configuration tag of your config file has no namespace attribute (as suggested in https://stackoverflow.com/a/12011221/150370). Otherwise, assemblyBinding tags will be ignored.
The key point is referencing right version in your config file.
Steps;
1- look at what is the version of your Newtonsoft.Json.dll in the project reference property what ever the version in your package folder (For example mine is 7.0.1 and the reference Version is 7.0.0.0)
2- look at what the project expect from you in the exception (mine is 6.0.0.0)
3- Add dependent assembly to your config file as it should be..
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30AD4FE6B2A6AEED" culture="neutral"/>
<bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="7.0.0.0"/>
</dependentAssembly>
I had no luck with any of the solutions presented here (uninstalling, reinstalling, deleting references, creating bindingRedirects etc.) I had to go back to an old version of Newtonsoft. Version 5.0.6 had been working before, so I tried that one. I had to enter these two commands in the Package Console:
uninstall-package newtonsoft.json -force
install-package newtonsoft.json -version "5.0.6"
The -force option in the first command is required to force the uninstall. Dependencies with other assemblies prevent the uninstall without it.
I fixed the problem adding this binding redirect to my .config file:
<runtime>
. . .
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed"
culture="neutral" />
<bindingRedirect oldVersion="4.5.0.0" newVersion="6.0.0.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>
The error message complains about not finding version 4.5.0.0, the current version of Newtonsoft.Json is 6.0.0.0 so the redirect should go from 4.5 to 6.0, not viceversa
I think you are pointing to the wrong target, change it to 4.5 instead of 6.0
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed"
culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="4.5.0.0" />
</dependentAssembly>
This should work.
I've spend couple of days trying to resolve this frustrating issue. I've tried pretty much everything that can be found on the web. Finally I found that this error could be caused (like in my case) by the different target .Net project versions (4.5 and 4.5.1) in one solution. The steps bellow fixed it for me:
Double check the .Net version of every project that's in your solution. Just right click on project and go to Properties.
If possible set the same .Net version for all projects. If not at least try to change the Startup project one (for me this was the one causing the issues).
Remove all Newtonsoft.Json packs from the solution.
uninstall-package newtonsoft.json -force
Update all Newtonsoft.Json versions in all packages.config files, like so
<package id="Newtonsoft.Json" version="7.0.1" targetFramework="net451" />
Reinstall Newtonsoft.Json from "Package Manager Console" with:
install-package newtonsoft.json
Rebuild the solution
(Optional) 7. If you changed the Startup project, return it again
uninstall-package newtonsoft.json -force
install-package newtonsoft.json
Did the trick for me :)
if you using multiple project in same solution
and library of the one other
check is all projects has same version of Newtonsoft.Json
Remove the Newtonsoft.Json assembly from the project reference and add it again. You probably deleted or replaced the dll by accident.
I was writing a WebApi REST service client, so for me this error was caused by adding References to the System.Net.Http and System.Net.Http.Formatting assemblies manually via Add Reference, when I should have added the Microsoft.AspNet.WebApi.Client package via NuGet.
See also this answer to another question.
You have 2 different versions of JSON.NET library in your solution. To solve this you should upgrade them to latest version. Follow these steps:
1-Open solution explorer
2-Right Click on solution name
3-Select Manage Nuget Packages for Solution
4-Select Updates from menu
5-Update JSON.NET package
This will resolve your issue.
link:
Could not load file or assembly 'Newtonsoft.Json, Version=7.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed' or one of its dependencies
Deploy the correct version to the CI machine
This is telling you that the assembly loader found a different version of the Newtonsoft.Json assembly, that does not match the reference you created in your project. To load the assembly correctly, you must either deploy the assembly side by side with your compiled code, or install the correct version of the assembly in the destination machine (i.e. in the GAC).
Alternative: make sure the configuration is in the correct file
If you want to keep the current solution, and load an assembly with a different version, make sure that the configuration you posted is in the correct .config file. Remember that there is no xpto.dll.config, a DLL loaded by an application always uses the config file of the running application.
Normally adding the binding redirect should solve this problem, but it was not working for me. After a few hours of banging my head against the wall, I realized that there was an xmlns attribute causing problems in my web.config. After removing the xmlns attribute from the configuration node in Web.config, the binding redirects worked as expected.
http://www.davepaquette.com/archive/2014/10/02/could-not-load-file-or-assembly-newtonsoft-json-version4-5-0-0.aspx
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json"
publicKeyToken="30AD4FE6B2A6AEED" culture="neutral"/>
<bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="7.0.0.0"/>
</dependentAssembly>
</assemblyBinding>
Works for me.... just put the version you are using in newVersion i.e(newVersion="7.0.0.0")
I was getting same error and by adding below code error resolved on production.
Answer is too late but might help someone.
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-12.0.0.0" newVersion="12.0.0.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>
Close solution.
Open packages.config and *.csproj with text editor and delete any line have Newtonsoft.Json
Ex:
<Reference Include="Newtonsoft.Json,Version=9.0.0.0,Culture=neutral,PublicKeyToken=30ad4fe6b2a6aeed, processorArchitecture=MSIL">
<HintPath>..\packages\Newtonsoft.Json.9.0.1\lib\net40\Newtonsoft.Json.dll</HintPath>
<Private>True</Private>
</Reference>
Or
<package id="Newtonsoft.Json" version="9.0.1" targetFramework="net40" />
Open solution again and re-install Newtonsoft.Json by Install-Package Newtonsoft.Json
It work for me.
We had the exact same issue that you mentioned. We're using nunit to run tests through CI, and we have nunit running a file called tests.nunit, which describe a list of test dll fixtures to run.
Each test fixture had their own config file, but when run through the "tests.nunit" file the binding redirects seem to be ignored. The solution was to add the binding redirects to a new config file, "tests.config" that was beside the "tests.nunit" file.
I have got the same type of problem. And I also solved it just doing the following:
Go to TOOLS > NuGet Package Manager and Select Package Manager Console. Finally, execute the following two commands :)
uninstall-package newtonsoft.json -force
install-package newtonsoft.json
You should update the web.config file in the server.
When nuget install NewtonSoft update this file including this code
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="6.0.0.0" />
</dependentAssembly>
</assemblyBinding>
Just check the version of Newtonsoft.Json Newtonsoft properties
Then you need to add that version in your web config (in my case 8.0.0.0)
Web config
I made the mistake of adding a NewtonSoft .dll file for .Net 4.5.
My main project was 4.5, but when I added an extra project to my solution, it strangely added it as a .Net 2.0 project... and when I attempted to use NewtonSoft's 4.5 dll with this, I got this "Newtonsoft.Json couldn't be found" error.
The solution (of course) was to change this new project from .Net 2.0 to 4.5.
I was facing the same error and struggled with it for hours. I had a web API project which is using Newtonsoft.json and another UnitTest project for the web API project. The unit test project also needed the Newtonsoft.json reference. But on adding the link I was getting the above exception.
I finally resolved it by adding the below code snippet in the app.config of the unit test project:
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30AD4FE6B2A6AEED" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="6.0.0.0" />
</dependentAssembly>
In my case, the main project was still referencing an old version of Newtonsoft.Json which didn't exists in the project any more (shown by a yellow exclamation mark). Removing the reference solved the problem, no bindingRedirect was necessary.
I had the exact same problem with version 7.0.0.0, and the lib causing my problem was Microsoft.Rest.ClientRuntime which somehow was referring to the wrong version (6.0.0.0) of Newtonsoft.json, despite the right dependency management in nugget (the right version of newtonsoft.json (7.0.0.0) was installed).
I solved this by applying the redirection above from 6.0.0.0 to 7.0.0.0 (from Kadir Can) in the config file:
<bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="7.0.0.0" />
----> After a few days without changing anything it came up again with the same error. I installed version 6.0.0.0 n updated it to 7.0.0.0 it works fine now.
Reinstall newtonsoft package through nuget did not worked for me.
I had to manually call JsonConvert.DeserializeObject to bypass this issue
I changed
HttpResponseMessage response = await client.GetAsync(url));
response.EnsureSuccessStatusCode();
MyObject data = await response.Content.ReadAsAsync<MyObject>();
For
HttpResponseMessage response = await client.GetAsync(url));
response.EnsureSuccessStatusCode();
string jsonStr = await response.Content.ReadAsStringAsync();
MyObject data = JsonConvert.DeserializeObject<MyObject>(jsonStr);
In my case, after downloading the assembly and adding the reference to the project, I solved this by 'unblocking' the DLL before adding the reference to the project.
Using Windows explorer, browse to the DLL location, right-click on the DLL and then select 'properties'. You'll find an 'unblock' button on one of the tabs and then you can add the reference and the assembly will load correctly.
Nothing from above helped me, but what actually fixed it is the following:
Remove all dependency bindings in app.config (from all app.config files in the solution)
Execute the following command from "Package Manager Console"
Get-Project -All | Add-BindingRedirect
Rebuild
Reference:
http://blog.myget.org/post/2014/11/27/Could-not-load-file-or-assembly-NuGet-Assembly-Redirects.aspx
Right click your project select manage Nuget packages, type newtonsoft in the search box and install the latest version. Then Run your App
Another insidious problem is that it appears that binding redirects can just silently fail if the element has an incorrect configuration on any other dependentAssembly elements.
Ensure that you only have one element under each element.
In some instances, VS generates this:
<dependentAssembly>
<assemblyIdentity ...
<assemblyIdentity ...
</dependentAssembly>
Instead of
<dependentAssembly>
<assemblyIdentity ...
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity ...
</dependentAssembly>
Took me a long time to realise this was the problem!
I have a bit of a weird problem.
I developed an app with MVC 4 and the new Web API and it works fine locally.
I installed MVC4 on the server and deployed the app. Now I get the following error:
Could not load file or assembly 'System.Net.Http, Version=2.0.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)
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in
Funny enough, the version of System.Net.Http that I locally have either in my package folder or in the ASP.NET MVC 4\Assemblies folder is 1.0.0.0.
I actually removed the reference to System.Net.Http from my project, but I still get the same message. I'm a bit confused about where it gets the 2.0.0.0 reference from and why it would work locally but not on the server.
Looking at the nuget dependencies:
ASP.NET WEb API Core Libraries (Beta) depends on System.Net.Http.Formatting.
And System.Net.Http.Formatting depends on System.Net.Http.
I guess that is where this comes from. But I do have Version 2.0.20126.16343 of this package installed, it's just that the dll inside has version 1.0.0.0
Am I missing something?
UPDATE:
This is a sub-application of another ASP.NET app, but the other one is still based on WebForms. So, something is getting messed up. But if I do a clean under the assembly section in the web.config if does not even find the app itself anymore.
I had the same error while deploying previously converted (from .NET 4.5 to 4.0) web app on IIS 6.0.
In the web.config runtime section I've found
<dependentAssembly>
<assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
<bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="4.0.0.0"/>
</dependentAssembly>
which I've changed to
<dependentAssembly>
<assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
<bindingRedirect oldVersion="0.0.0.0-1.0.0.0" newVersion="2.0.0.0"/>
</dependentAssembly>
Now works like charm.
I had the same problem with deployment my app to appharbor. The problem it does not support .NET 4.5 yet. What I did.
Switched my project to .NET 4.0 profile.
Uninstalled Web API NuGet package.
Installed Web API (Beta) NuGet package again.
Verified that .csproj file contains for ALL referenced assemblies, so it will always take it from Bin folder, instead of GAC.
Mine worked with:
Note the redirect of 1-4 to 2.0
<dependentAssembly>
<assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
<bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="2.0.0.0"/>
</dependentAssembly>
In your project's References folder there should be a reference to this dll, and the version should be 2.0.0.0. Make sure this is set to Copy Local = true. And then make sure it finds its way to your server app's bin folder.
This is one of the libraries that is now managed by nuget. So open Nuget and make sure everything is up to date. And in your projects packages directory the file should be here:
\packages\System.Net.Http.2.0.20126.16343\lib\net40
You could also try creating a new MVC4 app and see if the file shows up for that one.
In my case I fixed it in a much easier way, just give a HintPath to the reference to the nuget package:
<Reference Include="System.Data.Entity" />
<Reference Include="System.Net.Http, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">
<Private>True</Private>
+ <HintPath>..\..\packages\Microsoft.Net.Http.2.0.20710.0\lib\net40\System.Net.Http.dll</HintPath>
</Reference>
<Reference Include="System.Net.Http.WebRequest, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">
<Private>True</Private>
+ <HintPath>..\..\packages\Microsoft.Net.Http.2.0.20710.0\lib\net40\System.Net.Http.WebRequest.dll</HintPath>
</Reference>
<Reference Include="System.Numerics" />
<Reference Include="System.Security" />
In my case I unintentionally added a dependency to System.Net.Http version 2.1.10.0 through NuGet. I couldn’t get rid of it in the NuGet Package Manager (because other packages seemed to be dependent on it). However those packages aren’t dependent on this particular version.
Here's what I did in order to get rid of it (you can also use the NuGet console instead (using the –force parameter):
Change version of Microsoft.Net.Http in packages.config from 2.1.10.0 to 2.0.0.0
Uninstall BCL Portability Pack in NuGet Package Manager
Manually get rid of dependent libraries (System.Net.Http.* which have version 2.1.10.0)
Add a reference to System.Net.Http 2.0.0.0
In file config I deleted dependent Assembly:
<dependentAssembly>
<assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
<bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="2.0.0.0"/>
<dependentAssembly>
Now it works fine.
I was facing this issue on a test server (Windows 2008 R2) which was supposedly "ready" for deployment ;)
The hint was that when I checked the versions of System.net between my DEV machine and deployment server, they did not match.
Fixed using the steps below:
Downloaded .NET Framework 4.5 Standalone installer from HERE
Ran the installer on the deployment machine
Post installation of the framework, server wanted a reboot, so did that and volla! We are good to go!!
We are using VS 2013, created a new MVC 4 Web API and had a problem with the system.net.http.dll not being the correct version when built on our TeamCity server but it builds fine on our local developer machines that have VS 2013 installed.
We finally determined the problem.
When creating a new MVC 4 Web API and choosing the framework 4.0 on project creation we found the the correct NuGet package version for DLL was being put in:
..\packages\Microsoft.Net.Http.2.0.20710.0\lib\net40\System.Net.Http.dll
However the .csproj file for this project said the path for this system.net.http.dll file is:
..\packages\Microsoft.Net.Http.2.0.30506.0\lib\net40\System.Net.Http.dll
So when the build is attempted is fails on this path difference but is finding the correct framework version of the file elsewhere on the developer machine but not on our TeamCity build server.
So far this is the only difference we found. Changing the path in the .csproj file and building on local Dev machine with VS2013 still works find.
Checking that into version control and having our TeamCity build server (without VS 2013 installed locally) now finds the correct version of the .dll in its NuGet package folder for the solution and builds successfully rather than searching for another version of system.net.http.dll and finding a newer version which doesn't match the framework hence causing build failures.
Not sure if this helps.
Check your project file path for the DLL and make sure it matches your package folder path for the DLL.
Just simplifying the other answers for what worked for me.
I went to the NuGet manager, uninstalled the related packages (In my case, "Microsoft ASP.NET Web API 2.1 Client Libraries" and "Json.NET") and reinstalled them. Just took a few clicks.
Close the project, Open it again. Then, Clean Solution + Build. Works for me
For version 2.2.15.0, I did this:
<dependentAssembly>
<assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
<bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="2.2.15.0"/>
</dependentAssembly>
I had this exact same issue! I took a look at my Warnings tab in VS and noticed that one of my nuget packages was INDIRECTLY referencing .NETFramework Version 4.5.0.0. I had to uninstall this package and then reinstall the 4.0 version but be sure to specify the package versions that support 4.0(it'll default back to 4.5 i believe if you don't specify when installing the package). Hope this helps!
We had this happening on a server after deployment. It was caused either by:
A) Old files in the bin folder still hanging around that ought to have been deleted
or
B) Not having read access to the folder for the Application Pool Identity user.
In other words, for us this was resolved by fixing permissions on the folders for the site and wiping out the bin folder and redeploying.
I had the same issue with Gembox.spreadsheet.dll version 31.
" Could not load file or assembly 'GemBox.Spreadsheet,
Version=39.3.30.1095, Culture=neutral,
PublicKeyToken=b1b72c69714d4847' or one of its dependencies. The
located assembly's manifest definition does not match the assembly
reference. (Exception from HRESULT: 0x80131040) "
I tried almost everything from these articles and none of them worked. It just got fixed with simple step.
I tried building individual projects that basically set up the correct version reference to the dll and the error was entirely gone from the solution.
Go a similar issue and the directive mentionned in many comments worked fine
<dependentAssembly>
<assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
<bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="2.0.0.0"/>
<dependentAssembly>
Although, you have to ensure the old version coverage is high enough otherwise newer versions may not be redirected to the specific version you need and location using that newer reference won't work properly since the older reference is already in the bin directory.
For this error (and similar) it's worth going through NuGet Consolidate (Solution > Manage NuGet Packages...) to ensure the same referenced component versions are consistent in each class library referenced in the solution, since even a slightly older version may have dependencies on other older components. It's straightforward to use in conjunction with Updates and can save a lot of pain.
This solved this issue for me and I would say it's a must to get familiar with if you're creating helper libraries that also reference MVC or other web-based NuGet components.
I have the following situation
Project A
- Uses Castle Windsor v2.2
- Uses Project B via WindsorContainer
Project B
- Uses NHibernate
- Uses Castle Windsor v2.1
In the bin folder of Project A I have the dll Castle.DynamicProxy2.dll v2.2 and NHibernate dlls. Now the problem is that NHibernate is dependent on Castle.DynamicProxy2.dll v2.1 which is not there. How do I resolve this situation.
I used the following configuration to resolve the issue.
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Castle.DynamicProxy2" publicKeyToken="407dd0808d44fbdc" />
<codeBase version="2.1.0.0" href="v2.1\Castle.DynamicProxy2.dll" />
<codeBase version="2.2.0.0" href="v2.2\Castle.DynamicProxy2.dll" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Castle.Core" publicKeyToken="407dd0808d44fbdc" />
<codeBase version="1.1.0.0" href="v2.1\Castle.Core.dll" />
<codeBase version="1.2.0.0" href="v2.2\Castle.Core.dll" />
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
One thing very, very, very important that one might miss if he is not paying enough attention.
The assembly you write in the codeBase version tag, must be strong named.
From the following link: http://msdn.microsoft.com/en-us/library/efs781xb.aspx
For assemblies without a strong name, version is ignored and the
loader uses the first appearance of <codebase> inside
<dependentAssembly>. If there is an entry in the application
configuration file that redirects binding to another assembly, the
redirection will take precedence even if the assembly version doesnt
match the binding request.
One solution (or workaround) would be to install both versions in the Global Assembly Cache (GAC) on the machine(s) on which your software needs to run, and reference the assemblies using their strong names. This assumes that the assemblies do indeed have strong names.
Installing into the GAC will be a pain if you have more than a few developers or if you plan to deploy your solution to many computers (eg as an end-user application). In this case, I believe (but I might be wrong) that your only option is to merge one of the two versions into the assembly requiring that version. In your specific case, you need Castle.DynamicProxy2.dll v2.1 to be merged into NHibernate.dll.
You can use a tool called ILMerge to merge the assemblies. The command you will need to run looks something like this (untested):
ILMerge /t:library /internalize /out:Deploy/NHibernate.dll
NHibernate.dll Castle.DynamicProxy2.dll
The /internalize switch tells ILMerge to mark all types from the second assembly (Castle in this case) internal in the output assembly. Without this, you might get compile errors when you try to compile a project referencing both your new NHibernate.dll and the shelf version of Castle.DynamicProxy2.dll v2.2, as they will contain classes with the exact same names.