Utilize .NET SDK workloads infrastructure to generate runtime pack msis for Visual Studio

[marcpopMSFT]

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

Today customers targeting self-contained applications download the runtime packs at build time. This prevents offline scenarios with Visual Studio. This also impacts internal customers that install pre-release builds.

Describe the solution you'd like

Expand the existing runtime pack infrastructure used in the runtime repo today to the aspnet and windows desktop runtime packs.

• Do similar authoring to what exists in the runtime repo
  • https://github.com/dotnet/runtime/blob/78f5a9839ac7d49a3cfaa6f4015a90b1cc846fa1/src/mono/nuget/Microsoft.NET.Workload.Mono.Toolchain.Manifest/WorkloadManifest.json.in#L131
• provide better descriptions than what is in the runtime repo
• Update the VS setupauthoring (see mail thread for link to existing authoring) to add the runtime pack as an optional component
• Add the baseline manifest into the installer repo
  • https://github.com/dotnet/installer/blob/main/src/redist/targets/BundledManifests.targets

Drawbacks are that this could impact servicing codeflow in the future. The recommendation is to only produce these for windows versions that VS ships on (the idea being we still download for cross-compiling but for the RID that matches the OS, we can provide that to VS).

See email or ask marcpop for more details

Additional context

No response

[marcpopMSFT]

WD version is here. I'd recommend coordinating to do both at the same time. There's a monday sync on workloads if someone wants to come learn more.

[dougbu]

Not sure who on our team has much experience w/ workloads (I have none) and I doubt many here have used the "workloads infrastructure" mentioned here. @joperezr do you have relevant context or suggestions on who to contact❔

[joperezr]

I'm not very familiar with workloads, but I know that @terrajobst has been looking into these lately in a context of a different project so he may be able to share more info or at least points us to someone that can help.

[terrajobst]

My impression from talking to @timheuer @baronfel @dsplaisted was that workloads are currently tailored to the mobile workloads we recently added (iOS and Android in particlar). Conceptually, they are meant to represent optional components for .NET which allows us to ship a core SDK that doesn't need to be huge while also having the smarts in the tools to know when they are needed and missing and prompt the user to install them (e.g. by giving actionable errors on the CLI or by launching the acquisition experience inside the IDE).

My understanding is that workloads are really useful when you need to ship tooling (custom MSBuild SDKs, tasks, and targets), which makes sense for ASP.NET Core.

I believe originally we had a goal to provide WinForms/WPF and ASP.NET Core as workloads too but we cut it because (1) we already ship them and (2) we needed to focus on the mobile experiences. It sounds like @marcpopMSFT is suggesting we're doing them for .NET 8?

[dsplaisted]

Currently, to build a self-contained app, the correct runtime packs need to be downloaded from NuGet feeds. With internal builds of VS, this can be a pain, as the runtime packs may not be released publicly, so you have to find out what NuGet feeds you need to set up to access the runtime packs.

The workload infrastructure would allow us to include the runtime packs as optional installs in Visual Studio, which would make dogfooding and internal testing a lot easier. We already do this for the iOS and Android runtime packs, so it works and we think it would be a good idea to do it for the rest.

[marcpopMSFT]

Besides internal builds, I think this would finally enable offline mode for self-contained.

To Immo's original question, this is not a proposal to make aspnet an optional workload. This is for just the runtime packs themselves which today are always downloaded from nuget on the fly and to only do it for the current configuration within VS (ie we don't need to pre-download every runtime pack, just the local matching windows RID).

[terrajobst]

@dsplaisted why couldn't we publish the transport packages to nuget.org? My understanding is that unless you use an SDK that points to them or people manually override properties in their project file nothing will "pull" on these packages / the user won't be prompted to install them.

[mkArtakMSFT]

Thanks @marcpopMSFT. How urgent do you think this is? Are there any deadlines that we need to handle this before?

[dsplaisted]

@dsplaisted why couldn't we publish the transport packages to nuget.org? My understanding is that unless you use an SDK that points to them or people manually override properties in their project file nothing will "pull" on these packages / the user won't be prompted to install them.

There are times when an SDK is inserted into internal builds of Visual Studio (because we want to keep it as up-to-date as possible), but we can't push the corresponding runtime packs publicly yet, as that version of the runtime hasn't been released yet.

[marcpopMSFT]

Thanks @marcpopMSFT. How urgent do you think this is? Are there any deadlines that we need to handle this before?

We've lived without this for many years. We usually get a handful of reports every few months usually the weeks before a VS release. For example, we've checked in a final SDK version for 17.5 already but the runtime packs won't be available on nuget.org until next week. I suspect I'll get a few reports in the next week.

Internal customers can setup the private feed (a moderate pain) or set the RuntimeFrameworkVersion to an older version (easiest but can be forgotten) or override the KnownRuntimePack version (complicated and can be forgotten).

There is no deadline for doing this but it is a nice to have quality of life improvement for internal folks (or offline scenarios).

[MSLukeWest]

+1 to making this happen. It would be useful for internal test pipelines that run using local machine accounts to be able to have these packages downloaded by the VS installer. Bonus points if you maintain two components; one for 6.0 and one for 7.0.

[spadapet]

Another +1 to make this happen. Similar to what @MSLukeWest mentioned, we have an internal test that runs against the latest main builds and creates a self-contained project. The test can fail for many days with these errors:

The test won't have access to any internal dotnet feeds from the lab machine. So it needs a workload installed locally.

[marcpopMSFT]

@danmoseley This comes up most months as feedback from VS and moreso near the end of the release. Might be nice to explore this for 9 if there is capacity.