Файл метаданных... не удалось найти ошибку при создании проектов

Ответ 1

У меня была аналогичная проблема, в которой "метаданные не могли быть найдены". в свойстве решения убедитесь, что флажок "build" помечен в "Build/Configuration Manager" для каждого проекта.

Ответ 2

Обычно это вызвано проектом, на который ссылаются в другом решении, чем тот, который бросает ошибку. Если вы очистите другое решение или отделите код, вы, скорее всего, увидите эту ошибку. Решение состоит в том, чтобы прокручивать список ошибок "не найденных метаданных" и просматривать ссылки на проекты. 9/10 раз вы увидите неверную ссылку на проект, который не находится в этом решении. Добавьте проекты, чтобы исправить опорные ошибки и перестроить. Это должно исправить это.

(Я просто столкнулся с этим сегодня и имел в прошлом, и это ВСЕГДА работало)

Ответ 3

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

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

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

Ответ 4

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

Ответ 5

Для меня у меня был проект, упомянутый в другом проекте. Он не показывал, что он был разбит в списке ссылок в окне проводника решений, но я все равно удалил и все это прочитал. Теперь он строит отлично!

Ответ 6

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

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

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

Ответ 7

То, как я обходился в прошлом в VS2005, а также сейчас в VS2008, - это убедиться, что все зависимости правильны, а ссылки указывают на проекты, а не на dll. Затем выполните и вручную создайте каждый проект в порядке зависимости. После сборки последней вы можете запустить полную сборку решений и ее штраф.

Этот ответ для будущих ссылок для других, поскольку я знаю, что вопрос более 15 месяцев.

Приветствия

Ответ 8

У меня есть несколько моментов, которые я хотел бы сделать.

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

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

Вы должны помнить, что способ создания сборки Visual Studio не совсем то же, что и MSBuild. Это связано с тем, что MSBuild в первую очередь зависит от файла проекта, чтобы сообщить ему, что такое зависимости, тогда как Visual Studio также может сохранять их в файле soltuion. Поэтому иногда вы можете видеть ситуации, когда Visual Studio отлично строит решение, но MSBuild просто не может этого сделать.

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

Я надеюсь, что эта информация поможет.

Ответ 9

Если вы используете контексты данных LinqtoSQL, например, и файл .designer.cs отсутствует, вы увидите, что файл метаданных не найден.

Воспроизведение файла designer.cs легко.

Откройте dbml с помощью представления xml. Добавьте пустую строку, затем удалите ее, затем сохраните. Это должно восстановить файл designer.cs.

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

Ответ 10

У меня есть аналогичная проблема каждый раз, когда я обновляю проект из SVN.
Еще одно решение для ASP.NET:

• Закройте среду IDE.
• Удалите файлы в C:\WINDOWS\microsoft.net\framework\v…\Temporary ASP.NET File\.

Ответ 11

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

Ответ 12

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

И в другой ситуации я переместил код из одного проекта в другой, и этот фрагмент кода ссылался на Json.net. Я вручную добавил ссылку на Json.net, но это вызвало проблему. Я решил это, установив Json.net через NuGet, и это заставило проблему уйти. Надежда, которая помогает кому-то.

Ответ 13

Сначала убедитесь, что флажок "build" помечен в Build → Configuration Manager для каждого проекта.

Если у вас уже есть все проекты, выбранные в меню "Build → Configuration Manager", и перезапуск VS трюка не работает для вас, как вам нужно найти ссылку на файл (может быть dll или cs) в вашем проекте и удалить эти ссылки вручную. Эти файлы (ы)/ссылки должны отображаться с желтым значком. Ошибка определенно подсказывает вам, какой проект решения вы должны изучать.

Причиной этой ошибки является то, что вы вручную удалили файл вручную в проводнике Windows, а VS не обновил ссылку и попытался найти файл, который больше не существует!

Ответ 14

То же самое произошло. У меня есть несколько решений, ссылающихся на те же проекты библиотек (.net 3.5). Я заметил, что когда один был построен в debug/normal config, а другой с использованием какой-либо другой директивы компилятора (sqlite/local mode), это произойдет. Просто получите оба проекта, построенные с одинаковыми директивами, и вы должны быть в порядке.

Ответ 15

Если вы добавили новый проект в решение, убедитесь, что он находится в списке сборки (см. Configuration Manager)

Ответ 16

Я застрял в проблеме сохранения, когда хотел включить DLL файл, созданный Matlab. И я, наконец, решил его, скопировав файл .ctf, что означает сертификат, я полагаю, и .netmodule, который необходим для правильной работы .dll, вместе с DLL файлом. И это действительно сработало! Итак, мое предложение - проверить, нужны ли DLL для любых других файлов.

Ответ 17

Windows 7 Ultimate 32 Visual Studio 2008 SQL Server v2005

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

Как только я reset ссылка на базу данных на правильную настройку, я смог построить без дальнейших проблем. Кроме того, это была моя первая попытка перестроить этот проект после разветвления исходного кода в VSS.

Удача

Ответ 18

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

Ответ 19

EE - В моем случае проблема была в проекте, который имеет структуру Entity, открыть диаграмму, перетащить любую таблицу 2 см:) и сохранить, VS обновит все свои ссылки на БД... построит эти проекты и построит решение, Buildssss.

Ответ 20

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

Ответ 21

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

Подробный подход:

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

Раздел (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.