VS2010, MSBuild and Environment Variables

Question

I have a question about MSBuild.exe and Environment Variables. First, the development environment:

The code is mostly C++ with some C#. There are over 5,000 classes, 340 projects and 200 solutions arranged in a deep source tree. There is a solution at the root of the tree and at various other points in the tree. We use TFS and maintain multiple active branches for a series of future releases. Each developer uses a local view to modify and test code. Some developers work on multiple branches concurrently. Sometimes developers build solutions from different TFS branches concurrently.

We use about 70 environment variables for locating shared header files, libraries, etc. In VS2008 we used a file with the same base name as the solution file and an extension of .slnenv for defining the environment variables. All variables are defined relative to the base of the source tree. This .slnenv file is read by a custom VS2008 AddIn that creates Environment Variables in the VS2008 process space, i.e.

  MyProjectDir=$(SolutionDir)\..\..
  MyRoot=$(MyProjectDir)\..\..
  MyInstallDir=$(MyRoot)\Install
  MySourceDir=$(MyRoot)\Source
  MyUnmanagedSourceDir=$(MySourceDir)\My\Unmanaged
  MyIncludeDirs=$(MyProjectDir);$(MyUnmanagedSourceDir)

This AddIn does not work correctly with VS2010 because MSBuild does not inherit the environment variables that are created after the solution is loaded.

My question is how do I get these environment variables to MSBuild? I have found two methods that work, but are not as convenient as the AddIn we had been using.

VS2010 can be started with a command script that first sets Environment Variables in the process space and then starts VS2010. MSBuild does inherit these Environment Variables. This is unsatisfactory because the scripts would need to be customized for the various points where a solution can be loaded.

The second method I have tried is defining the Environment Variables as Properties in property sheets and .vcxproj files. We have a base property sheet that all .vcxproj files load. In that property sheet:

  <PropertyGroup>
    <MyRoot>$(MyProjectDir)\..\..</MyRoot>
    <MyInstallDir>$(MyRoot)\Install</MyInstallDir>
    <MySourceDir>$(MyRoot)\Source</MySourceDir>
    <MyUnmanagedSourceDir>$(MySourceDir)\My\Unmanaged</MyUnmanagedSourceDir>
    <MyIncludeDirs>$(MyProjectDir);$(MyUnmanagedSourceDir)</MyIncludeDirs>
  </PropertyGroup>

Then I can define the base directory in each .vcxproj file:

  <PropertyGroup>
    <MyProjectDir>..\..</MyProjectDir>
  </PropertyGroup>

This method uses relative path names where the AddIn resolved all Environment Variables to absolute path names. I'd rather not have to edit 340 .vcxproj files where the definition of "MyProjectDir" would vary depending on how far from the source root the project file exists. So far I've tried this method in just one project.

I have tried to modify the AddIn to create Properties rather than Environment Variables. I tried using ENV2.get_Properties(), but that seems to work only for Properties that are defined in VS2010, not for Properties I've defined.

Thank you, Dan Kary

Answer 1

After discussion via email, we figured what were Dan needs and following message helps him with question issue. He agrees that this could be helpfull to other SO members:

Aha, I get it now.

As I did understand from that topic - you really need all that stuff only for build step (paths for include clause, paths to built tool to resolve dll\exe dependency), and no regular developer activities depends on it. It's good, cause we don't need to fight VStudio about not reinitializing env vars after first load. We just need somehow edit and implement your solution for huge amount of proj files ;) Task become much easier :D

Small disclaimer - I'm writing this on the road and have no access to fully fledged dev env to check and bulletproof all further recomendations, so take my apologizes in advance for any mistakes I will make ;)

I would like to bring your attention to some msbuild features: http://msdn.microsoft.com/en-us/library/ms164309.aspx

You have predefined properties, that available for all scripts and projects, it looks like this will help you solve first issue - absolute paths instead of relative. This is small excerpt from the link for further reference

$(MSBuildProjectDirectory) - 
The absolute path of the directory where the project file is located, for example, C:\MyCompany\MyProduct.

$(MSBuildProjectFile) - 
The complete file name of the project file, including the file name extension, for example, 
MyApp.proj.

$(MSBuildProjectExtension)
The file name extension of the project file, including the period, for example, .proj.

$(MSBuildProjectFullPath)
The absolute path and complete file name of the project file, for example, C:\MyCompany\MyProduct\MyApp.proj.

$(MSBuildProjectName)
The file name of the project file without the file name extension, for example, MyApp.

So you should be able to use this defined properties in your Property sheets. Now, with msbuild 4.0 toolset (toolset defined by attribute ToolsVersion="" on the root script element) there is interesting trick Microsoft.Common.Targets define 2 variables to conditionally import custom msbuild script before or after itself CustomBeforeMicrosoftCommonTargets and CustomAfterMicrosoftCommonTargets You can use it the following way ( I think it will possible help you to avoid editing of all proj files or at least - reduce editing to very simplified copy-paste part) Define it using relative path to include your property sheet files

<CustomBeforeMicrosoftCommonTargets>$(MSBuildProjectFile)\ConcreteProjectCustomProperties.propz</CustomBeforeMicrosoftCommonTargets>

Take a note that CustomBeforeMicrosoftCommonTargets should be global scoped property to be inherited by all secondary

And if you properly define your ConcreteProjectCustomProperties.propz I think you could achieve what you need. "Properly" is that you will include there your global properties file (with relative or absolute path) and then define all your project-level properties.

NB: Also take a note that later defined properties not available for reference to early defined Your example defines $(MyIncludeDirs) with reference to $(MyProjectDir), but $(MyProjectDir) declared and defined a bit later. It could be due to "exampling" and fast churning that code, but if you define your vars same way in production - it could lead to subtle error.

I hope I got your problem properly and my explanations will help you to quickly move all your properties from custom add-on to simpler and native msbuild script ;)