Support acquiring WindowsDesktop targets on-demand in non-Microsoft-built SDKs

[baronfel]

It looks like for Windows Desktop we don't do the pluggable mechanism for WindowsDesktop like we do for other on-demand bits of functionality like AOT compilation or SingleFile compilation. The normal pattern is that framework references and other tools can be located in a number of locations:

• in the DOTNETSDK_WORKLOAD_PACK_ROOTS directory,
• in the user's HOME/.dotnet/packs directory,
• colocated with the SDK install root in the packs directory, and finally
• resolved from NuGet

This allows for different deployments of the SDK to still provide the same dependencies and logic, just with varying amounts of pre-packaging.

The WindowsDesktop bits do not appear to follow this pattern. While we do provide the packages for the reference assemblies and win0x86, win-x64, and win-arm64 runtime implementations, the SDK hard-codes an expectation that the WindowsDesktop targets will be colocated in the SDK layout here. If we do expect users to be able to do some amount of compilation for the WindowsDesktop runtime on other platforms, then we will need to do some amount of work to make the WindowsDesktop feature set behave like our other FrameworkReferences.

cc @marcpopMSFT @dsplaisted

Attached is a binlog for anyone that would like to look at the problem.
dotnet.zip

Originally posted by @baronfel in dotnet/core#9258 (reply in thread)

[baronfel]

We should do this, but we need help from the Windows Desktop team to put the Runtime and Targeting packs into a FrameworkReference-like shape, and then the SDK could update the various KnownFrameworkReference metadata to consume the new package(s), like other FrameworkReferences are handled.

[marcpopMSFT]

@merriemcgaw I think this would need changes to the windows desktop targets. Thoughts on who we could talk to about that and determine what the cost for this would look like and work would look like?

[merriemcgaw]

That's a tricky one @marcpopMSFT. The repo is co-owned by the WinForms and WPF teams and we share responsibility for code flow. We inherited it when WindowsDesktop was added to the SDK.

Some of the items you're talking about supporting (AOT) neither team will be ready for in .NET 10. There's work to be done in runtime and in WinForms/WPF repos. Let me talk with @JeremyKuhne about his thoughts. As far as prioritization, it's not going to be high on the list immediately as we're heads down for .NET 9 and VS atm.

[marcpopMSFT]

@merriemcgaw Thanks for the reply. Let me know what you come up with for what's possible when. Note that the ask is not for AOT support but rather for the targeting and runtime packs I believe. Those are already supported on windows and for MS built linux builds of the SDK but for non-MS SDKS, there needs to be an alternative way to load them. See Chet's link to the hardcoded path to the windowsdesktop targets and then our assumption that those targets load the runtime/ref packs from hardcoded locations as well.

[marcpopMSFT]

Triage: ping @merriemcgaw @JeremyKuhne if ya'll have additional thoughts on this.

[JeremyKuhne]

If we do expect users to be able to do some amount of compilation for the WindowsDesktop runtime on other platforms

What does this mean exactly? WindowsDesktop is very specifically Windows only, what scenario requires building it elsewhere? I can't imagine any other platforms wanting to build Windows builds?

[marcpopMSFT]

mount of compilation for the WindowsDesktop runtime on other platforms

This specific issue means that customers using source build SDKs cannot build for WindowsDesktop. There is a specific customer desire to be able to compile for windows even when not running on windows (think CI servers). Does that help explain why this would be valuable for customers?

[merriemcgaw]

I can see the utility for CI servers. This wouldn't be something we could take up until the fall I think, given other work we've got on our plates. Is the customer expecting this for .NET 9? Because that seems like a big stretch at the present moment.

[baronfel]

Ideally, we'd be able to get the work backported to the .NET 8 SDKs even if it is done sometime after .NET 9 release - because that's the SDK that lost the ability to build for Windows Desktop platforms due to our removal of Microsoft-built SDKs from the Ubuntu and Red Hat platforms (among others), and it's our current LTS.

[merriemcgaw]

That makes sense. We'll have to look at the effort involved (both WinForms and WPF own this repo, but neither team did the initial packaging). Do you have an initial structure we can use as reference for what we want to create?

[baronfel]

So the WindowsDesktop Runtimes look to be all set - we track them as KnownFrameworkReferences already

I think the main thing missing is to package up the WindowsDesktop.props and .targets, and all the other logic they Import into another Known package that we could flow into ProcessFrameworkReferences and write a bit of C# to determine how and when to import it from using the existing patterns in that file.

@dsplaisted may have better specifics here though.

[marcpopMSFT]

From triage, dsplaisted had three ideas

1. Get the artifacts from the Microsoft build to build in source build. We need the folder Sdks\Microsoft.NET.Sdk.WindowsDesktop to be included in the sourcebuild build. @MichaelSimons do you know why this is excluded from the source build sdk?
2. Let targeting packs have build logic. This requires a new feature to the SDK design for targeting packs.
3. Wrap up these tasks/targets into a nuget package that could be referenced by a windows application

[marcpopMSFT]

Could be this exclusion: https:/dotnet/sdk/blob/main/src/Layout/redist/targets/BundledSdks.targets#L4

[baronfel]

Triage: kicked this back over to @merriemcgaw now that we have feedback from Daniel about the possible ways forward. Our preference is to do option 1 above (making the WindowsDesktop SDK source-buildable so that we can flow that source-built artifact into the source-built SDK).