Do not import .NET Framework's copy of Microsoft.WinFX.targets when building Sdk style projects.

[vatsan-madhavan]

From dotnet/wpf#2258 (comment)

In SDK style projects, we didn't intend for WPF specific functionality to be present unless Microsoft.NET.Sdk.WindowsDesktop SDK is used. Contrary to this intention, when MSBuild/Visual Studio is used for builds, .NET Framework's copy of WinFX.targets gets imported by default irrespective of the SDK being used. This happens even for Microsoft.NET.Sdk projects.

This results in inconsistent results for Resource items when built by msbuild vs. dotnet. For e.g., a Microsoft.NET.Sdk project with Resource items built using msbuild will invoke PresentationBuildTasks (the .NET Framework version) and embed the resource into the assembly.

The same project, when built using dotnet will not do this.

A developer could perceive the dotnet behavior as a regression (as seen in dotnet/wpf#2258), but in reality the msbuild behavior is unexpected.

/cc @nguerrera, @dsplaisted, @livarcocc
/cc @rladuca

[nguerrera]

This is limited to the case where the sdk project targets .NET Framework, right?

I am not sure that we can "fix" this as it's a breaking change. Some people managed to use the in-box PBT with SDK projects. We would have had to have had the foresight to turn them off in v1 of the SDK to do this without breaking.

My suggestion would be to just document to use Microsoft.NET.Sdk.WindowsDesktop moving forward for these use cases, if we can get away with that.

[weltkante]

Well, that case also affects multitarget SDK projects where you have e.g. net48 and netcoreapp3.0 in the TargetFrameworks are an issue as well. This is kinda common when you start porting your libraries.

If this is fixed it must be done in a way that Microsoft.NET.Sdk multitarget projects exclude the Desktop WPF Rules for net48 and similar targets and includes the rules for Microsoft.NET.Sdk.WindowsDesktop projects. Otherwise you wouldn't be able to multitarget WPF libraries at all anymore.

If above is not possible then its preferable to be left in the current state.

[tmat]

@nguerrera Is there a property that we can use to explicitly remove the .NET Framework targets? If compat is concern we can make it opt-out by setting the property.