Schedule actions based on symbols and tables

[barnson]

User story

In the long-ago, WiX scheduled standard actions based on the presence of rows in certain tables. Starting in WiX v4, that was changed to use symbols instead of tables. Good call but it means that when a compiler extension uses EnsureTable, standard actions are no longer scheduled if there are no symbols that end up matching that table.

Proposal

Check WixEnsureTableSymbols for scheduling standard actions too.

Considerations

No response

[bevanweiss]

My (perhaps naive) thoughts on this was that rather than introducing a behind the scenes link between tables and actions it could be handled explicitly in the extension. For example, the RemoveFoldersEx extension has EnsureTable("RemoveFile"), is there any reason that if it depends on the RemoveFiles standard action it couldn't also have EnsureStandardAction("InstallExecuteSequence/RemoveFiles")?

Because 'technically' the RemoveFile table might not exist in the MSI prior to execution. The extension might choose to do a bunch of magic at runtime to create the temporary table fulfilling the requirements of the (required) Standard Action.

That might be the other possibility for the extension too I guess... it could have determined at runtime that the RemoveFiles action wasn't currently scheduled, and added it in itself (although I think that would raise possible issues with when temporary tables are dropped between execution contexts).

[barnson]

WiX knows what standard actions are required for each standard table. We shouldn't duplicate that logic.

One idea that's worth investigating is whether table and standard action definitions could be fragments in the stdlib, so rather than having specific logic for ensuring tables, we could have a simple reference instead.

[bevanweiss]

WiX knows what standard actions are required for each standard table. We shouldn't duplicate that logic.

I haven't seen such within the code. Even the two Core Symbols that reference the RemoveFiles Standard Action bring it in explicitly, ala

case SymbolDefinitionType.File:
    set.Add("InstallExecuteSequence/InstallFiles");
    set.Add("InstallExecuteSequence/RemoveFiles");

https://github.com/wixtoolset/wix/blob/ce73352b1fa1d4f9cded10a0ee410f2e786bd326/src/wix/WixToolset.Core.WindowsInstaller/Bind/SequenceActionsCommand.cs#L442

Whilst having a more data structured approach like fragments in the stdlib does sound good, it feels like it would result in a similar overall use 'shape' to what I'm proposing. There would be an element for which standard table is required, like an <EnsureTable .../>, and there would either be an implicit behind the scenes connection to a Standard Action, or there would be an <EnsureStandardAction .../> element. We already have the EnsureTable, just that it's in the C# code against the compiler 'chunk' in question (i.e. Core, Ext.. ext Ext etc), and my proposal is an equivalent EnsureStandardAction to make explicit the 'dependency' on the Standard Action (in addition to that on the table).

An alternative location might be an extension of the SymbolDefinition, so that this linkage isn't pushed down to the compiler level, and is instead already on the Symbol.

Example..

public static readonly IntermediateSymbolDefinition File = new IntermediateSymbolDefinition(
  SymbolDefinitionType.File,
  new[]
  {
    new IntermediateFieldDefinition(nameof(FileSymbolFields.ComponentRef), IntermediateFieldType.String),
    ...
  },
  new[]
  {
    // empty array, we don't need to ensure to bring in tables... the symbols will handle
    // BUT... without any symbols, we might not get the InstallFile / RemoveFile tables created...
    // if all files are permanent perhaps we don't get the RemoveFile table?
  },
  new[]
  {
    something to ensure that the InstallFiles StandardAction is brought in
    something to ensure that the RemoveFiles StandardAction is brought in
  }
  ,
  typeof(FileSymbol));

[barnson]

Given a standard table, you know the standard actions that should be scheduled. The reverse is not true. Authoring can already pull in a standard action (and a standard table).

(FYI, by design, symbols aren't directly tied to MSI tables and actions. That's the job of the MSI backend.)