Add ability to reference old style action names

[fk250046]

I would like to be able to mention WIX custom action names with the form WiX4ConfigXmlFile.
The approach I see is to replace this names with actual Action names the build uses: WiX4ConfigXmlFile_X86. I think that this can be done at compile stage.

[robmen]

Why do you want to reference them by a shorter name? We need more details to motivate the need for a solution and why you can't reference the CustomActions by their architecture specific name.

[fk250046]

I have several reasons:

1. I build the same project for two platforms - x86 and x64 - this is the main one that every one can face
2. I want to change condition on WIX custom actions (Probably there are another solutions to prevent running actions under particular circumstances but this one seems to me easier)
3. I want to change sequence, for example the default behavior is to put ConfigureXmlFile after DuplicateFile but I want to pot it before.

However there is a workaround for #1 - it is possible to use WIX variables but I cannot see workaround for #2 and #3

Also can you please explain the reason why platform suffix was added to every action. I understand addition of prefix.

[robmen]

All three of those can be solved by using the preprocessor. It definitely isn't as pretty. However, this problem is but one piece of a larger puzzle to normalize multi-architecture references across the WiX Toolset. Proposals need to move us toward a solution to the larger issue. Adding hacks that only target a narrow slice of the problem will simply turn into unwanted technical debt.

The preprocessor is the best solution (presented so far) because it is simple and works today.

Also can you please explain the reason why platform suffix was added to every action.

If you can make the multi-platform actions work without the suffix then that would be a change I'd be very interested in.

[barnson]

Ids have to be unique so each platform-specific custom action needs its own id.

[fyodorkor]

I am sorry, I do not understand. How it worked in WIX 3? There was support for 2 platfoms and action names were without suffix. I attached 3 files: Product.wxs, Snapshots of X86 CustomAction table and X64 CustomAction table. You can see that all action names are the same without suffix. And everything works fine.
Why WiX 4 cannot work the same way?


Product.txt

[barnson]

WiX v3 had only a couple of platform-specific custom actions for x64; almost all CAs were 32-bit x86, even in an x64 package. In WiX v4, every custom action (almost) is available in three architectures, so the WiX v3 approach won't work.

[fyodorkor]

This I understand, But now you have three different dll files compiled for each platform and they are imported to MSI during build from different locations. All functions in all dll files have the same signatures regradless of platform they were compiled. So It is possible to mantain the same signature for Custom Actions too. I use this approach for my library of custom actions: when I build for x86 I link to x86 dll and the same for x64. My code looks like this:

<Binary Id="CA" SourceFile="[CALocation]\$(var.Platform)\CustomActions.dll" />

Can you use the same approach in WIX4?

[robmen]

The binary files are bound into a binary .wixlib. The SourceFile does not contain variables once bound. Take a look at the code.

[barnson]

All of the Binary and CustomAction ids are in a single .wixlib in each extension, with all the platforms in one. That's where the uniqueness comes in.

[fyodorkor]

Sorry, xml formatting did no pass, The code:
Binary Id="CA" SourceFile="[CALocation]$(var.Platform)\CustomActions.dll"

[fyodorkor]

Sorry, I may look like a nagger but here is example of the code from WIX 4:
CustomAction Id="$(var.Prefix)SchedXmlConfig$(var.Suffix)" DllEntry="SchedXmlConfig" Execute="immediate" Return="check" SuppressModularization="yes" BinaryRef="$(var.Prefix)UtilCA$(var.Suffix)"
Here BinaryRef designates location of binary stream that is taken according to platform (this is similar to SourceFIle) but the actual DllEntry is the same for all platforms. So why the custom action should have different names? This may have sense if one package can contain binary files for several platforms but this is not the case, is not it?
I can build package as is and then rename action names to be without suffix and everything will work because DLLEntrys are the same and binary streams correspond to platform.

[robmen]

So why the custom action should have different names?

Uhh, because the BinaryRef is different.

This may have sense if one package can contain binary files for several platforms but this is not the case, is not it?

No. It is the case. The .wixlib (that ends up in the .wixext) has all architectures in it so we can send all the architectures out to the world as a single unit. That is the crux of the issue that needs resolution.

Seriously, try changing the .wxs code to make your vision work. If you find a way (without modifying the core toolset), that'd be very cool. But to do so you will need to understand bound .wixlibs first. When that makes sense, then you'll start to see the parts of the core toolset that actually need changing (assuming you don't find a way to make your vision work purely in .wxs code to begin with).

[fk250046]

Finally I start understanding the internals of WIX after couple days of debugging and I admit that my attempt to slove my problem was a quite hasty. Currently I do not see the resolution through WXS code on extension level but it indeed can be resolved on the end uder level through preprocessor. Therefore I do not think that this "required" feature needs much attension at this point.
At the same time I have several thoughts how to elimitate suffix from custom actions that do not have sense to be run cross platform e.g. to run 64 bit custom action from 32 bit package on 64 bit operating system (system configuration related actions can?). What do you think about allowing any ref attribute to keep variables that can be resolved during link time (before binding)? This attributes will not be resolved in preprocessor and will be passed through to linker untouched . Currently it is not possible becasue any ref attribute points to primary key and it is checked for validity.

[barnson]

The idea is to allow "pivots" on things like architecture that are resolved at link time without having to use the preprocessor.