Файл метаданных '.dll' не найден.

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

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

ОТВЕТЫ

Ответ 1

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

Письменные инструкции:

  1. Щелкните правой кнопкой мыши решение и выберите Свойства.
  2. Нажмите Конфигурация слева.
  3. Убедитесь, что установлен флажок "Построить" для проекта, который он не может найти. Если он уже установлен, снимите флажок, нажмите "Применить" и снова установите флажки.
  4. (Необязательно) Это необходимо сделать для режимов выпуска и отладки в свойствах решения.

Инструкции по захвату экрана:

  • Они говорят, что картинка стоит тысячи слов. Нажмите на GIF, чтобы увеличить масштаб, и, надеюсь, вам будет легко следить:

Gif Instructions

Ответ 2

Это все еще может произойти в более новых версиях Visual Studio (у меня только что это произошло в Visual Studio 2013):

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

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

Обратите внимание, что при удалении файла .suo будут сброшены стартовые проекты решения.

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

Ответ 3

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

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

Ответ 4

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

Секция 1):

В общем решения:

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

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

  1. Перезапустите Visual Studio и повторите сборку.

  2. Перейдите в "Обозреватель решений". Щелкните правой кнопкой мыши на Решение. Перейти к свойствам. Перейдите в "Диспетчер конфигурации". Проверьте, установлены ли флажки под "Build" или нет. Если какие-либо или все из них не отмечены, то проверьте их и попробуйте построить заново.

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

  4. Порядок сборки и зависимости проекта:

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

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

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

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

Раздел (2):

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

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

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

Я наткнулся на сообщение в блоге: Ошибка TFS - Невозможно открыть исходный файл ("Неопределенная ошибка")

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

Раздел (3):

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

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

Ответ 5

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

Один проект был 3.5, а другой ссылающийся на проект 4.6.1.

Ответ 6

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

Ответ 7

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

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

Быстрый поиск файла .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 перед тем, как начать играть.

Ответ 8

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

Ответ 9

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

Ответ 10

В моем случае у меня есть установленная директория ошибочно.

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

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

Ответ 11

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

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

Ответ 12

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

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

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

Ответ 13

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

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

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

Ответ 14

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

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

Ответ 15

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

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

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

Ответ 16

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

Ответ 17

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

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

Ответ 19

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

Ответ 20

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

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

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

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

Рекомендация -as глупа, как может sound-:

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

Мне потребовалось полчаса, прежде чем эта идея поразила меня...

Ответ 21

Похоже, такие ошибки связаны с тем, что Visual Studio не предоставляет правильную информацию об ошибке. Разработчик даже не понимает причину неудачной сборки. Это может быть синтаксическая ошибка или что-то еще. В общем, для решения таких проблем вы должны найти корень проблемы (например, посмотрите журнал сборки).

В моем случае проблема была в том, что в окне Error List не было ошибок. Но на самом деле были синтаксические ошибки; Я нашел эти ошибки в окне " Output, и после их устранения проблема была решена.

Ответ 22

У меня тоже была такая же ошибка. Он прячется как на пути ниже. Путь, на который я ссылался для файла DLL, выглядит как "D:\Assemblies Folder\Assembly1.dll".

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

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

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

Ответ 23

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

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

Ответ 24

На основании сообщения об ошибке я не верю, что путь к файлу усекается. Это выглядит просто неправильно. Если я правильно читаю сообщение, оно, похоже, ищет файл DLL в...

РАБОЧИЕ = -\Tools\VersionManagementSystem\BusinessLogicLayer\Bin\Debug\BusinessLogicLayer.dll

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

Ответ 25

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

Ответ 26

Я использую Visual Studio 2013.

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

Ответ 27

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

Ответ 28

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

Ответ 29

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

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

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

Ответ 30

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

namespace X.Y.Z.W
{

    // Class code

}

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

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

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