Error cs0009 не удалось открыть файл метаданных

Обновлено: 04.07.2024

Наиболее распространенный ответ - перейти к свойствам решения, перейти к настройке и снять флажок → применить → проверить и применить снова, но это не сработало

ОТВЕТЫ

Ответ 1

Ответ 2

Шаги по исправлению этой ошибки: Файл .dll файла MetaData не найден.

Очистить все проекты.

Выгрузить все проекты.

Обновить все проекты.

Тогда проблема решена.

Ответ 3

У меня была эта проблема с решением, содержащим несколько проектов.

Я думаю, это произошло от дублирования .csproj и добавления копии в решение. Файл .csproj содержит элемент <ProjectGuid> . Я установил GUID для скопированного проекта на новый.

Я также выполнил следующие шаги:

  • Закройте решение
  • Удалить папку bin
  • Удалить все папки obj
  • Открыть решение и построить

Ответ 4

Ответ 5

Дважды проверьте имя папки проекта. В моем случае моя папка проекта была названа с пробелами в ней. Когда я клонировал проект из Team Foundation Server с помощью git bash, пробелы в имени папки были преобразованы в: "%20". Изменение этих объектов в пространстве устранило проблему для меня.

Ответ 6

Я исправляю эту проблему, выполнив следующие действия:

  1. Чистое решение
  2. Закрыть Visual Studio
  3. Удаление /bin из каталога проекта
  4. Перезапустите Visual Studio
  5. Восстановить решение

Ответ 7

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

Как только я исправил это, проблема была решена.

Ответ 8

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

например:

должен быть

Ответ 9

Для меня уборка и строительство не работали. Выгрузка проекта не сработала. Перезапуск Visual Studio или даже компьютера не работал. Вот что сработало:

Перейдите к каждому из проектов, которые выдают ошибку, и в разделе "Ссылки" удалите ссылку на проблемный проект и добавьте ее снова. Это решает проблему.

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

Ответ 10

В моем случае мне пришлось открыть файл.csproj и вручную добавить ссылку, например, так (Microsoft.Extensions.Identity.Stores.dll отсутствовал):

Ответ 11

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

У меня была эта проблема, я попробовал все ранее предлагаемые ответы, а затем по подозрению проверил рамки. Один из проектов, на которые делается ссылка, был нацелен на 4.6.1, когда вызывающий проект был только 4.5.2.

Ответ 12

Ответ 13

Запуск этой команды в bash для удаления всех использованных ящиков для меня

Невозможно гарантировать, что это сработает для кого-то еще, но

Также имейте в виду, что он удалит все файлы bin, так как вам придется перестраивать все проекты. Очевидно, лучше всего использовать cd в соответствующем каталоге перед его использованием.

Ответ 14

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

Ответ 15

Закройте Visual Studio, найдите файл решения .suo, удалите его, снова откройте Visual Studio.

Ответ 16

Очистка моего решения вызвала эту проблему с Visual Studio 2017. Выгрузка/перезагрузка проектов или дополнительная очистка не имели значения. Единственное, что сработало, это закрытие и перезапуск Visual Studio.

Ответ 17

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

Обычно затрагиваются следующие файлы: AssemblyInfo.cs , .sln a Properties > Application > Assembly Имя Properties > Application > Assembly и Пространство имен по умолчанию. Убедитесь, что обновили их с новым именем.

Откройте проводник, если папка со старым именем все еще существует, ее необходимо удалить. Затем очистите и постройте решение, пока ошибка не исчезнет. (При необходимости очистите и постройте проект один за другим, особенно затронутый проект.)

Ответ 18

У меня была такая же ошибка. В моем случае я построил библиотеку (назовите ее commsLibrary), которая ссылалась на другие библиотеки, включая их в качестве проектов в мое решение. Позже, когда я собрал проект и добавил свой commsLibrary, всякий раз, когда я собирался построить, я получал файл метаданных, но ошибка не обнаруживалась. Поэтому я добавил библиотеки, на которые моя библиотека comms ссылалась на текущий проект, и затем смог их собрать.

Ответ 19

Переключение конфигурации с релиза - любой процессор на релиз - смешанные платформы решили мою проблему. Я подозреваю, что проект использует библиотеки классов, которые используют 32-битные COM-объекты.

Ответ 20

Столкнувшись с таким количеством неприятностей, вот решение, которое я нашел.

откройте этот файл в любом текстовом редакторе и найдите отсутствующий файл ItemGroup.

<ItemGroup> <None Include=". "/> </ItemGroup>

удалите ItemGroup и снова откройте ваш проект и соберите

Ответ 21

Ответ 22

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

Для меня было 44 ошибки; 43 оканчивался на .dll (поиск зависимости), а первый в списке ошибок заканчивался на .cs (поиск фактического класса). Я пытался очистить-собрать и очистить, выгрузить, перезагрузить, собрать, но ничего не получалось. Я закончил тем, что нашел класс в проекте и просто удалил его, так как он все равно показывался как недоступный, после чего последовала чистая сборка.

Это помогло мне! Надеюсь это поможет.

Ответ 23

У меня было 2 файла (и 2 класса) в одном проекте с тем же именем.

Ответ 24

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

Ответ 25

Для меня то, что сработало, было:

Удалите, а затем переустановите указанный пакет Nuget, в котором произошла ошибка.

Ответ 26

