I’ve got a problem similar to,but subtly different from, that described here (Loading assemblies and their dependencies).
I have a C++ DLL for 3D rendering that is what we sell to customers. For .NET users we will have a CLR wrapper around it. The C++ DLL can be built in both 32 and 64bit versions, but I think this means we need to have two CLR wrappers since the CLR binds to a specific DLL?
Say now our customer has a .NET app that can be either 32 or 64bit, and that it being a pure .NET app it leaves the CLR to work it out from a single set of assemblies. The question is how can the app code dynamically choose between our 32 and 64bit CLR/DLL combinations at run-time?
Even more specifically, is the suggested answer to the aforementioned question applicable here too (i.e. create a ResolveEvent handler)?
I finally have an answer for this that appears to work.
Compile both 32 & 64 bit versions – both managed & unmanaged – into separate folders. Then have the .NET app choose at run time which directory to load the assemblies from.
The problem with using the ResolveEvent is that it only gets called if assemblies aren’t found, so it is all to easy to accidentally end up with 32 bit versions. Instead use a second AppDomain object where we can change the ApplicationBase property to point at the right folder. So you end up with code like:
You end up with 2 exes – your normal app and a second switching app that chooses which bits to load. Note – I can’t take credit for the details of this myself. One of my colleagues sussed that out given my initial pointer. If and when he signs up to StackOverflow I’ll assign the answer to him