Я работаю над веб-проектом в Visual Studio 2008. Когда я нажимаю F12 (или щелкаю правой кнопкой мыши и выбираю «Перейти к определению») Visual Studio последовательно переходит к файлу метаданных, а не к источнику.

Некоторые моменты:

• Весь исходный код - C #, VB.Net нет
• Все проекты в одном решении
• Все является ссылкой на проект, а не ссылкой на файл (проверено и дважды проверено)
• Я пробовал подход Clean / Rebuild Solution (даже до очистки каталога Temp, каталога Temporary ASP.NET Files и т. Д.).

Кто-нибудь еще видел такое поведение и / или знает, как его исправить?

Что ж, другой разработчик нашел ответ. Конкретный проект, с которым у нас возникла проблема, изначально был добавлен как ссылка на файл, затем удален и добавлен как ссылка на проект. Однако Visual Studio сохранила оба файла в файле csproj для веб-сайта, что вызвало проблему. Он вошел и вручную отредактировал файл csproj, чтобы удалить ссылку на файл проблемного проекта, и теперь все исправлено.

Это происходит, когда вы не добавляете ссылку в качестве проекта, а указываете на dll или exe, используя вкладку «Обзор» в диалоговом окне «Добавить ссылку». Если вы добавляете ссылку с помощью вкладки «Проекты», вы должны перейти непосредственно к исходному коду, выбрав «Перейти к определению».

Однако, если вы установите ReSharper , вы перейдете к исходному коду, даже если вы добавили ссылку на dll / exe с помощью вкладки «Обзор».

Похоже, это тоже нужно настроить в Resharper. Моя Visual Studio не переходит к исходному коду .NET Framework, пока я не включу его в Resharper.

1. закройте свое решение.

2.<name of the solution> Удалите скрытый файл .suo в папке, в которой <name of the solution>существует файл .sln вашего решения .

3. откройте свое решение.

4. Восстановите свое решение.

Для тех, кто использует VS 2017 (на данный момент у меня версия 15.3.4), вот простые шаги:

1. Откройте свое решение в проводнике Windows и закройте Visual Studio.
2. В меню проводника выберите «Просмотр» и убедитесь, что установлен флажок «Скрытые элементы».
3. Перейдите во вложенную папку .vs\[your solution name]\v15
4. Удалить .suoфайл
5. Перезапустите VS и создайте свое решение

Это исправило для меня: F12 открыл фактический исходный файл, а не версию «из метаданных».

Visual Studio часто страдает от проблемы перехода к метаданным, а не к вашему проекту, если вы меняете место, где вы создаете проект, т.е. у вас может быть несколько версий для тестирования.

Просто удалите ссылку и сразу добавьте обратно, и все будет в порядке.

Отмеченное решение не всегда работает. Вы должны убедиться, что GUID указанного проекта в файлах проекта является правильным GUID для проекта, на который вы пытаетесь сослаться. Visual Studio позволяет им в некоторых случаях выходить из синхронизации. Вы можете получить GUID проекта из файла проекта с помощью текстового редактора. Итак, если проект A эталонный проект B. Откройте проект B.csproj в текстовом редакторе, скопируйте GUID проекта из тега. Затем откройте проект A.csproj в текстовом редакторе и убедитесь, что вы используете правильный GUID. В этом случае ищите название проекта "B". Это должно быть в. Замените GUID в теге на правильный. Сохраните и перезагрузите. Конечно, также убедитесь, что ссылки на ваши проекты на основе файлов удалены. Вам нужны только ссылки на проекты.

Я убил все экземпляры VS, удалил SUO, запустил sln, и у меня это сработало ...

Удалите ссылочную dll, выполните сборку (появятся ошибки), ДОБАВЬТЕ ссылку (вы удалили), затем снова выполните сборку ... F12 для вашей функции должен работать (работал у меня).

Я понял, как решить свою проблему из этого поста , возможно, это также сработает для некоторых из вас.

Я выполнил следующие шаги:

1. Закройте раствор.
2. Удалите файл базы данных intellisense для решения: .ncb
3. Откройте решение.
4. Восстановите решение.

