Помилка "Файл метаданих" ... \ Release \ project.dll "не вдалося знайти у Visual Studio"

Нещодавно я почав отримувати це повідомлення випадковим чином:

Файл метаданих '... \ Release \ project.dll' не вдалося знайти у Visual Studio

У мене є рішення з кількома проектами в ньому. Поточний режим збірки - «Налагодження», а всі конфігурації проектів встановлюються на «Налагодження». Але коли я намагаюся запустити основний проект - іноді він дає мені кілька помилок, усі з яких "Файл метаданих" ... \ Release \ projectX.dll 'не вдалося знайти "- і, дивіться, це говорить про ЗВІЙТЕ папка, хоча поточний режим - налагодження. Чому? Я намагався шукати посилання на "Випуск \ projectX.dll" у всіх файлах рішення, і знайшов його у файлі ResolveAssemblyReference.cache.

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

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

Начебто помилка. Чому він шукає посилання на проекти в папках Release, коли я завжди використовую режим налагодження?

PS. Для тих, хто зіткнувся з цією проблемою: я не міг її вирішити просто. Він зник лише після того, як я перевстановив Windows :(

Всі правильно ... спробуйте все ... (для того, щоб витратити трохи часу на багато часу)

1. У вас поганий код? Виправте це першим.
2. Очищення рішення та перезапуск Visual Studio
3. Видалити / Додати посилання
4. Перевірте свій замовлення на збір з більшими проектами та перевірте
5. Вручну відновити підпроекти
6. Копіюйте файли між проектами вручну в пов'язані папки
7. Іди, попити кави, пограти в пінбол і повернутися завтра ... Ти можеш придумати щось інше.

У мене була точно така ж проблема. Велике візуальне студійне рішення з 50+ проектами.

Всі посилання були додані як проекти. Порядок складання проекту був правильним (клацніть правою кнопкою миші на проект та виберіть порядок складання).

Однак, будуючи деякі проекти вищого рівня, проект «корінь», від якого вони залежали, не будувався.

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

Щоб перевірити це, виберіть "Менеджер конфігурацій" (меню "Збірка") і перевірте, чи налаштовані проблемні проекти.

Коли ви скажете, що ви видалили посилання на ці проекти та повторно додали їх, як саме ви їх повторно додали? Чи використовували ви вкладку "Огляд" у діалоговому вікні "Додати довідку" у Visual Studio? Або ви використовували вкладку "Проекти" (яка перераховує сусідні проекти у вашому рішенні)?

Редагувати : Якщо ви використовуєте вкладку «Огляд» і вручну додаєте посилання на свій .dll, який знаходиться в папці / Випуск, то Visual Studio завжди шукатиме .dll у цьому місці, незалежно від того, у якому режимі ви перебуваєте наразі перебуває у (Налагодження чи випуск).

Якщо ви видалили фактичний .dll файл із папки Release (вручну або виконавши "Очищення рішення"), то ваша посилання порушиться, оскільки .dll не існує.

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

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

Розділ (1):

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

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

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

1. Перезапустіть VS та спробуйте створити його ще раз.

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

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

4. Залежності замовлення та проекту:

   Перейдіть до "Провідник рішень" . Клацніть правою кнопкою миші рішення. Перейдіть до розділу "Залежності проекту ..." . Ви побачите 2 вкладки: "Залежності" та "Порядок побудови" . Цей порядок побудови - це той, в якому будується рішення. Перевірте залежність проекту та порядок побудови, щоб перевірити, чи намагається якийсь проект (скажімо, «проект1»), який залежить від інших (скажімо, «проект2»), створити перед цим (проект2). Це може бути причиною помилки.

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

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

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

   ---

Розділ (2):

Мій конкретний випадок:

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

Отже, я вирішив позбутися від іншої помилки, на яку я зіткнувся ("Не вдалося відкрити вихідний файл (" Невизначена помилка ")").

Я натрапив на блог: http://www.anujvarma.com/tfs-errorsource-file-could-not-be-opened-unspecified-error/#comment-1539

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

Розділ (3):

Мораль історії:

Спробуйте всі рішення, як зазначено в розділі (1) вище (та будь-які інші рішення), щоб позбутися від помилки. Якщо нічого не виходить, відповідно до блогу, згаданого в розділі (2) вище, видаліть записи всіх вихідних файлів, які більше відсутні в керуванні джерелами та файловій системі з вашого .csproj-файлу .

У мене була ця проблема раніше, і єдиний спосіб, який я вирішив її вирішити, - це запустити Clean Solution і перезапустити Visual Studio.

Для мене зазвичай цільова рамка відключається (4.5.2 замість 4.6) Якщо ви зафіксуєте цільову рамку проекту, щоб вона відповідала цільовій структурі рішення та будувала, буде створений новий .dll.

Відкрийте Visual Studio як адміністратор.

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

Ви перевірили настройки менеджера конфігурацій? У діалоговому вікні налаштувань проекту у верхньому правому куті.

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

Я також бачив цю помилку в рішеннях, де у мене є кілька проектів (зазвичай це проекти NetTiers, де я оновив один або кілька підпроектів, щоб орієнтуватися на рамки 4.0). Видалити це може бути проблематично. Часто це можна вирішити, спочатку виправляючи всі інші помилки в підпроектах (наприклад, будь-які відсутні посилання), індивідуально відновлюючи ці підпроекти, потім видаляючи / додаючи назад будь-які посилання на ці підпроекти у Visual Studio. Особисто мені пощастило вирішити цю помилку, очистивши розчин самостійно.

Нещодавно ми стикалися з цим питанням після оновлення до Office 2010 з Office 2007 - нам довелося вручну змінити посилання в нашому проекті на версію 14 Office Interops, яку ми використовуємо в деяких проектах.

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

У моєму випадку це було викликано двома речами (VS.2012):

1) Один з проектів був налаштований для AnyCPU замість x86

