Dev17 breaks ability to compile some WPF projects

[jaredpar]

Dev17 breaks WPF project builds when project files were using the Microsoft.Net.Sdk and manually listing out the XAML files in the project. For example:

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

  <PropertyGroup>
    <OutputType>WinExe</OutputType>
    <TargetFramework>net472</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <Reference Include="PresentationCore" />
    <Reference Include="PresentationFramework" />
    <!-- few more omitted for brevity -->
  </ItemGroup>

  <ItemGroup>
    <ApplicationDefinition Include="App.xaml">
      <Generator>MSBuild:Compile</Generator>
      <SubType>Designer</SubType>
    </ApplicationDefinition>
    <Page Include="MainWindow.xaml">
      <Generator>MSBuild:Compile</Generator>
      <SubType>Designer</SubType>
    </Page>
  </ItemGroup>

</Project>

This approach worked in both Dev15 and Dev16 but breaks in Dev17. I ran into this when migrating VsVim to work on top of Dev17. The break here is subtle because under the hood it's just not passing the .g.cs files to the compiler anymore. That means you end up with strange errors like in ability to access controls by name that you designed in a XAML file. If you have purely design XAML then likely you end up with compiling code but strange runtime behavior.

The repro is a bit involved here so I created a GitHub repo that contains the full code that will reproduce the issue. The README.md has instructions.

https://github.com/jaredpar/Dev17WpfUpgradeIssue

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[dsplaisted]

@ryalanms Can you take a look?

[dsplaisted]

This may be a dupe of dotnet/wpf#4515

[jaredpar]

@dsplaisted yes that does look very similar

[ryalanms]

Yes, this is a duplicate of dotnet/wpf#4515. Set ImportFrameworkWinFXTargets to true to temporarily work around it.

This can be moved to the WPF repo. Thank you for the minimal repro projects.

[Nirmal4G]

Here, the root of the problem is where the PBT that ships with Windows Desktop SDK is failing. We should look into that!

[dsplaisted]

In this case the PBT from the Windows Desktop SDK is not being imported, since the project doesn't specify the SDK or set UseWPF to true. So in the .NET 5 SDK the PDT from full MSBuild was being imported, but the props change in .NET 6 accidentally disabled that.

[Nirmal4G]

Yeah, found that it was the case. Just now, I was combing through the binlogs of the repro project mentioned above. So, we need to preserve the imports of Common targets even if UseWPF or the Windows Desktop SDK is not used! IMO, very roundabout way of doing things but fine.

You could use the Desktop SDK (projects using < v5 SDK) or set UseWPF to true but I understand that this is very well be a breaking change for existing projects!