Project settings changes with VS2010

MSBuild syntax

If you explore your project files on disk, you will notice that our default project extension changed from .vcproj to .vcxproj. The file extension for property sheets changed from .vsprops to .props and that their content format changed to msbuild syntax. As Marian Luparu explains in this blog post, moving to the msbuild syntax is a big step forward for VC build system. It provides to C++ developers with an open, extensible and customizable architecture, enriched with cool features (like better diagnostics).

Custom build rules

Custom build rules are no longer implemented solely via .rules files, but through a triplet of files .props/.targets/.xml.  VS2010 automatically converts any rules files that your projects reference into their corresponding .props/.targets/.xml. We plan to publish a separate blog post about custom build rules, but until then let me briefly describe the three files. Since property pages are data driven in VS2010 (as explained in this post), the xml file supports the property page UI of the custom build rule and defines at the same time the task that will be invoked during build. The “.props” file contains the default values for the properties defined in the xml file. The targets file defines the build behavior of the custom build rule. Custom build rules information is better structured in three distinct components (a property sheet, an inline task and a property page) and integrates more seamlessly with project system and build features.

Filters

If you inspect the content of the project file you will see how the filters information is no longer defined there. They exist now in a complementary file, located at the same level as the project file on disk, always having the following format for the name: [ProjectName].vcxproj.filters. Thus, the build information is separated from the solution explorer display information and incremental build will not be affected by an exclusive-UI settings change.

Project dependencies

Until Orcas, we used to define project dependencies only in the solution file and project references in the project file. Also, the project dependencies in some cases were implying a reference implicitly for e.g. a solution dependency between executable and library project would automatically pass the dependency to the link command line (not being more than a project reference defined at the solution level). With VS2010, we stopped supporting project dependencies defining implicit references and we also introduced a new way of defining project dependencies at the project level. Since a project reference and a project dependency are close concepts, both applying to a project, it made sense to have them represented together, in a consistent way, in the project file. As you will see in the snippets below, the only difference between a project reference definition and a project dependency definition consists in metadata that defines the output assembly inclusion/exclusion into/from the main project link command line.

Although we did not remove the “Project Dependencies” dialog, we recommend defining new project dependencies via the “Framework and References” dialog. You need to set the “Reference Assembly Output” property in the property page UI to false for a project dependency and to true for a project reference.

Because we recommend this pattern going forward, the conversion to VS2010 is also converting the project dependency information defined at solution level into project reference information defined at project level. What we have defined in the Orcas solution file after adding DependencyProject.vcproj as dependency for MainProject.vcproj (via ProjectàProject Dependencies… menu):

MySolution.sln:

Project(“{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}”) = “DependencyProject”, “DependencyProject\DependencyProject.vcproj”, “{AD3B5768-7679-4CEC-B4A7-3AD056B3632C}”

EndProject

Project(“{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}”) = “MainProject”, “MainProject\MainProject.vcproj”, “{BA6A25FC-401B-4F6F-BAF0-083708C6502A}”

                ProjectSection(ProjectDependencies) = postProject

                                {AD3B5768-7679-4CEC-B4A7-3AD056B3632C} = {AD3B5768-7679-4CEC-B4A7-3AD056B3632C}

                EndProjectSection

EndProject

It looks in the VS2010 project file like this:

MainProject.vcxproj:

  <ItemGroup>

    <ProjectReference Include=”..\DependencyProject\DependencyProject.vcxproj”>

      <Project>{ad3b5768-7679-4cec-b4a7-3ad056b3632c}</Project>

      <ReferenceOutputAssembly>false</ReferenceOutputAssembly>

    </ProjectReference>

  </ItemGroup>

The project name and GUID are information taken from the Orcas solution file. ReferenceOutputAssembly metadata is used to control whether the assembly pointed by the referenced project will be included or not into the command line of the compiler, during the build of the main project. Since we converted a relationship of “dependency” (as we call it in Orcas), which means only build order, we set the ReferenceOutputAssembly metadata to false.

To demonstrate the difference between converting an Orcas project dependency and an Orcas project reference, consider the following example of a referenced project added in Orcas via Project Properties – Framework and References.

In the Orcas project we would have:

MainProject.vcproj:

               <References>

                                <ProjectReference

                                                ReferencedProjectIdentifier=”{C0F77507-0B6F-41AC-A576-2D462FED270E}”

                                                RelativePathToProject=”.\ReferenceProject\ReferenceProject.vcproj”

                                />

                </References>

And in the VS2010 project we convert to:

MainProject.vcxproj:

<ItemGroup>

    <ProjectReference Include=”..\ReferenceProject\ReferenceProject.vcxproj”>

      <Project>{c0f77507-0b6f-41ac-a576-2d462fed270e}</Project>

      <CopyLocalSatelliteAssemblies>true</CopyLocalSatelliteAssemblies>

      <ReferenceOutputAssembly>true</ReferenceOutputAssembly>

    </ProjectReference>

  </ItemGroup>

The end result of the above is both projects DependencyProject and ReferenceProject showing up in the Framework and References window. In VS2008, only ReferenceProject would show up.