views:

2018

answers:

5

I have a number of solutions with a large number of projects in them. I would like to be able to define global settings for the solution that are used by all projects. For example an include directory. I want to be able to change the include directory in one place for all projects in the solutions.

When I searched for a solution I found a good description of the problem that matches mine exactly but the solution suggested there, project property sheets, are defined per project and not per solutions.

I could use environment variables or Visual studio settings, but then everyone that needs to compile te code has to define the exact same settings.

Can anyone suggest a way to do this? Thanks.

A: 

I searched exactly the same thing some time ago but didn't find exactly what i wanted.

The only thing that might be close to this feature are Property Sheets. That's not exactly global as it's owned by a project and used by others.

Klaim
A: 

Maybe you could add an MSBuild file to your solution in which you define a number of shared properties, and then <Import> that file into all your real projects?

That is, in your "settings" MSBuild file you define a number of properties:

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003"&gt;
    <PropertyGroup>
        <WinUnitIncludeDir>C:\Includes\WinUnit</WinUnitIncludeDir>
        <!-- Other shared properties go here -->
    </PropertyGroup>
</Project>

From your real projects, you can then refer to this:

<Project ...>
    ...
    <Import Project="path/to/settings.msbuild" />
    ...
    <Configurations>
        <Configuration ...>
            <Tool Name="VCCLCompilerTool"
                  ...
                  AdditionalIncludeDirectories="$(WinUnitIncludeDir)"
                  ... />
            ...
        ...
    ...
</Project>
Arnout
Visual C++ 2008 does not use MSBuild (it uses VCBuild), but you can use a similar technique with property files as suggested by @Stephen W. Carson. Visual C++ 2010 will use MSBuild.
jwfearn
+5  A: 

We use property sheets to accomplish this. A single property sheet can be assigned to all the projects in the solution. From then on you can change a setting in that one property sheet and it will affect all the projects.

Advanced tip: We actually use multiple property sheets, (e.g. one for release target types, one for debug target types). The tip is that the order is very important. If you're editing the project files by hand then the last property sheet will override settings in the previous property sheets in the list. If you're editing in the GUI, then the TOP one overrides the ones below it.

Stephen W. Carson
I too use a hierarchy of property sheets and it works well.
jwfearn
A: 

As others have suggested, property sheets can do what you want. The trick is to use InheritedPropertySheets as you would use #include in C++. NOTE: the XML is slightly different for project files and property sheet files. Here's a contrived and simplified example of two projects (prjA.vcproj and prjB.vcproj) including the same property sheet (sln.vsprops) which itself includes another (strict.vsprops):

strict.vsprops

<VisualStudioPropertySheet ...>
    <Tool Name="VCCLCompilerTool" WarningLevel="3" WarnAsError="true"/>
</VisualStudioPropertySheet>

sln.vsprops

<VisualStudioPropertySheet ... InheritedPropertySheets=".\strict.vsprops">
    <Tool
        Name="VCCLCompilerTool"
        PreprocessorDefinitions="NOMINMAX=1"
        RuntimeTypeInfo="true"
    />
</VisualStudioPropertySheet>

prjA.vcproj

<VisualStudioProject ...>
    <Configurations>
        <Configuration ... InheritedPropertySheets=".\sln.vsprops">
        </Configuration>
    </Configurations>
    ...
</VisualStudioProject>

prjB.vcproj

<VisualStudioProject ...>
    <Configurations>
        <Configuration ... InheritedPropertySheets=".\sln.vsprops">
        </Configuration>
    </Configurations>
    ...
</VisualStudioProject>

You may also find this question and its answers useful.

jwfearn
A: 

As suggested, you should look at Property Sheets (aka .vsprops files).
I wrote a very short introduction to this feature here.

Xavier Nodet