I have a WPF app I'm compiling in Visual Studio 2010 that uses a CLR .dll to interact with some unmanaged C/C++ code. The idea is that WPF references the CLR .dll which in turn references the unmanaged code. Unfortunately, I'm running into terrible linking issues because the unmanaged C/C++ code and related libraries all link statically to the C/C++ runtime, but if I try to use that code generation method on the CLR .dll, it throws an error because the /clr option and statically linking to the CRT are incompatible. I need to somehow glue these things together.
My thought was to try to create an additional .dll that just contained all of the unmanaged code in a single package (also linked statically to the CRT), then link that to the CLR .dll, which in turn links into the app (blech!). I tried to make such a .dll, but the problem is that (maybe obviously?) it didn't pull in any of the symbols from the static .lib files because it didn't need any of them. I tried forcing symbol references (/OPT:NOREF), but that didn't seem to do anything. It's just an empty .dll that "links" to the libs but isn't actually doing anything. So a big fail on that idea.
Am I approaching this whole thing all wrong?
I don't have source code for some of the unmanaged libraries, so I can't recompile them to link dynamically to the CRT. These linking problems are getting really frustrating!
Thanks for any suggestions!
UPDATE: I guess this is tantamount to trying to mix /MT and /MD modules together, which, according to this, is not possible. How is it that you're supposed to link projects in which you don't have control over third party libraries? You just hope that they've all chosen to use the same runtime library linking method?! Seems like a horrible idea...
