I recently installed CsvHelper (https://joshclose.github.io/CsvHelper/) when i try to use the library I get the following error:
Could not load file or assembly 'System.Threading.Tasks.Extensions, Version=4.2.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
In my app.config I have binding redirect:
<dependentAssembly>
<assemblyIdentity name="System.Threading.Tasks.Extensions" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-4.2.0.1" newVersion="4.2.0.1" />
</dependentAssembly>
Also in my project I have reference to
\packages\System.Threading.Tasks.Extensions.4.5.3\lib\netstandard2.0\System.Threading.Tasks.Extensions.dll
Its version is 4.2.0.1 I am not sure why its still trying to load 4.2.0.0 of the library.
my project is running .net 4.7.2
I had the same problem today in a multi project solution, System.Threading.Tasks.Extensions got installed by embedding the Autofac package. After removing and reinstalling Autofac (via nuget) in both projects, the two packages.config contained the same entry
<package id="System.Threading.Tasks.Extensions" version="4.5.4" targetFramework="net472" />
but while one project referenced the correct dll in
packages\System.Threading.Tasks.Extensions.4.5.4\lib
the other one referenced the older version in
packages\System.Threading.Tasks.Extensions.4.5.2\lib
After manually removing the older dll from the references (not via nuget) and embedding the correct one, everything worked again. I don't see why the correct packages.config entry did not enforce the correct reference.
EDIT:
If it works on your dev machine but not on the machine you deployed to, don't forget to deploy the binding redirects in web.config / app.config. In my case they look like so:
<dependentAssembly>
<assemblyIdentity name="System.Threading.Tasks.Extensions" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-4.2.0.1" newVersion="4.2.0.1" />
</dependentAssembly>
I had this problem in a multi-project solution when upgrading .net version. In my case running Update-Package -reinstall command in Package Manager Console solved the problem.
According to https://github.com/JoshClose/CsvHelper/issues/1462 this seems to be a bug in one of the CSVHelper 15.0.0 dependencies. The 15.0.0 version (not sure about earlier ones) brings in some other assembly which causes the problem.
Personally I worked around this by downgrading to 13.0 (a comment also noted that 12.3.2 worked), but that bug report now states that they have released 15.0.1 specifically to fix this. I've yet to confirm that myself.
So i created a new .NET 472 project then added all the libs etc and code and now it works.
I suspect it originally broke because I had installed a really old version of csvhelper lib with excel plugin. Even though i removed it and removed all references it was still picking it up from somewhere.
I had this problem today in a multi-project solution. Fixed it by updating other NuGet packages in the offending project. Unfortunately, not sure which one fixed the problem.
Current version of CsvHelper: 15.0.5.
<assemblyBinding>
<probing privatePath="System.Threading.Tasks.Extensions.dll"/>
</assemblyBinding>
<assemblyBinding>
<probing privatePath="System.Runtime.CompilerServices.Unsafe.dll"/>
</assemblyBinding>
<assemblyBinding>
<probing privatePath="Microsoft.Bcl.AsyncInterfaces.dll"/>
</assemblyBinding>
This answer assumes that you are using PackageReference for your nuget references. If that's the case, there is also a known bug in PackageReference .Net tooling model. For some weird cases, the nuget restore msbuild tool chain places ref assemblies, when it should have ideally placed the lib assemblies. How can you find out if you are facing a similar problem? You can use a standard reflector application like ILSpy to read the failing library's metadata in your working directory. If you see RefAssemblies attribute in its metadata, then you are also encountering this problem.
To fix this problem, you can use something like the following tag in your csproj file to fix the nuget copying issue.
<Target Name="ReplaceRefWithLib" BeforeTargets="ResolveAssemblyReferences">
<ItemGroup>
<_noCopyRefs Include="#(Reference)" Condition="'%(Reference.Private)' == 'false'" />
<_noCopyRefsByFileName Include="#(_noCopyRefs->'%(FileName)')">
<OriginalItem>%(Identity)</OriginalItem>
</_noCopyRefsByFileName>
<_libByFileName Include="#(ReferenceCopyLocalPaths->'%(FileName)')">
<OriginalItem>%(Identity)</OriginalItem>
</_libByFileName>
<_overlappingRefByFileName Include="#(_noCopyRefsByFileName)" Condition="'#(_noCopyRefsByFileName)' == '#(_libByFileName)' AND '%(Identity)' != ''" />
<_overlappingLibByFileName Include="#(_libByFileName)" Condition="'#(_noCopyRefsByFileName)' == '#(_libByFileName)' AND '%(Identity)' != ''" />
<_overlappingRef Include="#(_overlappingRefByFileName->'%(OriginalItem)')" />
<_overlappingLib Include="#(_overlappingLibByFileName->'%(OriginalItem)')" />
</ItemGroup>
<ItemGroup Condition="'#(_overlappingRef)' != ''">
<Reference Remove="#(_overlappingRef)" />
<Reference Include="#(_overlappingLib)">
<Private>false</Private>
</Reference>
</ItemGroup>
</Target>
Hoping this helps.
In my case I had a different version of System.Threading.Tasks.Extensions in my unit testing project than in my main project so after I upgraded my unit testing project to match the version it worked for me.
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.
I am having problems running my web application.
The project setup is ASP.NET Core web application (.NET Framework). I don't seem to get any Build error. The project doesn't just run.
System.IO.FileLoadException: 'Could not load file or assembly 'Microsoft.Win32.Primitives, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)'
Try adding the System.Net.Http nuget package.
This happened to me after I had updated to Visual Studio 2017 15.4.5 and also updated a load of Nuget packages. I think part of the problem is also using .net framework 4.7.1 as well, which I installed last week...
The fix for me was to remove the dependent assembly from web.config, so just comment out or delete this section:
<dependentAssembly>
<assemblyIdentity name="Microsoft.Win32.Primitives" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-4.0.1.0" newVersion="4.0.1.0" />
</dependentAssembly>
In other for me to get it working i uninstalled the Microsoft.Win32.Primitives then installed the exact version which is 4.0. this worked fir me.
Note that there are higher versions but they did not work for me.
I accidently deleted my *.suo files and the problem fixed itself. Maybe it was an accident, or irrelevant but i just thought to share it.
If you are targeting .Net 4.7.1 project, I contend that a 4.7.1 versioned Primitives DLL is not available. Take a look at the properties in Nuget
I believe the Nuget expression would need a > not a = 4.6.
This feels like a hack, but it seemed to work. If you open Web.config, change this to 4.6
I am facing the error below
Could not load file or assembly 'Newtonsoft.Json, Version=7.0.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)
I could see the below in Web.config
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json" culture="neutral" publicKeyToken="30ad4fe6b2a6aeed" />
<bindingRedirect oldVersion="0.0.0.0-7.0.0.0" newVersion="7.0.0.0" />
</dependentAssembly>
So I changed it to
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json" culture="neutral" publicKeyToken="30ad4fe6b2a6aeed" />
<bindingRedirect oldVersion="0.0.0.0-7.0.0.0" newVersion="7.0.1.0" />
</dependentAssembly>
In packeges.config I could see the below entry
But still I am facing the same issue. Please help
A lot of things can go wrong and this error message tells you nothing.
But still I am facing the same issue.
Maybe the easiest way will be to try and reinstall the package.
Go to TOOLS > NuGet Package Manager and Select Package Manager Console. Execute the following two commands:
uninstall-package newtonsoft.json -force
install-package newtonsoft.json
If you still get an error after doing this, then what worked for me eventually is that I deleted Json.Net's 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. In package manager console again execute:
Update-Package –reinstall Newtonsoft.Json
Also take a look at your .Net version of the projects in your solution.
This is the Microsoft solution with unloading the project.
I had the same issue. I followed ekostadinov's forced uninstall/reinstall steps, but needed to add one extra step:
I was upgrading my Solution to Framework 4.5.2. My old Web.Config file had a namespace in the configuration tag.
<configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">
I updated to:
<configuration>
Then the bindingRedirect should work for whatever version of NewtonSoft you are using:
<runtime xmlns="">
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-11.0.0.0" newVersion="11.0.0.0" />
</dependentAssembly>
</assemblyBinding>
This can happen if package.config contains 2 same packages name with a different version.
For Example,
<package id="System.Spatial" version="5.6.2" targetFramework="net45" />
<package id="System.Spatial" version="5.6.4" targetFramework="net45" />
Thank You.
I had the same issue and doing the uninstall and reinstall didn't help. At the time I was trying to install the most current version (10.0.3) of Newtonsoft.Json. I ended up installing the 7.0.1 version and then ran across another article that suggested copying that .dll to :\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE. Which I did.
Started the install REST API process again and then received a different error. When attempting to install Microsoft.Rest.ClientRuntime 2.3.2 it failed. For this, I just went into NuGet and had it install to the project in which I was installed the REST API.
Started the REST API install again and this time it installed.
Oh and if it helps anyone with searches, I was doing the Azure Immersion 02-API App tutorial using VS2015 on Windows Server 2012R2.
I had the same issue and I got the exception when I was trying to create MassTransit queues:
"Exception: System.TypeInitializationException: The type initializer for 'MassTransit.Serialization.JsonMessageSerializer' threw an exception. ---> System.IO.FileLoadException: Could not load file or assembly 'Newtonsoft.Json, Version=12.0.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)"
Solution that worked for me (after spending couple of days reverting several commits):
We had a windows service solution that has .Service project and
.XUnitTests project. Both of them were using a common nuget that has
dependency on Newtonsoft.Json.dll. There was no explicit reference to
Newtonsoft.Json nuget package in both projects (but we were using
'using Newtonsoft.Json;' namespace in our classes), so the common
nuget was using version 9 of Newtonsoft.Json by default.
As soon as I installed the Newtonsoft.Json nuget in both .Service and
.XUnitTests projects, the common nuget package started using the
latest v12 Newtonsoft and that fixed my issue.
Just posting it in here if it saves anyone their valuable time.
most of the time this error happens because of different assemblies are dependent on specific version of some other assembly.
the easiest fix is to update all packages that are dependent to Newtonsoft.Json using the nuget package manager.
it will automatically set all config files in your project.
I got the same error, and fixed it by doing a 'Clean' on my solution. I'm using Newtonsoft.Json in a UWP app.
Thanks #ekostadinov. I was able to get it working with the solution from #ekostadinov. In my case, the default Web MVC template had NewtonSoft JSON version 6. I had added a class library and to that I installed NewtonSoft JSON version 9 from Nuget package manager.
I tried removing the reference from my Web project, packages config and dependencies, but still I was getting error. Now, I was getting error message saying unable to find Newtonsoft JSON version 6. Initially I was getting error message saying unable to find Newtonsoft JSON version 9.
Then I followed #ekostadinov steps.
uninstall-package newtonsoft.json -force
install-package newtonsoft.json
I got a warning with respect to a dependency in the package manager console mentioning about a dependency with the version of Web.Grease dll. But anyways, it was successful.
Just to double check, I ran the last command mentioned in the above post
Update-Package –reinstall Newtonsoft.Json
It ran without any warnings as well.
Now, I am able to use version 9 in all my projects.
Well, in my case, there were multiple projects in the solution and each was using different version of NewtonSoft.json. I had to go ahead and change the version in each project's package.config to match with latest version(Well, it could be any version just that it should be same across the projects). Once all the package.config point to the same version, all I had to do was
Update-Package –reinstall Newtonsoft.Json
Now, watch out I also had to manually change the version on web.config assembly entry in one of the projects. but that did the job.
My be it is too late but hopefully, it might be useful for the people supporting old projects.
Add dependentAssembly tag and give the version number in oldVersion for which you are getting error.
In my case it was giving the error for version 6.0.0
Give the installed version value in newVersion as mentioned below:
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json" culture="neutral" publicKeyToken="30ad4fe6b2a6aeed" />
<bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="10.0.0.0" />
</dependentAssembly>