(Я считаю, что шаг 3 или 4 восстанавливает файл базы данных intellisense, если он отсутствует)

Intellisense, «перейти к определению» и «найти все ссылки» должны снова работать.

В моем случае (с использованием Visual Studio Professional 2015), когда я отключил конструктор XAML, F12 перестал работать. Как только я отменил изменения и перезапустил Visual Studio, F12 снова заработал.

Проверял шаблон несколько раз, чтобы подтвердить, а затем опубликовал. Надеюсь, это кому-то поможет.

Симптом:

Visual Studio 2010 Ultimate неоднократно не мог найти ссылки на функции, #defines, includes и т. Д. При использовании функций «Перейти к определению», «Перейти к объявлению» или «Найти все ссылки» - как ни странно, Intellisense работала.

Fix:

1. Закройте Visual Studio
2. Удалите (переименуйте, если хотите быть консервативным) файл решения .sdf.
3. Повторно открыть Visual Studio

Файл .sdf будет автоматически перестроен путем анализа включаемых файлов в вашем решении.

Для меня решение GUID не сработало, и я не смог найти свой файл .ncb. (Или, может быть, я ленив и недостаточно внимательно смотрел, но это не важно.) Перестройка и перезапуск Visual Studio тоже не помогли.

Что я сделал, так это закрыл визуальную студию и удалил .dll и .pdb, на которые есть ссылки в верхней части файла метаданных, на которые мой intellisense продолжал ссылаться. В моем случае это означало, что я удалил свой .dll и его .pdb-файл из Utilities / bin / Release. (Утилиты - это название проекта .dll, с которым у меня возникли проблемы.) Затем я перезапустил Visual Studio и пересобирал .dll, а затем все решение. Больше никаких проблем!

Только что нашел другую причину. Я обновил свой веб-проект до 4.0, но оставил библиотеки классов на 2.0. В этот момент все библиотеки классов в моем решении рассматривались как ссылки на файлы из моего веб-проекта. Может помочь кому-нибудь другому ...

Я столкнулся с той же проблемой, и один из коллег предложил мне следующее решение, и оно сработало! Если ничего из вышеперечисленного вам не подходит,

1. Удалите все ссылки и добавьте их обратно (убедитесь, что путь правильный)
2. Перейдите в Свойства решения и еще раз проверьте зависимости всех проектов. Убедитесь, что проект, который вы будете использовать, добавлен как зависимый в проект, над которым вы работаете.

Я выполнил все предложенные шаги, но ничего не изменилось, затем,
наконец, щелкните правой кнопкой мыши и добавьте справочное меню, вкладку проекта

1. просто отмените выбор эталонного проекта.
2. сохраните решение.
3. выберите тот же проект.
4. Восстановите решение.

Проблема решена. Надеюсь, это кому-то поможет.

Следующие шаги сработали для меня.

1. Перейдите в файл .csproj
2. Откройте его в Блокноте. Перейдите к строке, где есть ссылка на dll.<Reference Include="">

3. Удалить строку

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

После удаления файлов dll из Visual Studio и добавления их вручную из обозревателя решений -> Веб-сайт -> Добавить -> Ссылка и включения 32-разрядных приложений в IIS это исправлено для меня.

# 1

Отметьте «Просмотр - Обозреватель объектов», и если вы видите несколько сборок с одинаковым именем - вот почему вы получаете эту ошибку.

Для нас это была ошибка в VS 2019:

Если у вас есть «помощники Razor» ASP.NET в App_Codeпапке, Visual Studio 2019 интерпретирует это как другую сборку, но с тем же именем, которая скрывает фактическую сборку.

Для этого нет никакого решения, кроме как переписать эти помощники в частичные представления или помощники HTML (вам все равно придется это сделать, если вы планируете переход на .NET Core).

См. Этот обходной путь на сайте MS и, пожалуйста, проголосуйте за ошибку там, чтобы MS ее исправила.

https://developercommunity.visualstudio.com/solutions/1008795/view.html (проголосуйте за)

# 2

Другая причина, по которой одна и та же сборка может быть загружена дважды в обозревателе объектов, заключается в том, что у вас есть проект модульного тестирования, который запускает процесс iis-express и никогда не завершает его должным образом.

