none
une ambiguïté à lever RRS feed

  • Question

  • bonjour,

    J'ai dans le framework de IBPP le message suivant: comment lever cette ambiguïté?

    1>c:\program files\microsoft sdks\windows\v7.0a\include\servprov.h(96): error C2872: 'IServiceProvider' : symbole ambigu
    1>          est peut-être 'c:\program files\microsoft sdks\windows\v7.0a\include\servprov.h(53) : System::IServiceProvider IServiceProvider'
    1>          ou       'c:\program files\reference assemblies\microsoft\framework\.netframework\v4.0\mscorlib.dll : System::IServiceProvider'

    J'ai recherché sur msdn et j'ai trouvé:

    using namespace System;
    using namespace Microsoft::VisualC

    Mais ça a empiré les choses

    et j'ai essayé de mettre le fichier mscorlib.dll dans la configuration sans que ça change quelque chose.

    Finalement la question à poser est quel sont les préconditions (includes et namespace ou directive par exemple) a mettre en place la priorité à mscorlib.dll.

    Il faut remarqué que la compilation et l'édition de lien de IBPP marche bien sur un projet test avec les mêmes options clr et path mais avec seulement form1 et test et all_in_one.cpp. Ce n'est pas répétable et je n'ai pas encore identifier le moyen de l'éviter. Je n'ai réussi ca qu'une seul fois et j'ai crée des projets test nombreux sans le répéter à nouveau.

    Il faut absolument avoir un précondition à ce problème. il faut dire au compilateur qu'on choisi mscorlib.dll. J'ai mis mscorlib dans les choix de composants mais ça n'a rien changé. Il faut probablement avoir un mot clef pour pouvoir dire #define XXX = mscorlib.dll


    Jean Noël Martin











    • Modifié JeanNoel53 mercredi 19 septembre 2012 15:17
    mardi 18 septembre 2012 08:53

Réponses

  • Cette ambigüité doit être absolument levée. J'ai trouvé une tournure bestial qui a été de

    1° détruire le fichier servprov.h

    2° détruire le fichier urlmon.h

    3 mise en commentaire d'une référence dans le fichier ObjBase.h

    Moyennant cette modification du framework de base ça passe bien.


    Jean Noël Martin


    • Modifié JeanNoel53 mercredi 19 septembre 2012 15:53
    • Marqué comme réponse JeanNoel53 mercredi 19 septembre 2012 15:53
    mercredi 19 septembre 2012 13:28

Toutes les réponses

  • Cette ambigüité doit être absolument levée. J'ai trouvé une tournure bestial qui a été de

    1° détruire le fichier servprov.h

    2° détruire le fichier urlmon.h

    3 mise en commentaire d'une référence dans le fichier ObjBase.h

    Moyennant cette modification du framework de base ça passe bien.


    Jean Noël Martin


    • Modifié JeanNoel53 mercredi 19 septembre 2012 15:53
    • Marqué comme réponse JeanNoel53 mercredi 19 septembre 2012 15:53
    mercredi 19 septembre 2012 13:28
  • Etes-vous sur qu'il n'existe pas de constantes de compilation qui permettent de ne pas inclure les .h non compatible avec le type du projet.

    Si vous êtres perdu avec ces constantes, utilisez l'option /P sur les cpp qui posent problème.

    C'est le genre de problème qui se résout facilement en utilisant correctement les variables d'environnement, voir en modifiant l'ordre des includes.

    http://msdn.microsoft.com/fr-fr/library/8z9z0bx6(v=vs.80).aspx

    En plus, je ne vois pas comment se justifie l'utilisation de ces deux définitions en même temps, à moins de l'utilisation d'un StdAfx fourretout dans un projet monolithique peu maintenable.


    Paul Bacelar, Ex - MVP VC++

    mercredi 19 septembre 2012 18:56
    Modérateur