RobMensching.com /Blog
when setup isn't just xcopy

Subscription required, fortunately they are free.

In an effort to cut down on spam to the WiX mailing lists, I will be flipping the switch to require that you subscribe to the list before being allowed to send mail to it in the next few days. The hope is that the requirement for spammers to respond to a confirmation email will raise the bar high enough that they'll just leave us all alone. I also hope that this requirement doesn't scare off anyone wanting to participate in the WiX community.

Switching the mailing list to require subscription was easily the most discussed topic on the wix-users mailing list in a long time. I really appreciated all of the feedback since it made it pretty clear which way to go. I just needed to go get a few logistical things pulled together such as updating the WiX web site with information about how to join the mailing lists (the updates should go out later today).

The last bit of feedback on the thread also gave me a good laugh tonight. I'll leave you with that comment as well as the link to join the wix-users mailing list if you are interested:

> Come on, guys, all it takes is a single, emtpy e-mail to

> wix-users-request@lists.sourceforge.net?subject=subscribe

> and, I guess, a reply to a confirmation mail. Couldn't be easier...

Planting a flag on the peak of Everest is easy as well - all you have to do is press the stick firmly into the snow.

 

More red UI!

After years of being blue, Soma announced that MSDN has finally gone red.

Everyone knows how much I absolutely love a red UI so this is a fantastic upgrade in my mind. Windows Vista went red earlier this year, MSDN goes red now and I expect Office will give up their blue to start sporting a nice red ribbon with their next service pack.

If anyone asks, just tell them that the WiX toolset was setting this "red" trend waaaay back when.  That's right, we were the trend setters for all this 2008 "red is the new black" back in 1999.

 

PS: Yes, I am joking. <smile/>

Deployment Tools Foundation joins the WiX toolset.

Back in early 2003, I was learning C# by rewriting WiX v1, which was tens of thousands of lines of VBScript, to create WiX v2. At the same time, Jason Ginchereau was experimenting with C# to create a managed library to interface with the Windows Installer API. I didn't know about Jason's work at the time so we created a very limited interop layer in WiX to communicate with the Windows Installer APIs. Jason, on the other hand, worked until he had covered every aspect of managed code interop with the Windows Installer API plus support for reading/writing Cabinet and Zip files. He named the result the Deployment Tools Foundation (DTF):

Deployment Tools Foundation is a rich set of .NET class libraries and related resources that together bring the Windows deployment platform technologies into the .NET world. It is designed to greatly simplify deployment-related development tasks while still exposing the complete functionality of the underlying technology.

Over the last six months or so Jason and I have been working together more. You see, Jason is the dev lead on the Visual Studio team responsible for integrating the WiX toolset into the next release of Visual Studio. Among the various things Jason and I have been discussing is what to do with DTF.

The biggest hurdle was that there were not enough test cycles available to ship DTF as part of the next version of Visual Studio. Even though DTF was used by many teams inside Microsoft, all code that becomes part of a shipping product must have a certain level of verification by official test resources. Since there weren't enough resources available to ship DTF as part of the product, Jason was looking for alternatives. Joining the WiX toolset community was an interesting option.

The next hurdle was managed code Custom Actions. As noted above, the Deployment Tools Foundation has full support for the Windows Installer API. That means it is possible to create all types of Custom Action (immediate, deferred, impersonated, rollback, commit, you name it) using managed code.

However, a year ago I posted the outcome of the managed code Custom Action discussion I had with Carolyn (MSI Dev Manager) and a couple Windows architects. To sum up that blog entry they had two issues. First, the technical issue was that managed code Custom Actions needed to be run in a separate process. Second, the Windows platform has a strategic goal to reduce the number of Custom Actions.

When I posted that blog entry, DTF suffered from both issues. A month or so after the blog entry, Jason had addressed the technical issue by implementing the necessary interprocess communication mechanisms to move the managed code Custom Actions into a separate process but still be able to communicate with the Windows Installer. He did a very nice job keeping the overhead very, very low (a simple named pipe) and as a result his solution is very robust.

That left the strategic concerns. I struggled with one for a long time. On one hand, I could understand why they don't want to have a proliferation of Custom Actions. But, at the same time, I saw fewer and fewer native APIs being developed for fewer and fewer native code developers.

I think it was sometime over the week I took off for my birthday that I subconsciously decided what to do. The next blog entry I wrote was titled Obsolete skills where the subconscious decision finally bubbled to the surface. After that, I sat down with Jason and we discussed what it would take to integrate DTF into WiX.

Last night Jason finished the integration work and today you can find the Deployment Tools Foundation in the sdk directory of the latest Windows Installer XML toolset release.

Jason, thank you for all of your hard work and I look forward to watching DTF grow.

 

My apology to InstallAware Software Corporation.

Every once in a while I make a mistake where I know I did something wrong but cannot pinpoint the exact problem. These are the worse kind of mistakes because I don't know what I need to learn to avoid repeating the mistake. As a result I often back away from the problem even though leaving the issue un-addressed may be yet another mistake.

I made one of these mistakes on this blog back in December of 2006. Sinan Karaca from InstallAware Software Corporation asked me to blog about their new WiXAware product. At the time, I had a very negative impression of the company based on my conversations with other people. While I was impressed with Sinan's presentation and believed that WiXAware showed great promise, I allowed my negative impression to color our discussion and, later, my two blog posts.

After realizing that something had gone wrong I backed away from the whole issue and left it unresolved.

A few weeks ago, Sinan reopened the discussion and we traded emails until it became crystal clear to me what mistake I had made 18 months ago. The fundamental mistake I made was that I never gave InstallAware the opportunity to address the issues I had based my negative impression on. In the recent email discussion, Sinan explained his side of the story and I came to realize how the misunderstandings began then spiraled out of control.

I apologized to Sinan and he forwarded my apology on to the WiXAware team. If I could undo my mistake, I would. Fortunately, Sinan was good enough to reopen the dialog when he saw an opportunity and help me see clearly what I did wrong and allow me to learn from it. I immediately offered to make my apology public in an effort to bring the issue to close and Sinan accepted.

 

Sinan Karaca and InstallAware Software Corporation, I apologize for the attitude I had in our first meeting and follow up posting. I fully admit that I should have given you the opportunity to explain up front and address any grievances I might have had. I'm sorry.

 

From here I hope that InstallAware and Sinan and I can start again. I also encourage you to develop you own impression of InstallAware Software Corporation. Finally, for those of you that haven't already made this mistake, please learn from mine.