Ahh. Good old Microsoft. I used to be in Microsoft world long time ago, and back then it was a big mess. We had this thing called DLL Hell. Visual Studio comes with it's own dlls that need to be packaged with your applications. When you installed your application, the DLLs would go into the path. The problem is that if you had 2 applications built in Visual studio, they would step on each others toes. This and the lack of dependency management and version control of dependencies caused a lot of confusion. You never knew what DLLs you were dependent on and what version. On top of that, a lot of configuration was stored in the registry, and it was messy to edit the registry. So, to assist in troubleshooting, you would maintain this pristine environment that had all the DLLs that you needed. Whenever your application didn't work, the first thing is that you copy all the DLLs from your pristine env into your target machine. It broke someone else though... but screw em! If copying DLLs didn't solve the problem, you tried tinkering around with the Registry, in which case, you will either fix the problem or nothing else will work. I mean like Windows might stop working. Either restore from backup, or reinstall everything from scratch. Remember this is not your "build" machine, in the sense that this is not where you build your artifacts. This is an environment that you have carefully and lovingly built. It's your baby. You don;t let anyone touch that machine. It's your sweet little delicate flower.
I don;t know how things are with .NET. I think they probably have made some progress
Java, OTH, was built with the notion of classpath from the very begginning. All the depdnencies are packaged into jars. Each Java application has a classpath, and you put all the jars that your application needs into the classpath. Since, each app can have it's own classpath, you solve the DLL hell problem. You just put all the jars that an application needs into it's own folder. You still need to keep the pristine jars somewhere. However, you can just check in all the jars that you need into your source control repo. "installing" an application requires you to only copy the jars from your one place to another. There's nothing else to mess with. This is why you don;t need "pristine" builds. You instead have a "build" machine, which most java developers understand as a machine that is responsible for building your application. You don't keep the build anywhere. You just build it from scratch everytime you want. A much less flaky solution
You still have a verison of DLL Hell that I call Jar Purgatory. You usually end up having a lib folder in your source control that has all the jars that you need. Everytime, you use a new library, you figure out what other libraries it needs, and you copy the jars of all these libraries into the lib folder. The problem is people always add jars, but no one removes jars. Why? Because who is going to risk it? Who knows where the library is being used? So, over time you end up bloating your lib folder. And when you run into a situation where you have to upgrade a jar, you are never sure what other jars you need to upgrade. So, you never upgrade any jar. In 2 years, you dare not go to latest version of hibernate because you don't want to upgrade apache common lang :p
This problem is solved by maven which provides robust dependency management and version control of artifacts. Anyways, no point in going into this in much detail
Michele the way
you should approach this is that you shouldn;t depend on a pristine environment. Instead think about having your build be self contained. Your code should build anywhere. All it should need is sme sort of build tool. The build tool could be plain old JDK or ANT or Maven. Everything else should be checked into the source control. This allows you to put something like Jenkins on your build machine. Jenkins can be setup to check out the source from repo, and run the build script. If you do this, you will be worried less about having a pristine environment, and more about having a pristine release in your source code repo (which is a more manageable problem)