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


723

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

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


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

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

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


Я перепробовал все ответы выше и, к сожалению, в моем случае ничего не получалось. Я столкнулся с двумя ошибками: 1. Отсутствует файл .dll. 2. Метод, уже определенный в другом месте с такими же параметрами. Сначала я удалил вторую ошибку, удалив дублированную функцию в другом месте. Моя первая ошибка - отсутствие отсутствующего DLL-файла, решилась сама собой. Я хочу сказать, если у вас есть более одной ошибки вместе с ошибкой файла .dll отсутствует! Пожалуйста, попробуйте сначала устранить другие ошибки. Может быть. DLL ошибка решает сама!
пользователь

Ответы:


909

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

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

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

Снимок экрана Инструкции:

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

Gif Инструкции


177
И, в моем случае, даже если флажок был установлен, снятие флажка и повторная проверка исправили проблему.
нгм

13
Это решило мою проблему - я должен был сделать это для обоих режимов Release и Debug в свойствах решения. Спасибо!
TheJerm

133
Снимите флажок / проверка не решила проблему, поэтому мне пришлось сделать следующие шаги: - очистить решение - снять все флажки сборки - перезапустить VS - проверить все флажки сборки
Фрэнки

27
Другая вещь, которую нужно сделать, это проверить каждую из зависимостей проекта, по какой-то причине она не была установлена ​​автоматически. Свойства решения -> Общие свойства -> Зависимости проекта.
Аничо

9
Снимите флажок -> У меня проверка работала ненадолго, после чего проблема вернулась. Затем я перезапустил Visual Studio, и проблема ушла.
DeveloperDan

224

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

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

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

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

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


24
Это решило проблему для меня. Также стоит отметить, что .suoфайлы скрыты. Так что вам придется настроить свой обозреватель для отображения скрытых файлов.
Джордж Ховарт

6
Я работаю с проектом Xamarin, и файл .suo находится в папке .vs /. Я попытался удалить его, и это не решило мою проблему

VS2013 - Мне пришлось переместить мое рабочее пространство TFS в другое место. После того, как я закончил это, я начал получать эту ошибку. Удаление файла sou работало на меня.
Вин

40
Это сработало и для меня. Но в Visual Studio 2015 .suoфайл скрыт и находится в скрытом .vsкаталоге рядом с .sln. Например: если файл решения, c:\foo\mysolution.slnто ищитеc:\foo\mysolution\.vs\mysolution\v14\.suo
Wyck

6
Для VS2017, для простоты, я просто удалил .vsскрытую папку, которая также удалила .suoфайл. Я снова открыл решение, исправил еще одну несвязанную ошибку, и проблема была решена.
user3613932

183

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

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


9
Мне удалось исправить, сопоставив платформу для проекта с более высокой версией, указанной в предупреждающем сообщении, щелкнув правой кнопкой мыши проект> Свойства> Приложение> Целевая платформа.
StronglyTyped

1
То же самое для меня, используя vs2015.
bruno.bologna

Ага. именно это и случилось со мной. VS 2015
KevinDeus

Спасибо! Это решило мою проблему. VS 2015 после обновления проекта до .Net Framework 4.7.1.
DHoover

Вау, это исправило это для меня. Новый проект был ориентирован на другую версию .net. Не могу поверить, что нет проверки даже в vs2017.
Дуглас Гаскелл

104

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

Секция 1):

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

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

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

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

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

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

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

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

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

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

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


Раздел (2):

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

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

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

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

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


Раздел (3):

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

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


4
Моя проблема была в Построении заказа / Зависимости проекта. Удаление и добавление обратных ссылок из других проектов исправит это (я думаю), но вы также можете сделать это сами.
Nacht - Восстановить Монику

4
Я столкнулся с этой проблемой, понизив .NET v4.5проект до .NET v.4.
guneysus

1
Мне помогло удаление «%» из пути к ссылочной DLL
Boogier

1
Решение в разделе 2 сработало для меня! У меня была другая ошибка, и когда я установил, что остальные волшебным образом исчезли.
Мартин Йоханссон

1
У меня была та же проблема, что и у Бугира. У меня в имени папки% 20 вместо пробела и dll искал пробел. Потратил так много времени, пытаясь все остальные исправления, когда фактическое было самым простым.
Ленни К

38

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

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


2
Это также происходит между 4.5.2. 4.6
АззамАзиз

2
Действительно, у меня был один из 4.6.1, а остальное было 4.5.2, спасибо!
Мейсон

7
Да, кажется, в любое время версия фреймворка отличается, это происходит. Великая ошибка Microsoft!
Эрик Шнайдер

Ага! Я пытался использовать .Net 4.7.1 .dll, когда мой проект был .Net 4.6.1. Предупреждение было скрыто от других предметов, но об этом не было ошибок. Моя ошибка была красная сельдь
Esaith

29

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


Эта проблема возникла после возврата изменений git в файлы проекта. Перезапустил VS2015 и решил проблему
Ludovic C

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

1
У меня все еще есть проблема с VS2019, и это исправило ее для меня, спасибо
pcdev

20

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

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

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



14

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


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

В моем случае он даже не строит проект по отдельности, он выдает ту же ошибку. Допустим, мой проект называется «proj1», и когда я его создаю (как вы сказали, вручную), он мне дает Metadata file ...proj1.dll could not be found!
A-Sharabiani

