ms.date: "10/25/2019"

The MSBuild system for C++ projects was introduced in Visual Studio 2010. In Visual Studio 2008 and earlier releases, the VCBuild system was used. Certain file types and concepts that depended on VCBuild either do not exist or are represented differently in MSBuild. This document discusses the differences in the current build system. To convert a Visual Studio 2008 project to MSBuild, you must use Visual Studio 2010. After the project is converted, you should use the latest version of Visual Studio to upgrade the to the current IDE and compiler toolset. For more information, including how to obtain Visual Studio 2010, see [Instructions for Visual Studio 2008](use-native-multi-targeting.md#instructions-for-visual-studio-2008).

The following sections summarize the changes from VCBuild to MSBuild. If your VCBuild project has custom build rules or macros that aren't recognized by MSBuild, see [Visual Studio Projects - C++](../build/creating-and-managing-visual-cpp-projects.md) to learn how to translate those instructions to the MSBuild system. The initial conversion from VCBuild to MSBuild is just an intermediate step. It isn't necessary to get the project file completely correct or to get the program to compile without errors. You are only using Visual Studio 2010 to convert the project to MSBuild format so that you get the project working in the latest version of Visual Studio.

Project files no longer use the .vcproj file name extension. Visual Studio 2010 automatically converts project files that were created by an earlier release of Visual C++ to the MSBuild format, which uses the .vcxproj extension for project files.

In Visual Studio 2008 and earlier, a *project property sheet* is an XML-based file that has a .vsprops file name extension. A project property sheet lets you specify switches for build tools such as the compiler or linker and create user-defined macros. In MSBuild, the file name extension for a project property sheet is .props.

In Visual Studio 2008 and earlier, a *rule file* is an XML-based file that has a .rules file name extension. A rule file lets you define custom build rules and incorporate them into the build process of a Visual Studio C++ project. A custom build rule, which can be associated with one or more file name extensions, lets you pass input files to a tool that creates one or more output files.

In the MSBuild system, custom build rules are represented by three file types, .xml, .props, and .targets, instead of a .rules file. When a .rules file that was created by using an earlier release of Visual C++ is migrated to Visual Studio 2010, equivalent .xml, .props, and .targets files are created and stored in your project together with the original .rules file.

In Visual Studio 2008 and earlier, the **$(Inherit)** macro specifies the order in which inherited properties appear on the command line that is composed by the project build system. The **$(NoInherit)** macro causes any occurrences of $(Inherit) to be ignored and causes any properties that would otherwise be inherited, not to be inherited. For example, by default the $(Inherit) macro causes files specified by using the [/I (Additional Include Directories)](../build/reference/i-additional-include-directories.md) compiler option to be appended to the command line.

In Visual Studio 2010, inheritance is supported by specifying the value of a property as the concatenation of one or more literal values and property macros. The **$(Inherit)** and **$(NoInherit)** macros are not supported.

A user file (.vcxproj.user) stores user-specific properties, for example, debugging and deployment settings. The *vcxproj.user* file applies to all projects for a particular user.

When **Solution Explorer** is used to add a file to a project, the filters file (*.vcxproj.filters*) defines where in the **Solution Explorer** tree view the file is added, based on its file name extension.

Visual C++ directories settings are specified on the [VC++ Directories Property Page](../ide/vcpp-directories-property-page.md). In Visual Studio 2008 and earlier, directories settings apply per-user and the list of excluded directories is specified in the *sysincl.dat* file.

To migrate VC++ directories settings from a *.vssettings* file that was created by an earlier release of Visual Studio:

1. Open the **Tools** menu, click **Import and Export Settings**

2. Select **Import selected environment settings**

3. Follow the directions in the wizard.

title: "Upgrading C++ projects from earlier versions of Visual Studio"

ms.date: "10/25/2019"

To upgrade a project created in Visual Studio 2008 or earlier, you must first use Visual Studio 2010 to convert the project from the VCBuild to the MSBuild format. For more information, see [Instructions for Visual Studio 2008](use-native-multi-targeting.md#instructions-for-visual-studio-2008).

To upgrade a project created in Visual Studio 2010 or later, simply open the project in the latest version of Visual Studio. Visual Studio offers to upgrade the project to the current schema. If you choose **No**, and you have the older version of Visual Studio on your computer, you can work in the project in a newer version of Visual Studio and continue to target the older toolset. For more information, see [Use native multi-targeting in Visual Studio to build old projects](use-native-multi-targeting.md). If you choose **Yes**, then the project will be converted and cannot be converted back to the earlier version. Therefore, in upgrade scenarios, it is good practice to make a copy of the existing project and solution files.

If your project must continue to run on Windows XP, you can upgrade it to Visual Studio 2019, but you have to specify the toolset as v141 or earlier.

When you upgrade a project, you get an upgrade report, which is also saved in your project folder as UpgradeLog.htm. The upgrade report shows a summary of what problems were encountered and some information about changes that were made, including:

3. Code that no longer compiles cleanly due to compiler conformance improvements or changes in the standard

4. Code that relies on Visual Studio or Windows features that are no longer available or header files that either aren't included in a default installation of Visual Studio, or were removed from the product

5. Code that no longer compiles due to changes in APIs such as renamed APIs, changed function signatures, or deprecated functions

6. Code that no longer compiles due to changes in diagnostics, such as a warning becoming an error

7. Linker errors due to libraries that were changed, especially when /NODEFAULTLIB is used

8. Runtime errors or unexpected results due to behavior changes

9. Errors that were introduced in the tools. If you encounter an issue, report it to the Visual C++ team through your normal support channels or by using the [Visual Studio C++ Developer Community](https://developercommunity.visualstudio.com/spaces/62/index.html) page.

Many upgraded projects and solutions can be built successfully without modification. However, the older the project, the more likely that it will require changes to project settings as well as source code. The C++ code editor displays red squiggles under the errors, and green squiggles to indicate warnings flagged by the default code analysis tools.

We recommend that you use the following guidelines to address the settings issues first, and then if the project still doesn't build, you can address the code issues. For more information, see [Overview of potential upgrade issues](../porting/overview-of-potential-upgrade-issues-visual-cpp.md).