Ошибка «Файл метаданных«… \ Release \ project.dll »не найден в Visual Studio»


135

Недавно я начал получать это сообщение случайно:

Файл метаданных '... \ Release \ project.dll' не найден в Visual Studio

У меня есть решение с несколькими проектами. Текущий режим сборки - отладка, а все проекты настроены на отладку. Но когда я пытаюсь запустить основной проект - иногда он выдает мне несколько ошибок, все из которых "файл метаданных '... \ Release \ projectX.dll' не может быть найден" - и, смотрите, он говорит о RELEASE папка, хотя текущий режим - отладка. Зачем? Я попытался найти ссылку на «Release \ projectX.dll» во всех файлах решения и нашел ее в файле ResolveAssemblyReference.cache.

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

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

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

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


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

эта проблема может возникнуть, если ссылочная dll использует другую (более низкую) версию .net Framework
m4ngl3r

Я получал эту проблему последовательно, пока я не отключил параллельные сборки. Я думаю, что есть ошибка в проверке зависимостей параллельной сборки, возможно связанная с кэшированием устаревшей информации. (Кстати, сейчас я использую параллельные сборки, и я просто собираю заново, если проблема возникает, что обычно работает.)
yoyo


Ответы:


138

Все правильно ... попробуй все ... (чтобы немного потрачено много времени)

  1. У тебя плохой код? Исправьте это сначала.
  2. Чистое решение и перезапустите Visual Studio
  3. Удалить / добавить ссылки
  4. Проверьте ваш порядок сборки с большими проектами и проверьте
  5. Перестройка подпроектов вручную
  6. Вручную скопируйте библиотеки между проектами в связанные папки bin
  7. Пойди принеси кофе, поиграй в пинбол и возвращайся завтра ... тем временем ты можешь подумать о чем-то другом.

17
Вам необходимо устранить все ОШИБКИ и получить стабильные решения / проект.
Рави Рам

это происходит из-за различия имен в имени папки и имени пространства имен. Если вы создаете пространство имен с определенным именем, а затем переименовываете его, то пространство имен будет иметь само старое имя. А сборник будет взять старый путь , чтобы найти .dllи .exeфайл. Чтобы избежать этого, откройте .csprojфайл каждого пространства имен с текстовым файлом и найдите старый путь в файле. удалите это, очистите и восстановите решение. Это сработало для меня. Я провел целый день, работая над этой проблемой.
Сурадж

Если у вас нет успеха, и это требует времени, просто вернитесь сначала к повторению некоторых основных вещей. Я начал строить подпроекты, все еще получал ошибки, но затем закрыл и заново открыл VS, пересобрал решение, все работало.
Крис Хэлкроу,

6
Я не соответствовал именам и именам проектов в домашнем dll, на который ссылаются. Кроме того, он был построен с .NET 4.5.2 вместо 4.5. Мужчина!
Джесс

1
Попробуйте удалить файл .suo. Это довольно распространено для того, чтобы стать испорченным.
Тимбо

21

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

Все ссылки были добавлены как проекты. Порядок сборки проекта был правильным (щелкните правой кнопкой мыши по проекту и выберите порядок сборки).

Однако при сборке некоторых проектов более высокого уровня «корневой» проект, от которого они зависели, не был построен.

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

Чтобы проверить это, выберите «Диспетчер конфигурации» (меню «Сборка») и проверьте, настроены ли проблемные проекты на сборку.


Спасибо! Это отлично сработало, когда по какой-то причине моя конфигурация релиза не создала ни один из моих проектов.
Vectovox

Вы спасли мою жизнь!
Четан Шетти

16

Когда вы говорите, что удалили ссылки на эти проекты и заново их добавили, как вы их точно добавили? Использовали ли вы вкладку «Обзор» в диалоговом окне «Добавить ссылку» в Visual Studio? Или вы использовали вкладку «Проекты» (в которой перечислены соседние проекты в вашем решении)?

