What VC++ compiler/linker does when building a C++ project with Managed Extension

The initial problem is that I tried to rebuild a C++ project with debug symbols and copied it to test machine, The output of the project is external COM server(.exe file).

When calling the COM interface function, there's a RPC call failre: COMException(0x800706BE): The remote procedure call failed.

According to the COM HRESULT design, if the FACILITY code is 7, it's actually a WIN32 error, and the win32 error code is 0x6BE, which is the above mentioned "remote procedure call failed".

All I do is replace the COM server .exe file, the origin file works well.

When I checked into the project, I found it's a C++ project with Managed Extension. When I checking the DLL with reflector, it shows there's 2 additional .NET assembly reference.

Then I checked the project setting and found nothing about the extra 2 assembly reference. I turned on the show includes option of compiler and verbose library of linker, and try to analyze whether the assembly is indirectly referenced via .h开发者_开发百科 file.

I've collect all the .h file and grep all the files with '#using' '#import' and the assembly file itself.

There really is a '#using ' in one of the .h file but not-relevant to the referenced assembly.

And about the linked .lib library files, only one of the .lib file is a side-product of another managed-extension-enabled C++ project, all others are produced by a pure, traditional C++ project. For the managed-extension-enabled C++ project, I checked the output DLL assembly, it did NOT reference to the 2 assembly.

I even try to capture the access of the additional assembly file via sysinternal's filemon and procmon, but the rebuild process does NOT access these file.

I'm very confused about the compile and linking process model of a VC++/CLI project, where the additional assembly reference slipped into the final assembly?

Thanks in advance for any of your help.

I've solved the problem, and I'd like to share some experience:

1. The VC++ compiler can treat the whole project as ManagedExtension enabled, you can set it via Project Properties->General->Common Language Runtime Support.

2. You can also turn it on for individual .cpp file, But in the .vcproj file, the attribute name for whole project is "ManagedExtension" while the attribute for individual .cpp file is "CompileAsManaged"

3. The VC++ compile embed the referenced assembly during the compile time, not link time. So reference to specific version of assembly is embedded in the .obj file. I use cygwin's strings utility to extract the name of the reference assembly

4. .lib file is just an archive of .obj files

5. From linker's point view, there's no difference between native .obj file and .lib file. The metadata of MSIL code is just stored in a section( I guess) as data.

BTW, I've tried to use reflector+reflexi to hack the reference assembly version but this feature cannot work with mixed assembly.