Error cs0009 не удалось открыть файл метаданных
Наиболее распространенный ответ - перейти к свойствам решения, перейти к настройке и снять флажок → применить → проверить и применить снова, но это не сработало
ОТВЕТЫ
Ответ 1
Ответ 2
Шаги по исправлению этой ошибки: Файл .dll файла MetaData не найден.
Очистить все проекты.
Выгрузить все проекты.
Обновить все проекты.
Тогда проблема решена.
Ответ 3
У меня была эта проблема с решением, содержащим несколько проектов.
Я думаю, это произошло от дублирования .csproj и добавления копии в решение. Файл .csproj содержит элемент <ProjectGuid> . Я установил GUID для скопированного проекта на новый.
Я также выполнил следующие шаги:
- Закройте решение
- Удалить папку bin
- Удалить все папки obj
- Открыть решение и построить
Ответ 4
Ответ 5
Дважды проверьте имя папки проекта. В моем случае моя папка проекта была названа с пробелами в ней. Когда я клонировал проект из Team Foundation Server с помощью git bash, пробелы в имени папки были преобразованы в: "%20". Изменение этих объектов в пространстве устранило проблему для меня.
Ответ 6
Я исправляю эту проблему, выполнив следующие действия:
- Чистое решение
- Закрыть Visual Studio
- Удаление /bin из каталога проекта
- Перезапустите Visual Studio
- Восстановить решение
Ответ 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 не создает проект, на который ссылаются.
- щелкните правой кнопкой мыши на решении и выберите Свойства.
- нажать Настройки слева.
- убедитесь, что установлен флажок "построить" для проекта, который он не может найти. Если он уже установлен, снимите флажок, нажмите Применить и установите флажки еще раз.
это все еще может произойти в более новых версиях 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 показал виновные строки. У меня был раздел под названием , который, казалось, висел на старом неправильном путь_к_файлу.
Так что простое исправление действительно:
- резервное копирование .файл csproj.
- найти неправильные пути .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.
Читайте также: