J'utilise la fenêtre Immediate de la VS Detkuggers 'pour appeler une API statique sur une classe qui est un type ambigu défini dans 2 assemblages différents.
L'appel échoue avec le message suivant:
Le type Ce message a du sens puisque c'est bien le cas. Ma question est de savoir comment puis-je contourner cela dans le débogueur pour spécifier quelle assemblée je veux être utilisée pour lier ce type?
Y a-t-il un moyen de qualifier un type avec le nom de l'assemblage qu'il est défini?
merci
Bhavin. foo existe dans les deux bla.dll et bar.dll
3 Réponses :
On dirait que vous avez deux types qui ont le même nom et l'espace de noms, mais vivent dans des assemblées différentes? Si tel est le cas, malheureusement, il n'ya aucun moyen de désambigucher cet appel dans la fenêtre immédiate. La fenêtre immédiate considère que ces deux types d'une portée et car le nom de l'assemblage ne peut pas faire partie de la syntaxe de casse en C # ou VB.NET, il n'y a aucun moyen de désambiguez ces types.
La seule option que vous avez consiste à créer une API alternative uniquement de débogage qui se lie à l'un ou à l'autre. Appelez-le ensuite pendant la session de débogage.
Est-ce que la même chose s'applique à la fenêtre de la montre (dans VS2010)? J'ai trouvé cette réponse à la vôtre tout en recherchant plus d'informations sur Cette question , et ça sonne comme si les deux situations sont comparables.
@shambulateur Oui La même chose s'applique à la fenêtre de la montre. La montre, immédiatement, les locaux et même la survolte sont toutes des vues sur le même moteur de données sous-jacent. Si on ne peut pas différencier, les autres ne peuvent pas non plus
@JaredPpar vs2012 gère-t-il mieux cela? Par exemple. Il pourrait laisser l'utilisateur choisir une DLL / prioriser une DLL, rechercher le graphique de dépendance à trouver la bonne (à partir du cadre de pile actif), obtenez de l'aide du compilateur sur lequel DLL aurait été utilisé dans le code ....
@joHv aussi loin que je sais qu'il n'y a pas de changement dans VS2012 ici.
Même comportement dans VS2013 aussi.
Non même l'utilisation de la réflexion pour obtenir une poignée sur le bon type / méthode?
Comme l'indique Maslow, il est possible d'utiliser la réflexion pour obtenir ce que vous voulez. Ce n'est pas jolie, cependant. Par exemple, si vous souhaitez voir la valeur de la propriété statique dans cet exemple, Il est également possible d'appeler des méthodes, etc. à l'aide des outils appropriés à partir de l'espace nominal Espace de noms. < / p> mon.properties.settings.default , alors en supposant que mainwindow est un autre type dans l'assembly (par exemple, < Code> bla.dll ) contenant la valeur que vous souhaitez déboguer, cette expression vous obtiendra la valeur: my.properties.Settings est un type qui est défini dans deux assemblys différents.
Si vous ne pouvez pas vivre avec une solution par JaredPar Vous voudrez peut-être jeter un coup d'œil à cela afin de la question: Comment désambiguez le type dans la fenêtre de surveillance lorsqu'il y a deux types avec le même nom < P> Cette approche peut également être prise pour une fenêtre immédiate Exemple: < / p> Créer consoleApplication1
Ajouter ClassLibrary2 comme référence à ConsoleApplication1 et modifiez les alias de propriété de Global à Myalias2
Ajouter ClassLibrary3 comme référence à ConsoleApplication1 et modifiez les alias de propriété de Global vers Myalias3
programme.cs: classlibrary2 / class1.cs: classlibrary3 / classe1 .cs: testé dans VS2015 Edition communautaire
sont-ils dans la même espace de noms? Habituellement, différents assemblages utilisent des espaces de noms différents?
Ils sont dans la même espace de noms. C'est malheureux et je ne peux pas changer ces assemblées. De plus, le code de l'API est exactement le même, donc cela n'a pas d'importance que le débogueur choisit - je veux juste qu'il utilise quelqu'un mais je ne peux pas sembler le faire fonctionner.