Monthly Archives: April 2007

TFS Build Automation Part 1 – Introduction

I’ve been using Visual Studio Team Foundation for the past 6 months now. I’ve banged my head against the wall ( a lot actually ) but I’m finally getting to a point where I feel that I’m in charge of it instead of the other way around. One thing that I really like about TFS is the Team Build product. Team Build is an agent that you install on your build box. It gives you the ability to kick off builds remotely.

For example, I’m able to open up VS2005 Team Explorer and go to Team Builds. I’m then shown a list of known build types in which I can bring up all kinds of information about previous builds and/or kick off a new build. Once I tell TFS to initiate a build of a build type, it sends the job over to Team Build and the process runs from there. All of this occurs without me needing to logon to the actual build machine. I don’t know about you, but I think this rocks.

So what is a team build type? In TFS Source Control there is a special root level project called TeamBuildTypes. Each sub project represents a build type. TFS Build Types are pretty much solution centric. It’s MSBuild based so really you could do whatever you want, but if you want to conform to the pattern think solutions.

The TeamBuildType consists of three files:

TFSBuild.proj — An MSBuild project file that contains the built-in logic to use TFS to build a .NET solution.

TFSBuild.rsp — a response file used to pass properties to MSBuild when firing up the build.

WorkspaceMappings.xml — A simple XML file that maps your project area in TFS Source Control to your project directory on the build machine. This makes tasks such as keeping track of what changesets went into a build, labeling the files and getting them for compiling a piece of cake!

So after you install all the pieces of TFS and check a VS2005 .NET solution into source control, you can run the wizard and create your first TeamBuildType. With a couple more clicks you’ll have TeamBuild building your first build.

Mastering (Distributed) Windows Installer Development Obstacles

I don’t mean for this to be a rant, but more an invitation to discuss what I see as three fundamental problems that face Windows Installer developers:

  • The path to mastering Windows Installer to get packages to do exactly what you want them to do is not defined very well.
  • Getting all of the other developers on your project to care enough about Setup to convince them to go down that path is next to impossible.
  • There is really no good ways of assessing and recognizing developer’s efforts in this achieving the above goals.

Below, I’m going to make references to the `Fundamentals` rules 1, 2 and 5 detailed on the Windows Installer Team Blog at

http://blogs.msdn.com/windows_installer_team/archive/2006/05/01/587990.aspx

Rule 1: Learn the Windows Installer Technology
Rule 2: Know Your Way Around the Installer SDK
Rule 5: Build Setup Into Your Application Development from the Start

On the surface I agree with these goals that these `rules` describe. However, I think the problems are oversimplified and anyone claiming to have easily solved them and created a finely tuned distributed setup developing team capable of deploying properly behaving MSI packages is selling you a bill of goods. There is one such particular company that comes to mind that loves to boast this claim, but I’m not here to name names.


First rule #1 states that frequently people author bad packages using GUI based editing tools and that you must first master Windows Installer BEFORE you author packages. I agree! There are a lot of bad packages out there that have been authored by part-time Setup Developers who haven’t bothered to master the Windows Installer API.

However, Windows Installer is just simply WAY too complicated of an API to assume that you can `master` it before you even start authoring packages. This is like saying you must master the Microsoft.NET framework before you can write a C# program. Mastering a technology comes from iteratively gaining knowledge and experience, often at the expense of making mistakes along the way.

I’ll agree that blindly using an Industrial Strength Household Name MSI Editing Tool (ISHNMET or InstallShield if you can’t read between the lines) and completely disregarding the underlying API is a bad thing, but what’s the alternative here provided by the Windows Installer team? Using ORCA and home built scripts to call the API and create packages?
Rule #2 says the best way to learn Windows Installer is the Windows Installer SDK. It then goes on to say that the SDK is not meant to be read front to back. Combine that with the thinking that `ISHNMET too high level and therefore bad` and WOW, can you say Up The River Without A Paddle? Let me get back to this though…

Rule #5 says that developers should treat Setup as first class development tasks and contribute to the installer source. I completely agree, but according to Rule #1, they can’t do so until they `master` MSI. Let’s get back to the Up The River Without a Paddle problem. If it’s so difficult for one person who actually CARES enough about Setup to attempt to master MSI, how do you expect dozens of developers who DON’T care about Setup to master MSI? Furthermore, how do we expect them to design integration points into their application that take setup into consideration? Also, how do we expect them to try to learn all this when we say the pretty GUI tool that will help them is `evil` and that they really need to dig deep into the SDK and master MSI before they actually start authoring packages?

