I have an ASP.NET web project that has been running for years. Last year we changed one of the data sources to MYSQL so added MySqlConnector from NuGet. Just recently the application started throwing the error "Could not load file or assembly 'System.Diagnostics.DiagnosticSource, Version=6.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference." This error only occurs when we try to connect to MySql using MySqlConnetor. All NuGet packages have been updated and using .NET framework 4.6.1. The assembly binding portion of the webconfig is;
<assemblyIdentity name="System.Diagnostics.DiagnosticSource" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-7.0.0.0" newVersion="7.0.0.0" />
</dependentAssembly>
Similar questions have been ask in this forum and I have tried all suggested solutions, but am still getting the error. This must have been caused by an OS update as the error started occurring on the live server as well as my development machine.
Can anybody help to resolve this.
I have added third party reference (Json newtonsoft) dll in my script component, but when i run the package through sql server agent, I am getting an error
Could not load file or assembly 'Newtonsoft.Json, Version=10.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed' or one of its dependencies. The system cannot find the file specified.
I have registered the dll in gac and same dll (even same version) is also used in uat but while executing on prod it is getting failed.
Any suggestions?
Firstly I would check that the version in the web.config matches the version of the DLL. Right click on the newstonsoft.dll and go to details tab, product version.
You should then have a corresponding assembly identity in your web.config like
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json"
publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-10.0.0.0"
newVersion="10.0.0.0" />
</dependentAssembly>
Also if you have multiple projects in your solution then right click your solution, manage nuget packages for solution and go to the consolidate tab to check that you don't have multiple versions of newtonsoft
Finally resolved the issue-
The command to register DLL was having space before the DLL name. While registering through cmd it showed registering success however the folder was not created in gac_msil location I. E. dll was not registered.
My ASP.Net MVC Application works fine when run locally on IIS, but gives the following error when deployed to Azure:
Could not load file or assembly 'Microsoft.Owin, Version=2.1.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)
This is the piece of the stack trace that led me to believe that SignalR is a potential culprit:
[FileLoadException: Could not load file or assembly 'Microsoft.Owin, Version=2.1.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)]
Owin.OwinExtensions.MapSignalR(IAppBuilder builder, String path, HubConfiguration configuration) +0
Owin.OwinExtensions.MapSignalR(IAppBuilder builder, HubConfiguration configuration) +12
QuikWorx.O365Web.Startup.Configuration(IAppBuilder app) +169
According to NuGet, I have version 3.0.1 of Microsoft.Owin installed on the application, but apparently something (SignalR) requires version 2.1.0. I would have thought that the following bindingRedirect would force SignalR to use the installed version 3.0.1 (verified present, version 3.0.1 in /bin on Azure):
<dependentAssembly>
<assemblyIdentity name="Microsoft.Owin" publicKeyToken="31bf3856ad364e35" />
<bindingRedirect oldVersion="0.0.0.0-3.0.1.0" newVersion="3.0.1.0" />
</dependentAssembly>
...but alas, this is not the case.
I've also tried the following without success:
Forced reinstall of Microsoft.Owin 3.0.1 with NuGet.
Forced reinstall of the SignalR component (Microsoft.AspNet.SignalR.Core) that requires Microsoft.Owin 2.1.0 with NuGet
Changing the oldVersion of the bindingRedirect for Microsoft.Owin to "0.0.0.0-2.1.0.0" (this makes no sense)
Removing the bindingRedirect for Microsoft.Owin
Deleting all files and folders in the site directory using rd /Q /S in Kudu
Is there anything else that I could attempt?
Would love to get to the root cause of the issue, as in why it works locally, but not in Azure, but based on this answer you should probably try to install Microsoft OWIN itself - via NuGet, directly to the project that's failing.
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.
This exception is not showing when debugging locally and shows up only when i browse to the remote url address of the server..
I have FTP'd the MVC 3 app to my remote server and a check of the Bin folder there shows that I have all three MySQL reference assemblies. All are version 6.4.4.0.
In my web.config file all of the version numbers relating to those are set to version 6.4.4.0.
Why am I getting this error message about version 6.3.6.0, and how can this be solved?
Could not load file or assembly 'MySql.Data, Version=6.3.6.0,culture=neutral, PublicKeyToken=c5687fc88969c44d' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
Exception Details: System.IO.FileLoadException: Could not load file or assembly 'MySql.Data, Version=6.3.6.0, Culture=neutral, PublicKeyToken=c5687fc88969c44d' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
There are a lot of things to check with this, but the most common one I've run accross was resolved by making sure the assembly is referenced correctly in the Visual Studio project and that the information is correct in the web.config.
In Visual Studio, check the properties on the references for the assemblies
verify the the version listed.
check if Specific Version is true/false.
check if Copy Local is true.
If the version is wrong, you may have to remove and re-add the reference.
I would guess the exception was not thrown on your local machine because the older version of the assemblies are available on your machine.
The reason your local information is showing in the exception is unrelated to the assembly reference issue. Your local system is where the assembly was built, and so that information is built in for debugging purposes. (If this exception was thrown while you were debugging, VS would bring you to that line of that file.)
Ok I was worried that I somewhere along the way bits of 6.3.6.0 where left on my system from when I had it installed.. After days of trying to figure this one out I actually have come up with the fix for this issue... I just simply needed to overwrite the version information using assembly binding in the web.config. Once I did that it loads from the remote server error free... Here is what I added to my web.config:
<dependentAssembly>
<assemblyIdentity name="MySql.Data" publicKeyToken="c5687fc88969c44d" />
<bindingRedirect oldVersion="0.0.0.0-6.3.6.0" newVersion="6.4.4.0" />
</dependentAssembly>
Could you please explain where I put the "Copy local = true" I do not see it as being part of any property window. I did find "Always Copy" for the resources. also where does this go in the web.config
<dependentAssembly>
<assemblyIdentity name="MySql.Data" publicKeyToken="c5687fc88969c44d" />
<bindingRedirect oldVersion="0.0.0.0-6.3.6.0" newVersion="6.4.4.0" />
</dependentAssembly>
I ran the package manager console and then used this to fix this problem:
PM> Install-Package MySQL.Data.Entities