14

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

Если путь к вашему решению похож на «Мой проект% 2c Очень популярный% 2c модульное тестирование% 2c Software and Hardware.zip», он не может разрешить файл метаданных, возможно, мы должны предотвратить использование некоторых недопустимых слов, таких как% 2c.

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


1
Не могли бы вы более подробно проработать свой ответ, добавив немного больше описания предлагаемого вами решения?
abarisone

Мой git-клон добавил% к пути к моей папке, удалив это, решив проблему.
Эрик Бергштедт

@abarisone Я удалил строку «% 2c» из пути, затем она сработала
masphei

1
Это тоже была моя проблема, когда я клонировал проект с именем «% 20» вместо простого пробела. Спасибо @abarisone, твой подход решил мою проблему.
М.А. Кордейру

Когда я клонировал свой проект из TFS, он также почему-то добавил% 20. Удаление решило проблему и для меня.
Selthien

13

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


Ну, я собирался ответить на то же самое, в моем случае я добавил новый проект, нацеленный на .Net 4.5.x, и это начало происходить, когда в этом проекте я добавил ссылку на проект, который использовал .Net 4.6.
Хуан,

12

Visual Studio 2019 это работало для меня:

  1. Закрыть Visual Studio
  2. Удалить скрытый .vs папку
  3. Снова откройте Visual Studio и перестройте решение.

Большое спасибо, это сработало и после еще одной неудачной сборки.
Iamsodarncool

Спасибо, это сделало это для меня.
iaacp

10

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

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

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


10

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

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


1
Я не знаю почему, но я уже год так работаю. мой подпроект был 4.6.1, а основной проект 4.5.2. это работало без проблем. внезапно я получаю эту ошибку, но я не хочу понижать суб-проект, потому что он имеет функцию, существующую в 4.6.1, я не верю, что это проблема. Microsoft объясняет, что это все еще должно работать
batmaci

TLDR: проверьте предупреждения компиляции. Это то, что случилось со мной, но с изюминкой. Проекты были на 4.5.2. Добавлены новые проекты на 4.6. Установленные пакеты nuget на 4.6 проектов. Понизил 4.6 проектов до 4.5.2. Nugets ожидали 4.6. Понижение нюгетов решено.
w00ngy

9

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

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

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


8

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

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

Щелкните правой кнопкой мыши ссылку «папка» в обозревателе решений, «удалить неиспользуемые ссылки». Я сделал это на всех моих проектах в этом решении, он сделал
свое дело

8

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

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

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


1
Тьфу, это. Так много вещей, которые Microsoft требует перезагрузки, чтобы снова работать.
Ятрикс

8

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

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


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

7

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


Это комментарий, ответ или новый вопрос? Кроме того, обратите внимание, что ОП с 2009 года
ГМО

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

4
Я не критикую чей-либо ответ, просто предлагаю альтернативное решение того же симптома.
Эрик

7

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

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


В моем случае ошибка была скрыта, пока я не открыл Visual Studio 2015 в режиме администратора. Только тогда он показал ошибку компиляции. После исправления я мог продолжить.
SL Barth - Восстановить Монику

6

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


6

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


ты гений !!
Итамар

Я не видел твой комментарий, прежде чем понял его. Но это была моя проблема.
Л Джонсон

6

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

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


Который...? 260? Или чуть меньше (на практике)?
Питер Мортенсен

6

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

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

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

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

Рекомендация - как бы глупо это не звучало:

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

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


Я думаю, что каждый должен смотреть на этот ответ. Посмотрите в окне вывода сборки и посмотрите, есть ли там какие-либо ошибки или предупреждения, а затем исправьте их. Задача решена. Спасибо Хайнц Кесслер за ваш ответ.
Капитан Америка

5

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

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

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

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


5

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

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


1
Эта!!! Хотя вышеприведенный ответ был хорошим, я просто упустил из виду это. Спасибо, сэр.
Рис Джонс

@RhysJohns счастливого кодирования :)))
Code_Worm

4

Просто указав на очевидную очевидность: если у вас не включено «Показывать окно вывода при запуске сборки», убедитесь, что вы замечаете, что ваша сборка не удалась (небольшая ошибка «сборка не удалась» внизу слева) !!!!


У меня недавно было что-то похожее - совершенно неожиданно, сотни ошибок cs0006 в журнале ошибок, но больше ничего (и я прочесал это с очень хорошей расческой). В конце концов (!) Я подумал о том, чтобы посмотреть в окно «Вывод», и была обнаружена ошибка компилятора, и, конечно же, в коде ошибки была красная заглушка под ним. Я понятия не имею, почему об ошибке не сообщили в окне ошибок. VS2017 Предприятие.
августа

4

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

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

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


4

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

Работа = - \ Tools \ VersionManagementSystem \ BusinessLogicLayer \ Bin \ Debug \ BusinessLogicLayer.dll

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


Я не знаю, как, поскольку я ничего не изменил и у меня нет пользовательских событий или конфигураций сборки
Оливер

4

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


4

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


Что такое «поддельная сборка»? Можете ли вы уточнить? (Ответьте, расширив свой ответ.)
Питер Мортенсен
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.