Неизвестная ошибка сборки файл не найден wpf

• Remove From My Forums

All replies

• I had 3 XAML windows in my projet. The next, day, I delete one of them via the visual studio interface. However, when I try to compile my projet, it says ‘Could not find the file [my xaml file]’ after I deleted it. I do know how to make the compiler
  stop looking for the file

  Hi  Vindi Quartz,

  When you delete the file make sure you save the project file. What happens is the CSproj still has a compile reference to the old file path, and can’t find it.

  You can refer the following workaround: All files are saved when compilation is invoked.

  Incremental build fails after rename of XAML file

  Besides, this issue is more related to the visual studio, you can go to the
  Visual Studio General Questions forum.

  Best Regards

  Yong Lu

  ---

  MSDN Community Support
  Please remember to click «Mark as Answer» the responses that resolved your issue, and to click «Unmark as Answer» if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to
  MSDN Support, feel free to contact MSDNFSF@microsoft.com.

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

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

Matt_Bro
18 июль 2013, в 14:17

Поделиться

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

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

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

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

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

corvuscorax
22 апр. 2014, в 10:44

Поделиться

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

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

jordan koskei
15 дек. 2015, в 22:08

Поделиться

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

Секция 1):

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

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

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

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

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

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

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

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

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

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

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

Раздел (2):

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

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

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

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

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

Раздел (3):

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

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

Vikram
05 май 2014, в 16:54

Поделиться

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

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

Eric Schneider
08 апр. 2016, в 15:14

Поделиться

Roffers
28 май 2015, в 11:55

Поделиться

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

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

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

Alex Stephens
27 нояб. 2014, в 09:50

Поделиться

Mladen Nikolov
11 фев. 2016, в 14:37

Поделиться

user1678541
14 сен. 2012, в 21:48

Поделиться

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

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

Todd Vance
11 дек. 2015, в 17:13

Поделиться

В моем случае у меня есть установленная директория ошибочно.

Если ваш путь решения — это что-то вроде «Мое Project% 2c Very Popular% 2c Unit Testing% 2c Software и Hardware.zip», он не может разрешить файл метаданных, возможно, нам следует предотвратить некоторые недопустимые слова, такие как% 2c.

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

masphei
27 март 2015, в 09:55

Поделиться

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

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

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

Andre Mesquita
31 март 2017, в 13:03

Поделиться

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

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

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

prospector
19 дек. 2014, в 22:20

Поделиться

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

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

Baglay Vyacheslav
11 июль 2014, в 15:03

Поделиться

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

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

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

Chris Moschini
28 янв. 2014, в 07:29

Поделиться

Eric
24 июль 2014, в 20:57

Поделиться

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

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

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

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

Рекомендация -as глупа, как может sound-:

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

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

Heinz Kessler
01 нояб. 2015, в 10:01

Поделиться

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

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

dan-gph
31 окт. 2014, в 00:47

Поделиться

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

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

Code_Worm
21 июнь 2018, в 16:14

Поделиться

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

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

burzhuy
31 янв. 2017, в 09:37

Поделиться

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

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

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

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

Arun Prasad
18 июнь 2016, в 07:16

Поделиться

David Ford
10 апр. 2014, в 15:04

Поделиться

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

namespace X.Y.Z.W
{

    // Class code

}

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

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

ошибка CS0234: имя типа или пространства имен ‘W’ не существует в пространстве имен ‘XYZ’ (отсутствует ссылка на сборку?)

Michail Michailidis
24 нояб. 2015, в 16:43

Поделиться

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

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

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

Dmitri Trofimov
04 сен. 2015, в 09:47

Поделиться

tbone
09 июль 2015, в 19:19

Поделиться

Ajaco
17 июнь 2015, в 17:29

Поделиться

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

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

DrBB
09 апр. 2015, в 20:49

Поделиться

FLCL
05 дек. 2014, в 14:53

Поделиться

Antonin GAVREL
17 сен. 2018, в 15:23

Поделиться

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

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

Ogglas
17 янв. 2017, в 13:06

Поделиться

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

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

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

Pierre-Olivier Pignon
19 окт. 2016, в 06:04

Поделиться

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

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

Nick
12 дек. 2015, в 20:29

Поделиться

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

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

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

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

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

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

drfaka
05 июнь 2015, в 07:37

Поделиться

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

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

Jack Fairfield
13 май 2015, в 19:52

Поделиться

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

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

CoderRoller
06 март 2015, в 20:52

Поделиться

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

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

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

JaredPar
14 сен. 2009, в 15:44

Поделиться

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

Mathieu VIALES
14 июль 2017, в 13:50

Поделиться

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

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

Serve Laurijssen
23 июль 2015, в 10:54

Поделиться

Jon D
14 авг. 2014, в 10:51

Поделиться

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

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

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

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

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

Liero
05 авг. 2014, в 10:05

Поделиться

wtjones
20 май 2014, в 20:33

Поделиться

Abdullah Tahan
26 нояб. 2018, в 08:32

Поделиться

Joe Dyndale
05 март 2018, в 16:50

Поделиться

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

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

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

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

RenniePet
25 фев. 2018, в 16:47

Поделиться

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

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

Mykhailo Seniutovych
25 сен. 2017, в 16:22

Поделиться

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

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

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

josepainumkal
25 июль 2017, в 20:01

Поделиться

Hassan Malik
24 апр. 2017, в 07:40

Поделиться

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

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

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

mschwaig
21 июль 2016, в 21:27

Поделиться

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

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

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

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

Alexander D
21 июль 2016, в 15:36

Поделиться

Mirek
21 нояб. 2015, в 21:49

Поделиться

• Щелкните правой кнопкой мыши на решении и нажмите «Очистить».
• Щелкните правой кнопкой мыши на решении и нажмите «Восстановить».

abdullah almoshaighe
07 окт. 2014, в 18:02

Поделиться

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

user8128167
29 янв. 2019, в 22:42

Поделиться

В моем случае в моем файле Web.config это

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

к этому

<?xml version="1.0"?>

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

Elnoor
16 нояб. 2018, в 22:06

Поделиться

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

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

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

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

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

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

Другая Solution-> Clean, другая Solution-> Перестройка, и она работает локально и на сервере сборки.

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

ecth
09 окт. 2018, в 13:06

Поделиться

annoying_squid
20 сен. 2018, в 15:08

Поделиться

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

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

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

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

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

Remus.A
06 фев. 2018, в 11:37

Поделиться

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

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

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

Fakhar Ahmad Rasul
02 фев. 2018, в 22:09

Поделиться

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

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

2. В приложении измените целевую платформу на ту же, что и у основного проекта (например, «.NET Framework 4.5»).

Hamid
03 янв. 2018, в 14:40

Поделиться

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

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

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

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

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

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

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

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

MGOwen
18 авг. 2017, в 07:14

Поделиться

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

if(myVar is null)
    DoSomething();

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

if(myVar == null)

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

Gavimoss
01 авг. 2017, в 18:21

Поделиться

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

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

NoHero
06 июль 2017, в 14:22

Поделиться

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

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

Nick Van Brunt
02 март 2017, в 20:38

Поделиться

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

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

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

Basheer AL-MOMANI
07 дек. 2016, в 10:12

Поделиться

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

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

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

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

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

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

A user
14 окт. 2016, в 10:16

Поделиться

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

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

Tarmo Elfving
07 июнь 2016, в 18:16

Поделиться