WindowsDesktop reference assembly split

[nguerrera]

We do not want the reference assemblies for both WPF and Winforms to be used together unless the user has indicate that they are using both frameworks. The reason is that this causes a degradation in the design-time experience with the many similar types between both frameworks causing ambiguities and confusion.

This should be based on the existing $(UseWPF) and $(UseWindowsForms) in the WindowsDesktop SDK.

WindowsDesktop currently has assemblies in an effective diamond:

  WindowsFormsIntegration (D)
        /               \
WPF (B)            WinForms (C)
       \                 /
 Common windows utilities (A)

These could be referenced as follows:

UseWPF	UseWindowsForms	Assemblies To Reference
False	False	A (*)
True	False	A, B
False	True	A, C
True	True	A, B, C, D

(*) There is still an open question as to whether this should be an error case when neither UseXxx is used.

This will require a design for splitting the reference assets for the targeting pack for WindowsDesktop. The thinking right now is that we will replace the globbing in the bring-up PR (#2774) with a proper file list (#10537), and that each targeting pack file list will be able to designate "profiles". These "profiles" are then allowed to overlap as needed.

A FrameworkReferences should be able to address such a profile. Furthermore, this should be done by assigning a unique FrameworkReference name for each subset to retain the simplicity of just having a single string to record per FrameworkReference in NuGet/Home#7342

We could do this by picking distinct complete names for each profile:

<FrameworkReference include="Microsoft.WindowsForms" />
<FrameworkReference Include="Microsoft.WPF" />

Or by encoding the shared framework + profile in the name:

<FrameworkReference Include="Microsoft.WindowsDesktop.App|WindowsForms" />
<FrameworkReference Include="Microsoft.WindowsDesktop.App|WPF" />

[dsplaisted]

We discussed this further and landed on this:

UseWPF	UseWindowsForms	FrameworkReference
False	False	Error
True	False	Microsoft.WindowsDesktop.App|WPF
False	True	Microsoft.WindowsDesktop.App|WindowsForms
True	True	Microsoft.WindowsDesktop.App

So there will be two profiles, one for Windows Forms and one for WPF. If you want to use both, then no profile will be specified, which means all the assemblies (including the integration assembly) from the targeting pack will be referenced.

In the framework list, each assembly will list the profiles it is included in. So the Profiles attributes will look like this:

Assembly Group	Profiles attribute value
Common	WindowsForms;WPF
WPF	WPF
WindowsForms	WindowsForms
Integration	no profile attribute

[vatsan-madhavan]

/cc @dotnet/wpf-developers

[dsplaisted]

The experience should now be enabled, but it's via hard-coding which assemblies belong to which profiles in the SDK. So I'm going to leave this issue open until the profiles are added to the targeting pack manifest, and the SDK is updated to consume them.

[dsplaisted]

The last part of this has been implemented with #3304