Another Trying Day

Sadly, this has become an all too common occurrence.... I have to ask for your prayers again. Tomorrow my wife will be having yet another surgery as part of her war against cancer. This time the goal is to remove a tumor from her right lung. We won't know which procedure the Doctor will ultimately choose until he's had a first hand examination, but right now it looks like she'll be in the hospital for 3-5 days and possibly as many as seven.

So please forgive me as go offline for a few days. Perhaps Aaron will say a few words in my absence. Maybe something like "VBScript CA's Don't Suck, CANCER SUCKS".

Development Tools Diversity

I'm curious as to the ecosystem diversity of my readers so please take the new poll over on the right.

I'm interested in truthfulness here please! You may select as many as you like, but I ask that each one you select be truely represented as a tool you use to ship a production install. If you've only played with a tool but don't otherwise ship product with it, please don't select it.

Mailbag: Adventures In Server 2008 Logo Certification

A recent blog article about Server 2008 Logo Requirements generated some interesting feedback from Colby. I asked him if he minded if I reposted it here and he approved so here goes:

Chris,
I'm not really responding to any of your comments directly. I'm just throwing stuff out there as someone who is currently going through the Windows Server 2008 Logo Certification for my product.

Most of the problems I've had to date actually come from the application code side rather than from the install/MSI package. For example, all binaries (executable files, activeX controls, dynamic link libraries, etc.) must be digitally signed as well as have the appropriate requestedPrivileges attribute set in a manifest (either embedded or external manifest). This can be quite annoying if you have a lot of legacy applications to distribute. We actually have legacy binaries compiled using Borland, Delphi, and a couple of other non-Microsoft compilers and those binaries don't accept a digital signature. Other issues relate to kernel mode drivers not being properly authored to meet Microsoft standards (all drivers installed by a logo certified application must be signed by Windows Hardware Quality Labs [WHQL], pass all WHQL tests, and pass all driver tests in the certification tests). That requirement can also be a problem for companies that compile their services to run on different platforms (in my experience, those are the ones most likely to ignore the Windows standards - whether intentionally or not). These have been my two biggest problems so far. The installation requirements for certification (Chapter 2 of the Windows Server 2008 Logo Certification Framework document, see link below) are pretty easy to follow if you're using MSI [and I agree w/ you that Robert can't be blamed for not knowing that MSI was dropped as a requirement - the latest framework document was just released on 1/8/08!, which is another annoying part of this process: MS keeps changing the rules before 2K8 even ships!). Evidently, we're not the only ones having these problems (as Application Compatibility for Windows Vista forum shows [RSS=http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=904&SiteID=1]). In fact, our VeriTest contact has mentioned that a only a very low number of applications have actually been certified thus far.

