C2872 IServiceProvider ambiguous symbol - migrating C++/MFC App with /clr to Visual Studio 2005

[phnimx]

I'm attempting to migrate a predominately MFC application that I've just
inherited from
Visual Studio.NET 2003 to Visual Studio 2005. I've managed to clean up a
myriad of compile and link errors but I'm stuck on one final problem.
Please note that this application compiled/linked and ran just fine out of
Visual Studio.NET 2003.


Details:
It's originally incarnated as an MFC app, i.e. CWinApp, CMultiDocTemplate,
CDocument, etc.
Today however, it's still an MFC app but it's got sections of Managed C++
Code all over the place.



Obstacle:
At compile time Visual Studio 2005 reports the following error:


c:\program files\microsoft visual studio 8\vc\include\comdefsp.h(1041) :
error C2872: 'IServiceProvider' : ambiguous symbol

could be 'c:\program files\microsoft visual studio
8\vc\platformsdk\include\servprov.h(100) : IServiceProvider'

or 'c:\windows\microsoft.net\framework\v2.0.50727\mscorlib.dll :
System::IServiceProvider'


Problem:
I've scoured the code including generating precompiled files, to determine
where IServiceProvider is actually used. It turns out NOWHERE. At least not
directly.
The Managed C++ Code parts are just a few minor Winforms. The Winforms
acquire functionality from other library assemblies external to this MFC
app. Not relevant.
I'm guessing at this point that mscorlib.dll::System::IServiceProvider in
not actually used by this MFC app.
However the COM Interface IServiceProvider may indeed be used since we do
some measure of CoCreateInstance().. to use MSXML4.DLL.


Questions:

1) Does anyone have any idea how to get passed this latest compiler
complaint?

2) Is there a way to exclude both the COM Interface IServiceProvider and
System::IServiceProvider?

3) Is or are there techniques for acquiring more build information at
compile time other than /VERBOSE and /P compiler switches?

Thanks in advance

 

[Jeffrey Tan[MSFT]]

Hi Phnimx,

Yes, this newsgroup is more suitable for this question than CLR newsgroup,
although I have also provided a reply to you in the CLR newsgroup . I
paste my reply below for your information:

"This is a common problem in managed C++ by mixing unamanged and managed
code. The key point is that some header file includes "using namespace
System;" statement which makes names from the System namespace accessible
to the entire program. However, windows.h indirectly contains #include
servprov.h, which has the following declaration:
"typedef interface IServiceProvider IServiceProvider;"

The IServiceProvider becomes an ambiguous symbol.

The link below talks about this problem in details:
"Managed Extensions for C++ Migration Guide--Ambiguous References"
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vcmxspec/ht
ml/vcmg_ambiguousreferences.asp

You may follow the resolution in the link to move "#include <windows.h>" to
the top.

MFC application may use some more complex header files including, in which
case you do not use any IServiceProvider directly in code. If the the
resolution in the link does not work for you, you may try to find "using
namespace system" in MCDll.h and move it below the #includes in MCDll.h.
This should fix the problem.

Please feel free to let me know the result. Thanks."

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[phnimx]

Hi Jeffrey,
Infinite thanks for yet another excellent response.
I followed your instructions and they seem to have solved the compile
problem. So now I've gotten passed the compile stage.
Unfortunately, the link stage has failed with the following errors:

Merging metadata
MainFrm.obj : error LNK2022: metadata operation failed (8013118D) :
Inconsistent layout information in duplicated types (_PROPSHEETPAGEA):
(0x020000f1).
MainFrm.obj : error LNK2022: metadata operation failed (8013118D) :
Inconsistent layout information in duplicated types (_PROPSHEETPAGEW):
(0x020000f4).
MainFrm.obj : error LNK2022: metadata operation failed (8013118D) :
Inconsistent layout information in duplicated types (tagTOOLINFOA):
(0x020001f1).
Finished merging metadata


