Как открыть проект созданный в более поздней версии visual studio

Обновлено: 05.07.2024

Изменения не требуются.
Эти проекты можно без внесения изменений открыть в Visual Studio 2015, Visual Studio 2013, Visual Studio 2012 и Visual Studio 2010 с пакетом обновления 1 (SP1).
- Move, "C:\Work\Move\Move.sln"

Версия 30-ти дневная пробная:

Установленная версия: Enterprise

Visual Basic 2015 00322-80000-00000-AA161
Microsoft Visual Basic 2015

Visual C++ 2015 00322-80000-00000-AA161
Microsoft Visual C++ 2015

Инструменты моделирования и архитектуры 00322-80000-00000-AA161
Инструменты моделирования и архитектуры (Майкрософт)

SQL Server Data Tools 14.0.60519.0
Microsoft SQL Server Data Tools

TypeScript 1.8.36.0
Средства TypeScript для Visual Studio

Визуализатор PreEmptive Analytics 1.2
Расширение Microsoft Visual Studio для визуализации агрегированных сводок, полученных от продуктов PreEmptive Analytics.

Инструменты мобильных услуг Microsoft Azure 1.4
Инструменты мобильных услуг Microsoft Azure

Общие инструменты Windows Azure 1.8
Предоставляет общие службы для использования мобильными службами и инструментами Microsoft Azure.

Система проектов JavaScript 2.0
Система проектов JavaScript

. возможно придется не мытьем так катаньем.
ставьте Вижиал Студио предыдуших времен и
ИМ СООТВЕТСВУЮШИЕ сервер дата тулс.
например 2005>2008>2010>2012>2015

. где нибудь на страничке SSDT будет тема
миграции старых проектов

. реально -- это бардак -- совместимость
SQL Server-SSRS, VS, SSDT, старые проекты.

Пока не понятно, что значит: Источник данных "OLAP Data" содержит значение ImpersonationMode, которое не поддерживается для операций обработки.

вот занудный ютюб про установку.
В самом конце 12:26 мужик открывает студио и
создает новый проект SSAS SSIS или SSRS:

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

Более того, старый проект односторонне преобразовался и открылся!

Боюсь спугнуть свое счастье, но пора домой, а то отчислят за не посещаемость!

Завтра проверю процессинг и отпишусь по результатам.

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

Более того, старый проект односторонне преобразовался и открылся!

Боюсь спугнуть свое счастье, но пора домой, а то отчислят за не посещаемость!

Завтра проверю процессинг и отпишусь по результатам.

Для работы с кубами (в том числе и по старым проектам) в Visual Studio 2015 необходимо установить SQL Server Data Tools.
По умолчанию инсталлятор VS этот компонент не ставит. После установки VS по умолчанию можно еще раз запустить инсталлятор и доустановить SSDT. Однако это не помогает.

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

Проекты, созданные в предыдущих версиях VS, при открытии автоматически и безвозвратно преобразовываются в формат VS 2015.

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

Если вы выберете " нет", проект не будет обновлен. для проектов, созданных в Visual Studio 2010 и более поздних версий, можно по-прежнему использовать проект в более новой версии Visual Studio. Просто задайте свойства проекта, чтобы они продолжали работать с более старым набором инструментов. если вы оставляете старую версию Visual Studio на компьютере, его набор инструментов доступен в более поздних версиях. например, если проект должен продолжать работать в Windows XP, можно выполнить обновление до Visual Studio 2019. Затем вы указываете набор инструментов в качестве v141_xp или более ранней версии в свойствах проекта. Дополнительные сведения см. в разделе Использование собственного многоплатформенного нацеливания в Visual Studio для сборки старых проектов.

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

Обновление отчетов

При обновлении проекта появляется отчет об обновлении. Отчет также сохраняется в папке проекта как UpgradeLog.htm. В отчете об обновлении отображается сводка проблем, обнаруженных во время преобразования. В нем перечислены некоторые сведения о внесенных изменениях, включая:

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

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

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

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

