Showing posts with label Blazor. Show all posts
Showing posts with label Blazor. Show all posts

Monday, January 6, 2020

Countdown to .NET 5

2020 is an excellent year for .NET. This is the year we'll finally see .NET 5 merging .NET Core, .NET Framework and Xamarin.
2020 brings great news for .NET developers. This is the year that, Microsoft expects to consolidate .NET Core and .NET Framework on a single platform called .NET 5 including .NET mobile (Xamarin), ASP.NET Core, Entity Framework Core, WinForms, WPF and ML.NET.. The first preview is expected in the first half of the year with the official release foretasted for Nov, 2020. Excited? You should be!

Update: The first beta release is available now!

Great news for .NET developers

That's great news for folks working on .NET Core since there'll be an influx of projects to work, contribute and develop. But that's even better news for teams working on slow-moving projects (aka, most of us) which have been deferring an update to the more modern, faster and container-friendly .NET Core.

I posted some time ago my insights regarding this update. TLDR, I'm super excited! Being a long time Fedora Linux user and a big open source enthusiast, I have been using .NET Core for my personal projects on Linux (and running them successfully on both Docker, AWS and Azure). While I'm transitioning more and more my workflow to open source software (such as Vim, i3, etc) and and have been working a decent portion of my time with Go and Python, .NET is still my default framework.

So let's take another look at what's coming up next with .NET.

Highlights of .NET 5

Apart from the single codebase, my preferred highlights of .NET 5 are:
  • .NET will become a single platform including Xamarin, ASP.NET Core, Entity Framework Core, WinForms, WPF and ML.NET
  • Unified .NET SDK experience:
    • Single BCL (Base Class Library) across all .NET 5 applications. Today Xamarin applications use the Mono BCL but will move to use the.NET Core BCL, improving compatibility across our application models.
    • Mobile development (Xamarin) is integrated into .NET 5. This means the .NET SDK will support mobile. For example, you can use “dotnet new XamarinForms” to create a mobile application.
  • Native Applications supporting multiple platforms: Single Device project that supports an application that can work across multiple devices for example Window Desktop, Microsoft Duo (Android), and iOS using the native controls supported on those platforms.
  • Cloud Native Applications: High performance, single file (.exe) <50MB microservices and support for building multiple project (API, web front ends, containers) both locally and in the cloud.
  • Open source and hosted on GitHub
  • Cross-platform and better performance
  • Decent command-line interface (CLI)
  • Java, Objective-C and Swift interoperability
  • Support of static compilation of .NET (ahead-of-time – AOT)
  • Smaller footprints

A Unified Platform

This is a more holistic view of what .NET 5 will be:

The Schedule

The proposed merge is expected to happen by November 2020. Here's the plan:
You can also check the release status in real time on GitHub (Jan, 2020):

What's Next

So what's next? Well, the best thing to do is to keep an eye on .NET's official blog as they'll be updating the status of the project through there. Would you like to contribute? Jump into .NET Core and CoreFx repositories in GitHub. For more information on the topic, consider reading .NET Core and .NET merging as .NET 5.0.

References

See Also

For more posts on .NET Core, please click here.
Posted by
Labels: , , , , , , , , , , , , , , , , , , ,

Friday, May 10, 2019

.NET Core and .NET Framework merging as .NET 5.0

Good news for .NET developers: .NET Core and .NET merging as .NET 5.0 soon!
In a surprising (and much welcomed) move, Microsoft announced that .NET and .NET Core 3.0 will be merged into .NET 5.0. As a big fan of the KISS principle and lean architectures, this decision will benefit the whole .NET ecosystem. Here's what Microsoft said about it:
There will be just one .NET going forward, and you will be able to use it to target Windows, Linux, macOS, iOS, Android, tvOS, watchOS and WebAssembly and more.

Why it Matters?

Let's review why it matters:
  • First because the .NET Framework has a huge market share and is being run on billions of Windows devices. Merging it with .NET Core would mean that the whole .NET platform would access other architectures including being able to run Docker and containers as a whole natively.
  • Second because .NET Core is way more performant than .NET Framework. That would bring significant optimizations to the whole ecosystem, including Entity Framework and Docker.
  • Third because .NET Core incorporates much of the modern development toolset including a very robust CLI, ability to run containers,  build more lightweight microservices, and simplified deployment to the cloud.
  • Finally because the .NET Core development experience is way better and less decoupled from tools like Visual Studio (thanks in part to the .NET Standard). In other words,  developers love .NET Core.

I also welcome the simplification of the name and the confusion around the name, libraries and standards that were created since .NET was introduced.

The Schedule

The proposed merge is expected to happen by November 2020. Here's the plan:

Mono and .NET Core

Since the .NET Core and Mono runtimes have a lot of similarities, CoreCLR and Mono will be drop-in replacements for one another. Developers will be able to switch to choose between the different runtime options. Microsoft is also committed on investing on throughput and reliability in CoreCLR and invest more in startup and size reduction with the Mono AOT compiler.

In theory, all .NET 5 applications will use the CoreFX framework, CoreFX will work in places not used today. .NET 5 applications will be buildable with the .NET CLI, ensuring that you have common command-line tooling across projects.

Questions

Moving to a single .NET implementation raises important questions, including:
  • What will the target framework be? 
  • Will NuGet package compatibility rules be the same?
  • Which workloads should be supported out-of-the-box by the .NET 5 SDK?
  • How does writing code for a specific architecture will work?
  • Will we still need the .NET Standard?

Final Thoughts

Apart from the above questions, this is very exciting for .NET developers. Having worked with .NET since 1.1 and being a .NET Core early adopter mainly focusing on Linux development, I never liked the idea of two very similar but distinct frameworks. It just seemed like an unnecessary complication. With a much better performance, cli and more extensive target installation base, integrating .NET Core enhancements into .NET will be much appreciated by the whole community.

That announcement ends that duality and brings all .NET developers on board of the same boat again.

References

See Also

For more posts on .NET Core, please click here.
Posted by
Labels: , , , , , , , ,

Friday, June 22, 2018

Blazor, a new framework for .NET web apps

There's an emerging way to develop web applications on the .NET world: Blazor. Read and understand what changes.

There's a new talk from the awesome Steve Sanderson on the new Blazor framework. For those who don't know Blazor, it's a Full-stack web development with C# and WebAssembly. It's an experimental project exploring what would be building .Net applications using the .Net framework and C# that run in the browser using WebAssembly.

I've been following Blazor and am very excited with the direction the project is taking and following it very closely. Hope this project matures enough and gets incorporate in the .Net Core framework on the next release.

Blazor and WebAssembly

Steve Sanderson describes on Blazor: a technical introduction details about the Blazor Framework that are worth reading. Basically we'll have two modes: interpreted and ahead-of time. Take a look at the differences below.

Interpreted Mode

In interpreted mode, the runtime is compiled to WebAssembly, but the .NET assembly files are not. The browser then load and execute the runtime, which loads and execute s standard .NET assemblies built by the normal .NET build tools.

Diagram showing interpreted mode

Ahead-of-time (AOT) compiled mode

In AOT mode, your application’s .NET assemblies are transformed to pure WebAssembly binaries at build time
Diagram showing AOT mode

Blazor Presentation

The full blazor presentation is available on YouTube. I encourage you to watch it.

Final Thoughts

Blazor is really exciting and is being in active development. We will revisit the latest updates and surely update this post and build some prototypes in the future. Keep tuned. 
Posted by
Labels: , , , , ,

About the Author

Bruno Hildenbrand