Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / .NET Framework / CLR / January 2007

Tip: Looking for answers? Try searching our database.

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

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
phnimx - 05 Jan 2007 00:34 GMT
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] - 05 Jan 2007 02:26 GMT
Hi Phnimx,

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.
Ben Voigt - 05 Jan 2007 15:49 GMT
> Hi Phnimx,
>
> 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

This is a good reason to absolutely forbid use of "using namespace" at file
scope in any header file.

I no longer have any recognizable wizard-generated code in any of my C++/CLI
files, but the few "using namespace System;" I do have are inside my own
namespace ProjectName {} blocks.
Jeffrey Tan[MSFT] - 08 Jan 2007 03:19 GMT
Yep, thanks for your sharing.

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.

Rate this thread:







Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.