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.

 

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

 

  • I hope the new .props files are handled better by Visual Studio than the .vsprops. With VS 2005 and 2008 the vsprops are not saved until I close the solution. So if I work for a day on the same solution my work is not being saved! If VS crashes I lose my work. Also when I go to close the solution I get a message "some vsprops files need to be saved". Usually these files are under source control (read-only) so the saving fails. But doesn't say which file failed. I have to remember which properties I edited for the past 8 hours, find which vsprops file they belong to, locate that file in source control and manually check it out. That's very bad workflow.

    Ideally the vsprops will be checked out as soon as I try to edit them. Less ideally Save All or building the solution should save them as well (and of course if they happen to change externally they should be automatically reloaded like the project files do). And least ideally, when it fails to save a props file VS should tell me the full name of the file that failed.

    There is a similar problem for setup projects - when I try to edit a property of a setup project I get an error that it is read-only. I have to manually check it out. Would be nice if this happens automatically like any other project files. This is not as big deal as the vsprops because I at least get the error as soon as I touch something, and I can also right-click -> check out.

  • Agreed with Ivo, especially when setting options like symbol patchs etc.  These need to be saved after editing, not exiting.

  • > Brian Tyler explains thoroughly this change and its benefits in this blog post.

    link is missing!

  • Another vote of agreement with Ivo. I could have sworn I'd brought this up on Connect previously, but I can't find it now.

    I think the reason it can't automatically check the .vsprops files out is because they're not part of the solution (as in, not visible in solution explorer like a normal source or project file.) Rather they're a special case of reference.

    That could still be fixed easily enough though, it'd be nice to have them automatically checked out, and saved when "save all" is used.

    (By the way, you can press the "save" button in the property manager overlay to save individual property sheets without waiting till you exit VS, even in 2005.)

    Personally, my biggest problem is the lack of a GUI for editing custom build rules. The new format is harder to write than the old one, so removing the GUI is a huge step backwards.

    Oh, and I disagree with "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." It clearly isn't better to have us edit three files instead of one, when the old syntax was perfectly workable and more streamlined.

  • Just click "blog post".  It's stealthy!

  • The examples above are really confusing.

    The first reference to "MyProject.vcproj" appears to be a solution file, not a project file.  The solution file references two projects "DependencyProject.vcproj" and "MainProject.vcproj".  Then, in the VS2010 coverted version of it, "MainProject.vcproj" is gone, replaced by "MyProject.vcxproj".

    I'm going to assume that you really meant "MyProject.vcproj" to be "MySolution.sln".  I'm also going to assume that the upgraded "MainProject.vcproj" is now called "MainProject.vcxproj" (not "MyProject.vcxproj").

    Now what happens if "MySolution.sln" includes both "MainProject.vcproj" and "DependencyProject.vcproj" with the dependency listed above, but "MyOtherSolution.sln" only includes "MainProject.vcproj".  Does the upgraded "MainProject.vcxproj" contain the dependency on "DependencyProject.vcxproj" or not?

  • BTW, I've been experimenting with this in VS2010 RC, and adding a dependency via "Project -> Project Dependencies" stores the dependency in the solution, just like it did in VS2008.

    To store the dependency in the .vcxproj file, select the project to contain the dependency and go to "Project -> Properties", "Common Properties", "Framework and References" and "Add New Reference".

  • @Dale Nichols.

    Thank you Dale for pointing this out. I was focused in the post on the conversion aspect, which behaves as I describd. I forgot to mention that we did not remove the "Project Dependencies" dialog and that we only added another way for defining project dependencies.

    The blog post content will be updated soon with a new paragraph explaining this.

    However, note that with VS2010 project dependencies defined in the solution are no longer triggering a reference entry in the main project link command line, as they used to trigger in Orcas.

    Thank you.

    Andreea Isac

  • @Dale Nichols

    Thank you Dale for finding the typos in the code snippets. The blog content will be updated soon with correct project and solution names.

    The answer to your question (about the two solutions sharing the same project, the project having a dependency, but the dependency being included in only one of the two solutions) depends on which solution you convert first and whether you chose to overwrite the converted project.

    If you convert the solution containing the main and the dependency projects, your converted main project will contain the dependency. If you convert the solution containing only the main project, the converted main project won't contain the dependency.

    If you convert them both and you pick the small solution first, make sure to overwrite the common project when the second solution conversion asks for it. If you convert the big solution first, do not allow project overwrite when the small solution will convert.

    Andreea Isac

  • @Ivo, JK, Andrew - About property sheets

    We are sorry to hear about your experience with property sheets. We are aware of these inconveniences but unfortunately we didn't find enough time to fix them for VS2010. However, we plan to rethink and reimplement the property sheets area in a future release.

    Let me give you some workarounds for these issues that will make your experience more enjoyable.

    For the property sheets saving problem: They are not saved with "save all", but there is a save button that has effect individually for each property sheet file selected in property manager. Similarly, the Ctrl+S shortcut has the same effect. Also, note that the build attempts to save all property sheets in use.

    For the lack of source control support: You can obtain full source control support if you add your property sheets as existing items into the solution. However, this is not possible if those property sheets are located outside the solution folders structure.

    Also, change notifications will be received and reload will become possible with property sheets as soon as they are solution items.

    Andreea Isac

  • @Andrew - custom build rules

    "Personally, my biggest problem is the lack of a GUI for editing custom build rules. The new format is harder to write than the old one, so removing the GUI is a huge step backwards."

    We are very sorry for not having enough time to implement a UI experience to help with custom build rules creation/maintenance. We definitely plan to include such feature in a future release.

    Until then, we will do our best in providing documentation and guidance, examples and direct help for particular scenarios on forums. Please do not hesitate to contact us on the VC forums if you need assistance with implementing a particular behavior in your custom build rules.

    "It clearly isn't better to have us edit three files instead of one, when the old syntax was perfectly workable and more streamlined."

    Andrew, note that we had to change the syntax to msbuild. This had to impact not only project files, but property sheets and custom build rules as well. The benefits of the msbuild system are more numerous and of greater impact than the temporary unfamiliarity of implementing new custom build rules. We hope to eliminate this unfamiliarity very soon with blog posts, answers on forums, documentation and examples.

    Note that all the custom build rules you already have should be automatically converted to the new format by our VS2010 convertor, without any investment from your part. Let us know if you encounter issues with your custom build rules after converting to VS2010.

    Also, with msbuild going forward, we recommended extending the build functionality with writing custom tasks. Custom build rules are mostly legacy and we don't recommend writing new ones. A few convincing reasons are lack of incremental support and impossibility of cancelling them during the build.

    I hope this answers your questions about the custom build rules changes. Let us know if you have other concerns about the changes we made in VS2010.

    Andreea Isac

  • > A few convincing reasons are lack of incremental support and impossibility of cancelling them during the build.

    This concerns me a bit. Why can't custom build rules be canceled in VS2010? Can't the build system issue a ^C or ^Break?

  • > A few convincing reasons are lack of incremental support and impossibility of cancelling them during the build.

    Phaeron, just to assure you, the above statement is not correct. Custom build rule supports incremental build in general and can be cancelled both through IDE and ^C.

    Li Shao, Project and Build Team

  • What happens if you have a project that has a dependency set, but that project is not in the current solution?  Will the compiler attempt to find the project and build it?

    We have a large solution with 50+ projects that have dependencies set. Since our solution is so big, we often just load the individual projects during editing for fast building.  What happens then?  Will the dependencies be lost?  Or will it attempt to back trace through the tree of dependencies and projects even though they're not in the solution and build them anyways, thus losing our speed benefit?  Or are such dependencies ignored?

  • Hello,

    After migrating from VS2008 post-build-events seem to fail in VS2010 because the macros TargetPath and TargetDir are wrong defined in VS2010.

    TargetPath and TargetDir seem to ignore the a customized value of "Output File".

    For intance, we set the "Output File" to "..\lib\mylib.lib", but the TargetPath is still "Release\mylib.lib" which is bogus.

    I hope, that this will be fixed in 2010, or am i missing something there?

Page 1 of 3 (36 items) 123