I have a C# class library which contains a number of dlls in the assembly which I have updated. The classes are executed from a .exe file. Recompiling the calling the exe is fairly tricky (not done by me). I now get the following.
Could not load file or assembly 'xxx.xxx.xxx.xxx, Version=0.3.1768.0,
Culture=neutral, PublicKeyToken=xxxxxxxx' or one of its dependencies.
The located assembly's manifest definition does not match the assembly
reference. (Exception from HRESULT: 0x80131040)
Does this mean that the references used when compiling the .exe are now different from the newer dlls I have used in the assembly that the classes inherit? Note that I have kept the original dlls used to build the .exe file. So I'm curious as to the message and I'm assuming that it is because the dlls pulled in a references in the references are newer than those in the directories used for the executable.
Related
I have the situation where I have a class library being used in a Unity3D project, and which uses Json serialization/deserialization. Since the official NewtonSoft.Json NuGet doesn't work well together with Unity, I am using Json.Net.Unity3D (v. 9.0.0.0), which has worked fine up until now.
Now I'm setting up another project, where one of the main component has a dependency on NewtonSoft.Json (v. 11.0.0.0). This new project also needs to reference the previously mentioned class library. This compiles without problem, but when the class library tries to use the Json functions, it can't find the needed Json library and I get an error.
System.IO.FileLoadException: Could not load file or assembly 'Newtonsoft.Json, Version=9.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)
File name: 'Newtonsoft.Json, Version=9.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed' ---> System.IO.FileLoadException: Could not load file or assembly 'Newtonsoft.Json, Version=11.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)
File name: 'Newtonsoft.Json, Version=11.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed'
Since the two Json library versions have differing PublicKeyTokens, the binding redirect won't work. I've been trying unsuccessfully to find a solution to this problem, but would need some input. These are the possible options I've come up with:
Preventing the main project's Json library propagating to the
referenced project somehow. If I run a test version where the main
project doesn't have a Json library at all, the sub project works
fine.
Hacking the binding redirect to accept different dll:s for different versions. Doesn't seem to be possible.
Having both versions installed in the main project and used where appropriate. Also seems like a non-starter.
Any insight would be much appreciated - I've wasted way too much time on this problem already.
Here's a small test solution that demonstrates the problem
I'm not sure if this would work, but you could try to have the v9 referenced through nuget package, and the v11 referenced manually from dll file that will be "copy always" to output directory plus it should have different file name. This way the output assembly should load two json dlls - v9 and v11.
I ended up deciding that this was not possible with a reasonable amount of work, so I took another approach. I created an interface that provided the same methods from NewtonSoft.Json used by my library (i.e. JsonConvert.Serialize and Deserialize), and then made a wrapper implementing said interface in each project referencing the library. This allowed me to completely remove any references to NewtonSoft.Json from the library, and it only required a small amount of duplicated code in each project.
I have set my assembly reference as shown above to the my Web Api project. After compiling, it shows correct dll on the webapi's bin folder. But when I ran the app, it automatically changes to the older dll (ver 4.0). This is happening only for the bin folder's assembly. The web api's reference still shows the correct version (5.2.3). This is really strange. Could you tell me how to sort out this issue ? Thanks in advance.
It returns this error due to auto changed the assembly :
Could not load file or assembly 'System.Net.Http.Formatting' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
So I started working on an existing project at work in NopCommerence and I accidently added the Newtonsoft.Json DLL to the Nop.Core project, ever since then, the project keeps randomly crashing giving me the error:
Could not load file or assembly 'Newtonsoft.Json, Version=6.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)
Could not load file or assembly 'Newtonsoft.Json, Version=4.5.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 removed the reference from the project right away, so there is now no reference to this DLL in the Nop.Core project.
But there is some code in the project which looks for the reference:
When we get to that plugin it crashes here:
I got no clue where to even look to solve this, it looks like it's trying to load two different versions of the DLL and when I Google around, it says to update though NuGet and I did this and nothing has solved it.
So you removed the reference, but what about the actual dll file? It looks like something is 'discovering' it at runtime and it exists on your disk somewhere and the application is finding it.
It's hard to know what to suggest but try to find out where the app is looking for plugin files, then look in that directory and delete the Json stuff. You could also try just deleting all of the bin and obj directories in the whole solution, since they will be re-created by the next build. Also look in the packages directory in the root of your solution, you may find a copy of the Json package lingering there. If you;ve definitely removed it using NuGet, then delete it from packages too.
Make a backup copy before you start, just in case my suggestions are complete rubbish ;-)
I built a simple WIX installer that deploys an exe and a third-party dll, and creates shortcuts. The installer appears to work fine, and places both the exe and dll in a folder in C:\Program Files(x86), but when I try to run the application I get an error:
System.IO.FileLoadException: Could not load file or assembly 'GACManagerApi, 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)
File name: 'GACManagerApi, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'
The application runs just fine from the IDE, and even from the executable in the IDE bin directory, but after deploying with WIX cannot load the assembly. On a hunch, I copied the dll from the bin directory to the deployed location, and it started working. Looking closer, it appears that WIX is doing something to the third-party metadata when it deploys that changes the signature enough that the exe can no longer load it. Here is the definition of the assembly in the wxs:
<Component Id="GACManagerApi">
<File Id="GACManagerApiDLL" Name="GACManagerApi.dll" Source="$(var.GHCComponentManager.TargetPath)" />
</Component>
I also noticed that the details on the dll properties are different, with the File description, product name and original filename being changed to that of my executable, instead of the original values for the assembly.
Am I missing something in my wsx that is causing this to happen?
I figured it out. The problem was how I was defining the Source attribute. The hint really should have been in the file property details, but I was too consumed with my assumptions to see it. I was reading some other documents talking about pulling assemblies from outside the project when I noticed it.
I was defining the source as:
Source="$(var.GHCComponentManager.TargetPath)"
which translates literally to the full path of my release executable. With the Name attribute of the File element, it was effectively moving my executable to the release location and renaming it GACManagerApi.dll. The correct source should be:
Source="$(var.GHCComponentManager.TargetDir)\GACManagerApi.dll"
I'm trying to compile an application for which I have the solution and can't get past:
'Microsoft.Practices.EnterpriseLibrary.Common.Configuration.IConfigurationSource'
is defined in an assembly that is not referenced. You must add a
reference to assembly 'Microsoft.Practices.EnterpriseLibrary.Common,
Version=3.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
So I added the assembly to the GAC:
After some research I opened up visual studio with the Fusion Assembly Binding Viewer running, which seemed to create a lot of logs but none that related to this exact version of the assembly (however 4.1.0.0 is in there).
I can't simply add -> reference as VS tells me that a reference with the same name already exists.
What other avenues should I explore?
Have you tried to Alias the assembly also if you are using .net 4.0 you would have to have an entry in the .config file for example that shows the old assembly name referencing the new assembly name. Several other things to keep in mind .. if the .DLL is in the GAC and you don't have a copy of that assembly in the bin folder, this could cause an issue..
Is this local referencing or is the code on a remote machine ..? if it's a remote machine.. why not add that specific assembly to the GAC.. notice the versioning difference of the two assembly's in your screen shot as well..