Visual studio - отримання помилки "Файл метаданих 'XYZ' не вдалося знайти" після продовження редагування

Я натрапив на проблему, яка насправді дратує.
Коли я налагоджую своє програмне забезпечення, все працює нормально, але якщо я досягну точки зупинки та відредагую код, при спробі продовжити роботу з'являється повідомлення про помилку:
Metadata file 'XYZ' could not be found

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

Те, що я намагався дотепер:

• Мій код компілюється та працює.
• Я очистив розчин і перезапустив VS.
• Я переконався, що проект відсутнього файлу будується для конфігурації, яку я запускаю (у менеджері конфігурацій).
• Я вручну створив проект відсутнього файлу.

Додаткова інформація :

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

Будь-які ідеї?

Врешті-решт проблему вирішили:

1. Очистіть кожен проект окремо ( клацніть правою кнопкою миші > Очистити ).
2. Відновіть кожен проект окремо ( клацніть правою кнопкою миші > Відновити ).
3. Відновіть стартовий проект.

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

Редагувати:
Відповідно до коментаря @maplemale, здається, що іноді також потрібно видалення та повторне додавання кожного посилання.

Оновлення 2019:
Це питання отримувало багато трафіку в минулому, але, схоже, з моменту випуску VS 2017 йому було приділено набагато менше уваги.
Отже, ще однією пропозицією буде - оновити до новішої версії VS (> = 2017), і серед інших нових функцій ця проблема також буде вирішена

Наскільки я можу зрозуміти, це трапляється, коли залежності проекту псуються з будь-якої причини (в той час як всі посилання між проектами все ще недоторкані). У багатьох випадках це НЕ проблема коду. А для тих, у кого є кілька проектів, переглядати їх по черзі НЕ прийнятно.

Скинути залежності проекту легко -

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

Тим, у кого в коді є проблема або якась інша проблема, яка спричиняє цю проблему, вам, очевидно, доведеться вирішити цю проблему спочатку.

Однією з можливих причин може бути те, що ви оновили деякі свої проекти (у рішенні) до вищої версії, наприклад з .NET 4.0 до 4.5. Це трапилось у моєму випадку, коли я відкрив рішення у VS 2013 (спочатку створений за допомогою VS 2010 та .NET 4,0). Коли я відкрив у VS 2013 мій проект C ++ оновився до .NET 4.5, і я почав бачити проблему.

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

Я натрапив на ту саму помилку, для вирішення якої спробував кілька кроків. Будь ласка, виконайте всі кроки:

1. Очистіть цілий розчин
2. Клацніть правою кнопкою миші на кожному проекті у вашому рішенні, перейдіть до Властивості та зробіть свій простір імен за замовчуванням, а також ім'я збірки за замовчуванням таким самим, як у вашому коді (тобто простір імен перед назвою класу)
3. Перевірте імена папок для кожного проекту, переглядаючи браузер (де знаходиться рішення вашого проекту). Якщо не відповідає іменам вашого проекту, зробіть його схожим (як крок 2 ) з ними.
4. Видаліть усі посилання з кожного проекту, що стосуються іншого того самого рішення, і додайте його знову.
5. У папці Your Project Solution ви знайдете файл Visual c # Project. Клацніть правою кнопкою миші та відкрийте Блокнот. У початкових рядках ви знайдете рядки для кожного проекту, як показано нижче:

Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "**Client**", "**Client** \ **Client**.csproj", "{4503E259-0E3B-414A-9074-F251684322A5}" EndProject

Перевірте ще раз імена папок (я виділив жирним шрифтом) і зробіть їх схожими на те, що ви зробили на кроці 2 .

6. Знову очистіть весь розчин

7. Побудуйте рішення (якщо не вдається, спробуйте побудувати індивідуального після очищення ще раз)

Переконайтесь, що всі ваші залежні проекти використовують однакову версію .Net Framework. У мене була та сама проблема, спричинена залежним проектом за допомогою 4.5.1, тоді як усі інші використовували 4.5. Зміна проекту з 4.5.1 на 4.5 та відновлення мого рішення вирішили цю проблему для мене.

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

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

