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.