I am at a complete loss here. I have no idea what to do. I follows the
LNK2022 suggestion and (ildasm -tokens).
I am at a loss as to what to look for in the results of (ildasm -tokens).
These structures (PROPSHEETPAGEA, PROPSHEETPAGEW) are actually single/double
byte #ifdef(s) in Win32 and we don't use them directly. We use
the MFC classes instead, CPropertySheet, CPropertyPage, etc..... I don't
understand why the linker complains about the ansi TOOLINFO and not the wide
one?
Again, we don't user this struct directly we use the MFC class instead.
When errors like this appear, do you have a check list of things to do that
will reveal why the linker complains?
If so may I have that list?
Can you please help with this newest problem?
Thank you,
Phnimx.

Hi Phnimx,

Yes, this newsgroup is more suitable for this question than CLR newsgroup,
although I have also provided a reply to you in the CLR newsgroup . I
paste my reply below for your information:

"This is a common problem in managed C++ by mixing unamanged and managed
code. The key point is that some header file includes "using namespace
System;" statement which makes names from the System namespace accessible
to the entire program. However, windows.h indirectly contains #include
servprov.h, which has the following declaration:
"typedef interface IServiceProvider IServiceProvider;"

The IServiceProvider becomes an ambiguous symbol.

The link below talks about this problem in details:
"Managed Extensions for C++ Migration Guide--Ambiguous References"
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vcmxspec/ht
ml/vcmg_ambiguousreferences.asp

You may follow the resolution in the link to move "#include <windows.h>"
to
the top.

MFC application may use some more complex header files including, in which
case you do not use any IServiceProvider directly in code. If the the
resolution in the link does not work for you, you may try to find "using
namespace system" in MCDll.h and move it below the #includes in MCDll.h.
This should fix the problem.

Please feel free to let me know the result. Thanks."

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no
rights.

 

[Jeffrey Tan[MSFT]]

Hi Phnimx,

You are welcome.

Based on my research, there may be several causes to this LNK2022 error.
One is caused by using anonymous structures in Managed C++:
"FIX: Error LNK2022: Metadata Operation Failed (8013118D)"
http://support.microsoft.com/default.aspx/kb/324088

If you did not use anonymous structures in your application, this KB is not
related.

Another more possible cause is the inconsistent _WIN32_IE & _WIN32_WINNT
definitions which causes inconsistent _PROPSHEETPAGEA structure size and
layout during link-time.

To resolve this issue you may try to add the following statement in
stdafx.h, which re-defines _WIN32_IE and _WIN32_WINNT:

#if (_WIN32_IE <0x0400)
#define _WIN32_IE 0x0401
#endif

#if (_WIN32_WINNT < 0x0500)
#define _WIN32_WINNT 0x0500
#endif

This ensures a compatible definition and I hope you are able to link the
application successfully.

The 3rd possibility is the windows.h header file alignment incompatible, if
you have the following setting:
Under Configuration Properties->C/C++->Code Generation->set Struct Member
Alignment: 1 Byte (/Zp1)

Since windows.h header files require 8 packing, you need to force the
compiler to do this. You may wrap your Windows.h header file with #pragma
pack(8):

#pragma pack(8)
#include <windows.h>
#pragma pack()

The link below speaks more about pragma directives:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclang/html
/_predir_pragma_directives.asp

Hope this helps.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Jeffrey Tan[MSFT]]

Hi Phnimx,

How about this LNK2022 error now? Have you reviewed my last reply to you?
Does it make sense to you?

If you still need any help or have any concern, please feel free to tell
me, thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[phnimx]

Hi Jeffrey,
I have successfully completed the migration process!
The help I received from you (specifically) was instrumental in the success
of the migration.
The experiences I have had with you with regard to ALL of the problems I
have brought to you, have been the best experiences EVER on the MSDN
Newgroups!
YOU SIR ARE #1 IN MY BOOK!
If we ever meet, I'm buying you whatever (breakfast/lunch/dinner) you like.
I very much appreciate your help. Keep up the amazing work.
Best regards,
Phnimx

 

[Jeffrey Tan[MSFT]]

Hi Phnimx,

Thanks for confirming the status!

I am also glad to work you such a nice customer. If you need further help,
please feel free to post, thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.