The located assembly's manifest definition does not match the assembly reference

前端 未结 30 2104
北恋
北恋 2020-11-22 01:41

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: Co

相关标签:
30条回答
  • 2020-11-22 02:08

    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>
    
    0 讨论(0)
  • 2020-11-22 02:08

    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://docs.microsoft.com/en-us/dotnet/framework/configure-apps/how-to-enable-and-disable-automatic-binding-redirection

    0 讨论(0)
  • 2020-11-22 02:09

    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.

    0 讨论(0)
  • 2020-11-22 02:10

    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.

    0 讨论(0)
  • 2020-11-22 02:12

    I got the same error... In my case it got resolved as follows:

    • At first when the application was installed then the people here had used Microsoft Enterprise Library 4.1 in the application.
    • In previous week my machine was formatted & after that today when I built that application then it gave me an error that Enterprise Library assembly is missing.
    • Then I installed Microsoft Enterprise Library 5.0 which I got on Google as first search entry.
    • Then when I built the application then it gave me the above error i.e. The located assembly's manifest definition does not match the assembly reference.
    • After much of a search work & analysis, I found that application was referring 4.1.0.0 & the DLL in the bin folder was of the version 5.0.0.0
    • What i did was then I installed the Microsoft Enterprise Library 4.1.
    • Removed the previous reference(5.0) & added the 4.0 reference.
    • Built the application & voila...it worked.
    0 讨论(0)
  • 2020-11-22 02:13

    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.

    0 讨论(0)
提交回复
热议问题