Ошибки компоновщика из-за измененных библиотек, особенно при использовании параметра/NODEFAULTLIB.

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

Ошибки, появившиеся в средствах. если у вас возникла ошибка, сообщите о ней команде Visual C++ по стандартным каналам поддержки или с помощью страницы Community Visual Studio разработчика C++ .

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

задайте предпочтительные версии набора инструментов платформы, стандарта языка C++ и Windows SDK версии (если применимо). (Project > Свойства > Свойства конфигурации > Общие)

При наличии большого количества ошибок можно временно отключить некоторые параметры, пока вы их исправите. чтобы отключить этот /permissive- параметр, используйте Project > свойства > конфигурации свойства > языка C/C++ > . чтобы отключить параметр анализа кода , используйте свойства конфигурации Project > свойства > > Code Analysis.

Убедитесь, что все зависимости существуют и что пути к включаемым файлам или папкам библиотеки указаны правильно. (Project > Свойства > Свойства конфигурации > VC++ каталоги)

Выявление и устранение ошибок, вызванных ссылками на интерфейсы API, которые больше не существуют.

Устраните все оставшиеся ошибки, препятствующие компиляции. Сведения об устранении распространенных ошибок см. в статье Обзор возможных проблем с обновлением .

Снова включите /permissive- и исправьте все новые ошибки, вызванные несоответствием коду, который ранее был скомпилирован в MSVC.

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

Рассмотрим другие возможности для модернизации кода. Например, замените пользовательские структуры данных и алгоритмы на шаблоны из стандартной библиотеки C++ или в библиотеку с открытым исходным кодом. Используя стандартные функции, можно упростить поддержку кода другими пользователями. Можно быть уверенным, что этот код тщательно проверен и проверен многими экспертами по стандартам и широкому сообществу C++.

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

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

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

Если вы ищете сведения о последнем выпуске, см. версию этой страницы для Visual Studio 2022.

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

Типы проектов

В следующем списке описывается поддержка проектов Visual Studio 2017, созданных в более ранних версиях.

Теперь проекты моделирования называются в меню и шаблонах проектами проверки зависимостей.
UML-схемы больше не поддерживаются в Visual Studio 2017. UML-файлы указываются в обозревателе решений, как и ранее, но открываются как XML-файлы. Для просмотра, создания или изменения UML-схем следует использовать Visual Studio 2015.
В Visual Studio 2017 проверка архитектурных зависимостей больше не выполняется при сборке проекта моделирования. Вместо этого проверка осуществляется при сборке каждого проекта кода. Это изменение не влияет на проект моделирования, но необходимо внести изменения в проверяемые проекты кода. Visual Studio 2017 автоматически вносит необходимые изменения в проекты кода (дополнительные сведения).

Как Visual Studio определяет необходимость переноса проекта

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

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

совместимость с целевыми версиями платформ вплоть до Visual Studio 2013 RTM;

совместимость ресурсов времени разработки с предыдущими версиями Visual Studio (в частности, с различными каналами Visual Studio 2017, Visual Studio 2015 RTM и с обновлением 3, Visual Studio 2013 RTM и с обновлением 5, Visual Studio 2012 с обновлением 4, Visual Studio 2010 с пакетом обновления 1 (SP1)); в случае использования нерекомендуемых ресурсов времени разработки в Visual Studio 2017 предпринимается попытка обработать их корректно, не повреждая их, чтобы проект по-прежнему мог открываться в предыдущих версиях;

нарушение совместимости с предыдущими версиями вплоть до Visual Studio 2013 RTM и с обновлением 5 из-за новых ресурсов времени разработки.

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

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

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

С целью обеспечения максимальной совместимости с проектами, созданными в более ранних версиях, Visual Studio 2017 включает в себя необходимые цепочки инструментов MSBuild для поддержки значений ToolsVersion 15, 14, 12 и 4. Сборка проектов, в которых используется любое из этих значений ToolsVersion , должна выполняться успешно. (При этом необходимо учитывать, поддерживает ли вообще Visual Studio 2017 данный тип проекта, как описано в статье Целевые платформы и совместимость.)

