Program Visual Studio pobiera niepoprawną ścieżkę do projektu z dowolnego miejsca

Visual Studio (i prawdopodobnie TFS) w jakiś sposób (myślę, że być może podczas scalania kontroli źródła) pomyliło się co do ścieżki projektu w moim rozwiązaniu.

Wydaje się, że jest tutaj (przykładowe ścieżki prostoty):

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

podczas gdy w rzeczywistości plik projektu znajduje się tutaj:

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

Nie mogę za całe życie sprawić, by rozpoznał właściwą lokalizację. Próbowałem:

• Usunięcie i ponowne dodanie projektu z właściwej lokalizacji. Pojawia się komunikat o błędzie The project file at C:\My Projects\ExampleSolution\ExampleProjectWrong\ExampleProjectCorrect.csproj could not be found.

• Ręczna edycja pliku .sln, aby upewnić się, że wszystkie odwołania ExampleProjectCorrect.csprojmają prawidłowe ścieżki.

• Wyszukiwanie w plikach w katalogu rozwiązania zarówno poprawnych, jak i niepoprawnych ścieżek, aby spróbować wyśledzić, gdzie studio ukrywa niepoprawną ścieżkę.

• Usuwanie katalogów pamięci podręcznej dla VS i TFS

Rwę sobie włosy z głowy, ponieważ nie mogę odtworzyć rozwiązania, ponieważ ma blisko 100 projektów bez różnicy i jest powiązany z kontrolą źródła z kilkoma innymi programistami, którzy nad nim pracują.

Czy ktoś może wskazać mi właściwy kierunek, gdzie przechowuje tę niewłaściwą ścieżkę i / lub jak ją zresetować, aby ta cholerna rzecz załadowała się poprawnie?

1. Przejdź do Zarządzaj obszarami roboczymi (przez menu Plik / Kontrola źródła lub menu rozwijane obszaru roboczego w Eksploratorze kontroli źródła)
2. wybierz edycję dla swojego obszaru roboczego.
3. W folderach roboczych powinieneś zobaczyć mapowanie katalogu kontroli źródła do starego / niewłaściwego katalogu projektu.
4. Wybierz go i kliknij usuń .
5. Zamknij VS i usuń plik suo.

Nadal odwołuje się do niewłaściwego katalogu. Może ponowne wiązanie może zadziałać w tym momencie, ale tego nie próbowałem. Załaduj ponownie swój projekt i wszystko powinno być gotowe.

Po prostu usunięcie .suopliku rozwiązań działało dla mnie.

Miałem do czynienia z tym problemem po przeprowadzeniu migracji z programu Visual Source Safe 2005 do TFS 2012. Nie mogłem się doczekać, aż „Kreator konwersji” pojawi się w ciągu następnych kilku tygodni, więc właśnie uruchomiłem VSSConvert.exe. Zajęło to około 6 lat historii i przeniosło to do TFS .. podczas gdy nie otrzymałem aktualnej historii osi czasu .. Otrzymałem kilka wpisów tego samego dnia z komentarzami wskazującymi na faktyczne zameldowania w historii. . nie jest zły.

Więc po tym, jak działał przez całą noc (Pomyślnie, yay!), Miałem problemy z załadowaniem moich projektów, tak jak brzmiało to pytanie. Z jakiegoś powodu kilka projektów było odwoływanych do niewłaściwego katalogu. Sprawdziłem pliki .sln, .vsproj i pobierałem najnowsze, usuwałem ponowne pobieranie, dodawałem usuwanie itp. Próbowałem wszystkiego, co tu podano ... nawet uaktualniając mój obszar roboczy, co nawet nie jestem pewien.

WRESZCIE ... usunąłem pliki * .suo i altówkę. Zadziałało.

Spędziłem nad tym kilka godzin.

Nieco inne rozwiązanie.

TFS wyświetlał nieistniejącą ścieżkę dla określonego rozwiązania. Wcześniej miałem laptopa z oddzielnym napędem D :, ale teraz mam tylko napęd C:. TFS nadal uważało, że mój projekt jest przechowywany w D: \ Project \ MikesProject

Nie miałem .suopliku do usunięcia, ścieżka D: nie została wymieniona nigdzie w moich obszarach roboczych (ukryta w File\Source Control\Advanced\Workspacesmenu), TFS pokazało, że mam najnowsze pliki w moim (już nieistniejącym) D: katalogu, a TFS w VS2013 nie miał opcji „Usuń mapowania” dla tego projektu.

