"Перейти до визначення" у Visual Studio відображає лише метадані


132

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

Деякі очки:

  • Весь вихідний код - це C #, VB.Net немає
  • Усі проекти знаходяться в одному рішенні
  • Все є посиланням на проект на відміну від посилання на файл (перевірено та перевірено)
  • Я спробував підходи «Очистити / відновити рішення» (навіть до моменту очищення каталогу Temp, каталогу тимчасових файлів ASP.NET тощо).

Хтось ще бачив таку поведінку та / або знає, як її виправити?


У мене ця проблема була лише в змішаних рішеннях з vb.net та c # в різних посилаються проектах. Дивно: /
Байард Рендел


Для мене перезапуск Visual Studio виправив цю проблему (у проекті .net Core в рамках мультипроектного рішення).
niico

Відповіді:


59

Що ж, інший розробник знайшов відповідь. Конкретний проект, з яким ми мали проблему, спочатку був доданий як посилання на файл, потім видалений та доданий як Довідник проекту. Visual Studio, однак, зберігається у файлі csproj для веб-сайту, викликаючи проблему. Він увійшов і вручну відредагував файл csproj, щоб видалити посилання файлу на проблемний проект, і все зараз виправлено


Це чудова інформація. Мені цікаво дізнатись, чи встановлено у вас SP1?
NotMe

добре, якби я міг знайти цю інформацію будь-де в Інтернеті, я б сказав вам. Я запускаю VS 2008 9.0.21022.8 RTM, але буду проклятий, якщо зможу знайти де-небудь, якщо це відповідає VS 2008 SP1 або оригіналу
pfunk

Чудово, дякую - це мені допомагає. Він повинен бути ProjectReference у файлі csproj, якщо відкрити його за допомогою редактора text / xml. Будь-який інший слід видалити.
Віктор Гельмутдінов

3
Це також може статися, якщо GUID у ProjectReference не відповідає значенню ProjectGuid у проекті, що посилається
Девід Гардінер

Дякую! Проблеми подібного роду досі зберігаються в MSVS
Алекс

42

Це трапляється, коли ви не додаєте посилання як проект, але вказуєте на dll або exe, використовуючи вкладку «Огляд» у діалоговому вікні «Додати довідку». Якщо ви додаєте посилання на вкладці Проекти, вам слід перейти безпосередньо до вихідного коду, коли ви виберете «Перейти до визначення».

Однак якщо ви встановите ReSharper , ви перейдете до вихідного коду, навіть якщо ви додали посилання на dll / exe за допомогою вкладки Огляд.


39

Схоже, це потрібно налаштувати і в Resharper. Моя Visual Studio не переходить до вихідного коду .NET Framework, поки я не ввімкну його в Resharper.

Налаштування повторної горілки, щоб дозволити перехід до зовнішнього джерела


1
Привіт, це працює для мене. Це вирішило цю проблему. Використовуючи VS2015 Update 3, ReSharper 2016.1.2
Michal

25

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

2. видаліть прихований <name of the solution>.suo-файл у папці, де <name of the solution>існує .sln-файл вашого рішення .

3. відкрийте своє рішення.

4. відновити своє рішення.


7
Це був варіант, який працював на мене. Однак я використовую VS2019 RC (16.0.0) і мені довелося видалити файл .sou за адресою .vs \ {ProjectName} \ v16
Nick DeVore

1
Прибирав це і для мене. Використовуючи VS2017, .sou-файли знаходилися в декількох місцях - ".vs \ <ProjectName> \ v15", так само, як Нік зазначив, що файл VS2019 .sou знаходиться у підпотоку V16. Зауважте, що у мене також був підкаталог "... V14", мабуть, з попереднього VS2015, який я використовував у тому самому рішенні перед оновленням до 2017 року. Очищено їх і всі проблеми усунулися.
BRebey

1
* .suo not .sou - власне розширення файлу
Mike Cheel

1
Те саме в Visual Studio 2019. Закрийте рішення, відкрийте рішення у файлі провідника, знайдіть .suo-файли та видаліть їх усі. Повторно відкрийте рішення і воно працює знову.
yesman

Цей Варіант працював на мене, дякую. Для VS2019 видаліть vs папку та відкрийте проект
Ashi

21