Следующие шаги

Дополнительные сведения см. в следующих статьях:

См. также

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

Если вы ищете сведения о следующем выпуске, см. версию этой страницы для Visual Studio 2022.

Мы стараемся сохранить обратную совместимость с предыдущими версиями, такими как Visual Studio 2017, Visual Studio 2015, Visual Studio 2013 и Visual Studio 2012. Однако поддержка некоторых типов проектов также со временем меняется. Новейшая версия Visual Studio может не поддерживать некоторые проекты или же потребовать обновить проект так, что он больше не будет обратно совместимым.

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

Некоторые типы проектов требуют конкретных рабочих нагрузок. При отсутствии установленной рабочей нагрузки Visual Studio сообщает о неизвестном или несовместимом типе проекта. В этом случае проверьте параметры установки в Visual Studio Installer и повторите попытку. Дополнительные сведения о поддержке проектов в Visual Studio 2019 см. в статье Целевая платформа и совместимость для Visual Studio 2019.

Типы проектов

В следующем списке описывается поддержка проектов Visual Studio 2019, созданных в более ранних версиях.

Visual Studio 2017: Формат XPROJ поддерживается исключительно для переноса в формат CSPROJ. При открытии XPROJ-файла вам будет предложено перенести файл в формат CSPROJ в стиле SDK. (Будет создана резервная копия XPROJ-файла.) Проекты формата CSPROJ в стиле SDK не поддерживаются в Visual Studio 2015 и более ранних версиях.

Теперь проекты моделирования называются в меню и шаблонах проектами проверки зависимостей.
UML-схемы больше не поддерживаются в Visual Studio 2017 и Visual Studio 2019. UML-файлы указываются в обозревателе решений, как и ранее, но открываются как XML-файлы. Для просмотра, создания или изменения UML-схем следует использовать Visual Studio 2015.
В Visual Studio 2019 проверка архитектурных зависимостей больше не выполняется при сборке проекта моделирования. Вместо этого проверка осуществляется при сборке каждого проекта кода. Это изменение не влияет на проект моделирования, но необходимо внести изменения в проверяемые проекты кода. Visual Studio 2019 автоматически вносит необходимые изменения в проекты кода.

Из установщика Visual Studio 2019 были исключены версии пакетов SDK Windows 10, предшествующие обновлению Windows 10 Fall Creators Update (сборка 16299). Вы можете вручную скачать старые версии таких пакетов SDK или использовать их более новые версии.

Миграция проекта

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

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

совместимость с целевыми версиями платформ вплоть до Visual Studio 2013 RTM;

совместимость ресурсов времени разработки с предыдущими версиями Visual Studio (в частности, с различными каналами Visual Studio 2019, Visual Studio 2017; Visual Studio 2015 RTM и с обновлением 3, Visual Studio 2013 RTM и с обновлением 5, Visual Studio 2012 с обновлением 4, Visual Studio 2010 с пакетом обновления 1 (SP1)); в случае использования нерекомендуемых ресурсов времени разработки в Visual Studio 2019 предпринимается попытка обработать их корректно, не повреждая их, чтобы проект по-прежнему мог открываться в предыдущих версиях;

Группа разработчиков проекта оценивает эти критерии и создает запрос, если есть необходимость в поддержке, обеспечении совместимости и миграции. Мы пытаемся обеспечивать совместимость между версиями Visual Studio, чтобы проекты, создаваемые в одной версии Visual Studio, могли работать и в других версиях.

Иногда такая совместимость невозможна. Тогда в Visual Studio открывается мастер обновления для внесения необходимых односторонних изменений. Одним из этих односторонних изменений может быть изменение свойства ToolsVersion в файле проекта. Оно указывает, какая именно версия MSBuild может преобразовывать исходный код проекта в требуемые выполняемые и развертываемые артефакты.

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

