Не вдалося знайти файл метаданих ".dll"

Я працюю над проектом WPF, C # 3.0, і я отримую цю помилку:

Error 1 Metadata file
'WORK=- \Tools\VersionManagementSystem\BusinessLogicLayer\bin\Debug
\BusinessLogicLayer.dll' could not be found C:\-=WORK=- \Tools
\VersionManagementSystem\VersionManagementSystem\CSC VersionManagementSystem

Ось як я посилаюся на свої користувальницькі контролі:

xmlns:vms="clr-namespace:VersionManagementSystem"
<vms:SignOffProjectListing Margin="5"/>

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

Я перевірив конфігурації замовлень та конфігурацій залежностей.

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

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

У мене просто була така ж проблема. Visual Studio не будує проект, на який посилається.

Письмові інструкції:

1. Клацніть правою кнопкою миші рішення та натисніть кнопку Властивості.
2. Клацніть конфігурація зліва.
3. Переконайтесь, що прапорець "Збірка" для проекту, який він не може знайти, встановлений. Якщо це вже встановлено, зніміть прапорець, натисніть кнопку застосувати та встановіть прапорці ще раз.
4. (Необов’язково) Вам довелося це зробити і для режимів випуску, і для налагодження властивостей рішення.

Інструкції з захоплення екрана:

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

Це все ще може статися в нових версіях Visual Studio (у мене якраз це було в Visual Studio 2013):

Ще потрібно спробувати закрити Visual Studio і видалити .suoфайл, який знаходиться поруч із .slnфайлом. (Він буде повторно згенерований наступного разу Save all(або вийти з Visual Studio)).

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

Зауважте, що видалення .suoфайлу скине проект запуску рішення.

Більше про .suoфайл тут .

Запропонована відповідь не спрацювала для мене. Помилка є приманкою для іншої проблеми.

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

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

Розділ (1):

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

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

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

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

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

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

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

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

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

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

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

Розділ (2):

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

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

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

Я натрапив на повідомлення в блозі: помилка TFS - вихідний файл не вдалося відкрити ("Не визначена помилка")

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

Розділ (3):

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

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

У моєму випадку це було викликано невідповідністю версії .NET Framework.

Один проект - 3,5, а інший - проект 4.6.1.

Закриття та повторне відкриття Visual Studio 2013 працювало на мене!

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

Мені здавалося очевидним, що ця неправильна посилання на файл мета-даних повинна десь міститися.

Швидкий пошук файлу .csproj показав винні рядки. У мене був розділ під назвою <itemGroup>, який, здається, висить на старій неправильній файловій стежці.

<ItemGroup>
    <ProjectReference Include="..\..\..\MySiteOld\MySite.Entities\MySite.Entities.csproj">
        <Project>{5b0a347e-cd9a-4746-a3b6-99d6d010a6c2}</Project>
        <Name>Beeyp.Entities</Name>
    </ProjectReference>
...

Тож справді просте виправлення:

1. Створіть резервну копію файлу .csproj.
2. Знайдіть неправильні шляхи у файлі .csproj та перейменуйте відповідним чином.

Будь ласка, переконайтесь, що ви створили резервну копію свого старого .csproj перед тим, як переглядати .

Я також зустрів цю проблему. По-перше, ви повинні вручну скласти ваш DLL-проект, клацнувши правою кнопкою миші, Створити. Тоді це спрацює.

У моєму випадку я маю встановлений каталог помилково.

Якщо ваш шлях рішення є чимось на кшталт "Мій проект% 2c Дуже популярний Тестування модуля% 2c%% 2c Software and Hardware.zip", він не може вирішити файл метаданих, можливо, ми повинні запобігти деяким невірним словам, наприклад% 2c.

Перейменування шляху на звичайну назву вирішило мою проблему.

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

Visual Studio 2019 це працювало для мене:

1. Закрити Visual Studio
2. Видаліть приховану .vsпапку
3. Повторно відкрийте Visual Studio і відновіть рішення.

Для мене вона намагалася знайти DLL в шляху, який містив проект, але ми перемістили його в новий каталог. Рішення пройшло правильний шлях до Проекту, але Visual Studio якось продовжував шукати в старому місці.

Рішення: Перейменуйте кожну проблему Проект - просто додайте символ чи що завгодно - потім перейменуйте його на початкове ім’я.

