Doctor Deploys Blog

Stefan Krueger met with us a few weeks ago for the Microsoft MVP Global Summit. Among the many topics we discussed was a suggestion from Stefan that we use the team’s blog to communicate relevant bug fixes that we make in our releases. This posting is the result of that suggestion. (Thanks, Stefan!)

Windows Vista Service Pack 1 was recently released and you may have noticed that the version of MSI on the system has incremented to 4.0.6001.18000. Below you will find a list of the most important issues that we addressed in Service Pack 1 and the SDK.

Updates that can be found in Windows Vista Service Pack 1:

·         User Shortcuts in Redirected Start Menu Do Not Get Removed On App Uninstall

If you attempt to uninstall an application that was installed for a roaming user, you may receive error 1910 and the shortcuts from the start menu will not get removed.

·         Win32_product does not work on vista when more than one per-user application is installed

Queries to the Win32_Product WMI class will if the machine has at least 2 per-user applications installed with a generic failure error.

Updates that can be found in the Windows SDK for Windows Server 2008:

·         PatchWiz 4.0 ignores the IgnoreMissingSrcFile property

This property in the TargetImages Table is often used to reduce the time necessary to generate a patch, but the property was ignored in patchwiz 4.0 that was included in the Windows Vista SDK.

·         Patchwiz 4.0 does not recreate the Patch table if dropped

Previous versions of patchwiz would automatically recreate critical tables (eg: Patch, PatchPackage) if they were dropped in the patch. Patchwiz 4.0 did not include this behavior, which caused failures in some cases.

·         PatchWiz 4.0 does not support authoring of OptimizeCA MsiPatchMetadata property

The OptimizeCA property can be included in the MsiPatchMetadata of a MSP to restrict custom action usage and improve performance during patch application. Using this property with patchwiz 4.0 caused a build failure.

·         PatchWiz 4.0 is unable to build patch for products with large number of files (>32767)

Previous versions of patchwiz supported building patches with a large number of files, but patchwiz 4.0 did not.

·         Orca crashes when a transform is generated and a row is deleted from the current table

Orca crashes if the user attempts to generate a new transform and deletes a row from an existing table.  (Using Orca, select New Transform, then delete a row from a table).

·         ICE30 does not display all ICE errors

ICE30 only detects a subset of the total number of SFN/LFN collisions for components that contain files.

[Author: Tyler Robinson]
This posting is provided “AS IS” with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm.

Original post by Windows Installer Team

The Windows Installer (MSI) team is part of the rapidly-growing Windows Application Platform (WAP) team here at Microsoft. We currently have several openings for talented Program Managers with real-world knowledge of the Application Deployment, Platform and/or related Tools space.

The positions we have open are job codes 225586, 225368, 228382, 223260, and 226806. (Please go to the Microsoft Career web site and log in before clicking on these links.) If you think you might be a good fit for any of these positions, please apply through Microsoft’s Career web site.

[Author: Tyler Robinson]
This posting is provided “AS IS” with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm.

Original post by Windows Installer Team

Hello Everyone —

The schedules for Microsoft TechEd 2008 in sunny Orlando, Florida have recently been posted and I am pleased to announce that we will have FOUR Windows Installer-related sessions: two during the Developers Conference June 3-6 and two during the IT Professionals Conference June 10-13.

IT Professionals Conference Sessions:

Developers Conference Sessions:

If you plan to attend TechEd, please attend our sessions and say HI to myself, Ken, Hem and Robert!

[Author: Tyler Robinson]
This posting is provided “AS IS” with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm.

Original post by Windows Installer Team

Like almost all Thursday nights, I was out with the guys writing code for the WiX toolset. Also, like almost all Thursday nights, Jenny called me before she headed off to bed. Sadly, tonight she informed me that her Zune had frozen on her walk to work this morning.

Well, I just got home after getting the last set of build system changes in and posted. I decided to take a peek and see if I could fix the ailing music player. It was definitely frozen with its screen dimmed showing one of the menus but not responding to input.

After pressing and holding a few buttons, I decided it was time to hit the Internet. In the first page, I came across this blog entry that did just the trick. Press and hold the Back button and the up on the pad for a few seconds and the Zune will reset. This fixed Jenny’s Zune and it seems quite happy, connected and charging.

Reading through the comments here are a few other key combinations that you can use on your Zune:

• On - press and hold the Play button.
• Sleep - press and hold the Play button.
• Off - press and hold the Back button plus down on the pad.
• Reset - press and hold Back button plus up on the pad.
• Erase - press and hold the Back button plus up on the pad then press then hold Back button plus right on the pad plus Play button. From KB926917.
• Format - press and hold the Back button plus up on the pad then press then hold Back button plus left on the pad plus Play button. Formatting will require you to connect your Zune back to a computer for the Zune to be useable again.  From KB927001.

 