Для тих, хто використовує VS 2017 (я зараз у версії 15.3.4) ось прості кроки:

  1. Відкрийте своє рішення в Провіднику Windows і закрийте Visual Studio
  2. У меню Explorer виберіть Переглянути та переконайтесь, що прапорець "Приховані елементи" позначено
  3. Перейдіть до підпапки .vs\[your solution name]\v15
  4. Видаліть .suoфайл
  5. Перезапустіть VS і складіть своє рішення

Це вирішило для мене: F12 відкрив фактичний вихідний файл, а не версію "з метаданих".


Як зазначається в коментарях в інших місцях, каталог V16, якщо ви використовуєте VS2019.
Отіс

10

Візуальна студія часто страждає від проблеми переходу до метаданих, а не вашого проекту, якщо ви зміните місце, де ви будуєте проект, тобто у вас може бути кілька версій, щоб перевірити речі.

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


8

Позначене рішення не завжди працює. Ви повинні переконатися, що посилання GUID проекту у файлах проекту є правильним GUID для проекту, на який ви намагаєтесь посилатися. Visual Studio дійсно дозволяє їм вийти з синхронізації за деяких обставин. Ви можете отримати GUID проекту з файлу проекту за допомогою текстового редактора. Отже, якщо проект Довідковий проект B. Відкрийте проект B.csproj в текстовому редакторі, скопіюйте GUID проекту з тегу. Потім відкрийте проект A.csproj в текстовому редакторі та переконайтеся, що ви використовуєте правильний GUID. Шукайте назву проекту "B" у цьому випадку. Це повинно бути в. Замініть GUID у тегу правильним. Збережіть і перезавантажте. Звичайно, також переконайтесь, що файли посилань на ваші проекти видалені. Вам потрібні лише посилання на проекти.


6

Я вбив усі екземпляри VS, видалив SUO, запустив sln і він працював на мене ...


У мене стався несподіваний збій msbuild, а згодом виникли різні проблеми, включаючи цю. Це вирішило це питання. Дивно.
Кріс Лукич

3

Видаліть довідковий dll, Build (отримає помилки), ADD THE Reference (ви видалили), а потім побудуйте знову ... F12 на вашій функції тоді повинен працювати (працював для мене).


2

Я зрозумів, як вирішити свою проблему з цієї посади , можливо, це теж спрацює для когось із вас.

Я дотримувався цих кроків:

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

(Я вважаю, що або крок 3 або 4 відновлює файл бази даних intellisense, коли він відсутній)

Intellisense "перейти до визначення" та "знайти всі посилання" має працювати знову.


2

У моєму випадку (використовуючи Visual Studio Professional 2015), коли я відключив конструктор XAML, F12 перестав працювати. Як тільки я відновив зміни та перезапустив Visual Studio, F12 знову працював.

Перевіряли шаблон кілька разів, щоб підтвердити, а потім опублікували. Сподіваюся, це комусь допоможе.


1

Симптом:

Visual Studio 2010 Ultimate неодноразово не знаходив посилань на функції, #defines, включає в себе тощо при використанні функцій "Перейти до визначення" або "Перейти до декларації" або "Знайти всі посилання" - як не дивно, Intellisense працював.

Виправити:

  1. Закрити Visual Studio
  2. Видаліть (перейменуйте, якщо хочете бути консервативним) .sdf-файл рішення
  3. Відкрийте візуальну студію

.Sdf-файл буде автоматично відновлений шляхом розбору файлів, що включають у ваше рішення


2
@alestanis Можливо, ця відповідь не вирішила проблеми для всіх.
nuzzolilo

@alestanis У мене проблема в ОП, але прийнята відповідь мені не допомогла .... Можливо, нам слід просто видалити всі питання, на які є прийнята відповідь?
Карл

1

Для мене рішення GUID не працювало, і я не зміг знайти свій .ncb файл. (А може, я лінивий і не виглядав досить важко, але це не важливо.) Перебудова та перезапуск візуальної студії також не допомогли.

Що я зробив, це закрити візуальну студію і видалити .dll і .pdb, на які посилаються у верхній частині файлу Meta Data, на який мій інтеліссенс посилався. У моєму випадку це означало, що я видалив свій .dll і його .pdb файл з Utilities / bin / Release. (Утиліти - це назва проекту .dll, з яким у мене виникли проблеми.) Потім я перезапустив візуальну студію та відновив .dll, а потім все рішення. Більше проблем немає!


1