Єдине, що мені вдалося, це видалити .suoфайл Solution User Options ( ) . Зверніть увагу, що це прихований файл.

Щоб знайти цей файл, закрийте віртуальну студію та знайдіть .suo у файловому провіднику у своєму проекті.

PS: новий файл .suo буде знову створений під час відновлення проекту, і, сподіваємось, цей нещодавно створений файл не дасть вам проблем.

Сподіваюся, це допоможе комусь позбутися цієї надоїдливої ​​помилки :).

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

Розділ (1):

Загальні рішення:

У мене було 4 помилки подібного роду («файл метаданих не вдалося знайти») разом із 1 помилкою, що «вихідний файл неможливо відкрити (« невизначена помилка »)».

Я намагався позбутися помилки "Файл метаданих не вдалося знайти". Для цього я прочитав багато дописів, блогів тощо і виявив, що ці рішення можуть бути ефективними (узагальнюючи їх тут):

Перезапустіть VS і спробуйте побудувати знову.

Перейдіть до "Solution Explorer". Клацніть правою кнопкою миші на Рішення. Перейдіть до Властивості. Перейдіть до 'Configuration Manager'. Перевірте, чи встановлені прапорці в розділі "Збірка" чи ні. Якщо будь-який або всі з них не позначені, перевірте їх і спробуйте побудувати знову.

Якщо вищевказані рішення не працюють, дотримуйтесь послідовності, згаданої у кроці 2 вище, і навіть якщо всі прапорці встановлені, зніміть їх, знову поставте прапорець та спробуйте побудувати знову.

Замовлення побудови та залежності від проекту:

Перейдіть до "Solution Explorer". Клацніть правою кнопкою миші на Рішення. Перейдіть до розділу "Залежності проекту ...". Ви побачите 2 вкладки: "Залежності" та "Порядок побудови". Цей порядок побудови є тим, в якому будується рішення. Перевірте залежності проекту та порядок побудови, щоб перевірити, чи намагається якийсь проект (скажімо 'project1'), який залежить від іншого (скажімо 'project2'), побудувати до цього (project2). Це може бути причиною помилки.

Перевірте шлях відсутнього .dll:

Перевірте шлях відсутнього .dll. Якщо шлях містить пробіл або будь-який інший неприпустимий символ шляху, видаліть його та спробуйте побудувати знову.

Якщо це причина, відрегулюйте порядок складання.

У мене ця проблема була днями! Я спробував усі речі вище, але проблема постійно поверталася. Коли це повідомлення відображається, воно може мати значення "один або кілька проектів у вашому рішенні не скомпільовано чисто", отже, метадані для файлу ніколи не записувались. Але в моєму випадку я не бачив жодної з інших помилок компілятора !!! Я продовжував намагатися скомпілювати кожне рішення вручну, і лише після того, як VS2012 фактично виявив деякі помилки компілятора, яких я раніше не бачив, ця проблема зникла.

Я обдурив замовлення збірки, жодних замовлень збірки, посилаючись на налагоджувальні DLL-файли (які були скомпільовані вручну) ... Здавалося б, НІЩО не працювало, поки я не знайшов цих помилок, які не виявилися при компіляції всього рішення !!!!

Іноді, здається, під час компіляції компілятор виходить із деяких помилок ... Я бачив це раніше, коли після виправлення проблем наступні компіляції показують НОВІ помилки. Я не знаю, чому це трапляється, і у мене дещо рідко виникають ці проблеми. Однак, коли вони у вас є такі, це справжній біль, намагаючись з’ясувати, що відбувається. Щасти!

Чи використовуєте ви у своєму проекті інструмент генерації коду бази даних, такий як SQLMETAL?

Якщо так, можливо, ви зіткнулися з проблемою переходу від плюралізованої до неплюралізованої системи.

У моєму випадку я зауважив, що деякі старі плюралізовані (*) імена таблиць (до яких SQLMETAL за замовчуванням додає літеру " s " в кінці) посилаються на класи, що створюються SQLMETAL.

Оскільки нещодавно я вимкнув плюралізацію імен , після відновлення деяких класів, пов’язаних з базою даних, деякі з них втратили префікс " s ". Отже, всі посилання на пошкоджені класи таблиць стали недійсними. З цієї причини у мене є кілька помилок компіляції, наприклад, такі:

