Sounds to me like what you really want is to put vms in .. then have the builds run in those vms.
What about things like OS differences? Cheers, Greg On Wed, Apr 2, 2008 at 10:33 AM, Trey Nash <[EMAIL PROTECTED]> wrote: > Hi all, > > I saw Simon's question asking about the existence of a .NET Framework msi, > and I could not help but share one of my pet peeve's regarding the direction > Microsoft is going with their SDKs and tools. > > I have the need to be able to xcopy install the Windows SDK, the .NET SDK, > and all of their tools. Why? For the same reason many other shops, > including Microsoft, follow this practice. > > However, it seems more and more that things such as the Windows SDK and the > .NET SDK are moving away from the ability to be xcopy installed. For the > Windows SDK, I suppose I could attempt to hack up SetEnv.cmd, etc. > > I do know that the .NET Framework SDK can actually be xcopy installed. > There are some undocumented environment variables that one can define that > allow one to do such things as setup a GAC at any old place. > > Consider the benefits of xcopy SDK install: > > - The tools used to build the product are checked into the source depot > along with the code so that the build tools are versioned along with the > source. It's a concept that makes perfect sense and a concept that > Microsoft themselves follow with their internal build systems. > > - This is very important for build reproducibility reasons. Any machine > can become a build machine by simply installing the source depot client > software, whether that's perforce, svn, etc. In other words, the build > machine config is checked into the depot as well. > > - A corollary to the point above is that each developer's machine matches > the build machine config since the config comes from the depot. A beautiful > system indeed. ;-) > > - If one need's to step back in time, instead of just being able to suck > code from the depot based on some label or date, one has to remember exactly > which versions of which SDKs were installed on the build machine. And if > enough time has passed, one has to worry about whether one can even find > them easily if at all! > > - Updating the build machine can be done at any location rather than at the > build machine. That's because the build machine's environment comes > entirely from the depot. > > - The build environment is "sandboxed" into a subdirectory that is built > from the contents of the source depot. Therefore, the configuration outside > of the "sandbox" is irrelevant. For example, it does not matter what > version of the same SDKs a developer may have on their machine if at all. > All that matters is what is in the sandbox. In this scenario, a developer > would be able to build a .NET 3.5 targeted binary without ever having > installed the .NET 3.5 runtime or the .NET 3.5 SDK. > > - Build automation becomes much simpler because any tool used for the > purposes of automation can be placed into the depot and versioned along with > everything else (assuming it can be xcopy installed). > > Now, **technically**, I suppose one **could** push the msi/installer > packages for these SDKs into the depot and then potentially have a checked > in script such that the build machine sucks them down and installs them > prior to building and then uninstalls them when done. Ouch! :-) > > Look, Microsoft does this internally for many of the same reasons. It's > just good practice. You can find traces of this in the build environment in > the WDK. That's because the WDK build environment and the WDK build > mechanism is essentially the same environment the OS is built with. And > that same build environment can build managed targets by using a .NET SDK > environment that was sucked out of the source depot (that is, xcopy > installed) rather than Windows Installer installed. They (Microsoft) should > recognize that developers other than themselves would want to do the same > thing for the same beneficial reasons. I wish they would document the > already existing mechanism that would allow one to xcopy the SDKs and tools. > > FWIW, one can do this if one is building a purely native app using the > compilers in the SDK or WDK. The WDK is xcopy installable. The Platform > SDK was, for the most part, xcopy installable. > > Any suggestions, comments, or ideas on this matter? I've tried picking apart > the makefiles in the WDK build environment to find out how they do it, but > have not had much time to dig deeper and be successful at it. > > Thanks, > > -Trey > > ----------------------------------------- > Author of "Accelerated C# 2008" and "Accelerated C# 2005" > http://www.amazon.com/Accelerated-C-2008-Trey-Nash/dp/1590598733 > > =================================== > This list is hosted by DevelopMentor(R) http://www.develop.com > > View archives and manage your subscription(s) at http://discuss.develop.com > -- Studying for the Turing test =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