Щойно знайшов ще одну причину. Я покращив свій веб-проект до 4.0, але залишив бібліотеки класів на рівні 2.0. Тоді всі бібліотеки класів у моєму рішенні розглядалися як посилання на файли з мого веб-проекту. Може допомогти комусь іншому ...


1

Я зіткнувся з тим же питанням, і один з колег дав мені наступне рішення, і воно спрацювало! Якщо жодне з перерахованого вище не працює для вас,

  1. Видаліть усі посилання та додайте їх назад (переконайтесь, що шлях правильний)
  2. Перейдіть до властивостей Solution та перевірте залежність проектів усіх проектів. Переконайтеся, що проект, який ви будете використовувати, доданий як залежний у проект, над яким ви працюєте.

1

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

  1. просто не вибрано довідковий проект.
  2. зберегти рішення.
  3. вибрати той же проект.
  4. Відновіть рішення.

Проблема сортована. Сподіваюся, це допоможе комусь.


1

Нижче кроки працювали на мене.

  1. Перейдіть у файл .csproj
  2. Відкрийте його в Блокноті Перейдіть до рядка, де посилається dll.<Reference Include="">
  3. Видаліть рядок

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

1

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


1

№1

Поставте прапорець "Перегляд - браузер об'єктів", і якщо ви бачите більше однієї збірки з такою ж назвою - саме тому ви отримуєте цю помилку.

Для нас це була помилка у VS 2019:

Якщо у вас в App_Codeпапці ASP.NET "помічники Razor", Visual Studio 2019 інтерпретує це як інша збірка, але з тим же ім'ям, що приховує фактичну збірку.

Немає жодного виправлення, крім того, щоб переписати цих помічників на часткові перегляди чи HTML-помічники (це все одно доведеться робити, якщо ви плануєте перейти на .NET Core).

Дивіться це рішення на веб-сайті MS і будь ласка, виправте помилку там, щоб MS виправила її

https://developercommunity.visualstudio.com/solutions/1008795/view.html (будь ласка, піднесіть заявку)

№2

Ще одна причина, чому таку ж збірку можна два рази завантажувати в браузер об’єктів, - якщо у вас є проект-тест, який запускає процес iis-express і ніколи не вбиває його належним чином.


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

0

У моєму випадку я нещодавно змінився

<mvcBuildViews>

до "true" у файлі .csproj мого сайту (щоб знайти помилки компіляції у файлах перегляду Razor: http://forums.asp.net/t/1909113.aspx?How+to+have+Visual+Studio+2012+returned + компілювати + помилки + на + розрив + синтаксис + помилка + в + asp + net + web + сторінка + 2 + ), і коли я потім будував, я отримував помилки з мого веб-сайту / obj / налагодження / каталог. З будь-якого з цих файлів (які застаріли), клацнути правою кнопкою миші та вибрати "Перейти до визначення", ви отримаєте версію [метадані].

Тож для мене жодне з рішень тут не працювало, тому що я не починав з файлу, який був насправді в моєму проекті. Видалено всю цілу / obj / налагодження / каталог, помилки відійшли, і з будь-якого звичайного файлу я можу правильно використовувати перейти до визначення.


0

Я щойно зіткнувся з цією проблемою на 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.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. Клацніть правою кнопкою миші посилання в нещодавно доданому проекті та перейдіть до визначення.

0

Я мав циркулярну довідку між двома залученими проектами (що є ні-ні). Довелося трохи реструктурувати мій код, щоб вирішити його, оскільки обидва проекти справді залежали один від одного. Видалення однієї з посилань вирішило проблему інтелігенції. Це було логічно хибно, і я, мабуть, не помітив би без цієї помилки!


0

Цей працював на мене:

  1. Клацніть правою кнопкою миші dll у довідковій папці у вашому провіднику рішень
  2. Видаліть файл dll
  3. Клацніть правою кнопкою миші папку Довідник
  4. Додайте посилання на файл dll ще раз

0

Це може статися, якщо ви намагаєтеся перейти до визначення проекту, який було вивантажено (Недоступно). Клацніть правою кнопкою миші вивантажений проект і виберіть "Перезавантажити проект".


-1

Найкраща здогадка - це те, що у вас немає інформації про налагодження. Можливо, у вас є кілька копій вашої збірки на диску, і у неї немає .pdb-файлу.

Зробіть пошук назв збірок зі своїх проектів та видаліть їх усіх та відновіть.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.