"macros", in the context of the project system, refer to "$(name)" formatted variables that can be used in the project's properties. in VC 5 and 6 there was support for using these kind of macros in some properties. in VS.NET 2002 we extended the support to virtually every property in the project system.

there are two kinds of macros in VS 2002 and 2003: a set of macros that are provided by the project system, such as "$(ProjectDir)" and "$(ConfigurationName)", and macros that are actually environment variables. when the project system evaluates (expands) the value of a macro, it first checks its list of built-in macros, and if it doesn't find it there, then looks in the environment. you can find a list of the built-in macros, and see what they evaluate to, by going to the property pages dialog, selecting any property that is a string-value (e.g. the #defines for the compiler) and clicking either the "..." button or the entry in the drop-down, depending on the property. this will bring up an edit control that has a button named "macros>>". clicking this button will expand the control so that it contains a list of the macros and their expanded values.

using environment variables as macros lets you create paths that are share-able and "source-code-control-able". for instance, if i add "c:\my_includes" to my include path property (C/C++ compiler, general page, additional include directories) then that project is not share-able by another developer who has my_includes installed at "c:\bobs_includes" or "d:\my_includes". but if i use "$(MyIncludes)" then it is. of course, i need to let all the other developers know that they need to set the "MyIncludes" environment variable, or provide them with a batch file that does it for them.

all this is pretty elementary so far, but a surprising number of people don't take full advantage of macros.

i should note one thing: some of the built-in macros are dependent on other built-in macros or properties. for instance, the "$(TargetName)" macro uses the linker's "output file" property, so if you set the "output file" prop to "$(TargetName)" you've clearly created a bad situation. the project system will stop the recursion at 32 evaluations, and print an error message (in the output window) when you build, but this is still something to be aware of.