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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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