Blazor: client-side and server-side
A quick reminder: Blazor is an open source .NET web framework using C#/Razor and HTML that runs entirely in the browser via WebAssembly. It’s a big deal, and not only for .NET developers, because it’s the first client-side framework using a big-name programming language that will allow code to be shared between front and back end, allowing all sorts of productivity and consistency improvements. We’ve been following its progress for some time now, and since our last report, the Blazor team has continued releasing updates every 1–2 months.
Recently, Microsoft announced that as of ASP.NET Core 3.0 Preview 4: “Blazor is no longer experimental and we are committing to ship it as a supported web UI framework including support for running client-side in the browser on WebAssembly.”
- Server-side Blazor will ship as part of .NET Core 3.0. This was already announced last October (previously called “Blazor Components”).
- Client-side Blazor won’t ship as part of the initial .NET Core 3.0 release, but Microsoft are now announcing it is committed to ship as part of a future .NET Core release (and hence is no longer an “experiment”).
With all Microsoft’s talk of Blazor, the development community is responding with third-party components, demos and example code. The Blazor community is compiling a list here: https://github.com/AdrienTorris/awesome-blazor.
Popular UI component vendor Telerik has also begun publishing Blazor components, demonstrating its expectation that the framework has a bright future.
The ASP.NET team have put together a single-day Blazor workshop, which they ran at NDC London this year and have open sourced on GitHub. You can run through the entire workshop yourself, with full instructions and source code.The workshop is well worth considering. It will introduce you to the Blazor component model, and at the end of it, you’ll have a pizza ordering web app written entirely in C# and running as a client-side single page application.
Some tips from the coalface on building .NET Standard applications, which might save you some headaches:
- Net Standard 1.x doesn’t work correctly when targeting the full .NET Framework (see https://github.com/dotnet/standard/issues/567). This is caused by some bad assembly redirects in .NET 4.7.1 (or earlier). Thankfully there are some easy ways to avoid the problem, the simplest being to either target .NET 4.7.2+ or to use .NET Standard 2.0+, which would have the added bonus of giving you access to more APIs.
- Always ensure AutoGenerateBindingRedirects is enabled on projects consuming .NET Standard libraries.
- Migrate away from Packages.Config to new style PackageReferences. This requires NuGet 4.7.1+. It was broken some time around NuGet 4.9.2, but continues to work fine in Visual Studio.