2

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!

Paul
  • 105
  • 1
  • 12

1 Answers1

2

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:

  • in the MSI create a property set with formatted custom action (type 51)

  • 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.

Cosmin
  • 21,216
  • 5
  • 45
  • 60
  • Thanks for your answer. Solution #1 is not good for me because this custom action DLL is generic, so I can't hardcode a GUID in it. That's why I was wondering if I could get this GUID from within the custom action (e.g. by reading the action name and then extracting the GUID out of it). Solution #2 is not good either, because I have to include logic from the MSM in the MSI. I mean, what good is an MSM if I have to include some of its logic in the MSI? By the way, I'm using WiX 3.0 on Visual Studio. – Paul Nov 01 '11 at 19:02
  • 1
    Then you're pretty much stuck. Either you find a way to pass the GUID to your custom action, or find a way to set the MSI property. There are no other solutions. Also, the MSM GUID is not related in any way with your custom action, so you can't extract it from somewhere. You could try, but it's not reliable. This GUID is usually hard-coded, for example as a custom action parameter. – Cosmin Nov 01 '11 at 20:24
  • 1
    Is it possible for the custom action to see the name of the action which is invoking it? Thanks again. – Paul Nov 01 '11 at 20:45
  • Not really. The best you can do is use a custom action which receives the installation handle and try to get the module GUID or action name from the MSI database. – Cosmin Nov 01 '11 at 20:47
  • 1
    Yes, I can access the database and query the module GUID. The problem is that there can be multiple modules, and thus multiple GUIDs, and I won't be able to tell which one is invoking the CA. Can you think of a way of getting the name of the current action? I can read the SEQUENCE property to determine which sequence table is being run, but how do I know which of their actions is being executed? Thanks. – Paul Nov 01 '11 at 21:22
  • "Yes, I can access the database and query the module GUID." It's kind of off-topic, but how do you get it? Please, could you post your code somewhere? – Salaros Feb 22 '13 at 10:25