What .Net Core 3.0 means for developers

It’s hard to believe that .Net is nearly 18 years old; the first public release of the .Net Framework was in February 2002. Over the years it has become the foundation of much of Windows development, and with the release of .Net Core in 2014 and the formation of the .Net Foundation it has begun a move away from its proprietary roots to an open source development model that’s intended to be the basis of all .Net development.

.Net Core launched with a limited set of features but has rapidly started to catch up with the .Net Framework. Where it was initially for console and web applications, it’s now ready for the desktop and for GUI code. We’re not far from Microsoft shifting all .Net support to .Net Core and the .Net Standard libraries that provide a common set of APIs for your code across the various .Net implementations, including Xamarin and Unity.

Third time’s the charm

Microsoft recently launched Version 3.0 of .Net Core. It’s a big update to the platform, with many new APIs and, at last, support for Windows desktop applications. It adds support for C# 8.0 and .Net Standard 2.1, as well as ARM64 support across multiple operating systems, including Linux. Browser-hosted apps will get a boost from Microsoft’s Blazor Web Assembly and server-side tools.

Windows desktop support is perhaps the biggest change to .Net Core in this release. It’s important to note that any apps that use Windows desktop components can’t take advantage of .Net Core’s cross-platform capabilities. You may want to go back to the original Xamarin approach of developing multiple solutions in a single Visual Studio project that builds on a common core of code with different, targeted UIs for each solution.

.Net Core on the Windows desktop

Desktop apps will use familiar Windows Presentation Foundation and Windows Forms, making it easy to bring older .Net Framework applications across to .Net Core. You’re not blocked from using modern controls; support for XAML Islands means you can use WinUI controls and Microsoft’s new Fluent design language. XAML Islands is an important technology, but if you’re targeting more than one version of Windows, you need to add fallback controls for older versions. Microsoft is releasing an update to Visual Studio that will add templates for .Net Core desktop applications. It’s adding support for high DPI applications to WinForms, an important requirement for modern PC and laptops like the Surface Book.

GUIs aren’t the only feature necessary for desktop applications. Windows .Net Core code will need to call COM code, working with existing SDKs and plug-ins, and where .Net Core code is called from COM. The latter scenario is complex, as it relies on detection of the appropriate CLR and automatically loading it when the host application calls your .Net Core COM server.

Where the familiar .Net Framework has shims to manage this, .Net Core has been designed to avoid using systemwide shims to simplify deployment (as the documentation says, “less magic”). Instead it adds a COM library to your code that will expose itself as a custom shim, with a manifest of the classes it uses. When it’s called it triggers a series of actions that find the right runtime and eventually activate the called class, which runs in its own context. Although the process seems complex, it’s automatically generated by .Net Core when you build your code. All you need to worry about is whether this approach gives you the performance you need.

I’ve written about MSIX, Microsoft’s new application packaging technology. It’s now able to deploy .Net Core packages as well as Win32 and UWP. Using MSIX for desktop .Net Core apps makes a lot of sense, as it allows admins to add their own customizations to installers before deploying across an organization.

.Net Core for modern microservice applications

The underlying .Net Core platform has been enhanced to improve support for modern applications, with better support for asynchronous communications and, finally, the addition of built-in JSON support. With .Net Core originally designed for microservices, adding fast, low-memory JSON tools makes a lot of sense. You won’t need to rely on third-party libraries, as the internal JSON reader can be used to build your own parsers. Support for UTF-8 characters will allow you to use more compact JSON encoders, with speedups of between 30 percent and 80 percent over popular libraries.

Another important update for microservice development is support for HTTP/2. Using HTTP/2 for REST APIs will improve client and server security, with the option of turning off encryption during development to simplify debugging with wire-level tools such as Fiddler. Additional security comes with support for TLS 1.3, though you won’t see the benefit in your desktop apps until client OSes like Windows and MacOS add support. You will get value if you’re using .Net Core 3.0 microservices on Linux and using services such as Cloudflare for DDOS prevention.

A more predictable release schedule

Microsoft and the .Net Foundation aim to put .Net development on a more predictable schedule, starting with this release. A long-term support release in November 2019 will quickly follow the initial .Net Core 3.0 in September 2019. A year later we’ll see the long-awaited merger of .Net Core and the .Net Framework in .Net 5.0. Following that, the next long-term support release will be .Net 6.0, in 2021. Microsoft said at Build 2019 that it aims to deliver a yearly cadence for releases, with even version numbers being the LTS versions. The intent is to make .Net releases predictable and to ensure that it’s easy to step from release to release.

That change affects how Microsoft will update SDK releases. It’s introducing the concept of feature bands, with an updated version numbering process. Patch numbers will now be three digits, with the first digit indicating the supported feature band. Installing 3.0.103 will replace any prior version in the 1xx series. However, installing 3.0.201 won’t affect any installed 1.x versions.

A new release of .Net Core is always important, and this one especially so as it’s the final step before all .Net platform development shifts to .Net 5.0. You have a year to shift existing .Net apps away from the old .Net Framework to new APIs and to .Net Standard. By adding desktop application support and MSIX this release will give you a head start on your migration.