Original post by Rob Mensching

Issue Description

Performing either of the following operations causes patchwiz.dll v4.0 to delete all writable files and folders in the root directory:

1.       UiCreatePatchPackage is called with the hwndStatus parameter set to NULL OR

2.       UiCreatePatchPackageEx is called with the hwndStatus parameter set to NULL and dwFlags set to 0×800 OR

3.       Using msimsp.exe v3.0 to create Windows Installer patches while using patchwiz.dll v4.0.

Cause

When invalid parameters are supplied to UiCreatePatchPackageEx API, it bails out with an error code. However, while returning, the API erroneously uses partially initialized data to clean up the temporary directory. This partially initialized data results in deleting the writeable data root drive.

Resolution

There are three resolutions for this issue currently:

1.       Do not use patchwiz.dll v4.0 to call UiCreatePatchPackage and UiCreatePatchPackageEx with these parameters.

2.       Get the latest patchwiz.dll v4.5 from the Windows Installer 4.5 Beta program. The latest version of patchwiz.dll there fixes the data loss issue mentioned in this blog. However, the call to UiCreatePatchPackage with hwndStatus parameter set to NULL will fail to create a patch. We understand that this is a regression. It will be fixed in Windows Installer 4.5 RTM.

3.       Use patchwiz.dll v3.1.

[Author: Hemchander  Sannidhanam]
This posting is provided “AS IS” with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm.

Original post by Windows Installer Team

Someone asked recently how to use an ampersand (&) in the Product Name for their .wxs file.  Probably something like:

<Product Name="Stuff & Stuff Demo" ...

The error message itself is pretty brutal but does pinpoint (to the exact character) the problem:

stuff.wxs(3) : error CNDL0104 : Not a valid source file; detail: An erroroccurred while parsing EntityName. Line 3, position 27.

The error message is coming from the XML parser (we currently don’t try to trap those and print out friendlier error messages, not sure that is even possible) telling you that the the “entity” (things that start with an ampersand) name is invalid. The trick is to realize that ampersands are special characters in XML. Fortunately, this fact is pretty well documented all over the Internet. So the fix is easy:

<Product Name="Stuff &amp; Stuff Demo" ...

The follow up question was how to get an ampersand to show up in the UI. The issue is that if you have something like:

<Control Text="&amp;Print" ...

The control’s text is going to look like “Print”. For as long as I can remember, Windows dialogs have used used an ampersand to mark the accelerator key (or is it accessibility key?) . So hopefully it is no surprise that the Windows Installer chose to follow the same convention for their dialogs. Anyway, if you really wanted “&Print” to be the text of the control then you’d need to escape the ampersand like:

<Control Text="&amp;&amp;Print" ...

This is one of those cases where the special characters in one language (XML) also used represent special characters another language (MSI UI) end up complicating the escaping across the board. Fortunately, this doesn’t happen too often (and isn’t nearly as ugly as the escaping of XSL in Formatted text fields).

 

Original post by Rob Mensching

I just couldn’t focus tonight so I went surfing for recent blog entries and web pages talking about the WiX toolset. Usually, I can search for wix and find some interesting things that either need to be fixed or documented better or sometimes a success story. Unfortunately, tonight I tripped across a troll post.

Now the conventional wisdom is that the only way to deal with a troll is to ignore it. “Do not feed the trolls” and all that. However, I’ve been thinking about this issue for a while and I thought I would float the question out there to see what all of you think.

First a little background then the question. The blog entry at the top of the search list tonight went something just like this:

The other day I was reading a blog where Rob Mensching was very proud that WiX installs tend to be Red instead of Blue:

“Blam! Right out of the gate I knew I was looking at a package built by WiX. How? Look at the red. All the other installation vendors out there like blue.”

Well, I suppose that’s better then the way I used to know that a package was built using WiX. You know….. No Dialogs At All!

Before I start let me note that the issues I raise below are minor and completely dismissible by themselves. The question to ask yourself is if these sorts issues are relatively constant do you simply ignore them all or do you look through the mild (or not so mild) inflammatory remarks and debate the underlying issue?

With that context in mind, let me enumerate the issues that I find misleading, inflammatory and interesting (yes, interesting) from the snippet of the blog above:

