Wow, how time flies. Here's a quick qik where I quickly trace out the last 9 years.
(I am clearly still not quite comfortable talking to the phone. I'm talking way too quickly. However, I really liked the way the whiteboarding worked out so I'll probably do more of that).
An MSBuild debilitating bug was accidentally introduced in WiX v3.0.4206.0. We got a fix in later that day and I just pushed a new build, WiX v3.0.4207.0. In case you pulled down 4206 thinking you were getting much goodness, you didn't... 4207 is much better. <smile/>
Sorry for the trouble.
Last night I noticed this blog entry about the lack of Windows Installer Training courses. It got me thinking about an idea that Bob Arnson, Peter Marcu and I toss around occasionally. The idea always ends with this question, "What if we could do the Installation Architecture Reviews outside of Microsoft?"
For over a year now, those of us that volunteer on the WiX toolset have offered to do installation architectural reviews for teams inside Microsoft. Over that time we've seen the whole gambit of installation scenarios from 64-bit registration issues to multi-server Web+DB applications to tiny internal IT apps hurting for a real build process to Internet patch distribution challenges to the very important application that they didn't realize wouldn't install on Vista (until we pointed out the non-deferred system modifying CustomAction).
We usually meet with the team over lunch in some conference room and talk for an hour or two about whatever the team wants to cover. We always start by understanding the application design before digging into the setup design. Often we end up spending more time talking about the design of their application than their setup since fixing architectural issues at the root is usually easier than creating workarounds at the edge. In the end, both sides have always have a good time and everyone walks away having learned something. Sometimes we even get invited back later to follow up on progress made or to answer additional questions.
So the idea that Bob, Peter and I discuss is what it would be like to provide the same installation architecture reviews for companies outside of Microsoft. We think it would be fantastically fun but aren't sure there would be enough interest to warrant the effort it would take to "break out of the corporate firewall". So, it occurred to me that I should just ask. Duh.
If you would be interested in investigating what it would take to have a few guys that work on the WiX toolset and at Microsoft doing an architectural review of your application or system installation, please contact me. If we get enough interest, we'll see what we can work out.
tags:
rob,
mensching,
installation,
architecture,
reviews,
wix,
toolset,
microsoft,
bob,
arnson,
peter,
marcuI've been getting some great feedback about where people think we should take WiX v2 and WiX v3 next. It has me reconsidering some of my original short and medium term plans. I want to summarize the feedback so far and encourage others to comment if they have opinions as well.
WiX v2 SP1
Original Plan (described in detail here):
- Add MSI 4.5 support. MSI 4.5 was just released so we can add support to WiX v2 for it.
- Revert MergeMod.dll. Recently discovered WiX v2 shipped with a broken MergeMod.dll, so we need to go back to an older one that works correctly.
- Fix SQL CustomAction. Need to get the fix for a crashing bug out there widely.
Suggested New Plan:
- Revert MergeMod.dll. Simple fix already tested in WiX v3.
- Fix SQL CustomAction. Simple fix already tested in WiX v3 extensively.
Reason:
It is pretty clear that most people would rather see a stable WiX v3 released than have a lot of work done on WiX v2. The MSI 4.5 support will be a fair bit of work porting back the existing support in WiX v3 to fit WiX v2. More pointedly, I haven't heard anyone asking for us to do this. The other two bug fixes are trivial to port back and have already had extensive testing in WiX v3 so I think that makes an update of WiX v2 to fix some bad bugs really easy.
The question to you is whether it is important to have MSI 4.5 support in WiX v2? WiX v3 already has support and time spent doing the MSI 4.5 work in WiX v2 will be time away from finishing WiX v3.
WiX v3
Original Plan (described in detail here):
- Core Toolset Patching + Language Enhancements. These are basically done and we're just fixing bugs.
- Extension stabilization + more. The version for the extensions has been frozen and we have a few more Custom Actions than WiX v2.
- WiX Bootstrapper. Project not yet started to provide chaining and external UI handler.
- Votive MSBuild Integration + designer framework. Votive is far more stable but no closer to providing designers.
- ClickThrough. ClickThrough is currently not being developed.
- Deployment Tools Foundation. DTF was a late add but has been getting a lot of attention lately and stabilizing quickly.
Suggested New Plan:
- Core Toolset Patching + Language Enhancements. Finish off all of the bugs.
- Extension stabilization + more. Call the current list of extensions good for WiX v3 and finish off all of the bugs.
- Votive MSBuild Integration. Cut the designer support and just finish off all the bugs.
- Deployment Tools Foundation. Finish off all of the bugs.
Reason:
As noted above, it is pretty clear that most people want a stable WiX v3 released. The suggested plan above cuts all of the "long pole" features and allows us to focus on finishing WiX v3. The hardest cut for me is the bootstrapper but I have to admit that it still has quite a way to go before being done. Theoretically, focusing on the bugs would allow us to become very stable before the end of the year and let the toolset bake for a few months next year before declaring it stable.
The question to you is whether getting a stable WiX v3 earlier is worth postponing those features for the next version? I didn't have anything on the feature list for WiX v4 so bootstrapping, Votive enhancements and ClickThrough could easily be the next focus.
Comments? Questions? Your feedback is much appreciated.
At the beginning of the year we declared the WiX v2 toolset stable. It was a great feeling to finally have something we could point people to when they asked for a WiX toolset that was under constant development. Back then I noted that we would release new drops of WiX v2 when bad enough bugs or big enough changes showed up to warrant it. Three things have come up:
1. MSI 4.5 - rumor has it that MSI 4.5 will be released soon. We have all of the new functionality provided in MSI 4.5 already in WiX v3 so it will just be a matter of porting those changes back to WiX v2.
2. MergeMod.dll - the latest version of mergemod.dll has a nasty bug in it that remained dormant until recently. Bob tracked down the issue and confirmed the bug with the Windows Installer team. We downgraded mergemod.dll in WiX v3 to an older version that doesn't have the bug. Unfortunately, we recently realized that WiX v2 has the same broken version of mergemod.dll so we'll release an update for that.
3. SQL CustomAction - SFBUG:1653864 tracked a rather subtle bug that was fixed a little while ago. That fix has been ported to WiX v2 and will be in the next release.
We started off by jokingly calling this next release of WiX v2 "SP1". The name is starting to stick so I expect we'll stick with it. The version number will still be "2.0" (with some build number higher than "6400.0").
Just a heads up for those of you who are currently running WiX v2. We'll have a release candidate for WiX v2 "SP1" in the next month or so and would greatly appreciate it everyone gives it a good run through the paces. More information will be posted here and on the WiX web site soon.
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.
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/>
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.
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.