Ale to, co zrobił pracy było po prostu zrobić „Pobierz najnowszą wersję” na projekcie.

Po wykonaniu tej czynności nowa kopia kodu została zapisana na moim dysku C: i (co ciekawe), teraz ścieżka lokalna została podkreślona .

Wcześniej ścieżka D: nie była wyświetlana w ten sposób.

Dziwny. Bardzo dziwne.

Mieliśmy podobne problemy z przenoszeniem i zmianą nazw. Usunięcie lokalnych katalogów, a następnie ponowne rozwiązanie go.

Nawet po usunięciu .suopliku i .vsfolderów musiałem edytować .slnplik i usunąć stary względny adres URL, SccProjectName#mimo że SccLocalPath#był poprawny. Najwyraźniej VS używa również nazwy jako ścieżki podpowiedzi.

Spróbuj usunąć lub zmienić nazwę pliku .suo (łącznie z rozszerzeniem). Ten plik znajduje się w tej samej lokalizacji, w której znajduje się plik rozwiązania. U mnie to zadziałało.

Zgaduję, ale być może niektóre z Twoich innych projektów odwołują się do Twojego projektu z niewłaściwej lokalizacji? W takim przypadku musisz nie tylko usunąć i ponownie wstawić projekt do rozwiązania, ale także usunąć i odtworzyć odniesienia z projektów odwołujących się (przechowywane w ich plikach .csproj).

Po wypróbowaniu wielu zaleceń usunąłem plik suo (ponownie). Ostatni raz pracował. Dlaczego wcześniej nie zadziałało, nie wiem. Ogólnie uważam, że usunięcie pliku suo jest jednym z pierwszych kroków, które robię.

Moje rozwiązanie witryny internetowej asp.net zostało otwarte z mojego oddziału deweloperskiego. Następnie w innym celu otworzyłem to samo rozwiązanie z głównego oddziału.

Dokonałem zmiany w jednym z moich plików .ascx.cs w gałęzi dev i ustawiłem punkt przerwania. Kiedy uruchomiłem debugger, wszystkie moje punkty przerwania zostały trafione w gałęzi deweloperskiej z wyjątkiem .ascx.cs, który trafiał do gałęzi głównej. Nie mam pojęcia.

Próbowałem wyczyścić folder tymczasowy, ale nie zadziałało.

Co zadziałało:

Zamknięto wszystkie wystąpienia programu Visual Studio

Ponownie otworzyłem rozwiązanie z gałęzi Dev.

Uruchom ponownie, a punkty przerwania zaczęły uderzać.

W moim przypadku skopiowałem plik * .sln do folderu projektu i zmieniłem ścieżkę do projektu na plik * .sln. Tylko to rozwiązało problem (w porównaniu z 2015 sp1, projekt winservise).

Usunięcie * .suo mi nie pomaga.

Sprawdziło się u nas jeszcze jedno rozwiązanie - po próbie usunięcia suo i prawie wszystkiego, o czym mowa w tym wątku. W rozwiązaniu mieliśmy projekt, który wyświetlał wersję widmową pliku csproj. Usunęliśmy ten plik, a nasze ścieżki zostały naprawione w innym projekcie, który próbowaliśmy dodać.

Jeśli używasz aplikacji sieci Web w lokalnych usługach IIS zamiast w usługach IISExpress, upewnij się, że naciśniesz przycisk „Utwórz katalog wirtualny”, przechodząc do właściwości projektu. Gdy to zrobisz, wykonaj „Wyczyść rozwiązanie” i „Przebuduj rozwiązanie”.

Usunięcie plików obj i bin rozwiązałoby problem ...

Wiem, że to stara kwestia. Właśnie przeszedłem przez ten sam problem. Niedawno przeprowadziliśmy migrację TFS, więc utworzyłem nowy obszar roboczy do mapowania na nowy serwer i zachowałem stary. Za każdym razem, gdy otwieram rozwiązanie, które ma być przeznaczone dla mojego nowego obszaru roboczego, VS zawsze próbował załadować projekty z mojego starego katalogu mapowania, dopóki nie usunąłem starego obszaru roboczego.