Solve : C++ question regarding #import and Microsoft logic?

1.	Solve : C++ question regarding #import and Microsoft logic?
Answer» Hey people... I have a C++ project that contains a stdafx.h file which tries to import a TLB (we'll call it MYFAVLibrary.tlb). When I go to compile the project I get an error on the line Code: [Select]#import "MYFAVLibrary.tlb" raw_interfaces_only, raw_native_types, no_namespace, named_guids The error is Code: [Select]error C4772: #import referenced a type from a missing type library; '__missing_type__' used as a placeholder I have tracked down which types were replaced with '__missing_type__' and they are IXMLDOMDocument, IXMLDOMNodeList, and IXMLDOMnode. These types are defined in the msxml.h header file derived from msxml3.dll. The header file is listed in the external DEPENDENCIES for the project and if I try to add one of those types in the code it is recognized so I am not sure why they are not being seen when #import tries to build the TLH file. Microsoft states the following about error C4772: Quote Note that the compiler will not find type libraries in different directories if you use the /I (Additional INCLUDE Directories) compiler option to specify those directories. If you want the compiler to find type libraries in different directories, add those directories to the PATH environment variable. My project does use the Additional Include Directories switch which could have something to do with this. However, msxml3.dll lives in C:\Windows\System32 which is part of the path so I am not sure why this wouldn't be working. Anybody have any experience with this situation? Thanks!I couldn't say if it was the CAUSE of the problem, but using MSXML from C++ usually means using the MSXML SDK; this SDK includes header files for you. if I understand correctly you used the "import" functionality to create the header file you are using now. It might help to use the "actual" header files, though I don't know that for sure. Hey BC_Programmer... Good to talk to you again. I guess saying the header file was derived from the dll is a poor choice of words on my part. Actually, the header file is part of the Microsoft Windows SDK which is indeed installed on my system. But the types are also found in the msxml dlls. Sorry about that. The code Code: [Select]#import "MYFAVLibrary.tlb" raw_interfaces_only, raw_native_types, no_namespace, named_guids will write out a MYFAVLibrary.tlh file that requires the types from MSXML. Somehow, I am missing where that reference needs to come from. The quoted text that I took from Microsofts website confuses me a little bit. So if you specify additional include directories, the compiler can't search them... That is how I read that and it seems counterproductive. But, the header file from the SDK is recognized in the project and the dll lives inside a directory found in the PATH environment variable. Hmm...I wonder if maybe MSXML might refer to other types, say from olelib? (I'm just guessing here, never really used COM & C/C++)Quote from: BC_Programmer on June 22, 2012, 09:32:40 AM I wonder if maybe MSXML might refer to other types, say from olelib? (I'm just guessing here, never really used COM & C/C++) I really don't know. I guess that would be a possibility but there are plenty of OLE headers being passed in as external dependencies as well, and from the same Windows SDK. The main problem is that I inherited this project so I don't FULLY understand all of it's intricacies. The people that gave it to me can build it just fine in a WinXP environment using the same compiler I am using (VS2010). I don't see how the OS (mine being Win7) would be what makes a DIFFERENCE. A different compiler, yea, maybe so. I have got to be missing something, either a library altogether or how something is referenced... Thanks.well, the only thing I can figure is maybe the DLL (MSXML3.dll) differs enough from the XP version that it won't compile with the same code- a source level incompatibility preventing things from linking properly (I'm not sure but I think there is some sort of linking taking place in the guts of a #import). Also, possibly dumb question: the XML include is before the #import for the external library?

Answer»

Hey people...

I have a C++ project that contains a stdafx.h file which tries to import a TLB (we'll call it MYFAVLibrary.tlb). When I go to compile the project I get an error on the line

Code: [Select]#import "MYFAVLibrary.tlb" raw_interfaces_only, raw_native_types, no_namespace, named_guids

The error is

Code: [Select]error C4772: #import referenced a type from a missing type library; '__missing_type__' used as a placeholder

I have tracked down which types were replaced with '__missing_type__' and they are IXMLDOMDocument, IXMLDOMNodeList, and IXMLDOMnode. These types are defined in the msxml.h header file derived from msxml3.dll. The header file is listed in the external DEPENDENCIES for the project and if I try to add one of those types in the code it is recognized so I am not sure why they are not being seen when #import tries to build the TLH file.

Microsoft states the following about error C4772:

Quote

Note that the compiler will not find type libraries in different directories if you use the /I (Additional INCLUDE Directories) compiler option to specify those directories. If you want the compiler to find type libraries in different directories, add those directories to the PATH environment variable.

My project does use the Additional Include Directories switch which could have something to do with this. However, msxml3.dll lives in C:\Windows\System32 which is part of the path so I am not sure why this wouldn't be working. Anybody have any experience with this situation?

Thanks!I couldn't say if it was the CAUSE of the problem, but using MSXML from C++ usually means using the MSXML SDK; this SDK includes header files for you. if I understand correctly you used the "import" functionality to create the header file you are using now. It might help to use the "actual" header files, though I don't know that for sure.

Hey BC_Programmer... Good to talk to you again. I guess saying the header file was derived from the dll is a poor choice of words on my part. Actually, the header file is part of the Microsoft Windows SDK which is indeed installed on my system. But the types are also found in the msxml dlls. Sorry about that.

The code

Code: [Select]#import "MYFAVLibrary.tlb" raw_interfaces_only, raw_native_types, no_namespace, named_guids

will write out a MYFAVLibrary.tlh file that requires the types from MSXML. Somehow, I am missing where that reference needs to come from. The quoted text that I took from Microsofts website confuses me a little bit. So if you specify additional include directories, the compiler can't search them... That is how I read that and it seems counterproductive. But, the header file from the SDK is recognized in the project and the dll lives inside a directory found in the PATH environment variable. Hmm...I wonder if maybe MSXML might refer to other types, say from olelib? (I'm just guessing here, never really used COM & C/C++)Quote from: BC_Programmer on June 22, 2012, 09:32:40 AM

I wonder if maybe MSXML might refer to other types, say from olelib? (I'm just guessing here, never really used COM & C/C++)

I really don't know. I guess that would be a possibility but there are plenty of OLE headers being passed in as external dependencies as well, and from the same Windows SDK. The main problem is that I inherited this project so I don't FULLY understand all of it's intricacies. The people that gave it to me can build it just fine in a WinXP environment using the same compiler I am using (VS2010). I don't see how the OS (mine being Win7) would be what makes a DIFFERENCE. A different compiler, yea, maybe so. I have got to be missing something, either a library altogether or how something is referenced...

Thanks.well, the only thing I can figure is maybe the DLL (MSXML3.dll) differs enough from the XP version that it won't compile with the same code- a source level incompatibility preventing things from linking properly (I'm not sure but I think there is some sort of linking taking place in the guts of a #import).

Also, possibly dumb question: the XML include is before the #import for the external library?

Solve : C++ question regarding #import and Microsoft logic?

Discussion

No Comment Found

Related InterviewSolutions

Reply to Comment