Namespace clashes between .NET Framework and 3rd party C++ library

[bendx]

I'm having a namespace clashing issue in my managed C++ app. I am using VC8 and have a simple .cpp file that includes headers from a 3rd party library. That 3rd party library has classes named System and Image and a variety of others that can be found in the .NET Framework.

As soon as I turn on CLR Runtime support and make the app a managed C++ build, I get dozens of name clashing errors because of the ambiguity between the .NET classes and the 3rd party library.

How can I solve this? I believe VC8 is automatically including or "using" some of the default .NET namespaces like System; and System.Drawing, etc, even when I haven't explicitely done so.

I've tried explicitely referring to all of my 3rd party classes with a namespace prefix like 3rdParty::SomeClass, but it still says there's an ambiguity.

[cilu]

First, System is a namespace not a class name in .NET framework.

Second, use fully qualified names, like System::Drawing::Image.

[bendx]

I realize that System is a namespace in .NET, but the VC8 compiler is saying that it is not sure if the use of the .NET System namespace could mean the .NET System namespace or my 3rd party library's System class. Funny enough it finds this problem on a Microsoft header file, not in my code.

This is presumably because I've done an include on my 3rd party library along with a using namespace My3rdPartyLibrary; causing VC8 to consider both as possibilities.

I can get around this by not doing a using namespace on my 3rd party lib, however then I have to go into the headers for my 3rd party lib and prefix the namespace to every single class. I would then need to do this every time their headers changed, and there are cases where their macros would require some weird modifications as well.

In the end this might be the best way for me to do it, but it will be a wicked pain in the neck.

Right now I've had to resort to building my .NET code in C# and pInvoking into a C++ wrapper dll that I've created, which forwards calls to my 3rd party library. Its not impossible, but it causes me to write a ton of wrapper functions and its just not doable as the project continues to grow.