Encoding a Custom Action Type field is relatively simple. You just need to use the different values as flags, and use that as a number. Decoding is a completely different matter. There are several conflicting rules, and various flags have the same value. To make matters more complex, the msidbCustomActionTypeBinaryData flag has a value of 0, making it impossible to use as a flag. In this very simple project, I have encoded the rules to decode.
Before reading this article, you should have a good grasp on what a MSI database is, and how to edit it using Orca. You will not be doing that with this program, but not being able to do that renders the contents of this article somewhat useless.
The rules for encoding are very simple, and they are as follows:
Action Types with values lower than 7 imply the use of msidbCustomActionTypeBinaryData. All others are not using it.
If msidbCustomActionTypeInScript is present, the values 0x100 and 0x200 are msidbCustomActionTypeRollback and msidbCustomActionTypeCommit. If it's not present, those values represent msidbCustomActionTypeFirstSequence and msidbCustomActionTypeOncePerProcess. Also, the value msidbCustomActionTypeClientRepeat should never be selected at the same time as msidbCustomActionTypeInScript.
The first 7 values are exclusive. That is, an action may be msidbCustomActionTypeDll, msidbCustomActionTypeExe, msidbCustomActionTypeTextData, msidbCustomActionTypeJScript, msidbCustomActionTypeVBScript or msidbCustomActionTypeInstall but none of them at the same time. This basically amounts to values 1 through 7 not being flags, but textual values.
The Type column was obviously grown organically, and as such it doesn't make sense as a true flag. This makes sense historically, but it makes decoding much more difficult than what it should be. I hope my little program helps with that confusion.
| You must Sign In to use this message board. | ||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||
