Project settings changes with VS2010

Project settings changes with VS2010

Rate This
  • Comments 36

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.



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):



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


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}




It looks in the VS2010 project file like this:




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






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:











And in the VS2010 project we convert to:




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







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:



SCC = This is a Source Code Control file


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:








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



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



    <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


  • My problem (both MSB8006 and LNK1104) was that the upgrade set "Link Library Dependencies" to "True" instead of "False".  "Copy Local" should probably be "False" as well (I haven't verified this yet).

    I suspect this is the problem for several other people as well.

    Andreea Isac: "If your project has a dependency (or reference) set to another project that is not a member of your current solution it will be ignored. You will not see the dependency/reference either in "Project Dependencies" nor "Framework and References" dialogs. Also the solution build or the main project build will ignore to build any dependency/reference that is not part of the current solution. This behavior is different in the VS command prompt, msbuild will detect and will build the depndency/reference."

    [Dale] This does not appear to be correct.  The project won't be listed in the references, but it listed in the compiles.  For example, if "Link Library Dependencies" is "true", then the library will be listed on the link command line, even if it isn't in the solution.

    Note: Figuring all of this out is a lot of work, and there is a lot of misinformation out there, including from Microsoft.

  • Thank you Dale for your feedback. Before I posted my statement I made a quick verification and I was seeing how dependency/reference projects are not considered if they are not included in the solution. That was because the dependency and the reference projects were applications and not libraries or dlls. I do reproduce now a build break when dependency/reference project is not included in the solution and Link Library Dependencies is set to true.

    I will get back to you shortly with a resolution/workaround.

  • My custom build rule didnt convert correctly from 2005 to 2010. It resulted in a different command line. I now have to figure out how to edit the 3 build rule files and I then I need to figure out if its possible to change them in a way that will resolve my issue. :(

  • Ok, the problem I have is that $(OutDir) is used in the command Im using (xcopy) and its being represented in the command line with \\ appended to the end even though when viewed in the macro list the backslashes arent there. Anyway I dont think this is specifically a problem with the conversion but any thoughts would be appreciated. I did read this but it doesnt particularly help me.

  • Bmm... I can have a look. Can you make a small repro project for us, or describe a list of repro steps. You can also contact me at andris  at  microsoft  dot  com.

  • Hello VC Team,

    You said that Visual C++ projects are moved to MS Build Environnement and the extension is moved from vcproj to vcxproj what that it means?

    Because I recently learned about Code Document Object Model or CodeDOM classes of .NET 4.0 and I explored CppCodeProvider assembly for C++ developper interest. I was supprised that some classes are not fully implemented like CppCodeGenerator (marked obsolete) or Cpp CodeCompiler is missed so     I am not able to build a sample I took in MSDN about a simple C++/CLI syntaxe of Hello World Program to produce a correct Code DOM program graph and to build it into a assembly.

    I also recently learned in MSDN 2010 that it is possible to add a personnal BuildProvider class in <System.CodeDom> section of a web.config file of an ASP.NET Web Site Project. So It is possible to route ASP.NET Build Environnement to execute our CppCodeProvider to produce C++/CLI code as code behind of an ASP.NET Web page. Why no person of the team is focused on that possibility? Is it possible to add the keyword partial in C++/CLI syntaxe because it is required for language that support ASP.NET.

    Thanks, Excuse-me my english.

Page 3 of 3 (36 items) 123