Pracuję w projekcie sieci Web w programie Visual Studio 2008. Kiedy naciskam klawisz F12 (lub klikam prawym przyciskiem myszy i wybieram opcję Przejdź do definicji), program Visual Studio konsekwentnie przechodzi do pliku metadanych zamiast do źródła.

Kilka punktów:

• Cały kod źródłowy jest w C #, nie ma VB.Net
• Wszystkie projekty są w tym samym rozwiązaniu
• Wszystko jest odniesieniem do projektu, a nie odniesieniem do pliku (zaznaczone i dwukrotnie sprawdzone)
• Wypróbowałem podejście Clean / Rebuild Solution (nawet do momentu wyczyszczenia katalogu Temp, katalogu Temporary ASP.NET Files itp.).

Czy ktoś inny widział to zachowanie i / lub wie, jak to naprawić?

Cóż, inny programista znalazł odpowiedź. Konkretny projekt, z którym mieliśmy problem, został pierwotnie dodany jako odniesienie do pliku, a następnie usunięty i dodany jako odniesienie do projektu. Jednak program Visual Studio zachował oba pliki w pliku csproj witryny sieci Web, powodując problem. Wszedł i ręcznie zmodyfikował plik csproj, aby usunąć odniesienie do pliku z projektem powodującym problem i wszystko jest teraz naprawione

Dzieje się tak, gdy nie dodasz odwołania jako projektu, ale wskażesz plik dll lub exe za pomocą karty Przeglądaj w oknie dialogowym Dodaj odwołanie. Jeśli dodasz odniesienie za pomocą zakładki Projekty, powinieneś przejść bezpośrednio do kodu źródłowego po wybraniu Przejdź do definicji.

Jeśli jednak zainstalujesz ReSharper , przejdziesz do kodu źródłowego, nawet jeśli dodałeś swoje odniesienie do dll / exe za pomocą karty Przeglądaj.

Wygląda na to, że trzeba go również skonfigurować w Resharper. Mój program Visual Studio nie przechodzi do kodu źródłowego .NET Framework, dopóki nie włączę go w programie Resharper.

1. zamknij rozwiązanie.

2. Usuń ukryty <name of the solution>plik .suo w folderze, w którym znajduje się <name of the solution>plik .sln rozwiązania .

3. otwórz rozwiązanie.

4. przebuduj swoje rozwiązanie.

Dla tych, którzy używają VS 2017 (jestem w wersji 15.3.4 w tej chwili) oto proste kroki:

1. Otwórz rozwiązanie w Eksploratorze Windows i zamknij program Visual Studio
2. W menu eksploratora wybierz Widok i upewnij się, że pole wyboru „Ukryte elementy” jest zaznaczone
3. Przejdź do podfolderu .vs\[your solution name]\v15
4. Usuń .suoplik
5. Uruchom ponownie VS i stwórz swoje rozwiązanie

To rozwiązało problem: F12 otworzył rzeczywisty plik źródłowy, a nie wersję „z metadanych”.

Visual studio często boryka się z problemem przechodzenia do metadanych zamiast projektu, jeśli zmienisz lokalizację, w której budujesz projekt, tj. Możesz mieć kilka wersji do przetestowania.

Po prostu usuń odniesienie i natychmiast dodaj je z powrotem, a wszystko zostanie uporządkowane.

Zaznaczone rozwiązanie nie zawsze działa. Należy upewnić się, że identyfikator GUID projektu, do którego istnieje odwołanie, w plikach projektu jest poprawnym identyfikatorem GUID projektu, do którego próbujesz się odwołać. Program Visual Studio pozwala im w pewnych okolicznościach wyjść z synchronizacji. Identyfikator GUID projektu można uzyskać z pliku projektu za pomocą edytora tekstu. Jeśli więc projekt referencyjny B. Otwórz projekt B.csproj w edytorze tekstu, skopiuj identyfikator GUID projektu z tagu. Następnie otwórz projekt A.csproj w edytorze tekstu i upewnij się, że używasz poprawnego identyfikatora GUID. W tym przypadku wyszukaj nazwę projektu „B”. Powinien być o godz. Zastąp identyfikator GUID w tagu na prawidłowy. Zapisz i załaduj ponownie. Oczywiście upewnij się również, że odniesienia oparte na plikach do twoich projektów zostały usunięte. Potrzebujesz tylko referencji do projektów.

Zabiłem wszystkie instancje VS, skasowałem SUO, uruchomiłem sln i to zadziałało ...

Usuń referencyjną bibliotekę dll, zbuduj (wystąpią błędy), DODAJ referencję (usunąłeś), a następnie zbuduj ponownie ... F12 na twojej funkcji powinno wtedy działać (działało dla mnie).

Dowiedziałem się z tego postu , jak rozwiązać mój problem , może u niektórych też się uda.

Wykonałem następujące kroki:

