我在尝试构建MSM时遇到了这个问题。显然，模块属性（以及所有标识符）在模块生成期间通过在其名称末尾添加模块GUID来重命名。例如，属性“MY_PROPERTY”被重命名为“MY_PROPERTY.803A3089_928F_46F1_BBAE_CBD39A7D6A72”（假设803A3089-928F-46F1-BBAE-CBD39A7D6A72是模块GUID）。我相信这是用于防止多个模块试图使用同名标识符之间冲突的机制。
在MSM中，我需要调用DLL自定义操作，该操作需要使用某个值设置特定属性（让我们称之为“THE_PROPERTY”）。问题是如上所述，THE_PROPERTY被重命名为THE_PROPERTY.803A3089_928F_46F1_BBAE_CBD39A7D6A72，因此自定义操作永远不会找到该属性并失败。
有什么方法可以解决这个问题吗？我正在考虑修改自定义操作，以便它试图（以某种方式）弄清楚调用它的模块的GUID。执行此操作的一种方法是查看当前操作名称，该名称还应包括GUID。但是我可以从自定义操作中获取当前操作名称吗？你能想到另一个解决方案吗？
谢谢！
答案 0 :(得分：2)
实际上，可以使用属性名称后面的模块GUID来访问合并模块中的属性。
一个好的解决方案是让自定义操作访问THE_PROPERTY.803A3089_928F_46F1_BBAE_CBD39A7D6A72而不是THE_PROPERTY。
另一种解决方案是使用type 51 custom action：
将其配置为将THE_PROPERTY设置为：
[THE_PROPERTY.803A3089_928F_46F1_BBAE_CBD39A7D6A72]
在自定义操作之前安排它，该操作显示为THE_PROPERTY
这样，合并模块属性将保存到MSI属性中，该属性具有自定义操作使用的名称。
为每个设置创作工具添加不同的51类自定义操作。如果您需要确切的说明，请提及您正在使用的设置工具。 Visual Studio不支持此功能。