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

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

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

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

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

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

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

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

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

Секция 1):

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

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

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

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

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

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' не может быть найден", и я попробовал несколько вещей, описанных выше, но причина ошибки заключалась в том, что я ссылался на сторонний файл DLL, который был нацелен на версию .NET что мой проект целевой .NET версия. Таким образом, решение состояло в том, чтобы изменить целевую структуру моего проекта.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

namespace X.Y.Z.W
{

    // Class code

}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я получил эту ошибку после открытия проекта, в котором была ссылка на 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>

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

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

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

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

В моем случае ReSharper был глуп, и, хотя мой проект нацелен на С# 6, мне предлагали рефакторинг для использования функций только С# 7.

По этой причине я закончил тем, что изменил этот код,

private DateTime? _joinedDate;
[Column(TypeName = "DateTime2")]
public DateTime JoinedDate
{
    get { return _joinedDate ?? DateTime.Now; }
    set { _joinedDate = value; }
}

в этот код:

private DateTime? _joinedDate;
[Column(TypeName = "DateTime2")]
public DateTime JoinedDate
{
    get => _joinedDate ?? DateTime.Now;
    set => _joinedDate = value;
}

По какой-то причине использование getter и setter с использованием тел выражений заставило компилятор выдавать ошибку метаданных вместо синтаксической ошибки.

aaaaaand шесть лет спустя во время обновления до Visual Studio 2015 такая же проблема. Поскольку это конкретное решение отсутствует в этом списке, я добавляю к нему.

Две ссылочные dll находились в папке c:\windows\system32.... Перемещение их в не системную папку и добавление ссылки на новую папку наконец-то исправили. Остальные вопросы были действительно тем, что уже говорили здесь уже

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

Причиной проблемы может быть смешанное добавление ссылок на файлы DLL и проекты в решении.

Если у вас есть проекты A, B и C:

• Ссылки B и C как проекты в решении.
• B ссылается на C как файл DLL (ссылка на файл)

Вы можете построить каждый проект отдельно, но не можете перестроить решение, заканчивающееся на: файл метаданных 'C.dll' не найден.

Помогает изменение ссылки из файла на проект в решении.

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

Моя проблема возникла, когда я написал код на С# 7, но проект использовал более старую версию для .net Framework

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

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

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

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

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

Для меня проблема была в том, что у меня было открыто два окна Visual Studio, мой проект выполнялся в режиме отладки в одном окне, и я попытался построить его в другом.

Мне пришлось прекратить отладку, а затем он позволил мне построить успешно.

Я столкнулся с этой проблемой. В моем случае несколько С# проектов упоминались как файлы DLL. Любая ошибка времени компиляции в проекте, который используется как файл DLL (в других проектах), может привести к потоку ошибок. Причина в том, что ошибка времени компиляции предотвращает создание соответствующего файла DLL, и это приводит к серии ошибок в проектах, которые ссылаются на отсутствующий файл DLL.

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

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

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

Я столкнулся с этой ошибкой в Visual Studio 2015, когда удалил аннотацию типа из вызова метода расширения, из-за которого остались только пустые угловые скобки.

Поэтому вместо obj.extensionMethod<Type>() меня был obj.extensionMethod<>().

Я бы классифицировал это как ошибку в Visual Studio, так как не вижу, как эта ошибка может привести к этой ошибке.

Вау, похоже, что эта ошибка может прийти отовсюду.

В любом случае, я добавил новый контроллер WebAPI в свое приложение MVC, и он автоматически получил все ссылки от NuGet. Чуть позже я удалил ссылки из интерфейса NuGet, но я забыл удалить файлы, используя их (например, System.Http).

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

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

Я выяснил, что если вы удалите сборку Microsoft.CSharp в качестве ссылки в проекте, вы получите эту ошибку.

• Щелкните правой кнопкой мыши на решении и нажмите "Очистить".
• Щелкните правой кнопкой мыши на решении и нажмите "Восстановить".

Когда я делал сборку, в Visual Studio 2017 обычно отображались такие ошибки:

Error   CS0006  Metadata file 'C:\src\ProjectDir\MyApp\bin\x64\Debug\Inspection.exe' could not be found MyApp   C:\src\ProjectDir\MyApp\CSC 1   Active

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

Error   CS1503  Argument 1: cannot convert from 'MyApp.Model.Entities.Asset' to 'MyApp.Model.Model.Entities.Inspection' MyApp   C:\src\ProjectDir\MyApp\ViewModels\AssetDetailsViewModel.cs 1453    Active

Поэтому я потратил время на устранение первой ошибки, но настоящая проблема оказалась из-за второй ошибки. Сначала мне пришлось удалить все каталоги /bin и /obj, затем я также удалил файлы .suo, как указано выше. Это позволило мне сузить проблему до проблемы интерфейса.

В моем интерфейсе у меня было это:

    Task<IList<Defect>> LoadDefects(Asset asset);

Но в моей реальной реализации у меня был этот код:

    public virtual async Task<IList<Defect>> LoadDefects(Inspection inspection)
    {
       var results ...
       // ....

        return results;
    }

