Не удалось найти файл метаданных c

Обновлено: 07.08.2024

Вот как я ссылаюсь на свои пользовательские элементы управления:

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

Я проверил порядок сборки и конфигурации зависимостей.

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

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

У меня просто была такая же проблема. Visual Studio не создает проект, на который ссылаются.

Письменные инструкции:

  1. Щелкните правой кнопкой мыши решение и выберите Свойства.
  2. Нажмите Конфигурация слева.
  3. Убедитесь, что установлен флажок "Построить" для проекта, который он не может найти. Если он уже установлен, снимите флажок, нажмите "Применить" и снова установите флажки.
  4. (Необязательно) Это необходимо сделать для режимов выпуска и отладки в свойствах решения.

Инструкции по захвату экрана:

  • Они говорят, что картинка стоит тысячи слов. Нажмите на GIF, чтобы увеличить масштаб, и, надеюсь, вам будет легко следить:

Это все еще может произойти в более новых версиях Visual Studio (у меня только что это произошло в Visual Studio 2013):

Еще одна попытка - закрыть Visual Studio и удалить файл .suo который находится рядом с файлом .sln . (Он будет сгенерирован заново при следующем Save all (или выходе из Visual Studio)).

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

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

Подробнее о файле .suo здесь.

Предлагаемый ответ не работает для меня. Ошибка является приманкой для другой проблемы.

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

Секция 1):

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

У меня было четыре ошибки такого типа ("файл метаданных не найден"), а также одна ошибка: "Не удалось открыть исходный файл (" ошибка не определена ")".

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

Перезапустите Visual Studio и повторите сборку.

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

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

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

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

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

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

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

Раздел (2):

Мой частный случай:

Я попробовал все шаги выше с различными перестановками и комбинациями с перезапуском Visual Studio несколько раз. Но это не помогло мне.

Итак, я решил избавиться от другой ошибки, с которой мне пришлось столкнуться ("Невозможно открыть исходный файл (" ошибка не определена ")").

Раздел (3):

Мораль истории:

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

Не удалось найти файл метаданных
Подскажите, как решить проблему с EF. После компиляции проекта (при добавлении Database First.

Не удалось найти файл метаданных
Доброго дня форумчанам. У меня возникло следующее недопонимание с VS2012: Преамбула: Работаю.

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

Обычно такая ошибка возникает в паре с другими ошибками компиляции. Эту ошибку можно игнорировать и сконцентрироваться на исправлении других.

Раз ошибка с неверным форматом URL, то убедитесь - как и сказано - что у URI верный формат. То есть схема://домен/путь Раз ошибка с неверным форматом URL, то убедитесь - как и сказано - что г URI верный формат. То есть схема://домен/путь

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

Добавлено через 10 минут
esenbek, еще раз повторяю, читайте документацию к этой библиотеке! Либо по F12 переходите к описанию метода и смотрите, что ей необходимо.

Не заметно. Перепроверьте код класса Loader - это же ведь ваш класс, если судить по пространству имен. В первую очередь инициализацию static членов. ??
я просто скачал и начал внедрять что и как. но блин вот эту ошибку не понимаю.


Ошибка: не удалось найти файл obj
вот сама ошибка "Hello World!.exe" (Win32). Загружено.

Ошибка Не удалось открыть редактор управления доступом.Не удаётся найти указанный файл
Здравствуйте мне нужно по инструкции зайти в свойства файла hosts - безопасность - дополнительно -.


Ошибка Метаданных "не найден идентификатор в справочнике Идентификатор объекта метаданных"
В общем ситуация следующая, только начал разбираться с 1С, скачал с оф сайта учебную версию для.

Ошибка:Не удалось переместить файл джумла
Не устанавливаются модули, не загружаются фотки в альбом.

Некоторая информация о решении:

Я работаю в режиме отладки, и Visual Studio жалуется на то, что не найдет dll: s в папке выпуска.

Проекты Visual Studio, о которых жалуются, используются многими другими проектами в решении.

У меня такая же проблема с другим решением.

Решение было создано с нуля.

В решении есть 9 проектов. Одна библиотека WPF и 8 классов, использующая dotnet 3.5.

Любые идеи о том, что вызывает эту проблему?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Windows 7 Ultimate 32
Visual Studio 2008
SQL Server v2005

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

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

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

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

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

Раздел (1):

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

Перезагрузите VS и попробуйте создать еще раз.

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

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

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

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

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

Раздел (2):

Мой частный случай:

Я пробовал все вышеперечисленные шаги с различными перестановками и комбинациями с повторным запуском VS несколько раз. Но это мне не помогло.

Раздел (3):

Мораль истории:

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

Некоторая информация о решении:

Я работаю в режиме отладки, и Visual Studio жалуется, что не нашел dll: s в папке выпуска.

Проекты, на которые жалуется Visual Studio, используются во многих других проектах решения.

Я изменил путь вывода по умолчанию для всех проектов на . \ build \ debug \ ProjectName и . \ build \ release \ ProjectName соответственно. (Просто чтобы собрать все файлы сборки в одном каталоге)

У меня такая же проблема с другим решением.

Решение было создано с нуля.

В решении 9 проектов. Один WPF и 8 библиотек классов с использованием dotnet 3.5.

Есть идеи о том, что вызывает эту проблему?

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

Для тех, кто не может его найти, Build / Configuration Manager относится к пункту меню Build -> Configuration Manager. Я только что столкнулся с этой проблемой, причиной была другая ошибка, из-за которой указанный проект не был успешно построен. Это было на чистой проверке, поэтому никаких файлов dll от предыдущих успешных сборок не существовало. Исправьте ошибки и убедитесь, что проект, на который есть ссылка, строится правильно. Иногда даже это не помогает, как отмечал Ник выше. В этом случае закрытие и перезапуск VS всегда помогало мне. YMMV. Не решил проблему. Я перезапустил VS, и это не решило проблему.

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

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

Действительно, я удалил все ссылки и добавил их снова.

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

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

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

Восстановить файл designer.cs очень просто.

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

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

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

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

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

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

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

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

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

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

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

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

Жалуются только те проекты, которые есть в моем решении.

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

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

Windows 7 Максимальная 32 Visual Studio 2008 SQL Server v2005

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

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

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

Я хотел бы отметить пару моментов.

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

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

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

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

Читайте также: