Je travaille dans un projet Web dans Visual Studio 2008. Lorsque je clique sur F12 (ou clique avec le bouton droit et sélectionne Atteindre la définition), Visual Studio accède systématiquement au fichier de métadonnées au lieu d'aller à la source.

Des points:

• Tout le code source est C #, il n'y a pas de VB.Net
• Tous les projets sont dans la même solution
• Tout est une référence de projet par opposition à une référence de fichier (vérifié et revérifié)
• J'ai essayé l'approche Clean / Rebuild Solution (même au point de vider le répertoire Temp, le répertoire Temporary ASP.NET Files, etc.).

Quelqu'un d'autre a-t-il vu ce comportement et / ou sait-il comment y remédier?

Eh bien, un autre développeur a trouvé la réponse. Le projet spécifique avec lequel nous avons eu un problème a été initialement ajouté en tant que référence de fichier, puis supprimé et ajouté en tant que référence de projet. Cependant, Visual Studio a conservé les deux dans le fichier csproj du site Web, ce qui a provoqué le problème. Il est entré et a modifié manuellement le fichier csproj pour supprimer la référence de fichier au projet problématique et tout est résolu maintenant

Cela se produit lorsque vous n'ajoutez pas de référence en tant que projet mais que vous pointez sur une DLL ou un exe à l'aide de l'onglet Parcourir dans la boîte de dialogue Ajouter une référence. Si vous ajoutez une référence à l'aide de l'onglet Projets, vous devez accéder directement au code source lorsque vous sélectionnez Aller à la définition.

Cependant, si vous installez ReSharper , vous accéderez au code source même si vous avez ajouté votre référence à une dll / exe à l'aide de l'onglet Parcourir.

On dirait qu'il doit également être configuré dans Resharper. Mon Visual Studio ne navigue pas vers le code source .NET Framework tant que je ne l'ai pas activé dans Resharper.

1. fermez votre solution.

2. supprimez le <name of the solution>fichier .suo caché dans le dossier où se trouve le <name of the solution>fichier .sln de votre solution .

3. ouvrez votre solution.

4. reconstruisez votre solution.

Pour ceux qui utilisent VS 2017 (j'en suis à la version 15.3.4 en ce moment), voici les étapes simples:

1. Ouvrez votre solution dans l'Explorateur Windows et fermez Visual Studio
2. Dans le menu de l'explorateur, sélectionnez Afficher et assurez-vous que la case "Éléments cachés" est cochée
3. Accédez au sous-dossier .vs\[your solution name]\v15
4. Supprimer le .suofichier
5. Redémarrez VS et créez votre solution

Cela a résolu le problème pour moi: F12 a ouvert le fichier source réel, pas la version "à partir des métadonnées".

Visual Studio souffre souvent d'un problème d'accès aux métadonnées plutôt qu'à votre projet si vous changez l'emplacement où vous construisez le projet, c'est-à-dire que vous pouvez avoir plusieurs versions pour tester les choses.

Supprimez simplement la référence et rajoutez-la immédiatement et tout sera réglé.

La solution marquée ne fonctionne pas toujours. Vous devez vous assurer que le GUID du projet référencé dans les fichiers de projet est le GUID correct pour le projet que vous essayez de référencer. Visual Studio leur permet de se désynchroniser dans certaines circonstances. Vous pouvez obtenir le GUID du projet à partir du fichier projet avec un éditeur de texte. Donc, si le projet Un projet de référence B. Ouvrez le projet B.csproj dans l'éditeur de texte, copiez le GUID du projet à partir de la balise. Puis ouvrez le projet A.csproj dans l'éditeur de texte et assurez-vous que vous utilisez le GUID correct. Recherchez le nom de projet "B" dans ce cas. Cela devrait être à. Remplacez le GUID de la balise par le bon. Enregistrez et rechargez. Bien sûr, assurez-vous également que les références basées sur des fichiers à vos projets sont supprimées. Vous ne voulez que des références de projet.

J'ai tué toutes les instances VS, supprimé le SUO, lancé sln et cela a fonctionné pour moi ...

Supprimez la dll de référence, Build (obtiendra des erreurs), AJOUTEZ LA référence (que vous avez supprimée) puis construisez à nouveau ... F12 sur votre fonction devrait alors fonctionner (a fonctionné pour moi).

J'ai trouvé comment résoudre mon problème à partir de cet article , peut-être que cela fonctionnera aussi pour certains d'entre vous.

J'ai suivi ces étapes:

1. Fermez la solution.
2. Supprimez le fichier de base de données intellisense de la solution: .ncb
3. Ouvrez la solution.
4. Reconstruisez la solution.

(Je crois que l'étape 3 ou 4 régénère le fichier de base de données intellisense lorsqu'il est manquant)

Intellisense, "aller à la définition" et "trouver toutes les références" devraient fonctionner à nouveau.

Dans mon cas, (en utilisant Visual Studio Professional 2015), lorsque j'ai désactivé le concepteur XAML, le F12 a cessé de fonctionner. Dès que j'ai annulé les modifications et redémarré Visual Studio, le F12 a fonctionné à nouveau.

Vérifié le modèle plusieurs fois pour confirmer, puis publié. J'espère que ça aide quelqu'un.

Symptôme:

Visual Studio 2010 Ultimate échouait à plusieurs reprises à trouver des références à des fonctions, #defines, includes, etc. lors de l'utilisation des fonctionnalités «Aller à la définition» ou «Aller à la déclaration» ou «Rechercher toutes les références» - curieusement Intellisense fonctionnait.

Réparer:

1. Fermer Visual Studio
2. Supprimez (renommez si vous voulez être prudent) le fichier .sdf de la solution
3. Rouvrir Visual Studio

Le fichier .sdf sera automatiquement reconstruit en analysant les fichiers d'inclusion dans votre solution

Pour moi, la solution GUID n'a pas fonctionné et je n'ai pas trouvé mon fichier .ncb. (Ou peut-être que je suis paresseux et que je n'ai pas cherché suffisamment, mais ce n'est pas important.) La reconstruction et le redémarrage de Visual Studio n'ont pas non plus aidé.

Ce que j'ai fait a été de fermer Visual Studio et de supprimer les fichiers .dll et .pdb référencés en haut du fichier Meta Data auquel mon intellisense continuait de se connecter. Dans mon cas, cela signifiait que j'ai supprimé mon .dll et c'est le fichier .pdb de Utilities / bin / Release. (Utilitaires est le nom du projet .dll avec lequel j'avais des problèmes.) Ensuite, j'ai redémarré Visual Studio et reconstruit le .dll, puis toute la solution. Plus de problèmes!

