Installing MAUI workloads on Linux fails on read-only filesystems such as Flatpak

[NoTuxNoBux]

Description

For Linux there is documentation to install .NET workloads necessary for MAUI, possibly by using sudo to elevate privileges. This approach however cannot work in a Flatpak, sandboxed or otherwise read-only filesystem context even with elevated privileges.

From what I gather from other issues work is currently underway to get better support for Linux to build MAUI projects for Android and iOS, so I thought I'd report this sooner rather than later as perhaps this as this might fly under the radar otherwise.

Steps to Reproduce

1. Install VSCodium flatpak, i.e. flatpak install VSCodium.
2. Install the .NET 8 Flatpak extension, i.e. flatpak install org.freedesktop.Sdk.Extension.dotnet8.
3. For ease of use, export the DOTNET_ROOT, i.e. export DOTNET_ROOT=/usr/lib/sdk/dotnet8, in the CLI.
4. Do dotnet workload restore in a MAUI project or otherwise try installing a workload.

The result:

Installing workloads: maui-android android wasi-experimental
Unhandled exception: System.IO.IOException: Read-only file system : '/usr/lib/sdk/dotnet8/lib/metadata'
   at System.IO.FileSystem.CreateDirectory(String fullPath, UnixFileMode unixCreateMode)
   at System.IO.Directory.CreateDirectory(String path)
   at Microsoft.DotNet.Workloads.Workload.Install.WorkloadInstallerFactory.CanWriteToDotnetRoot(String dotnetDir)
   at Microsoft.DotNet.Workloads.Workload.Install.WorkloadInstallerFactory.GetWorkloadInstaller(IReporter reporter, SdkFeatureBand sdkFeatureBand, IWorkloadResolver workloadResolver, VerbosityOptions verbosity, String userProfileDir, Boolean verifySignatures, INuGetPackageDownloader nugetPackageDownloader, String dotnetDir, String tempDirPath, PackageSourceLocation packageSourceLocation, RestoreActionConfig restoreActionConfig, Boolean elevationRequired, Boolean shouldLog)
   at Microsoft.DotNet.Workloads.Workload.Install.WorkloadInstallCommand..ctor(ParseResult parseResult, IReporter reporter, IWorkloadResolverFactory workloadResolverFactory, IInstaller workloadInstaller, INuGetPackageDownloader nugetPackageDownloader, IWorkloadManifestUpdater workloadManifestUpdater, String tempDirPath, IReadOnlyCollection`1 workloadIds)
   at Microsoft.DotNet.Workloads.Workload.Restore.WorkloadRestoreCommand.Execute()
   at System.CommandLine.Invocation.InvocationPipeline.Invoke(ParseResult parseResult)
   at Microsoft.DotNet.Cli.Program.ProcessArgs(String[] args, TimeSpan startupTime, ITelemetry telemetryClient)

Link to public reproduction project repository

No response

Version with bug

8.0.60 SR6

Is this a regression from previous behavior?

No, this is something new

Last version that worked well

Unknown/Other

Affected platforms

Other (Tizen, Linux, etc. not supported by Microsoft directly)

Affected platform versions

No response

Did you find any workaround?

No, ideally .NET workloads should be installed somewhere in a persistent folder, preferably user-specific.

Even without read-only filesystems requiring elevated privileges for these workloads is poor practice because it effectively makes the .NET CLI a 'system package manager' in a way by creating files that cannot be tracked by the system's package manager.

Relevant log output

No response

[github-actions]

Hi I'm an AI powered bot that finds similar issues based off the issue title.

Please view the issues below to see if they solve your problem, and if the issue describes your problem please consider closing this one and thumbs upping the other issue to help us prioritize it. Thank you!

Open similar issues:

• workload install command in dot-net 8 doesn't work (#21583), similarity score: 0.75

Note: You can give me feedback by thumbs upping or thumbs downing this comment.

[PureWeen]

Duplicate of #40721

[NoTuxNoBux]

@PureWeen Hi, quick question: is #40721 an internal ticket? GitHub doesn't seem to make it a link and I would like to follow progress on the original issue if this is a duplicate 🙂 .