Це має скинути якийсь глобальний кеш-пам'ять у Visual Studio, оскільки це очищує як цю проблему, так і декілька подібних до неї, тоді як такі речі, як Clean, не роблять.

Я додав новий проект до свого рішення і почав отримувати це.

Причина? Проект, який я взяв за мету, орієнтувався на інший .NET-фреймворк (4.6, а інші два - 4.5.2)

Для мене це сталося, коли я включав новий проект до рішення.

Visual Studio автоматично вибирає .NET Framework 4.5.

Я змінив версію .NET 4.5.2, як і інші бібліотеки, і вона працювала.

Для мене спрацювали наступні кроки:

• Знайдіть проект, який не будує
• Видаліть / додайте посилання на проекти в рамках рішення.

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

Потім я закрив Visual Studio 2013, знову відкрив своє рішення і воно склало чудово.

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

Схоже, такі помилки пов'язані з тим, що Visual Studio не надає правильної інформації про помилку. Розробник навіть не розуміє причину невдалої збірки. Це може бути синтаксична помилка чи щось інше. Як правило, для вирішення таких проблем вам слід знайти корінь проблеми (наприклад, подивитися журнал збірки).

У моєму випадку проблема полягала в тому, що у Error Listвікні не було помилок. Але насправді були синтаксичні помилки; Я знайшов ці помилки у Outputвікні, і після їх виправлення проблема була вирішена.

Мій приклад проблеми був викликаний спільним проектом, який мав у ньому дублікат імені класу (під іншим іменем файлу). Дивно, що Visual Studio не міг цього виявити, а натомість просто підірвав процес збирання.

Я отримав цю проблему у Visual Studio 2012 за рішенням, в якому було багато проектів. Перебудовуючи кожен проект у рішенні вручну в тому ж порядку, що і Порядок збирання проекту (клацніть правою кнопкою миші та відновіть у Провіднику рішень), це зафіксувало для мене.

Врешті-решт я потрапив до однієї, яка дала мені помилку компіляції. Я виправив помилку, і рішення складеться правильно після цього.

У моєму випадку проблема полягала в тому, що я вручну видалив файл без компіляції, який позначено як "відсутній". Одного разу я видалив посилання на файл, який зараз відсутній, і перекомпілював - все було добре.

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

Якщо повернутися до цього через кілька років, ця проблема більш ніж вірогідно пов'язана з максимальним обмеженням шляху Windows:

Іменування файлів, шляхів та просторів імен , максимальне обмеження довжини шляху

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

помилка CS0067: подія "XYZ" ніколи не використовується

які з будь-якої причини не відображалися у вікні помилок.

Через це система збірки Visual Studio, здавалося, пропустила помилку і намагалася створити залежні проекти, що, в свою чергу, не вдалося з прикрим повідомленням метаданих.

Рекомендація настільки дурна, як це може здатися:

Спочатку подивіться на своє вихідне вікно !

Минуло півгодини, перш ніж ця ідея мене вдарила ...

У мене теж була така ж помилка. Він ховається, як на нижньому шляху. Шлях, на який я посилався до файлу DLL, схожий на "D: \ Assemblies Folder \ Assembly1.dll".

Але початковий шлях, по якому йдеться про збірку, був "D: \ Асамблеї% 20Folder \ Assembly1.dll".

Через зміну назви шляху, збірку неможливо було отримати з початкового контуру, а отже, видає помилку "Метадані не знайдено".

Рішення знаходиться у питанні переповнення стека. Як замінити всі пробіли на% 20 у C #? .

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

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

Просто вказуючи на очевидно очевидний: якщо у вас немає "Показувати вікно виводу при запуску збірки", переконайтеся, що ви помітили, якщо ваша збірка не працює (невелика помилка "збій не вдалася" внизу ліворуч) !!!!

У мене виникла помилка, коли я намагався опублікувати веб-додаток. Виявилося, що в одну із властивостей класу було загорнено

#if DEBUG
    public int SomeProperty { get; set; }
#endif

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

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

РОБОТА = - \ Інструменти \ VersionManagementSystem \ BusinessLogicLayer \ bin \ Налагодження \ BusinessLogicLayer.dll

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

У мене виникло це питання, оскільки .nuget\NuGet.exeвін не був включений до мого сховища. Хоча я включив DownloadNuGetExeу NuGet.targets, він повідомив про помилку проксі при спробі завантажити його. Це спричинило збій решти складання проекту.

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