Still, it’s better than nothing — the Windows Store is likely to have a lot of window shoppers looking to buy apps.

However, a hurdle to get an app listing page is that the app must pass “certification.” In the past, this was known as the Windows Logo program and had many pages of technical requirements. In Windows 8, the list is much smaller and less prescriptive. For example, the Logo program for previous versions required the use of MSI, then required MSI or ClickOnce; for Windows 8, there are no technology restrictions.

Some requirements that struck me as interesting:

1.2 Your app must not take a dependency on the VB6 runtime

VB6, IE6 — anything v6 must go away.

5.1 Your app must properly implement a clean, reversible installation

If the installation fails, the app should be able to roll it back and restore the machine to its previous state.

If Windows 8 certification is anything like previous versions’, it will involve automated test suites that will highlight rollback that’s less than perfect.

5.4 Your app must never block silent install/uninstall

So don’t throw UI from custom actions and don’t rely on being able to prompt the user (i.e., also don’t break requirement #5.1).

6.1 All executable files (.exe, .dll, .ocx, .sys, .cpl, .drv, .scr) must be signed with an Authenticode certificate

MSI packages aren’t mentioned. But if you ship a Burn bundle or other bootstrapper .exe, that’s going to require signing.

10.1 Your app must be installed in the Program Files folder by default

There’s nothing mentioned that would exempt per-user apps in general from this requirement, though you can always request exceptions. Given the emphasis Metro places on per-user, restricted apps, perhaps this requirement will be extended/relaxed for per-user desktop apps too.

10.6 Your app must write user data at first run and not during the installation in “per-machine” installations

Long-time readers of wix-users will recognize this as advice given again and again. Good to see Windows catching on.

10.7 Exceptions and Waivers

A waiver is required for apps that write to the global assembly cache (GAC) .NET apps should keep assembly dependencies private, and store it in the app directory unless sharing an assembly is explicitly required.

I suspect it’s a response to the GAC getting used too often when it’s not needed or very useful. (See also Rico Mariani’s blog post on using NGen, which falls into the same boat.) Still, I’m mildly surprised to see it a requirement.

12.5 App running under the WoW64 emulator should not attempt to subvert or bypass Wow64 virtualization mechanisms

This one’s interesting, depending how struct “subvert” turns out to be. For example, several WiX custom actions make fairly trivial “subversions” of WoW64 to avoid the need for both 32-bit and 64-bit custom actions just to write to the right version of Program Files.

All in all, there’s nothing terribly surprising in this set of requirements. A lot of them just codify what’s already known as best practice for Windows apps in the age of UAC. Of course, this is just the first version of the certification requirements and Windows 8 isn’t yet shipping; there’s plenty of time for Microsoft to add, drop, or change requirements. In the end, you get to decide whether the effort of certification is worth having a presence in the Windows Store. Remember the Metro-style app folks, who have no choice in the matter: The Windows Store is the only way they can ship.

There are three primary buckets applications fall into in the brave new Windows 8 world:

1. Metro-style
2. Windows 8 non-Metro-style
3. “Retro-style” (aka legacy, anything created before 2011)

Metro-style apps get all the goodies Windows 8 offers, including AppX packaging I’ll blog about. As Rob describes, deployment is a first-class citizen in Windows 8. Apps in the other two buckets have the exact same options they have in Windows 7. And by exact, I mean “really, almost exactly 100 percent.”

No soup for you

As is its wont, rather than fixing the weaknesses of its existing platform, Microsoft replaced it with an all-new platform with a different set of weaknesses. Naturally, Windows 8 still includes Windows Installer. But if you were hoping for some of the same deployment love for your non-Metro-style apps that the Windows team showered on Metro-style apps, I’m sorry to disappoint: For better or worse, Windows 8′s MSI is functionally identical to Windows 7′s MSI v5.0.

A quick spelunking in the Windows 8 SDK available to MSDN subscribers reveals mostly structual changes to the MSI header files. For example, the _WIN32_MSI macro is defined as “500″ for both Windows 7 and Windows 8:

#if (_WIN32_WINNT >= 0x0601 || (defined(NTDDI_VERSION) && NTDDI_VERSION >= NTDDI_WIN8))
 #define _WIN32_MSI   500
#elif (_WIN32_WINNT >= 0x0601 || (defined(NTDDI_VERSION) && NTDDI_VERSION >= NTDDI_WIN7))
 #define _WIN32_MSI   500

The only addition is a new MSIARCHITECTUREFLAGS value in Msi.h:

typedef enum tagMSIARCHITECTUREFLAGS
{
 MSIARCHITECTUREFLAGS_X86   = 0x00000001L, // set if creating the script for i386 platform
 MSIARCHITECTUREFLAGS_IA64  = 0x00000002L, // set if creating the script for IA64 platform
 MSIARCHITECTUREFLAGS_AMD64 = 0x00000004L, // set if creating the script for AMD64 platform
 MSIARCHITECTUREFLAGS_ARM   = 0x00000008L //set if creating the script for ARM platform
}MSIARCHITECTUREFLAGS;

and a new property name in MsiDefs.h:

#define IPROPNAME_ARM              TEXT("Arm")

As we’ve known for a while that Windows 8 will support the ARM architecture, its presence isn’t too surprising.

There are no other new enumeration values. There are no new MSI API functions. While it’s possible there are, for example, new standard actions that wouldn’t have visible impact in the header files, I don’t find it too likely.

That yields two tiny bits of good news:

1. Lack of visible interface changes probably means a lack of visible behavior changes. That likely means that your Retro-style installers will probably work without change, or at least as well as the classic Windows 8 desktop supports Retro-style apps.
2. WiX and Burn won’t need to do anything to support Windows 8. OK, that’s something only a few of us need to worry about…

Coming up: More about Metro-style deployment.

What’s new?

• In a long-awaited nod to modern UIs, MSI 5.0 supports a hyperlink control. In WiX authoring, the hyperlink control using "Hyperlink" as the Control/@Type attribute:
  

  <Control Id="MyHyperlinkControl1" Height="20" Width="100" Type="Hyperlink" X="5" Y="5">
    <Text><![CDATA[<a href="http://www.joyofsetup.com/">Joy of Setup</a>]]></Text>
  </Control>

• The MsiPrint control event supports printing a rich-edit control, much like the WixUI support for printing the license agreement.
• The MsiLaunchApp control event launches an installed file, like the WixShellExec custom action.
• The MsiShortcutProperty table supports adding properties to shortcuts. WiX exposes this functionality with ShortcutProperty elements as children of the Shortcut element.
• The MsiLockPermissionsEx table supports a richer set of security settings, like WixUtilExtension’s PermissionEx element and custom actions. WiX supports MsiLockPermissionsEx with a PermissionEx element in the WiX (not WixUtilExtension) namespace. MsiLockPermissionsEx and the new PermissionEx element use security descriptor definition language (SDDL) to describe permissions. Both also support conditionally applying permissions. See Securing Resources for details.
• The MsiServiceConfig and MsiServiceConfigFailureActions tables add service-configuration options, like WixUtilExtension’s ServiceConfig element and custom actions. WiX supports the tables with a ServiceConfig element that, like the PermissionEx element, is in the WiX namespace.

1. The Google Chrome download is a svelte 474K bootstrapper that downloads the setup bits. No offline installer is available (unless it’s well-hidden).
2. Google Chrome is a "composite" setup: The guts of the application are installed by a non-MSI self-extractor. However, Google Chrome includes Google Gears, the browser add-in/library that adds a bunch of functionality for making apps-in-the-browser more powerful. The Gears in Google Chrome is installed by an MSI package. And yes, it’s built with WiX.
3. The Google Updater is no longer a LocalSystem service; instead, it starts at logon from the HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run registry key.
4. Last and absolutely not least: Google Chrome is a per-user application. It even installs in the per-user LocalAppDataFolder. (The included Google Gears is marked as "UAC compliant.")

That Google Chrome is a per-user app is amazing. Even with UAC on Windows Vista and Windows Server 2008, it’s so easy to say that "everyone’s used to needing admin privileges to install." That Google took the extra effort to limit themselves to the capabilities of a per-user app says a lot about their desire to have:

• a low-impact setup
• and absolutely no barriers to entry.

I wonder if it’s the start of a trend…

A couple of people on the wix-users mailing list have asked about using the feature action state in component conditions. There’s good news and bad news.

Good news for simple cases

The good news is that in simple cases with simple conditions, there’s probably another way to get the behavior you’re looking for. For example, one component can be assigned to multiple features, so if you’re trying to install a component when any of several features are being installed, just reference the component in all the features. MSI will install the component once, regardless of how many features reference it.

The bad news

If you want to conditionalize a component based on whether a particular feature is being installed (i.e., its action state), you can’t rely solely on the component’s condition. The Component Table doc has this to say:

The Condition field enables or disables a component only during the CostFinalize action. To enable or disable a component after CostFinalize, you must use a custom action or the DoAction ControlEvent to call MsiSetComponentState.

The CostFinalize action doc says:

The CostFinalize action queries the Condition table to determine which features are scheduled to be installed. Costing is done for each component in the Component table.

Unfortunately, it doesn’t state explicitly that the order of the two sentences is the order of execution. But, even if it did, there’s this table in Conditional Statement Syntax:

Feature and Component State Values

The following table shows where it is valid to use the feature and component operator symbols.

Operator <state>	Where this syntax is valid
$component-action	In the Condition table, and in the sequence tables, after the CostFinalize action.
&feature-action	In the Condition table, and in the sequence tables, after the CostFinalize action.
!feature-state	In the Condition table, and in the sequence tables, after the CostFinalize action.
?component-state	In the Condition table, and in the sequence tables, after the CostFinalize action.

So there are two fairly explicit strikes against being able to use a feature action state in a component condition:

• Conditional Statement Syntax doesn’t list the Component table as a valid place to use the &feature-action syntax.
• It says the syntax is valid only after CostFinalize but according to Component Table, that’s too late to use the component condition to enable/disable the component.

The Component Table says to use a “custom action or the DoAction ControlEvent to call MsiSetComponentState.” I haven’t quite deciphered whether the doc is saying to use DoAction to call a custom action from the UI or whether there’s a special, secret way of calling MsiSetComponentState via DoAction. If it’s the latter, I’m not aware of it (hence “special, secret”).

Here be dragons

Having been a writer for many years, I try to be nice about doc that is correct, even if in retrospect it’s not as helpful as it could have been. So here’s me being nice. The following sentence from Component Table easily leads a trusting reader down the wrong path:

The Condition column in the Component table accepts conditional expressions containing references to the installed states of features and components.

So here we have a sentence that contradicts the table in Conditional Statement Syntax and it’s really easy to misread the “installed state[s]” as “action states.” At the very least, it deserves clarification.

The basic idea is that you have some kind of optional functionality — like a Web site or Visual Studio integration — that you want the user to be able to enable or disable from the installer UI. (I’m assuming here that the functionality is in reality just a set of discrete components organized into a feature.)

The easiest way to get this working is to use MSI’s built-in SelectionTree control — the normal, boring, not-quite-easy-to-use feature tree that you see in most installers. That’s the approach we used with the WiX installer; in addition to features for plain sets of files, there are features for Visual Studio, Votive, and MSBuild integration.

The thrust of this question, though, is generally about using some other UI, like checkboxes or groups of radio buttons, to offer a better user experience during setup. But if you replace the SelectionTree control, you need to also replace how it manages feature states for you. Feature conditions seem like a fairly cheap way of accomplishing that, assuming you use public (i.e., all UPPERCASE) and secure (Property/@Secure=”yes”) properties to ensure they’re always passed to the MSI server for the installation execution sequence.

But it doesn’t work and as is usual with MSI, reading the SDK doc and examining a verbose log tell us why — almost.

Let’s start with the doc on the Condition table, which is the table where feature conditions are stored. A promising blurb:

The Level may be set based on any conditional statement, such as a test for platform, operating system, or a particular property setting.

A nice feature of the MSI SDK doc is that each table lists the actions that refer to the table. For the Condition table, it says:

This table is referred to when the CostFinalize action is executed.

Follow that link and you get another couple of interesting blurbs:

The CostFinalize action must be executed before starting any user interface sequence which allows the user to view or modify Feature table selections or directories.

and

The CostFinalize action queries the Condition table to determine which features are scheduled to be installed.

So far, everything sounds like it will work. It doesn’t, though, so clearly the docs aren’t telling the whole story. Verbose logs are our next step. Starting with MSI 3.1, they include entries when properties are added, changed, or deleted, so you can verify that the properties are being set correctly during the UI sequence. You can also verify that MSI is passing those properties to the execution sequence. Search the log for “Switching to server” to see the list of properties being passed. For example, from a complete install of the Windows Vista SDK version of Orca:

MSI (c) (6C:24) [14:54:54:015]: Switching to server: CUBDIR=”C:\Program Files (x86)\Orca\” ORCADIRECTORY=”C:\Program Files (x86)\Orca\” TARGETDIR=”V:\” MS.51D569E0_8A28_11D2_B962_006097C4DE24=”C:\WINNT\SysWOW64\” MS.51D569E2_8A28_11D2_B962_006097C4DE24=”C:\WINNT\SysWOW64\” MS.7EBEDD6A_AA66_11D2_B980_006097C4DE24=”C:\WINNT\SysWOW64\” MS.7EBEDD3E_AA66_11D2_B980_006097C4DE24=”C:\WINNT\SysWOW64\” INSTALLLEVEL=”1000″ COMPANYNAME=”MS” USERNAME=”Bob Arnson” CURRENTDIRECTORY=”X:\” CLIENTUILEVEL=”0″ CLIENTPROCESSID=”3180″ SOURCEDIR=”X:\” ACTION=”INSTALL” EXECUTEACTION=”INSTALL” ROOTDRIVE=”V:\” SECONDSEQUENCE=”1″ ADDLOCAL=OrcaHelp,Orca,EvalComServer,MergeModServer,CUBFiles,FullCUBFile,LogoCUBFile,XPLogoCUBFile,MMCUBFile

Notice the ADDLOCAL property setting. It’s a comma-delimited list of feature names that are to be installed. I didn’t pick them individually; instead, I used the “complete” button to say I wanted everything. The orca.msi package publishes a SetInstallLevel control event with a high install level to let MSI decide to install all features rather than using an AddLocal control event to manually list them.

Let’s assume that MSI uses the ADDLOCAL property and its friends the REMOVE and ADDSOURCE properties (among other friends) to communicate to the MSI server the feature choices the user made during the UI sequence. If you think about the many different ways the UI can implicitly and explicitly set which features get installed — from “typical” and “complete” buttons publishing SetInstallLevel control events and SelectionTree controls letting users pick and choose individual features — it makes sense that MSI would need a rich way of controlling feature installation and it makes sense for MSI to use its own properties mechanism rather than invent a new one. (And note that the same thing applies to uninstallation and reinstallation — those are all handled on a per-feature basis via properties.)

OK, so what does that have to do with feature conditions? (I’m getting there, really.) All the feature-selection property topics have this blurb:

The installer sets the Preselected Property to a value of “1″ during the resumption of a suspended installation, or when any of the above properties are specified on the command line.

Follow the Preselected link and you get this blurb:

The Preselected property indicates that features have already been selected and that the selection dialog need not be shown.

Now it’s time to enter the murky world of speculation. There’s no doc to indicate that the feature-selection properties or the Preselected property have any affect on feature-condition evaluation in CostFinalize. But I think it’s reasonable to infer that an explicit feature selection (via ADDLOCAL, for example) would override the more implicit feature-selection options available, including the Condition table and INSTALLLEVEL property.

And, to make a long story short — too late! — Carolyn, MSI Team Dev Lead, confirmed that’s the case. Feature conditions are evaluated only if no feature-selection properties are set. And, as the UI sequence converts SetInstallLevel control events, feature-selection control events, and SelectionTree control settings into the corresponding feature-selection properties, feature conditions that include properties set during the UI sequence won’t work as expected.

Note that an installation that doesn’t run the UI sequence (e.g., using the /qb command-line switch to run a basic-UI installation) can use properties set during the execute sequence in feature conditions. But the same caveat applies: If any feature-selection properties are set, feature conditions aren’t evaluated.

OK, fine, what now?

So how do you get this working? As I said near the beginning of this much-longer-than-expected tome, “if you replace the SelectionTree control, you need to also replace how it manages feature states for you.” As SelectionTree controls end up setting the feature-selection properties, you need to do the same thing, directly or indirectly. The easiest way is to publish feature-selection control events from your feature-selection dialog.

For example, the WixUI dialog set WixUI_Mondo uses SetInstallLevel published from SetupTypeDlg:

<Control Id=”CompleteButton” Type=”PushButton” X=”40″ Y=”171″ Width=”80″ Height=”17″ ToolTip=”!(loc.SetupTypeDlgCompleteButtonTooltip)” Text=”!(loc.SetupTypeDlgCompleteButton)”>
<Publish Property=”WixUI_InstallMode” Value=”InstallComplete”>1</Publish>
<Publish Event=”SetInstallLevel” Value=”1000″>1</Publish>
</Control>

If you wanted to explicitly list features, the easiest way to do so is to use an AddLocal control event with an argument of ALL to install all features locally, then use individual Remove control events to remove the features that don’t apply. Doing so covers lets the user both install and uninstall features. For example:

<Control Id=”Next” Type=”PushButton” X=”235″ Y=”243″ Width=”57″ Height=”18″ Default=”yes” Text=”&Next >”>
<Publish Event=”AddLocal” Value=”ALL”>1</Publish>
<Publish Event=”Remove” Value=”FeatureX”>NOT FEATUREX_CHECKBOX</Publish>
<Publish Event=”Remove” Value=”FeatureY”>NOT FEATUREY_CHECKBOX</Publish>
<Publish Event=”Remove” Value=”FeatureZ”>NOT FEATUREZ_CHECKBOX</Publish>
</Control>

Hope this helps understand why things aren’t always as simple as a first glance might indicate.