Freigeben über

XCOPY the Windows SDK?

  • Artikel

I've heard from a couple of developers lately that want to be able to XCOPY the Windows SDK, the .NET Framework SDK, and all of the tools. These users want the tools used to build their product to be checked into the source repository along with the code, so that the build tools can be versioned with the source.

Users note that more and more products, such as the Windows SDK and the .NET Framework SDK, are moving away from the ability to be xcopy installed. Although apparently the WDK (Windows Driver Kit, previously known as the DDK), supports xcopy install, I haven't tried this myself.

Some developers modify the Windows SDK file SetEnv.cmd file to create their own custom build environment. This file sets the appropriate environment variables for the Windows SDK build environment with respect to OS and platform type. It sets the library, headers and tools paths. It determines which registry keys to look at based on architecture type, to find or set the values for VC and VS root for the compilers, and sets the path for the .NET Framework. Do you use SetEnv.cmd as a template for creating a custom build environment? Shoot me an email; I want to know more about how and why you do that!

This solution works for some, but others want the SDK to support xcopy install. That way, if they have to go back and support an old piece of code, they can just access their source repository through a label, comment or date. If they used the standard SDK with Windows Installer, the developer has to remember exactly which versions of which SDKs were installed on the build machine. It's especially thorny with the .NET Framework SDK because it uses the GAC too, essential for building managed targets.

Another complaint is that custom install locations for the Windows SDK don't behave entirely as expected. Not all components install to the specified custom location. SDK compilers are the same VC++ compiler MSI package that ships with Visual Studio, and behaves in the same way, installing to a Visual Studio Path under Program Files and not to the standard SDK directory. Other 'external' MSIs in the SDK follow suit: the Compact Framework, VC Redist, Document Explorer, etc.

Here are some of the benefits developer Trey Nash believes would come from an XCOPY install for the Windows/.NET Framework SDK. (Read Trey’s post on the MSDN Windows SDK Forum.)

1. The tools used to build the product are checked into the source depot along with the code so that the build tools are labeled/tagged along with the source. It's a concept that makes perfect sense and a concept that is employed with razzle.

2. This is very important for build reproducibility reasons. Any machine can become a build machine by simply installing the SCM client software. In other words, the build machine config is checked into the depot as well. Stepping back in time is trivial.

3. A corollary to point 2 is that each developer's machine matches the build machine config, because the config comes from the depot. A beautiful system indeed. ;-)

4. Without xcopy install of SDKs, 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!

5. Updating the build machine can be done at any location rather than just at the build machine. That's because the build machine's environment comes entirely from the depot.

6. 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. Or a developer could build a .NET 1.1 targeted binary even if the developer's machine only has .NET 3.5 installed via Windows Installer. I'm assuming that there is some sort of SetEnv.cmd sort of thing that sets up the environment variables properly just as razzle does.

7. 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.

8. Getting a new developer (or tester that needs to build the code) up and running on the team involves simply deploying the SCM client to the machine and the rest comes down from the SCM depot. Nothing else is required to be installed first.

What are your thoughts?

Comments

  • Anonymous
    July 06, 2009
    My thoughts? "Yes!" Trey's thoughts are spot on. We reaaaally need to have the build system stored in the source control system. This is how Windows is built, right? Other people have the exact same requirements--Windows is not somehow special in this regard.