Visual Studio récupérant un chemin incorrect vers un projet depuis quelque part

98

Visual Studio (et peut-être TFS) a en quelque sorte (je pense peut-être lors d'une fusion de contrôle de source) devenir confus sur le chemin d'un projet dans ma solution.

Il pense que c'est ici (exemples de chemins pour plus de simplicité):

C:\My Projects\ExampleSolution\ExampleProjectWrong\ExampleProjectCorrect.csproj

alors qu'en fait, le fichier projet se trouve ici:

C:\My Projects\ExampleSolution\ExampleProjectCorrect\ExampleProjectCorrect.csproj

Je ne peux pas pour la vie de moi faire reconnaître le bon emplacement. J'ai essayé:

  • Suppression et réajout du projet à partir de l'emplacement correct. Un message d'erreur apparaît disant The project file at C:\My Projects\ExampleSolution\ExampleProjectWrong\ExampleProjectCorrect.csproj could not be found.

  • Éditer manuellement le fichier .sln pour garantir que toutes les références ExampleProjectCorrect.csprojont les chemins corrects.

  • Faire une recherche dans les fichiers du répertoire de la solution pour les chemins corrects et incorrects, pour essayer de localiser où Studio cache le chemin incorrect.

  • Suppression des répertoires de cache pour VS et TFS

Je m'arrache les cheveux parce que je ne peux pas recréer la solution car elle n'a presque aucune différence dans 100 projets et est liée au contrôle de code source avec plusieurs autres développeurs qui y travaillent.

Quelqu'un peut-il me diriger dans la bonne direction pour savoir où il stocke ce chemin incorrect et / ou comment le réinitialiser pour que la fichue chose se charge correctement?

visual-studio caching tfs Charlie Drewitt
la source
Alors, que se passe-t-il si vous déplacez le projet vers le répertoire ExampleProjectWrong?
Hans Passant
Ok, quelques progrès .. Le déplacer dans le mauvais dossier me permet de le charger dans Visual Studio. Je ne peux pas le garder là cependant car le répertoire 'ExampleProjectWrong' abrite un autre projet, contenant à peu près la même structure de dossiers. Alors, avez-vous des idées pour changer le chemin du projet maintenant que je l'ai chargé? Le champ chemin dans les propriétés du projet déchargé n'est pas disponible, même lorsque le projet est déchargé?
Charlie Drewitt
3
J'ai eu ce problème pour la deuxième fois maintenant, mais cette fois, j'ai pu comprendre que le projet ramifié ciblait le dossier d'origine car j'utilise différentes chaînes de connexion. C'était très étrange la première fois, provoquant le débogage de visualstudio dans les fichiers du dossier source, et le mélangeant avec des fichiers de la branche, et même Log4net connecté au dossier d'origine! J'ai supprimé le fichier suo de la solution et il accède désormais correctement uniquement aux fichiers branchés.
Binke
2
J'ai eu exactement le même problème. Ce n'était pas aussi simple que de supprimer le fichier suo. J'ai dû: 1. Supprimer le projet incriminé de la solution. 2. Enregistrez la solution. 3. Supprimez le .suo 4. Ouvrez la solution et ajoutez à nouveau le projet.
SeanLAllen
1
La suppression du fichier SUO a fonctionné pour moi.
DanielV

Réponses:

96
  1. Accédez à Gérer les espaces de travail (via le menu Fichier / Contrôle de la source ou la liste déroulante de l'espace de travail dans l'Explorateur de contrôle de la source)
  2. sélectionnez modifier pour votre espace de travail.
  3. Vous devriez voir, sous les dossiers de travail, un mappage du répertoire de contrôle de source vers l'ancien / mauvais répertoire de projet.
  4. Sélectionnez-le et cliquez sur Supprimer .
  5. Fermez VS et supprimez le fichier suo.

Il fait toujours référence au mauvais répertoire. Peut-être que la reliure pourrait fonctionner à ce stade, mais je n'ai pas essayé cela. Rechargez votre projet et vous devriez être prêt à partir.

Benjamin Potts
la source
1
Aussi, soyez trompé par le lien de chemin local dans l'explorateur de contrôle de source. J'avais plus d'un mappage pour mon espace de travail et il montrait ce à quoi je m'attendais, mais quand il a essayé de charger le projet, il utilisait l'autre chemin.
Benjamin Potts
1
Le fichier .suo est masqué, vous devez donc activer l'option "Afficher tous les fichiers et dossiers"
ANIL MANE
8
Dans Visual Studio 2015, j'ai rencontré la même erreur. Ce qui a fonctionné pour moi a été de supprimer le répertoire caché .vs et le fichier .suo.
Daniel Leiszen
5
Pour VS2015, votre .suofichier n'est peut-être pas là où vous le pensez. Supprimez celui qui se trouve à côté de votre .slnfichier (n'oubliez pas de "afficher les fichiers cachés") et il y en a aussi un qui se cache dans un sous-répertoire à .\.vs\[solution_name]\v14\.suo. Une fois que je les ai tous les deux, je pourrais ajouter à nouveau le projet. Oups - crédit partiel à @DanielLeiszen (vient de remarquer qu'il a commenté la même chose)
Richard Hauer
1
J'ai dû supprimer le fichier .suo et redémarrer VS pour que la raison l'emporte
Appulus
33

La simple suppression du .suofichier de solutions a fonctionné pour moi.

Lloyd Powell
la source
5
Dans VS2015, je devais fermer toutes les instances de Visual Studio avant que la suppression ne <SolutionDir>\.vs\<SolutionName>\<VsVersion>\.suofonctionne pour moi.
GraehamF
12

J'étais confronté à ce problème après avoir effectué une migration de Visual Source Safe 2005 vers TFS 2012. Je ne pouvais pas attendre la sortie de "l'assistant de conversion" dans les prochaines semaines, alors j'ai juste lancé VSSConvert.exe. Cela a pris environ 6 ans d'histoire et l'a déplacé dans TFS .. alors que je n'ai pas eu l'historique réel de la chronologie .. J'ai reçu un tas d'entrées le même jour avec les commentaires indiquant les enregistrements réels de l'historique. . pas mal.

Donc, après avoir couru toute la nuit (avec succès, oui!), J'avais du mal à charger mes projets comme cette question le disait. Pour une raison quelconque, quelques projets étaient référencés dans un répertoire incorrect. J'ai vérifié le .sln, les fichiers .vsproj, et obtenir les derniers, supprimer la ré-obtention, ajouter la suppression, etc. J'ai essayé tout ce qui est noté ici ... même la mise à niveau de mon espace de travail, ce que je ne suis pas sûr de ce que cela a fait.

ENFIN ... J'ai supprimé les fichiers * .suo et l'alto. Ça a marché.

J'ai passé quelques heures sur celui-ci.

hanzolo
la source
2
Avant de supprimer le fichier * .suo, assurez-vous de fermer toutes les instances de Visual Studio, puis ouvrez à nouveau la solution.
Mas du
5

Une solution légèrement différente.

TFS affichait un chemin d'accès inexistant pour une solution particulière. Auparavant, j'avais un ordinateur portable avec un lecteur D: séparé, mais maintenant, je n'ai qu'un lecteur C:. TFS pensait toujours que mon projet était stocké sur D: \ Project \ MikesProject

Je n'avais pas de .suofichier à supprimer, le chemin D: n'était mentionné nulle part dans mes espaces de travail (enterré sous le File\Source Control\Advanced\Workspacesmenu), TFS a montré que j'avais les derniers fichiers dans mon (qui n'existe plus) D: et TFS dans VS2013 n’avaient pas d’option «Supprimer les mappages» pour ce projet.

