Using Visual Studio Project Properties Effectively for Multiple Projects and Configurations

Using Visual Studio project properties effectively for multiple projects and configurations

I just found out somthing I didnt think was possible (it is not exposed by the GUI) that helps make property sheet far more useful. The "Condition" attribute of many of the tags in the project property files and it can be used in the .props files as well!

I just put together the following as a test and it worked great and did the task of 5 (common,x64,x86,debug,release) separate property sheets!

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup Label="UserMacros">
    <!--debug suffix-->
    <DebugSuffix Condition="'$(Configuration)'=='Debug'">-d</DebugSuffix>
    <DebugSuffix Condition="'$(Configuration)'!='Debug'"></DebugSuffix>
    <!--platform-->
    <ShortPlatform Condition="'$(Platform)' == 'Win32'">x86</ShortPlatform>
    <ShortPlatform Condition="'$(Platform)' == 'x64'">x64</ShortPlatform>
    <!--toolset-->
    <Toolset Condition="'$(PlatformToolset)' == 'v90'">vc90</Toolset>
    <Toolset Condition="'$(PlatformToolset)' == 'v100'">vc100</Toolset>
  </PropertyGroup>
  <!--target-->
  <PropertyGroup>
    <TargetName>$(ProjectName)-$(Toolset)-$(ShortPlatform)$(DebugSuffix)</TargetName>
  </PropertyGroup>
</Project>

Only issue is the properties GUI cant handle it, a project that uses the above property sheet just reports default inherited values like "$(ProjectName)" for the target.

Visual Studio Solutions / Multiple project : How to effectively propagate project properties amongst several C++ projects

I think you need to investigate properties files, i.e. *.vsprops (older) or *.props (latest)

You do need to add the properties file manually to each project, but once that's done, you have multiple projects, but one .[vs]props file. If you change the properties, all projects inherit the new settings.

How to build project in multiple configurations to automate the build process?

I think you have to use msbuild script to build your project rather than VS IDE. Scripts are more flexible and can realize your requirements.

1) create a new file called build.proj and then add these on that file:

<Project>

 <ItemGroup>
    <!--include all c# csproj files to build these projects all at once-->
    <NetProjectFile Include="**\*.csproj" /> 
    <!--include the c++ proj files-->
    <NativeProjectFile Include="**\*.vcxproj" />
 </ItemGroup>
<Target Name="Build">
  <MSBuild Projects="@(NetProjectFile)" Targets="Restore;Build" Properties="Configuration=Debug;Platform=AnyCPU"/>
  
  <!--OutDir is the path of the execute file ,pdb.... if you also want the intermediate files to be in the same folder, you should also use IntDir -->
  <MSBuild Projects="@(NativeProjectFile)" Targets="Build" Properties="Configuration=Release;Platform=x86;OutDir=xxx\xxx\"/>
 
  <MSBuild Projects="@(NativeProjectFile)" Targets="Build" Properties="Configuration=Release;Platform=x64;OutDir=xxx\xxx\"/>

</Target>

</Project>

3) Just run msbuild build.proj -t:Build to get what you want.

Visual studio 2010 - retain project properties between different build configurations?

Configuration settings are stored in .vcproj / .vcxproj file. You could open it in some text editor and copy some settings manually, but it wouldn't be convenient. For now you could just open projects properties and copy these settings while switching Debug / Release configuration in the upper left corner of that window.

Next time when you are setting properties that are intended to be the same for all configurations, choose Configuration: All Configurations to avoid troubles.

How do I manage many configurations in Visual Studio?

Yes you have.

You can create a single set of project properties ("vsprops") and have multiple configurations inherit from that single set.

When you want to change something for in all of them, you just change the one they all inherit from.

Go to the property manager (View->Other Windows->Property Manager or View->Property Manager) and right click one of the configurations. choose "Add new project property sheet", give the new sheet a proper name. now when you right click the sheet you just created you can change the properties in it. you can add this sheet to any of the other configurations you have by right clicking it and selecting "Add Existing property sheet".

When you edit the properties of the configuration you can select for "Inherit from parent" this will set the value to whatever the parent has. Notice that for some fields the values are replaced - for instance "General->Output Directory" - while in others they are aggregated, for instance "C++->General->Additional Include Directories" The values of the proper configuration are added to the values inherited.

Visual Studio: can I copy a project's properties to use in another project?

Try using Property Sheets. These can create a single properties file that can be inherited by multiple projects.

1. Use "View > Other Windows > Property Manager" to bring up the Property Manager. It will show your projects and configurations.

2. Right click a configuration, and select "Add New Project Property Sheet...". You can name it, and select a location that works for all your projects.

3. Once created, you can edit its properties just as you would a build configuration.

4. To use that property sheet as the basis for other projects, just right click the configuration or project, and select "Add Existing Property Sheet...". Browse to where you saved the original sheet, and it will be inherited.

Any changes to the original sheet will be applied to any project that inherits it, unless they are overridden. If you go into properties higher up the chain, properties that override will have bold type for their values. To get them to always use the value in the base sheet, there will be a "inherit from parent or project defaults" option where applicable.

In Visual Studio projects, can a user macro be set across multiple configurations/platforms?

How property sheets work

Property sheets are simple lists of properties. Entries aren't per-configuration or per-platform.

If you add a property sheet to the top level of a project, it's added to all configuration/platform combinations underneath, as if you individually added that property sheet file to each configuration yourself.

All properties are therefore visible across all configuration/platform variants.

This means you can also do things like have one sheet for all your x86 configurations and a different sheet for all your x64 configurations, e.g. for build paths. That way all the rest of your properties in your code can just use $(MYLIB_INCLUDE) without worrying about whether it's a 32- or 64-bit build.

You can usefully combine per-configuration/platform and global property sheets, too, a property sheet can reference one further down the list. (Order is significant, and they seem to be read from bottom to top according to the UI).

You can check what the final values of properties are by going to edit a property in the main project properties page, and tabbing open the "Macros>" tab. This is useful when debugging ordering issues with one user macro referencing another from a different sheet.

Example of usage, with code

As an example, which you can download from pg_sysdatetime on github here, I created three property sheets:

• pg_sysdatetime.props is the master sheet that users can edit to change paths. It defines PGBASEDIR_x86 and PGBASEDIR_x64 macros with the paths to the 32-bit and 64-bit PostgreSQL installs on the system.

• pg_sysdatetime_x86.props is a simple wrapper that defines PGBASEDIR as $(PGBASEDIR_x86).

• pg_sysdatetime_x64.props does the same for $(PGBASEDIR_x64)

I added pg_sysdatetime.props to the top level of the project, so it got applied to all configuration/platform combinations.

I then added sysdatetime_x86.props to all x86 platform configurations, and sysdatetime_x64.props to all x64 platform configurations.

The properties editor looks like:

and I can see the macros properly defined when editing a property:

Now I can reference the PostgreSQL libdir, include directory, etc from anywhere in my project with simple macros like:

 $(PGBASEDIR)\lib

without caring whether I'm doing a 32-bit or 64-bit build, etc etc. So I can just edit settings for "all configurations", "all platforms" and know that they'll work for everything, I don't have to individually edit each one.

It's almost like using a Makefile from 1980 ;-)

---

Related Topics