You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As background - 32-bit msiexec.exe itself is subject to WOW64 32-bit in-process redirections - this is done to maximize compatibility with 32-bit software installs on the 64-bit platform - especially script, DLL and EXE custom actions for legacy packages built for as 32-bit OS.
Unfortunately when an MSI is marked as "being able to service 64-bit" it also refuses to run on 32-bit. This one I don't know the background reason for and if it had not been done, one "64-bit enabled" MSI could potentially serve both bitnesses.
Similar to a 32-bit setup.exe wrapped around a 32-bit and 64-bit MSI to provide a "single installer" experience, the chocolatey package will be able to sort out bitness specific installers automatically.
Since the existing MSI simply copies files, it is ok if the chocolatey package just installs one of them for both win 8 and win 10 ?
Joey Aiello (@joeyaiello) I am actually pointing out that when the installation technology is MSI - you don't have any other choice than to do an installer file per-bitness.
However, even if you did setup.exe, probably still best to have 2 because the only way to make one is to make the wrapper setup.exe 32-bit and Nano and many installations of Server Core won't have the 32-bit subsystem installed.
FYI - chocolatey handles the switch between bitness specific installers transparently.
Activity
mirichmo commentedon Nov 4, 2016
For each supported architecture; the way CoreCLR does it.
SteveL-MSFT commentedon Nov 4, 2016
Yes, x86 x64, etc..., but we shouldn't have win8.1 win10, etc...
DarwinJS commentedon Nov 17, 2016
Actually, due to the way the "64-bit enabled" "switch" works in MSI you must have two installers to support both bitnesses. At least that's what it says in this book: https://smile.amazon.com/Deploying-Supporting-Applications-64-bit-Windows-ebook/dp/B0098P9Z22/ ;)
As background - 32-bit msiexec.exe itself is subject to WOW64 32-bit in-process redirections - this is done to maximize compatibility with 32-bit software installs on the 64-bit platform - especially script, DLL and EXE custom actions for legacy packages built for as 32-bit OS.
Unfortunately when an MSI is marked as "being able to service 64-bit" it also refuses to run on 32-bit. This one I don't know the background reason for and if it had not been done, one "64-bit enabled" MSI could potentially serve both bitnesses.
Similar to a 32-bit setup.exe wrapped around a 32-bit and 64-bit MSI to provide a "single installer" experience, the chocolatey package will be able to sort out bitness specific installers automatically.
Since the existing MSI simply copies files, it is ok if the chocolatey package just installs one of them for both win 8 and win 10 ?
joeyaiello commentedon Jan 25, 2017
Darwin (@DarwinJS) I think you're agreeing with Steve Lee (@SteveL-MSFT) and Mike Richmond (@mirichmo) on this one: we should have a universal installer for each bitness (so two total).
DarwinJS commentedon Jan 25, 2017
Joey Aiello (@joeyaiello) I am actually pointing out that when the installation technology is MSI - you don't have any other choice than to do an installer file per-bitness.
However, even if you did setup.exe, probably still best to have 2 because the only way to make one is to make the wrapper setup.exe 32-bit and Nano and many installations of Server Core won't have the 32-bit subsystem installed.
FYI - chocolatey handles the switch between bitness specific installers transparently.
2 remaining items
joeyaiello commentedon May 16, 2017
I think this is dependent on #3747
mirichmo commentedon May 16, 2017
Yes, it is now
SteveL-MSFT commentedon Jun 7, 2017
We should do the same as #3961 which is to have a package with all dependencies
daxian-dbw commentedon Aug 29, 2017
I think now this issue depends on #4665 and #4315. I will leave this issue open and let Mike Richmond (@mirichmo) and Aditya Patwardhan (@adityapatwardhan) decide when this should be closed.
adityapatwardhan commentedon Oct 2, 2017
Dongbo Wang (@daxian-dbw) Can we close this issue? Both #4665 and #4315 are closed now?
daxian-dbw commentedon Oct 3, 2017
Aditya Patwardhan (@adityapatwardhan) Sure, closed.