Distribute preview releases with packages.microsoft.com

[richlander]

Distribute preview releases with packages.microsoft.com

The primary model for software distribution on Linux is via a package manager. We distribute .NET via packages.microsoft.com (Microsoft's Linux package feed; supports multiple distros), but only for stable releases. This is unfortunate, since most people want to rely on the same acquisition patterns for all .NET releases, stable, preview or otherwise. When someone reads one of our exciting preview announcement blog posts, they naturally want to respond to our call to action to try out and test new features. We expect that many Linux users pass on these releases because they cannot coveniently install and use them. We've seen .NET users on Linux being frustrated by this, and it also means we're missing out on valuable preview usage on Linux that would result in earlier product feedback.

Relevant feedback:

• How can install preview version of SDKs in linux using command line
• Do you have a plan to release Linux Package Manager version of .NET core
• Travis: Unable to locate package dotnet-sdk-2.1.300-preview2-008530
• 2.1 Preview is leaking into 2.0.x Ubuntu packages
• Cannot find dotnet-runtime in ubuntu 14.04, 16.04 and debian 7 feed

Note: This feedback is old. It would be good to see some more recent feedback. Perhaps, .NET Linux users can contribute that.

A hypothesis is that we have this problem due to a lack of preview testing on Linux, not due to anything unique to Linux or package manager behavior.

We could improve this situation by doing the following:

• Fund more preview testing for Linux, specifically focused on side-by-side breaks.
• Look at side-by-side test coverage we have for Windows. Ensure we have parity coverage on Linux (macOS would be a good idea, too).
• Document side-by-side scenarios that the community can test, to help us with coverage.
• Document the risks of installing previews (and nightlies) side-by-side with stable releases.

Another hypothesis is that a package manager cannot easily separate preview from stable versions for shared components (discussed later).

We could improve this situation by offering multiple feeds/channels:

• dotnet -- stable versions
• dotnet-preview -- stable and preview versions
• dotnet-nightly -- stable, preview, and nightly versions

Details

Preview releases are available for Linux but as .tar.gz "tarball" "binaries". People can download those, so what's the problem? There are two problems:

• People want to use a package manager to install .NET, for all release types.
• Package manager and "binaries" installs don't compose, making preview "binaries" very inconvenient to use if you've already installed a stable version of .NET. Very few (if any) people are going to switch to using the "binaries" style installation for stable releases so that they can more easily use preview releases.

This problem isn't new with .NET 5. We've known about it for a long time. The primary issue is that installing a preview can negatively affect a stable release. "What? I thought .NET Core was a side-by-side install". .NET does have side-by-side installs, but there are two files that are shared across .NET versions:

• dotnet -- single instance file
• libhostfxr.so -- highest version is always used (The .NET Framework mscoreei.dll file is a direct analogue)

Note: Linux-style names are used above.

See (my WSL2 Ubuntu 20.04 instance):

rich@mazama:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 20.04 LTS
Release:        20.04
Codename:       focal
rich@mazama:~$ which dotnet
/usr/bin/dotnet
rich@mazama:~$ ls -l /usr/bin/dotnet
lrwxrwxrwx 1 root root 24 Apr 30 14:18 /usr/bin/dotnet -> /usr/share/dotnet/dotnet
rich@mazama:~$ ls /usr/share/dotnet/
LICENSE.txt  ThirdPartyNotices.txt  dotnet  host  packs  sdk  shared  templates
rich@mazama:~$ ls /usr/share/dotnet/host/fxr/5.0.0-preview.4.20227.9/
libhostfxr.so

Bugs in these preview files can negatively affect stable versions. There are other aspects of a preview install that can cause problems for an existing stable one. For example, the preview version of NuGet can have a bug that corrupts the NuGet cache in a way that the older version of NuGet is no longer able to function.

Thinking about this from a Windows and Visual Studio perspective, we see this exact situation on a daily basis. Engineers on the .NET team are encouraged to install Visual Studio on their Windows machines from multiple Visual Studio channels. For example, on my machine, I have Visual Studio Community (stable) and Visual Studio Professional (preview) installed. Most of the engineers on the team also have Visual Studio installed from an internal-only channel. Each of the Visual Studio installers, from the various channels, install a different version of the .NET SDK. The .NET version installed via the preview and internal channels is almost always a preview build. This situation isn't limited to .NET team engineers. We also require people in the .NET community to install preview builds, to use .NET previews in Visual Studio. Anyone who installs both stable and preview (or internal) Visual Studio versions is subject to a similar situation as the one that we are discussing with Linux.

This model works on Windows because we get a ton of continuous ad-hoc testing on Windows, so any breakages in hostfxr, for example, get identified quickly. hostfxr is the component most likely to introduce a break like this - the latest version of that component is used, even if it is preview. The amount of ad-hoc side-by-side testing for Linux is low, and for a distro like Alpine is close to zero. The fix for that may be to add test cases for this to our "CTI validation" test phase (FYI: CTI is Microsoft contractor testing).

[marcpopMSFT]

Old issue triage: @richlander is this still relevant?

[richlander]

Can close.

[perlun]

@richlander - should we reconsider and reopen this? There doesn't seem to be any "canonical" issue for getting this resolved AFAICT. https://github.com/dotnet/runtime/issues/3324 refers to this issue, and we then have https://github.com/dotnet/core/issues/5445 and https://github.com/dotnet/core/issues/5446.

Is perhaps https://github.com/dotnet/core/issues/5445 to be seen as the "canonical" issue for this after all? If so, feel free to keep this closed. :+1: I guess the important part is the "getting the resolved" part, not focusing so much on which issue is tracking it. :sweat_smile:

[richlander]

We talked about this again recently and came to the same conclusion. We are not going to invest in delivering preview releases via PMC. It has higher expense than we want and isn't all that high on our priority list.

[perlun]

Got it. :+1: I found out that there are indeed packages available though, just a bit more hidden away. :see_no_evil: More details: https://github.com/dotnet/core/issues/5445#issuecomment-2315070317