A major drawback so far was the unavailability of any visual controls – you simply couldn’t write desktop applications for .NET Core. With .NET Core 3.0, Microsoft now added support for Windows Forms and WPF as desktop technologies. This finally enabled us to fully port our .NET assemblies to .NET Core 3.0 without giving up any major functionalities. So with List & Label 25, you’ll get
- full support for .NET Core 3.0, including our WinForms and WPF controls (e.g. WinForms PreviewControl, WPF Viewer)
- the Compatibility Shim is no longer required in web applications
- most samples ported to .NET Core 3.0
- most assemblies ported to .NET Core 3.0, just a few data providers are missing where the underlying drivers haven’t been ported so far
Of course, we’ll fully support .NET 4.x for years to come as well – at least as long as Microsoft does. So there’s no need to hurry, but you may now switch over anytime and stick to your favorite reporting tool ;).
To keep our assembly zoo manageable, we’ll discontinue support for .NET 2, .NET Standard 2 and .NET Client Profile with List & Label 25. All of these frameworks have been dropped by Microsoft while providing an easy migration path to the .NET 4.x / .NET Core 3.0 frameworks, respecively. So hopefully, this change will not affect you.
We look forward to even extending our .NET Core support moving forward to .NET 5 with a port of the Report Server to .NET Core on our roadmap. Will you port your existing apps, too?
Leading the development at combit as Managing Director. Microsoft .NET enthusiast driving innovation & agile project management. Used to be a physicist in my first life. I love hiking and vanlife.
Great, we will switch to .Net Core 3.0 as soon as LL25 will be available.
I wonder if we get any speed benefits out of this move? I think of Span? Does LL25 already use these and other new features?
Also as Microsoft at the recent DotNetConf-Conference announced the availability of the “nullable reference type” in C# 8.0. Mads Torgersen in his talk made it clear the library vendors should use the new feature but they should begin so that null reference error could be catched early. With your .Net Core 3.0 support do you also support this?
Thanks for your answer
Hi Mike,
We’re steadily refactoring our code base and use new features as they become available where they make sense. As the C# 8 compiler has just been released and .NET 4.x and Core 3 largely share the same code base, we’ll use the new features where they make sense while trying to avoid spoiling the code with #ifdefs all over.
I haven’t heard Mads’ talk at DotNetConf yet – where would you benefit from us using nullable reference types internally? Or are you thinking of null-dereferencing-safety? Would be great to hear more about this.
Regarding performance, the greatest boost will probably be the start up performance of your app and – if we’re talking of ASP.NET – the performance has been generally improved with the introduction of .NET Core. The bottlenecks we’re fighting on the reporting side are more on the unmanaged part, thus we’ll not profit that much from using the new types like Span etc.
You should still see a performance improvement in LL25, though – as always, this is one of our focus areas and we changed _a lot_ under the unmanaged hood to get better again.
Jochen