If anyone is considering Windows Server 2008 Certification, I HIGHLY recommend installing the Certification Tool and using it to do all your Vendor testing. It is the exact tool that VeriTest will use to run the tests and is quite easy to use. In fact, I created a VM for our employees to use that has everything installed for testing and includes recommendations for how to set up the Certification Tool (requires a SQL database to connect to). A copy of the readme is below and shows all the applications and tools necessary to run the certification tests. Most people start by downloading the Microsoft Certified for Windows Server 2008 Application Test Framework document (http://microsoft.mrmpslc.com/InnovateOnWindowsServer/redirect.aspx?u=http://download.microsoft.com/download/7/9/5/7959e7ea-f788-41cb-8b57-67bd122eb9b4/WindowsServer2008SoftwareLogoTestFramework.doc) and struggling through it (currently 230 pages). But if you just download the Word doc and then install the Certification Tool, the tool will pull in all the requirements from the document and is a MUCH easier way to start the in-house Vendor testing required prior to certification submission.

Basically, anyone doing this should START HERE:
http://microsoft.mrmpslc.com/InnovateOnWindowsServer/Resources.aspx

I hope this helps your readers who may be looking for Windows Certification!!

How do I add the elevation shield to my Vista install?

I have had people ask me this question a couple of times, and I figured I would post a quick note on how to do this. You could start by looking at the SDK article devoted to the PushButton control. You will notice that the PushButton control has an ElevationShield attribute.

By setting this flag in the PushButton control's attributes, it will cause the elevation shield to display on Windows Vista systems. Generally, your install will have a "Ready to Install" dialog with a Next or Start button on it. This is a good place to have the elevation shield. You would set the attributes flag as such:
1 - Visible
2 - Enabled
8388608 - ElevationShield

The total for the attributes column would be 8388611. Most of the recent versions of the commercial setup products will set this attribute for you with a simple checkbox producing a dialog similar to the following on Windows Vista:

Vista Server Logo Requirements Revisited

Recently I was watching a video on Channel 9 called Application Compatibility - MSI Installer ( re: Vista / Server 2008 ) where Robert Flaming of the Windows Installer team made a brief opening comment that the windows server logo has a requirement for MSI for the first time.

Now I'm sure Robert didn't think this opening remark would attract so much attention because it really isn't the focus of the video. Still it jumped out at me since back in September I blogged about a friend sent me an email detailing that MSI was dropped as a requirement for the Vista Server Logo program. I was really curious to find out if Robert had simply misspoken or if my information was wrong our out dated.

Recently Robert communicated via the Windows Installer team blog:

In recent multi-blog conversations between Windows Installer experts Aaron Stebner, Christopher Painter, and Stefan Krueger, it was noted that my statement that 'Windows Server 2008 logo would require Windows Installer' in the Channel 9 video Application Compatibility - MSI Installer Issues was out of sync with the published requirements.

Sure enough, the Windows Server 2008 Logo team demoted this from a requirement to a recommendation. Unfortunately the Windows Server 2008 Logo didn't let me know they had decided to do this.

Robert also went on to accept responsibility but I feel this is completely unneeded as it isn't his fault that a requirements change wasn't communicated back to him. Regardless, the question is now answered and I'm very grateful to Robert for doing so. More importantly though he gives very good perspective into the `why` so I highly encourage you to read the blog.



I only have two additional comments related to the `why`. First is I've seen many times in my career that developers/managers grasping at straws to put together a installation requirements or design document together will reference the logo requirement by proxy. From Roberts comments the logo program is a marketing program not a standard program so this association may be incorrect. Still it's sometimes difficult to put installation requirements to paper so I doubt that this practice will end.


The second comment is somewhat a question: For those of you in IT organizations, what attitudes do you see towards server care and feeding versus workstation care and feeding?

The reality is, from perspectives, a server is just a glorified workstation. You would think that MSI would automatically be good for both. In my current role at an ISV I have adopted MSI for my server installs as well as my client installs.

However, I remember at Continental Airlines that many people were very skeptical of automating server side deployment. Sure there were a few visionaries like the Sr. Director of Technology that I worked for who wanted to be able to use a graphical designer tool to cause the provisioning and configuration of a brand new blade through tools like ADS, DSI, GPO, AD, SMS and MSI. But many people who otherwise adjusted well to client side automation would get very defensive when you started talking about changing server side processes. If you suggested replacing an old, incomplete, outdated manual process with a zero touch automated process they would be practically afraid to death of the change. If you suggested using GPO, SMS or WSUS to manage these servers they would freak! I don't know if it was inexperience or just protectionism, but the moment you started mentioning production servers everything had to be done by hand.

So perhaps the server community isn't really ready for MSI yet anyways. What does your experience tell you?

A New(er) Look

I was looking at my profile the other day and I realized that my pictures were really old and somewhat misrepresenting of my appearance. I've never really spoken about this online... last summer I shaved off all of my hair.

This is the second time I've done this in my life. The first time was at a little place called Marine Corps Recruit Depot Parris Island. The second time was when I found out that my wife's cancer had returned. When she was first diagnosed we were told that the drugs she would be taking would not cause hair loss. However, the second time around was a different story. There was just no way I'd let her lose her hair all alone so off it came. I only wish that baldness actually bothered me so that it would be more of a sacrifice.

CAPICOM ... UGH!

I'm working on an install that requires me to write some custom actions to interact with the certificate stores. I seems there are four different ways to do it out there:

certmgr.exe : The way the developer suggests doing it. Of course it's a .NET SDK utility with redist rights.
cryptoAPI : Win32 API
CAPICOM : Scriptable COM
System.Security.Cryptography.X509Certificates : .NET Framework

After a whole lot of digging I decided ( for now ) to settle on CAPICOM. I found the CAPICOM SDK and example VBScript file that shows how to load a certificate into the store. I quickly ported that over to InstallScript and bingo, it all worked.

Of course there is a catch. This has added a dependency to CAPICOM.dll to my install. This wouldn't be so horrible except the Microsoft team that created CAPICOM obviously doesn't have the first frigging clue about how Windows Installer works. They seem to think that xcopy to system32 regsvr32 is the appropriate way to deploy this ActiveX control. There are tons of references that say CAPICOM is redistributable but the only MSI available is for the entire SDK. There is no merge module or prereq package containing just the ActiveX runtime control.

So I do some googling and I find an old thread from WiX-Users with a good discussion on the component rules and why this is a problem. Finally I stumbled across a Windows Installer log file that indicates Visual Studio C# Express deploys the file to C:\ProgramFiles\CommonFiles\Microsoft Shared\CAPICOM as ComponetID {9504EA7B-206D-4178-8E37-EF70AE544903},.

Ugh, Can we say DLL HELL?!?!?

Well I suppose since the application I'm deploying targets .NET 3.5 that I could just go ahead and use the x509Store class that's in the .NET BCL but 1) I haven't tested that yet and 2) Microsoft employees keep trying to convince me that managed code custom actions are evil while at the same time they compain that other infrastructure API's don't target the CLR. ( Yes, notice even Rob Mensching joining in wishing that Windows Error Reporting supported .NET! )