'xxxx' не містить визначення для 'TableNames', і не може бути знайдено жодного методу розширення 'TableNames', що приймає перший аргумент типу 'yyyy' (вам не вистачає директиви using або посилання на збірку?)

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

Після фіксації посилань на таблиці класів, що постраждали, вручну на їхні поточні імена (неплюралізовані), я, нарешті, зміг повернути свій проект до життя!

(*) Якщо параметр Visual Studio> Меню Інструменти > Параметри > Інструменти бази даних > Конструктор O / R > Плюралізація імен увімкнено, деякий генератор коду SQLMETALl додасть літеру « s » в кінці деяких сформованих класів таблиць, хоча таблиця має немає суфікса "s" у цільовій базі даних. Для отримання додаткової інформації див. Http://msdn.microsoft.com/en-us/library/bb386987(v=vs.110).aspx

Сподіваюся, це допоможе!

У мене виникла ця помилка. Я дотримувався всіх рішень тут, але нічого не працювало. Я використовував Visual Studio 2013 Professional. Я не зміг змусити відновити роботу окремого проекту, і нарешті зрозумів, що в моїх посиланнях є кругова залежність . Visual Studio зазвичай виконує досить гарну роботу, попереджаючи вас, якщо ви додаєте посилання на те, що посилається назад, але з певних причин цього не сталося. Я додав посилання на проект, який посилався на проект, над яким я працював, - і він прийняв його. Можливо, помилка проти?

Мої 5 центів.

Ця проблема почалася після рішення, яке було чистим.

Мені вдалося зникнути проблему, встановивши конфігурацію Active Solution у: Build -> Configuration manager для випуску. Потім побудуйте та знову встановіть його для налагодження. Після цього збірка була успішною.

Закрийте VS, знайдіть і видаліть папку 'пакети' зовні візуальної студії. Перезапустіть VS та побудуйте -> усі залежності будуть переінстальовані

Спільнота Visual Studio 2019 16.3.10 У
мене була подібна проблема зі збіркою випусків. Збірка налагодження компілювалася без жодних проблем. Виявляється, проблему спричинив OneDrive. Швидше за все, подібні проблеми можуть виникнути з будь-яким резервним накопичувачем або хмарною службою.

Я очистив усе згідно чудової відповіді Аві Тернера.

Крім того, я вручну видалив папку \ obj \ Release -folder зі своєї папки OneDrive, а також увійшов до OneDrive за допомогою браузера та видалив там папку, щоб також не дати OneDrive завантажити хмарну версію назад під час компіляції.
Після цього відбудували і все запрацювало як слід.

це відбувається через різницю імен у назві папки та назві простору імен. Якщо u створити простір імен у певному імені, а пізніше ви його перейменуєте, простір імен матиме старе ім'я. І компіляція піде старим шляхом, щоб знайти файл .dllі .exe. Щоб уникнути цього, відкрийте .csprojфайл кожного простору імен текстовим файлом і знайдіть у файлі старий шлях.

видаліть це, очистіть і відновіть розчин. Це спрацювало для мене. Я цілий день працював над цією проблемою.

У мене було це, і мені вдалося це виправити за допомогою цієї відповіді SO: Файл метаданих '.dll' не вдалося знайти

Мені довелося зняти всі прапорці, натиснути Застосувати, увімкнути всі прапорці, а потім знову застосувати, але проблему вирішено.

Я щойно зіткнувся з цією проблемою, і після години викручування зрозумів, що додав файл aspx до свого продукту, який мав те саме ім'я, що й один із моїх класів Linq-To-Sql .
Клас і сторінка, де "Черга".
Змінив сторінку на QueueMgr.aspx, і все побудовано просто чудово.

Для нової збірки може бути, що деякі залежності не встановлені. Для мене це були Crystal Reports.

Це трапляється, коли одна DLL проекту не працює, і це посилається на кількість проектів. Тож спочатку виправте це, а потім будуйте людей.

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

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

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

