Visual studio - получение ошибки "Файл метаданных" XYZ "не найден" после редактирования

Ответ 1

В конце концов, что решило проблему:

1. Очистить каждый проект индивидуально (щелкните правой кнопкой мыши > Очистить).
2. Перестройте каждый проект индивидуально (щелкните правой кнопкой мыши > Перестроить).
3. Перестройте автозагрузку проекта.

Я думаю, по какой-то причине, просто очистка раствора имела иной эффект, чем конкретная очистка каждого проекта в отдельности.

Редактировать:
Что касается комментария @maplemale, кажется, что иногда требуется удаление и повторное добавление каждой ссылки.

Обновление 2019:
В прошлом этот вопрос привлекал много внимания, но, похоже, что после выпуска VS 2017 он привлек гораздо меньше внимания.
Таким образом, другое предложение будет - Обновление до более новой версии VS (> = 2017), и среди других новых функций эта проблема также будет решена

Ответ 2

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

Легко для reset зависимостей проекта -

• Выберите все проекты и щелкните правой кнопкой мыши по разгрузке
• Выберите все проекты и щелкните правой кнопкой мыши по перезагрузке.
• Реконструкция

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

Ответ 3

Одна из возможных причин может заключаться в том, что вы обновили некоторые из ваших проектов (в решении) до более высокой версии, например. от .NET 4.0 до 4.5 Это произошло в моем случае, когда я открыл решение в VS 2013 (изначально созданное с использованием VS 2010 и .NET 4.0). Когда я открылся в VS 2013, мой проект на С++ обновился до .NET 4.5, и я начал видеть проблему.

Ответ 4

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

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

• Очистить все решение
• Щелкните правой кнопкой мыши по каждому проекту в вашем решении, перейдите в "Свойства" и создайте пространство имен по умолчанию, а также имя сборки по умолчанию, как и в вашем коде (например, пространство имен перед именем класса).
• Проверить имена папок для каждого проекта, пройдя через проводник (там, где ваше решение для проекта). Если вы не согласуетесь с вашими проектами, сделайте его похожим (как шаг 2).
• Удалите все ссылки из каждого проекта, относящиеся к другому из того же решения, и добавьте его снова.
• В папке "Project Solution" вы найдете файл Visual С# Project. Щелкните правой кнопкой мыши и откройте "Блокнот". В ваших начальных строках вы найдете строки для каждого проекта, как показано ниже:

Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "**Client**", "**Client** \ **Client**.csproj", "{4503E259-0E3B-414A-9074-F251684322A5}" EndProject

Повторно проверьте имена папок (я выделил в BOLD) и сделаю их похожими на то, что вы сделали в шаге 2.

6. Очистите все решение снова

7. Постройте решение (если не работает, попытайтесь создать человека после очистки снова)

Ответ 5

Убедитесь, что все ваши зависимые проекты используют ту же версию .Net Framework. У меня была такая же проблема, вызванная зависимым проектом, использующим 4.5.1, тогда как все остальные использовали 4.5. Изменение проекта с 4.5.1 до 4.5 и восстановление моего решения устранили эту проблему для меня.

Ответ 6

XYZ не найден, потому что он еще не построен....

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

Ответ 7

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

Чтобы найти этот файл, закройте свою студию Virsual и найдите .suo из проводника файлов в вашем проекте.

PS: новый новый файл .suo будет создан снова, когда вы перестроете свой проект, и, надеюсь, этот недавно созданный не даст вам проблем.

Я надеюсь, что это поможет кому-то избавиться от этой анонимной ошибки:).

Ответ 8

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

Я обманул порядок сборки, никаких заказов на сборку, ссылаясь на отладочные DLL (которые были скомпилированы вручную)... НИЧЕГО, казалось, работало, пока я не нашел эти ошибки, которые не отображались при компиляции всего решения!!!!

Иногда, кажется, при компиляции, что компилятор будет существовать на некоторых ошибках... Я видел это в прошлом, когда после устранения проблем последующие компиляции отображали NEW ошибки. Я не знаю, почему это происходит, и для меня несколько редких проблем. Однако, когда у вас их есть, это настоящая боль, пытаясь выяснить, что происходит. Удачи!

Ответ 9

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

Раздел (1):

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

У меня было 4 ошибки такого типа ( "файл метаданных не найден" ) и 1 ошибка: "Исходный файл не может быть открыт (" Unspecified error ")".

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

Перезагрузите VS и повторите попытку.

Перейдите в раздел "Обозреватель решений". Щелкните правой кнопкой мыши Решение. Перейдите в раздел "Свойства". Перейдите в "Configuration Manager". Проверьте, отмечены ли флажки в поле "Построить" или нет. Если какой-либо или все они не отмечены, проверьте их и попробуйте снова создать.

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

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

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

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

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

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

Ответ 10

Используете ли вы инструмент создания кода базы данных, например SQLMETAL, в своем проекте?

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

