WPF Theme Assemblies are not usable under the current FrameworkReference design

[vatsan-madhavan]

See discussion in #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

[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...

[dsplaisted]

For the first use (ResourceDictionary), do these assemblies need to be referenced at compile-time at all? Or is it enough that they are available at runtime (in the shared framework)?

[vatsan-madhavan]

They don't have to be available as a ref-assembly input to the compiler, but they do have to be available at run-time - typically in $(Outdir). The developer should be able to exercise some control over where the assembly lands. I'm not sure whether this would be useful at design-time as well - i think it would be safe to assume that this is the case.

In .NET Framework, the typical pattern of use would involve something like <Reference Include="PresentationFramework.Aero" CopyLocal="True" />. Again, this pattern won't work for simultaneous references to more than one theme assembly, but since the Refeence is used as a means to acheive CopyLocal rather than as a way to crate a true reference to the assembly, workaorunds can be created to copy all theme assemblies to $(OutDir).

[nguerrera]

Really, you need to copy these into the app even if framework dependent? They aren't found in the framework? That's very odd.

[nguerrera]

Do you mean Private=true rather than CopyLocal=true?. That's the actual rendering of the Copy Local option in properties pane when persisted to the csproj. This is an extremely bizarre thing to do with a framework assembly. It will copy a reference assembly from the targeting pack, which ordinarily wouldn't load, but it won't actually be used because the runtime assembly in the GAC will be preferred. Is it really a pattern to copy these reference assemblies into the app. Do you have a sample that does this?

[vatsan-madhavan]

Where they need to be placed depends on how they are referred to in a Uri. Typically, these assemblies (and resources in them) tend to be referred to in relation to the placement of the app itself - therefore the copying.

It should be possible to reference assets in the assembly in the framework folders directly - if the app creates the right Uri for doing so.

[dsplaisted]

In .NET Core, for framework-dependent apps, there's not a good way to copy an implementation assembly from the Framework to the output folder. Also, there's probably not a good way to construct a Uri pointing to the assembly in the shared framework directory, as the path depends on the exact runtime version, and there are different folders for each different shared framework (.NET Core, WindowsDesktop, and ASP.NET Core).

Also, I don't think the Uri in the Xaml should have to be dependent on whether an app is framework-dependent or self-contained. The same app might be published both ways, or change from one way to the other, or the Xaml might be in a library that doesn't know what app it will be a part of.

Would it be possible for the Uri to just specify the simple assembly name without a path? Then WPF could do an Assembly.Load() (or similar) on that name, and it would be located correctly regardless of the deployment method of the app.

[dsplaisted]

We discussed this offline. It turns out that referencing the themes from XAML works well today in .NET Core. You can refer to them via the assembly name, and they are loaded at runtime because they are part of the Framework and are in the right deps.json file. We may want guidance on how to refer to them in XAML, but we don't need any product changes for this use case.

For using the APIs at compile time, there are these scenarios:

• Specifying a single theme assembly to reference, and using types from it
• Referencing multiple theme assemblies, specifying assembly aliases along with the references, and using the aliases in order to refer to the types

We discussed the following options for how we could support these scenarios:

Properties in the WindowsDesktop SDK

A property could be used to specify a single theme to reference, for example

<WpfTheme>Luna</WpfTheme>

If multiple themes need to be referenced, that could be expressed in a different way. Probably we would pre-bake the assembly aliases for each theme in the WindowsDesktop SDK. We might also not need to let you select specific themes if you want more than one of them, you either have none, one, or all of them. So using all of them could look like:

<UseAllWpfThemes>true</UseAllWpfThemes>

Or perhaps:

<WpfTheme>all</WpfTheme>

FrameworkReference items

This would involve having a separate "profile" for each theme assembly, accessible via an explicit FrameworkReference:

<Project Sdk="Microsoft.NET.Sdk.WindowsDesktop">

  <PropertyGroup>
    <OutputType>WinExe</OutputType>
    <TargetFramework>netcoreapp3.0</TargetFramework>
    <UseWPF>true</UseWPF>
  </PropertyGroup>

  <ItemGroup>
    <FrameworkReference Include="Microsoft.WindowsDesktop.App.Aero2" />
  </ItemGroup>

</Project>

However, it's not clear how this model should support using multiple theme assemblies. We could support assembly alias metadata on the FrameworkReference, but that doesn't seem like a great solution because all other FrameworkReferences end up referencing multiple DLLs, while an assembly alias should only apply to one assembly.

Reference items

We could also allow Reference items to resolve to assemblies inside of a targeting pack for a FrameworkReference:

<Reference Include="PresentationFramework.AeroLite" />

We could ensure that the Aliases metadata from the Reference flowed through appropriately. This solution is the one most similar to how referencing theme assemblies works on .NET Framework today. However, it opens the door to referencing arbitrary assemblies inside of a targeting pack, which may not make sense.

[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]

After the above-mentioned offline discussion with @dsplaisted & @rladuca, my preference has shifted to Reference as well - for the simple reason that it's more general.

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

This would be a very good benefit to have!

[rladuca]

I also am now favoring Reference as well. We just had a report that users would like to reference System.Printing as part of a class library and not necessarily include all of the other references. We know that something like this would be the case for WindowsBase and likely System.Xaml as well.

I think @nguerrera 's idea makes sense in light of these customer scenarios.

[dsplaisted]

One thing to take into account is reference assemblies that exist in multiple targeting packs. WindowsBase is in both Microsoft.NETCore.App as well as Microsoft.WindowsDesktop.App, but this may be the only one.

Also, for the System.Printing scenario, we should think about how the FrameworkReference would flow through project and NuGet package references. If a project only wants to reference System.Printing from the WindowsDesktop shared framework, then it probably doesn't want projects that reference (either as a package or NuGet project) to reference all of the assemblies in the shared framework.