Standard: Ensure net standard 2.0 satisfies dependencies of WindowsBase and PresentationCore

[matthargett]

First, let me say that I understand that net standard doesn't include platform-specific UI libraries, and fully support that philosophy.

We are shipping a WPF application (React Native Windows, specifically) on Windows 7 and would like to use .NET Native compilation. The requisite UI libraries are missing, but we can hypothetically work around that by re-targeting and re-authoring those assemblies to target .NET Core/netstandard.

What we need is for the majority (even totality?) of types and methods for .NET namespaces/assemblies referenced by WindowsBase and PresentationCore to be present in net standard 2.0. (Similar dependency satisfaction for Xamarin.Forms on Linux would also help our future development plans.) Please let me know what other information I can provide to help achieve this goal.

[Petermarcu]

I believe the more interesting thing to talk about is whether WindowsBase and PresenatationCore can be implemented on top of .NET Standard. In other words, you could have an implementation of those on top of .NET Standard which would then be able to run anywhere that supports .NET Standard and supports whatever underlying tech is used for the UI stack.

Beyond that, in order to get .NET Native it will need to have a first class story for apps outside of UWP apps. Check out the dotnet/corert repo for that project.

So two things are needed that aren't really related to .NET standard.

1. Core UI libraries implemented on top of .NET Standard (this may create arguments for adding some of the most core types to the standard but is not a requirement)
2. .NET Native (CoreRT) needs to be finished to a point where it can be used outside UWP.

Make sense? Thoughts?

[matthargett]

1. Sorry if I wasn't clear, I did mean that netstandard should be complete enough to allow those libraries to be built on top of it. We will do a decompile-retarget-recompile and add a comment to this issue about missing types and/or namespaces. The Xaml namespace/assembly will definitely be among them.

2. .NET Native does work outside UWP. We proved this by invoking ILC.EXE manually on a non-UWP application that did target .NET Core, then copying the resulting binary and MRT.DLL over to a Windows 7 SP1 VM and physical machine for testing. What's holding us back is the missing WPF-related assemblies that target .NET Core

[Petermarcu]

Great. We're on the same page. I know the xaml types have been discussed. It would be great to see data for what types are in your list. We can decompose them and see which can just be on top vs needing to be in the standard.

Cool on #2, definitely not supported but as you proved, isn't too far off. There are some types that are implemented on .net core that don't exist in the mrt world for .net standard 2.0 support. That gap will need to be closed to get the end to end working.

[21c-HK]

I believe the more interesting thing to talk about is whether WindowsBase and PresenatationCore can be implemented on top of .NET Standard. In other words, you could have an implementation of those on top of .NET Standard which would then be able to run anywhere that supports .NET Standard and supports whatever underlying tech is used for the UI stack.

What would this look like? Some kind of drawing API that is supported on all platforms? I would love a modern 2D cross-platform hardware-accelerated drawing API in .NET Standard.

[mellinoe]

@21c-HK Given that there isn't really a "de-facto" 2D drawing library for .NET, I think it would be hard to include anything in the .NET Standard right now. Good first steps in that direction would be to get projects like SkiaSharp, etc. running on top of .NET Standard, and seeing how well they work, what sorts of patterns work or don't work, etc. There is nothing blocking projects like SkiaSharp from working on top of .NET Standard (even today, without .NET Standard 2.0); it's just work that hasn't been done yet.

Rather than wrapping a native library like Skia, another interesting option would be to write such an abstraction layer directly in C#. There are already low-level wrappers available for OpenGL, D3D/D2D, Vulkan, etc.

[weshaggard]

@matthargett did you have any further follow-up questions for this thread? If not we can close this issue.

[matthargett]

An update:

1. PresentationCore and WindowsBase (and few other assemblies) all reference private types of each other via friend assembly linkage, so now I understand why there is no good answer for a straight package of them individually. System.Xaml itself doesn't have this problem, but some of its private types are referenced by the others.

1. I guess what I'd like to know is how to implement a .NET Core wrapper/redirect for PresentationCore and WindowsBase so that the system-installed versions are delegated to, similar to how this happens for mscorlib and other platform/runtime-coupled assemblies. I've looked at System.Console's ConsolePal.Windows.cs and Win32Exception.*cs, and it looks like we would make a new namespace under the Interop namespace (a la Interop.Kernel32) like Interop.PresentationCore.

If my understanding of #2 is correct (please tell me if it's not), in which repo would I create an issue (and later a PR). Are there scripts available for automatically generating those .NET Core->.NET redirection sources? If the Interop namespaces aren't the place to do this, where's an example of how one would do this?

Happy to close this out once I know where to move the meta-issue to.

Thanks!

[terrajobst]

Correct me if I'm wrong but it seems you're asking whether you can build an application targeting .NET Core/.NET Standard that uses the "ambient" WPF assemblies from the .NET Framework. The answer to that would be no. This would basically result in mixing-and-matching runtimes, not just assemblies.

Also note that when you consume .NET Framework assemblies in the context of .NET Standard/.NET Core, we don't actually use the .NET Framework implementation of said assemblies; they assembly names are merely redirected to the implementations of .NET Standard/.NET Core.

In other words, there is no cheating. We can bridge differences in assembly names but we can't "magically" inject parts of the .NET Framework platform into .NET Core/.NET Standard -- this only works for higher level assemblies that are targeting .NET Framework.

So if we were to support the WPF assemblies for .NET Standard/.NET Core, we'd have an implementation of them specifically for those platforms and you would acquire the binaries in a non-.NET Framework specific way.