3

So, I want to do this (Visual Studio 2005 and/or 2010, with Microsoft and Intel compilers)

1 - New dev checks out code

2 - dev builds on desktop in unknown location with "default" values

No need for environment settings, no need for configuration, the as-submitted code "just works".

3 - build machine overrides "default" values with build-specific parameters

I thought I had this working with .vsprops. Define things like

<UserMacro Name="SHARED_LIBS_HOME" Value="....\shared" />

On the build server, where it's not in ....\shared, I use an environment variable SHARED_LIBS_HOME set to (say) "G:\Shared" and it will use G:\Shared instead of "....\shared" when running.

But this doesn't work: it looks like (with Visual Studio 2005 at least) if you have a property defined as an environment variable AND as a UserMacro in an included .vsprops, the UserMacro takes priority.

I can see a multitude of websites where one can set a .vsprops to override a .vcproj setting, or set a .vsprops to export values to the environment, but I want to set a .vsprops to set a property only if the environment is not already set.

In MSBUILD this is easy: Microsoft even has it listed as a "best practice" at http://msdn.microsoft.com/en-us/library/ee240983.aspx

Any suggestions?

Dana Lacoste
  • 179
  • 1
  • 7
  • Optional workaround 1: Require devs to set ONE env variable, use that variable in the .vsprops to include a "local" settings .vsprops file (i.e. InheritedPropertySheets="$(LocalSettings).vsprops" where $(LocalSettings) would be set to "default" for most people and default.vsprops would be checked in. For build machine, use a different setting for $(LocalSettings). The problem with this solution is that a new dev MUST set an env variable for LocalSettings. Therefore this isn't a solution, just a workaround. – Dana Lacoste Apr 28 '11 at 21:11
  • Optional workaround 2: On the build side, edit the .vsprops file and change the values accordingly. This works, but it is extremely annoying that the file must be edited every time the build runs! Therefore this is a workaround, but not a solution. – Dana Lacoste Apr 28 '11 at 21:12
  • Optional workaround 3: In the .vsprops, set properties for "DEFAULT_SHARED_LIBS_HOME" rather than "SHARED_LIBS_HOME". In the .vcproj/.csproj, use MSBuild syntax (from the "Best Practice" URL linked) to create a PropertyGroup and define SHARED_LIBS_HOME with a Condition= statement that uses the DEFAULT_ value if the property is not set some other way (i.e. the environment variable). This works, although it is a bit clumsy. My main problem with this is that I have one .vsprops file and about 150 .vcproj or .csproj files: adding an XML stanza into 150 files sounds like a maintenance headache! – Dana Lacoste Apr 28 '11 at 21:15
  • Possible duplicate: http://stackoverflow.com/questions/2002420/optional-environment-variables-with-vcproj-vsprops – Jan Hudec Jul 08 '11 at 10:01
  • 1
    I don't understand the workaround 3. It does not seem possible to use MSBuild syntax in .vcproj files. – Jan Hudec Jul 08 '11 at 10:03

0 Answers0