Файл метаданных ‘.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"  

Это происходит после каждой неудачной сборки. Единственный способ получить решение для компиляции – прокомментировать все мои пользовательские элементы управления и перестроить проект, а затем я раскомментирую usercontrols, и все в порядке.

Я проверил строчные заказы и конфигурации зависимостей.

Как вы можете видеть, он, кажется, укоротил абсолютный путь к файлу DLL … Я прочитал, что есть ошибка с длиной. Это возможная проблема?

Это очень раздражает, и для того, чтобы комментировать, строить и раскомментировать, assembly становится чрезвычайно утомительной.

У меня была такая же проблема. Visual Studio не создает проект, на который ссылаются.

  1. Щелкните правой кнопкой мыши по решению и выберите «Свойства».
  2. Нажмите «Конфигурация» слева.
  3. Убедитесь, что флажок «Сборка» для проекта, который он не может найти, проверяется. Если он уже проверен, снимите флажок, нажмите и снова установите флажки.

Это может произойти в новых версиях Visual Studio (я просто это произошло на Visual Studio 2013):

Еще одна вещь, которую стоит попробовать – закрыть Visual Studio и удалить файл .suo который находится рядом с файлом .sln . (Он будет сгенерирован при следующем Save all (или выходе из Visual Studio)).

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

Обратите внимание, что удаление файла .suo приведет к сбросу проекта (ов) запуска.

Подробнее о файле .suo здесь .

Предлагаемый ответ мне не помог. Ошибка является приманкой для другой проблемы.

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

Ну, мой ответ – это не просто резюме всех решений, но он предлагает больше, чем это.

Секция 1):

В общем случае решения:

У меня было четыре ошибки такого типа («файл метаданных не найден») вместе с одной ошибкой: «Исходный файл не может быть открыт (« Unspecified error »)».

Я попытался избавиться от ошибки «файл метаданных не найден». Для этого я прочитал много сообщений, блогов и т. Д. И нашел, что эти решения могут быть эффективными (обобщая их здесь):

  1. Перезагрузите Visual Studio и попытайтесь создать еще раз.

  2. Перейдите в «Обозреватель решений» . Щелкните правой кнопкой мыши Решение. Перейдите в раздел «Свойства» . Перейдите в «Configuration Manager» . Проверьте, отмечены ли флажки в поле «Построить» или нет. Если какой-либо или все они не отмечены, проверьте их и попробуйте создать еще раз.

  3. Если вышеуказанное решение (ы) не работает, следуйте последовательности, указанной на шаге 2 выше, и даже если все флажки отмечены, снимите флажок, проверьте еще раз и попытайтесь построить снова.

  4. Построение заказа и зависимостей проекта:

    Перейдите в «Обозреватель решений» . Щелкните правой кнопкой мыши Решение. Перейдите в раздел «Зависимости проектов …» . Вы увидите две вкладки: «Зависимости» и «Порядок сборки» . Этот порядок сборки является тем, в котором строится решение. Проверьте зависимости проекта и порядок сборки, чтобы проверить, пытается ли какой-то проект (например, «project1»), который зависит от другого (например, «project2»), перед этим (project2). Это может быть причиной ошибки.

  5. Проверьте путь к отсутствующему .dll:

    Проверьте путь к отсутствующей .dll. Если путь содержит пробел или какой-либо другой недопустимый путь, удалите его и попробуйте создать еще раз.

    Если это причина, то отрегулируйте порядок сборки.


Раздел (2):

Мой частный случай:

Я пробовал все вышеперечисленные шаги с различными перестановками и комбинациями с перезапуском Visual Studio несколько раз. Но это мне не помогло.

Итак, я решил избавиться от другой ошибки, с которой я сталкивался («Исходный файл не может быть открыт (« Unspecified error »)).

Я наткнулся на сообщение в блоге: файл источника ошибок TFS не мог быть открыт («Unspecified error»)

