Our WPF SyntaxEditor vNext beta began a week ago and has been going well. As we prepare for a 2019.1 version release, we are looking at making some other moves and wanted to get your feedback on them. First, let’s dig into some low-level .NET details to set up the background.

About .NET Core 3.0

.NET Core 3.0 is a newer, cross-platform, open source variation containing much of what is in the .NET Framework. It is still in preview with release date later this year, but is already much faster and more light-weight. Microsoft has been ensuring that it is capable of supporting Windows desktop development platforms like WPF and WinForms, and they have been updating Visual Studio to support desktop app development based on .NET Core 3.0. It also allows you to introduce newer Windows 10 APIs in desktop apps and host XAML islands (UWP controls). Further, .NET Framework 4.8 is intended to be the final version of that framework, with .NET Core as the migration path moving forward. More news in this area is sure to come in this week’s Build 2019 conference.

Moving to .NET Core 3.0

We’ve had numerous customers ask about moving our WPF Controls to .NET Core 3.0. A near-term goal for us is to ship native .NET Core 3.0 variations of our WPF Control assemblies as option, while still shipping .NET Framework-based variations.

On a side note, the existing WPF Control assemblies can already be used within .NET Core 3.0 applications. They are based on .NET Framework-only but are portable, and will work in .NET Core 3.0 applications.

What is .NET Standard?

This is where things get a bit more complex. .NET Framework is the base set of .NET APIs we have been using ever since .NET began. .NET Standard was more recently created as an API contract of sorts where a framework that implements a certain .NET Standard version guarantees that it supports a certain set of .NET APIs.

Think of .NET Standard like a set of interfaces and .NET Framework like a set of classes that implement those interfaces. Thus, more recent .NET Framework versions implement .NET Standard.

Microsoft's .NET Core diagram

.NET Core is simply another implementation of .NET Standard. Since the API implementation surface area is now about the same between .NET Core and .NET Framework, it’s a good time to consider moving to .NET Core for future work.

.NET Framework 4.6.1

The 4.6.1 version of the .NET Framework is now mature, as it was released at the end of 2015 and requires Visual Studio 2015 or later for development. It supports .NET Standard 2.0.

Back on Framework Updates

Both .NET Core 3.0 and .NET Framework 4.6.1 implement .NET Standard 2.0, which is the minimum set of APIs a number of our WPF Controls and SyntaxEditor text/parsing assemblies require.

One option we’ve been considering is:

Moving some of our non-UI class libraries like the various SyntaxEditor text assemblies that have no WPF references to be .NET Standard 2.0 class libraries. This would enable them to work in .NET Framework, .NET Core, Mono, etc… basically any framework implementing .NET Standard 2.0.

Continuing to ship .NET Framework versions of the WPF Control assemblies, but making their minimum target .NET 4.6.1, compared to the current .NET 4.0 minimum target. The .NET 4.6.1 version is needed to support references to .NET Standard 2.0 assemblies mentioned in the previous bullet, and would require you to target .NET 4.6.1 or later in your .NET Framework-based applications.

Adding .NET Core 3.0 versions of the WPF Control assemblies, so there is zero .NET Framework dependency for customers who wish to go purely to .NET Core 3.0.

A Twitter Poll

Please answer our Twitter poll as to whether you would support the changes mentioned above or not. If not, please indicate in the comments below or in the Twitter poll why.

Comments (10)

I'm really happy that you decided to include .NET Core binaries in the future. Microsoft also announced that .NET Framework 4 will be the last version. The next 'big' thing will be .NET 5 which combines most of .NET Framework, 100% of .NET Core and part of Mono and said it will be released in November 2020 already. So it's definitely worth a keep an eye on portability and focus on .NET Core as it seems to be the base of what .NET 5 will be.

So many new stuff is happening at the moment, cannot wait to see what vNext will bring!

We use Grids today and we ship a product that has to work on Windows Server, which means people are reticent to install any dependencies or undertake reboots. Even going from .NET 4 to .NET 4.5 has known incompatibilities and often affects the other software on the box, so we have to pick .NET 4 as our target.

.NET Core 3.0 and/or .NET 5 would solve our problems, if only the Windows compatibility wasn't so meager - .NET Core 3.0 is set to only support Windows Server 2012 and above.

My vote (I don't have Twitter) is for any solution that will be as compatible with .NET 4 but also provide compatibility with .NET Core 3.0 (whether directly or through .NET Standard 2.0). It sounds like this would involve a bit of "ifdef development" and two versions. Transitions are always messy, so I'm not sure Microsoft could have done a stellar job here even if they wanted to, but the outcome makes it very easy to toss everyone who can't fast forward to the latest technology overboard, and I'm very thankful that you are asking your customers about feedback.

I believe you can just right click on the Dependencies node in your .NET Core app project in Solution Explorer, and choose Add Reference there. Then use the Browse button on the dialog that appears to select the .NET Framework-based assemblies you wish to reference.

I'm not sure offhand if VS will show the toolbox items in that scenario or not though. VS should be showing toolbox items for any referenced assemblies, but if you aren't seeing them, perhaps Microsoft hasn't coded them yet to show if a .NET Framework assembly is referenced from a .NET Core app?

If they aren't showing up in the toolbox, you can still add them manually via XAML. After our SyntaxEditor vNext rollout of other platforms, we want to finish looking into the best way to ship native .NET Core 3 variations of the WPF control assemblies as well.