Using a .NET COM DLL in C++ Builder 4 - Ambiguity between Strings and System::Strings

Question

I've created a .NET COM DLL that I need to use in my C++ Builder 4 project. I'm able to import the DLL using the Import Type Library functionality (in fact I import the TLB file that comes with the DLL when I build it). This creates a Component_TLB.h in my C++ Builder \ Imports folder. I then #include this _TLB file in my project and I'm able to do the following:

TCOM_Create theDLL;
theDLL = CoCreate::Create();
theDLL->FunctionX(paramy);

This works as intended.

---

The Component_TLB.h created from the "Import Type Library" functionality includes (amongst other things) mscorlib :

#include "mscorlib_TLB.h"

...which seems to be a dependable of my DLL, here's what I've found in the comments:

// DepndLst: 
//   (1) v2.0 mscorlib, (C:\Windows\Microsoft.NET\Framework\v2.0.50727\mscorlib.tlb)  **<---**
//   (2) v2.0 stdole, (C:\Windows\SysWOW64\stdole2.tlb)
//   (3) v4.0 StdVCL, (C:\Windows\SysWow64\STDVCL40.DLL)

The problem is that because this mscorlib is included in my project I can't use the "String" type like I used to be. The following line:

String abc;

..gives me the following error:

[C++ Error] Unit1.cpp(23): E2015 Ambiguity between 'String' and 'System::String'.

It looks like this mscorlib has its own String type or something... I've found:

extern const GUID IID__String;

and

extern const GUID CLSID_String;

I use the String type A LOT in my project, how can I "force" the compiler to use System::String without having to recode everything line with a String type or how could I work around this ?

Answer 1

Use a namespace so these identifiers don't get added to the global namespace

namespace Mumble {
   #include Component_TLB.h
}