Seriously, you might be able to get a group of developers quickly trained how to drag a file into a VDPROJ GUI, but if you expect them to master the various patterns in Windows Installer, you are really in for a long struggle, especially if the SDK documentation is your best resource. The first time a developer wants to remove a file from the package and expect it to disappear he’ll just go into VDPROJ and delete the reference. He won’t care about such concepts as minor upgrades and transitive components. Another scenario is the first time he needs to install a service; the developer will dig into Installer Class custom actions to get the job done. He’s not going to care about why it’s better to use the ServiceInstall table. He’s certainly not going to care enough to try to write an unmanaged post build process using the Windows Installer API to hack and slash the package. Regardless the end result is another package will be deployed that simply fails to measure up because the developer assumed setup was `easy`.

What I’m really trying to say here is I basically agree with the goals of these best practice rules, but I feel that we are a very long way from being able to solve them. IMHO, authoring tools like WiX and InstallShield are both good in that they try to steer the developer into complying with the intricate patterns of MSI. (Assuming you can get two MSI developers to agree on the definition of compliance.) InstallShield attempts to steer you by abstracting you from the table data with point and click work flows and WiX attempts to do it by abstracting you from the table data with a `safer` schema and a compiler which is pedantic enough to not `let` you author bad table data.

I do agree that authoring tools shouldn’t serve as a replacement for understanding the underlying Windows Installer service, but they are critical in accelerating the learning and development curve and shouldn’t be looked at as the problem. (I know, you might be saying that WiX isn’t the problem, only ISHNMET is the problem…. B.S.) From the Windows Installer team, what’s the alternative solution? ORCA and the SDK documentation? If so, ugghhh……

Once you are ready to go from ISHNMET 101 to MSI 201 to MSI 301 (and that should be the goal of everyone contributing to a package) then there are very few resources to assist you. The SDK is a bear to read and understand (until about the 20th time you have read it along with blog articles to point things out). There are very few books on the subject. Most material is very informal (such as community forums and blog articles). There is very little training available and absolutely no certification tracks available. If you look at typical C# classes that cover setup (ancillary at best, if they cover it at all ) they might devote a couple paragraphs to VDPROJ or make such over simplified statements as `.NET is XCopy Deployment`. After all the author of the book most likely hasn’t mastered MSI, doesn’t really care about Setup and is merely trying to say that his book `covers` deployment issues.

Finally there is the matter of attempting to assess your progress on the path of mastering MSI. This has been on my mind for awhile but I’ve hesitated to blog about it. While we are all expected to master MSI, there really is no way to officially demonstrate our comprehension. There is no MCP test or track for MSI. There is no such beast as `Microsoft Certified Setup Developer`. There is no .NET elective in the MCSD track along the lines of `Designing Applications for Deployment` or `Mastering Distributed Setup Development using Windows Installer based tools`.

The only chance we have to be officially recognized as an MSI expert is to gain the MS MSI MVP award. The MVP program really isn’t geared for that in the first place. The MVP title is only supposed to show an awardees community involvement in assisting Microsoft users. Either way, Microsoft doesn’t really seem to be confirming new MSI MVP’s anymore. After all, you can’t go around having 100 MVP’s for such a small specialty as Windows Installer. Especially considering that few people outside of the setup community realize the importance of setup and MSI in the first place.

Now if you are an MVP please don’t be offended by my next statement…. I don’t mean it to apply specifically to you:

Some MVP’s seem to have been awarded their status for posting in a newsgroup that they have rolled their own way pattern to accomplish something that could be simply done in a tool like ISHNMET using the Click, Click, Click pattern. An example would be coming up with a way of writing some VBScript to use the Windows Installer automation interface to modify some table data because an upstream tool like VDPROJ isn’t mature enough to handle it for you.

Other potential MVP’s who choose to go the ISHNMET route are ignored for MVP consideration because either they must not really understand MSI if they are using ISHNMET (tool bias at its worst). Since when should you have to redesign the wheel to prove you understand that the wheel is round? Finally some people who should be MVP candidates are ignored because their thousands of thousands of contributions are in the `wrong` place. When someone helps an ISHNMET user the thinking seems to be that they haven’t assisted a Microsoft user. Unfortunately that line of thinking assumes that ISHNMET users aren’t really Microsoft Windows Installer users. MSI Rule #1 quickly reminds us that this is simply not true.

I’m really interested in your comments on this subject because frankly, if you made it this far down the article you must really a lot about Setup.