Switch away from using PresentationBuildTasks and Microsoft.WinFx.targets from C:\Windows

[KirillOsenkov]

For WPF projects targeting net472, we should see if it's feasible to use the modern PresentationBuildTasks and Microsoft.WinFx.targets used by modern .NET 6/7/8.

We are already importing Microsoft.WinFx.targets from:
C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Current\Bin\amd64\Microsoft.WinFX.targets

However that's just a shim that's loading the C:\Windows copy using $(MSBuildFrameworkToolsPath)\Microsoft.WinFx.targets"

Modern WPF projects import this file instead:
C:\Program Files\dotnet\sdk\8.0.100\Sdks\Microsoft.NET.Sdk.WindowsDesktop\targets\Microsoft.WinFX.targets at (163;3)

Should we see if we can import this for desktop too?

This issue is causing an insane amount of pain in our ecosystem.

Related links:

• Microsoft.NETFramework.ReferenceAssemblies Framework resolution in WPF temporary project microsoft/dotnet#1197
• Support NuGet PackageReference properly in WPF temporary assembly msbuild#2701
• SDK style projects with WPF do not import nuget props and targets msbuild#3254
• WPF project is missing nuget imports for "nested" build msbuild#3483
• Enable Source Link, Generators, and custom props/targets to work with WPF in 5.x sdk#15395
• Opt into IncludePackageReferencesDuringMarkupCompilation sdk#15465
• Revert 'Opt into IncludePackageReferencesDuringMarkupCompilation' sdk#15790
• [.NET 8 Regression] error CS1504: Source file "<Path to XAML>" could not be opened --- Could not find file sdk#34438
• Epic: Deterministic build support sourcelink#601
• PackageReference broken in WPF projects due to tmp_proj not importing Package-supplied build authoring #810
• Restore PackageReferences in temporary assembly projects to import build extensions #1056
• .NET Core 3 Preview 8 WPF Build error on custom BaseIntermediateOutputPath  #1718
• WPF tmpproj is excluding Microsoft.Net.Compilers.Toolset package  #3308
• Source Generator support for WPF project blocked? #3404
• Support PackageReferences in WPF projects #3585
• [release/5.0] Support Source Generators in WPF projects #3846
• Consolidate GenerateTemporaryTargetAssembly in to a single task/target  #3890
• WPF project build breaks because Roslyn Source Generators do not run in WPF inner-build #3963
• WPF source generator support should be on by default for .NET 6.0 #3974
• [release/5.0] Improve handling of custom paths in markup compiler #4009
• Setting IncludePackageReferencesDuringMarkupCompilation with a custom BaseIntermediateOutputPath causes build to fail #4067
• Latest Community Issues addressed and PRs merged.  #4302
• IncludePackageReferencesDuringMarkupCompilation causes excluded NuGet targets/props files to be executed #4311
• NuGet errors when compiling on command line with UWP projects and PackageReferences NuGet/Home#4515
• vsfeedback: msbuild /t:restore fails on ProjA (packageRef/.net461) w/ ref to ProjB (.netstandard) NuGet/Home#4532
• WPF with PackageReference and referencing .NET Core project produces NuGet error on build NuGet/Home#4652
• PackageReference broken in WPF projects due to tmp_proj not importing Package-supplied build authoring NuGet/Home#5894
• Support NuGet PackageReference properly in WPF temporary assembly NuGet/NuGet.Client#1786

Our ecosystem is hurting:

• Workaround for WPF PackageReference and source generators bug microsoft/CsWin32#7
• Allow Grpc.Tools to work in WPF projects grpc/grpc#22067
• WPF inner tmp_proj build doesn't generate version information Nerdbank.GitVersioning#147
• NB.GV defeats incremental build for .NET SDK style WPF projects Nerdbank.GitVersioning#175
• WPF: Build fails in wpftmp.csproj when ThisAssembly is used Nerdbank.GitVersioning#404
• Improve support of WPF projects Nerdbank.GitVersioning#405
• [Solution] Nullable attributes are not discovered in WPF projects manuelroemer/Nullable#11
• Reference problem in WPF environment manuelroemer/Nullable#20
• net5.0-windows fails because of WPF/XAML bug devlooped/ThisAssembly#14
• LibraryImport causes CS8795 #9579
• Work around failure to load correct compiler in RepoToolset roslyn-sdk#94
• C# code generator doesn't work with WPF projects. roslyn-sdk#647
• RepoToolset fails to load the correct compiler in WPF projects roslyn-tools#154
• WPF build failed pakrym/jab#41
• Source generator not running on build when imported from nuget roslyn#52427
• Unable build with WPF project. canton7/PropertyChanged.SourceGenerator#1
• WPF support novotnyllc/MSBuildSdkExtras#27
• WPF: Adding xmlns with clr-namespace to XAML breaks build with cryptic error message novotnyllc/MSBuildSdkExtras#32
• Build failing when including WPF items novotnyllc/MSBuildSdkExtras#66
• Use $(_TargetAssemblyProjectName) in Wpf.targets novotnyllc/MSBuildSdkExtras#68
• househeeping: resolve broken CI infrastructure reactiveui/ReactiveUI#1587
• XAML project fails to build in CI when building with Deterministic=true sourcelink#62
• SourceLink doesn't work well with WPF projects sourcelink#91

[KirillOsenkov]

In this file:
https://github.com/dotnet/msbuild/blob/main/src/Tasks/Microsoft.WinFx.targets

we should experiment with adding logic that, if an opt-in property is set, we import the modern WPF tasks from the SDK (C:\Program Files\dotnet\sdk\8.0.100\Sdks\Microsoft.NET.Sdk.WindowsDesktop\targets\Microsoft.WinFX.targets) instead of the legacy tasks from C:\Windows.

I suggest that the MSBuild team spikes an experiment to see how cheap this is.

[KirillOsenkov]

I forgot to mention another motivation behind this.

If we modernize WPF build tasks we'll be able to build WPF projects on Linux, which is currently not possible. Very often a codebase could have built on Linux but the WPF projects fail to build.

FYI @JanKrivanek

[rainersigwald]

The only people who can provide the support needed to do this are the owners of the WPF tooling, so moving this to dotnet/wpf. The MSBuild team will happily help out.

[ThomasGoulet73]

Am I understanding correctly that the goal of this issue is for non-SDK style projects to use the same PresentationBuildTasks and Microsoft.WinFx.targets as SDK style projects ?

IIRC, SDK style .Net Framework projects already use the PresentationBuildTasks and Microsoft.WinFx.targets from the SDK.

[KirillOsenkov]

@ThomasGoulet73 yes

[KirillOsenkov]

@ThomasGoulet73 a minor correction: another goal (that I personally care the most about) is for SDK-style projects that use legacy WPF and target desktop framework (instead of UseWpf=true and targeting modern .NET) to work using the latest markup compiler and not the legacy targets/tasks from C:\Windows