Incorrect PackageName for Microsoft.dotnetRuntime

[marcosfsch]

On version 5.0.6.30021 Microsoft.dotnetRuntime PackageName is set to "Microsoft Windows Desktop Runtime".

https://github.com/microsoft/winget-pkgs/blob/master/manifests/m/Microsoft/dotnetRuntime/5.0.6.30021/Microsoft.dotnetRuntime.locale.en-US.yaml

[ItzLevvie]

because that's what it shows up as in Control Panel:

and the name is similarly shown on the website too: https://dotnet.microsoft.com/download/dotnet/5.0.

[bearmannl]

So I got to this discussion because of an issue with the packages I came to discuss as well. Under the current versions we have .NET Core SDK and regular .NET SDK packages under the same package identifier Microsoft.dotnet (which causes issues updating the packages when installed simultaneously). Also, the preview versions are under a separate folder.

I was considering refactoring the dotnet packages to fix the above-mentioned issues, but I'd also recommend taking the new folder structure along with it. So instead of the following:

I would recommend this:

But before I get started on overhauling the entire folder structure, would really appreciate your feedback @denelon, @ItzLevvie, @OfficialEsco.

Also, would the .NET team need to get notified of these changes before the package identifiers start getting overhauled?

[OfficialEsco]

Yuuup, we need a overhaul and quality check on the .NET packages, would be nice if someone who knows what can be installed side by side setup the folder structure for the version folders.
Recently noticed .NET Runtime 3 and 5 (including x86 and x64) can be installed side by side and @KaranKad went ahead and fixed it for now.
I think its best to wait for a reply from @denelon around how they want to do it with the x86 and x64 Package.

[bearmannl]

Also note that there are several packages with arm installers, though not all.

[denelon]

I've been reaching out to some internal teams to get clarity. It appears we should treat these similar to programming languages. A package per major version is likely the best approach. I've not gotten clarity about all of the various minor versions yet.

[bearmannl]

I've been reaching out to some internal teams to get clarity. It appears we should treat these similar to programming languages. A package per major version is likely the best approach. I've not gotten clarity about all of the various minor versions yet.

I just went and installed all the SDKs for .NET 5.x and .NET Core 3.x, the following is the result:

After installing (amongst others) these packages:

Assuming a Major.Minor.Build versioning pattern for the SDKs, the packages that are capable of being installed side by side are at the Build 100 marks. so every 100/200/300/400 revision etc. can be installed next to each other, but within a 100-199 range the builds can not be installed in parallel.

The loose ends are the Visual Studio co-installed SDKs, but I suggest restructuring the SDKs and Runtimes according to this structure first:
Microsoft.dotNet.SDK.501x86
Microsoft.dotNet.SDK.502x86
Microsoft.dotNet.SDK.503x86
Microsoft.dotNet.SDK.501x64
Microsoft.dotNet.SDK.502x64
Microsoft.dotNet.SDK.503x64
Microsoft.dotNet.SDK.Preview.'similar version pattern'
Microsoft.dotNet.SDK.RC.'similar version pattern'

Microsoft.dotNet.Core.SDK.311x86
Microsoft.dotNet.Core.SDK.312x86
Microsoft.dotNet.Core.SDK.313x86
Microsoft.dotNet.Core.SDK.314x86
Microsoft.dotNet.Core.SDK.311x64
Microsoft.dotNet.Core.SDK.312x64
Microsoft.dotNet.Core.SDK.313x64
Microsoft.dotNet.Core.SDK.314x64
Microsoft.dotNet.Core.SDK.Preview.'similar version pattern'
Microsoft.dotNet.Core.SDK.RC.'similar version pattern'

Microsoft.dotNet.Runtime.'similar version pattern'
Microsoft.dotNet.Runtime.Preview.'similar version pattern'
Microsoft.dotNet.Runtime.RC.'similar version pattern'