Mais ce qui a fonctionné était simplement de faire une "Obtenir la dernière version" sur le projet.

Après cela, une nouvelle copie du code a été écrite sur mon lecteur C: et (fait intéressant), maintenant le chemin local a été souligné .

Auparavant, le chemin D: n'était pas montré comme ça.

Impair. Très étrange.

Mike Gledhill
la source
2
Exactement la même situation pour moi. J'ai hésité à appuyer sur la gâchette et à "Get Latest" à cause de ce chemin incorrect, mais @Mike m'a donné le courage!
Jonathan
2

Nous avons eu des problèmes similaires avec les déplacements et les renommages. Supprimer les répertoires locaux, puis le résoudre à nouveau.

Tony Hopkinson
la source
2

Même après avoir supprimé le .suofichier et les .vsdossiers, j'ai dû modifier le .slnfichier et supprimer l'ancienne URL relative SccProjectName#malgré le fait qu'elle SccLocalPath#était correcte. Apparemment, VS utilise également le nom comme chemin d'indication.

Adam
la source
1

Essayez de supprimer ou de renommer le fichier .suo (y compris l'extension). Ce fichier se trouve au même emplacement que votre fichier de solution. Cela a fonctionné pour moi.

Mandeep Janjua
la source
0

Juste deviner, mais peut-être que certains de vos autres projets font référence à votre projet à partir du mauvais endroit? Dans ce cas, il ne vous reste pas seulement à supprimer et réinsérer le projet dans votre solution, vous devrez également supprimer et recréer les références des projets de référencement (stockés dans leurs fichiers .csproj).

Doc Brown
la source
Merci pour la réponse. le projet n'est référencé à partir d'aucun autre projet dans la solution. pouvez-vous expliquer pourquoi la recherche dans les fichiers ne fonctionnerait pas? D'après mon expérience, si vous lui donnez un chemin de répertoire pour «Rechercher dans», au lieu de sélectionner «Solution entière», il recherchera tous les types de fichiers à moins qu'il ne soit spécifiquement indiqué de rechercher uniquement certains types de fichiers?
Charlie Drewitt
Désolé, vous avez raison, je pensais que vous utilisiez "Rechercher dans les fichiers" uniquement pour les fichiers de la solution, pas pour le répertoire de la solution, j'ai manqué cela. Donc ça devrait marcher. Pouvez-vous donner une description plus détaillée à quel moment exactement le message d'erreur apparaît? Cela se produit-il lors de la compilation, pour que vous puissiez voir quelle compilation de projet a échoué?
Doc Brown
0

Après avoir essayé de nombreuses recommandations, j'ai supprimé le fichier suo (à nouveau). La dernière fois a fonctionné. Pourquoi cela n'a pas fonctionné plus tôt, je ne sais pas. En général, je trouve que la suppression du fichier suo est l'une des premières étapes que je fais.

utilisateur3097514
la source
0

J'ai ouvert ma solution de site Web asp.net à partir de ma branche de développement. Ensuite, dans un autre but, j'ai ouvert la même solution depuis la branche principale.

J'ai modifié l'un de mes fichiers .ascx.cs dans la branche dev et défini le point d'arrêt. Lorsque j'ai exécuté le débogueur, tous mes points d'arrêt ont été atteints dans la branche de développement, à l'exception du .ascx.cs qui atteignait la branche principale. Je n'ai pas idée.

J'ai essayé de nettoyer le dossier temporaire mais cela n'a pas fonctionné.

Ce qui a fonctionné:

Fermé toutes les instances de Visual Studio

A ouvert à nouveau la solution de la branche Dev.

Exécutez à nouveau et les points de rupture ont commencé à frapper.

gbs
la source
0

Dans mon cas, j'ai copié le fichier * .sln dans le dossier du projet et changé le chemin du projet dans le fichier * .sln. Seul cela a résolu le problème (vs 2015 sp1, projet winservise).

Supprimer * .suo ne m'aide pas.

Kamerton
la source
0

Encore une autre solution a fonctionné pour nous - après avoir essayé la suppression de suo et presque tout ce qui est mentionné dans ce fil. Nous avions un projet dans la solution qui montrait une version fantôme du fichier csproj. Nous avons supprimé ce fichier et nos chemins fixés sur un autre projet que nous essayions d'ajouter.

Rondakay
la source
-1

Si vous exécutez votre application Web sous IIS local au lieu d'IISExpress, assurez-vous de cliquer sur le bouton "Créer un répertoire virtuel" en allant dans les propriétés du projet. Une fois cela fait, exécutez "Clean Solution" et "Rebuild Solution".

Sondage Ajinkya
la source
-1

La suppression des fichiers obj et bin résoudrait le problème ...

Mohanad Shamsneh
la source
-3

Je sais que c'est une vieille ligne. Je viens de traverser le même problème. Nous avons récemment migré le TFS, j'ai donc créé un nouvel espace de travail à mapper vers un nouveau serveur et gardé l'ancien. Chaque fois que j'ouvre une solution censée cibler mon nouvel espace de travail, VS essaie toujours de charger des projets à partir de mon ancien répertoire de mappage, jusqu'à ce que je supprime mon ancien espace de travail.

RetourToSorrento
la source
cela n'aide pas vraiment à la question initiale
vlad_tepesch
Je pensais que mon problème avait la même nature. J'avais deux espaces de travail, dont l'un est ancien. J'ai travaillé dans un nouveau, et créé une solution, ajouté des projets. tout va bien seulement si je n'ai pas fermé la solution. Mais si j'enregistrais la solution et que j'essayais de l'ouvrir, VS essayait toujours de charger des projets dans la solution à partir du répertoire mappé dans mon ancien espace de travail.
BackToSorrento