Finally I found a Code Guru project using CryptoAPI writtten in C++. I tried running the sample exe but wouldn't you know it.... it was a debug EXE with a dependency on MFC42D.dll.

The cryptoAPI example is probably the purist way to go in terms of eliminating the dependency but jeesh, it shouldn't have to be this hard. What's 3 lines of script becomes pages of C++.

I once mentioned capicom in a previous post and now I know why I get so many hits for it on my statcounter.

Someone please slap me and remind me that I actually LIKE setup!

Good, Bad or just Different?

Aaron Stenber has a rather interesting article discussing a novel approach used to author recent Microsoft packages such as Silverlight 1.0 and the .NET Framework 2.0SP1/3.0SP1.

Basically these setups are authored as fake MSI's that then get Major Upgrades applied as patches. The UI is outsourced to an external UI handler and the whole thing is packaged up into a custom self-extracting bootstrapper.

I have to admit, when I first read the article my first reaction was something along the lines of `What the heck???`. The design is so different to other servicing stories that I've seen that I had to email a trusted friend of mine for his reaction. His answer to me was:

I don't think you're missing anything. My initial reaction is a mix of "wow, what a hack" and "does this mean they admit MSI's model is too limited?" The empty MSI + patch is cute, because it gets around InstallShield's lingering cache-web-download file problem, but it just highlights that MSI should have had better options for caching the original MSI rather than wasting one of your patches as a workaround. A custom bootstrapper, custom external UI code, etc., are the only way to make installs like this bearable.

I want to be honest, I'm trying to keep a very open mind with this design. I am somewhat saddened that it has come down to this. I sometimes find myself wishing that merge modules and concurrent installs worked. It would be so nice if you really could isolate and package all of your third party dependencies into a nice, clean, single MSI package that could be loaded into a GPO advertisement. It would also be nice if GPO could understand how to apply transforms and/or set public properties. It would be nice not to have chainers and external UI handlers and to not have to decide how our servicing strategy would be in advance.

A Look at the Windows Installer Tao Part 4 shows:

Rule 41: Design and Test Your Servicing Strategy Before You Ship the Initial Product

Rule 42: Author Packages to Avoid Source Requirements During Patching

I guess in a sense this latest design is the ultimate expression of these two rules. For example the .NET 2.0SP1 performs a Major Upgrade of the 2.0 RTM and in effect calls a mulligan. For clean installs it basically accomplishes the initial deployment by using the expected servicing strategy thereby eliminating the potential pitfall of being in production before you figure out what your strategy will be. Furthormore by not deploying components in the base MSI you avoid running afoul of rule 42.

Still, a part of me is still scratching my head thinking "Wow, is this really how MSI is meant to be?". After all, these packages look and feel to a Systems Administrator a lot more like legacy setup.exe packages then MSI packages. For example the Microsoft Silverlight Deployment Guide makes no mention of GPO advertisements using MSI. Instead they mention wiring a batch file up to a machine starup script to fire the exe from a UNC path.

I sure would love to see a follow up discussion from various parties including the Windows Installer team. Is this just an ad-hoc approach used by certain teams from within the Microsoft firewall or is this the future best practices that tools like ISHNMET should be supporting?