С целью обеспечения совместимости с проектами, созданными в предыдущих версиях, Visual Studio 2019 включает в себя необходимые цепочки инструментов MSBuild для поддержки значений ToolsVersion 15, 14, 12 и 4. Сборка проектов, в которых используется любое из этих значений ToolsVersion , должна выполняться успешно. (При этом необходимо учитывать, поддерживает ли Visual Studio 2019 данный тип проекта, как описано в статье Целевая платформа и совместимость для Visual Studio 2019.)

Следующие шаги

Дополнительные сведения см. в следующих статьях:

См. также

Мы стараемся сохранить обратную совместимость с предыдущими версиями, такими как Visual Studio 2019, Visual Studio 2017, Visual Studio 2015, Visual Studio 2013 и Visual Studio 2012. Однако поддержка некоторых типов проектов также со временем меняется. Новейшая версия Visual Studio может не поддерживать некоторые проекты или же потребовать обновить проект так, что он больше не будет обратно совместимым.

Некоторые типы проектов требуют конкретных рабочих нагрузок. При отсутствии установленной рабочей нагрузки Visual Studio сообщает о неизвестном или несовместимом типе проекта. В этом случае проверьте параметры установки в Visual Studio Installer и повторите попытку. Дополнительные сведения о поддержке проектов в Visual Studio 2022 см. в статье Целевая платформа и совместимость.

Типы проектов

В следующем списке описывается поддержка проектов Visual Studio 2022, созданных в более ранних версиях.

Теперь проекты моделирования называются в меню и шаблонах проектами проверки зависимостей.
UML-схемы больше не поддерживаются в Visual Studio 2017 и Visual Studio 2019. UML-файлы указываются в обозревателе решений, как и ранее, но открываются как XML-файлы. Для просмотра, создания или изменения UML-схем следует использовать Visual Studio 2015.
В Visual Studio 2019 проверка архитектурных зависимостей больше не выполняется при сборке проекта моделирования. Вместо этого проверка осуществляется при сборке каждого проекта кода. Это изменение не влияет на проект моделирования, но необходимо внести изменения в проверяемые проекты кода. Visual Studio 2019 автоматически вносит необходимые изменения в проекты кода.

Миграция проекта

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

совместимость с целевыми версиями платформ вплоть до Visual Studio 2013 RTM;

совместимость ресурсов времени разработки с предыдущими версиями Visual Studio (в частности, с различными каналами Visual Studio 2022, Visual Studio 2019; Visual Studio 2017, Visual Studio 2015 RTM и с обновлением 3, Visual Studio 2013 RTM и с обновлением 5, Visual Studio 2012 с обновлением 4 и Visual Studio 2010 с пакетом обновления 1); в случае использования нерекомендуемых ресурсов времени разработки в Visual Studio 2022 предпринимается попытка обработать их корректно, не повреждая их, чтобы проект по-прежнему мог открываться в предыдущих версиях;

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

Какую редакцию VS вы используете? VS2008 Express, Standard, Pro или Team System? VS2010 Professional, Premium или Ultimate? Я ожидаю, что загруженный вами проект был создан с использованием более поздней версии Visual Studio и использует некоторые из этих расширенных функций. Таким образом, вы не можете открыть его.

Откройте файл .csproj для вашего решения в WordPad или текстовом редакторе. Ищите ProjectTypeGuids. Они указывают необходимые поддерживаемые типы для ваших решений. Ищите в интернете эти GUID, чтобы узнать, что им нужно. Например, E53F8FEA-EAE0-44A6-8774-FFD645390401 означает, что требуется «MVC 3.0»

Для Visual Studio 2010 (также для других версий):

Например, моя проблема заключалась в том, что я не установил Инструменты разработчика SharePoint, когда установил Visual Studio 2010 на свою виртуальную машину для разработки. Поэтому, когда я попытался открыть проект после удаления GUID, VS2010 сказал, что искомый путь не существует.

Поэтому VS2010 искал библиотеку SharePoint, которая не была установлена. Мне просто пришлось снова запустить установку, а затем добавить эту функцию.

Та же проблема с «Тип проекта не поддерживается этой установкой» для веб-проектов в VS 2010 Premium.

и GUIDs magic не помогли.

