Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MSI installer - redundancy in public properties #739

Open
AndrewDemski-ad-gmail-com opened this issue Oct 16, 2024 · 4 comments
Open

MSI installer - redundancy in public properties #739

AndrewDemski-ad-gmail-com opened this issue Oct 16, 2024 · 4 comments
Labels

Comments

@AndrewDemski-ad-gmail-com
Copy link
Contributor

AndrewDemski-ad-gmail-com commented Oct 16, 2024

<RegistrySearch Id="POWERSHELLEXE" Type="raw" Root="HKLM" Key="SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell" Name="Path" />

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:

<SetProperty Id="CA_PowerShell_Install" Before="CA_PowerShell_Install" Sequence="execute" Value="&quot;[%SystemDrive]\Windows\Sysnative\WindowsPowerShell\v1.0\powershell.exe&quot; -NoLogo -NonInteractive -NoProfile -ExecutionPolicy Bypass -File &quot;[INSTALLDIR]config\WAU-MSI_Actions.ps1&quot; &quot;[B_W_LIST_PATH]&quot; -InstallPath &quot;[INSTALLDIR]\&quot; -CurrentDir &quot;[CURRENTDIRECTORY]&quot;" />
<SetProperty Id="CA_PowerShell_Uninstall" Before="CA_PowerShell_Uninstall" Sequence="execute" Value="&quot;[%SystemDrive]\Windows\Sysnative\WindowsPowerShell\v1.0\powershell.exe&quot; -NoLogo -NonInteractive -NoProfile -ExecutionPolicy Bypass -File &quot;[INSTALLDIR]config\WAU-MSI_Actions.ps1&quot; &quot;[B_W_LIST_PATH]&quot; -InstallPath &quot;[INSTALLDIR]\&quot; -Upgrade &quot;#[UPGRADINGPRODUCTCODE]&quot; -Uninstall" />

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
Copy link
Owner

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

@AndrewDemski-ad-gmail-com
Copy link
Contributor Author

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

It somehow skipped my attention.

@AndrewDemski-ad-gmail-com
Copy link
Contributor Author

AndrewDemski-ad-gmail-com commented Oct 16, 2024

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

Copy link
Contributor

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

@github-actions github-actions bot added the stale label Nov 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants