[WiX-devs] [ wix-Bugs-935799 ] dark: Sequence table entries are not decompiled

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Bugs item #935799, was opened at 2004-04-15 18:07
Message generated for change (Comment added) made by ferrysoft
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=642714&aid=935799&group_id=105970

Category: dark
Group: None
Status: Open
Resolution: Invalid
Priority: 7
Submitted By: Mattie Casper (rezand)
Assigned to: Rob Mensching (robmen)
Summary: dark: Sequence table entries are not decompiled

Initial Comment:
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 
table:

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.

----------------------------------------------------------------------

Comment By: Ferrysoft (ferrysoft)
Date: 2004-08-22 17:16

Message:
Logged In: YES 
user_id=1108842

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.

----------------------------------------------------------------------

Comment By: Peter Rilling (prilling)
Date: 2004-07-06 19:48

Message:
Logged In: YES 
user_id=836002

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)

----------------------------------------------------------------------

Comment By: Mattie Casper (rezand)
Date: 2004-04-19 12:41

Message:
Logged In: YES 
user_id=342763

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.

----------------------------------------------------------------------

Comment By: Rob Mensching (robmen)
Date: 2004-04-16 05:22

Message:
Logged In: YES 
user_id=991639

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.

----------------------------------------------------------------------

Comment By: Mattie Casper (rezand)
Date: 2004-04-15 18:29

Message:
Logged In: YES 
user_id=342763

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.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=642714&aid=935799&group_id=105970