Je viens de trouver une autre cause. J'ai mis à niveau mon projet Web vers la version 4.0, mais j'ai laissé les bibliothèques de classes à la version 2.0. À ce stade, toutes les bibliothèques de classes de ma solution ont été traitées comme des références de fichiers de mon projet Web. Pourrait aider quelqu'un d'autre ...

J'ai rencontré le même problème et l'un de mes collègues m'a donné la solution suivante et cela a fonctionné! Si aucune des solutions ci-dessus ne fonctionne pour vous,

1. Supprimez toutes les références et rajoutez-les (assurez-vous que le chemin est correct)
2. Accédez aux propriétés de la solution et revérifiez les dépendances de projet de tous les projets. Assurez-vous que le projet que vous allez utiliser est ajouté en tant que personne à charge dans le projet sur lequel vous travaillez.

J'ai fait toutes les étapes suggérées mais rien n'a été changé puis
enfin faites un clic droit et ajoutez un menu de référence, onglet projet

1. désélectionne simplement le projet de référence.
2. enregistrez la solution.
3. sélectionnez le même projet.
4. Reconstruisez la solution.

Problème réglé. J'espère que cela aidera quelqu'un.

Les étapes ci-dessous ont fonctionné pour moi.

1. Accédez au fichier .csproj
2. Ouvrez-le dans le Bloc-notes Allez à la ligne où dll est référencé.<Reference Include="">

3. Supprimer la ligne

   <SpecificVersion>False</SpecificVersion> 
   or 
   <SpecificVersion>True</SpecificVersion>
   

Après avoir d'abord supprimé les fichiers dll de Visual Studio et les avoir rajoutés manuellement à partir de l'Explorateur de solutions -> Site Web -> Ajouter -> Référence et avoir activé les applications 32 bits dans IIS, le problème a été résolu pour moi.

#1

Cochez "Affichage - Explorateur d'objets" et si vous voyez plus d'un assemblage avec le même nom - c'est pourquoi vous obtenez cette erreur.

Pour nous, c'était un bug dans VS 2019:

Si vous avez ASP.NET «Razor helpers» dans le App_Codedossier, Visual Studio 2019 interprète cela comme un assembly différent mais avec le même nom, qui masque l'assembly réel.

Il n'y a pas de solution à cela autre que de réécrire ces helpers en vues partielles ou en helpers HTML (vous devrez le faire de toute façon si vous prévoyez de migrer vers .NET Core).

Consultez cette solution de contournement sur le site de MS et veuillez voter pour le bogue afin que MS le corrige

https://developercommunity.visualstudio.com/solutions/1008795/view.html (veuillez voter pour)

# 2

Une autre raison pour laquelle le même assemblage peut être chargé deux fois dans le navigateur d'objets est si vous avez un projet de test unitaire qui démarre le processus iis-express et ne le tue jamais correctement.

