MSI installer - redundancy in public properties

[AndrewDemski-ad-gmail-com]

https://github.com/Romanitho/Winget-AutoUpdate/blob/a63a3957978a14941f0b318afe9052d4988b84cd/Sources/Wix/build.wxs#L26

We are expanding the POWERSHELLEXE property during AppSearch action, but we are not using it later and we end up with those two little monsters: https://github.com/Romanitho/Winget-AutoUpdate/blob/a63a3957978a14941f0b318afe9052d4988b84cd/Sources/Wix/build.wxs#L254-L255

Shouldn't it be consistent/reused?

reference (using file Id for ps1 script): https://stackoverflow.com/questions/14045955/run-powershell-script-from-wix-installer

[Romanitho]

I did this because of the Sysnative command. But perhaps it can be done differently.

[AndrewDemski-ad-gmail-com]

I did this because of the Sysnative command. But perhaps it can be done differently.

You are right, msi file produed by wix uses Wix4UtilCA_X86.dll which suggests x86 context. sysnative must stay.

It somehow skipped my attention.

[AndrewDemski-ad-gmail-com]

After some digging I found that: https://wixtoolset.org/docs/tools/wixext/quietexec/#architecture-specific-custom-action-dlls

The $(sys.BUILDARCHSHORT) preprocessor variable contains the suffix you need for the custom action DLL id based on the architecture of the package you're building. For example, you can use BinaryRef="Wix4UtilCA_$(sys.BUILDARCHSHORT)" in your CustomAction authoring.

There is an example of how CA XML node should look like. I think that it will remove the dependency for sysnative usage..

..at least according to that documentation: https://wixtoolset.org/docs/tools/wixext/quietexec/#64-bit-awareness

[github-actions[bot]]

This issue is stale because it has been open for 30 days with no activity.

[github-actions[bot]]

This issue was closed because it has been inactive for 14 days since being marked as stale.