views:

150

answers:

2

I am working in a Visual Studio 2008 solution with multiple C# projects and some C++ projects and want to use post-build events to execute some 3rd party vendor command line tools. These post-build events are needed in several projects.

I can hard code the path names and other files needed on the command line, but I really would prefer something more flexible. Perhaps:

$(ToolsDir)\$(PackageBuilder) $(ThirdPartyDllFolder) $(SharedOutputFolder)

When I developed for UNIX and used makefiles to perform builds, I was able to define a variable in a high level makefile and have it inherited by children makefiles. In this way, I could have all output go to a particular place, or look in a particular place for a library, etc.

Is there an equivalent thing that can be done using Visual Studio solutions, such that I could define something like an environment variable and then reference it in a project level post-build event?

EDIT: I am using Windows environment variables right now, but would prefer something that did not require setup outside of just downloading the code and building it.

+1  A: 

Have you considered environment variables in Windows? I know it's not exactly the same thing, but you could set them with a batch file and execute that batch file post-build.

Scott Anderson
Scott, yes I actually use this method, but am searching for a method where a developer could just download the source code to a clean machine and build it without having to do extra "stuff".
Jeremy
+1  A: 

I had a similar issue a while back. My first "solution" was to create a tool that was built and run when a developer got the first "get" from the repository. It was not pretty and was one additional step - but only once.

I abandoned that and now we have another method. We put third-part tools in an svn repository (a different one than our source) and require a specific hierarchy and name for where that repository lives in relation to the root of our code base. This way we can use relative paths with confidence in our post-build steps or other parts.

I agree that this is a bit of a weakness in the MS build tools.

Tim