PatchWiz Kaboom!

Recently I was reading a thread in microsoft.public.platformsdk.msi where Jim Keir stumbled into a whopper of an MSI bug:

I've found a huge, steaming bug in PatchWiz 4.0.6000 . Under some circumstances, sadly those described in the SDK patching example, it can erase all writeable files on your drive.

To reproduce (carefully):
- Provide suitable PCP and source/target folders
- Call UiCreatePatchPackage with the optional hWnd parameter set to NULL and RemoveTempFolderIfPresent set to FALSE. Harmless, right?


Internally (I've debugged this) the ascii version convert the strings to wide-char and then pass them to UiCreatePatchPackageW . This unconditionally sets 0x8000 in the flags field, then it passes it all to UiCreatePatchPackageExW . That bombs because the UIALL flag (0x8000) is set and the window parameter is null. The error-handling then kicks in but it appears that some internal defaults haven't yet been overwritten. It tries to delete the temp folder despite being told not to both in the function call *and* the PCP, and also hasn't yet set the temp folder location. It seems that another internal call fails (code 87) with the result that it deletes
every writable file on the drive.


The corresponding logfile line is:
ERROR: During cleanup, could not delete the temporary folder: .


Rather annoyed. As you might imagine. Don't believe me? Go ahead and try it ;)

Furthor posts seem to confirm that this bug is real. Fortunatly I still develop on Windows XP with InstallShield 2008 so fortunatly I'm still on PatchWiz.dll3.1.4000.2049.

Still, something to watch out for, especially if you are tools developer or roll you own kind of guy.

Fighting Windows Installer

The other day a simple question was asked on the WiX-Users mailing list:

...I would like to Create a “major” upgrade installer, even when only the
fourth field of the Product Version has changed.

To which Windows Installer defender and Microsoft employee Bob Arnson proclaimed:

"Doctor, it hurts when I do this." You know the rest. It might be possible
to make it work but you're fighting Windows Installer, which doesn't support the
fourth field in a product version for upgrades.

Well considering the number of doctors that I've been to in the last year I know how I'd respond to that one. Time for a second opinion!

Sometimes working with Windows Installer is all about fighting Windows Installer. Don't believe me? Check out the LockPermissions table for starters.

For some reason Microsoft decided that when following an a.b.c.d versioning pattern that a change of d just doesn't qualify as a major upgrade. Why? It's just a version number for heavens sake. That business logic is entirely too coupled. The decision to go with a major upgrade should be driven by the change in components and feature structure and servicing experience desired not by the version. If a minor upgrade won't do the trick and SCM/Program Management says you are going from 1.0.100.0 to 1.0.100.1 well that's that. You need a Major Upgrade.

As an aside, I never agreed with the definition of a Small Update. A Small Update is basically a Minor Upgrade ( change of PackageCode but not ProductCode ) with the exception the ProductVersion does not change. What?? The SCM practices of everywhere I've ever worked would never allow that. Once 1.0.100.0 is fielded it's immutable. You must increment the version to show uniqueness. The only reason I can think of doing this is when you are trying to sneak a fast one under the radar.

Anyways, back to the question at hand: This is actually pretty easy to do. You just have to understand how FindRelatedProducts and RemoveExistingProducts work together. The former reads the upgrade table to know which products are to be searched for and which ActionProperty to put the data in. The later reads the table to know which property to expect to find the data in. The real work is performed by RemoveExistingProducts. A Type 51 custom a CA scheduled between the two would easily allow you to bend the business rules implemented but not exposed by FindRelatedProducts.

BTW, stay tuned to a future blog post where I point out how the .NET Framework install is a complete hack ( sorry, clever WiX based solution invented by Microsoft employees who should be worshipped ) that works against Windows Installer .

Seriously, what else could you call an empty MSI that is then patched with a full MSP and serviced by a bootstrapper and external UI handler just to get around the nasty database caching story that Windows Installer has. You know the one that strips out cabs and invalidates digital certificates causing annoying dialogs like "Please Insert The Stupid Media" and "Unkown Publisher".

Learning To Deploy VTSO 3 AddIns

Edit: Follow-up article VSTO Lessons Learned

I'm writing this open letter to anyone who can help me ramp up faster on learning the best practices for deploying VSTO 3 Add-In's written in Visual Studio 2008 targeting Office 2007. I've done a bunch of googling, asked for help in multiple forums but no one else seems to have gone down this road yet.

I'll share first what I have learned..... VSTO is basically a big adapter pattern / thunking layer framework to make it super easy to write managed code add-ins for Microsoft Office without all of the hassle of interop. I'm probably summing this up to simplistically but hey, I'm just a Setup Developer not a VSTO Developer.

The developer that I'm working with has created a .VSTO file which is basically a ClickOnce project generated by Visual Studio. We don't want to use ClickOnce to deploy the AddIn because we really have a bunch of AddIns to deploy along with .NET Framework 3.5, VSTO 3, several other prereqs, various system components, GAC assemblies and other managed applications such as tray apps and system services.

So currently I'm writing an MSI to lay everything down on the machine and then call out to %CommonProgramFiles%\Microsoft Shared\VSTO\9.0\VSTOInstaller.exe /Silent /Install [TARGETDIR]Foo.vsto.

The above is technically workng working but I'm really not happy with it. It looks a lot like the ugly devenv /setup CA calls I see Votive use in WiX. I feel caught between a rock and a hard place.... the Windows Installer purists proclaim that EXE CA's are full of danger to be mitigated ( why it's not mitigated in the EXE hosting model is a blog for another day ) and yet the VSTO people don't see to have given me any other choice.

Edit: I've noticed that calling VSTOInstaller installs the add-in only for the current user. If I run it as Deferred System Context the interactive user won't see the add-in. If I run it as Deferred then the user will but other users won't. This might require me to do some per-user pattern hacks.

Does anyone have any suggestions?

What's Your Blog Worth

I was a little bored and in need of distraction when I discovered an old interesting site that `calculates` blog worth. Just for fun ( and no serious comparisons intended ) I decided to plop in my own blog and it came back as $6,209.94. Personally I think my blog is really priceless. :-) But heh, who can argue? So for more fun I plopped in a few of my favorite MSI related blogs: Heath Stewart $2,822.70 Bob Arson $7,339.02 Aaron Stebner $8,468.10 Rob Mensching$17,500.74 Not too bad, but as important as us little MSI Experts sometimes think we are, let's look at a blog with a more general audience: Scott Guthrie: $1,715,072.52 Whew, I'd sell my blog for that much. Of course my comment about self grandeur equally applies to techies in general. Let's look outside of our circle at a few sights that might be popular with other members of your family: Rotten.com $2,072,426.34 Post Secret $5,539,266.48 Perez Hilton $5,655,561.72 Hmmm, funny yet little humbling isn't it? Well, I guess that's why Howard Stern makes $500 million and the rest of us make somewhere south of that.

Even developers are concerned about the environment...

Recently in the wix-users email list the following question was asked about hybrid installations:

Is it possible to create one MSI for both 32bit and 64 bit OS

Oh wait... You mean it's not that type of hybrid? Well then, I think I can still help you out.

5 years ago, there were very few people would have even thought about supporting the x64 environment. However, the current processor lineups from the major vendors support both instruction sets natively. The usage of 64-bit operating systems is increasing. Making it more prevalent is the fact that the x64 versions of Windows contain a 32-bit subsystem to support 32-bit applications. This means in most cases, you don't have to abandon your beloved 32-bit applications.

No one wants to maintain two installation codebases, it would be most convenient if both versions of the binaries could be supported in one installation package. Here is where the problem creeps in. Windows Installer only supports one processor architecture in the Summary Information stream. Of course, I wouldn't even bother telling you this if there wasn't a convenient work-around.

Since x64 versions of Windows support 32-bit applications, we can mark the Template Summary property as Intel;1033. While this does instruct Windows Installer to treat this package as a 32-bit package, Windows Installer allows for this package to contain components marked as 64-bit. Since the question comes from the wix-users list, we'll focus on WiX for this entry, but the same principles can be applied to any Windows Installer project no matter what your tool of choice is.

Consider the following snippet from a WiX product file:
<Directory Id="TARGETDIR" Name="SOURCEDIR">
<Directory Id="ProgramFilesFolder"
ShortSourceName="Progra~1" SourceName="Program Files">
<Directory Id="INSTALLDIR"
Name="Test">
<Component
Id="Common.txt" Guid="{FC288E49-D459-4EE8-AC1F-375497A6E09B}">
<File Id=" Common.txt" Name="Common.txt" KeyPath="yes" DiskId="1" Source="SourceDir\File\Common.txt"/>
</Component>
<Component
Id="_32bit.txt" Guid="{E4D22ADB-9A91-4388-8F5E-391DB1CCB211}">
<Condition>(VersionNT) AND (NOT VersionNT64)</Condition>
<File Id="_32bit.txt" Name="32bit.txt" KeyPath="yes" DiskId="1" Source="SourceDir\File\_32bit.txt"/>
</Component>
</Directory>
</Directory>
<Directory Id="ProgramFiles64Folder"
ShortSourceName="PROGRA~1" SourceName="Program Files">
<Directory Id="INSTALLDIR1" Name="Test">
<Component
Id="_64bit.txt" Guid="{8EE8C9CE-2F2A-43B8-B6B6-AD8E01A4109F}" Win64="yes">
<Condition>(VersionNT64)</Condition>
<File Id="_64bit.txt" Name="64bit.txt" KeyPath="yes" DiskId="1" Source="SourceDir\File\_64bit.txt"/>
</Component>
</Directory>
</Directory>
</Directory>
<Feature Id="32bit" AllowAdvertise="system"
Display="expand" Level="3" Title="32bit">
<ComponentRef Id="_32bit.txt"/>
<Condition Level="0">VersionNT64</Condition>
</Feature>
<Feature Id="64bit" AllowAdvertise="system"
Display="expand" Level="3" Title="64bit">
<ComponentRef Id="_64bit.txt"/>
<Condition Level="0">VersionNT
AND NOT VersionNT64</Condition>
</Feature>
<Feature Id="Common" AllowAdvertise="system"
Display="expand" Level="3" Title="Common">
<ComponentRef Id="Common.txt"/>
</Feature>

The application is divided in to three features, 32-bit, 64-bit, and a common feature. The common feature contains the bits that will be common to both architectures and of course the other features contain the architecture specific bits. The components are then conditionalized to only install on their supported architectures. The good news is, this is not theory, I have tested this and it works.

There is of course a reason why you would not want to do this. Look at the size of the .NET Framework 3.5 redistributable. It's HUGE! ...and why do you think that is? Correct, it contains the binaries for all of the different processor architectures. Aaron Stebner has discussed this in a pretty recent blog post of his.

So no, it's not that kind of hybrid, but it should at least help you in your development efforts.

Pay No Attention To The Bugs Behind the Curtain

Recently I expressed my concerns ( Wix: Forced To Use Beta Software ) about the release schedules and methologies employed by WiX 2.0/3.0. As usual my concerns were downplayed with comments like this one from an anonymous user:

You are overreacting.
WiX/Votive 3 is pretty stable and if you test the .msis correctly you won't run into dark holes.

Unlike your beloved InstallShield which likes to crash from time to time ;)

