I ran into this problem when trying to build an MSM. Apparently module properties (and all the identifiers for that matter) get renamed during the module generation by adding the module GUID at the end of its name. For example, property "MY_PROPERTY" gets renamed to "MY_PROPERTY.803A3089_928F_46F1_BBAE_CBD39A7D6A72" (assuming 803A3089-928F-46F1-BBAE-CBD39A7D6A72 is the module GUID). I believe this is the mechanism used to prevent conflicts between multiple modules trying to use identifiers with the same name.
From within the MSM I need to invoke a DLL custom action that requires a specific property to be set with some value (let's call it "THE_PROPERTY"). The problem is that THE_PROPERTY gets renamed as explained above to THE_PROPERTY.803A3089_928F_46F1_BBAE_CBD39A7D6A72, thus the custom action never finds the property and fails.
Is there any way to solve this problem? I was thinking of modifying the custom action so that it tries to figure out (somehow) the GUID of the module from which it is being invoked. One way of doing this could be by looking at the current action name, which should also include the GUID. But can I get the current action name from within the custom action? Can you think of another solution?
Thanks!
Indeed, properties inside a merge module are accessed by using the module GUID after the property name.
A good solution is to make the custom action access THE_PROPERTY.803A3089_928F_46F1_BBAE_CBD39A7D6A72 instead of THE_PROPERTY.
Another solution is to use a type 51 custom action:
configure it to set THE_PROPERTY to:
[THE_PROPERTY.803A3089_928F_46F1_BBAE_CBD39A7D6A72]
schedule it before the custom action which reads THE_PROPERTY
This way the merge module property is saved into an MSI property which has the name used by your custom action.
Type 51 custom actions are added differently for each setup authoring tool. If you need exact instructions, please mention the setup tool you are using. Visual Studio doesn't support this.