Я пробовал шаги, упомянутые в этом сообщении в блоге, и я избавился от ошибки «Исходный файл не мог быть открыт (« Unspecified error »)», и я неожиданно избавился от других ошибок («файл метаданных не найден»), поскольку Что ж.


Раздел (3):

Мораль истории:

Попробуйте все решения, упомянутые выше в разделе (1) (и любых других решениях) для устранения этой ошибки. Если ничего не работает, как в блоге, упомянутом в разделе (2) выше, удалите записи всех исходных файлов, которые больше не присутствуют в исходном элементе управления и файловой системе из вашего файла .csproj .

В моем случае это было вызвано несоответствием версии .NET Framework.

Один проект составлял 3,5, а другой – проект 4.6.1.

Закрытие и повторное открытие Visual Studio 2013 работало для меня!

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

Мне показалось очевидным, что эта неправильная ссылка на метаданные файла должна быть где-то сохранена.

Быстрый поиск файла .csproj показал виновные строки. У меня был раздел под названием , который, казалось, висел на старом неправильном пути к файлу.

   {5b0a347e-cd9a-4746-a3b6-99d6d010a6c2} Beeyp.Entities  ... 

Итак, простое исправление:

  1. Резервное копирование файла .csproj.
  2. Найдите неправильные пути в файле .csproj и переименуйте их соответствующим образом.

Убедитесь, что вы создали резервную копию старого .csproj перед тем, как начать скрипку .

Я получил ту же ошибку «Файл метаданных« .dll »не найден», и я пробовал несколько вещей, описанных выше, но причиной ошибки было то, что я ссылался на сторонний DLL-файл, который был нацелен на версию .NET выше что мой проект нацелен на версию .NET. Поэтому решение заключалось в изменении целевой структуры моего проекта.

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

В моем случае у меня установлен установленный каталог ошибочно.

Если ваш путь решения – это что-то вроде «Мое Project% 2c Very Popular% 2c Unit Testing% 2c Software и Hardware.zip», он не может разрешить файл метаданных, возможно, нам следует предотвратить некоторые недопустимые слова, такие как% 2c.

Переименование пути в обычное имя разрешило мою проблему.

Я добавил новый проект в свое решение и начал получать его.

Причина? Проект, который я привел, предназначался для другой платформы .NET (4.6, а мои другие были 4.5.2).

Я тоже вытаскивал свои волосы с этой проблемой, но, пробовав предыдущие ответы, единственное, что сработало для меня, – это открыть каждый проект в моем решении 1 на 1 и создать их индивидуально.

Затем я закрыл Visual Studio 2013, снова открыл свое решение, и он скомпилирован в порядке.

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

Для меня это произошло, когда я включил новый проект в решение.

Visual Studio автоматически выбирает .NET framework 4.5.

Я изменил версию .NET 4.5.2, как и другие библиотеки, и это сработало.

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

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

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

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

  • Найдите проект, который не строится
  • Удалите / добавьте ссылки на проекты в рамках решения.

Мой экземпляр проблемы был вызван общим проектом, в котором было дублируемое имя classа (под другим именем файла). Странно, что Visual Studio не смог обнаружить это и вместо этого просто взорвал процесс сборки.

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

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

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

ошибка CS0067: событие «XYZ» никогда не используется

что по какой-либо причине не появилось в окне ошибки.

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

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

Сначала посмотрите на окно вывода !

Мне потребовалось полчаса до того, как эта идея ударила меня …

В моем случае проблема заключалась в том, что я вручную удалил файл без компиляции, который был помечен как «отсутствует». Как только я удалил ссылку на отсутствующий файл и перекомпилировал – все было хорошо.

Я была такая же проблема. В моем случае проект по-прежнему будет построен в режиме выпуска, и именно тогда я попытался построить отладку, чтобы она не удалась.

То, что я закончил, чтобы исправить проблему, было просто скопировать все DLL (и другие файлы из моей папки выпуска) в мою папку отладки. Сделав это для каждого проекта, ошибки растаяли.