Wow! I've been in this business for a long time and it's very rare that I hear companies tell their customers `You are overreacting`.

Of course, I'm not overreacting. The last official release of WiX v2 and wiX v3 was May of 2007. That's nearly 8 months ago and another 12 months to go since Rob said it's unlikely to be resolve this year. So if you want to use any of the bleeding edge progress you have to comb your way through weekly releases.

Recently I was doing just that when I discovered that in the latest build of WiX that the Votive WiX Projects won't appear in Visual Studio 2005. Go back a build and they work.

Now I ask you: How many developers who read my blog work for companies where their iteration schedules are measured in years instead of months, drop untested preview builds on their customers, expect their customers to troubleshoot the problems and file their own bug reports, search blogs for release notes and tells them that they are overreacting when they suggest that the status-quo isn't working?

:Pause:

All you Microsoft employees can put your hands down now. Does anyone else still have their hand up?

Anyways, I know that's not how we do it where I work.

An Interesting Year Of Change To Come

Although I'm pretty savvy, I'm not really qualified to give financial advise. Still, I can't help but notice the pendulum swing that's happening and I advise everyone to seek knowledge and apply it to your own personal situation. It seems that change is in the air again ( as it always is ) and it smells like recession driven merger and consolidation. Just about every industry that I've been in is seeing a lot of activity in this area and a few minutes ago I found out that I've been `sold` once again. Just four months ago I was working for a privatly held company named Hart InterCivic who sold our Records Management group to a publicly traded company named Manaton who has just now been sold back to a private equity company named Thoma Cressy Bravo. This new company seems to be in the business of consolidating industries. The last company, Austin Information Systems / Overwatch Systems I worked at went through a similar transition ending up as part of Textron Systems. Before that I worked at Continental Airlines which has been part of the merger rumor mill with United Airlines and other suitors for years. Even before that at EDS there was always rumors that our group was going to be sold to CA, CSC or IBM.

