Figure out conventions for WPF Xaml files in Sdk-style projects

Currently, WPF projects for .NET Core 3.0 include explicit items for xaml files. We should include these items implicitly if possible. Though there are a bunch of different item templates (user control, page, window, etc), it looks like they all end up as Page items. So probably we can just include App.xaml as an ApplicationDefinition item, and all other xaml files as Page items.

<Project Sdk="Microsoft.NET.Sdk.Wpf">​
 ​
  <PropertyGroup>​
    <OutputType>WinExe</OutputType>​
    <TargetFramework>netcoreapp3.0</TargetFramework>​
  </PropertyGroup>​
 ​
  <ItemGroup>​
    <ApplicationDefinition Include="App.xaml" />​
    <Page Include="MainWindow.xaml" />​
  </ItemGroup>​
 ​
  <ItemGroup>​
    <FrameworkReference Include="Microsoft.DesktopUI"/>​
  </ItemGroup>​
 ​
</Project>

Proposal

In WPF SDK .props:

• Include “App.xaml” as an ApplicationDefinition item if it exists on disk, unless EnableDefaultApplicationDefinition is set to false
• Include all *.xaml files in project folder or subfolders as Page items (unless EnableDefaultPageItems property is set to false)

In WPF SDK .targets:

• Remove all Resource, Content, and None items from the Page items. IE: <Page Remove="@(Resource);@(Content);@(None)" /> (unless EnableDefaultPageItems property is set to false)

This would mean that by default, there wouldn’t be any Page or ApplicationDefinition items defined in the project file. If you wanted to use a xaml file as a different item type, you could explicitly include it in the project file, e.g. <Resource Include="MyResource.xaml" />. The WPF SDK .targets would then remove that file from the Page item.

We think that the project system currently would not understand the removal in the .targets file, which would mean that if you changed the build action of a Xaml file from Page to Resource in VS, you’d get something like the following in your project:

<Page Remove="MyResource.xaml" />
<Resource Include="MyResource.xaml" />

[vatsan-madhavan]

@dsplaisted

We should support a .xaml analogue of EnableDefaultCompileItems - something like EnableDefaultPageItems. When set to false, this would permit the developer to take full control over how the xaml files are incorporated into Page items in a project.

We would also want to enable developers to override the “App.xaml is where the ApplicationDefinition lives” presumption by explicitly setting ApplicationDefinition in the project. If this is already set, then the build system should not try to override it further.

Would you mind incorporating these into your proposal?

cc @SamBent, @rladuca

[vatsan-madhavan]

I was wondering if PresentationBuildTasks could be changed to take all of the xaml in one item set’

We should be able to investigate this anew, but this is proably not in scope for 3.0.

Some additional background FYI.

Today, we depend on the PBT (PresentationBuildTasks.dll) that is installed as part of .NET Framework, and servicing it with a feature update or a new Task is almost out of question. Even if we got permission to update it, the turnaroung time for releasing an update to it would be many months. As things stand, changing PBT that is currently in use is a non-starter.

We are porting PBT to .NET Core, and are in the process of creating a separate version. This would allow us to separate our builds away from the version that is installed as part of the .NET Framework. The porting of PBT to .NET Core is proving to be somewhat time-intensive, given the extensive differences in reflection capabilities between .NET Framework and .NET Core. We have made significant headway on this project already though. Once we have a working PBT for .NET core, we also need a new version of PBT that can be used for .NET Framework based toolchains (Visual Studio builds, for e.g.) that build .NET Core based WPF projects. This should not be too difficult, but it is still work that needs to be done yet.

All of these are prerequisites for even considering anything like adding additional intelligence in PBT to auto-detect ApplicationDefinition (or any other fundamental enhancements).

Once we have switched over successfully to a new PBT stack that is built entirely out of the .NET Core codebase for both (netcore and .NET Framework) toolchains, we can look into additional capabilities like this. I expect that stabilizing the new versions of PBT will take up most of our focus during 3.0, and we’ll be able to look into enhancements during 3.1 timeframe.