- Microsoft released a public preview of dotnetup, which installs and updates .NET in a user account instead of system folders.
- Microsoft's macOS and Linux announcement says it needs no root rights and suits short-lived CI workers. An unverified comment reported a privilege prompt during init.
- Leaders should ask which build jobs run with admin rights and who republishes shipped apps after monthly security updates.
Every software team makes a quiet security decision in a setup script: how much power should the machine that builds the product have? Microsoft's .NET team has just released a public preview of dotnetup. It installs .NET into a user account instead of system folders. The tool is small. The question behind it is not.
What Microsoft released
Microsoft calls dotnetup a toolchain manager. It installs, manages and updates .NET SDKs (the developer kit) and runtimes (the engine that runs finished apps). Everything goes into a user account.
The .NET team lists today's options on macOS and Linux. They include system package managers such as apt or brew, platform-specific tarballs, and scripts such as dotnet-install.sh. Microsoft says these can clash with admin permissions, spread files across root directories, or make side-by-side versions clumsy.
Microsoft compares dotnetup to rustup for Rust and nvm for Node. Both are dedicated toolchain managers.
How it works
Setup takes two steps. A bootstrap script downloads the binary. An init command then sets up the shell profile and fetches the latest stable .NET SDK. Everything lives in the user's home folder.
The tool tracks what Microsoft calls channels. A channel named 10.0 follows updates within .NET 10. A channel named latest follows the newest stable SDK, including new major releases. Exact versions stay fixed, so an install requested as 10.0.3 will not move during an update.
After an update, dotnetup removes components that nothing needs any more. It can install preview and daily runtime builds beside stable ones. It also respects global.json files, which pin the .NET version for a project.
Microsoft admits that install scripts can do much of this. It lists what dotnetup adds: tracking of what is installed, signature and checksum checks, quicker installs of many versions, and the same commands on every platform.
Why privileges matter on build machines
Consider how a system install works. It writes into folders owned by the operating system. Only an administrator may change those folders. So the installing job must run with admin rights.
A home-folder install is different. It writes only where the current user already has permission. No admin rights are needed. The job holds fewer powers.
That matters if a build job is ever compromised. An attacker who takes over a job inherits its rights. With admin rights, the attacker can reach system folders and other users' files. With user rights, the exposure is narrower, though it can still include whatever secrets and code that user can reach. This is our argument, not Microsoft's claim. The lesson is that an installer's default privilege level is a security choice, even when nobody on the team made it on purpose.
InfoWorld, which tested the tool, says .NET tools often need the highest privileges, which means administrative rights. That is InfoWorld's view of .NET installs in general. It adds that this is awkward for short-lived CI/CD runners, which load a fresh .NET instance each time a GitHub Action starts.
Microsoft's pitch speaks to this. Its announcement is framed around macOS and Linux. It says dotnetup needs no root privileges and runs without prompts. That makes it a fit for containerized or short-lived CI workers.
Limits worth knowing
This is a preview. Microsoft says dotnetup is built for non-admin, user-local use today. Support for system-level installs on Windows is planned for a future release.
One reader commenting on Microsoft's post reported a privilege prompt during dotnetup init. The comment gives no platform or detail. The post does not address it, and we have not confirmed it.
InfoWorld's tester installed it on a Windows PC, a MacBook Neo and an Ubuntu PC. The tester reported smooth installs. The tester also said dotnetup init showed install locations in the user's personal directories.
There is a trade-off. A user-local install shifts upkeep to each user or runner. Nobody patches a shared system copy for them. Microsoft notes that with system installs you may not control your ability to update. With dotnetup, an update is one command.
Microsoft also states a limit that matters to leaders. The .NET team ships security fixes in a monthly update. Updating a developer machine does not patch apps already shipped. For self-contained apps, teams must republish and redeploy with the new runtime.
Microsoft says it wants to integrate dotnetup into GitHub Actions and Azure DevOps, ideally by replacing parts of their current install-script logic. It also wants agent skills, so automated assistants reach for the tool by default. If assistants will install toolchains, the rights they run with deserve the same scrutiny as a person's.
Questions to put to your team
Ask which CI and build jobs install .NET with admin rights today, and whether they need to. Ask who owns the monthly updates. Ask how the team knows every self-contained app was republished after one. Ask whether projects pin versions with global.json, so builds stay predictable.
Treat dotnetup as a preview. Try it in a test pipeline before it touches production builds. An installer that asks for less leaves less to lose.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Microsoft (.NET team, devblogs.microsoft.com).