Well, heads up and hang on! I hope it's a good year for all of us.

WiX: Forced to use Beta Software

Aaron Stebner recently posted a blog describing why XNA Game Studio 2.0 switched from WiX 2.0 to WiX 3.0. Interestingly enough he failed to mention that WiX 3.0 is a BETA release.

This reminded me of a WiX-Users list post from Votive Author Justin Rockwood where he says:

Votive 2.0 hasn't been touched in over a year, so I'm not sure what the issues might be. Also, Votive 2.0 was designed primarily to work with Visual Studio 2003, although I think it also was supposed to work in VS 2005. Maybe with SP1 there were some changes. Actually, I know that's the case now that I think about it. SP1 moved a bunch of registry keys from HKLM to HKCU, so I bet Votive doesn't work on SP1. I'd like to say that we'll fix that, but we probably won't. J Sorry about that. I recommend one of the following: 1) move to Votive v3, which is more stable and more feature-rich, 2) use Visual Studio 2003 for Votive v2 development, or 3) uninstall SP1 for VS 2005. I know that these options may not be the best for you, for which I apologize, but Votive v2 is really not supported anymore.

Does anyone besides me see a problem with this? Let's break it down:

Votive 2.0 was designed for VS2003 and might work on VS2005 but not VS2005 SP1.
VS2005 SP1 was released on Dec 15, 2006.
WiX 2.0 was made the production gold release on May 25, 2007. That's over 5 months to `get it right`.
According to Justin: "Votive v2 is really not supported anymore."

So that leaves us with WiX 3.0 which is described as beta quality, ever changing, `use at your own risk` release. Personally I don't think it's fair to ask setup developer and tools ISV's ( InstallAware for example ) to have to make this choice.

According to WiX creator Rob Mensching don't expect this problem to be resolved for another year.

InstallShield .NET 3.5 Unofficial Fix

As recently announced on InstallSite InstallShield has published a .NET 3.5 prereq. Recently I noticed a thread on InstallShield community where user Bruno Walter noticed a potential problem with reboot handling of the prereq.

I've not actually had a chance to check this out yet but the defect seems to be confirmed and an unofficial work around provided by InstallShield development.

If you are on the bleeding edge with .NET 3.5 you might want to check the patch out which is available here.

Microsoft.Public.Platformsdk.MSI Is Overrated

In a comment to Aaron Shurts's recent blog Stefan Krueger left pointing to a support page that mentions:

The MSDN Managed Newsgroup benefit gives you unlimited access to English language managed newsgroups as an MSDN subscriber. Get responses to your questions from the community or Microsoft within two business days.

First off ( even though I've never met him in real life ) I highly respect and like Stefan. So my thoughts here are strictly about the newsgroup, not the messenger.

I find it interesting that Microsoft advertises the newsgroup as an MSDN Subscription feature. Then again, Microsoft has recently been in the news for charging for features that it otherwise gives away for free. Sadly, Macrovision is guilty of this as well since they claim that Bronze, Silver and Gold maintenance plans come with "24 x 7 access to product Web Communities".

Either way my personal opinion of the MSI newsgroup is very low. The volume of traffic is extremely light. When you wade past all of the `MI5 ruined my life` spam posts, there is almost zero traffic.

What's left is a core group of mostly InstallShield/Wise/InstallAware haters who love to roll their own tools. Ironically a couple of these people have been awarded MSI MVP Awards simply because of their participation in this one small forum and/or for rolling their own tools. ( But that's a topic for another day. )

The core group of this newsgroup typically `helps` people who are having problems writing MSI packages using the SDK tools, home grown tools and VDPROJ. From my observations, the same old problems crop up year after year. Problems that wouldn't be happening if better tools were selected.