Історія для мене полягала в тому, що я випадково змінив невеликий рядок коду серед тисяч файлів класу c #, а потім намагався відновити рішення. Як ви могли собі уявити, у мене виявилося більше 40 файлів метаданих, в яких відсутні помилки, і з ними одна помилка компіляції - яку я не ретельно перевіряв, чисто думаючи, що всі помилки однакові!

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

Невдала відповідь на вашу проблему, але сподіваюся, мій випадок не збігався з вашим.

У мене була та сама проблема. У моєму випадку я помилково встановив усі проекти крім проекту за допомогою основного методу як консольного додатка.

Для вирішення я перейшов до кожного проекту, крім проекту з основною функцією, і клацнув правою кнопкою миші> Properites> Тип виводу> Бібліотека класів

це трапилося зі мною, тому що у мене дивне зіткнення в просторах імен: у мене була AssemblyA з простором імен AssemblyA.ParentNamespace відьма визначає ClassA, а в тій самій збірці інший простір імен з ім'ям AssemblyA.ParentNamespace.ChildNamespace відьма визначає інший ClassA (але з те саме ім'я)

Тоді я мав у AssemblyA.ParentNamespace IInterfaceB відьму метод, який спочатку повертає IEnumerable, а відьма ClassB реалізує IInterfaceB

Пізніше я модифікував метод у ClassB, щоб повернути IEnumerable, але я забув оновити визначення IInterfaceB, тому метод все ще повертав IEnumerable, найцікавішим фактом було те, що рішення все ще компілюється, якщо я перероблюю все, але відьма тестує посилається на AssemblyA не спрацював і повертає помилку "Файл метаданих не вдалося знайти".

оновлення InterfaceB, щоб правильно повернути IEnumerable, оскільки його реалізатор ClassB вирішив проблему, на жаль, повідомлення про помилку було неясним, а також той факт, що компіляція спрацювала, змушує мене припустити, що, можливо, є щось виправити в компіляторі

Співробітник стикався з цією проблемою, і причина уникала нас. Врешті-решт ми зрозуміли, що каталог проекту (і, отже, шлях до пакетів NuGet) містив %20(спасибі, якийсь інструмент Git gui, який не буде називатися), і повідомлення про помилки показали, що компілятор шукав дуже схожий на вигляд шлях, але один який повинен був %20, скоріше простір. Очевидно, щось у системі збірки десь виконує HTML-декодування на локальних шляхах файлової системи.

Перейменовано каталог робочих копій, і все почало працювати.

У мене теж було це питання.

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

Після їх перевірки всі помилки зникнуть, залишивши лише помилку "Файл метаданих ... debug \ application.exe не вдалося знайти".

Я вирішив це, заглянувши у вікно виводу збірки, щоб знайти, які класи були дубльовані.

Потім клацніть правою кнопкою миші назву класу та "перейдіть до визначення".

можна буде вибрати два визначення, відкрийте обидва, друге визначення, здається, знову відкриє той самий файл, проте друге визначить джерелом помилки (червоне підкреслення).

Видаліть весь код із файлу та збережіть (Це не вплине на ваш фактичний файл).
Тепер це слід правильно скомпілювати.

Переконайтеся, що на шляху до вашого проекту немає пробілів ...

Я використовую Windows 10 з Visual Studio Community 2019, і я клонував рішення для декількох проектів, як це було з репозитарію GIT. У мене була ця помилка з усіма іншими залежностями у рішенні разом із помилкою E_POINTER . Його шлях, успадкований від GIT, мав пробіли, такі як C: / repos / МОЯ НАЗВА ПРОЕКТУ / ...

Я видалив його, клонував ще раз і переконався, що шлях не містить пробілів, таких як C: / repos / MY_PROJECT_NAME / ...

Це вирішило мою проблему.

У мене теж було таке ж питання.

У моєму випадку я нещодавно додав внутрішній клас десь у проекті. Одна із залежностей у рішенні має однакову назву класу, і обидві вони правильно додані до посилань.

Я змінив свою останню активність та перебудову, це працює.

Переконайтеся, що повідомлення компілятора є дійсними. У моєму випадку я виявляю посилання на помилку звідти, не вказане як помилка у списку помилок.