В моем случае, я отметил, что некоторые старые имена плюрализированных (*) таблиц (по которым SQLMETAL добавляет по умолчанию букву s "в конце) ссылки на таблицы, сгенерированные SqlMetal.

Так как я недавно отключил Плюралирование имен, после реорганизации некоторых классов, связанных с базой данных, некоторые из них потеряли префикс " s". Поэтому все ссылки на затронутые классы таблиц стали недействительными. По этой причине у меня есть несколько ошибок компиляции, например:

'xxxx' не содержит определения для "TableNames" и никакого метода расширения "TableNames", принимающий первый аргумент типа "yyyy", может быть найден (вам не хватает директивы using или ссылки на сборку?)

Как вы знаете, я беру только ошибку, чтобы предотвратить сборку сборки. И это недостающее assemply связано с зависимыми сборками, в результате чего исходный файл метаданных "XYZ" не найден "

После исправления затронутых таблиц классов ссылки вручную на их текущие имена (unpluralized), я был finnaly, способный вернуть мой проект!

(*) Если опция Visual Studio > меню "Сервис" > Параметры > Инструменты базы данных > Дизайнер O/R → Плурализация имен включена, некоторый генератор кода SQLMETALl добавит букву " s" в конце некоторых сгенерированных классов таблиц, хотя таблица не имеет суффикса "s" в целевой базе данных. Для получения дополнительной информации см. http://msdn.microsoft.com/en-us/library/bb386987 (v ​​= vs .110).aspx

Надеюсь, что это поможет!

Ответ 11

Мои 5 центов.

Эта проблема началась после того, как решение было чистым.

Мне удалось устранить проблему, установив конфигурацию Active Solution в: Build → Configuration Manager для выпуска. Затем создайте и установите его обратно для отладки снова. После этого сборка завершилась.

Ответ 12

Закройте VS, найдите и удалите папку "пакеты" снаружи визуальной студии. Перезагрузка VS и сборка → все зависимости переустановлены

Ответ 13

Для новой сборки возможно, что некоторые зависимости не установлены. Для меня это были Crystal Reports.

Ответ 14

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

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

Ответ 15

У меня возникла эта ошибка. Я следил за всеми решениями здесь, но ничего не получилось. Я использовал Visual Studio 2013 Professional. Я не мог заставить отдельные перестройки проекта работать, и я, наконец, понял, что в моих ссылках была круговая зависимость. Visual Studio делает довольно хорошую работу, как правило, предупреждая вас, если вы добавляете ссылку на что-то, что ссылается на нее, но по какой-то причине этого не произошло в этом случае. Я добавил ссылку на проект, который ссылался на проект, над которым я работал, и принял его. Возможно, ошибка VS?

Ответ 16

Это происходит, когда одна DLL проекта выходит из строя и на что ссылается количество проектов. Поэтому сначала исправьте его, а затем создайте людей.

Ответ 17

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

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

Ответ 18

Там также есть еще одна глупая причина, которую вы должны проверить с терпением... как это пришло мне в голову, потратив 4 часа на поиск ответов:

История для меня заключалась в том, что я случайно изменил небольшую строку кода среди тысяч файлов классов С#, а затем попытался перестроить решение. Как вы могли себе представить, у меня получилось 40 + метаданных без ошибок и с 1 ошибкой компиляции среди них, что я не проверял тщательно, чисто думая, что все ошибки были одинаковыми!

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

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

Ответ 19

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

Чтобы решить проблему, я перешел к каждому проекту, отличному от того, у кого есть основная функция, и right click > properites > output type > class library

Ответ 20

это случилось со мной, потому что у меня странное столкновение в пространствах имен: я имел AssemblyA с пространством имен AssemblyA.ParentNamespace ведьма определяет ClassA и в той же сборке другое пространство имен с именем AssemblyA.ParentNamespace.ChildNamespace witch определяет другой ClassA (но с тем же именем)

У меня тогда в AssemblyA.ParentNamespace IInterfaceB был метод, который в начале возвращает IEnumerable, а классB witch реализует IInterfaceB

Я позже модифицировал метод в ClassB, чтобы вернуть IEnumerable, но я забыл обновить определение IInterfaceB, поэтому метод все еще возвращал IEnumerable забавный факт заключался в том, что решение по-прежнему усложняется, если я все-таки перестроил, но тесты, на которые ссылается AssemblyA, не работали и возвращают ошибку "Метаданные не могут быть найдены".

обновление интерфейсаB для правильного возврата IEnumerable в качестве своего конструктора ClassB решило проблему, к сожалению, сообщение об ошибке было неопределенным, а также тот факт, что работа с компиляцией заставляла меня предположить, что, возможно, в компиляторе есть что-то исправить

Ответ 21

У меня было это и удалось исправить это, используя этот ответ SO: Файл метаданных '.dll' не найден

Мне нужно было снять все флажки, нажать "Применить", снова установить все флажки и снова нажать "Применить", но это устранило проблему.

Ответ 22

Я просто столкнулся с этой проблемой, и через час после того, как я понял, я добавил файл aspx для своего продукта, который имел то же имя, что и один из моих классов Linq-To-Sql. Класс и страница где "Очередь".
Изменил страницу на QueueMgr.aspx и все построено просто отлично.

Ответ 23

Коллега столкнулся с этой проблемой, и причина ускользала от нас. В конце концов мы поняли, что каталог проекта (и, следовательно, путь к пакетам NuGet) содержал %20 (спасибо, некоторый инструмент Git GUI, который не должен называться), и сообщения об ошибках показали, что компилятор искал очень похожий путь но тот, который должен был %20, а скорее пробел. Очевидно, что-то в системе сборки где-то выполняет HTML-декодирование на пути к локальной файловой системе.

Переименовал каталог рабочей копии, и все начало работать.