Project files in .NET Core 3.0

.NET Core 3 Project Files.md

Project files in .NET Core 3.0

We currently have an initial experience for creating WPF and Windows Forms .NET Core 3 apps. This is the project file generated when you create a new WPF .NET Core app using dotnet new wpf:

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

Similarly, this is what you get when you run dotnet new winforms:

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

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

  <ItemGroup>
    <FrameworkReference Include="Microsoft.DesktopUI"/>
  </ItemGroup>

</Project>

Some elements to note:

• For the WPF app, the value of the Sdk attribute of the Project element is Microsoft.NET.Sdk.Wpf. This is how the build logic (ie Xaml compilation) is brought in to the build. Windows Forms doesn't require any extra build logic, so it uses Microsoft.NET.Sdk (the same as console apps and class libraries).
• The WPF app has explicit includes for the ApplicationDefinition and Page items. Eventually, we expect these to become implicit (ie not listed in the project file) by default, similar to how .cs source files are not listed by default in Sdk-style projects. The .NET Sdk already has implicit EmbeddedResource items for .resx files, so these are not explicitly defined in the Windows Forms project.
• The FrameworkReference to Microsoft.DesktopUI is what declares a dependency on the WPF / Windows Forms shared framework, and makes the corresponding APIs available to compile against.

Opting into app-model specific build logic

We are using a different MSBuild Sdk to opt into WPF or ASP.NET build logic. This means that it's not possible to use both of these together in the same project. It is still possible to access the APIs from both app models in the same project (via multiple FrameworkReference items). The restriction means that it won't be possible to use Xaml compilation as well as the Web globs and publishing logic in the same project. If developers are creating an app that uses both app models, they may need to factor it into two separate projects and reference one from the other.

We considered some other options for how a project would enable app-model specific build logic. See previous versions of this gist for more details.

Shared framework names

The current plan of record is for WPF and Windows Forms to both be included in the same shared framework. This means there's not an obvious good name to use for this shared framework, or for the FrameworkReference item in the project file. Currently we are using Microsoft.DesktopUI. We might change it to something like Microsoft.Windows.Desktop. However, neither of these are a great name if UWP is going to support desktop apps, but is not part of the same shared framework.

From a user experience perspective, it may make more sense to have separate shared frameworks for Windows Forms and WPF. That way the names used in the FrameworkReference items can be more obvious.

Implicit FrameworkReferences

If a project uses Microsoft.NET.Sdk.Wpf, then it should have a FrameworkReference to Microsoft.DesktopUI (or whatever we rename it to). Similarly, if it uses Microsoft.NET.Sdk.Web, it should have a FrameworkReference to Microsoft.AspNetCore.App. Because of this, we may want to make these framework references implicit. This would simplify the projects and bring them more in line with the DRY principle.

Other notes

• We expect the build logic for the different app models to ship as part of the .NET Core SDK (at least for .NET Core 3.0). However, engineering-wise, they should be separate components which are inserted into the .NET Core SDK, as opposed to all the build logic living in one big repo.