This is a mismatch between assemblies: a DLL referenced from an assembly doesn't have a method signature that's expected.
Clean the solution, rebuild everything, and try again.
Also, be careful if this is a reference to something that's in the GAC; it could be that something somewhere is pointing to an incorrect version. Make sure (through the Properties of each reference) that the correct version is chosen or that Specific Version is set false.
I ran into this issue in a web api project.
Api project was using a nuget package of a library with version 3. And one of the referenced assemblies say X was using older version of the same nuget package with version 2.
Whenever referenced assembly is built or any other project referencing X is rebuilt, api project's assemblies gets updated with lower version. And got this assembly reference error.
Rebuild works but in my case I wanted a long term solution.
I made the assemblies reference same version of nuget package.
This usually happens when the version of one of the DLLs of the testing environment does not match the development environment.
Clean and Build your solution and take all your DLLs to the environment where the error is happening that should fix it
This happened to me when I updated web.config without updating all referenced dlls.
Using proper diff filter (beware of Meld's default directory compare filter ignoring binaries) the difference was identified, files were copied and everything worked fine.
This is a mismatch between assemblies: a DLL referenced from an assembly doesn't have a method signature that's expected.
Clean the solution, rebuild everything, and try again.
Also, be careful if this is a reference to something that's in the GAC; it could be that something somewhere is pointing to an incorrect version. Make sure (through the Properties of each reference) that the correct version is chosen or that Specific Version is set false.
Just delete the bin folder and then then the project recreates all again and it will be working now .
I had the issue where it wouldn't find the PayPal assembly and it was because I had named my solution PayPal. I'm sure this won't be the answer for anyone but thought I'd share it anyway: C# ASP.NET MVC PayPal not finding assembly
Just Check your webconfig file and remove this code :-
<dependentAssembly>
<assemblyIdentity name="itextsharp" publicKeyToken="8354ae6d2174ddca" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-5.5.13.0" newVersion="5.5.13.0" />
</dependentAssembly>
In my case I got this message while debugging:
"Error while calling service <ServiceName> Could not load file or assembly 'RestSharp,
Version=105.2.3.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies.
The located assembly's manifest definition does not match the assembly reference.
(Exception from HRESULT: 0x80131040)"
Cause
In my project I have had 2 internal components using the RestSharp but both component have different version of RestSharp (one with version 105.2.3.0 and the other with version 106.2.1.0).
Solution
Either upgrade one of the components to newer or downgrade the other. In my case it was safer for me to downgrade from 106.2.1.0 to 105.2.3.0 and than update the component in NuGet package manager. So both components has the same version.
Rebuild and it worked with out problems.
If you got this error trying to add a component to Visual Studio,- Microsoft.VisualStudio.TemplateWizardInterface - (after trying to install weird development tools)
consider this solution(courtesy of larocha (thanks, whoever you are)):
Microsoft.VisualStudio.TemplateWizardInterface" <dependentAssembly>
<!-- assemblyIdentity name="Microsoft.VisualStudio.TemplateWizardInterface" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" / -->
<bindingRedirect oldVersion="0.0.0.0-8.9.9.9" newVersion="9.0.0.0" />
</dependentAssembly>
source: http://webclientguidance.codeplex.com/workitem/15444
I had the issue where it wouldn't find the PayPal assembly and it was because I had named my solution PayPal. I'm sure this won't be the answer for anyone but thought I'd share it anyway: C# ASP.NET MVC PayPal not finding assembly
In my case it was happening because of WebGrease. I updated it to the latest version (using NuGet) but it was conflicted with the dependencies. I manually added the below code in web.config and it worked as a charm.
<dependentAssembly>
<assemblyIdentity name="WebGrease" culture="neutral" publicKeyToken="31bf3856ad364e35" />
<bindingRedirect oldVersion="0.0.0.0-1.6.5135.21930" newVersion="1.6.5135.21930" />
</dependentAssembly>
Please note my solution will only work when the error is related to WebGrease. The error code will remain the same. Also, you need to change the version in oldVersion and newVersion accordingly.
My problems solved by remove all the runtime part
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="System.Web.Helpers" publicKeyToken="31bf3856ad364e35"/>
<bindingRedirect oldVersion="1.0.0.0-3.0.0.0" newVersion="3.0.0.0"/>
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="System.Web.WebPages" publicKeyToken="31bf3856ad364e35"/>
<bindingRedirect oldVersion="1.0.0.0-3.0.0.0" newVersion="3.0.0.0"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
In my particular situation, I got this as a result of a CreateObject done in VBScript.
The cause in my case was a version of the assembly that resided in the GAC, that was older than the one I had compiled. (trying to solve an earlier problem, I installed the assembly in the GAC).
So, if you're working with COM visible classes, then be sure you remove older versions of your assembly from the GAC, before registering your new assembly with RegASM.
Just Check your webconfig file and remove this code :-
<dependentAssembly>
<assemblyIdentity name="itextsharp" publicKeyToken="8354ae6d2174ddca" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-5.5.13.0" newVersion="5.5.13.0" />
</dependentAssembly>
Just another case here. I had this error from Managed Debugging Assistant on the first time deserializing a XML file into objects under VS2010/.NET 4. A DLL containing classes for the objects is generated in a post-build event (usual Microsoft style stuff). Worked very well for several projects in same solution, problem appeared when doing that in one more of the projects. Error text:
BindingFailure was detected Message: The assembly with display name MyProjectName.XmlSerializers' failed to load in the 'LoadFrom' binding context of the AppDomain with ID 1. The cause of the failure was: System.IO.FileLoadException: Could not load file or assembly MyProjectName.XmlSerializers, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
Since some answers here suggested a platform mismatch, I noticed that 3 projects and the solution had "mixed platforms" configuration selected, and 3 projects were compiled for x86 instead of AnyCPU. I have no platform-specific code (though some vendor-provided DLLs rely on a few x86 libraries). I replaced all occurrences of x86 into AnyCPU with this:
for a in $( egrep '(x86|AnyCPU)' */*.csproj *.sln -l ) ; do echo $a ; sed -i 's/x86/AnyCPU/' $a ; done
Then the project would build but all options to run or debug code would be greyed out. Restarting VS would not help.
I reverted with git the references to the x86-library, just in case, but kept AnyCPU for all the code I compile.
Following F5 or Start Debugging Button is Greyed Out for Winform application? I unloaded and reloaded the starting project (it was also the one where the initial problem appeared in the first place).
After that, everything fell back into place: the program works without the initial error.
See http://www.catb.org/jargon/html/R/rain-dance.html , http://www.catb.org/jargon/html/V/voodoo-programming.html or http://www.catb.org/jargon/html/I/incantation.html and links there.
I ran into similar problems when accessing the project files from different computers via a shared folder. In my case clean + reabuild did not help. Had to delete the bin and objects folders from the output directory.
This is a mismatch between assemblies: a DLL referenced from an assembly doesn't have a method signature that's expected.
Clean the solution, rebuild everything, and try again.
Also, be careful if this is a reference to something that's in the GAC; it could be that something somewhere is pointing to an incorrect version. Make sure (through the Properties of each reference) that the correct version is chosen or that Specific Version is set false.
I got this error when working in the Designer. I had been developing in VS 2012, but "upgraded" to 2017 over the past couple days. Solution was to close and reopen VS.
It may be related to a bug which I've seen reported elsewhere, where the Reference Manager does not work? In that situation, the following error message is encountered when trying to add a reference in the Solution Explorer:
"Error HRESULT E_FAIL has been returned from a call to a COM component."
My workaround was to close the solution, reopen in VS2012, add the reference, close 2012 and reopen 2017. Ridiculous that 2017 should have been released with such an obvious bug.
In my case for a wcf rest services project I had to add a runtime section to the web.config where there the requested dll was:
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="DotNetOpenAuth.Core" publicKeyToken="2780ccd10d57b246" />
<bindingRedirect oldVersion="0.0.0.0-4.1.0.0" newVersion="4.1.0.0" />
</dependentAssembly>
.
.
.
<runtime>
I just delete settings.lic file from project and start working!
This is a mismatch between assemblies: a DLL referenced from an assembly doesn't have a method signature that's expected.
Clean the solution, rebuild everything, and try again.
Also, be careful if this is a reference to something that's in the GAC; it could be that something somewhere is pointing to an incorrect version. Make sure (through the Properties of each reference) that the correct version is chosen or that Specific Version is set false.
If you got this error trying to add a component to Visual Studio,- Microsoft.VisualStudio.TemplateWizardInterface - (after trying to install weird development tools)
consider this solution(courtesy of larocha (thanks, whoever you are)):
Microsoft.VisualStudio.TemplateWizardInterface" <dependentAssembly>
<!-- assemblyIdentity name="Microsoft.VisualStudio.TemplateWizardInterface" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" / -->
<bindingRedirect oldVersion="0.0.0.0-8.9.9.9" newVersion="9.0.0.0" />
</dependentAssembly>
source: http://webclientguidance.codeplex.com/workitem/15444
In my case for a wcf rest services project I had to add a runtime section to the web.config where there the requested dll was:
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="DotNetOpenAuth.Core" publicKeyToken="2780ccd10d57b246" />
<bindingRedirect oldVersion="0.0.0.0-4.1.0.0" newVersion="4.1.0.0" />
</dependentAssembly>
.
.
.
<runtime>
My WPF project referenced 3 custom dlls. I updated one of them, deleted the reference and added the reference to the new dll. It also showed the correct version number in the properties of the reference. It was rebuilding without an error.
But when the application was running, the failure "The located assembly's manifest .." occured, mentioning the old version.
After searching for a solution for hours and reading couple of threads like this, I remembered the other dlls. One of the other dlls was referencing the old version, and that's why the failure occured. After rebuilding the 2nd dll and recreating both references in my WPF project, the failure was gone.
Don't forget to check your other dlls!
Just another case here. I had this error from Managed Debugging Assistant on the first time deserializing a XML file into objects under VS2010/.NET 4. A DLL containing classes for the objects is generated in a post-build event (usual Microsoft style stuff). Worked very well for several projects in same solution, problem appeared when doing that in one more of the projects. Error text:
BindingFailure was detected Message: The assembly with display name MyProjectName.XmlSerializers' failed to load in the 'LoadFrom' binding context of the AppDomain with ID 1. The cause of the failure was: System.IO.FileLoadException: Could not load file or assembly MyProjectName.XmlSerializers, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
Since some answers here suggested a platform mismatch, I noticed that 3 projects and the solution had "mixed platforms" configuration selected, and 3 projects were compiled for x86 instead of AnyCPU. I have no platform-specific code (though some vendor-provided DLLs rely on a few x86 libraries). I replaced all occurrences of x86 into AnyCPU with this:
for a in $( egrep '(x86|AnyCPU)' */*.csproj *.sln -l ) ; do echo $a ; sed -i 's/x86/AnyCPU/' $a ; done
Then the project would build but all options to run or debug code would be greyed out. Restarting VS would not help.
I reverted with git the references to the x86-library, just in case, but kept AnyCPU for all the code I compile.
Following F5 or Start Debugging Button is Greyed Out for Winform application? I unloaded and reloaded the starting project (it was also the one where the initial problem appeared in the first place).
After that, everything fell back into place: the program works without the initial error.
See http://www.catb.org/jargon/html/R/rain-dance.html , http://www.catb.org/jargon/html/V/voodoo-programming.html or http://www.catb.org/jargon/html/I/incantation.html and links there.
I just delete settings.lic file from project and start working!
In my case I got this message while debugging:
"Error while calling service <ServiceName> Could not load file or assembly 'RestSharp,
Version=105.2.3.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies.
The located assembly's manifest definition does not match the assembly reference.
(Exception from HRESULT: 0x80131040)"
Cause
In my project I have had 2 internal components using the RestSharp but both component have different version of RestSharp (one with version 105.2.3.0 and the other with version 106.2.1.0).
Solution
Either upgrade one of the components to newer or downgrade the other. In my case it was safer for me to downgrade from 106.2.1.0 to 105.2.3.0 and than update the component in NuGet package manager. So both components has the same version.
Rebuild and it worked with out problems.
My problems solved by remove all the runtime part
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="System.Web.Helpers" publicKeyToken="31bf3856ad364e35"/>
<bindingRedirect oldVersion="1.0.0.0-3.0.0.0" newVersion="3.0.0.0"/>
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="System.Web.WebPages" publicKeyToken="31bf3856ad364e35"/>
<bindingRedirect oldVersion="1.0.0.0-3.0.0.0" newVersion="3.0.0.0"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
This happened to me when I updated web.config without updating all referenced dlls.
Using proper diff filter (beware of Meld's default directory compare filter ignoring binaries) the difference was identified, files were copied and everything worked fine.
I ran into similar problems when accessing the project files from different computers via a shared folder. In my case clean + reabuild did not help. Had to delete the bin and objects folders from the output directory.
I recently had this issue and I ran 'depends.exe' on the dll in question. It showed me that the dll was compiled in x86 while some of the dependencys were compiled in x64.
If you are still having troubles I would recommend using depends.exe.
My WPF project referenced 3 custom dlls. I updated one of them, deleted the reference and added the reference to the new dll. It also showed the correct version number in the properties of the reference. It was rebuilding without an error.
But when the application was running, the failure "The located assembly's manifest .." occured, mentioning the old version.
After searching for a solution for hours and reading couple of threads like this, I remembered the other dlls. One of the other dlls was referencing the old version, and that's why the failure occured. After rebuilding the 2nd dll and recreating both references in my WPF project, the failure was gone.
Don't forget to check your other dlls!
This usually happens when the version of one of the DLLs of the testing environment does not match the development environment.
Clean and Build your solution and take all your DLLs to the environment where the error is happening that should fix it
I ran into this issue in a web api project.
Api project was using a nuget package of a library with version 3. And one of the referenced assemblies say X was using older version of the same nuget package with version 2.
Whenever referenced assembly is built or any other project referencing X is rebuilt, api project's assemblies gets updated with lower version. And got this assembly reference error.
Rebuild works but in my case I wanted a long term solution.
I made the assemblies reference same version of nuget package.
I got this error when working in the Designer. I had been developing in VS 2012, but "upgraded" to 2017 over the past couple days. Solution was to close and reopen VS.
It may be related to a bug which I've seen reported elsewhere, where the Reference Manager does not work? In that situation, the following error message is encountered when trying to add a reference in the Solution Explorer:
"Error HRESULT E_FAIL has been returned from a call to a COM component."
My workaround was to close the solution, reopen in VS2012, add the reference, close 2012 and reopen 2017. Ridiculous that 2017 should have been released with such an obvious bug.
I recently had this issue and I ran 'depends.exe' on the dll in question. It showed me that the dll was compiled in x86 while some of the dependencys were compiled in x64.
If you are still having troubles I would recommend using depends.exe.
Source: Stackoverflow.com