MSBuild Reserved Properties

msbuild c:\traversal.projMSBuildNodeCount -- if you passed the /m switch, it will give you the number of nodes being used. Normally not very useful, unless for some reason you have to special case when multiple threads are being used, in which case you can test for $(MSBuildNodeCount) < 2.

MSBuildLastTaskResult -- value is 'true' or 'false' depending on whether the last task run succeeded (returned true) or failed. Of course, typically when a task fails, it's the last thing that happens in that project, so you won't get a chance to see a value of 'false'. The exceptions are if the task had ContinueOnError="true", in which case execution continues but this property is set to 'false', or if it is tested in a target launched by an <OnError> tag.

MSBuildOverrideTasksPath -- MSBuild 4.0 has the concept of override tasks, which force themselves to be used instead of any with the same name defined elsewhere in a <UsingTask>. This is mainly in order to make multi-targeting work properly in 4.0, and isn't a generally useful feature, but in any case this property points to where the .overridetasks files that define these are.

MSBuildProgramFiles32 -- always points to the 32 bit program files folder, even on a 64-bit OS. To get the regular program files folder, you can just use $(ProgramFiles).

MSBuildProjectDirectoryNoRoot -- the full path to the project directory, but without the root part (such as "c:\"). This odd property is useful if you want to make a project output to a separate tree mirroring the project structure - for example if you want your source tree to be read-only, and your intermediates elsewhere, organized otherwise in the same tree as the project files and sources.

MSBuildStartupDirectory -- where MSBuild.exe was invoked from originally. If you want to have a setup where for example you can type "msbuild" in a folder and have it build everything in that folder or below, you can use this property to make a set of projects to build by doing something like this: <ProjectsToBuild Include="$(MSBuildStartupDirectory)\**\*.*proj"/>

MSBuildThisFile -- like MSBuildProjectFile but the actual file the property is in, rather than the main project file. This is useful for example when you want to your targets file to define some items whose location you know relative to that targets file. Q: Why can't you just use a relative path instead of this property? A: Because relative paths in item expressions are evaluated by MSBuild relative to the project file, not the file in which they are expressed.Q: Why are relative paths evaluated relative to the project file? A: Because often that way is useful, too. For example, every project file might have an app.config in the "config" folder below it, and your targets file wants to grab that and copy it. It's nice to be able to define an item like <FileToCopy Include="config\app.config"/> and know it will pick up the one below the project.

MSBuildThisFileDirectory -- similar to aboveMSBuildThisFileDirectoryNoRoot -- similar to aboveMSBuildThisFileExtension -- similar to aboveMSBuildThisFileFullPath -- similar to aboveMSBuildThisFileName -- similar to above

MSBuildToolsPath -- the key location defined in the current MSBuild "toolset". For example for the "v4.0" toolset, it points to the .NET 4.0 install folder, where microsoft.common.targets is. See note about MSBuildBinPath below.

MSBuildToolsVersion -- the "name" of the current MSBuild "toolset". So called because it's typically a version. MSBuild ships with "v2.0" "v3.5" and "v4.0". Do not confuse this with "TargetFrameworkVersion" which is just a property. There's more information on this elsewhere.

also MSBuildBinPath is present there, but is deprecated. It has exactly the same value as MSBuildToolsPath, which was introduced in 3.5 because it is a less misleading name. It's "tools path" because it points to where the key .targets and .tasks files are for the MSBuild Toolset (such as "v4.0" or "v3.5" or "v2.0") the project is using.MSBuildNodeCount -- if you passed the /m switch, it will give you the number of nodes being used. Normally not very useful, unless for some reason you have to special case when multiple threads are being used, in which case you can test for $(MSBuildNodeCount) < 2.

(restored line breaks and removed rogue edit about $(OS), which is an environment variable, not an MSBuild reserved property).

MSBuildExtensionsPath, MSBuildExtensionsPath32 and MSBuildExtensionsPath64 can be overridden using environment variables if required.

Note this forum discussion: http://social.msdn.microsoft.com/Forums/en-US/msbuild/thread/20c4d82b-8847-4704-b928-50a3aded1d5a

"During the cycle a change was made to the property $(MSBuildExtensionsPath). In the past this path always pointed to (by default) "C:\Program Files\MSBuild" on both a 32-bit and a 64-bit box.

The change was to make this point to (by default) "C:\Program Files\MSBuild" on a 32-bit box, or "C:\Program Files (x86)\MSBuild" on a 64-bit box."

Note that MSBuildThisFile... are not available in version 3.5, only 4.0:
http://sedodream.com/2010/03/11/MSBuild40ReservedProperties.aspx