How do I stop VS2K10 from caching environment variables

I'm in the middle of writing a C++ extension to a computer game using a t开发者_Python百科hird-party library. Since each person who develops against this system may have the header files in different directories, it uses environment variables in its project file to point to where those header files are located.

Occasionally, new versions of the libraries are released, and I tend to keep the new and old versions around in case I need to compile against the old version.

Changing the environment variable to point to the new version's location worked perfectly in Visual Studio 2008.

Changing the environment variable to point to the new version's location is a massive failure in Visual Studio 2010.

I've tried all of the following:

1. Using setx to change the environment variable in a cmd shell.
2. Rebooting the computer
3. Rescanning the Solution
4. Unloading and reloading the project.
5. Recreating the project and solution files.

None of these has worked.

Is there some way to prevent VS2K10 from caching environment variables?

Visual studio loads environment variables when it starts up as far I know but I haven't used environment variables since VS2003. Usually restarting visual studio is enough to pick up the new environment variables. If that's not the case then it's yet another argument to not use environment variables for project configuration.

Alternative #1: Use property sheets

Since you're in Visual Studio land you can use a property sheet or a series of property sheets to inherit project settings that can be distributed to each developer which can be used to define settings for different builds, architectures, and common include paths, etc. Doing this usually means standardizing a development environment based on the source control tree. While they may update or pull down source and libraries to different locations locally the relative paths should be the same as the property sheets which are usually based off source control.

Alternative #2: Using a dedicated build machine.

One machine is setup to perform your various builds and possibly running smoke tests and other automated unit tests. This allows developers to specify there environments, solutions, and projects however they please provided that they only check in source files. Should the source they check in not be compatible with the build machine environment it should be capable of sending an email with attached output where it will be easy enough to use the blame feature of your source control for someone who incorrectly added a dependency or whatever the case may be. It's common to schedule nightly builds in this kind of environment to catch newly introduced mistakes before they become buried in further changes.

That said I've used environment variables for including particular versions of boost and other libraries in the past and it worked out alright because I was the only developer using C++ in that office and there was only one development machine needing the environment. When you have multiple people modifying multiple things you really need to come up with some kind of uniform way of laying out your source, libs, and output.

It turns out this may have been something with the way that Visual Studio or Windows was configured on that computer. My laptop's Visual Studio 2010 install does not exhibit this same problem.

This machine had a critical existence failure late last week, and I'll see if its replacement has the same problem after I install VS2010 on it.

I don't know how to prevent it, but the cache seems to be stored in the solution's .suo file. Deleting this file removed the cached environment values when I encountered the same problem. The .suo file seems to be re-created when the project is reopened.

Come to think of it, I deleted the vcproj.user file at the same time. Better nuke both to be sure. :)

Hope this helps.