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?
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.