For example, one recent particularly funny thread was when Microsoft Windows Installer MVP Dennis Bareis was having difficulty understanding registry appending and registry types. I've been using InstallShield for years and their graphical designers make this question a non issue as the tool guides you through authoring your registry table entries. If you want to know what it actually looks like, you can see it in the direct editor. I suppose everything has to be harder when you are rolling your own and trying to prove that you know more about MSI then InstallShield.

Well, I'm sure with this post I haven't made any more friends at Microsoft. Sorry, but this is how I feel on the subject and I'm more interested in telling it the way it is and trying to improve things then paying homage and maintaining the status quo.

How Gracious of Them

The Windows Installer team has seen it in their heart of hearts to provide some information on where to receive professional support for Windows Installer.


Yes, I am being a little sarcastic. If I don't maintain a support contract with Microsoft, then I am looking at spending anywhere between $99 and $515 for professional support. I wish I had thought to charge $99 every time someone emailed me a question about Windows Installer (Note to self...). :-)

In lieu of spending your hard-earned money on professional support, I thought I would direct you to what can often be more valuable, community support. There are many great resources in the nebulous cloud of the internet where you can find the information that you need concerning Windows Installer. The advantage of paying for it I guess would be the instant gratification of having an answer right away. What is not guaranteed is how long you will be on hold waiting for that answer.

The following is by no means a comprehensive list, but I believe this list should be in everyone's link box:
Windows Installer SDK - SDKs are not always the easiest reading material, but this is by far the most comprehensive reference concerning Windows Installer.
microsoft.public.platformsdk.msi - The most active newsgroup discussing Windows Installer
microsoft.public.windows.msi - Another newsgroup resource, but not quite as active as the platformsdk group.
microsoft.public.win2000.msi - The least active Windows Installer newsgroup.
InstallSite.org - Excellent site run by Stefan Krueger that contains, tutorials, tools, downloads, forums, and more. The forums are an excellent place to ask questions and get help. InstallSite is a very active community. It is mostly InstallShield-centric, but Windows Installer is Windows Installer no matter what tool you are using.
InstallShield Forums - These are the official forums run by Macrovision, and this is also a very active community.
Wise Product Forums - These are the official Altiris (now Symantec) forums with yet another very active community.
wix-users Email Group on Nabble - Whether you are a user of WiX or not, this searchable archive of emails about WiX and Windows Installer contains an incredible wealth of information. If you would like to subscribe to the email list, you can do so here.

I am in no way putting down the Microsoft employees or their capabilities. I am sure they could provide you with very sound advice and help. However, if you don't need your answer yesterday, 99 times out of 100 the community will come through for you.

I tried not to duplicate Chris's earlier post too much. I wanted to focus more on where you can ask questions and receive answers. The community will appreciate it very much if you were to search for your question first to see if it has already been answered.

New Contributor

MessageBox.Show("Hello World!");

There really is no better way to introduce yourself as a fellow nerd than with a little bit of code. When Chris mentioned that he was looking for contributors, I jumped at the chance. I have been reading his and many other associated blogs for many years now and thought this would be a good opportunity to share what I have learned and am continuing to learn about the black cloud that is Windows Installer.

I got my start in the tech industry in 1995 on a contract at Ford Motor Company. Since then I have tried to make the most of my experience by inserting myself in to as many roles as possible. I started in the tech industry doing cable pulling, and system installs and repairs. I moved over to the help desk shortly after and did my "time". ;-)

I then jumped over to the administration side of things, first in client administration (this is where I was introduced to application repackaging), then network administration. I spent a few years doing administration and then moved into development. My exposure was light at first, mainly cgi-based web applications written in Perl. I then started to dabble more and more with Win32 middleware and UI development, and quickly engulfed myself in .NET development with the release of Visual Studio .NET.

I was hooked and took full advantage in my role as a consultant to utilize nearly all of my skills and experience while constantly learning new ones. I started with Wise Solutions, Inc., developers of Wise for Windows Installer and Wise Package Studio. Wise was shortly after purchased by Altiris where I spent an additional 3 and half years traveling the globe performing training, and consulting engagements. I loved it, but the need to be near my family outweighed my love for traveling the globe.

I am currently employed by a software company in the Phoenix area as a Development Support Architect. I specialize in things such as internal tools development and installation architecture. I also provide mentoring for the various development teams in existing and new technologies such as Windows Vista. My unique background and experience allows me to assist them in taking full advantage of the operating system in their development and ensuring that our entire suite of products can co-exist peacefully.

I look forward to contributing!