[New Feature]: Split Dotnet packages by architecture

[novinxy]

Description of the new feature/enhancement

Hi,

I was wondering if we could split packages per architecture:

• Microsoft.DotNet.DesktopRuntime.8
• Microsoft.DotNet.DesktopRuntime.10
• Microsoft.DotNet.Runtime.8
• Microsoft.DotNet.Runtime.10
• and other "DotNets"

Basically do similar to what has been done to VCRedist, e.g.

• Microsoft.VCRedist.2015+.arm64
• Microsoft.VCRedist.2015+.x86
• Microsoft.VCRedist.2015+.x64

Many Microsoft.DotNet* packages have issues with side-installation of packages with different architecture:

• sometimes updates of singular packages don't work correctly
• can't uninstall singular package without uninstalling second one with --all-versions
• sometimes installation is also not possible

Additionally it's not possible to install any Dotnet with x86 using DSC as there is option for that. Splitting packages would resolve this issue as architecture would be defined in the name itself.

For all those issues there were reported numerous similar issues, to this repo and winget-cli

• #5731
• #5729
• #4883
• #3010
• #5722
• #5721
• [Package Issue]: Microsoft.DotNet.* #117876
• [Package Issue]: Microsoft.DotNet.SDK.8 #183481

I believe that the best option would be to implement reliably identify architecture, and add architecture options for winget-cli. But issues against that were reported 3 years ago and where still not resolved.
Maybe in the meantime we could just create copy of those packages with architecture in the name?
We could still leave old ones and give them updates, but make copy and recommend people to use new ones.

If there is help needed with this implementation I can do that

Proposed technical implementation details (optional)

No response

[DandelionSprout]

There were some attempts with that for Microsoft.DotNet.Runtime.8.

The problem is that new versions are pushed by @dotnet-winget-bot. I don't know who is maintaining that bot (if any), I don't know who to contact to submit improvements to it, and I'd bet big time that no one in higher positions would consider it ideal to ban the bot from the repo to prevent all-archs-in-one-manifest PRs.

[ThaDaVos]

Running into the same issue - currently it's not possible to install both with Winget, it's only one or the other - but I need both as I need x86 for specific NativeAoT projects and the x64 for all other projects

[novinxy]

I did some quick screening trough those package update made by dotnet-winget-bot to find people that might know something

@SpecterShell
@stephengillie

Do you guys know something about this bot and who to contact?

Sorry if I added you unnecesarily

[SpecterShell]

I'm unrelated to dotnet-winget-bot. I think it is related to this issue: #60134