2) У проекті, на який було посилано, якось не було встановлено прапорець "Побудувати".

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

У моєму випадку у мого коду були деякі помилки. Visual Studio показала помилку, яку ви мали замість фактичних помилок, як синтаксичні помилки чи невідомі назви класів. Спробуйте очистити рішення та проект будівництва за проектом. Таким чином ви виявите фактичні помилки.

Знову-таки, саме це викликає помилку для мене .

У мене була ця проблема і знадобилося багато часу, щоб її розібратися. Проблема виникла, коли я видалив проекти з рішення та замінив їх на нуті пакети.

Рішення здавалося гарним, але файл .csproj все ще містив ці проекти кілька разів як посилання.

Здається, що VS не очищує цей файл належним чином. Це все ще посилалося на зняті проекти під кришкою. Коли вручну видалено посилання з файлу csproj, все працює знову! wohoo

Ця проблема пов’язана з файлами pdb або CodeContracts.

Щоб вирішити це:

1. Очистіть вихідну папку та відновіть рішення.

2. Переконфігуруйте CodeContracts або відключіть її для тимчасової збірки.

У нас ця проблема виникає досить часто, але лише з посиланнями на проекти C ++ / CLI з проектів C #. Очевидно, що помилка в глибині Visual Studio, що Microsoft вирішила не виправляти, оскільки це "занадто складно", і вони пообіцяли капітальний ремонт системи побудови C ++, яка зараз орієнтована на Visual Studio 2010.

Це було деякий час тому, і, можливо, виправлення навіть увійшло до Visual Studio 2008; Я більше не стежив за цим. Однак наше типове рішення було

• Конфігурація комутатора
• Перезапустіть Visual Studio
• Побудуйте рішення

У мене була така сама проблема.

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

Тож я перейшов усе на версію 4.5, і це знову спрацювало.

Я, мабуть, пригадую подібну проблему кілька місяців тому. Я вирішив це тимчасово, скопіювавши посилання DLL у папку Release, тим самим задовольнивши очікування Visual Studio. Пізніше я виявив посилання на випуск DLL у своєму фактичному коді. Спробуйте здійснити пошук у всьому проекті для \ release \ project.dll.

Крім того, я помітив, що тестові проекти Visual Studio іноді ставлять атрибут "DeploymentItem" на кожен із методів тестування, що вказує на вашу цільову DLL, і якщо ви переключитесь між налагодженням та випуском, Visual Studio може заплутатися, якщо DLL більше не буде в очікуваному місці. На мій досвід, ці атрибути можна безпечно видалити, якщо ви їх самі не помістили як частину сценарію "єдиного розгортання".

У мене виникла ця проблема, і це було пов’язано з невірним методом у бібліотеці, що порушує право (dll), яка не повернула значення, наприклад

public bool DoSomething()
{
   //I never bothered putting code here....

}

Коли я прокоментував це, все складене :)

Іноді VS2010 перемикає мою конфігурацію з будь-якого процесора на змішану платформу. Коли це відбувається, я отримую це повідомлення про помилку.

Щоб вирішити це питання, я перемикаюся на будь-який процесор:
1. Клацніть правою кнопкою миші рішення та виберіть властивості.
2. Клацніть на «Властивості конфігурації», а потім на кнопку «Менеджер конфігурацій ...
3. У розділі Платформа активного рішення виберіть Будь-який процесор

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

Я в остаточному підсумку видалив свої посилання (я правильно їх додав на вкладці "Проекти", і вони створювали просто чудово), вручну редагувавши мої файли .csproj та видаляючи химерні записи, які не належали - і встановлював мої вихідні дані для налагодження та release, x86 та x64 та будь-який процесор для всіх бути "\ bin" - я створив його один раз, потім повторно додав посилання (знову, використовуючи вкладку "проекти"), і все знову почало працювати для мене. Зовсім не довелося перезапускати Visual Studio.

Для мене це було спричинено тим, що ціль Build була переписана, щоб не виводити dll. Вилучивши це, щоб повернутися до цілі збірки за замовчуванням, виправлена ​​проблема.

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

Здається, це відбувається, коли ви замовляєте рішення з кількома проектами, на які є посилання між ними, і ви ще не будували його раніше. Якщо у вас є посилання безпосередньо на dll, замість посилання на проект, ви отримаєте це повідомлення. Ви завжди повинні використовувати вкладку "Проекти" у діалоговому вікні "Додати довідку", щоб додати посилання на проект у тому самому рішенні. Таким чином, VS може знати правильний порядок побудови рішення

те саме сталося сьогодні зі мною, як описав Відар

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

Чи є налаштування в VS для покращення цього?

У мене була така ж проблема. Я помітив, що мій db контекст (EF4), який знаходився в проекті dll, чомусь не розпізнавався. Я видалив його і створив інший замість цього. і це вирішило це для мене.

Була така ж проблема і сьогодні.

Моя програма, програма Windows Forms, випадково мала посилання на себе. Дивно.

Після видалення помилка зникла.

Посилання додається щоразу, коли я перетягував у форму управління користувача, розташоване в самому проекті Windows Forms.

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

Рішення: Оскільки мої dll були там для папки ... \ bin \ Release , я спробував відновити режим випуску і виявив помилку в одному рядку в одному з підпроектів. Вирішення помилки та відновлення рішення позбулося помилки збірки.

Для мене Visual Studio створив ім'я проекту.v11 типу "Параметри користувача Visual Studio Solution". Я видалив цей файл і перезапустив, і все було добре.