редактировать : если вы используете вкладку «Обзор» и вручную добавляете ссылку на свой DLL-файл, который находится в папке / Release, Visual Studio всегда будет искать DLL-файл в этом месте, независимо от того, в каком режиме вы находитесь. в настоящее время в (Отладка или Выпуск).

Если вы удалили действительный файл .dll из папки выпуска (вручную или с помощью команды «Очистить решение»), то ваша ссылка прервется, поскольку файл .dll не существует.

Я бы предложил удалить ссылку на ProjectX.dll и снова добавить ее, но на этот раз используйте вкладку «Проекты» в диалоговом окне «Добавить ссылку». Когда вы добавляете ссылку таким образом, Visual Studio знает, где взять соответствующий DLL-файл. Если вы находитесь в режиме отладки, он получит его из папки / Debug. В режиме Release, папка / Release. Ваша ошибка сборки должна исчезнуть, и вы больше не будете (неправильно) ссылаться на Release .dll в режиме отладки.


Я использовал вкладку «Обзор» в диалоговом окне «Добавить
ссылку

1
Для меня Visual Studio создал проект name.v11 типа «Параметры пользователя решения Visual Studio». Я удалил этот файл и перезапустил, и все было хорошо.
Уэс Грант

15

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

Секция 1):

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

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

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

  1. Перезапустите VS и попробуйте собрать снова.

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

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

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

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

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

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

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


Раздел (2):

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

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

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

Я наткнулся на блог: http://www.anujvarma.com/tfs-errorsource-file-could-not-be-opened-unspecified-error/#comment-1539

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


Раздел (3):

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

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



1
Голосуйте за этот ответ, потому что мы столкнулись с этим вопросом для коллеги. Его система каким-то образом потеряла большинство / все свои зависимости, поэтому при сборке она не будет собрана в правильном порядке, потому что «файл метаданных для« what.dll »не существует». Мы просто просмотрели все его проекты с другой системой, чтобы проверить все зависимости, которые ему нужны для каждого проекта.
jmbertucci

Хорошо ... Я рад, что мой ответ помог вам.
Викрам

11

У меня была эта проблема раньше, и я нашел единственный способ ее решить - запустить Clean Solution и перезапустить Visual Studio.


1
Это не помогает в моей ситуации, через короткое время проблема появляется снова.
ночной кодер

Это то, что исправило это для меня.
сплинтор

3
Этот только работал для меня также. Делал несколько чисток и ничего не получалось. Как только я сделал чистку и перезапустил, снова заработало. Как раздражает.
Рикки

8

Для меня обычно целевая платформа отключена (4.5.2 вместо 4.6). Если вы исправите целевую инфраструктуру проекта так, чтобы она соответствовала целевой структуре решения и сборки, будет создан новый .dll.


У меня была такая же проблема для проекта, который был создан с более старой версией Visual Studio. После обновления VS были созданы проекты с более новой версией .NET и возникла проблема с DLL-not-found. (Перейдите на панель свойств проекта для просмотра / редактирования версии .NET.) Спасибо!
Тони Ю Ю

Спасибо миллион раз (это число других решений, которые я пробовал). Это сработало. Почему-то библиотека, которую я добавляю, предназначалась для другой версии платформы .NET, чем все другие проекты
Nour Lababidi

1
Я добавил новый проект библиотеки классов (dll), на который ссылались в нескольких других проектах. Новая DLL была .NET Framework 4.8, в то время как все остальные проекты были 4.7.2. Изменение целевой структуры (в свойствах проекта) на 4.7.2 исправило это для меня. Спасибо Адам!
iCode


3

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


3

Вы проверили настройки диспетчера конфигурации? В диалоге настроек проекта в правом верхнем углу.

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


Я проверил это. Все проекты имеют одинаковую конфигурацию.
ночной кодер

2

