Fixes dotnet/sdk#51173

Customer Impact

• Customer reported
• Found internally

We became aware of the issue through a customer report of a different issue.

When a customer is targeting .NET 10.0 and building a WPF application (not hybrid WPF+Winforms), references the package System.Drawing.Common, and uses types present in that package, they will see a compilation error:

error CS1069: The type name 'Bitmap' could not be found in the namespace 'System.Drawing'. This type has been forwarded to assembly 'System.Drawing.Common, Version=0.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' Consider adding a reference to that assembly.

There is a workaround -- add the following to the project;

  <Target Name="_addDrawingReference" AfterTargets="ResolveTargetingPackAssets">
    <ItemGroup>
      <Reference Condition="'%(Reference.FileName)' == 'PresentationCore'" Include="%(Reference.RootDir)%(Reference.Directory)System.Drawing.Common.dll" />
    </ItemGroup>
  </Target>

The same bug can occur for an older .NET project if it explicitly opts into package pruning with RestoreEnablePackagePruning. This workaround will work there as well.

Background

The bug occurs because pruning represents all the runtime assemblies in the WindowsDesktop shared framework and will prune packages that overlap. WindowsDesktop has different reference vs runtime assemblies. It's references are factored into two sets: WPF and WindowsForms. There is one package in this set that is not shared between WindowsForms and WPF -- System.Drawing.Common. So when building for WPF the reference is pruned and a compilation error can occur.

We fix this by adding System.Drawing.Common to the default reference set for WPF. Moving forward we must follow the rule that any packages which overlap with shared frameworks must be represented in their entirety when that framework is referenced. We had similar bugs to this in ASP.NETCore, but there we chose to just remove the package from the pruning set since users would directly reference it and it did not have any past CVEs that would make more desirable to prune. System.Drawing.Common is more likely to be referenced transitively (it was in the customer report) - so we couldn't just drop it from the pruning list unless we also dropped every package which ever referenced it. It also has had past CVEs that make it desirable to prune to avoid false positive audit / CG alerts.

Regression

• Yes
• No

Regressed in .NET 10.0 when enabling pruning for WindowsDesktop shared framework (earlier previews, repro'ed this in P5)

Testing

Verified customer repro is fixed. Adhoc testing of WPF templates. Tested https://github.com/Microsoft/WPF-Samples after retargeting to net10. Ran data analysis of namespace and type name collisions.

Risk

Medium

We are adding new types to the default reference set, and some of those types conflict with WPF types if using statements for both are present. This should only ever break compile-time (not runtime), only for folks targeting net10.0, and the break is normal/expected for what folks see on retargeting. They will know what to do to resolve the break without reading any documentation.

We are effectively trading a break that is hard to diagnose, with a non-intuitive workaround for a break that is easy to diagnose with an intuitive fix.

We tried to measure the likelihood of both breaks. The internal component governance data shows about 54 hits of projects that reference drawing and target Windows desktop - rather small in the grand scheme of things (our popular packages in this feed are ~10-20k). Most likely internal data has fewer WPF client applications. We don't have great data, but I looked to a github search was surprised to search for cases of a drawing reference in a WPF app. I expected those to be few, but my search found 5K source hits across github (looking for code-behind files with a using statement for drawing) and I was able to reproduce the bug in more than one of those projects in the first page of results.

I did a similar search for cases where our newly introduced type collisions might cause a compiler error. I couldn't find any. The data set was similar - WPF sources using Drawing - but most of those had already dealt with the type conflicts present in the base-shared framework's System.Drawing.Primitives assembly. Any case of .NETFramework source (or source ported from .NETFramework) had also already dealt with the conflicts since all the System.Drawing types were in a single System.Drawing assembly in netfx.