Is it possible to use a new SDK-style .csproj file for a UWP project?

Question

Has anyone successfully created a .csproj file for a UWP project that uses the new SDK-style .csproj format? I drew inspiration from this question about WPF, and that got me 90% of the way there.

After that, I began using the MSBuild.Sdk.Extras package, which gave me access to uap10.0 as a <TargetFramework>, and after a little bit of tweaking, I got it actually compiling with the following .csproj:

<Project Sdk="MSBuild.Sdk.Extras">
  <PropertyGroup>    
    <!--UWP-specific properties-->        
    <TargetPlatformVersion Condition=" '$(TargetPlatformVersion)' == '' ">10.0.17134.0</TargetPlatformVersion>
    <TargetPlatformMinVersion>10.0.17134.0</TargetPlatformMinVersion>
    <TargetFrameworks>uap10.0</TargetFrameworks>
    <OutputType>AppContainerExe</OutputType>    
    <LanguageTargets>$(MSBuildExtensionsPath)\Microsoft\WindowsXaml\v$(VisualStudioVersion)\Microsoft.Windows.UI.Xaml.CSharp.targets</LanguageTargets>
    <Platform Condition=" '$(Platform)' == '' ">x86</Platform>
    <PackageCertificateKeyFile>Test.UWP_TemporaryKey.pfx</PackageCertificateKeyFile>
  </PropertyGroup>


  <PropertyGroup Condition="'$(Configuration)'=='Debug'">
    <OutputPath>bin\x86\Debug\</OutputPath>
    <DebugType>full</DebugType>
    <PlatformTarget>x86</PlatformTarget>
    <DebugSymbols>true</DebugSymbols>
    <DefineConstants>DEBUG;TRACE;NETFX_CORE;WINDOWS_UWP</DefineConstants>
  </PropertyGroup>


  <PropertyGroup Condition="'$(Configuration)'=='Release'">
    <OutputPath>bin\x86\Release\</OutputPath>
    <DefineConstants>TRACE;NETFX_CORE;WINDOWS_UWP</DefineConstants>
    <Optimize>true</Optimize>
    <PlatformTarget>x86</PlatformTarget>
    <UseDotNetNativeToolchain>true</UseDotNetNativeToolchain>
  </PropertyGroup>  


  <ItemGroup>    

    <!--XAML stuff-->
    <ApplicationDefinition Include="App.xaml">
      <SubType>Designer</SubType>
      <Generator>MSBuild:Compile</Generator>
    </ApplicationDefinition>

    <Page Include="**\*.xaml" Exclude="App.xaml">
      <SubType>Designer</SubType>
      <Generator>MSBuild:Compile</Generator>
    </Page>        
    <Compile Update="**\*.xaml.cs" SubType="Code" DependentUpon="%(Filename)" />

     <AppxManifest Include="Package.appxmanifest">
      <SubType>Designer</SubType>
    </AppxManifest>

    <!--Local projects-->

    <!--Nuget references-->
  </ItemGroup>      

</Project>

However, a few problems remain:

• When comparing a stock UWP project, and my custom project, the custom project's compiled /bin directory doesn't seem to include dependency .dlls. (/bin dir for custom project on the left, stock UWP project on the right.)

• Visual Studio's intellisense complains about built-in XAML types not being supported.

...which leads to the resultant .exe immediately crashing on boot.

Does anyone have advice for how to get this thing to the finish line?

Answer 1

~EDIT MARK II:~ It looks like the current goal is to support .NET Core 3 (which implies new .csproj style) with the release of WinUI 3.0, which is targeting "some time in 2020" for release.

And, in case the links die, the first is a link to a WinUI GitHub issue, where the PM for the WinUI project says

Our current plan is that managed WinUI 3 apps uses .NET Core 3 instead of .NET Native at release time.

And the second link is to the WinUI project's roadmap, which says:

We're planning to release WinUI 3.0 in 2020.

and

2. Preview release: we're planning to release a more complete preview in the first half of 2020

~EDIT:~ There were some quiet announcements at Build 2019 that UWP will begin running on the .NET Core runtime with the release of .NET Core 3. It seems likely this will involve a move to the new .csproj style for UWP projects as well.

ORIGINAL POST:

It would appear that the answer for now, is no. Per Claire Novotny, the smart lady who made the MS Build SDK Extras:

You cannot currently use the SDK style projects for an application itself, only for UWP class libraries. The project system needs to support deploying and launching it in the correct way as well.

Answer 2

It seems the answer is no

https://github.com/dotnet/sdk/issues/1408

Apparently

No plans at the moment to support this.