WindowsBase NETCoreApp vs WindowsDesktopApp

I am starting this as a question, if there is a bug I am not quite sure who it belongs to.

It appears that WindowsBase assembly is both part of Microsoft.WindowsDesktop.App as well as Microsoft.NETCore.App. However, they have different assembly version (4.0.0.0 vs 6.0.2.0):

C:\Program Files\dotnet\shared\Microsoft.NETCore.App\6.0.14\WindowsBase.dll
WindowsBase, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35

vs

C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App\6.0.14\WindowsBase.dll
WindowsBase, Version=6.0.2.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35

My question is why do they have different versions?

(Obviously I do have an issue for context, when you compile C++/CLI assembly targeting net6.0, it uses references from Microsoft.WindowsDesktop.App. When you then add the C++/CLI assembly as a reference to a normal net6.0 project, you get a MSB3277 conflict between WindowsBase 4.0.0.0 coming from a Microsoft.NETCore.App.Ref and WindowsBase 6.0.2.0 coming from the C++/CLI reference.)

/cc @vatsan-madhavan @pchaurasia14

[dsplaisted]

How does the SDK know that given assembly reference requires a FrameworkReference to be added?

Normally NuGet restore flows that information, either for project or package references.

If you’re referencing a DLL directly, then that information doesn’t flow and you need to know to add the FrameworkReference.

[joperezr]

Or perhaps the version in Microsoft.NETCore.App is just a facade to enable code compiled against .NET Framework to work.

I believe this is why.