1. cliquez sur le menu du site Web de VS.
2. Ajouter une référence ...
3. Cliquez sur l'onglet projet de la boîte de dialogue
4. Sélectionnez ddl
5. Cliquez sur le bouton OK

Dans mon cas, je venais de changer

<mvcBuildViews>

à "true" dans le fichier .csproj de mon site (pour trouver des erreurs de compilation dans mes fichiers de vue Razor: http://forums.asp.net/t/1909113.aspx?How+to+have+Visual+Studio+2012+returned + compiler + erreurs + sur + rasoir + syntaxe + erreur + dans + asp + net + page + web + 2 + ), et quand j'ai ensuite construit, j'obtenais des erreurs dans le répertoire / obj / Debug / de mon site. À partir de n'importe lequel de ces fichiers (qui étaient obsolètes), un clic droit et la sélection "Aller à la définition" me donnerait la version [métadonnées].

Donc pour moi, aucune des solutions ici n'a fonctionné, car je ne partais pas d'un fichier qui était en fait dans mon projet. Supprimé tout ce répertoire / obj / Debug /, les erreurs ont disparu, et à partir de tout fichier normal, je peux utiliser correctement Aller à la définition.

Je viens de rencontrer ce problème sur VS 2013. Quelque chose que je ne pouvais (ne pas?) Isoler était de changer le GUID dans le fichier CSPROJ. Puisque les fichiers CSPROJ sont archivés dans SVN, je ne pouvais pas simplement changer le GUID sur mon dev local. Au lieu de cela, je retournais constamment SVN au changement local à chaque fois que cela se produisait.

Tout d'abord, j'ai dû résoudre le problème de changement de GUID.

1. Rétablissez le CSPROJ à la version enregistrée.
2. Ouvrez le CSPROJ via un éditeur de texte, PAS VS.

3. Extraire la valeur du fichier CSPROJ vierge.

   {B1234567-5123-4AAE-FE43-8465767788ED}

4. Ouvrez le fichier SLN via un éditeur de texte, PAS VS.

5. Recherchez la référence de projet dans la solution.

   Project ("{FAE12345-3210-1357-B3EB-00CA4F396F7C}") = "Some.Project", ".... \ assemblies \ Some.Project \ Some.Project.csproj", "{B7654321-5321-4AAE- FE3D-ED20900088ED} "EndProject

6. Le premier GUID répertorié est le GUID de la solution. Pour chaque projet référencé dans votre SLN, vous devriez voir cette valeur répétée au premier argument. Le GUID qui suit le .csproj est celui que vous souhaitez remplacer par le GUID vierge.

Cela devrait résoudre le premier problème, mais l'atterrissage "Aller à la définition" dans les métadonnées n'est pas résolu. Dans notre fichier SLN, il y a un projet principal (notre site Web), donc son entrée dans le fichier SLN doit contenir une entrée ProjectSection avec plusieurs valeurs GUID. Voici un exemple:

ProjectSection(ProjectDependencies) = postProject
{AC50D230-24C4-4DCA-BAAD-355E6AF5EFBD} = {AC50D230-24C4-4DCA-BAAD-355E6AF5EFBD}
EndProjectSection

Notez que le GUID manquant dans cette collection est celui de mon projet vierge.

1. Ajoutez le GUID manquant comme dernière entrée entre ProjectSection et EndProjectSection. Le format semble être par ligne, et c'est {GUID} = {GUID}.
2. Enregistrez le fichier.
3. Ouvrez votre solution.
4. Cliquez avec le bouton droit sur une référence dans le projet nouvellement ajouté et «Aller à la définition».

J'avais une référence circulaire entre les deux projets concernés (ce qui est un non-non). J'ai dû restructurer un peu mon code pour le résoudre car les deux projets étaient vraiment dépendants l'un de l'autre. La suppression d'une des références a résolu le problème d'intellisense. C'était logiquement défectueux et je ne l'aurais probablement pas remarqué sans cette erreur!

Celui-ci a fonctionné pour moi:

1. Cliquez avec le bouton droit sur la dll dans le dossier de référence de votre explorateur de solutions
2. Supprimer le fichier dll
3. Cliquez avec le bouton droit sur le dossier de référence, puis
4. Ajouter à nouveau une référence au fichier dll

Cela peut se produire si vous essayez d'accéder à la définition dans un projet qui a été déchargé (non disponible). Cliquez avec le bouton droit sur le projet déchargé et sélectionnez "Recharger le projet".

La meilleure estimation est que vous ne disposez pas d'informations de débogage. Peut-être que vous avez plusieurs copies de votre assemblage sur le disque et qu'il ne contient pas le fichier .pdb.

Recherchez vos noms d'assembly dans vos projets, supprimez-les tous et reconstruisez-les.