it-swarm-ru.tech

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

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

543
Oliver

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

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

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

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

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

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

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

189
corvuscorax

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

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

122
jordan koskei

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

Секция 1):

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

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

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

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

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

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

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

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

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

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

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


Раздел (2):

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

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

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

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

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


Раздел (3):

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

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

86
Vikram

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

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

33
Eric Schneider

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

23
Roffers

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

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

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

16
Alex Stephens

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

13
user1678541

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

13
Mladen Nikolov

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

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

10
Todd Vance

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

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

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

10
masphei

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

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

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

9
Andre Mesquita

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

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

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

8
prospector

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

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

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

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

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

8
Chris Moschini

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

7
Eric

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

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

7
dan-gph

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

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

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

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

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

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

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

6
Heinz Kessler

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

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

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

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

5
Arun Prasad

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

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

5
Code_Worm

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

5
David Ford

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

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

5
Oliver

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

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

5
burzhuy

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

4
FLCL

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

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

4
DrBB

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

namespace X.Y.Z.W
{

    // Class code

}

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

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

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

4
Michail Michailidis

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

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

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

4
Dmitri Trofimov

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

4
Ajaco

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

4
tbone

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

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

3
CoderRoller

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

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

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

3
JaredPar

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

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

3
Nick

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

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

3
Jack Fairfield

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

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

 Enter image description here

3
Ogglas

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

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

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

3
Pierre-Olivier Pignon

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

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

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

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

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

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

3
drfaka

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

3
Antonin GAVREL

В моем случае некоторые проекты в решении были нацелены на любой процессор , некоторые на x86. Ошибка компиляции исчезла после объединения цели платформы в решении.

3
Tomas Kubes

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

2
Jon D

В моем случае это было ReSharper быть глупым и, хотя мой проект нацелен на C # 6, мне предлагали рефакторинг, чтобы использовать функции только C # 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 с использованием тел выражений заставило компилятор выдавать ошибку метаданных вместо синтаксической ошибки.

2
Mathieu VIALES

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

2
wtjones

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

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

2
Serve Laurijssen

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

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

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

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

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

2
Liero

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

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

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

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

1
RenniePet

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

1
Joe Dyndale

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

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

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

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

1
Alexander D

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

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

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

1
josepainumkal

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

1
Hassan Malik

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

1
Mirek

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

1
Abdullah Tahan

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

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

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

1
mschwaig

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

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

1
Mykhailo Seniutovych

Я согласен со всем вышесказанным, только разница. В моем случае: я использую Visual Studio 2019. Я закрыл VS-2019 и открыл с VS-2017. и перестроить проект все работает отлично! Для кого на моей должности дата: 19.04.2009

1
dewelloper
  1. Щелкните правой кнопкой мыши на решении и нажмите Очистить.
  2. Щелкните правой кнопкой мыши по решению и выберите «Перестроить».
1
abdullah almoshaighe

В моем случае я решил эту проблему, заметив, что я ссылался на проект .Net Framework 4.7 как зависимость от проекта .Net Framework 4.6.1. После миграции проекта 4.7 на 4.6.1 мое приложение скомпилировалось нормально

0
Alexandre Lima

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

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

0
Tarmo Elfving

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

if(myVar is null)
    DoSomething();

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

if(myVar == null)

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

0
Gavimoss

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

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

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

0
Fakhar Ahmad Rasul

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

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

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

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

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

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

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

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

0
MGOwen

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

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

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

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

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

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

Другое решение-> Очистить, другое решение-> Перестроить, и оно работает локально и на сервере сборки.

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

0
ecth

В моем случае внутри моего файла Web.config, меняющего это 

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

к этому

<?xml version="1.0"?>

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

0
Elnoor

В моем случае это случилось со мной, когда я ссылался на пакеты NuGet локально и переместил их каталог куда-то еще, я изменил путь внутри NuGet.Config, но, к сожалению, я обнаружил, что мне следует вручную изменить файлы .csproject, чтобы обновить путь ссылки, но сообщение об ошибке CS0006 был далек от описания этой проблемы. Как правило, это также происходит, когда существует ссылка на DLL, которая не может быть найдена, чтобы можно было определить проблему, найдите в своих ссылках в проекте проблему, в которой вы найдете некоторые ссылки со значком предупреждения, связанным с ними. попробуйте исправить это, и оно должно работать как положено.

0
Ali Ezzat Odeh

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

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

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

0
Basheer AL-MOMANI

Когда я делал сборку, в 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.

0
user8128167

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

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

0
Nick Van Brunt

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

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

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

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

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

0
Remus.A

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

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

0
NoHero

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

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

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

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

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

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

0
A user

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

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

  2. В Приложение , изменить Целевая среда на ту же, что и основной проект (например, «.NET Framework 4.5»).

0
Hamid

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" />.

0
annoying_squid