Discussion :

[r0d]

Bonjour � tous,

Je travaille sur une dll en C++/CLI, et j'ai exactement le m�me probl�me que l'initiateur de ce post: http://www.developpez.net/forums/arc.../t-233797.html
A savoir, des erreurs concernant des appels ambigus � IServerProvider.
Cependant, la solution propos�e (utiliser #define WIN32_LEAN_AND_MEAN) dans le post ci-dessus ne fonctionne pas dans mon cas, pour la simple et bonne raison que je n'inclus pas windows.h. Je devine que cet en-t�te doit �tre inclus par les dlls que j'utilise dans la mienne, mais je n'y ai pas acc�s (j'ai juste les dlls et les libs compil�s, pas les sources).

Quelqu'un a une id�e de la fa�on dont je pourrais r�soudre ce probl�me?

[nico-pyright(c)]

Salut Rod,

tu peux pr�ciser explicitement le namespace que tu utilises, pour �viter que le compilateur ne sache pas quel IServerProvider utiliser. Concr�tement, cela revient � enlever tous les using des .h pour les mettre dans les .cpp.

[r0d]

Merci Nico

Alors en fait, cet exemple nous montre une fois de plus qu'il faut manipuler les namespace avec la plus grande prudence. A mon avis, il est pr�f�rable d'�viter les using le plus possible. Car pour ce probl�me-ci, je l'ai r�solu en supprimant totalement mes using namespace et en sp�cifiant explicitement, � chaque utilisation d'un objet du framework, � quel espace de nommage il appartient. Par exemple: System::String ^ toto.

Seeya.

[M�dinoc]

Le plus "normal" � faire, pour moi, c'est:

1. Virer les using namespace (particuli�rement System, puisque c'est lui qui contient IServiceProvider) dans les headers.
2. Si tu es en WinForms et que �a te fait suer de mettre le namespace tout le temps, d�placer les impl�mentations des fonctions concern�es du header vers le source.
3. Dans le source, inclure <windows.h> avant les using namespace.

Encore que normalement, si tu inclus simplement <windows.h> avant tous les autres headers, �a devrait aussi marcher...