Те же проекты отлично работали на соседней коробке с VS 2010 Premium.

Как оказалось, единственное отличие заключалось в том, что в моей установке VS отсутствовали следующие установленные продукты (их можно найти в диалоговом окне «О VS»):

Инструменты разработчика Microsoft Office
Инструменты разработчика Microsoft Visual Studio 2010 SharePoint

Установка и удаление программ -> VS 2010 -> Настройка -> Проверка перечисленных выше продуктов - и проблема была решена.

У меня была такая же проблема при открытии решения NuGet с VS 2010 Ultimate, но следующая команда исправила это:

Вы также можете попробовать выполнить следующую команду:

Мои проблемы, потому что эта строка в проекте (.csproj) имеет новую строку (vs2010)

Когда я обновлюсь до

Я могу открыть снова

В дополнение к этому, «тип проекта не поддерживается этой установкой» может возникнуть, если вы пытаетесь открыть проект на компьютере, который не содержит целевой версии платформы.

В моем случае я пытался открыть библиотеку классов, которая была создана на машине с VS2012 и по умолчанию настроил целевую платформу на 4.5 . Поскольку я знал, что эта библиотека не использует какие-либо 4.5 биты, я решил проблему, отредактировав файл .csproj от <TargetFrameworkVersion>v4.5</TargetFrameworkVersion> до <TargetFrameworkVersion>v4.0</TargetFrameworkVersion> (или любой другой, подходящий для вашего проекта) и библиотека открыта.

У меня была эта проблема при попытке добавить проект WPF в решение WCF в Visual Studio Express 2012 для Web. Удаление содержимого между тегами «ProjectTypeGuids» и оставление только тегов решило проблему. Чтобы узнать, как редактировать файл .csproj, прочитайте комментарий MindStalker.

Проблема для меня заключалась в том, что мой ProjectTypeGuid был MVC4, но у меня не было этого на целевом сервере. Решением было изменить ProjectTypeGuids на библиотеку классов и включить в проект библиотеки DLL MVC, а не забрать их из GAC.

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

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

Решение:

Причина проблемы

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

Скопируйте этот проект в папку проекта Visual Studio, затем откройте его из Visual Studio, теперь он будет открыт.

Я сам нашел эту технику в Visual Studio 2013

У меня была такая же проблема. Проблема для меня была в файле .sln. В конце файла было несколько из следующих:

GlobalSection (TeamFoundationVersionControl) = предварительное решение

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

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

Откройте файлы проекта в Блокноте и найдите руководство по проекту. Затем погуглите, и вы узнаете, какой тип проекта не поддерживается вашей текущей установкой VS.

проверьте, присутствует ли одна и та же версия vs2010 на win7 и winXP. Я подозреваю, что типы проектов, представленные на winXP, не установлены в win7, и поэтому проекты выгружаются

Я использую Skydrive для обмена файлами проекта между копиями Visual Studio на моем ноутбуке и ПК.

В приложении metro skydrive есть настройка, заставляющая их копировать.

Это в VS2017. Один из файлов .csproj имел конфликт слияния из git, и я не разрешил его. Решение этой проблемы устранило.

Я получил это на windows 10.

Я понял, что пути к файлам слишком длинные.

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

Я клонировал проект (CleanArchitecture) и хотел переименовать пространство имен.

Я клонировал проект на
Затем я открыл , нажал , перешел на , поискал и заменил его на . Это изменило все вхождения пространства имен проекта на , примите имя файлов в !
Мне пришлось вручную перейти на , а затем изменить имя файлов .
Затем в Visual Studio перезагрузите проекты.

Я тоже столкнулся с этой проблемой. Я наконец-то вышел из этого с помощью этой помощи:

Доступно обновление, улучшающее стабильность Visual Studio 2012.

Обновление доступно через Центр обновления Майкрософт, а также его можно загрузить из Центра загрузки Майкрософт.

Глобальная версия этого обновления имеет атрибуты файлов (или более поздние атрибуты файлов), перечисленные в следующей таблице.

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