WiX v3.0.4130.0 was released on Friday, 30-May-08. You can download it from http://wix.sourceforge.net/releases/3.0.4130.0/.
There’ve been a couple of reports that WiX v3.0.4123 doesn’t include mergemod.dll. That’s unfortunate because it’s a really annoying bug and worse, I was the last one to touch mergemod.dll (to fix 1965131) so it was probably my fault.
I couldn’t reproduce the problem, however; mergemod.dll was present in Wix3.msi, Wix3_x64.msi, and wix3-binaries.zip. I was about to ask for install logs to investigate when a likely cause occurred to me. The bug fix was to revert from a version of mergemod.dll with a bug to a prior one that doesn’t have the bug. Unfortunately, downgrading files is problematic with major upgrades: Windows Installer wants very much to keep higher-versioned files around. After all, the latest version probably has all the latest bug fixes, right?
If you install WiX v3.0.4123 over v3.0.4116, the log will contain a line like this:
MSI (c) (34:D4) [10:47:26:734]: Disallowing installation of component: {AAF02F71-9684-4F4F-8EEA-FC99A61EAA9A} since the same component with higher versioned keyfile exists
Simple workaround: Uninstall the earlier version of WiX, then install v3.0.4123.
As I’ve mentioned before, I’m a big fan of agile development. Turns out it might be responsible not only for great software but enhanced developer brains:
Brain research on rats suggests that voluntary pressure in the form of audacious goals taken on by high performance teams makes them produce more neuron stem cells, rewire the brain, and become smarter. Involuntary pressure, often seen on waterfall teams, reduces stem cell production and makes employees stupider.
[from Jeff Sutherland on an article in The Economist]
Remember that even if your day-to-day efforts focus on yet-another-TPS-report-generator, software is also in large part responsible for some truly awe-inspiring things.
WiX v3.0.4123.0 was released on Friday, 23-May-08. You can download it from http://wix.sourceforge.net/releases/3.0.4123.0/.
Not code-related but Rob announced that the WiX mailing lists will now require subscribing before accepting incoming messages. It’s not a panacea, but it should significantly cut down on the spam.
Microsoft Source Analysis for C# — known inside Microsoft as StyleCop — is now available. We use StyleCop on new WiX code, in addition to FxCop to analyze code for style consistency and correctness. Now that StyleC…er, Microsoft Source Analysis for C# is available outside the campus grounds, we can include the settings files we use in the WiX codebase.
StyleCop is a Visual Studio package that integrates analysis commands in the Solution Explorer and a tool window to show analysis results. StyleCop also includes MSBuild tasks so you can make analysis runs part of your daily builds.
Naturally, the Style…dammit…Microsoft Source Analysis for C# installer is authored in WiX. The package is extremely clean. There are no ICE errors and only ICE33 warnings about non-advertised COM registration. The only custom actions come from WixUIExtension and WixVSExtension. The UI is built with WixUI, though the StyleCop team chose to use some logo-themed white bitmaps rather than the classic-yet-modern red.
The first few times you run StyleCop on existing code, you’re bound to be surprised and probably frustrated. The rules are, after all, about enforcing a consistent coding style. Unless you happen to already be using the StyleCop style, you’ll get a lot of “violations” that seem quite arbitrary. Yep, and that’s the point: Coding style discussions are pretty much religious wars over arbitrary decisions. (Yes, there are exceptions, but mostly it’s personal esthetic choice. Except for tabs versus spaces; don’t mess with tabs versus spaces!)
Just stick with StyleCop style and you’ll be consistent, even if elements of the style aren’t your personal favorite.
WiX v3.0.4116.0 was released on Friday, 16-May-08. You can download it from http://wix.sourceforge.net/releases/3.0.4116.0/.
WixFirewallExtension is a new WiX extension that lets you configure the Windows Firewall from your program’s installer. Windows has had a built-in firewall since Windows XP was released in 2001, though it was XP’s Service Pack 2 that introduced a firewall of sufficient power for most people to use it. (It helps that in SP2, the firewall is turned on by default. The same is true on Windows Vista, Server 2003 SP1, and Server 2008.)
Outgoing connections — from the local computer to a server — aren’t blocked. (In fact, the firewall on XP SP2 and Server 2003 SP1 doesn’t support blocking outbound connections. That feature was added to the firewall in Vista and Server 2008.) Incoming connections are blocked unless the firewall is configured to allow them. If your program is any kind of a server, it needs to add itself to the firewall’s exception list or it won’t receive any connections that originate from another machine.
There are two types of firewall exceptions:
For both types of exceptions, the scope of the exception controls which incoming connections are accepted:
You can configure your program’s firewall exceptions using the FirewallException element. To configure an application exception, nest the FirewallException element under the program’s File element or under a Component element and specify the program’s file id in the File attribute:
<Wix xmlns=”http://schemas.microsoft.com/wix/2006/wi” xmlns:fire=”http://schemas.microsoft.com/wix/FirewallExtension”>
…
<Component Id=”MyComponent1″ Guid=”PUT-GUID-HERE”>
<File KeyPath=”yes” Source=”program.exe”>
<fire:FirewallException Id=”FWX1″ Name=”My Program” />
…
The Id and Name attributes are both required. You can adjust the scope of the exception using the Scope attribute, which takes values any or localSubnet or by using RemoteAddress child elements:
<Wix xmlns=”http://schemas.microsoft.com/wix/2006/wi” xmlns:fire=”http://schemas.microsoft.com/wix/FirewallExtension”>
…
<Component Id=”MyComponent2″ Guid=”PUT-GUID-HERE”>
<File KeyPath=”yes” Source=”program.exe”>
<fire:FirewallException Id=”FWX2″ Name=”My Program”>
<fire:RemoteAddress>127.0.0.1</fire:RemoteAddress>
<fire:RemoteAddress>127.0.0.2</fire:RemoteAddress>
<fire:RemoteAddress>127.0.0.3</fire:RemoteAddress>
…
RemoteAddress is a direct line to the firewall API’s support for remote addresses.
There’s also a Program attribute that lets you specify a formatted string that identifies the program that should get the firewall exception. It’s useful if you want to specify an exception for a program installed by a different package.
To specify a port exception, use the Port and Protocol attributes. Port takes an integer value and Protocol takes tcp, udp, or any. Note that any requires Windows Vista and Server 2008; on XP SP2 and Server 2003 SP1, specify two port exceptions, one with Protocol=”tcp” and another with Protocol=”udp” as a workaround.
<Wix xmlns=”http://schemas.microsoft.com/wix/2006/wi” xmlns:fire=”http://schemas.microsoft.com/wix/FirewallExtension”>
…
<Component Id=”MyComponent3″ Guid=”PUT-GUID-HERE”>
<File KeyPath=”yes” Source=”program.exe”>
<fire:FirewallException Id=”FWX3″ Name=”My Program” Port=”1025″ Protocol=”udp” />
…
Both types of exceptions also support the IgnoreFailure attribute to specify whether firewall configuration failures should be ignored or cause the installation to roll back.
The firewall extension is part of the work I’m undertaking to convert ACES Studio’s products from our old script-based installer to a declarative installer built with WiX. Studio management was pleased to contribute the work to the WiX community.
Virtualization products are low-level programs, pretty much by definition. They have drivers and often poke and prod both the host and guest OSes to perform better. That means they’re sensitive to changes in the OS from service packs. The recent releases of XP SP3, Vista SP1, and Windows 2008 Server have now been matched with updates for both Virtual PC and Virtual Server.
The Virtual PC service pack is delivered as a major upgrade while the Virtual Server update is delivered as a raw .msp patch. That’s pretty unusual; most patches are delivered as self-extractors to manage the elevation, properties of the patch installation, and UI. The Virtual Server folks got most of it covered but one, based on the following instruction on the download page:
Note: Save the MSP file locally and Run the patch from an elevated command window in Windows Vista SP1 and Windows Server 2008
Unfortunately, instructions on download pages are soon forgotten, as you’ll undoubtedly agree if you’ve spent time in tech support. One of the most important things setup can do is prevent common user error. Given that the patch is three-quarters the size of the original release, releasing the Virtual Server update as a major upgrade like they did for Virtual PC would have taken care of the elevation problem in one fell swoop.
[via Virtual PC Guy]
The WiX installer had a bug that I noticed during our transition from Visual Studio 2005 to Visual Studio 2008. If you had the Votive feature installed for VS2005 and VS2008, then uninstalled VS2005, the Votive feature was "orphaned" and couldn’t be uninstalled. The cause is that the Votive features are enabled only when the corresponding version of Visual Studio is installed. (The Feature/@Level attribute is 0 with a Condition child element to enable it.) MSI sees the feature as disabled in maintenance mode and won’t remove it.
Oops.
The solution is easy, though: Add OR REMOVE to the condition that enables the feature. That ensures the feature is enabled during whole-product uninstall or an attempt to remove that particular feature.