WPF Theme Assemblies are not usable under the current FrameworkReference design

See discussion in https://github.com/dotnet/sdk/pull/3259 for context.

Background:

WPF’s theme assemblies (PresentationFramework.Aero, PresentationFramework.Aero2, PresentationFramework.AeroLite, PresentationFramework.Classic, PresentationFramework.Luna and PresentationFramework.Royale) expose the same types.

For e.g., DataGridHeaderBorder.

These assemblies can be used in two ways.

Typically, they are used as resource assemblies. i.e., they are not referenced from the project, and instead, XAML resources within them are consumed as resources using <ResourceDictionary ..>. When used this way, all of these assemblies can (and often are) used in to supply themes contextually (i.e., depending on the system theme, for e.g., or some other user preference).

Less commonly, they are directly referenced and their types are either consumed in XAML or directly in code. When used this way, only one assembly can be referenced directly. If more than one assembly needs to be referenced, namespace aliasing has to be used.

Problem:

The current SDK/FrameworkReference design in .NET Core always enables references to each of these assemblies. This makes them virtually unusable. We need a better scheme/solution.

/cc @nguerrera, @rladuca, @dsplaisted cc @dotnet/wpf-developers

[nguerrera]

My preference is Reference items. It is more general, and it also unblocks other requests. We can have the capability to resolve individual references inside framework targeting packs, and designate some assemblies as not being in any “profile” and forced to resolve this way. I would further allow a way to specify a FrameworkReference with default compilation references excluded and allow individual references to be chosen. WPF itself is (or was at least) using custom trickery to implement a NetCoreReference, which could be made first class. Corefx also ran into similar problems. I

Ideally, it would be RAR that resolved these so that it respected the search paths, etc. Conceptually, we could add the framework targeting pack ref folders as target framework directories. For perf, we probably also want to pass in the framework lists to RAR. This may require some changes to the framework lists we have or changes to RAR.

We need to think about transitivity. By downgrading to Reference, there will be no transitivity through P2P, but nuget would likely recognize it as a frameworAssembly. I am not sure if that is good or bad. In the case of the particular anti-pattern of having multiple framework assemblies with the same fully qualified name, transitivity is kind of devastating, because you start using more than one because a dependency does.

[vatsan-madhavan]

Also, here is a skeleton of a proposal from the original thread: link

The default - not reference any of them.

Put each of them in a separate newly added FrameworkReferences (Microsoft.WindowsDesktop.App.WPF.Aero, Microsoft.WindowsDesktop.App.WPF.Aero2, Microsoft.WindowsDesktop.App.WPF.Luna etc.) and allow them to be included them one at a time (UseWpfAero, UseWpfAero2 etc.).

And also provide a mechanism for enabling Aliases to each to support the scenario of more than one of them being requested simultaneously. I’m not sure what this would look like…