Если у вас есть место в имени вашего решения, это также вызовет проблему. Удаление пространства из имени вашего решения, поэтому путь не содержит% 20.

Просто указывая на откровенно очевидное: если у вас нет «Показать окно вывода при запуске сборки», убедитесь, что вы заметили, что ваша assembly не работает (небольшая ошибка «build failed» в левом нижнем углу) !!!!

У меня была эта ошибка, когда я пытался опубликовать веб-приложение. Оказалось, что один из свойств classа был

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

но использование имущества не было. Очевидно, публикация была выполнена в конфигурации Release без символа DEBUG .

Возвращаясь к этому несколько лет спустя, эта проблема более чем вероятно связана с максимальным пределом пути Windows:

Именование файлов, путей и пространств имен , ограничение максимальной длины пути

Я запускаю Visual Studio 2013.

Похоже, что зависимости сборки были неверными. Удаление файлов * .suo устранило проблемы, которые у меня были.

Для моего случая было то, что я прокомментировал classы в определенном (пустом) пространстве имен:

 namespace XYZW { // Class code } 

Когда я удалил код пространства имен и импортировал (используя) его команды, это устранило проблему.

В сборке также говорилось – вместе с отсутствующим DLL-файлом проекта:

ошибка CS0234: Тип или имя пространства имен «W» не существует в пространстве имен «XYZ» (вам не хватает ссылки на сборку?)

У меня тоже была такая же ошибка. Он скрывается, как на следующем пути. Путь, который я назвал для DLL-файла, похож на «D: \ Assemblies Folder \ Assembly1.dll».

Но исходным путем, на котором ссылалась assembly, была «D: \ Assemblies% 20Folder \ Assembly1.dll».

Из-за этого изменения имени пути assembly не может быть извлечена из исходного пути и, следовательно, выбрасывает ошибку «Метаданные не найдены».

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

Эта ошибка может быть показана, если вы используете поддельные сборки. Удаление подделок приводит к успешной реализации проекта.

Я получил эту ошибку после открытия проекта, в котором была ссылка на Entity Framework, поэтому я удалил такие ссылки и переустановил Entity Framework версии 6.0.0.0 через pthe acket manager следующим образом:

 install-package entityframework -version 6.0.0.0 

Ошибка все еще показывалась, поэтому я думал, что эти ссылки были там, потому что в проекте была установлена ​​более ранняя версия Entity Framework, предположительно «предустановленная», но она не работала.

Поэтому я подошел к файлу packages.config и заметил, что есть еще одна ссылка:

  ****   

Затем я удалил строку, очистил и перестроил проект и контейнерное решение, и он, наконец, работал.

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

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

Советы в предыдущих ответах не помогли, но через некоторое время я заметил недостающие ссылки в некоторых проектах для нескольких сборок, таких как System.dll.

Предположим, что существует проект A, зависящий от проекта B. В проекте B не было ссылки на System.dll, но ошибка после сборки была похожа на «Файл метаданных B.dll» не найден ».

Ошибка в пропуске System.dll в проекте B.

Добавление ссылки на библиотеки, такие как System.dll в проекте B, решило проблему. (System.Data, System.DirectoryServices и т. Д.)

  • WPF VirtualizingStackPanel для повышения производительности
  • Как использовать привязки WPF с RelativeSource?
  • Как преобразовать ImageSource в массив байтов?
  • Можете ли вы использовать поставщика членства asp.net в приложении Windows?
  • Найти элемент WPF внутри DataTemplate в коде
  • Использование SynchronizationContext для отправки событий обратно в пользовательский интерфейс для WinForms или WPF
  • заполнять дерево из списка путей файла в wpf
  • Как динамически создавать столбцы в DataGrid WPF?
  • WPF ListView Неактивный цвет выделения
  • Связывание со статическим classом
  • Разница между Label и TextBlock
  • Давайте будем гением компьютера.