Last week was the premier event for developers targeting the Microsoft space: Microsoft Build. DevExpress was there, of course, with a full complement of staff at our booth, including myself.
On the first day of the event, Microsoft published a whole collection of news items for the development community, among which was some further information about the future of .NET, and in particular .NET Core. What I want to do in this post is to explore these announcements, what has happened, where we are now, and what the future portends.
The past
On December 20, 2018, Microsoft released the first public preview of .NET Core 3. Unlike previous versions, this release provided the first look at .NET Core's support for WinForms, WPF, and Entity Framework 6.
Image: https://devblogs.microsoft.com/dotnet/net-core-3-and-support-for-windows-desktop-applications/
A mere two weeks after this preview was made available, we announced that v18.2.4 of the DevExpress controls and components would support .NET Core 3, and furthermore published links to WinForms and WPF GitHub repositories holding our demos that were built and tested under this preview of .NET Core. The repositories have detailed instructions on how to install our NuGet packages and test these .NET Core 3 demos.
And yet, despite the promise of having a single platform for truly cross-platform applications — recall that .NET Core is designed to be used under Windows, Linux or MacOS — there was a certain confusion in the community, Does it mean the traditional .Net Framework days are numbered? Should I start migrating my projects to .NET Core? What’s the future of my desktop apps?
The Present
As part of the announcements at Build, Microsoft answered some of these questions, and announced .NET Core 5 (which for simplicity, they’re calling “.NET 5”). Of course, even having revealed this newer version, Microsoft still haven't fully released .NET Core 3: this is slated for September 2019.
Image: https://devblogs.microsoft.com/dotnet/introducing-net-5/
But what about the traditional .NET Framework, which stands at version 4.7? What will happen to that? In essence, it is going to be frozen as is, no new features or enhancements will be made. It'll probably reach version 4.8, and that will be that. There will be no .NET Framework 5, and, if you think about it, that's why the version after .NET Core 3 will be .NET 5: they want to skip the possible confusion about using the term ".NET Core 4". They expect that desktop developers will make the effort to migrate to .NET Core to gain all the benefits it provides.
Benefits? Well, first and foremost, it’s the ability to distribute .NET with your applications without having to share it with other apps on the machine. It's just local to your app, so you will no longer require a user to update their machine just to run your product, and maybe stopping other apps working. As for the widely repeated “cross-platform” promise, be warned: you won’t be able to run your WinForms Office-like application on a Mac or anything like that. Windows and WPF are strictly for Windows machines. .NET Core adds multi-platform support only for application engines and their internal logic. The user interface will remain platform-dependent.
The news about .NET 5 is exciting, no doubt, and shows how optimistic Microsoft are about this unified platform, but at present it is still too far away. Right now we’re focusing on what matters most: proper .NET Core 3 support. In contrast to our original announcement about .NET Core, DevExpress NuGet packages now deliver more libraries, including XAF and Office controls, and, even better, they are now natively built under .NET Core (previously, you’d get libraries built under .NET Framework that were compatible with Core).
The Future
Now that we know .NET Core is the Real Deal, here comes another big question: “what should I, as a developer, do next”?
First, take some time to investigate whether your current Windows apps can be migrated to .NET Core 3. This would be an ideal time to identify possible issues, such as a namespace, class, property or method being only available in the full Framework, but not in .NET Core (maybe there's a replacement?). Perhaps you'll decide that it's best to leave those legacy apps on the .NET Framework and only use .NET Core for new apps. Take a look at our GitHub repositories, they may give you some ideas:
There's another caveat here: please realize that the Visual Studio designers do not work at present with .NET Core 3 Preview. Microsoft still have a lot of work to make this happen and we are in close contact with the development team there.
Second, realize that there is still quite a bit of time: .NET Core 3 is slated for September of this year, and .NET 5 will be over a year later.
Image: https://devblogs.microsoft.com/dotnet/introducing-net-5/
Third, you can rely on us to keep up with Microsoft's releases. We are committed to maintaining and updating our controls and libraries to work with .NET Core. We’ll make sure to publish NuGet packages with our .NET Core-compatible libraries immediately after Microsoft release a new version. Once .NET Core 3 is officially published, we’ll provide more information on how to migrate your big legacy projects, and share existing limitations and possible ways around it.