views:

43

answers:

2

I have an exe that runs as part of the post-build for my project. Currently it is just sitting in the projet's bin directory.

Now that I want to use the same post-build action for all projects, where should I place it? Is there a common location already set up for this? Would I just stick it in a well known path an hard code it?

One option I'm thinking about is placing it in "$(DevEnvDir)\MyUtils".

+1  A: 

That would work (as would anywhere on your PATH and you wouldn't have to prefix it with anything). However, if it's only used in one solution and the solution is in source control, I'd recommend putting it in the solution directory and checking the utility into source control as well, so anyone else checking out the project can just check it out and click build.

Robert Fraser
Alas, it would span multiple solutions. And I suspect they wouldn't all necessarily even have the same source control provider.
Jonathan Allen
I agree with Richard here -- have copies in each solution. New developers on the project will appreciate it, and versioning of the tools is no longer an issue.
Robert Fraser
+1  A: 

I generally use the following folder structure (all of which is in the trunk of the source tree):

/source - contains solution file and project directories

/lib - dll references

/tools - exe's

/build - ccnet / nant build scripts

/deployment - any deployment powershell scripts

That way, you can reference your tools via solution directory + "..\tools\toolname.exe"

Richard Szalay
It would be used by multiple solutions, so that may prove difficult to maintain.
Jonathan Allen
Within trunk I actually have an applications directory, with each directory having the strcture I mentioned in my post. You could easily have a tools directory alongside applications if you wanted. However, I actually prefer to keep the tools duplicated for each solution (that has it's own build) as it reduces versioning hassles.
Richard Szalay
FYI, I am currently using this configuration in a project with 4 different solutions, each with separated builds with some interdependencies and it even includes an automated Flex build/unit tests. I've had no difficulty with maintenance.
Richard Szalay