1. Zamknij rozwiązanie.
2. Usuń plik bazy danych Intellisense dla rozwiązania: .ncb
3. Otwórz rozwiązanie.
4. Odbuduj rozwiązanie.

(Uważam, że krok 3 lub 4 regeneruje plik bazy danych Intellisense, gdy jej brakuje)

Inteligencja, „przejdź do definicji” i „znajdź wszystkie odniesienia” powinny znowu działać.

W moim przypadku (używając Visual Studio Professional 2015), kiedy wyłączyłem projektanta XAML, F12 przestał działać. Gdy tylko cofnę zmiany i ponownie uruchomię Visual Studio, F12 znów zadziałał.

Sprawdziłem wzór wiele razy, aby potwierdzić, a następnie opublikowałem. Mam nadzieję, że to komuś pomoże.

Objaw:

Program Visual Studio 2010 Ultimate wielokrotnie nie znajdował odniesień do funkcji, # definiuje, zawiera itp. Podczas korzystania z funkcji „Przejdź do definicji”, „Przejdź do deklaracji” lub „Znajdź wszystkie odwołania” - dziwnie działała funkcja Intellisense.

Naprawić:

1. Zamknij program Visual Studio
2. Usuń (zmień nazwę, jeśli chcesz zachować ostrożność) plik .sdf rozwiązania
3. Otwórz ponownie program Visual Studio

Plik .sdf zostanie automatycznie odbudowany przez przeanalizowanie plików dołączanych w rozwiązaniu

Dla mnie rozwiązanie GUID nie działało i nie mogłem znaleźć mojego pliku .ncb. (A może jestem leniwy i nie wyglądałem wystarczająco mocno, ale to nie jest ważne). Odbudowa i ponowne uruchomienie Visual Studio też nie pomogło.

To, co zrobiłem, to zamknąłem Visual Studio i usunąłem .dll i .pdb, do których istnieją odniesienia w górnej części pliku Meta Data, z którym łączyło się moje intelisense. W moim przypadku oznaczało to, że usunąłem plik .dll i jego plik .pdb z Utilities / bin / Release. (Utilities to nazwa projektu .dll, z którym miałem problemy). Następnie ponownie uruchomiłem program Visual Studio i odbudowałem plik .dll, a następnie całe rozwiązanie. Żadnych więcej problemów!

Właśnie znalazłem inny powód. Zaktualizowałem swój projekt sieciowy do 4.0, ale zostawiłem biblioteki klas w wersji 2.0. W tym momencie wszystkie biblioteki klas w moim rozwiązaniu były traktowane jako odwołania do plików z mojego projektu internetowego. Może pomóc komuś innemu ...

Napotkałem ten sam problem i jeden z kolegów dał mi następujące rozwiązanie i zadziałało! Jeśli żadne z powyższych nie działa dla Ciebie,

1. Usuń wszystkie odniesienia i dodaj je z powrotem (upewnij się, że ścieżka jest poprawna)
2. Przejdź do właściwości rozwiązania i ponownie sprawdź zależności projektów wszystkich projektów. Upewnij się, że projekt, którego będziesz używać, został dodany jako zależny w projekcie, nad którym pracujesz.

Wykonałem wszystkie sugerowane kroki, ale nic się nie zmieniło, a następnie
kliknij prawym przyciskiem myszy i dodaj menu referencyjne, zakładkę projektu

1. po prostu odznaczono projekt referencyjny.
2. zapisz rozwiązanie.
3. wybierz ten sam projekt.
4. Odbuduj rozwiązanie.

Problem rozwiązany. Mam nadzieję, że komuś to pomoże.

Poniższe kroki zadziałały dla mnie.

1. Przejdź do pliku .csproj
2. Otwórz go w Notatniku Przejdź do wiersza, do którego odnosi się dll.<Reference Include="">

3. Usuń linię

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

Po usunięciu plików dll z programu Visual Studio i dodaniu ich z powrotem ręcznie z Eksploratora rozwiązań -> Witryna internetowa -> Dodaj -> Odniesienie i włączenie aplikacji 32-bitowych w usługach IIS naprawiłem to za mnie.

# 1

Zaznacz „Widok - Przeglądarka obiektów” i jeśli widzisz więcej niż jeden zespół o tej samej nazwie - dlatego otrzymujesz ten błąd.

Dla nas był to błąd w VS 2019:

Jeśli masz w App_Codefolderze „Pomocników Razor” ASP.NET, program Visual Studio 2019 interpretuje to jako inny zestaw, ale o tej samej nazwie, co powoduje ukrycie rzeczywistego zestawu.

Nie ma innego rozwiązania niż przepisanie tych helperów do częściowych widoków lub pomocników HTML (i tak będziesz musiał to zrobić, jeśli planujesz migrację do .NET Core).

Zobacz to obejście na stronie MS i proszę, zagłosuj tam na błąd, aby MS go naprawił

