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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Секция 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 .

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

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

Снова откройте Visual Studio с правами администратора.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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