Microsoft.dotNet.Core.Runtime.'similar version pattern'
Microsoft.dotNet.Core.Runtime.Preview.'similar version pattern'
Microsoft.dotNet.Core.Runtime.RC.'similar version pattern'

You get the gist of it for the similar version patterns, I'm hoping that the previews, RCs, and runtimes all follow a similar 100's Build version parallelism convention as the main SDKs do.

I'd be willing to open the 130'ish PRs to remove all the old and introduce all the new versions, upgrade all the manifests to 1.0, split everything based on architecture, etc... but I'm not going to get started unless there is some consensus here at least 😉

Let me know what you think @denelon.

[denelon]

@bearmannl thanks for doing all of that legwork!

I've got an e-mail thread with some of our .net experts internally. Everyone is returning from a long holiday weekend, so I might need a few days to get the right responses. I'll let you know as soon as we have consensus.

[trparky]

When is this going to be fixed?

[KaranKad]

I'll put them under Microsoft.WindowsDesktopRuntime i.e - Microsoft.WindowsDesktopRuntime-3-x64 and so on for others because it sounds similar to colsole version of dotnet runtime.

Need to update dependencies as well.

What do you think about it @ItzLevvie @jedieaston @OfficialEsco

[jedieaston]

Microsoft.WindowsDesktopRuntime.3-x64 seems like a better ID to me, but that seems fine.

I shudder every time we have to break out major versions like this, it seems like once we have package pinning in the client we'll want to merge these back into a single ID and let people just do winget install --version and have multiple versions pinned (since they are installed separately, it should work?).

[JohnMcPMS]

I shudder every time we have to break out major versions like this

If we want to properly support side-by-side installation of versions with the same ID, that is itself a large task conceptually (in that it will probably take a lot of thought/planning/verification of existing code as well as potentially in writing code). Certainly there are currently cases where it does not work (upgrade being one).

I think that there is actually a break in how these should be treated though, although I could be totally wrong as this is mostly osmosis knowledge. But it is my understanding that .Net 3/5/6 are not strictly compatible, and thus if I have 3 or 5 it does not mean that I want to upgrade to 6 on winget upgrade but instead I want the latest of 3 or 5.

I have in the last few days had the thought of generalized links between packages, one of the types being the logical "next" package in a series. In this way we could create those breakpoints between 3/5/6 while also allowing for a way to move forward if needed.

[jedieaston]

generalized links between packages

I’ve suggested this a couple other ways before but it would be really nice. They’re really common on Linux, where you can install python3 (if you want to stay up to date), or just install python3.9 if you want to get security updates for that release only.

.NET’s SDKs also install alongside each other, even if you want to upgrade (as I am aware, last time I did .NET Core I had like five bug fix releases installed simultaneously since different projects wanted different patch levels). There definitely needs to be some thinking on how winget deals with that scenario.

[bearmannl]

Just throwing this out there, what if you were to implement an overall 'parallel versions manifest' at a package level which tells winget which versions are allowed to be used in parallel, and which version paths require upgrades within those sub-versions?

Can detail more later if needed what I mean by this but basically what I'm saying is, if it is too hard to make the machine understand the distinction between these package versions, why not declare it in a human maintainable file? That way all the versions still sit neatly under one root folder per package, with versioning folder structure compliant to the main pattern, and the additional manifest handles the intricacies that the folder structure and logic can't.

[OfficialEsco]

Uhhhhm, so what is the latest approach here?

As of the manifest changes i would suggest
Microsoft.WindowsDesktopRuntime.3-x64 in combination with the Channel (3.1.100) and Pinning?

[bearmannl]

Uhhhhm, so what is the latest approach here?

I guess someone needs to finalize this now. I'm good with what you suggested.

[Trenly]

@denelon - Is this resolved now that the DotNet team has taken over their manifests?

[denelon]

Yes, I'll close this issue since the DotNet team publishes manifests with their release cadence.