If you’ve experimented with Rust, you already know how simple it is to get a basic toolchain in place, with the simple rustup command-line tool. The same tool works on Windows, macOS, and Linux, building a consistent environment that’s ready for you to pick up your favorite coding editor and start work.
It’s a simple enough tool, and one that’s done much to help popularize a new programming language. With rustup, you know what you’re getting, and you can start working on any laptop, anywhere.
Managing .NET environments is complex
Things are not so simple with .NET. Yes, it’s cross platform, running on Windows, macOS, and Linux. However, it’s not so easy to set up, often relying on third-party repositories and installers, as well as many different scripts that install different versions and their associated platforms. Have you installed ASP.NET Core? Do you need Aspire, or are you building a mobile application with MAUI? Everything has its own custom install route, which will likely differ depending on the target OS. To cap it off, .NET tools often need to be run with the highest level of privileges needed, requiring developers to have administrative rights.
None of that is particularly developer friendly, and it makes it hard to build .NET tooling into ephemeral environments like CI/CD build tools and runners, where you need to populate a hosted container for test and compilation, loading a new instance of the .NET CLI every time you fire up a GitHub Action — and having to run tooling with a much higher set of privileges than you want for an automated process. Things get more confusing when you’re maintaining an application with a current build of .NET at the same time as updating it for the next long-term release, all on the same development workstation.
With platform-specific toolchains and installation mechanisms, complexity gets in the way of coding and .NET becomes less of a priority, despite its cross-platform features and its maturity. It’s clearly time for a new approach to installing .NET, making it easier to set up, without requiring users to elevate permissions (helping keep their systems secure).
Up and running with dotnetup
That’s where the public preview of dotnetup comes into play. As the name suggests, dotnetup is the equivalent of rustup for .NET: one command that sets you up to start coding wherever you are, on a Windows PC, in a Linux container, or on a MacBook. Like rustup, dotnetup is a simple command-line tool that installs SDKs and runtimes, along with platform tooling. It’s configurable, so if you only need specific tools, you can install only them. And dotnetup supports working with different versions of .NET, keeping them isolated from each other, allowing you to dedicate specific workspaces to different .NET releases. It allows you to develop against specific versions, without affecting the global, machine-wide runtime used to run .NET applications on your PC.
As a command line tool, dotnetup looks and behaves the same wherever you run it. Installation is straightforward, using curl and the default shell on macOS and Linux, and PowerShell tools on Windows. The install scripts don’t set the paths for the CLI binary, so you need to copy and run the two lines of settings scripts output when the install completes. This installs the current signed build, though you can use a different set of scripts to install the current nightly release if you want to experiment with new features.
The same .NET environment wherever you need it
I installed dotnetup on three different systems: a Windows PC, a MacBook Neo, and a PC running Ubuntu. All three installs went smoothly, and when I ran the dotnetup init command, the tool showed where the SDKs and runtimes would be installed. It’s important to note that these locations are in a user’s own personal directories, and the SDKs and runtimes install in the current user context. It’s recommended to avoid using elevated account privileges. Microsoft is working on newer versions of dotnetup that will allow this for Windows.
I did find that different operating systems installed different versions of the .NET SDKs. Windows installed SDKs for .NET 9 and .NET 10, along with the familiar .NET runtime, a Windows desktop runtime, and ASP.NET. macOS installed only the .NET 10 SDK, and Linux did the same. I was unable to install ASP.NET on my Mac, even when explicitly trying to load it.
While it’s easiest to simply accept the defaults, dotnetup offers an interactive mode that provides options for managing the versions of .NET installed and the environment they run in, and for cleaning up unwanted or out-of-date versions. You can use the interactive mode to choose a .NET channel, like latest or long-term support version, or a specific version. In the latter case, you can choose major or minor releases, with the option of picking a feature band (say a 10.0.1xx series release) or a specific SDK.
This
[…]
Content was trimmed to protect the source. Please visit the original article for the full text.
Read the original article: