Microsoft.VisualStudio.Threading + >=net8.0-windows -> Transitive WPF Framework Reference

[teneko]

Hi @AArnott, I just want to share an observation with you.

Because

• you have Microsoft.VisualStudio.Threading.Only as package dependency
• Microsoft.VisualStudio.Threading.Only ALSO targets net8.0-windows
• I target net10.0-windows

I transitively get the "Microsoft.WindowsDesktop.App.WPF" FrameworkReference. I already wondered why in my "win-x64/publish" the following files appeared:

• D3DCompiler_47_cor3.dll
• PenImc_cor3.dll
• PresentationNative_cor3.dll
• vcruntime140_cor3.dll
• wpfgfx_cor3.dll

Because you are not multi-targeteting framework net*-windows and I do not depend on it, I simply assume, that I safely can drop the WPF framework reference. I do so by doing:

<Target Name="SuppressTransitiveWpfFrameworkReference"
  AfterTargets="ResolvePackageAssets"
  BeforeTargets="AddTransitiveFrameworkReferences">
  <ItemGroup>
    <TransitiveFrameworkReference Remove="Microsoft.WindowsDesktop.App.WPF" />
  </ItemGroup>
</Target>

It makes me curious, is this normal behaviour? I would expect that since your package is not targeting net8-windows or greater, that NuGet would rather not tend to resolve the net*-windows on my side. Anyway, I think you cannot do anything, right? And I am right to assume, that you are not removing Microsoft.VisualStudio.Threading.Only anytime soon, right? 🙂 So just consider this issue as informational, for others that may face this slight oddity.

[AArnott]

The behavior you're seeing has nothing to do with StreamJsonRpc's own target frameworks, and everything to do with your own, and those found in the Microsoft.VisualStudio.Threading.Only package. Yes StreamJsonRpc depends on the threading package, but the target framework that resolves from it is based on the Target Framework of the app, ultimately.

So I'm going to refer you to microsoft/vs-threading#1530 where this has been discussed before, and if you'd like to continue the conversation, let's continue it there.