Я также видел эту ошибку в решениях, в которых у меня есть несколько проектов (обычно это проекты netTiers, в которых я обновил один или несколько подпроектов для платформы 4.0). Это может быть проблематично удалить. Однако часто это можно устранить, сначала исправив все другие ошибки в подпроектах (например, любые отсутствующие ссылки), по отдельности перестроив эти подпроекты, а затем удалив / добавив обратно все ссылки на эти подпроекты в Visual Studio. Лично мне не повезло решить эту ошибку, очистив решение в одиночку.


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

2

Мы недавно столкнулись с этой проблемой после обновления до Office 2010 с Office 2007 - нам пришлось вручную изменить ссылки в нашем проекте на версию 14 взаимодействий Office, которые мы используем в некоторых проектах.

Надеюсь, это поможет - нам понадобилось несколько дней, чтобы понять это.


2

В моем случае это было вызвано двумя причинами (VS.2012):

1) Один из проектов был настроен для AnyCPU вместо x86

2) Проект, на который ссылались, как-то не отмечен.

Проверьте свою сборку | Configuration Manager, чтобы получить обзор того, что строится и для какой платформы. Также убедитесь, что вы проверили его для Debug & Release, так как они могут иметь разные настройки.


2

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

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


2

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

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

Кажется, что VS не очищает этот файл соответствующим образом. Он все еще ссылался на удаленные проекты под капотом. Когда вручную удалены ссылки из файла csproj, все снова работает! Wohoo


2

Эта проблема связана с файлами pdb или CodeContracts.

Чтобы решить это:

  1. Очистите папку вывода и перестройте решение.

  2. Переконфигурируйте CodeContracts или отключите его для временной сборки.


2

Мы часто сталкиваемся с этой проблемой, но только со ссылками на проекты C ++ / CLI из проектов C #. Очевидно, в глубине Visual Studio это ошибка, которую Microsoft решила не исправлять, потому что она «слишком сложна», и они пообещали пересмотреть систему сборки C ++, которая теперь предназначена для Visual Studio 2010.

Это было некоторое время назад, и, возможно, исправление даже вошло в Visual Studio 2008; Я больше не следил за этим. Тем не менее, наш типичный обходной путь был

  • Конфигурация коммутатора
  • Перезапустите Visual Studio
  • Постройте решение

После этого проблема исчезнет навсегда или просто временно? А что вы подразумеваете под "конфигурацией коммутатора"? Например, я всегда использую конфигурацию отладки. Что я должен делать?
ночной кодер

Временно исчезает. На самом деле, это может не быть решением для вас, если вы никогда не переключите конфигурацию между отладкой и выпуском. Или переключение на выпуск, а затем отладка может это исправить, кто знает;)
OutOfMemory

Ну, несколько дней назад я переключился на выпуск, построил решение, а затем снова переключился на Debug. После этого проблема видоизменилась :): теперь я получаю только 1 такую ​​ошибку вместо нескольких - это как будто другие проекты были «исправлены» :)
nightcoder

2

У меня была такая же проблема сама.

Visual Studio 2013 только сказал мне, что не может ссылаться на него и не может найти метаданные. Когда я открыл свое решение (в котором есть несколько проектов), он сказал, что я использую проекты ниже, чем базовая версия одного из моих проектов.

Поэтому я перешел на версию 4.5, и она снова заработала.


Это было то же самое решение, к которому я пришел, имея эту проблему. Некоторые из ссылок использовали Framework выше, чем мое базовое приложение, когда я изменил Framework в базовом приложении на 4.5.2 (так же, как другие ссылки), проблема исчезла. Хотя VS ничего не сказал о различных версиях фреймворка ..
NoLifeKing

1

Кажется, я вспомнил, что у меня была похожая проблема несколько месяцев назад. Я решил это временно, скопировав DLL-библиотеку, на которую ссылаются, в папку Release, таким образом удовлетворяя ожидания Visual Studio. Позже я обнаружил ссылку на Release DLL в моем реальном коде. Вы должны попробовать выполнить поиск по всему проекту для \ release \ project.dll.

