You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Running `dotnet workload history` will print out a table of the history of workload installations or modifications for the current .NET SDK installation. The table will show key information like the date of the installation or modification, the command that was run, the workloads that were installed or modified, and the relevant version(s) for the command.
37
36
The most important piece of information is the _id_ - this can be used in the `dotnet workload update` command with the `--from-history` option (for example `dotnet workload update --from-history 3` to return to loose manifest mode) to tell the SDK to return to the state at that version. This can be useful if you want to revert to a previous state for any reason.
38
37
39
-
In this example, I had an SDK installation with the initial state of the android, ios, maccatalyst, and maui-windows workloads installed. I then ran `dotnet workload install aspire --version 9.0.100-rc.1.24453.3` to install the aspire workload and switch to workload sets mode, and the history command shows that the installation was successful. If I want to return to the previous state for any reason, I can use the _id_ from the history table to do so: `dotnet workload update --from-history 1`.
38
+
In this example, I had an SDK installation with the initial state of the android, ios, maccatalyst, and maui-windows workloads installed. I then ran `dotnet workload install aspire --version 9.0.100-rc.1.24453.3` to install the aspire workload and switch to workload sets mode, and the history command shows that the installation was successful. If I want to return to the previous state for any reason, I can use the _id_ from the history table to do so: `dotnet workload update --from-history 1`.
0 commit comments