https://developercommunity.visualstudio.com/solutions/1008795/view.html (prosimy o zagłosowanie)

# 2

Innym powodem, dla którego ten sam zestaw może zostać załadowany dwukrotnie w przeglądarce obiektów, jest to, że masz projekt testu jednostkowego, który uruchamia proces iis-express i nigdy go poprawnie nie zabija.

1. kliknij menu strony internetowej z VS.
2. Dodaj odniesienie ...
3. Kliknij kartę projektu w oknie dialogowym
4. Wybierz ddl
5. Kliknij przycisk OK

W moim przypadku niedawno się zmieniłem

<mvcBuildViews>

na „true” w pliku .csproj mojej witryny (aby znaleźć błędy kompilacji w moich plikach widoku Razor: http://forums.asp.net/t/1909113.aspx?How+to+have+Visual+Studio+2012+returned + kompilacja + błędów + on + razor + składnia + błąd + w + asp + net + strona + internetowa + 2 + ), a kiedy budowałem, otrzymywałem błędy z katalogu / obj / Debug / mojej witryny. Z dowolnego z tych plików (które były nieaktualne) kliknięcie prawym przyciskiem myszy i wybranie opcji „Przejdź do definicji” dało mi wersję [metadane].

Więc dla mnie żadne z rozwiązań tutaj nie zadziałało, ponieważ nie zaczynałam od pliku, który faktycznie był w moim projekcie. Usunąłem ten cały katalog / obj / Debug /, błędy zniknęły iz każdego normalnego pliku mogę poprawnie użyć opcji Przejdź do definicji.

Właśnie natknąłem się na ten problem w VS 2013. Coś, czego nie mogłem (zrobiłem?) Nie wyodrębnić, to zmiana GUID w pliku CSPROJ. Ponieważ pliki CSPROJ są wpisywane do SVN, nie mogłem po prostu zmienić identyfikatora GUID na moim lokalnym dev. Zamiast tego stale SVN cofał lokalną zmianę za każdym razem, gdy to się stało.

Najpierw musiałem rozwiązać problem zmieniającego się identyfikatora GUID.

1. Przywróć CSPROJ do wersji zarejestrowanej.
2. Otwórz CSPROJ za pomocą edytora tekstu, NIE VS.

3. Wyodrębnij wartość z nieskazitelnego pliku CSPROJ.

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

4. Otwórz plik SLN za pomocą edytora tekstu, NIE VS.

5. Zlokalizuj odwołanie do projektu w rozwiązaniu.

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

6. Pierwszy wymieniony identyfikator GUID to identyfikator GUID rozwiązania. Dla każdego projektu, do którego odwołuje się SLN, powinieneś zobaczyć tę wartość powtórzoną przy pierwszym argumencie. Identyfikator GUID następujący po .csproj to ten, który chcesz zastąpić nieskazitelnym identyfikatorem GUID.

To powinno rozwiązać pierwszy problem, ale lądowanie „Idź do definicji” w metadanych nie zostało rozwiązane. W naszym pliku SLN znajduje się projekt główny (nasza witryna internetowa), więc jego wpis w pliku SLN powinien zawierać wpis ProjectSection z wieloma wartościami GUID. Oto przykład:

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

Zwróć uwagę, że brakujący identyfikator GUID w tej kolekcji to ten z mojego nieskazitelnego projektu.

1. Dodaj brakujący identyfikator GUID jako ostatni wpis między ProjectSection i EndProjectSection. Wygląda na to, że format jest oparty na wierszu i to {GUID} = {GUID}.
2. Zapisz plik.
3. Otwórz swoje rozwiązanie.
4. Kliknij prawym przyciskiem myszy odniesienie w nowo dodanym projekcie i „Przejdź do definicji”.

Miałem cykliczne odniesienie między dwoma zaangażowanymi projektami (co jest nie-nie). Musiałem trochę zmienić mój kod, aby go rozwiązać, ponieważ oba projekty były naprawdę od siebie zależne. Usunięcie jednego z odnośników rozwiązało problem inteligencji. Był logicznie błędny i prawdopodobnie nie zauważyłbym bez tego błędu!

Ten pracował dla mnie:

1. Kliknij prawym przyciskiem myszy dll w folderze referencyjnym w eksploratorze rozwiązań
2. Usuń plik dll
3. Następnie kliknij prawym przyciskiem myszy folder Reference
4. Dodaj ponownie odniesienie do pliku dll

Może się to zdarzyć, jeśli próbujesz przeskoczyć do definicji w projekcie, który został usunięty (niedostępny). Kliknij prawym przyciskiem myszy wyładowany projekt i wybierz „Wczytaj ponownie projekt”.

Najlepiej przypuszczać, że nie masz informacji debugowania. Być może masz wiele kopii zestawu na dysku i nie zawiera on pliku .pdb.

Wyszukaj nazwy zestawów w swoich projektach, usuń je wszystkie i przebuduj.