none
une linge de directive du preprocesseur conduit à un message d'erreur sur lequel je ne peux rien faire RRS feed

  • Question

  • bonjour

    J'ai un message d'erreur qui se produit dans un fichier qui compilait bien  sur un autre applicatif et que j'ai introduit dans un autre applicatif.

    Je vous met la directive et le message

    #import "C:\Program Files\Fichiers Communs\System\ADO\msado15.dll" \
    no_namespace rename("EOF", "EndOfFile")

    et le message d’erreur:

    1>e:\program files\microsoft visual studio 10.0\vc\include\comdefsp.h(1041): error C2872: 'IServiceProvider' : symbole ambigu
    1>          est peut-être 'c:\program files\microsoft sdks\windows\v7.0a\include\servprov.h(103) : IServiceProvider'
    1>          ou       'c:\program files\reference assemblies\microsoft\framework\.netframework\v4.0\mscorlib.dll : System::IServiceProvider'
    1>e:\program files\microsoft visual studio 10.0\vc\include\comdefsp.h(1041): error C2872: 'IServiceProvider' : symbole ambigu
    1>          est peut-être 'c:\program files\microsoft sdks\windows\v7.0a\include\servprov.h(103) : IServiceProvider'
    1>          ou       'c:\program files\reference assemblies\microsoft\framework\.netframework\v4.0\mscorlib.dll : System::IServiceProvider'
    

    Que signifie cette erreur et comment la traiter?


    Jean Noël Martin

    lundi 7 avril 2014 02:54

Réponses

Toutes les réponses

  • Le message est assez explicite, dans comdefsp.h, on utilise l'interface de nom "IServiceProvider" mais le compilateur dispose de deux définitions de cette interface dans 2 namespaces différents mais que des using peu judicieux font remonter dans l'espace sans nom.

    Il y a une définition de cette interface dans serprov.h et une définition dans l'assembly mscorlib.dll.

    Vous pouvez toujours faire des acrobaties avec les namespaces, mais quel est l'intérêt d'utiliser des composants COM d'accès aux données qui ne sont plus maintenus depuis 15 ans dans un programme utilisant le framework .NET disposant d'assemblies d'accès aux données largement supérieurs que sont ADO.NET ou Entity Framework ???


    Paul Bacelar, Ex - MVP VC++


    lundi 7 avril 2014 09:11
    Modérateur
  • je vous met les using pour avoir plus d'exlications

            using namespace System;
    	using namespace System::ComponentModel;
    	using namespace System::Collections;
    	using namespace System::Configuration;
    	using namespace System::Windows::Forms;
    	using namespace System::Data;
    	using namespace System::Drawing;
    	using namespace System::IO;
    	using namespace System::Data::Sql;
    	using namespace System::Data::SqlClient;
    	using namespace System::Runtime::InteropServices;
    	using namespace msclr::interop;
    je comprend qu'il y en a peut être trop mais je ne sais pas faire le tri. Notamment je ne sais pas ce qui vient de COM(pas utilisé) ce qui vient de ADO.NET et de ce qui vent de .NET


    Jean Noël Martin

    lundi 7 avril 2014 15:36
  • OK, vous faites un projet gloubi-boulga, il n'y a que Casimir qui les digèrent.

    Tout ce qui est dans System::Data fait partie d'ADO.NET, donc arrêtez d'utiliser ces cochonneries de MDAC du siècle dernier et utilisez pleinement et correctement ADO.NET.

    ADO.NET fonctionne parfaitement avec tous les autres assemblies .NET.

    Le problème n'est pas le nombre de using mais le mélange de technologies qui ne sont pas faites pour travailler ensemble, MDAC et .NET, surtout quand on y connait rien.

    Quand vous faire #import, vous importez la tlb (les types) des composants COM hébergés dans la dll.

    Avec le "no_namespace" que vous avez copié sans le comprendre (http://msdn.microsoft.com/fr-fr/library/ze72hya7.aspx) vous avez injecté dans l'espace sans nom l'ensemble des types définis dans la dll, bien joué.

    A moins d'accéder à une source de données qui ne dispose pas de connecteur .NET mais de connecteur MDAC, il n'y a aucune justification à utiliser ces tromblons dans un projet .NET, à par se compliquer la vie inutilement.

    Donc, par pitié, utilisez ADO.NET et laissez MDAC dans son cercueil.


    Paul Bacelar, Ex - MVP VC++

    lundi 7 avril 2014 17:13
    Modérateur
  • J'ai donc supprimé les deux lignes de directives et ça a résolu le problème.

    Jean Noël Martin

    lundi 7 avril 2014 17:49