where should I install development tools to?

Question

At work we're using NUnit, FxCop and some other tertiary software on our projects. Right now we have the project files for each app stored in the project's repo and the software is installed per developer machine (well... currently only one, me).

We're hiring a couple other developers in a few weeks and I'm trying to set things up to be easier and more transparent.

I read that it's a good idea to install these types of software into the the repo, and copy/paste shortcuts to your desktop to run the gui. This makes it so that it's easy to update to newer versions of the software (install them to your working copy, over top of the old one, and then commit the changes) and it's a cinch to update all of the developers: The next checkout will include the new version of the software.

So I'm wondering...

Does this work as advertised? has anyone tried it?

Also, considering the repository folder structure below, if you've got multiple pieces of software being developed, do you install a copy of, say nunit, in each project's Extras folder, or do you install one and only one in the Repositories' Common folder to be used for all projects? (the latter makes me think that there's a logical and physical disconnect between the project and the tool, but the former means that there could be a whack of different tools because project a is using nunit 2.4.5 and project b is using nunit 2.4.8 etc. - along with all of the other tools/versions)

Repository>Common
Repository>ProjectName>Extras
Repository>ProjectName>Trunk
Repository>ProjectName>Tags
Repository>ProjectName>Experiments

I'm not sure if this last part makes sense... let me know and I'll clarify.

Answer 1

I don't "install" or put 3rd part tools in a respository. They go on a file server but not in the repo.

Typically when I have multiple versions of tools I configure them by setting environment variables in the build process.

Use a dedicated build machine as well to help define your policies and limit the headaches your developers have.

Answer 2

We use a folder (or project) called "Vendor". All of our dependendent libraries that are not developed in-house, as well as any tools go in there. It's at the top level of the source tree.

Answer 3

Our development team is using VMs. So a new team member gets a VM with Visual Studio and SQL Server 2008 Express already installed. These commercial tools where we don't have the chance to modify, are not in our version control system. But we do have versioned documentation of what tools are installed on the VM image.
With the open source tool Fitnesse, being checked into the repository works well. As you say, checking a new version and updating the references allows instant upgraded for the team. But it works well in this case because no tool installation process.
In our case we have our middle ground tools like xUnit, FxCop, ccNet are checked into the project. We are mainly working with one large project, so everything goes into under it.
For a previous employer, we had a Common tools area in the repository. Because of the different projects not all wanting to switch to a new version of a tool at the same time, each version of the tool needed to be checked into its own folder. Making this area of the repository little different than a file share. The repository controlled storage can still be useful. Version control tools allow you to specify "views" to bring down all of the needed project files.