In Visual Studio projects, can a user macro be set

I've recently encountered Property Sheets in Visual Studio, which provide a way to define user defined $(MACRO)s for a project. They're not what I really want but are the closest I can find in VS so far.

However, under the property manager (View -> Other Windows -> Property Manager) it doesn't seem to be possible to get the User Macros section of the configuration editor to show up unless you edit a specific configuration/platform combo, like Debug | Win32.

If you have quite a few configurations and want to (say) set a macro to the same value for all configurations on the same platform, this gets cumbersome fast.

When editing project properties normally you can select "All Configurations" and/or "All Platforms" to have changes copied to sub-sections. This isn't available when editing a property sheet.

Is there any way to set values in a property sheet for multiple configurations/platforms at once? Consider, for example, that you want to set a macro POSTGRES_INSTALL to %PROGRAMFILES%\PostgreSQL\9.3 for x64 targets and %PROGRAMFILES(x86)%\PostgreSQL\9.3 for x86 targets, is there any way to do that for multiple targets (Debug, Release, SomeCustomTarget) at the same time?

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