У меня была такая же проблема, и я попытался решения из файла метаданных .dll не удалось найти

но ничего из этого не сработало.

Таким образом, после проб и ошибок я исправил это, выгрузив и перезагрузив проект, выполнив это, сбросив файл конфигурации и исправив проблему.

Ответ 27

В моем случае я запустил тесты и получил ошибку CS0006. Оказалось, что я запускаю тесты в режиме Release. Переход в режим отладки исправил эту ошибку.

вот как я ссылаюсь на мои usercontrols:

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

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

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

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

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

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

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

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

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

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

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

Ну, мой ответ-это не только итог решения, но он предлагает больше, чем это.

разделе (1):

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

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

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

перезапустите Visual Studio и повторите попытку построения.

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

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

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

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

Проверьте путь пропавших без вести .dll:

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

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

Раздел (2):

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

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

Итак, я решил избавиться от другой ошибки, с которой я столкнулся ('Source Не удалось открыть файл (‘Unspecified error')').

раздел (3):

мораль:

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

один проект был 3.5, а другой ссылался на проект 4.6.1.

закрытие и повторное открытие Visual Studio 2013 работало для меня!

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

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

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

Так что простое исправление действительно:

  1. резервное копирование .файл csproj.
  2. найти неправильные пути .csproj файл и переименовать соответствующим образом.

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

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

в моем случае у меня есть установленный каталог ошибочными способами.

Если ваш путь решения что-то вроде "Мой проект%2c очень популярен%2C модульное тестирование%2C программного и аппаратного обеспечения.zip", он не может разрешить файл метаданных, возможно, мы должны предотвратить некоторые недопустимые слова, такие как %2c.

переименование пути в обычное имя разрешило мою проблему.

Я добавил новый проект в моей решение и начал получать это.

затем я закрыл Visual Studio 2013, снова открыл свое решение, и оно было скомпилировано нормально.

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

для меня это произошло, когда я включил новый проект в решение.

для меня он пытался найти DLL в пути, который раньше содержал проект, но мы переместили его в новый каталог. Решение имело правильный путь к проекту, но Visual Studio каким-то образом продолжала искать в старом месте.

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

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

для меня работали следующие шаги:

  • найти проект, который не строит
  • удалить/добавить ссылки на проекты в решении.

мой экземпляр проблемы был вызван общим проектом, в котором было Дублированное имя класса (под другим именем файла). Странно, что Visual Studio не смогла обнаружить это и вместо этого просто взорвала процесс сборки.

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

В конце концов я добрался до того, что дал мне ошибку компиляции. Я исправил ошибку, и после этого решение будет построено правильно.

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

ошибка CS0067: событие " XYZ " никогда не используется

Это, по какой-либо причине, не отображается в окне ошибки.

рекомендация-как глупо, как это может быть звук:

первый взгляд на ваш Окно Вывода!

Мне потребовалось полчаса, прежде чем эта идея пришла мне в голову.

в моем случае проблема заключалась в том, что я вручную удалил файл без компиляции, который был помечен как "отсутствует". Как только я удалил ссылку на Теперь отсутствующий файл и перекомпилировал - все было хорошо.

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

Если у вас есть пробел в имени решения, это также вызовет проблему. Удаление пробела из имени решения, поэтому путь не содержит %20, решит эту проблему.

просто указывая на вопиюще очевидное: если у вас нет "показать окно вывода при запуске сборки" включен, убедитесь, что вы заметили, если ваша сборка не работает (небольшая ошибка "build failed" в левом нижнем углу).

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

но использование свойства не было. Публикация была выполнена в конфигурации выпуска без DEBUG символ, очевидно.

возвращаясь к этому через несколько лет, эта проблема, скорее всего, связана с пределом максимального пути Windows:

Я запускаю Visual Studio 2013.

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

для моего случая это было то, что я прокомментировал классы в определенном (пустом) пространстве имен:

когда я удалил код пространства имен и команды импорта (использования) из него - это исправило проблему.

в сборке он также говорил-вместе с отсутствующим DLL-файлом проекта:

ошибка CS0234: имя типа или пространства имен " W "не существует в пространстве имен" X. Y. Z " (отсутствует ссылка на сборку?)

У меня тоже была такая же ошибка. Он прячется, как в нижеприведенном пути. Путь, который я упомянул для файла DLL, похож на "D:\Assemblies папка\Assembly1.файл DLL."

но исходный путь, на который ссылается сборка, был "D:\Assemblies%20Folder\Assembly1 - . файл DLL."

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

похоже, что такие ошибки связаны с тем, что Visual Studio не предоставляет правильную информацию об ошибке. Разработчик даже не понимает причину неудачной сборки. Это может быть синтаксическая ошибка или что-то еще. В общем, чтобы решить такие проблемы, вы должны найти корень проблемы (например, посмотрите журнал сборки).

в моем случае проблема была в том, что Error List окно не показало никаких ошибок. Но на самом деле был синтаксис ошибки; я нашел эти ошибки в Output Окно, и после их исправления, проблема была решена.

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

Немного информации о решении:

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

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

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

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

Решение создавалось с нуля.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Детальный подход:

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

Секция 1):

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

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

Перезапустите VS и попробуйте снова построить.

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

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

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

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

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

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

Если это причина, измените порядок сборки.

Раздел (2):

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

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

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

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

Раздел (3):

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

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

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

Я работаю в режиме отладки, и 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.

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