1. If you read my original blog entry, nowhere in it will you see that I state that I am proud that installation packages built by the WiX toolset are often red. In fact, I’m not particularly proud about the graphics in the WiX toolset. I think the graphics provided in the default WixUI are actually pretty ugly. I have asked a few times if someone with more artistic skill than me was interested in donating better graphics to the project (I personally hacked out that red bitmap from the blue one that was part of the Orca install almost 9 years ago). I picked red (9 years ago!) for the exact reason I stated in my blog entry “All the other installation vendors out there like blue.” Red provided a quick indicator that you were probably looking at a WiX built package.

   So my first issue is that the snippet above completely misrepresents what I believe.

   A little bit of me wonders whether someone reading that blog entry would begin to believe that I think the default WixUI somehow sets the standard for what a beautiful looking install package should aspire to.

2. The second part is a backhanded criticism of the WiX toolset that links to an old blog post which suggests WiX is incorrect and inferior for allowing installation packages to be built without a UI. The blog author is entitled to his opinion that all installation packages should have a UI. However, the author chooses to use divisive language to attack the WiX toolset (i.e. “WiX is too primitive of a toolset to possibly assist the developer in authoring a decent UI experience” [ed. emphasis mine]) and me (i.e. “I suppose if you only go by one persons definition of bad”). Unfortunately, that word choice naturally puts people that are associated with the WiX toolset on the defensive (particularly, those of us that volunteer on the toolset).

   So my second issue is that ignoring an individual due to “troll-like” behaviors means that is not possible to rebuke incorrect statements made by that individual.

   In this case, the invalid statements were that the WiX toolset does nothing to assist developers with UI, there are actually a few defaults to choose from but they are all red. <smile/>

   Ironically, if you read through the comments in that old blog post you’ll see the exact point when I realized I came to believe I was dealing with a troll and completely quit responding. You can also see how I started a bit defensive in my first comment and tried to regain my composure in the subsequent comment.

3. Now the part that I find interesting is that underneath all of this is what could be a very fascinating debate about the role of UI in an installation package. There are things the WiX toolset does poorly (for example, the default graphics are pretty ugly and creating custom UI by hand is tedious) but there are a couple things in WiX that might be interesting (such as the “advanced” WixUI structure). Plus the simple discussion about whether every single installation package requires UI or not could be interesting.

   So, finally, I am wondering if I should just ignore the inflammatory remarks and always discuss/debate on the salient points (if any).

The above is a dissection of a very specific and small set of events around my work on the WiX toolset in an attempt to appropriately frame the general question, “Is it better to tend to the trolls or should we just ignore them?”

I welcome your comments. I’d be especially interested in other’s interactions with what you believed to be troll-like behavior, how you handled it and how that worked out.

 

Original post by Rob Mensching

Today I finally worked out the final issues blocking the latest release of the WiX toolset. There were several small bugs in the release batch files that just took time to run down. There is a fair bit of remaining clean up work for me to do but I am pretty sure that the worst has passed and weekly releases will be back on track.

A few people have asked me why it took five weeks to get everything working. There were two major issues that took a lot of time. Before I list those, just to remind everyone, the biggest change is that build process now builds 64-bit (both amd64 and ia64) versions of the Custom Actions. Since the beginning we we have avoided building anything 64-bit (32-bit Custom Actions on WOW can do quite a bit) but a few bugs came up that were impossible to fix without real 64-bit code. Again, Mike Carlson did the majority of the work.

The first issue that slowed the process down is that I require that at least the x86 version of WiX toolset to be built from freely available tools and SDKs from Microsoft. When the WiX toolset was first released, a number of people tried to argue that WiX was just a ploy to get developers to fork over cash for expensive versions of Visual Studio. That argument was quickly put down when it became clear that with the Windows SDK, .NET Framework SDK and free version of the VC tools you could build the WiX toolset.

Since then the WiX toolset has become more complicated. Most of the issues now come from Votive and the horribly designed VSIP SDK required to build Votive. There are actually tasks in the Votive build process that write registry keys so that a required VSIP build task operates correctly. The 64-bit builds have introduced new complications because you need both VS C++ and the Windows SDK installed to get all of the necessary tools and headers/libraries to successfully build. It took Mike a fair bit of time and a number of different machine configurations to track that one down.

The second issue came down to time, my time. Once 64-bit builds were checked in, it was my task to work through the release implications. Unfortunately, I was buried by day job pressures and then got sick. I finally had time to focus for a few hours last Thursday night and another couple hours this morning to fix the last few problems I hadn’t flushed out.

And now I have time with less pressure. So I am focusing on reducing the release process with the hope that improvements there will reduce the bottleneck on me. Releasing WiX v2 and WiX v3 with their now disjoint and thus doubly-expansive set of dependencies hasn’t been something I’ve kept up well. Unsurprisingly not maintaining the dependencies came back to bite me these last few weeks.

Again I apologize for the delay and thank you for your patience. If you see any problems, please do open bugs on SourceForge.

 

Original post by Rob Mensching