views:

102

answers:

3

Our automated build machine needs to archive the version numbers of the OS plus various tools used during each build. (In case we ever need to replicate exactly the same build later on, perhaps when the machine is long dead.)

I see the command "msinfo32.exe" can be used to dump a whole load of system version information, which we might as well archive.

Does anyone know of a way to easily archive the version numbers of the Visual Studio tools?

What mechanisms do other developers use to gather this kind of information for archive purposes?


Extra information for Fabio Gomes.

I agree with you that in 5 years time it'll probably be impossible to recreate the exact OS and tool configuration (down to the nearest security update). Unfortunately this really comes from a contractual requirement. As part of our deliverable to a customer we must provide a copy of all source code and clear instructions on exactly how to replicate the build. It's probably impossible for us to meet this requirement perfectly.

So - I'll just mark your answer as correct (I agree with you that it's practically impossible), and get on with playing with the rest of stack overflow. :)

PS. It would be really great if stack overflow supported replies to answers instead of having to edit the original question.. But I see it has already been denied.

A: 

If you are building on the command line you could tell it to be verbose and capture all of the output to a text file to archiving with each build.

eg, msbuild > myfile.txt

BrianLy
A: 

Sorry, but what could lead for a need to replicated the exact same build in the future?

In my experience, either you keep your product installers safe or start a new build from scratch.

Also IMO the only way to replicated the exact same build in the future is to run your build machine on a Virtual Machine and keep the VM backup around.

I think that most softwares you will need to replicate the exact same build in the future will not be available anymore, so you will need to keep a copy of every software versio you install in this machine.

Could you be more specific about the problem you are trying to solve?

Fabio Gomes
A: 

An alternative suggestion: put the relevant tools (compilers, system headers and libraries, etc.) in your repository itself, rather than expecting them to be locally installed. See also a blog post I wrote on this topic.

I have Visual Studio, gcc, etc. all checked into my Subversion repository.