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