#25 dark: Sequence table entries are not decompiled

Rob Mensching
dark (136)
Mattie Casper

dark seems not to know how to handle many, many
actions in the sequence tables. I believe this is because
it won't write-out any action that's not also in the
Custom Action table.

This results in dark erroneously overlooking the following
items (for example) from Orca's InstallExecuteSequence

MigrateFeatureStates 1200
PublishComponents 6200
RegisterClassInfo 4600
RegisterExtensionInfo 4700
RegisterMIMEInfo 4900
RegisterProgIdInfo 4800
AllocateRegistrySpace NOT Installed 1550
AppSearch 400
BindImage 4300
CCPSearch NOT Installed 500
CreateFolders 3700
DeleteServices VersionNT 2000
DuplicateFiles 4210
FindRelatedProducts 200
InstallODBC 5400
InstallServices VersionNT 5800
MoveFiles 3800
PatchFiles 4090
RegisterComPlus 5700
RegisterFonts 5300
RegisterTypeLibraries 5500
RemoveDuplicateFiles 3400
RemoveEnvironmentStrings 3300
RemoveExistingProducts 6700
RemoveFolders 3600
RemoveIniValues 3100
RemoveODBC 2400
RMCCPSearch NOT Installed 600
SelfRegModules 5600
SelfUnregModules 2200
SetODBCFolders 1100
StartServices VersionNT 5900
StopServices VersionNT 1900
UnregisterClassInfo 2700
UnregisterComPlus 2100
UnregisterExtensionInfo 2800
UnregisterFonts 2500
UnregisterMIMEInfo 3000
UnregisterProgIdInfo 2900
UnregisterTypeLibraries 2300
WriteEnvironmentStrings 5200
WriteIniValues 5100

Note: Many of my bugs come from dark'ing orca.msi and
then recompiling this back into an .MSI and looking at
the transform/diff between the two. This is a good way
to find little discrepancies in dark/candle/light. I imagine
the goal is that you can complete this circle and have a
functionally identical installer.


  • Mattie Casper
    Mattie Casper

    Logged In: YES

    It's possible some of these are candle's fault for not-
    reinserting them.

    Still, dark needs some sort of mechanism (perhaps a new
    command-line switch) for choosing to export the standard
    actions in the order they were in the initial install. Standard
    actions have many variations on scheduling and we'd want to
    preserve those choices somehow.

  • Rob Mensching
    Rob Mensching

    Logged In: YES

    Dark does not dump out standard actions (they are
    unnecessary) and light only adds back the standard actions
    that are necessary to get the MSI to install. This creates
    smaller MSIs that have no bloat.

  • Mattie Casper
    Mattie Casper

    Logged In: YES

    I believe there may be a misunderstanding. The bug is not
    necessarily against dark (see my earlier comment), and there
    are still major considerations outstanding.

    1. These standard actions are not actually being re-added
      by light. (Unless you just now fixed this.)
    2. Even if light was fixed to readd these actions, the original
      sequencing of those actions are lost from their first 'dark'
      import. Standard actions do not have to be sequenced in
      their suggested locations and this is commonly different for
      some standard actions (e.g. RemoveExistingProducts).

    Perhaps #2 can be resolved through a command-line switch
    that allows dark to export all standard actions with their
    same sequence to the .wxs file.

  • Peter Rilling
    Peter Rilling

    Logged In: YES

    The problem with not allowing standard actions to be
    exported is that if you decompile an MSI that was generated
    using VS.NET, then recompile again (all using Wix), the
    installation will fail. An error is always displayed indicating
    that that you do not have the correct framework version.
    Once I copied all the InstallExecutionSequence rows from the
    MSI that VS.NET built to the one the candle.exe built, my
    MSI worked. The point is that, dark.exe DOES NOT export
    everything that is necessary.

    (I previous added a bug relating specifically to the VS.NET
    msi decompile/compile issue)

  • Mike Green
    Mike Green

    Logged In: YES

    I agree with the previous issue loggers that there should be a
    way for the sequence of all sequence tables (not just
    InstallExecuteSequence) to preserve their relative
    sequencing, when passed through a complete
    dark/candle/light cycle.

    Now that dark is available, I suspect that most people will try
    the dark/candle/light cycle using an .msi file created by Visual
    Studio. Since Visual Studio doesn't use the 'standard' action
    sequence numbers then the technique of decompiling custom
    actions to "before"/"after" action names is guaranteed to be
    flawed unless the standard actions are also decompiled and
    compiled. The result will be that many people will conclude
    that dark/candle/light is broken in some way and may
    abandon it

    Request IDs 984404 and 991833 are examples of this. I've
    experienced similar problems and they seem to be caused by
    the AppSearch and LaunchConditions actions being setup by
    Visual Studio in a reversal of the standard way. This results in
    custom actions that are sequenced relative to these actions
    also ending up in the wrong sequence.

    Suggestion: Retain the existing design concept of not
    including the standard actions in the .wxs file and continue to
    automatically insert the standard actions via candle/light.
    This would continue to optimise the size of the .msi file for
    those WiX authors who are only interested in compiling via
    candle/light and are not interested in using dark.

    However, if standard actions are encountered by dark with
    non-standard sequence numbers then output all actions to
    the .wxs file and allow those actions to override the standard
    sequence numbers when compiling via candle/light. If all of
    the standard actions encountered by dark use standard
    sequence numbers then there would be no need to output
    the standard actions to the .wxs file.

  • Rob Mensching
    Rob Mensching

    Logged In: YES

    Should be fixed in v2.0.2722.0, dark now has switch to
    preserve sequence tables.