- •Table of Contents
- •About the Author
- •Acknowledgments
- •Introduction
- •Version Support
- •Supported Versions
- •A Unified Platform
- •Roadmap
- •Supported Operating Systems
- •Command Line Interface
- •Desktop Development
- •Blazor
- •MAUI
- •Wrapping Up
- •.NET 6 Architecture
- •Runtimes
- •CoreCLR
- •Mono
- •WinRT
- •Managed Execution Process
- •Desktop Packs
- •Wrapping Up
- •Dotnet New
- •Dotnet Restore
- •NuGet.config
- •Dotnet Build
- •Dotnet Publish
- •Dotnet Run
- •Dotnet Test
- •Using the CLI in GitHub Actions
- •Other Commands
- •Wrapping Up
- •WinAPI
- •WinForms
- •STAThread
- •WinForms Startup
- •DPI Mode
- •Responding to Scale Events
- •Visual Styles
- •Text Rendering
- •The Message Loop
- •The Form Designer
- •WPF Startup
- •XAML Layout
- •Visual Tree
- •Data Binding
- •Windows App SDK
- •Building a Windows App SDK application
- •Using Windows APIs with Windows App SDK
- •Packaging
- •Migrating to .NET 6
- •Upgrade Assistant
- •Wrapping Up
- •Blazor WebAssembly
- •Creating a Blazor Wasm Project
- •Blazor Progressive Web Apps
- •Exploring the Blazor Client Project
- •Blazor in .NET 6
- •Blazor Component System
- •Creating Blazor Pages
- •Running a Blazor App
- •Blazor Server
- •SignalR
- •Blazor Desktop
- •Wrapping Up
- •Project Structure
- •Exploring MAUI
- •The Cross-Platform World
- •Application Lifecycle
- •MVVM
- •MVVM Toolkit
- •Wrapping Up
- •Model-View-Controller
- •Routing
- •Views
- •Controllers
- •Controller-Based APIs
- •Minimal APIs
- •Wrapping Up
- •Web Apps
- •Creating an App Service
- •Static Web Apps
- •Web App for Containers
- •Docker
- •Azure Functions
- •Deploying Azure Functions
- •Wrapping Up
- •Record Types
- •Monolith Architecture
- •Microservices
- •Container Orchestration
- •Kubernetes
- •Docker Compose
- •Dapr
- •Installing Dapr
- •Dapr State Management
- •Wrapping Up
- •Roslyn
- •Compiler API
- •Diagnostic API
- •Scripting API
- •Workspace API
- •Syntax Tree
- •Roslyn SDK
- •Source Generators
- •Writing a Source Generator
- •Debugging Source Generators
- •Wrapping Up
- •Garbage Collector
- •The Heap
- •The Stack
- •Garbage Collection
- •A Look at the Threadpool
- •Async in .NET 6
- •Await/Async
- •Cancellations
- •WaitAsync
- •Conclusion
- •Index
CHAPTER 2
Runtimes and Desktop
Packs
.NET 6 runs everywhere, from Windows to the Web, Linux, and mobile and embedded devices. But how? How do they manage to get the same code to run and behave in (mostly) the same way not only across platforms but also across CPU architectures? The secret is in the underlying architecture of .NET 6.
There have been numerous iterations in Microsoft’s cross-platform strategy. We’ve seen shared projects in Xamarin, where the code gets compiled into each platform; we have had portable class libraries where the libraries supported the lowest common denominator of all the selected platforms and more recently we had .NET Standard libraries. But why all these different approaches? It’s actually quite simple. .NET on one
platform was not exactly the same as .NET on another platform. We’ve had .NET, Mono,
.NET Compact Framework, .NET Micro Framework, etc.
Fixing the splintering of .NET versions was one of the core promises of .NET Core; it took a bit longer than expected but we are finally getting really close to one .NET. No matter what platform you are running on, if your application is running on .NET 6, you can use .NET 6 class libraries and share them over all supported platforms.
.NET 6 Architecture
A very big step on the road to .NET unification was taken in .NET 5, by closing a big gap in missing APIs compared to the classic .NET Framework Microsoft that was able to serve the .NET API surface as an abstraction layer. This means that, as developers, we don’t have to worry about what platform we’re running on or if certain .NET features will work or even compile on the platform we’re running on. Figure 2-1 shows Microsoft’s view on .NET architecture.
21
© Nico Vermeir 2022
N. Vermeir, Introducing .NET 6, https://doi.org/10.1007/978-1-4842-7319-7_2