Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Support installing workloads in user folder

See original GitHub issue

Currently, workloads are installed in the dotnet root folder. We should also support installing them into a different, user-local folder. Benefits would include:

Support source-built .NET.
- The fallback workaround for source-built .NET would involve manually extracting various packages to specific folders, and setting some environment variables to tell the .NET SDK to load workloads from those folders.
Support installing workloads in Docker containers, where there are not permissions to write to the dotnet root folder
Better support for .NET SDKs installed via a package manager such as rpm or apt. Currently we expect that you will be able to install workloads in this case via sudo, but it may be an anti-pattern to elevate permissions to write to a folder that is owned by a package manager.

However, we do need to make sure to consider the security implications of having a root-installed .NET SDK load workloads which are installed with non-root permissions.

It’s also possible that we want to represent workloads themselves as packages managed by rpm or apt. In this case we might not need to also support installing packages to user folders. (However, for this to work, we would need to be able to source-build all workloads available on Linux in order to make them available to source-built .NET as source-built packages).

Once we have settled on this as the right approach and reviewed the security implications, we should schedule this work as soon as we are able after the currently committed .NET 6 workloads work. The current estimate is 6.0.200 though we should start as soon as we can.