1. щелкните меню веб-сайта в VS.
2. Добавить ссылку ...
3. Щелкните вкладку проекта в диалоговом окне
4. Выберите ddl
5. Нажмите кнопку ОК

В моем случае я только недавно сменил

<mvcBuildViews>

в "true" в файле .csproj моего сайта (чтобы найти ошибки компиляции в моих файлах представления Razor: http://forums.asp.net/t/1909113.aspx?How+to+have+Visual+Studio+2012+returned + компиляция + ошибки + на + razor + синтаксис + ошибка + в + asp + net + web + page + 2 + ), и когда я затем построил, я получал ошибки из моего каталога / obj / Debug / моего сайта. В любом из этих файлов (которые были устаревшими), щелкнув правой кнопкой мыши и выбрав «Перейти к определению», я получил бы версию [метаданных].

Поэтому для меня ни одно из решений здесь не сработало, потому что я начинал не с файла, который на самом деле был в моем проекте. Удалил весь каталог / obj / Debug /, ошибки исчезли, и из любого нормального файла я могу правильно использовать Go To Definition.

Я только что столкнулся с этой проблемой на VS 2013. Что-то, что я не мог (сделал?) Не изолировать, - это изменение GUID в файле CSPROJ. Поскольку файлы CSPROJ проверяются в SVN, я не мог просто изменить GUID на моем локальном устройстве. Вместо этого я постоянно возвращал локальное изменение в SVN каждый раз, когда это происходило.

Во-первых, мне пришлось решить проблему с изменением GUID.

1. Верните CSPROJ к зарегистрированной версии.
2. Откройте CSPROJ через текстовый редактор, а НЕ VS.

3. Извлечь значение из исходного файла CSPROJ.

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

4. Откройте файл SLN через текстовый редактор, а НЕ VS.

5. Найдите в решении ссылку на проект.

   Project ("{FAE12345-3210-1357-B3EB-00CA4F396F7C}") = "Some.Project", ".... \ сборки \ Some.Project \ Some.Project.csproj", "{B7654321-5321-4AAE- FE3D-ED20900088ED} "Конечный проект

6. Первый в списке GUID - это GUID решения. Для каждого проекта, указанного в вашем SLN, вы должны увидеть это значение, повторяющееся в первом аргументе. Идентификатор GUID, следующий за .csproj, - это тот, который вы хотите заменить на исходный GUID.

Это должно решить первую проблему, но приземление «Перейти к определению» в метаданных не решено. В нашем SLN-файле есть главный проект (наш веб-сайт), поэтому его запись в SLN-файле должна содержать запись ProjectSection с несколькими значениями GUID. Вот пример:

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

Обратите внимание, что отсутствующий идентификатор GUID в этой коллекции принадлежит моему первому проекту.

1. Добавьте отсутствующий GUID в качестве последней записи между ProjectSection и EndProjectSection. Формат представляется построчным, и это {GUID} = {GUID}.
2. Сохраните файл.
3. Откройте свое решение.
4. Щелкните правой кнопкой мыши ссылку во вновь добавленном проекте и выберите «Перейти к определению».

У меня была циркулярная ссылка между двумя задействованными проектами (а это нет-нет). Пришлось немного реструктурировать свой код, чтобы решить эту проблему, поскольку оба проекта действительно зависели друг от друга. Удаление одной из ссылок решило проблему intellisense. Это было логически ошибочно, и я бы, наверное, не заметил без этой ошибки!

Это сработало для меня:

1. Щелкните правой кнопкой мыши dll в справочной папке в проводнике решений.
2. Удалить файл dll
3. Щелкните правой кнопкой мыши папку Reference, затем
4. Снова добавить ссылку на файл dll

Это может произойти, если вы пытаетесь перейти к определению в проекте, который был выгружен (недоступен). Щелкните правой кнопкой мыши выгруженный проект и выберите «Перезагрузить проект».

Скорее всего, у вас нет отладочной информации. Возможно, у вас есть несколько копий вашей сборки на диске, а с ней нет файла .pdb.

Выполните поиск имен ваших сборок в своих проектах, удалите их все и перестройте.