.NET 9 and 10 both provide `microsoft.net.sdk.aspire` 8.2.2

[mateusrodrigues]

Describe the Bug

We're currently experimenting with packaging .NET 10 on Ubuntu and have encountered an issue when attempting to install .NET 9 and .NET 10 Preview 3 side by side. The problem arises due to a conflict involving the microsoft.net.sdk.aspire component.

Both dotnet-sdk-9.0 and dotnet-sdk-10.0 attempt to install the same set of files to the path:
$DOTNET_ROOT/sdk-manifests/8.0.100/microsoft.net.sdk.aspire/8.2.2.

As a result, apt fails due to file collisions when installing both side-by-side.

Preparing to unpack .../08-dotnet-sdk-10.0_10.0.100~preview3-0ubuntu1~25.04.1~ppa1_amd64.deb ...                        
Unpacking dotnet-sdk-10.0 (10.0.100~preview3-0ubuntu1~25.04.1~ppa1) ...                                                 
dpkg: error processing archive /tmp/apt-dpkg-install-Qeman8/08-dotnet-sdk-10.0_10.0.100~preview3-0ubuntu1~25.04.1~ppa1_a
md64.deb (--unpack):                                                                                                    
 trying to overwrite '/usr/lib/dotnet/sdk-manifests/8.0.100/microsoft.net.sdk.aspire/8.2.2/WorkloadManifest.Aspire.targe
ts', which is also in package dotnet-sdk-9.0 (9.0.105-0ubuntu1)                                                         
dmesg: read kernel buffer failed: Operation not permitted

Note: This might be an expected non-issue on the SDK side. If that's the case, distro maintainers should look into how to break the Aspire binaries off to a separate package to avoid the conflict.

Steps to Reproduce

On a Ubuntu 24.04 box:

sudo add-apt-repository ppa:dotnet/backports
sudo apt install dotnet9
sudo add-apt-repository ppa:dotnet/previews
sudo apt install dotnet10

[dviererbe]

To be precise, this are the files the dotnet-sdk-9.0 and dotnet-sdk-10.0 package have in common and collide:

./usr/lib/dotnet/sdk-manifests/8.0.100/microsoft.net.sdk.aspire/8.2.2/WorkloadManifest.Aspire.targets
./usr/lib/dotnet/sdk-manifests/8.0.100/microsoft.net.sdk.aspire/8.2.2/WorkloadManifest.json
./usr/lib/dotnet/sdk-manifests/8.0.100/microsoft.net.sdk.aspire/8.2.2/WorkloadManifest.targets

The dotnet-sdk-8.0 package does not encounter this issue, because it apparently ships a preview version, which is odd too. Is this to be expected?

./usr/lib/dotnet/sdk-manifests/8.0.100/microsoft.net.sdk.aspire/8.0.0-preview.1.23557.2/WorkloadManifest.json
./usr/lib/dotnet/sdk-manifests/8.0.100/microsoft.net.sdk.aspire/8.0.0-preview.1.23557.2/WorkloadManifest.targets

A simple fix for solving this issue is creating a new binary package named something like dotnet-sdk-$MAJOR.$MINOR-aspire that contains the conflicting files and specify the conflicting/replacement relationships between these packages, similar to the .NET host.

Here are examples how they could be defined in debian/control:

Package: dotnet-sdk-8.0-aspire

Package: dotnet-sdk-9.0-aspire
Conflicts: dotnet-sdk-8.0-aspire
Replaces: dotnet-sdk-8.0-aspire
Provides: dotnet-sdk-8.0-aspire

Package: dotnet-sdk-10.0-aspire
Conflicts: dotnet-sdk-8.0-aspire, dotnet-sdk-9.0-aspire
Replaces: dotnet-sdk-8.0-aspire, dotnet-sdk-9.0-aspire
Provides: dotnet-sdk-8.0-aspire, dotnet-sdk-9.0-aspire

[dviererbe]

@omajid did you experience similar issues on RHEL or Fedora?

[MichaelSimons]

Both dotnet-sdk-9.0 and dotnet-sdk-10.0 attempt to install the same set of files to the path:
$DOTNET_ROOT/sdk-manifests/8.0.100/microsoft.net.sdk.aspire/8.2.2.

@dviererbe - Why are both 9.0 and 10.0 installing to the sdk-manifests/8.0.100 folder?

It is currently expected that 9.0 and 10.0 have the same aspire version. It will be going away with #4735. That said, I want to understand the underlying issue here because it is possible multiple sdk versions can ship the same versions of subcomponents especially across multiple feature bands for (e.g 10.0.1xx and 10.0.2xx).

[dviererbe]

@MichaelSimons

@dviererbe - Why are both 9.0 and 10.0 installing to the sdk-manifests/8.0.100 folder?

The conflicting files are both build outputs when building the .NET 9 and 10 SDK. We simply copy the files to the installation target (see here). To be honest there was no deeper thought about these file on my side. Therefore, if these files should be excluded or moved to a different path, then we can do that.

It is currently expected that 9.0 and 10.0 have the same aspire version.

Question: Does this mean that that we should manipulate the path of the files to match the SDK version? Something like this:

-$DOTNET_ROOT/sdk-manifests/8.0.100/microsoft.net.sdk.aspire/8.2.2
+$DOTNET_ROOT/sdk-manifests/$DOTNET_MAJOR.$DOTNET_MINOR.100/microsoft.net.sdk.aspire/8.2.2

---

Question: Is it to be expected that the .NET 8 SDK just builds version 8.0.0-preview.1.23557.2 instead of 8.2.2 (like .NET 9/10)?

[omajid]

@omajid did you experience similar issues on RHEL or Fedora?

I noticed the possible SDK version leading to a conflict back in 9.0: https://pagure.io/dotnet-sig/dotnet9.0/blob/main/f/dotnet9.0.spec#_830. I forgot to follow-up on it.

The directory also exists in 10.0 right now.

dnf/rpm are okay with identical files being installed by two packages, so this doesn't break (yet) for us.

We simply copy the files to the installation target (see here). To be honest there was no deeper thought about these file on my side. Therefore, if these files should be excluded or moved to a different path, then we can do that.

Same for us.

[MichaelSimons]

Question: Does this mean that that we should manipulate the path of the files to match the SDK version? Something like this:

Looking at this deeper, 8.0.100 is right for this aspire component.

Question: Is it to be expected that the .NET 8 SDK just builds version 8.0.0-preview.1.23557.2 instead of 8.2.2 (like .NET 9/10)?

Yes that is expected.

[MichaelSimons]

@joperezr - Do you have an ETA yet of when the Aspire workload will be removed from .NET 10. Here is another instance where it is causing issues.

[MichaelSimons]

[Triage] Closing as duplicate of #4735 as removing aspire will address this.