Файл метаданных.' библиотека DLL не может быть найден

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

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

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

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

на и здесь.

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

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

Ну, мой ответ-это не только итог решения, но он предлагает больше, чем это.

разделе (1):

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

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

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

1. перезапустите Visual Studio и повторите попытку построения.

2. на 'Обозреватель'. Щелкните правой кнопкой мыши на решение. Перейти к свойства. Перейти к 'Configuration Manager'. Проверьте, установлены ли флажки под 'Build' проверяются или нет. Если какой-либо из них или все они не отмечены, то проверьте их и попробуйте построить снова.

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

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

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

5. Проверьте путь пропавших без вести .dll:

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

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

---

Раздел (2):

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

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

Итак, я решил избавиться от другой ошибки, с которой я столкнулся ('Source Не удалось открыть файл (‘Unspecified error')').

я наткнулся на сообщение в блоге:ошибка TFS-исходный файл не может быть открыт (‘Unspecified error')

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

---

раздел (3):

мораль:

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

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

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

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

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

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

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

<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, щелкнув правой кнопкой мыши, построить. Тогда это сработает.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

рекомендация-как глупо, как это может быть звук:

сначала посмотри на свой Окно Вывода!

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

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

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

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

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

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

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

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

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

именование файлов, путей и пространств имен, Ограничение Максимальной Длины Пути

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

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

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

namespace X.Y.Z.W
{

    // Class code

}

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

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

ошибка CS0234: имя типа или пространства имен " W "не существует в пространстве имен" X. Y. Z " (отсутствует ссылка на сборку?)

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

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

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

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

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

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

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

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

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