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

Visual Studio (et peut-être même TFS) est en quelque sorte confondu (je pense que lors d’une fusion de contrôle de source) au sujet du cheminement d’un projet dans ma solution.

Il pense que c’est ici (exemple de chemins pour la simplicité):

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

alors qu’en réalité, le fichier de projet se trouve ici:

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

Je ne peux pas pour la vie me le faire reconnaître le bon endroit. J’ai essayé:

  • Supprimer et ré-append le projet à l’emplacement correct. Un message d’erreur s’affiche indiquant que The project file at C:\My Projects\ExampleSolution\ExampleProjectWrong\ExampleProjectCorrect.csproj could not be found .

  • Modifier manuellement le fichier .sln pour vous assurer que toutes les références à ExampleProjectCorrect.csproj ont les chemins corrects.

  • Faire une recherche dans les fichiers du répertoire de la solution pour les chemins corrects et incorrects, pour essayer de trouver où le 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 ne fait pratiquement aucune différence dans 100 projets et est liée au contrôle des sources avec plusieurs autres développeurs qui y travaillent.

Quelqu’un peut-il me diriger dans la bonne direction quant à l’endroit où il stocke ce chemin incorrect et / ou comment le réinitialiser pour que la foutue chose se charge correctement?

  1. Accédez à Gérer les espaces de travail (via le menu Contrôle de fichier / source ou la liste déroulante de l’espace de travail dans l’Explorateur de contrôle de code 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 source vers le répertoire de projet ancien / incorrect.
  4. Sélectionnez-le et cliquez sur supprimer .
  5. Fermez VS et supprimez le fichier suo.

Il référence toujours le mauvais répertoire. La reliure pourrait peut-être fonctionner à ce stade, mais je n’ai pas essayé. Rechargez votre projet et vous devriez être prêt à partir.

.suo simplement le fichier de solutions .suo fonctionné pour moi.

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 pour “l’Assistant de conversion” qui devait sortir dans les prochaines semaines, alors j’ai simplement 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 de chronologie réelle. 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 de la difficulté à charger mes projets comme le disait cette question. Pour une raison quelconque, quelques projets étaient référencés dans un répertoire incorrect. J’ai vérifié le fichier .sln, les fichiers .vsproj, et obtenu la dernière version, supprimant le re-get, ajoutant suppression, etc. J’ai essayé tout ce qui est noté ici … même la mise à jour de mon espace de travail.

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

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

Une solution légèrement différente.

TFS affichait un chemin non existant pour une solution particulière. Auparavant, j’avais un ordinateur portable avec un lecteur D: séparé, mais maintenant, j’ai juste un lecteur C :. TFS pensait toujours que mon projet était stocké sur D: \ Project \ MikesProject

Je n’avais pas de fichier .suo à supprimer, le D: path n’était mentionné nulle part dans mes espaces de travail (enterré sous le menu File\Source Control\Advanced\Workspaces ), TFS montrait que j’avais les derniers fichiers mon répertoire D: (qui n’existe plus) et TFS dans VS2013 n’ont pas d’option “Remove Mappings” pour ce projet.

Mais ce qui a fonctionné était de simplement faire une “dernière version” sur le projet.

Après cela, une nouvelle copie du code a été écrite sur mon lecteur C: et, chose intéressante, le chemin local a été souligné .

Auparavant, le chemin D: n’était pas affiché comme ceci.

Impair. Très étrange.

Nous avons eu des problèmes similaires avec les mouvements et les renoms. Suppression des répertoires locaux, puis résolution du problème.

Même après la suppression du fichier .suo et des dossiers .vs , j’ai dû modifier le fichier .sln et supprimer l’ancienne URL relative de SccProjectName# malgré le fait que SccLocalPath# soit correct. Apparemment, VS utilise également le nom comme un indice.

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

Juste deviner, mais peut-être que certains de vos autres projets font référence à votre projet au mauvais endroit? Dans ce cas, vous ne devez pas simplement 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érence (stockés dans leurs fichiers .csproj).

Après avoir essayé de nombreuses recommandations, j’ai supprimé le fichier suo (à nouveau). La dernière fois travaillée. 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.

J’ai ouvert ma solution de site Web asp.net depuis ma twig Dev. Ensuite, pour une autre raison, j’ai ouvert la même solution depuis la twig principale.

J’ai modifié l’un de mes fichiers .ascx.cs dans la twig dev et défini un point d’arrêt. Lorsque j’ai exécuté le débogueur, tous mes points d’arrêt ont été frappés dans la twig Dev, à l’exception du fichier .ascx.cs qui touchait la twig principale. Je ne sais pas.

Essayé de nettoyer le dossier temporaire mais n’a pas fonctionné.

Ce qui a fonctionné:

Fermé toutes les instances de Visual Studio

Ouvrez à nouveau la solution de la twig Dev.

Exécuter à nouveau et les points de rupture ont commencé à bash.

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

Supprimer * .suo ne m’aide pas.

Si vous exécutez votre application Web sous IIS local au lieu d’IISExpress, assurez-vous d’afficher le bouton “Créer un répertoire virtuel” dans les propriétés du projet. Une fois cela fait, effectuez “Clean Solution” et “Rebuild Solution”.

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