Read through some of the most compelling questions from our webinar on The State of .NET after the release of .NET 5.
After the official release of .NET 5 at .NET Conf 2020, everyone has questions about what this will mean for their various experiences within the .NET world. Progress hosted a webinar to address what .NET 5 means for developers, The State of .NET, with two of our own developer advocates (who both also happen to be Microsoft MVPs).
You can catch the webinar here:
During that webinar, the chat lines were open and being fielded by other Telerik engineers and product owners. This blog post is a compilation of some of the Q&As we think you’ll find most relevant.
A: There generally shouldn’t be any. MS has prepared various guides for migrating too.
A: LTS means long-term support—it is a product lifecycle management policy in which a stable release is maintained for a longer period of time than the standard edition. Microsoft is committed to supporting LTS frameworks for three years after the initial release. Microsoft has announced that even-numbered versions will have LTS; odd versions will not. So, .NET 6, scheduled for release next year, will be a long-term supported version.
If a release (like .NET 5) does not have long-term support, it does not mean that the framework will not be supported. It means that support will end three months after the next even-numbered release (so .NET 5 support is projected to end in February 2022).
Additionally, LTS releases (even-numbered versions) will receive critical and compatibility fixes throughout their lifecycle; current releases (odd-numbered releases) will receive those same fixes and will also be updated with compatible innovations and features.
Updates are cumulative, with each update built upon all of the updates that preceded it. A device needs to install the latest update to remain supported. Updates may include new features, fixes (security and/or non-security), or a combination of both. Not all features in an update will work on all devices.
More information on the different .NET versions and their support is available here.
A: That’s a great question with no single correct answer. If you need to use the new features (especially things like Blazor WebAssembly), go for .NET 5—especially if you have some time until you have to go live. If you are already live and need stability and safety, you may want to stay on 3.1 until .NET 6 drops next year, as that will be the next LTS. Ultimately, this is entirely up to you.
A: .NET 5 also shipped ClickOnce, which put it on par in terms of deployment capabilities with the .NET Framework. In addition, .NET 5 has the concept of Single File Application which allows you to ship the needed .NET version bits with your app. More info here.
A: Microsoft has generally improved the performance of the framework in .NET 5 so you should see benefits too.
A: It’s here to stay. It is based on open and modern web standards, not on proprietary plugins and applets.
A: Perhaps through some magic similar to the server pre-rendering they added for Wasm you could be able to choose what to render out through some Razor markup in the index page. I haven’t tried that, though.
A: Yes, you can do PWAs to provide offline capabilities over WebAssembly. (More here.)
A: If your users have a very low latency to the server (like in an intranet)—yes. If the latency is high—you should still consider WebAssembly.
A: It will still be a tad slower than server-side Blazor, because WebAssembly is still slower. When multithreading and AoT come in, that performance will improve dramatically. For the time being, it would be up to you to choose whether the trade-off of the Wasm code being a tad slower is worth alleviating the server.
A: I’ve had them in a shared project so it should be possible to share. If not in a different way, at least as a build action to copy the files. This may be an interesting start.
A: Now that there is server pre-rendering for WebAssembly it will be more suitable and will be able to handle SEO better too.
A: Blazor does not support IE at the framework level. Other modern browsers like Chrome, Safari, Firefox, Edge are OK.
A: Modern browsers—Chrome, Firefox, Safari, Edge, but no IE—that comes from the framework now.
A: The Telerik UI for Blazor suite works the same across all browsers it supports and outputs the same HTML and styling.
If assembly X is required, X is loaded; whereas YZ assemblies may not be required, so are not transmitted?
A: You choose on which page to load the assemblies that are marked as lazy-loaded, so when that page is requested, only then are those assemblies requested from the server.
Q: Okay, but Blazor is still loading the entire image for that page (i.e. the underlying Wasm requirement has not changed vis-a-vis Blazor).
A: Wasm and the framework runtime are still required. But you can shave off a few MB of non-essential assemblies.
Q: Right… help me better comprehend the lazy loading. As I postulated earlier, XYZ assemblies are involved, but only X has the control I need. So only X is transferred?
A: I recommend you start from the MSDN docs about this. It is up to you to choose which assemblies to load and when.
A: Both yes and no. Some things are still done with JS—it is an integral part of the web—such as browser APIs (say, camera, location, … ) and getting element sizes. So you still need JS, but you will write a lot less of it, and there is a good chance existing NuGet packages will wrap such features for you so you can use them with C# only.
A: There isn’t a single answer to this. It depends a lot on your team skill set and preferences. This blog post can give you some ideas.
A: I’d say it can help. There are some common concepts. This post can give you some ideas.
A: Perhaps, but there may be some trickiness in the routing. You can host Blazor apps in Razor Pages though.
A: No, you can use partial classes: https://www.telerik.com/blogs/using-a-code-behind-approach-to-blazor-components.
A: Yes, Telerik UI for Blazor already supports .NET 5 in its 2.19.0 release.
A: The Blazor bindings for Xamarin are still experimental, so whether you can trust and go with that is up to your project needs and timelines.
A: It is more likely that MAUI will replace Xamarin as the cross-platform targeting framework. Blazor, at the moment, targets web apps. There are some experiments on using Blazor syntax to write Xamarin apps though. We will see what MS does.
A: The mobile bindings are for Xamarin and we have a few Xamarin components for them: https://docs.telerik.com/devtools/xamarin/blazormobilecontrols/blazor-mobile-bindings-overview.
A: Blazor mobile bindings are intended to write any Xamarin app, including future platforms’ support such as WPF.
A: Yes, it will—covering Windows and macOS.
A: Microsoft has announced inclusion of support for macOS with .NET 6. More information is available here.
A: MAUI uses the Xamarin XAML syntax, while Uno uses the UWP XAML syntax. Both output the same native apps per platform.
A: At this point, Microsoft is stating that with MAUI it will add support for both macOS and WPF. More information is available here.
A: It is still being updated and going strong to support everyone who still has (and will keep having for years) Web Forms apps.
A: While we don’t target or support it, if it can run a .NET Core app, you should be able to get our .NET Core components working there.
A: Check out the example shown here.
A: You could use the Telerik DataSource package for that. It would generally be up to you to serialize and deserialize the request, however. But that’s general OData specifics. With Telerik UI for Blazor, the grid has an extension method that can do the serialization to OData v4 too.
A: RadGrid with its Virtualization feature would allow you to handle hundreds of thousands of rows without negatively impacting the user experience.
A: If you would like to take advantage of Kendo UI, Telerik WinForms and Telerik UI for ASP.NET Core, then the perfect license would be the DevCraft one. It includes all UI components from various frameworks and great tools such as Reporting, Test Studio and JustMock. :)
A: There is no built-in way for GraphQL APIs; however, you can refer to the blogs on the matter that showcase how to build and consume GraphQL in your .NET application similar to this one.
A: During .NET Conf Microsoft said they are working on it, so it should happen sooner rather than later.
A: You should be able to start such a migration if you want to. It saves network bytes and since there are .NET packages for it, it should work under Azure too (best to address that with the MS docs, though, although I see some blog posts about this already so it should work).
A: For Blazor—only C# is supported by MS. For gRPC—I have not tried using VB with that and I can only assume, but since it compiles to .NET Standard, I think it should be possible.
A: Visual Studio 2019 16.8 or later is required to use .NET 5 from Visual Studio.
A: Check this out. :) As of .NET 5, Visual Basic will support Class Library, Console, Windows Forms, WPF, Worker Service and ASP.NET Core Web API. Microsoft says, “We are supporting these application types to provide a good path forward for the existing VB customer who want to migrate their applications to .NET Core.”
A: Microsoft has announced that Web Forms will remain only in .NET 4.x (currently at 4.8), and it will not be available in .NET Core or future .NET versions. So, you may want to look into migrating to a more modern framework by the time the “old” .NET goes out of support by MS.
A: It should be possible. MS provides a lot of migration guides and there might be one for that too. Generally, the view engine is still available so targeting more modern frameworks should let you migrate. Microsoft is also working on a webview that is even more lightweight.
A: I am not aware of breaking changes in this regard, but it is best to check that with the MS docs.
A: By default, yes.
A: Probably not. WPF is a proven, widely spread technology.
A: The .cshtml is a Razor Page that is not Blazor. A .razor is a razor component that you can generally use in a Blazor app or as a component in a Razor Page.
Q: Follow-up question to that: We used viewComponents as components in Razor Page, so is that not the right way to do it in .NET 5?
A: It is an option. You can continue with the viewComponent approach in .NET 5 as well, if you choose to use ASP.NET Core 5.0.
A: This is the extension for Razor components. It has been around since they became available for .NET Core Razor Pages.
DevCraft will arm you with everything you need to deliver outstanding applications in less time and with less effort.
With award-winning technical support delivered by the developers who built the products and a ton of resources and trainings, you can rest assured that you have a stable partner to rely on for your everyday challenges along your software development journey.
Download your 30-day free trial today!
Galia is a Product Marketing Manager for Telerik Reporting, Telerik Report Server and Telerik DevCraft at Progress. She has 18+ years in marketing, improving the sales, performance and reputation of a great number of international companies. Outside of work, she enjoys reading, psychology, mountain climbing and music.
Subscribe to be the first to get our expert-written articles and tutorials for developers!