Freigeben über

DebugDiag - The Saga to RTM, Continued

  • Artikel

For the past several days, I have spent a lot of time mired in the very bureaucracy that I identified in this blog entry... all for one reason - to get DebugDiag and the IIS Diagnostics Toolkit integrated and released.

Yes, the Windows OOB process has bogged things down for about six months, mostly because we had to move all source code from the original source tree into a new arbitrary source tree and successfully build. A lot of other dependencies (like CHM and documentation) had to be identified and resolved, which is quite a bit of work for one MSI.

In particular, DebugDiag presented a formidable challenge since it never started from an NT Build Environment, so it had to be wedged in. I spent a week just getting all parts of DebugDiag to successfully build in an NT Build Environment. Funny... I don't recall getting paid to do any of this, since Windows OOB is supposed to take care of all this (remember, we are paying them to do this release for us). But, I had to jump in to make forward progress because otherwise Windows OOB languished for weeks without making any significant progress. At that pace, we would not be shipping DebugDiag or IIS Diagnostics Toolkit for years, and Chris would not have any hair left. J/K. :-)

Then, there were issues surrounding WiX source files to build the actual IIS Diagnostics Toolkit MSI. Or rather, I produced the original WiX source files that simply worked, and I checked it in, but Windows OOB required some other arbitrary details that made everything more complex and simultaneously non-functional... and I had to step in again to bail things out. Sense a repeating pattern here?

In all, let's just say that there were several points where one could have easily given up and let the red-tape win. And despite the fact that Windows OOB was paid to do this release, I definitely did way too much of their job... but Chris and I weren't thrilled with letting the red-tape win, so we had to push it through.

And the ironic thing is that the Windows OOB folks feel that we left them with a real mess that they had to spend lots of time to "fix". Now, if I had no history, I would probably agree with them... except for the fact that we've already successfully built and released the DebugDiag and IIS Diagnostic Toolkit MSIs. So, it is not as if we had non-functional source code; the problem is that Windows OOB cannot make it functional. I find it hard to believe that we are at fault when they are the ones being paid to make the release work... and we've already shown that the release works. Yup, it's because we need to get that darn "check-box".

Anyhow, I can finally see the light at the end of the tunnel... hopefully it isn't an oncoming train. So, don't ever say that I haven't taken one for the team... because I probably took several shots here. ;-)

IIS Diagnostics Toolkit and DebugDiag should be released shortly. Please consider it a Christmas Present from the IIS team. I know I will enjoy announcing its release. :-)

Enjoy.

//David

Comments

  • Anonymous
    December 14, 2005
    I, for one, welcome you efforts.

    Management might be reluctant to put beta software on the working webservers as a matter of policy. But 'offical' released will be better received.
  • Anonymous
    December 14, 2005
    If you care to comment, I'd be interested to know more about the "NT Build Environment" you refer to, and how this environment differs from DebugDiag's original build environment.

    Also, in general how was your experience working with WiX?
  • Anonymous
    December 19, 2005
    gosaca - You can view VS.Net as a development platform which defines one set of procedures to use all of the freely available platform tools, and the NT Build Environment is another way to use the same tools.

    The NT Build Environment is basically an extension of the same tools and resource files documented at:
    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ddtools/hh/ddtools/TOC_Build_012b8fad-adb9-4324-bae0-71b90cfbaeca.xml.asp

    It uses the same compilers, linkers, include, and library files as released by Visual Studio and the Microsoft Platform SDK:
    http://www.microsoft.com/downloads/details.aspx?FamilyId=A55B6B43-E24F-4EA3-A93E-40C0EC4F68E5&displaylang=en

    Except it is a bit more customized since we are literally building the platform we compile against -- so we need to be able to pick out versions of files, pre-compile the compiler to compile the daily builds, pre-build the libraries/include files we link against, etc -- whereas end-user just gets everything nicely packaged and versioned.

    DebugDiag is a VC++ 6.0 project that got upgraded to VS.Net - so it followed procedures of VS.Net and thus had no relation to NT Build Environment procedures. But to release it, it had to follow NT Build Environment procedures (yet another random rule...).

    I use WiX all the time to build MSIs. I have already templated and wrapped WiX tools such that I can quickly roll out a typical MSI installer within seconds - all you need to give me is a directory structure and list of files... so for me to build an installer for DebugDiag is trivial. I built all of the installers for recent IIS tools like IIS Diagnostics Toolkit, SSLDiag, AuthDiag, etc.

    So of course, my frustration here is that in order to release DebugDiag, I have to explain to someone else with no clue of DebugDiag and little about WiX and NT Build Environment so that they can recreate it (no, they can't just use what I already completed). Then, they can hit "build" on my behalf because they are authorized to build the "official" DebugDiag and release it. If I was "authorized" to build and release DebugDiag, this would be done months ago...

    //David