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® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
