Файл метаданных.' 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 Error-не удалось открыть исходный файл (‘Unspecified error')

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

раздел (3):

мораль:

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

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

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

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

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

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

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

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

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

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

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

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

первый взгляд на ваш Окно Вывода!

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

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

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

то, что я сделал, чтобы исправить проблему, было просто скопировать все 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 версия моего проекта библиотеки классов (тот, который сломал сборку), идентичный .Net-версии ссылочного проекта и решенной проблемы.

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