Visual Studio and MSBuild net4x TFM builds use legacy PresentationBuildTasks.dll when using WindowsDesktop SDK

[vatsan-madhavan]

When building WPF projects targeting net4x TFM and using the WindowsDesktop SDK in Visual Studio or MSBuild, legacy PresentationBuildTasks.dll (i.e, the one that shipped with .NET Framework, and installed in GAC) is used for Markup Compilation.

This behavior is wrong - and not what is intended. The correct behavior is to use the copy of PresentationBuildTasks.dll that ships with the .NET Core SDK under 3.0.100\SDKs\Microsoft.NET.Sdk.WindowsDesktop\tools\net472\PresentationBuildTasks.dll

Repro:

# Launch Visual Studio 2019 Developer Command Prompt
dotnet new globaljson --sdk-version 3.0.100
dotnet new wpf --target-framework-override net472
msbuild /bl 
// Inspect the logs; Search for $task MarkupCompilePass1
// Observed: PresentationBuildTasks, Version 4.0.0.0 is used from the .NET Framework GAC  
// Expected: 3.0.100\SDKs\Microsoft.NET.Sdk.WindowsDesktop\tools\net472\PresentationBuildTasks.dll from .NET Core 3.0 SDK should be used

[nguerrera]

I think the description here should be "When building WPF projects targeting .NET Framework using the WindowsDesktop SDK", correct?

[vatsan-madhavan]

Yes, that’s it.

[vatsan-madhavan]

@nguerrera I was right the first time around. This applies to all TFM's - not just netfx TFM's. I just verified it experimentally. I don't know why I emphasized net472 TFM in my repro instructions - but that was certainly misleading... the only thing that matters is that $(MSBuildRuntimeType)==Full, which in turn ought to act as in index into net472\PresentationBuildTasks.dll but doesn't (which is the essence of the bug).

When building in MSBuild, .NET Framework's copy of WinFX.targets comes into play, which muddies the waters, along with the unexpected 'first one wins' behavior of UsingTask.. and so here we are.

[nguerrera]

I don't know how that could be because desktop PresentationBuildTasks.dll doesn't work targeting core. Checking.

[nguerrera]

My understanding was that the .NETFramework Microsoft.WinFX.targets would not be imported in a Core project.

[nguerrera]

λ dotnet new global.json --sdk-version 3.0.100
λ dotnet new wpf  
λ msbuild /bl

[nguerrera]

It looks to me that in fact you do have to target .NET Framework to see the issue.

[nguerrera]

This import doesn't happen when targeting core:

https://github.com/microsoft/msbuild/blob/3af6804637c057bf46bddccf23f1ede027885088/src/Tasks/Microsoft.Common.CurrentVersion.targets#L6057

[nguerrera]

Therefore, neither does this that would be under that:

https://github.com/microsoft/msbuild/blob/3af6804637c057bf46bddccf23f1ede027885088/src/Tasks/Microsoft.NETFramework.CurrentVersion.targets#L131

Therefore, there is nothing to override and the UsingTasks in the SDK work as expected when targeting core.

[nguerrera]

If you ever try to build for core using in-box netfx PBT, it will fail:

I hacked it now to do so and you get this:

"D:\Temp\pbt\pbt.csproj" (default target) (1) ->
(MarkupCompilePass1 target) ->
  C:\Program Files\dotnet\sdk\3.0.100\Sdks\Microsoft.NET.Sdk.WindowsDesktop\targets\Microsoft.WinFX.targets(243,9): err or MC1000: Unknown build error, 'Could not load type 'System.Object' from assembly 'System.Runtime, Version=4.2.1.0, Cu lture=neutral, PublicKeyToken=b03f5f7f11d50a3a' because the parent does not exist.'  [D:\Temp\pbt\pbt.csproj]

If this bug were impacting projects targeting core, we'd be unable to build them in VS, which uses full msbuild.

[vatsan-madhavan]

You're right - I had a corrupt installation of 3.0.100 on one of my test machines that mislead me... sorry about the confusion. I went back and rechecked this and my observations agree with your predictions/observations. Thanks!

[vatsan-madhavan]

Although I would love to fix this in 3.0 servicing, I think on second thoughts not.

This is unfortunately similar to #1915, for which we have a case for fixing in 3.0 servicing, but absent a clear plan to insert .NET Core 3.0.x SDK servicing update into VS 16.3.x update, there is not much value in making this fix - there is no effective path to deliver this fix to .NET 3.0 customers. We'll just have to deliver this to customers via .NET Core 3.1.

I'm going to just fix this in 3.1 and leave 3.0 as-is.

/cc @nguerrera, @ryalanms, @rladuca

[vatsan-madhavan]

Fixed via #2075 and #1999.