A merge module appends its Merge Module ID to all properties, directories, etc, defined in its tables, which is good for avoiding confusing them with properties etc. from other modules.
But how can I access a property defined in a merge module from a "self-authored" custom action (DLL, InstallScript, ...)? As far as I see, I have to append the MergeModule ID by myself, which makes the custom action hard to maintain, as Merge Module IDs may change.
Are there any tricks to avoid this?
Best regards
Matthias
This is a ready-only archive of the InstallSite Forum. You cannot post any new content here. / Dies ist ein Archiv des InstallSite Forums. Hier können keine neuen Beiträge veröffentlicht werden.
Properties etc. in Merge Modules
Started by
Matthias1967
, Nov 18 2009 08:15
4 replies to this topic
Posted 18 November 2009 - 13:51
When creating a merge module, the authoring tool appends this GUID as recommended. So theoretically you could remove the GUID from the property when you create the merge module - however that's not recommended.
Do you need to change the module ID frequently?
Do you need to change the module ID frequently?
Stefan Krüger
InstallSite.org twitter facebook
Posted 18 November 2009 - 14:13
I am not quite sure how often I need to change my Module IDs. Windows Installer documentation says I have to change it as soon as the module is not backward compatible with its predecessor - which sound similar to component IDs....
We are trying to use merge modules in order to modularize the setup of our applications, moving common parts (resources as well as setup logic) to some merge modules. However those "decorated names" make it hard to pass data (properties, directories, ...) between the "main" part of the MSI and the merge modules.
In custom action code (we use InstallScript) I have inserted a line
#define MODULE_ID "<MY_MODULE_ID>"
and I use this define wherever I have to access a "decorated" property.
But there are other places in the MSI tables where identifiers get decorated by InstallShield - I can remove the GUID, but I do not have an overview whether I have done it consistently, e.g. the Directory_parent column or the "source" column for a CA. Or I would like to include some dialogs in merge modules - I cannot guarantee that properties set in these dialogs is not used outside this very module.
I would have been glad to find a workaround that could make life a bit easier here.
Or is it not recommended to put setup logic into Merge Modules?
We are trying to use merge modules in order to modularize the setup of our applications, moving common parts (resources as well as setup logic) to some merge modules. However those "decorated names" make it hard to pass data (properties, directories, ...) between the "main" part of the MSI and the merge modules.
In custom action code (we use InstallScript) I have inserted a line
#define MODULE_ID "<MY_MODULE_ID>"
and I use this define wherever I have to access a "decorated" property.
But there are other places in the MSI tables where identifiers get decorated by InstallShield - I can remove the GUID, but I do not have an overview whether I have done it consistently, e.g. the Directory_parent column or the "source" column for a CA. Or I would like to include some dialogs in merge modules - I cannot guarantee that properties set in these dialogs is not used outside this very module.
I would have been glad to find a workaround that could make life a bit easier here.
Or is it not recommended to put setup logic into Merge Modules?
Posted 18 November 2009 - 15:21
Wouldn't it be a thousand times simpler to have the MM write the property data to the registry or an INI/INF/XML file?
- Don't know why 'x' happened? Want to know why 'y' happened? ProcMon will tell you.
- Try using http://www.google.com before posting.
- I answer questions only via forums. Please appreciate the time I give here and don't send me personal emails.
- Try using http://www.google.com before posting.
- I answer questions only via forums. Please appreciate the time I give here and don't send me personal emails.
Posted 19 November 2009 - 14:37
Writing to a location outside the MSI would be a possibility, yes.
But this requires the corresponding read operations in the "main" module - and this is not only replacing MsiGetProperty by reads in existing CAs, but also new CAs just to read into "main" properties, because these values are also needed in standard actions.
Moreover, this method just replaces the built-in way of passing data.
So it does have some advantages, but I wouldn't agree with it being a thousand times easier.
Regards
Matthias
But this requires the corresponding read operations in the "main" module - and this is not only replacing MsiGetProperty by reads in existing CAs, but also new CAs just to read into "main" properties, because these values are also needed in standard actions.
Moreover, this method just replaces the built-in way of passing data.
So it does have some advantages, but I wouldn't agree with it being a thousand times easier.
Regards
Matthias