Compartir a través de

Creative Commons Add-in's Office XP PIA - Conditioning the Office XP PIAs - Part 1

  • Artículo

Creative Commons Add-in for Microsoft OfficePreviously I described how the Office XP PIA install detected what parts of Office XP were installed. There are two places that the detection information is used and there are weaknesses in both places that we'll discuss. In this blog entry we'll take a look at the first place the detection logic is used.

The condition we'll cover here is hopefully self explanatory, not that I'm content to just leave it with that. <smile/> Imagine a line of WiX code that is a child of the Product element that looks much like this:

 <Condition Message="Please install Microsoft Office XP before installing this product.">
ACTION~="ADVERTISE" OR ACTION~="ADMIN" OR OFFICE10INSTALLED OR REMOVE~="ALL"
</Condition>

That Condition element turns into an entry in the LaunchCondition table. The easiest way to read the condition is to look at the content in the element and say, "If the ACTION Property is equal to ADVERTISE or ADMIN (ignoring case) or the Property OFFICE10INSTALLED is defined or REMOVE Property is equal to ALL (ignoring case) then let the install continue. Otherwise, display the message that says you have to install Office XP."

Let's break the condition down once more.

1. The ACTION Property is a standard Windows Installer Property. It can only have three values and ADVERTISE and ADMIN are described here. Fundamentally, this part of the condition says, "If we're doing an advertisement or an administrative install just pass on through."

2. The OFFICE10INSTALLED Property is a custom Property that is set via a ComponentSearch element for (what I'll call) the "Core Office Component" GUID. If the Core Office Component is installed the OFFICE10INSTALLED Property will contain the path to the KeyPath. If the Core Office Component is not installed then OFFICE10INSTALLED will not defined and the condition will fail. Obviously, this is the key part of the condition.

3. The REMOVE Property is another standard Windows Installer Property. I highly encourage you to read through the MSI SDK documentation about the REMOVE Property. Done? Good. In this case, the REMOVE Property is used to ensure that the condition will never prevent the user from uninstalling the Office XP PIA package. Imagine how frustrating the user would be if she first uninstalled her copy of Microsoft Office then tried to uninstall the Office XP package and found that she could not because the PIA package required Microsoft Office installed.

Now that we understand the condition, let me show you the various weaknesses in this little bit of logic. None of these are fatal, but each of them could be improved.

1. There isn't anything inherently wrong in allowing advertisements and administrative images to be created even though the other parts of the condition may later fail. However, in the Office XP PIA install there are two other conditions that basically make this part of our condition irrelevant. Curious what those conditions might be? Here's the WiX code for those two conditions:

 <Condition Message="[ProductName] can not be installed with the ADVERTISE action.">
ACTION~&lt;&gt;"ADVERTISE"
</Condition>
<Condition Message="Creating an admin install for [ProductName] is not supported.">
ACTION~&lt;&gt;"ADMIN"
</Condition>

2. The weakness with the second part of the condition is a bit more subtle. The Office XP PIAs only provide value if you have Word, Excel, PowerPoint, Access, Outlook, FrontPage, Publisher, Visio, or OWC installed. However, it turns out that the "Core Office Component" ends up shipped in quite a few Microsoft products. That means that there are cases where the Office XP PIA install package can be installed even though you don't actually have any applications that could use the PIAs on your machine. As we'll see next time, there are no adverse affects of allowing the install through but it certainly isn't optimal.

3. The final weakness actually demonstrates a change in what I used consider best practices and what I believe are "better practices" now. As noted in the scenario above, it was very important to add the REMOVE Property to the condition so the Office XP PIAs could always be uninstalled. In the past that seemed sufficient. However, now it seems better to use "Installed OR" in LaunchConditions. The Installed Property is standard Windows Installer Property like REMOVE but Installed is always set after the package is installed. Using "Installed OR" means that LaunchConditions will never block the user from repairing, patching, or uninstalling the package once it is installed.

Next time we'll dig into how we condition the Office XP PIA install to only install the right PIAs.

Comments

  • Anonymous
    August 25, 2006
    That's cool information, thanks!

    -- Jordi
  • Anonymous
    August 28, 2006
    Checking for ACTION<>"ADVERTISE" won't prevent an advertisement installation. That's because this condition is not checked, because the "LaunchConditions" action is not called from the AdvtExecuteSequence. Manually inserting this action is prevented by the WiX schema check, because it does not allow <LaunchConditions> to be a child of <AdvertiseExecuteSequence>. I tried this with WiX 2.0.4415.0. If you turn off the schema check with the -ss switch or insert the record manually with Orca, it works though. I see no reason why this action should not be allowed inside the AdvtExecuteSequence...

    Bye,
    Peter
  • Anonymous
    October 17, 2006
    Duane Johnson asked how to use WiX v3 to detect the CLR . Extensions in WiX v3 are far more powerful