Could you be missing the loaded assembly from your configuration file?
Ensure you have something similar to the following within your web.config. NuGet would normally do this but maybe it hasn't and it doesn't know what to load in
<dependentAssembly> <assemblyIdentity name="System.Runtime.InteropServices.RuntimeInformation" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" /> <bindingRedirect oldVersion="0.0.0.0-4.0.2.0" newVersion="4.0.2.0" /> </dependentAssembly>
Apparently this can be solved by adding a <qualifyAssembly> element to the app.config file. Adding the following has my app running smoothly:
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<qualifyAssembly partialName="System.Data.SqlServerCe" fullName="System.Data.SqlServerCe, Version=3.5.1.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91" />
</assemblyBinding>
</runtime>
yeah the fullName referred to above is indeed the full name for the assembly. It gives the CLR the info it needs to find and load the specific assembly. You can also substitute that fullName in a connection string in a .config file (in place of the partialName)
Remove all the references to Newtonsoft.Json in all your projects.
Go to Nuget Package Manager (right click on solution), download Newtonsoft.Json latest version and select all the projects to use it, and reinstall it.
Make sure the packages.config have the latest version:
<packages> <package id="Newtonsoft.Json" version="11.0.2" targetFramework="net461" /> </packages>
Rebuild solution.
This is one of the most common problems in .NET projects.
Basically someone made a reference directly to an local assembly instead of managing the package via NuGet or the project was made to compile in a different .NET version.
The best way to solve this is to locate the reference in your project references, remove it, clean the project, check if the DLL has gone and finally remake the reference using NuGet.
try clean your project.
Clean Project in Visual Studio
If this don't work, remove the reference under references. Save the dll file in your bin folder and then add it again. Browse your file, select it and click in ok.
I had a similar issue when I had two different projects within the same solution, in which one of them is referring to version 11.0.2 and the other is referring to version 6.0.4. If this is the case, try keeping the same version for both of them and retry.
Some time it happens because the oracle dll is 32 bit and your application is build on 64 bit changing the app to 32 bit may solve your problem
if the reason is 32/64 mixup i causes a BadImageFormatException
When I attempted to duplicate the problem, the error went away after I ran a NuGet update for System.Runtime.CompilerServices.Unsafe.
It looks like a new dependency with the latest Unity version (v5.9.3) and there is a configuration problem with a version of the dependent package. If you want to know more you can read stackoverflow.com/questions/215026/… and stackoverflow.com/questions/20978519/…
Jasen is correct if your NuGet plays nicely with your project, but I wasn't so lucky (when I tried re-adding the package, I got the same error).
What fixes the bug is adding a dependentAssembly entry for the 'missing' assembly inside your app/web config (which is the magic behind the NuGet install, and should happen automatically).
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="System.Runtime.CompilerServices.Unsafe" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-4.0.4.1" newVersion="4.0.4.1" />
</dependentAssembly>
...
Sounds like one part of the project is being built for x86-only while the rest is being built for any CPU/x64. This bit me, too. Are you running an x64 (or uh... IA64)?
Check the project properties and make sure everything is being built for "Any CPU". if you're in Visual Studio, you can check for everything by going to the "x86" or "Any CPU" menu (next to the "Debug"/"Release" menu) on the toolbar at the top of the screen and clicking "Configuration Manager..."
If you get this error while running the site in IIS 7+ on 64bit servers, you may have assemblies that are 32bit and your application pool will have the option "Enable 32-Bit Applications" set to False; Set this to true and restart the site to get it working.
Same here. It depends on where the error occurs. If it's through Visual Studio & Cassini web server, Fraser's right. If it occurs in IIS7+, Nicks answer is probably the most likely fix.
This was teh perfect answer for me (moved a site from IIS6 on x86 to IIS 7 on x64)
The BadImageFormatException on an application running on IIS (not running from VS, since visual studio fixes the problem by using the build for "Any CPU") can be caused by the following:
The site is one a server that is x64 and the Application Pool's default setting for Enable 32-Bit Applications was False. and you have 32-bit assemblies
On the level of Visual Studio, the fix is:
- Change the project setting "Target CPU" to "ANYCPU"
inetmgr then come to Application pool->Advanced setting of your pool-> will have the option "Enable 32-Bit Applications" set to true; and restart IIS. check again.!
if while In visual studio with IIS express working and when published failed try this:
Things I have tried:
- Make sure both projects are set to "Any CPU," with the build checkbox checked. They are.
- Make sure both projects are for the same Target Framework (.Net 4.0 Client Profile).
- Under ProjectB --> References --> ProjectA --> Properties, make sure "Copy Local" is set to "True" _ (I verified that ProjectA.dll is being copied correctly)
- Clean/Rebuild the solution. I even tried manually deleting the /bin and /obj folders in both projects.
- Restart Visual Studio. Restart my computer.
- Check out an entirely new copy of the repository.
But I still get the same error. I have no idea what I did to cause this, nor how to fix it. Any ideas?
i am pretty sure you're having a 32-bit / 64-bit conflict. It sounds like your main project might be set to 32-bit while the class its referencing is set to 64-bit. Try looking at this SO question and this one too. Between the two of them, you should be able to figure out your problem.
Do'h. I somehow completely missing "platform target" dropdown in project-->properties-->build - it was set for x86; setting it to "Any CPU" fixed this issue. I always thought that this setting was the same as the "platform target" dropdown in the configuration manager, but apparently it's not (in fact, the "platform target" in configuration manager doesn't appear to do anything at all!)
PS: Another reason is "Enable 32-bit applications" being "false" in app pool settings. You need to restart IIS after setting it to true.
Might be you are facing the problem with your website after deploying on server.
Then you need to adjust your application pool to Enable 32-Bit Applications.
Steps:
- Open IIS Manager
- Click on Application Pools
- Select whatever application pool you are using
- From right pane, click Advanced Settings...
- Set Enable 32-Bit Applications to True
I just had this error message running IIS Express in Visual Studio 2015. In my case I needed to be running the 64 bit version of IIS Express:
Tools -> Options -> Projects and Solutions -> Web Projects
Check the box that says "Use the 64 bit version of IIS Express for web sites and projects".
原文8：The located assembly's manifest definition does not match the assembly reference
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. Also see http://blogs.msdn.com/junfeng/archive/2004/03/25/95826.aspx.
Check the references version, and then look if its the same in packages.config and Web.config
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.
Another option would be to open the CompanyControls project, right-click the CompanyClasses.dllreference --> properties --> SpecificVersion = false
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>
My issue was the fact that the redirects were pointing to non-existent assemblies.The App.Config held assembly info from the latest NuGet packages I'd installed. When I downgraded these packages later, it did NOT clean this up. This was a .NET standard class library being hit by a 4.7.2 framework unit test project. The unit test project's issue presented at runtime..
is right. If your source control indicates that web.config has changes (because you've been playing with your NuGets) you might be wise to back those bindingRedirects out of there. Downgrading NuGets will not clean up the binding redirects
If you are using Visual Studio, try "clean solution" and then rebuild your project.
This is usually the solution for me. Often, deleting bin and obj do it. Basically, something I used to reference is still sitting there trying to satisfy the same requirement. For example, an old version being something I referenced directly and the new version being on NuGet
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
. 
That setting has only effect at compile time. After it is compiled, it will need the exact same assembly version with which you compiled it. See stackoverflow.com/questions/24022134/…
In my case, this error occurred while running an ASP.NET application. The solution was to:
- Delete the
objandbinfolders 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.
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.
"sn.exe" is a tool that comes with Visual Studio, it's a command line tool that can be run from the Visual Studio command prompt. Just run the Visual Studio command prompt (from the start menu), navigate to the folder that contains your assembly, and type "sn -T <assembly>" where <assembly> is the full name of the dll. This gets the Assembly "Token" information. Once you have this, when you are doing late binding with reflection, enter the token info into the assembly id string (i.e., "Assembly=MyAssembly.dll, Public Key Token=<token guid>) –
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
Similar answer for me. Update-Package -reinstall re-installs all NuGet packages at the same version.