Файл метаданных '.dll' не найден - PullRequest
591 голосов
/ 14 сентября 2009

Я работаю над проектом 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 ... Я читал, что есть ошибка с длиной. Это возможная проблема?

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

Ответы [ 71 ]

3 голосов
/ 17 января 2017

Удаление папки packages, содержащей NuGet, в папке решения у меня работало. После восстановления все снова заработало. Проверьте References в решении и проверьте ссылки, которые имеют желтый треугольник.

Пример изображения:

Enter image description here

3 голосов
/ 20 мая 2014

У меня была эта проблема, потому что .nuget\NuGet.exe не было включено в мой репозиторий. Хотя я включил DownloadNuGetExe в NuGet.targets, он сообщал об ошибке прокси-сервера при попытке загрузить его. Это привело к сбою остальных сборок проекта.

3 голосов
/ 19 октября 2016

В моем случае у меня была эта ошибка, потому что один из моих проектов использовал версию платформы .NET, отличную от других решений. Я использовал менеджер пакетов NuGet для установки NLog, поэтому, я думаю, он установлен для .Net-версии этого проекта.

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

Именно тогда, когда я удалил все файлы в obj\Debug из этого проекта, решение было скомпилировано.

3 голосов
/ 17 сентября 2018

У меня был класс в 4.6.1, обновляющий интерфейс в 4.6.2 ... обновление класса до 462 исправило его.

3 голосов
/ 13 мая 2015

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

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

3 голосов
/ 06 марта 2015

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

install-package entityframework -version 6.0.0.0

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

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

<packages>
  **<package id="EntityFramework" version="5.0.0" targetFramework="net45" />**
  <package id="EntityFramework" version="6.0.0" targetFramework="net45" />
</packages>

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

3 голосов
/ 05 июня 2015

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

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

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

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

Не было ошибки об отсутствии System.dll в проекте B.

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

3 голосов
/ 12 декабря 2015

В моем случае эти ошибки были вызваны некоторым повреждением в диспетчере пакетов NuGet. Подпроекты решения не создавались, но ошибок из-за ошибок метаданных не было.

Как только все пакеты NuGet были исправлены, проект снова может быть правильно собран.

3 голосов
/ 09 апреля 2018

В моем случае некоторые проекты в решении были нацелены на Любой процессор , некоторые на x86. Ошибка компиляции исчезла после объединения цели платформы в решении.

2 голосов
/ 25 февраля 2018

Как указывает пользователь @burzhuy, может быть важно взглянуть на окно Output, а не только на окно Error List.

В моем случае я работал над модификацией компилятора Roslyn . Его проекты сборки запускают дополнительную проверку, чтобы увидеть, согласуются ли открытые поля с тем, что было определено как открытый интерфейс компилятора, в противном случае он выдает ошибку RS0016 или RS0017. Я добавил пару открытых полей и исправил ошибку RS0016, наведя указатель мыши на ошибку и выбрав «Добавить в публичный API».

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

Вам нужно найти правильный файл PublicAPI.Unshipped.txt (в моем случае он был в E:\Roslyn\32414\src\Compilers\Core\Portable) и отредактировать его вручную, чтобы удалить ненужные строки.

...