10
votes

L'appel d'accès membre ne compile pas mais l'appel statique fait

Donc, aujourd'hui, j'ai fait face à un problème intéressant tout en essayant de construire notre solution d'entreprise et je voulais vous demander que vous savez pourquoi cela se produit. On m'a dit que cela pourrait être de ma machine / mon studio visuel parce que d'autres personnes n'avaient pas le même problème.

Nous avons donc une méthode dans le projet A code>: p>

public static string GetAttribute(this XElement node, string name)
{
   var xa = node.Attribute(name);
   return xa != null ? xa.Value : "";
}


9 commentaires

Vous référencez-vous l'assemblage contenant xelement? Cuz Son vous dit c'est le problème; Aucun nom de méthode mentionné. Je veux dire avez-vous essayé d'ajouter System.xml.Linq?


Oui, j'ai essayé cela réellement résoudre le problème, mais comme je l'ai dit, nous avons trouvé la solution de cela, mais le comportement étrange reste et j'ai été curieux. Plus Ajout de référence à system.xml.linq il résout le problème, mais il est étrange que le compilateur soit confondu avant cette cause, il est évident que je ne l'utilise pas) que je n'utilise pas des xelements.


Mais vous faites dans le projet B?


Non, j'ai ajouté la référence dans le projet A. Le projet B bâti était sans problème.


Ah. Intéressant. Modification de ce que vous m'avez dit dans ces commentaires sur la question clarifierait grandement pour les autres


Je ne suis pas sûr, mais si vous le dites ... ce n'est pas comme si je demande une solution de l'erreur plutôt que de demander une explication du comportement étrange. Qu'est-ce qui compte comment je l'ai résolu exactement?


??? Cela pourrait susciter des idées de mémoire. Je le vois comme potentiellement utile; Vous ne faites pas. C'est ta question.


Stackoverflow.com/a/35940354/17034


Merci Man, c'était exactement ce qui se passait.


3 Réponses :


0
votes

Je suppose que ça se passe:
- B a référence à système.xml.linq
- B est construit sans problème.
- Vous vous référez à B dans A
- A n'a pas eu de référence à système.xml.linq
- un semble consommer la fonction définie en b
- Lorsque vous essayez de créer un projet A, il produit cette erreur

Ai-je raison?

Si c'est le cas, il est totalement normal. Parce qu'un projet qui consomme une référence (a) doit avoir une référence à ce qui est référencé (System.XML.LINQ) par ce qu'il références (b).

pense comme ceci: lorsque vous essayez d'ajouter un package Nuget à votre projet s'il a une dépendance, Nuget l'installera aussi. Pourquoi? À cause de cette situation.

Ceci est complètement normal si je comprends votre réponse correctement.


5 commentaires

La question était la question de savoir pourquoi le compilateur est confus qu'il utilisera une fonction dans le projet B lorsque la navigation de Visual Studio sait clairement lequel est la bonne méthode (celle du projet A)? Lorsque vous répondez à cette réponse, vous trouverez une réponse à la réponse d'origine de la réponse au moins c'est comme ça que je l'ai eu. Consultez le lien dans les commentaires ci-dessous ma question, c'est à peu près répondre à tout ce que je demande et qui me demandent.


hahaha! Désolé pour mon anglais pauvre (à la fois pour ma réponse et ma confusion). Vous avez eu raison de faire ça :-)


Au fait, quelle version de VS utilisez-vous?


Avez-vous les deux espaces de noms versions à l'aide de Block? Avez-vous essayé d'appeler la méthode en fournissant tout le chemin? (ex :.reflectionhelpers.getTribute)


Oui, j'ai corrigé la confusion du compilateur avec la fourniture de tout le chemin (A.K.A l'appelant statiquement.) La question concerne la confusion et non la façon de le résoudre.



1
votes

C'est une supposition, mais je pense que votre fonction:

String Statique privé RPCroutingKeyNamingConvention (type MessageType, iTypenamesAmizeryMaMaSerializer) Ne correspond pas à la signature de votre méthode d'assistance, car vous essayez de retourner une chaîne:

Tattribute statique public getattribute (ce type de type) où tattribute: attribut; qui attend un type de retour tattribute.

Peut-être que vous pouvez essayer de modifier votre fonction RPCroutingKeyNamingConvention pour renvoyer globalrpcrequest et vérifier si le compilateur continue de devenir fou.


2 commentaires

ne correspond pas à la signature de votre méthode d'assistance car vous essayez de retourner une chaîne: Que voulez-vous dire que cela ne correspond pas à ma méthode d'assistance parce que j'essaie de retourner une chaîne .. C'est scandaleux à l'état?


@Yann Ranaudin Il n'essaie pas de retourner une chaîne, regardez ? QueueName: QueueName + "_" + DisponibilitéZone;



1
votes

Visual Studio est confondu tout le temps! J'ai essayé de reproduire le scénario de mon VS 2015 (.NET 4.6) et cela compile tout simplement bien. Je n'ai pas eu à ajouter de la référence à System.xml.Linq dans mon projet A.

Je suppose que cela pourrait être une question de cache. Vous voudrez peut-être essayer ceci:

  1. Supprimer Référence au projet B
  2. propre alors reconstruit les deux solutions
  3. Ajoutez la référence Retour
  4. Reconstruisez et voila !! Bien .. espérons

    J'espère que cela aide, laissez-moi savoir :)


0 commentaires