Кроме того, я заметил, что проекты модульных тестов Visual Studio иногда помещают атрибут «DeploymentItem» в каждый из методов тестирования, указывающий на целевую DLL, и если вы переключаетесь между Debug и Release, Visual Studio может запутаться, если DLL больше не будет в ожидаемом месте. По моему опыту, эти атрибуты можно безопасно удалить, если вы сами их не поместили в рамках сценария «одного развертывания».


1

У меня была эта проблема, и это было из-за недопустимого метода в библиотеке-нарушителе (DLL), которая не возвращала значение, например

public bool DoSomething()
{
   //I never bothered putting code here....

}

Когда я это прокомментировал, все скомпилировалось :)


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

1

Иногда VS2010 переключает мою конфигурацию с любого процессора на смешанную платформу. Когда это происходит, я получаю это сообщение об ошибке.

Чтобы решить эту проблему, я переключаюсь обратно на любой процессор:
1. Щелкните правой кнопкой мыши на решении и выберите свойства.
2. Нажмите Свойства конфигурации, а затем кнопку Диспетчер конфигурации ....
3. В разделе Платформа активного решения выберите Любой процессор.


1

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


1

Я закончил тем, что удалил свои ссылки (я добавил их должным образом, используя вкладку проектов, и они обычно строили очень хорошо), вручную отредактировал мои файлы .csproj и удалил странные записи, которые не принадлежали - и установил свои выходные данные для отладки и release, x86 и x64 и все остальные процессоры должны быть "\ bin" - я собрал его один раз, затем снова добавил ссылку (снова, используя вкладку проектов), и все снова заработало для меня Не нужно было перезапускать Visual Studio вообще.


1

Для меня это было вызвано тем, что цель Build была переписана, чтобы не выводить dll. Устранение этой ошибки для возврата к цели Build по умолчанию устранило проблему.


1

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


1
Вот Это Да! Я перепробовал так много вариантов, ничего не получалось. Но это решило проблему! Спасибо, приятель :)
Tharindu

0

Похоже, это происходит, когда вы извлекаете решение с несколькими проектами, между которыми есть ссылки, а вы еще не создали его. Если у вас есть ссылки непосредственно на библиотеки DLL, вместо ссылки на проект, вы получите это сообщение. Вы всегда должны использовать вкладку Projects в диалоговом окне Add Reference, чтобы добавить ссылку на проект в том же решении. Таким образом, VS может знать правильный порядок построения решения.


0

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

У меня есть ошибка Build в Helper Library (на которую ссылаются другие проекты), и вместо того, чтобы сообщить мне, что в Helper Library есть ошибка, компилятор выдает список ошибок типа MetaFile-not-found. После исправления ошибки сборки в вспомогательной библиотеке ошибки метафайла исчезли.

Есть ли какие-либо настройки в VS, чтобы улучшить это?


0

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


0

Была такая же проблема сегодня.

Мое приложение, приложения Windows Forms, случайно имело ссылку на себя. Weird.

После удаления ошибка исчезла.

Ссылка добавлялась каждый раз, когда я перетаскивал пользовательский элемент управления, расположенный в самом проекте Windows Forms, в форму.


0

У меня такая же проблема. Удаление и добавление dll вручную не помогло. ClassLibraries не компилировались для всех проектов и отсутствовали в папке ... \ bin \ Debug для проекта [потому что я очистил решение по ошибке]. Поскольку библиотека классов не компилируется, это означает, что в одном из этих подпроектов могут быть ошибки .

Решение: Поскольку мои dll находились там для папки ... \ bin \ Release , я попытался перестроить режим Release и обнаружил ошибку в одной строке в одном из подпроектов. Устранение ошибки и перестройка решения избавили от ошибки сборки.


0

Для меня Visual Studio создал проект name.v11 типа «Параметры пользователя решения Visual Studio». Я удалил этот файл и перезапустил, и все было хорошо.

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