dotnet-workload-install(1)

💖 dotnet-workload-install — the manual, but make it cute 💖

okay bestie, so this is the page for dotnet-workload-install(1) from the .NET Documentation manual. yes it's a real manpage, yes it's giving very "I live in your terminal", and yes I'm about to make it make sense. sit down, grab a boba, let's go 🧋✨

This article applies to: ✔️ .NET 6 SDK and later versions

---

✨ NAME ✨

dotnet-workload-install — installs optional workloads. that's it, that's the whole vibe. it installs stuff for you 💅

---

🌸 SYNOPSIS 🌸

dotnet workload install <WORKLOAD_ID>...
    [--configfile <FILE>] [--disable-parallel]
    [--ignore-failed-sources] [--include-previews] [--interactive]
    [--no-cache] [--skip-manifest-update] [--source <SOURCE>]
    [--temp-dir <PATH>] [-v|--verbosity <LEVEL>] [--version <VERSION>]

dotnet workload install -?|-h|--help

like, that's the shape of it. a bunch of workload IDs and then a whole wardrobe of optional flags 🎀

---

🦋 DESCRIPTION 🦋

so the dotnet workload install command installs one or more optional workloads. and "optional workloads" just means extra stuff you can layer on top of the .NET SDK so it can handle different kinds of apps — think .NET MAUI and Blazor WebAssembly AOT.

(that Blazor AOT link, if you wanna go down the rabbit hole: https://devblogs.microsoft.com/aspnet/asp-net-core-updates-in-net-6-preview-4/#blazor-webassembly-ahead-of-time-aot-compilation)

when the command is in workload-set update mode, the workload versions it installs:

• are from the latest workload set, or from a workload set version that you specified in a global.json or with the --version option.
• might not be the latest version available of each individual workload. for example, the install command won't install a newer workload set if you previously used the --version flag. the way it holds a grudge... 💀

for more info, see .NET SDK workload sets. and heads up: workload-set update mode is available since 8.0.400 SDK.

use dotnet workload search to see what workloads are even available to install. window shopping, but for workloads 🛍️

---

🫶 When to run elevated

okay this part matters, listen up.

for macOS and Linux SDK installations that live in a protected directory, the command needs to run elevated (use the sudo command). so yes, sudo is your friend here.

on Windows, the command doesn't need to run elevated even if the SDK is installed in the Program Files directory. for Windows, the command uses MSI installers for that location. no admin drama required 🪟✨

---

🌈 Results vary by SDK version

the dotnet workload commands operate in the context of specific SDK versions.

suppose you have both .NET 6.0.100 SDK and .NET 6.0.200 SDK installed. the dotnet workload commands will give different results depending on which SDK version you select. and this behavior applies to major and minor version and feature band differences — not to patch version differences. for example, .NET SDK 6.0.101 and 6.0.102 give the same results, whereas 6.0.100 and 6.0.200 give different results. you can specify the SDK version by using the global.json file. so basically: know which SDK you're standing in, bestie 👑

---

🎀 Advertising manifests

the names and versions of the assets that a workload installation requires are maintained in manifests. by default, the dotnet workload install command downloads the latest available manifests before it installs a workload. the local copy of a manifest then provides the info needed to find and download the assets for a workload.

the dotnet workload list command compares the versions of installed workloads with the currently available versions. when it finds that a version newer than the installed version is available, it advertises that fact in the command output. these newer-version notifications in dotnet workload list are available starting in .NET 6.

to enable these notifications, the latest available versions of the manifests are downloaded and stored as advertising manifests. these downloads happen asynchronously in the background when any of the following commands are run:

• dotnet build
• dotnet pack
• dotnet publish
• dotnet restore
• dotnet run
• dotnet test

if a command finishes before the manifest download finishes, the download is stopped. the download is tried again the next time one of these commands is run. you can set environment variables to disable these background downloads or control their frequency. by default, they don't happen more than once a day. very "I'll text you later" of them, honestly 🙈

you can prevent the dotnet workload install command from doing manifest downloads by using the --skip-manifest-update option.

the dotnet workload update command also downloads advertising manifests. the downloads are required to learn if an update is available, so there is no option to prevent them from running. however, you can use the --advertising-manifests-only option to skip workload updates and only do the manifest downloads. this option is available starting in .NET 6.

---

💜 ARGUMENTS 💜

• WORKLOAD_ID... — the workload ID, or multiple IDs, to install. use dotnet workload search to learn what workloads are available. plural IDs? plural slay ✨

---

🔥 OPTIONS 🔥

here's the full menu, no substitutions, no skips:

• --configfile <FILE> — the NuGet configuration file (nuget.config) to use. if specified, only the settings from this file will be used. if not specified, the hierarchy of configuration files from the current directory will be used. for more information, see Common NuGet Configurations.
• --disable-parallel — prevents restoring multiple projects in parallel. one at a time, babes 🚦
• -?, -h, --help — prints out a description of how to use the command. it's the "help me" button, use it liberally.
• --ignore-failed-sources — treats package source failures as warnings. not a crisis, just a lil note 🫶
• --include-previews — allows prerelease workload manifests. living on the edge, I respect it.
• --interactive — allows the command to stop and wait for user input or action. for example, to complete authentication. it will literally pause and wait for you, so don't walk away 🧍♀️
• --no-cache — prevents caching of packages and http requests. fresh every time, no leftovers.
• --skip-manifest-update — skip updating the workload manifests. the workload manifests define what assets and versions need to be installed for each workload.
• -s, --source <SOURCE> — specifies the URI of the NuGet package source to use. this setting overrides all of the sources specified in the nuget.config files. multiple sources can be provided by specifying this option multiple times. stack 'em 💅
• --temp-dir <PATH> — specify the temporary directory used to download and extract NuGet packages (must be secure). key word: secure. do not play with that one.
• -v, --verbosity <LEVEL> — sets the verbosity level of the command. allowed values are q[uiet], m[inimal], n[ormal], d[etailed], and diag[nostic]. the default is minimal. if you specify detailed or diagnostic verbosity, the command displays information about the NuGet packages that it downloads.
• --version — the workload set version to install or update to. if you specify the workload-set version in global.json, you can't use the --version option to specify the workload-set version. to make it possible to use the --version option in that case, run the command outside of the path containing the global.json file. available since 8.0.400 SDK. for more information, see .NET SDK workload sets.

---

⭐ EXAMPLES ⭐

• install the maui workload:

dotnet workload install maui

• install the maui-android and maui-ios workloads:

dotnet workload install maui-android maui-ios

---

heads up bestie: the --temp-dir path must be secure, and if your workload-set version is pinned in global.json, --version will not work from inside that directory. no cap, those are the rules 💀

---

and that's the whole page, you ate it, you understood it, main character energy confirmed 👑 this cutie was documented by the .NET Documentation crew and the page itself is dated 2025-06-13, filed under dotnet-workload-install(1). go install something iconic 🦋💖