Is ambiguous in the namespace
Résolu
Signaler
cs_Triceratop
cs_Triceratop
- Messages postés
- 5
- Date d'inscription
- vendredi 16 janvier 2009
- Statut
- Membre
- Dernière intervention
- 19 janvier 2009
cs_Triceratop
- Messages postés
- 5
- Date d'inscription
- vendredi 16 janvier 2009
- Statut
- Membre
- Dernière intervention
- 19 janvier 2009
A voir également:
- Vb.net namespace
- Basic will - Meilleures réponses
- No enclosing instance of type is in scope - Meilleures réponses
- What is makefile in linux - Conseils pratiques - C / C++ / C++.NET
- What is actionlistener in java - Conseils pratiques - Java
- What is bytecode in java - Conseils pratiques - Java
- What is byval in vba - Conseils pratiques - Visual Basic / VB.NET
- What is doevents in vba - Conseils pratiques - Visual Basic / VB.NET
4 réponses
cs_Triceratop
- Messages postés
- 5
- Date d'inscription
- vendredi 16 janvier 2009
- Statut
- Membre
- Dernière intervention
- 19 janvier 2009
J'ai enfin trouve le pb. J'ai deux references aux meme dll dans mon projet. une en COM et une en .NET. J'ai supprime la .NET et ca marche.
Merci pour ton aide.
Merci pour ton aide.
nhervagault
- Messages postés
- 6063
- Date d'inscription
- dimanche 13 avril 2003
- Statut
- Modérateur
- Dernière intervention
- 15 juillet 2011
Salut,
Tu doit avoir deux classe de meme nom dans deux namespace différents.
Exemple
Mynamespace.Point
System.Drawing.Point
Donc le coompilateur ne soit pas lequel choisir
En général c'est un defaut de conception
si tu utilises des lib externes ca peut arriver
Les solutions
Mettre les noms complets dans le code pour enlever les ambiguités.
Il est possible de mettre des alias sur les imports
exemple
Imports STR= Microsoft.VisualBasic.Strings
et a l'utilisation tu auras
STR.mafocntion
Esperant avoir été clair et que c'est la bonne réponse ;-)
Tu doit avoir deux classe de meme nom dans deux namespace différents.
Exemple
Mynamespace.Point
System.Drawing.Point
Donc le coompilateur ne soit pas lequel choisir
En général c'est un defaut de conception
si tu utilises des lib externes ca peut arriver
Les solutions
Mettre les noms complets dans le code pour enlever les ambiguités.
Il est possible de mettre des alias sur les imports
exemple
Imports STR= Microsoft.VisualBasic.Strings
et a l'utilisation tu auras
STR.mafocntion
Esperant avoir été clair et que c'est la bonne réponse ;-)
cs_Triceratop
- Messages postés
- 5
- Date d'inscription
- vendredi 16 janvier 2009
- Statut
- Membre
- Dernière intervention
- 19 janvier 2009
Merci pour ta reponse.
les noms sont helas deja complets...
les noms sont helas deja complets...
nhervagault
- Messages postés
- 6063
- Date d'inscription
- dimanche 13 avril 2003
- Statut
- Modérateur
- Dernière intervention
- 15 juillet 2011
Mais les lignes de codes qui sont soulignés.
http://msdn.microsoft.com/en-us/library/8f0k13d2.aspx
Je ne comprends pas sinon l'erreur.
Les noms vers les classes sont bien la version longue
system.toto.maclasse (pour les variables ambigues)
Arrives-tu a les identifier
http://msdn.microsoft.com/en-us/library/8f0k13d2.aspx
Je ne comprends pas sinon l'erreur.
Les noms vers les classes sont bien la version longue
system.toto.maclasse (pour les variables ambigues)
Arrives-tu a les identifier