Project settings changes with VS2010


Hi, I am Andreea Isac, a developer on the Visual C++ team at Microsoft. I would like to present you a summary of all project settings that are stored in a different manner or place with Visual Studio 2010, compared with previous VS releases.


 


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.




 


Note, that if you need to go back to VS2008 for a quick experiment, your project does have such dependencies and you are not using your source control for this, changing the converted solution header section with the VS2008 version will result into losing all your P2P information.


 


VC Directories


We also implemented VC directories differently with VS2010. They are no longer found in Tools à Options à Project and Solutions, but in the property pages of a loaded project. The data support behind the UI consists of user property sheets that are normally imported by any project from [LocalAppData]\Microsoft\MSBuild\v4.0. You can control the VC Directories settings by customizing what user property sheets to be imported in your projects and this way you can define per project or global VC Directories settings. This brings again consistency with msbuild syntax (to have a property sheet instead of an ini file), more flexibility in setting up multiple projects on the same machine (instead of having a rigid per user /per machine environment) and better source control experience with enlistments across different machines (instead of always changing the machine specific settings). Brian Tyler explains thoroughly this change and its benefits in this blog post.


 


Additional reference search paths


A change that is tied with VC directories is that assembly search paths (from Property Pages à Framework and References à Additional reference search paths) is now part of the VC directories section, in the property pages of a loaded project. It makes sense to have all the paths defining the build environment defined in the same place.


 


Source control information


Another settings location change that happens with conversion to VS2010 is project source control information for mssccprj.scc hint file based providers (like Visual Source Safe). Since the project file extension changed to .vcxproj, source control providers may not able to track this new extension and create mssccprj.scc hint files for it. This change does not apply for solution source control information (because the .sln extension remained the same), or for any other types of files except the project file.


 


An example is, in VS2008, if the source control provider is able to write a mssccprj.scc file and persist there the project bindings (which is the default case for the vcproj files), the mssccprj.scc file would look like this:


 


Mssccprj.scc:


SCC = This is a Source Code Control file


[MyProject.vcproj]


SCC_Aux_Path = “\\SCCServer\SCCDatabase


SCC_Project_Name = “$/MyProject.root/MyProject/MyProject”, IQAAAAAA


 


VS2008 will then be able to use the binding from this provider-generated file, and the vcproj project file will only contain “SAK” triggers:


 


MyProject.vcproj:


                SccProjectName=”SAK”


                SccAuxPath=”SAK”


                SccLocalPath=”SAK”


                SccProvider=”SAK”


 


By default VS2010 does not find the mssccprj.scc file and the project file will contain the following source control information:


 


MyProject.vcxproj:


    <SccProjectName>”$/MyProject.root/MyProject/MyProject”, IQAAAAAA </SccProjectName>


    <SccAuxPath></SccAuxPath>


    <SccLocalPath>.</SccLocalPath>


    <SccProvider>MSSCCI:Microsoft Visual SourceSafe</SccProvider>


 


SccAuxPath value wasn’t migrated into the new project file because usually this property stores user specific information. This is migrated into the solution suo file.


 


Note that the recognized project extensions might be settable in the source control provider UI, e.g. for SourceSafe the project extension can be added in SourceSafe Explorer/Tools/Options/File Types/CreateSccFiles list.




Let us know if you have any questions.


 


Andreea Isac


Software Developer Engineer


VC Project System and Build Team