Ошибка "Файл метаданных '...\Release\project.dll' не найден в Visual Studio"
Недавно я начал получать это сообщение случайно:
Файл метаданных '...\Release\project.dll' не найден в Visual Studio
У меня есть решение с несколькими проектами. Текущий режим сборки - отладка, а все проекты настроены на отладку. Но когда я пытаюсь запустить основной проект - иногда он выдает мне несколько ошибок, все из которых представляют собой "файл метаданных...\Release\projectX.dll'не может быть найден" - и, похоже, он говорит о RELEASE папка, хотя текущий режим - отладка. Зачем? Я попытался найти ссылку на "Release\projectX.dll" во всех файлах решения и нашел ее в файле ResolveAssemblyReference.cache.
Я сделал хороший поиск по Интернету и нашел несколько человек с похожей проблемой, но не было никакого решения или, по крайней мере, никакого рабочего решения.
Я пытался удалить ссылки на эти проекты и прочитать их, но через некоторое время я снова начал получать эти ошибки.
Это похоже на ошибку. Почему он выполняет поиск ссылочных проектов в папках Release, когда я всегда использую режим отладки?
PS. Для тех, кто столкнулся с этой проблемой: я не мог решить ее простым способом. Исчезло только после переустановки винды:(
47 ответов
Все правильно... попробуй все...(чтобы немного потрачено много времени)
- У тебя плохой код? Исправьте это сначала.
- Чистое решение и перезапустите Visual Studio
- Удалить / добавить ссылки
- Проверьте ваш порядок сборки с большими проектами и проверьте
- Перестройка подпроектов вручную
- Скопируйте вручную библиотеки между проектами в соответствующие папки bin
- Пойди принеси кофе, поиграй в пинбол и возвращайся завтра... ты можешь подумать о чем-то другом.
У меня была точно такая же проблема. Большое визуальное студийное решение с более чем 50 проектами.
Все ссылки были добавлены как проекты. Порядок сборки проекта был правильным (щелкните правой кнопкой мыши по проекту и выберите порядок сборки).
Однако при создании некоторых проектов более высокого уровня "корневой" проект, от которого они зависели, не был построен.
Проблема заключалась в том, что эти проекты не были выбраны для сборки в текущей конфигурации (не знаю, как это произошло).
Чтобы проверить это, выберите "Диспетчер конфигурации" (меню "Сборка") и проверьте, настроены ли проблемные проекты на сборку.
Что ж, мой ответ - не просто краткое изложение всех решений, но оно предлагает нечто большее.
Секция 1):
В общем решения:
У меня было 4 ошибки такого типа ("файл метаданных не найден"), а также 1 ошибка "Не удалось открыть исходный файл (" ошибка не определена ")".
Я попытался избавиться от ошибки "файл метаданных не найден". Для этого я прочитал много постов, блогов и т. Д. И обнаружил, что эти решения могут быть эффективными (обобщая их здесь):
Перезапустите VS и попробуйте собрать снова.
Перейдите в "Обозреватель решений". Щелкните правой кнопкой мыши на Решение. Перейти к свойствам. Перейдите в "Диспетчер конфигурации". Проверьте, установлены ли флажки в разделе "Сборка" или нет. Если какой-либо или все из них не проверены, то проверьте их и попробуйте построить снова.
Если вышеуказанные решения не работают, следуйте последовательности, упомянутой в шаге 2 выше, и даже если все флажки установлены, снимите их, проверьте снова и попробуйте выполнить сборку заново.
Порядок сборки и зависимости проекта:
Перейдите в "Обозреватель решений". Щелкните правой кнопкой мыши на Решение. Перейти к "Зависимости проекта...". Вы увидите 2 вкладки: "Зависимости" и "Порядок сборки". Этот порядок сборки является тем, в котором строится решение. Проверьте зависимости проекта и порядок сборки, чтобы убедиться, что какой-то проект (скажем, "проект1"), который зависит от другого (скажем, "проект2"), пытается построить этот проект (проект2). Это может быть причиной ошибки.
Проверьте путь к отсутствующему.dll:
Проверьте путь к отсутствующему.dll. Если путь содержит пробел или любой другой недопустимый символ пути, удалите его и попробуйте построить заново.
Если это причина, то отрегулируйте порядок сборки.
Раздел (2):
Мой частный случай:
Я попробовал все шаги выше с различными перестановками и комбинациями с перезапуском VS несколько раз. Но это не помогло мне.
Итак, я решил избавиться от другой ошибки, с которой мне пришлось столкнуться ("Невозможно открыть исходный файл (" ошибка не определена ")").
Я наткнулся на блог: http://www.anujvarma.com/tfs-errorsource-file-could-not-be-opened-unspecified-error/
Я попытался выполнить шаги, упомянутые в этом блоге, и избавился от ошибки "Невозможно открыть исходный файл (" ошибка не определена ")", и неожиданно избавился и от других ошибок ("файл метаданных не найден").
Раздел (3):
Мораль истории:
Попробуйте все решения, как указано в разделе (1) выше (и любые другие решения), чтобы избавиться от ошибки. Если ничего не получится, как в блоге, упомянутом в разделе (2) выше, удалите записи всех исходных файлов, которых больше нет в исходном элементе управления и файловой системе, из вашего файла.csproj.
Когда вы говорите, что удалили ссылки на эти проекты и заново их добавили, как вы их точно добавили? Использовали ли вы вкладку "Обзор" в диалоговом окне "Добавить ссылку" в Visual Studio? Или вы использовали вкладку "Проекты" (в которой перечислены соседние проекты в вашем решении)?
Редактировать: если вы используете вкладку "Обзор" и вручную добавляете ссылку на свой DLL-файл, расположенный в папке /Release, Visual Studio всегда будет искать DLL-файл в этом месте, независимо от того, в каком режиме вы находитесь. в настоящее время в (Отладка или Выпуск).
Если вы удалили действительный файл.dll из папки выпуска (вручную или с помощью "Чистого решения"), то ваша ссылка прекратится, потому что.dll не существует.
Я бы предложил удалить ссылку на ProjectX.dll и добавить ее снова, но на этот раз используйте вкладку "Проекты" в диалоговом окне "Добавить ссылку". Когда вы добавляете ссылку таким образом, Visual Studio знает, где взять соответствующий DLL-файл. Если вы находитесь в режиме отладки, он получит его из папки /Debug. В режиме Release, папка /Release. Ваша ошибка сборки должна исчезнуть, и вы больше не будете (неправильно) ссылаться на Release .dll в режиме отладки.
У меня была эта проблема раньше, и я нашел единственный способ ее решения - запустить Clean Solution и перезапустить Visual Studio.
Для меня обычно целевая платформа отключена (4.5.2 вместо 4.6). Если вы исправите целевую инфраструктуру проекта так, чтобы она соответствовала целевой платформе решения и сборки, будет создан новый.dll.
Большинство респондентов говорят, что вам нужно удалить библиотеки вашего решения, это правда, но при повторном добавлении библиотек ошибка будет снова показана. Необходимо проверить, все ли указанные библиотеки имеют совместимую инфраструктуру.net с платформой.net вашего решения. Затем исправьте все ошибки в своем коде и перестройте решение.
Вы проверили настройки диспетчера конфигурации? В диалоге настроек проекта в правом верхнем углу.
Иногда случается так, что между всеми записями выпуска появляется запись отладки. Если это так, автоматическая зависимость, созданная графом зависимостей решения, запутывается.
В моем случае у меня были некоторые ошибки в моем коде. Visual Studio показала вашу ошибку вместо реальных ошибок, таких как синтаксические ошибки или неизвестные имена классов. Попробуйте очистить решение и построить проект после проекта. Таким образом, вы обнаружите фактические ошибки.
Опять же, это как раз то, что вызывает ошибку для меня.
В моем случае это было вызвано двумя причинами (VS.2012):
1) Один из проектов был настроен для AnyCPU вместо x86
2) Проект, на который ссылались, как-то не отмечен.
Проверьте свою сборку | Configuration Manager для получения обзора того, что создается и для какой платформы. Также убедитесь, что вы проверили его для Debug & Release, так как они могут иметь разные настройки.
Эта проблема связана с файлами pdb или CodeContracts.
Чтобы решить это:
Очистите выходную папку и перестройте решение.
Переконфигурируйте CodeContracts или отключите его для временной сборки.
Я также видел эту ошибку в решениях, в которых у меня есть несколько проектов (обычно это проекты netTiers, в которых я обновил один или несколько подпроектов для платформы 4.0). Это может быть проблематично удалить. Однако часто это можно устранить, сначала исправив все другие ошибки в подпроектах (например, любые отсутствующие ссылки), по отдельности перестроив эти подпроекты, а затем удалив / добавив обратно все ссылки на эти подпроекты в Visual Studio. Лично мне не повезло решить эту ошибку, очистив решение в одиночку.
У меня была такая же проблема сама.
Visual Studio 2013 только сказал мне, что не может ссылаться на него и не может найти метаданные. Когда я открыл свое решение (в котором есть несколько проектов), он сказал, что я использую проекты ниже, чем базовая версия одного из моих проектов.
Поэтому я перешел на версию 4.5, и она снова заработала.
У меня была эта проблема, и мне потребовалось много времени, чтобы понять ее. Проблема возникла, когда я удалил проекты из решения и заменил их пакетами nuget.
Решение, похоже, было хорошим, но файл.csproj по-прежнему содержал эти проекты несколько раз в качестве ссылки.
Кажется, что VS не очищает этот файл соответствующим образом. Он все еще ссылался на удаленные проекты под капотом. Когда вручную удалены ссылки из файла csproj, все снова работает! Wohoo
Мы сталкиваемся с этой проблемой довольно часто, но только со ссылками на проекты C++/CLI из проектов C#. Очевидно, в глубине Visual Studio это ошибка, которую Microsoft решила не исправлять, потому что она "слишком сложна", и они пообещали пересмотреть систему сборки C++, которая теперь нацелена на Visual Studio 2010.
Это было некоторое время назад, и, возможно, исправление даже вошло в Visual Studio 2008; Я больше не следил за этим. Тем не менее, наш типичный обходной путь был
- Конфигурация коммутатора
- Перезапустите Visual Studio
- Постройте решение
Мы недавно столкнулись с этой проблемой после обновления до Office 2010 с Office 2007 - нам пришлось вручную изменить ссылки в нашем проекте на версию 14 взаимодействий Office, которые мы используем в некоторых проектах.
Надеюсь, это поможет - нам понадобилось несколько дней, чтобы понять это.
У меня была эта проблема, и это было из-за недопустимого метода в библиотеке нарушителя (dll), которая не возвращала значение, например
public bool DoSomething()
{
//I never bothered putting code here....
}
Когда я это закомментировал, все скомпилировалось:)
Для меня было удалить / удалить всю папку.vs (которая является невидимой), а затем:
- Build
- Rebuild
и сделано.
Для меня это было вызвано тем, что цель Build была переписана, чтобы не выводить dll. Устранение этой ошибки для возврата к цели Build по умолчанию устранило проблему.
Кажется, я вспомнил, что у меня была похожая проблема несколько месяцев назад. Я решил это временно, скопировав DLL-библиотеку, на которую ссылаются, в папку Release, таким образом, удовлетворяя ожидания Visual Studio. Позже я обнаружил ссылку на Release DLL в моем реальном коде. Вы должны попытаться выполнить поиск по всему проекту для \ release \ project.dll.
Кроме того, я заметил, что проекты модульных тестов Visual Studio иногда помещают атрибут "DeploymentItem" в каждый из методов тестирования, указывающий на вашу целевую DLL, и если вы переключаетесь между Debug и Release, Visual Studio может запутаться, если DLL больше не будет в ожидаемом месте. По моему опыту, эти атрибуты можно безопасно удалить, если вы сами их не поместили в рамках сценария "одиночного развертывания".
Я обнаружил, что это обычно происходит со мной, когда у меня все еще есть объявление метода в интерфейсе, который реализует класс, но позже я удалил его и забыл удалить его из интерфейса. Обычно я просто сохраняю все решение каждые 30 минут, а затем просто возвращаюсь к более ранней версии, если не могу найти ошибку.
Я закончил тем, что удалил свои ссылки (я добавил их должным образом, используя вкладку проектов, и они обычно создавались очень хорошо), вручную отредактировал мои файлы.csproj и удалил странные записи, которые не принадлежали - и установил свои выходные данные для отладки и release, x86 и x64 и все остальные процессоры должны быть "\bin" - я собрал его один раз, затем снова добавил ссылку (опять же, используя вкладку проектов), и все снова заработало для меня. Не нужно было перезапускать Visual Studio вообще.
В моем случае я работал на ветке от мастера. поэтому я проверил основную ветку, запустил сборку и затем проверил свою ветку. Это исправило проблему. Если вы уже являетесь мастером, я предлагаю вам проверить предыдущий коммит, а затем собрать его.
Иногда VS2010 переключает мою конфигурацию с любого процессора на смешанную платформу. Когда это происходит, я получаю это сообщение об ошибке.
Чтобы решить эту проблему, я переключаюсь обратно на любой процессор:
1. Щелкните правой кнопкой мыши на решении и выберите свойства.
2. Нажмите Свойства конфигурации, а затем кнопку Диспетчер конфигурации....
3. В разделе Платформа активного решения выберите Любой процессор.
Старый вопрос, но я столкнулся с другим его вариантом. У меня возникла эта проблема при создании приложения Xamarin iOS, но рассматриваемый путь больше походил на
/.../MyApp/bin/Debug/netstandard2.0/ref/MyApp.dll.
Обратите внимание на/refчасть...
После некоторых размышлений выяснилось, что в файле .csproj для этого проекта присутствовала следующая строка:
<ProduceReferenceAssembly>true</ProduceReferenceAssembly>
Не знаю, как и почему это было добавлено, или почему эталонная сборка не создается, или даже почему проект iOS вообще пытается использовать эталонную сборку, но удаление устранило проблему для меня.
Кажется, это происходит, когда вы извлекаете решение с несколькими проектами, между которыми есть ссылки, а вы еще не создали его. Если у вас есть ссылки непосредственно на dll, вместо ссылки на проект, вы получите это сообщение. Всегда следует использовать вкладку "Проекты" в диалоговом окне "Добавить ссылку", чтобы добавить ссылку на проект в том же решении. Таким образом, VS может знать правильный порядок построения решения.
Была такая же проблема сегодня.
Мое приложение, приложения Windows Forms, случайно имело ссылку на себя. Weird.
После удаления ошибка исчезла.
Ссылка добавлялась каждый раз, когда я перетаскивал пользовательский элемент управления, расположенный в самом проекте Windows Forms, в форму.
То же самое случилось со мной сегодня, как описано Видаром.
У меня есть ошибка Build в Helper Library (на которую ссылаются другие проекты), и вместо того, чтобы сообщить мне, что в Helper Library есть ошибка, компилятор выдает список ошибок типа MetaFile-not-found. После исправления ошибки сборки в вспомогательной библиотеке ошибки MetaFile исчезли.
Есть ли какие-либо настройки в VS, чтобы улучшить это?
В VS 2015 удаление "Анализаторов" в разделе "Ссылки" решило проблему