In Wix 4 do we use x86 ('Debug|x86') in wixproj Project Files ?

[garevaul]

Hi

These are my x86 entries in the wixproj files when I Upgraded from Wix 3x to Wix 4

Do we keep them x86 entries as it is, or we can use something like 'Any Cpu', or something else?

Regards

[BMurri]

Bundles and MSIs/etc. are platform-specific (because at their root, they are either native code or processed through native code). Managed code BAs (Bundle Applications) can be AnyCPU if desired.

[BMurri]

In WiX v4, if my packages are x64, I build my bundles to be x64 (basically, match my package/bundle platforms)

[garevaul]

Hi Blair, The Application (for which the installer is to be created) is a Net 6.0-windows. So I guess all the Dlls and Nugets used in it should be for Net 6.0 or could be Net Standard 2.x So, is it safe take x64 ? Regards Bikramjeeth

…

On 7 Jun 2023, 1:00 am, at 1:00 am, Blair L Murri ***@***.***> wrote: In WiX v4, if my packages are x64, I build my bundles to be x64 (basically, match my package/bundle platforms) -- Reply to this email directly or view it on GitHub: #7532 (comment) You are receiving this because you authored the thread. Message ID: ***@***.***>

[BMurri]

Really depends on your target audience. Since most managed code is built "Any CPU" it'll run just fine on any Windows box that happens to support the targeted runtime, and the installation location doesn't matter as to bitness because it can run no matter the platform. The complications come with the deployment tech you're using.

Is your primary target running workstations/home computers or servers?

Almost all non-server Windows boxes include support for x86, whether they are x64, arm64, or whatever 32-bit installation of Windows that's still running. If you go with x64, you won't be able to be installed on arm64 devices, and vice versa, but if you go with x86 packaging you only run into the inconvenience of ending up in the Program Files (x86) directory (and possibly putting your registry keys in the WOW64 section).

As far as I know all Server Windows boxes that are still supported by Microsoft are 64-bit, and the vast majority are x64 (although I understand that arm64 Windows Server is available today). The majority of servers include support for 32-bit code, but not all SKUs include 32-bit, it can be turned off in many (all?) SKUs, and there might be some where it's available but off by default. In the environment, you may be better off offering x64 and give consideration to also offering arm64 as well.

Because a significant portion of customers using non-server boxes do not know which platform they have, x86 remains a nearly universal deployment platform you can use. Virtually all those deploying server software tend to know if they are targeting x64 or arm64 (and x64 are the lion's share of the Windows server market today), so x86 might be limiting.

[garevaul]

I am creating my application, entirely Net6-Windows & Net6.0. I am Only going to be targetting Windows 7/10/11 PC. I guess its called Home computers. I may vaguely encounter Windows 7 (32 bit version) installed somewhere. So in which case I have kept the option of installing in 'C:\Program Files (x86)'. Else the Application will always be installed in 'C:\Program Files'. So shall I have 'Debug|x86' in my wixproj files, or something else would be better? Regards Bikramjeeth

…

On 7 Jun 2023, 12:25 pm, at 12:25 pm, Blair L Murri ***@***.***> wrote: Really depends on your target audience. Since most managed code is built "Any CPU" it'll run just fine on any Windows box that happens to support the targeted runtime, and the installation location doesn't matter as to bitness because it can run no matter the platform. The complications come with the deployment tech you're using. Is your primary target running workstations/home computers or servers? Almost all non-server Windows boxes include support for x86, whether they are x64, arm64, or whatever 32-bit installation of Windows that's still running. If you go with x64, you won't be able to be installed on arm64 devices, and vice versa, but if you go with x86 packaging you only run into the inconvenience of ending up in the Program Files (x86) directory (and possibly putting your registry keys in the WOW64 section). As far as I know all Server Windows boxes that are still supported by Microsoft are 64-bit, and the vast majority are x64 (although I understand that arm64 Windows Server is available today). The majority of servers include support for 32-bit code, but not all SKUs include 32-bit, it can be turned off in many (all?) SKUs, and there might be some where it's available but off by default. In the environment, you may be better off offering x64 and give consideration to also offering arm64 as well. Because a significant portion of customers using non-server boxes do not know which platform they have, x86 remains a nearly universal deployment platform you can use. Virtually all those deploying server software tend to know if they are targeting x64 or arm64 (and x64 are the lion's share of the Windows server market today), so x86 might be limiting. -- Reply to this email directly or view it on GitHub: #7532 (reply in thread) You are receiving this because you authored the thread. Message ID: ***@***.***>

[BMurri]

Given that, I'd recommend the pair: Debug|x86 and Release|x86, for both your Package and your Bundle.

[garevaul]

Thanx a ton Blair. Really appreciate the specific narrowing down. Kind Regards Bikramjeeth

…

On 7 Jun 2023, 9:17 pm, at 9:17 pm, Blair L Murri ***@***.***> wrote: Given that, I'd recommend the pair: `Debug|x86` and `Release|x86`, for both your `Package` and your `Bundle`. -- Reply to this email directly or view it on GitHub: #7532 (reply in thread) You are receiving this because you authored the thread. Message ID: ***@***.***>