Как открыть проект visual studio 2019 в visual studio 2012
Чтобы обновить проект, созданный в более ранней версии Visual Studio, просто откройте проект в последней версии Visual Studio. Visual Studio предлагает обновить проект до текущей схемы.
Если вы выберете "Нет", проект не обновляется. Для проектов, созданных в Visual Studio 2010 и более поздних версиях, вы по-прежнему можете использовать проект в более новой версии Visual Studio. Просто задайте свойства проекта, чтобы продолжать ориентироваться на старый набор инструментов. Если вы оставляете старую версию Visual Studio на компьютере, его набор инструментов доступен в более поздних версиях. Например, если проект должен продолжать работать в Windows XP, можно выполнить обновление до Visual Studio 2019 года. Затем набор инструментов указывается как v141_xp или более ранней версии в свойствах проекта. Дополнительные сведения см. в разделе Использование собственного многоплатформенного нацеливания в Visual Studio для сборки старых проектов.
Если выбрать "Да", проект будет обновлен на месте. Его нельзя преобразовать обратно в более раннюю версию. В сценариях обновления рекомендуется создать резервную копию существующих файлов проекта и решения.
Visual Studio 2022 имеет нерекомендуемую поддержку обновления типов проектов, имеющих .dsw или .dsp расширения. Для обновления этих проектов можно использовать более раннюю версию Visual Studio, например Visual Studio 2019, а затем обновить их в Visual Studio 2022, чтобы использовать новейшие средства и функции Visual Studio.
Обновление отчетов
При обновлении проекта вы получите отчет об обновлении. Отчет также сохраняется в папке проекта как UpgradeLog.htm. В отчете об обновлении показано, какие проблемы были обнаружены во время преобразования. В ней перечислены некоторые сведения о внесенных изменениях, в том числе:
Код, который больше не компилируется чисто из-за улучшений соответствия компилятора или изменений в стандарте.
Код, основанный на функциях Visual Studio или Windows, которые больше не доступны. Или файлы заголовков, которые либо не включены в установку Visual Studio по умолчанию, либо были удалены из продукта.
Код, который больше не компилируется из-за изменений в API, таких как переименованные API, измененные сигнатуры функций или устаревшие функции.
Код, который больше не компилируется из-за изменений в диагностике, таких как предупреждение становится ошибкой
Ошибки компоновщика из-за измененных библиотек, особенно при использовании /NODEFAULTLIB.
Ошибки среды выполнения или непредвиденные результаты из-за изменений в поведении.
Ошибки, появившиеся в средствах. Если возникла проблема, сообщите о ней команде Visual C++ через обычные каналы поддержки или на странице Сообщество разработчиков C++ Visual Studio C++.
Некоторые обновленные проекты и решения можно успешно создать без изменения. Однако для большинства проектов, скорее всего, потребуется изменить параметры проекта и исходный код. Нет единого правильного способа решения этих проблем, но мы рекомендуем использовать поэтапный подход. Прежде чем начать, ознакомьтесь с обзором потенциальных проблем обновления , чтобы получить дополнительные сведения о многих типах распространенных ошибок.
Задайте набор инструментов платформы, стандарт языка C++ и Windows версию пакета SDK (если применимо) для предпочтительных версий. (Project>PropertiesConfiguration>PropertiesGeneral >)
Если у вас много ошибок, вы можете временно отключить некоторые параметры при их исправлении. Чтобы отключить /permissive- параметр, используйте Project>PropertiesConfiguration>PropertiesC>/C++>Language. Чтобы отключить параметр анализа кода, используйте свойства Project>PropertiesConfiguration> >Code Analysis.
Убедитесь в наличии всех зависимостей и правильности путей включения или расположений библиотеки. (свойства >Project>PropertiesConfiguration> VC++ каталоги)
Выявление и устранение ошибок, вызванных ссылками на API, которые больше не существуют.
Исправьте все оставшиеся ошибки, которые препятствуют компиляции. Общие сведения о потенциальных проблемах обновления для устранения распространенных ошибок.
Включите и исправьте /permissive- новые ошибки, вызванные несоответствием кода, ранее скомпилированного в MSVC.
Включите анализ кода для выявления потенциальных проблем или устаревших шаблонов кодирования, которые больше не считаются приемлемыми. Если анализ кода помечает множество ошибок, вы можете отключить некоторые предупреждения, чтобы сосредоточиться на наиболее важных из них. Интегрированная среда разработки может помочь в быстрых исправлениях для некоторых видов проблем.
Рассмотрите другие возможности модернизации кода. Например, замените пользовательские структуры данных и алгоритмы стандартными библиотеками C++ или библиотекой Boost с открытым кодом. Используя стандартные функции, вы упрощаете обслуживание кода другими пользователями. Вы можете быть уверены, что этот код был хорошо протестирован и проверен многими экспертами в комитете по стандартам и более широком сообществе C++.
Набор инструментов платформы
Набор инструментов платформы состоит из компилятора C++ (cl.exe) и компоновщика (link.exe) вместе со стандартными библиотеками C/C++. Studio 2015, Visual Studio 2017 и Visual Studio 2019 совместимы на уровне двоичного кода. Об этом свидетельствует основной номер версии набора инструментов, который остался равным 14. Проекты, скомпилированные в Visual Studio 2019 или Visual Studio 2017 обратно совместимы на уровне ABI с проектами, скомпилированными в Visual Studio 2017 или Visual Studio 2015. Дополнительный номер версии обновляется на 1 для каждой версии с выпуска Visual Studio 2015:
- Visual Studio 2015: v140
- Visual Studio 2017: v141
- Visual Studio 2019: v142
- Visual Studio 2022: v143
Целевая платформа (только для проектов C++/CLI)
Создавая пользовательские наборы инструментов платформы, можно расширить поддержку целевой платформы. Дополнительные сведения см. в блоге по Visual C++ Нативное многоплатформенное нацеливание в C++ .
В обозревателе решенийVisual Studio выберите проект. В строке меню откройте меню Проект и выберите Выгрузить проект. Это выгружает файл проекта (VCXPROJ) для вашего проекта.
Проект на языке C++ не может быть загружен, пока вы редактируете файл проекта в Visual Studio. Однако можно использовать другой редактор, например блокнот, чтобы изменить файл проекта, пока проект загружен в Visual Studio. Visual Studio определяет, что файл проекта был изменен и отображает запрос о необходимости перезагрузить проект.
В строке меню последовательно выберите Файл, Открыть, Файл. В диалоговом окне Открыть файл перейдите к папке проекта и откройте файл проекта (с расширением VCXPROJ).
Сохраните изменения и закройте редактор.
В разделе Обозреватель решенийоткройте контекстное меню своего проекта и выберите Перезагрузить проект.
Изменение набора инструментов платформы
В диалоговом окне выберите страницу свойств Свойства конфигурации>Общие.
На странице свойств щелкните Набор инструментов платформы и выберите необходимый набор инструментов из раскрывающегося списка. Например, если вы установили набор инструментов Visual Studio 2010, выберите Visual Studio 2010 (версия 100) для использования в проекте.
Each version of Visual Studio generally supports most previous types of projects, files, and other assets. You can work with them as you always have, and provided that you don't depend on newer features, Visual Studio tries to preserve backwards compatibility with previous versions like Visual Studio 2015, Visual Studio 2013, and Visual Studio 2012. (See the Release Notes for which features are specific to which versions.)
Support for some project types also changes over time. A newer version of Visual Studio may no longer support certain projects at all, or requires updating a project such that it's no longer backwards compatible. For current status on migration issues, refer to the Visual Studio Developer Community site.
This present article provides details only for project types that Visual Studio 2017 can migrate. The article excludes project types that are no longer supported in Visual Studio 2017 and cannot therefore be migrated. The article also excludes supported project types that have no migration issues; that list is found on Platform Targeting and Compatibility.
If you're looking for information specific to our newest release, see the Visual Studio 2022 version of this page.
Certain project types require installing the appropriate workloads through the Visual Studio installer. If you don't have the workload installed, Visual Studio reports an unknown or incompatible project type. In that case, check your installation options and try again. Again, see the Platform Targeting and Compatibility article for details on project support in Visual Studio 2017.
Project types
The following list describes support in Visual Studio 2017 for projects that were created in earlier versions.
If you don't see a project or file type listed here that should be, consult the Visual Studio 2015 version of this article and use the Send feedback about > This page button at the bottom of this page to provide details of your project. (If you use the anonymous "Is this page helpful?" control, we aren't able to respond to your feedback.)
- Modeling projects are now referred to as "Dependency Validation" projects in the menus and templates.
- UML diagrams are no longer supported in Visual Studio 2017. UML files are listed in the Solution Explorer as before but are opened as XML files. Use Visual Studio 2015 to view, create, or edit UML diagrams.
- In Visual Studio 2017, validation of architectural dependencies is no longer performed when the modeling project is built. Instead, validation is carried out as each code project is built. This change does not affect the modeling project, but it does require changes to the code projects being validated. Visual Studio 2017 can automatically make the necessary changes to the code projects (more information).
How Visual Studio decides when to migrate a project
Each new version of Visual Studio generally seeks to maintain compatibility with previous versions, such that the same project can be opened, modified, and built across different versions. However, there are inevitable changes over time such that some project types may no longer be supported. (See Platform Targeting and Compatibility for which project types are supported in Visual Studio 2017.) In these cases, a newer version of Visual Studio won't load the project and doesn't offer a migration path; you need to maintain that project in a previous version of Visual Studio that does support it.
In other cases, the newer version of Visual Studio can open a project, but must update or migrate the project in such a way that might render it incompatible with previous versions. Visual Studio uses a number of criteria to determine whether such migration is necessary:
Compatibility with the target versions of platforms, back to Visual Studio 2013 RTM.
Compatibility of design-time assets with previous versions of Visual Studio. (Namely different channels of Visual Studio 2017; Visual Studio 2015 RTM & Update 3; Visual Studio 2013 RTM & Update 5; Visual Studio 2012 Update 4; Visual Studio 2010 SP 1.) Visual Studio 2017 aims to fail gracefully with deprecated design-time assets without corrupting them, such that previous versions can still open the project.
Whether new design time assets would break compatibility with previous versions down to Visual Studio 2013 RTM & Update 5.
The engineering owner of the project type in question looks at these criteria and makes the call where support, compatibility, and migration are concerned. Again, Visual Studio tries to maintain transparent compatibility between Visual Studio versions if possible, meaning that one can create and modify projects in one version of Visual Studio and it just works in other versions.
If such compatibility is not possible, however, as with some of the project types described in this article, then Visual Studio opens the upgrade wizard to make the necessary one-way changes.
Such one-way changes may involve changing the ToolsVersion property in the project file, which denotes exactly which version of MSBuild can turn the project's source code into runnable and deployable artifacts that you ultimately want. That is, what renders a project incompatible with previous versions of Visual Studio is not the Visual Studio version, but the MSBuild version, as determined by ToolsVersion . So long as your version of Visual Studio contains the MSBuild toolchain that matches the ToolsVersion in a project, then Visual Studio can invoke that toolchain to build the project.
To maintain maximum compatibility with projects created in older versions, Visual Studio 2017 includes the necessary MSBuild toolchains to support ToolsVersion 15, 14, 12, and 4. Projects that use any of these ToolsVersion values should result in a successful build. (Subject, again, to whether Visual Studio 2017 supports the project type at all, as described on Platform Targeting and Compatibility.)
In this context, the question naturally arises whether you should try to manually update or migrate a project to a newer ToolsVersion value. Making such a change is unnecessary, and would likely generate many errors and warnings that you'd need to fix to get the project to build again. Furthermore, if Visual Studio drops support for a specific ToolsVersion in the future, then opening the project will trigger the project migration process specifically because the ToolsVersion value must be changed. In such a case, the subsystem for that specific project type knows exactly what needs to be changed, and can make those changes automatically as described earlier in this article.
Next steps
Refer to the following articles for further discussion:
See also
Each new version of Visual Studio supports most types of projects, files, and other assets. You can work with them as you always have, provided that you don't depend on newer features.
If you're looking for information specific to our next release, see the Visual Studio 2022 version of this page.
We try to preserve backwards compatibility with previous versions, such as Visual Studio 2017, Visual Studio 2015, Visual Studio 2013, and Visual Studio 2012. However, support for some project types changes over time. A newer version of Visual Studio might not support certain projects at all, or it might require that you update a project so that it's no longer backwards-compatible.
For current status on migration issues, refer to the Visual Studio Developer Community. And to learn more about which features are specific to which Visual Studio version, see the Release Notes.
Some project types require specific workloads. If you don't have the workload installed, Visual Studio reports an unknown or incompatible project type. In that case, check your installation options in the Visual Studio Installer and try again. For more information about project support in Visual Studio 2019, see the Platform Targeting and Compatibility page.
Project types
The following list describes support in Visual Studio 2019 for projects that were created in earlier versions.
If you don't see a project or file type listed here that should be, consult the Visual Studio 2017 version of this article. You can also use the Send feedback about > This page button at the bottom of this page to provide details of your project. (If you use the anonymous "Is this page helpful?" control, we aren't able to respond to your feedback.)
Visual Studio 2017: The xproj format is not supported other than for migration to csproj format. When you open an xproj file, you're prompted to migrate the file to the SDK-style csproj format. (A backup of the xproj file is made.) SDK-style csproj projects are not supported in Visual Studio 2015 and earlier.
- Modeling projects are now referred to as "Dependency Validation" projects in the menus and templates.
- UML diagrams are no longer supported in Visual Studio 2017 and Visual Studio 2019. UML files are listed in the Solution Explorer as before but are opened as XML files. Use Visual Studio 2015 to view, create, or edit UML diagrams.
- In Visual Studio 2019, validation of architectural dependencies is no longer performed when the modeling project is built. Instead, validation is carried out as each code project is built. This change does not affect the modeling project, but it does require changes to the code projects being validated. Visual Studio 2019 can automatically make the necessary changes to the code projects.
Windows 10 SDKs before the Windows 10 Fall Creators Update (build 16299) have been removed from the Visual Studio 2019 installer. You can download the older SDKs manually or retarget your projects to use the newer SDKs.
Migrate a project
While we try to maintain compatibility with previous versions, there can be changes that aren't compatible with previous versions. (See Platform Targeting and Compatibility for which project types are supported in Visual Studio 2019.) When this happens, a newer version of Visual Studio won't load the project or offer a migration path. You might have to maintain that project in a previous version of Visual Studio.
Sometimes, the newer version of Visual Studio can open a project, but it must update or migrate the project in a way that might render it incompatible with previous versions. Visual Studio uses a number of criteria to determine whether such migration is necessary:
Compatibility with the target versions of platforms, back to Visual Studio 2013 RTM.
Compatibility of design-time assets with previous versions of Visual Studio. (Namely different channels of Visual Studio 2019, Visual Studio 2017; Visual Studio 2015 RTM & Update 3; Visual Studio 2013 RTM & Update 5; Visual Studio 2012 Update 4; Visual Studio 2010 SP 1.) Visual Studio 2019 aims to fail gracefully with deprecated design-time assets without corrupting them, such that previous versions can still open the project.
Whether new design time assets would break compatibility with previous versions down to Visual Studio 2013 RTM & Update 5.
The engineering team that owns the project type looks at these criteria and makes the call where support, compatibility, and migration are concerned. Again, we try to maintain compatibility between Visual Studio versions so that when you create and modify projects in one version of Visual Studio, it just works in other versions.
Sometimes, compatibility isn't possible. Then, Visual Studio opens the upgrade wizard to make the necessary one-way changes. These one-way changes might involve changing the ToolsVersion property in the project file, which denotes exactly which version of MSBuild can turn the project's source code into the runnable and deployable artifacts that you want.
What renders a project incompatible with previous versions of Visual Studio is not the Visual Studio version, but the MSBuild version, as determined by ToolsVersion . If your version of Visual Studio contains the MSBuild toolchain that matches the ToolsVersion in a project, then Visual Studio can invoke that toolchain to build the project.
To maintain compatibility with projects that you created in previous versions, Visual Studio 2019 includes the necessary MSBuild toolchains to support ToolsVersion 15, 14, 12, and 4. Projects that use any of these ToolsVersion values should result in a successful build. (Subject, again, to whether Visual Studio 2019 supports the project type, as described on Platform Targeting and Compatibility.)
You might be tempted to manually update or migrate a project to a newer ToolsVersion value. It's unnecessary to make such a change, and would likely generate many errors and warnings that you must fix to get the project to build again. Also, if Visual Studio doesn't support a specific ToolsVersion in the future, then the project triggers the project migration process when you open it because its ToolsVersion value must be changed.
Next steps
Refer to the following articles for further discussion:
See also
Each new version of Visual Studio supports most types of projects, files, and other assets. You can work with them as you always have, provided that you don't depend on newer features.
We try to preserve backwards compatibility with previous versions, such as Visual Studio 2019, Visual Studio 2017, Visual Studio 2015, Visual Studio 2013, and Visual Studio 2012. However, support for some project types changes over time. A newer version of Visual Studio might not support certain projects at all, or it might require that you update a project so that it's no longer backwards-compatible.
For current status on migration issues, refer to the Visual Studio Developer Community. And to learn more about which features are specific to which Visual Studio version, see the Release Notes.
Some project types require specific workloads. If you don't have the workload installed, Visual Studio reports an unknown or incompatible project type. In that case, check your installation options in the Visual Studio Installer and try again. For more information about project support in Visual Studio 2022, see the Platform Targeting and Compatibility page.
Project types
The following list describes support in Visual Studio 2022 for projects that were created in earlier versions.
If you don't see a project or file type listed here that should be, consult the Visual Studio 2019 version of this article. You can also use the Send feedback about > This page button at the bottom of this page to provide details of your project. (If you use the anonymous "Is this page helpful?" control, we aren't able to respond to your feedback.)
Visual Studio 2017: The xproj format is not supported other than for migration to csproj format. When you open an xproj file, you're prompted to migrate the file to the SDK-style csproj format. (A backup of the xproj file is made.) SDK-style csproj projects are not supported in Visual Studio 2015 and earlier.
- Modeling projects are now referred to as "Dependency Validation" projects in the menus and templates.
- UML diagrams are no longer supported in Visual Studio 2017 and Visual Studio 2019. UML files are listed in the Solution Explorer as before but are opened as XML files. Use Visual Studio 2015 to view, create, or edit UML diagrams.
- In Visual Studio 2019, validation of architectural dependencies is no longer performed when the modeling project is built. Instead, validation is carried out as each code project is built. This change does not affect the modeling project, but it does require changes to the code projects being validated. Visual Studio 2019 can automatically make the necessary changes to the code projects.
Windows 10 SDKs before the Windows 10 Fall Creators Update (build 16299) have been removed from the Visual Studio 2019 installer. You can download the older SDKs manually or retarget your projects to use the newer SDKs.
Migrate a project
While we try to maintain compatibility with previous versions, there can be changes that aren't compatible with previous versions. When this happens, a newer version of Visual Studio won't load the project or offer a migration path. You might have to maintain that project in a previous version of Visual Studio.
Sometimes, the newer version of Visual Studio can open a project, but it must update or migrate the project in a way that might render it incompatible with previous versions. Visual Studio uses a number of criteria to determine whether such migration is necessary:
Compatibility with the target versions of platforms, back to Visual Studio 2013 RTM.
Compatibility of design-time assets with previous versions of Visual Studio. (Namely different channels of Visual Studio 2022, Visual Studio 2019, Visual Studio 2017, Visual Studio 2015 RTM & Update 3, Visual Studio 2013 RTM & Update 5, Visual Studio 2012 Update 4, and Visual Studio 2010 SP1.) Visual Studio 2022 aims to fail gracefully with deprecated design-time assets without corrupting them, such that previous versions can still open the project.
Whether new design time assets would break compatibility with previous versions down to Visual Studio 2013 RTM & Update 5.
The engineering team that owns the project type looks at these criteria and makes the call where support, compatibility, and migration are concerned. Again, we try to maintain compatibility between Visual Studio versions so that when you create and modify projects in one version of Visual Studio, it just works in other versions.
Sometimes, compatibility isn't possible. Then, Visual Studio opens the upgrade wizard to make the necessary one-way changes. These one-way changes might involve changing the ToolsVersion property in the project file, which denotes exactly which version of MSBuild can turn the project's source code into the runnable and deployable artifacts that you want.
What renders a project incompatible with previous versions of Visual Studio is not the Visual Studio version, but the MSBuild version, as determined by ToolsVersion . If your version of Visual Studio contains the MSBuild toolchain that matches the ToolsVersion in a project, then Visual Studio can invoke that toolchain to build the project.
To maintain compatibility with projects that you created in previous versions, Visual Studio 2019 includes the necessary MSBuild toolchains to support ToolsVersion 15, 14, 12, and 4. Projects that use any of these ToolsVersion values should result in a successful build. (Subject, again, to whether Visual Studio 2019 supports the project type, as described on Platform Targeting and Compatibility.)
You might be tempted to manually update or migrate a project to a newer ToolsVersion value. It's unnecessary to make such a change, and would likely generate many errors and warnings that you must fix to get the project to build again. Also, if Visual Studio doesn't support a specific ToolsVersion in the future, then the project triggers the project migration process when you open it because its ToolsVersion value must be changed.
Как правило, каждая версия 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 2013 RTM и с обновлением 5 из-за новых ресурсов времени разработки.
Группа разработчиков проекта оценивает эти критерии и создает запрос, если есть необходимость в поддержке, обеспечении совместимости и миграции. Мы пытаемся обеспечивать совместимость между версиями 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 поддерживает большую часть типов проектов, файлов и других ресурсов. С ними можно работать как обычно, при условии, что вы не зависите от новых функций.
Мы стараемся сохранить обратную совместимость с предыдущими версиями, такими как Visual Studio 2019, 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 2022 см. в статье Целевая платформа и совместимость.
Типы проектов
В следующем списке описывается поддержка проектов Visual Studio 2022, созданных в более ранних версиях.
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 не будет загружаться проект или предлагаться путь миграции. С этим проектом необходимо будет работать в предыдущей версии Visual Studio.
Иногда проект может открываться в более новой версии 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 предпринимается попытка обработать их корректно, не повреждая их, чтобы проект по-прежнему мог открываться в предыдущих версиях;
нарушение совместимости с предыдущими версиями вплоть до 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 2019 включает в себя необходимые цепочки инструментов MSBuild для поддержки значений ToolsVersion 15, 14, 12 и 4. Сборка проектов, в которых используется любое из этих значений ToolsVersion , должна выполняться успешно. (При этом необходимо учитывать, поддерживает ли Visual Studio 2019 данный тип проекта, как описано в статье Целевая платформа и совместимость для Visual Studio 2019.)
Мы можем по отдельности использовать текстовый редактор и компилятор, вручную компилировать и запускать программу в консоли или терминале, однако более удобный способ представляет использование различных сред разработки или IDE. Они, как правило, содержит встроенный текстовый редактор, имеет связь с компилятором, позволяя скомпилировать и запустить программу по одному клику мыши, а также еще множество разных вспомогательных возможностей.
После загрузки и запуска установщика Visual Studio в нем необходимо отметить пункт "Разработка классических приложений на C++":
Выбрав все необходимые пункты, нажмем ОК для запуска установки. После установки Visual Studio создадим первый проект. Для этого откроем Visual Studio. На стартовом экране выберем тип Empty Project для языка C++:
На следующем экране в поле для имени проекта дадим проекту имя HelloApp и также можно указать расположение проекта. И затем нажмем на Create для создания проекта.
Если в VS уже открыт какой-нибудь проект, то можно содать новый проект для C через меню File (Файл) -> New (Создать) -> Project. (Проект) и дальше повторить те же действия.
После этого Visual Studio создаст пустой проект. Добавим в него текстовый файл для набора исходного кода. Для этого в окне Solution Explorer (Обозреватель решений) нажмем правой кнопкой мыши на узел Source Files и в контекстом меню выберем Add -> New Item. :
Затем нам откроется окно для добавления нового элемента:
Здесь нам надо выбрать пункт C++ File(.cpp) , а внизу окна укажем для файла имя Hello.c . Как правило, исходные файлы на Си имеют расширение .с . Оно указывает, что этот файл содержит исходный код на языке С, и он будет обрабатываться соответствующим компилятором.
После добавления файла изменим опции проекта. Для этого перейдем к пункту меню Project -> Properties
Сначала в свойствах проекта установим, что это будет консольное приложение. Для этого перейдем к пункту Linker ->System и далее для поля SubSystem установим значение Console(/SUBSYSTEM:CONSOLE) , выбрав нужный элемент в списке:
После установки этого значения нажмем на кнопку "Применить", чтобы новые настройки конфигурации вступили в силу.
Также в окне свойств проекта в левой части перейдем к секции С/С++ и далее к пункту Advanced:
В правой части окна для поля Compile As установим значение Compile as C Code (/TC) . Тем самым мы говорим, чтобы по умолчанию исходный код компилировался именно как код С, а не С++. После установки этой опции нажмем на кнопку "Применить".
После добавления файла проект будет иметь следующую структуру:
Вкратце пробежимся по этой структуре. Окно Solution Explorer содержит в решение. В данном случае оно называется HelloApp. Решение может содержать несколько проектов. По умолчанию у нас один проект, который имеет то же имя - HelloApp. В проекте есть ряд узлов:
External Dependencies : отображает файлы, которые используются в файлах исходного кода, но не являются частью проекта
Header Files : предназначена для хранения заголовочных файлов с расширением .h
Resource Files : предназначена для хранения файлов ресурсов, например, изображений
Source Files : хранит файлы с исходным кодом
Теперь определим в файле Hello.c простейший код, который будет выводить строку на консоль:
Здесь использован весь тот код, который был рассмотрен в предыдущих темах про компиляцию с помощью GCC.
Теперь запустим программу. Для этого в Visual Studio нажмем на сочетание клавиш Ctrl+F5 или выберем пункт меню Debug -> Start Without Debugging :
Затем в папке Debug в проекте мы можем увидеть скомпилированный файл exe, который мы можем запускать независимо от Visual Studio:
В данном случае файл HelloApp.exe как раз и представляет скомпилированный исполняемый файл. Кроме этого файла в той же папке автоматически генерируются два вспомогательных файла:
HelloApp.ilk : файл "incremental linker", который используется компоновщиком для ускорения компоновки
Читайте также: