[Update]: Turns out that this problem was caused by one and only one COM class, that happens to be a COM singleton, meaning that no matter how many times you call CoCreateInstance, you always get back the same instance. It gets wrapped by the first interop assembly that gets loaded (which makes sense) and when another bit of code asks for a reference it gets the same wrapper back. Which also makes sense. You can't have two wrapper objects pointing to the same COM instance, or chaos whould insue. So, the problem is not that you can't load two interop assemblies with different versions, it's that you can't wrap the same instance twice with two differently-versioned wrapper classes.
We ran afoul of an interesting problem at work today, which upon reflection (no pun intended) makes sense, but I'd never thought about before.
Due to an historical accident, we've got an application that's using our libraries, and also some primary interop assemblies to our core product. Unfortunately, they aren't the same version of the primary interop assemblies that we're using for our libraries. So primary is kind of fuzzy in this case. The problem is that only one of them ever gets loaded. They don't work in standard .NET side-by-side fashion. The have different version numbers, etc. so it should. However, when we started thinking about it, there can really only be one LoadLib and CoCreateInsance happening deep in the bowels some where, so having two primary interop assemblies pointing to the same COM objects doesn't really make any sense. Dang. Anyway, once they don't both get loaded, we get a nasty invalid cast exception where there shouldn't be one if we were dealing with properly side-by-sideable .NET assemblies.
If it's not one thing it's another.
Powered by: newtelligence dasBlog 2.3.9074.18820
The opinions expressed herein are my own personal opinions and do not represent
my employer's view in any way.
© Copyright 2013, Patrick Cauldwell