views:

326

answers:

3

My Visual Studio 2008 project references two (external) assemblies (A+B) both of which happen to be referencing the same third assembly (C). However, assembly A expects assembly C to have a public key which is different from what assembly B expects it to have.

Here's an example of the obvious exception:

Could not load file or assembly 'Newtonsoft.Json, Version=3.5.0.0, Culture=neutral, PublicKeyToken=9ad232b50c3e6444' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

Ofcourse, I would not be able to put both versions of C (only differing by public key) in the same directory, as their filenames are equal. Second, I've found that using assembly binding from the configuration file only allows version mapping, not public key mapping.

I've also tried to put one of the assemblies C in a separate directory and configure the CLR to search in that directory when loading assemblies. I could not get that to work unfortunately.

I'm aware that recompiling one of the external libraries (one of them happens to be open sourced) would fix this problem but I don't want to add that burden to my maintenance plan if it is not absolutely necessary.

So my question is: how would I reference both 'versions' of assembly C, which only differ by public key?

UPDATE

I stumbled upon this answer to a related question, providing an interesting solution using ilmerge. I haven't checked it out yet but it may be useful to anyone struggling with this problem.

+2  A: 

I wonder if AssemblyResolve would work:

AppDomain.CurrentDomain.AssemblyResolve += new ResolveEventHandler(CurrentDomain_AssemblyResolve);

static Assembly CurrentDomain_AssemblyResolve(object sender, ResolveEventArgs args)
{
    if (args.Name == "full name with old key")
    {
        return typeof(SomeTypeInReferencedAssembly).Assembly;
    }
    return null;
}

He're I'm assuming that you've referenced your preferred version and can use the type SomeTypeInReferencedAssembly to get the Assembly; you could also use:

return Assembly.Load("full name with new key");

I haven't tried it, but here I'm essentially saying "deploy one version of the dll, and when the system asks for the old one - lie".

Marc Gravell
Thanks, that's a great solution. Now let's hope some day one of the referencing assemblies will change their reference to C.
Sandor Drieënhuizen
Actually, it doesn't work for me: it now says that the assembly manifest of the type I return does not match the manifest of the reference. It's got a point there...
Sandor Drieënhuizen
Could you post the offending code in your question, Sandor?
Adam Robinson
Hmmm... I'm all out of ideas, then. Sorry.
Marc Gravell
+2  A: 

You should never have two assemblies with the same version but different public keys, that's a recipe for disaster. If the actual assembly versions are different, then the absolute easiest solution is to place them in the global assembly cache (GAC). This will not, however, play nicely if you'll be dealing with instances of types that are defined in C and used in both A and B (for example, C declares MyType, and you obtain an instance of MyType from B and pass it to A. As far as the runtime is concerned, these two types have absolutely nothing to do with one another aside from sharing a name).

If you're looking for a temporary solution, then I would go with Marc's; it sounds like it should work perfectly. That being said, however, the fact that you're going down this road should be a giant red flag.

Adam Robinson
You're absolutely right. Fortunately, in this case, I will never have to pass types around A and B because they have nothing to do with each other. I'm using Marc's solution as a temporary fix now until A or B changes its reference to C. I know this is kinda bad but I guess there's no proper way other than tossing out A or B.
Sandor Drieënhuizen
+1  A: 

I had similar problem and this is how i resolved it.

Hemanshu Bhojak