Сборка успешно завершена после того, как я обновил интерфейс до этого:

    Task<IList<Defect>> LoadDefects(Inspection inspection);

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

В моем случае в моем файле Web.config это

<?xml version="1.0" encoding="utf-8"?>

к этому

<?xml version="1.0"?>

исправил мою проблему

У меня была такая же проблема и другое решение.

Вопрос: одно решение, несколько проектов. Основное приложение, которое использует некоторые другие результаты, не удалось, сказав:

CSC: ошибка CS0006: файл метаданных 'C:\Repos\TheApplication\TheApplicationCommon\bin\Debug\TheApplication.dll' не найден

Но на самом деле этот проект сгенерировал C:\Repos\TheApplication\TheApplicationCommon\bin\Debug\TheApplicationCommon.dll Другой проект, который также использует ту же самую DLL, скомпилированную без нареканий.

Прежде чем я обновил внутренний NuGet-пакет, который использовал PostSharp 3.xxx и теперь использует PostSharp 4.xxx, я решил добавить это в мой файл *.csproj:

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="...">
  <Import Project="..." Condition="..." />
  <PropertyGroup>
    ...
    <AssemblyName>TheApplication</AssemblyName>
    ...
    <SkipPostSharp>True</SkipPostSharp> <!-- This line -->
  </PropertyGroup>
...

Другая Solution-> Clean, другая Solution-> Перестройка, и она работает локально и на сервере сборки.

Надеюсь, это поможет кому-то. Поток старый и довольно длинный, но эта проблема часто возвращается, и я пока не видел этого решения. Кстати, с использованием Visual Studio 2017 (15.8.x).

Visual Studio IDE не создает никаких закулисных структур, как это делает приложение Msbuild. VS IDE, по сути, просто создает файл проекта, который используется Msbuild, и довольно часто он делает ошибки, если вы оставляете его на усмотрение IDE, чтобы самому разобраться. Если вы получаете Metadata file '.dll' could not be found ошибку, скорее всего, из-за того, что правильные/ожидаемые сборки не найдены. Так что, возможно, Visual Studio может создавать файл проекта для приложения платформы 4.5 и ожидать 4,5 сборки, пока вы ссылаетесь на сборки 4.0. Поэтому посмотрите на свои настройки Visual Studio на предмет несовместимости или зайдите в файл проекта и вручную исправьте его, указав правильный путь <Reference Include="C:\\correct path to assembly\\yourAssembly.dll"/>.

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

Я полагаю, что возникла ошибка при сборке, потому что DLL файл библиотеки Logic Layer не мог быть собран, и основное приложение не смогло его найти.

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

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

PS: это было в Visual Studio 2015 Community Edition

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

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

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

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

1. Щелкните правой кнопкой мыши по проекту и выберите "Свойства".

2. В приложении измените целевую платформу на ту же, что и у основного проекта (например, ".NET Framework 4.5").

Ни один из десятков ответов до сих пор не работал для меня. В моем случае я тоже получил ошибку:

Имя элемента кортежа 'Value' выводится. Пожалуйста, используйте языковую версию 7.1 или выше для доступа к элементу по его предполагаемому имени

Это появилось рядом с ошибками "Файл метаданных .dll" не удалось найти "при сборке, но вскоре исчезло, поскольку ошибки иногда возникают, когда среда IDE" догоняет ".

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

В противном случае вы можете попробовать это в Visual Studio:

Меню Проект → <Имя проекта> Свойства → Построить → кнопка Дополнительно → Языковая версия → С# <последняя дополнительная версия> (например, "С# 5.0")

И это тоже исправляет.

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

Я видел эту ошибку, потому что у меня была следующая строка в моем коде (похоже, я все еще думал в режиме SQL):

if(myVar is null)
    DoSomething();

Visual studio (2017) не сообщала об ошибках при проектировании или компиляции, однако проект не собирался и выдавал ошибку "missing.dll". При изменении ошибочной строки на:

if(myVar == null)

Проблема решена.

У меня появилась эта проблема после того, как я сильно изменил решение, отложил изменения и отменил их.

Единственный способ решить эту проблему - удалить и снова добавить отображение из TFS в мою локальную папку.

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

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

Я столкнулся с этой проблемой после getting latest (команда Team Foundation Server (TFS)).

После разрешения конфликтов я обнаружил использование оператора для namespace that does not exist in the project.

Поэтому я удалил оператор using затем clean and rebuild, и все было в порядке.

Очень странно! Я перепробовал все предыдущие ответы и, к сожалению, в моем случае ничего не получалось.

Я столкнулся с двумя ошибками:

1. Отсутствует файл .dll
2. Метод уже определен в другом месте с такими же параметрами

Сначала я очистил вторую ошибку, удалив функцию, дублированную в другом месте.

Моя первая ошибка - отсутствие файла .dll - решила сама.

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

Проверьте файл .csproj основного проекта. Visual Studio не очищает это, если вы удаляете проекты или изменяете ссылки в решении.

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