Pages

Men

rh

12/30/2022

Index

MSDotnet Stack

Secure ASP.NET Core Blazor WebAssembly

Blazor WebAssembly apps are secured in the same manner as single-page applications (SPAs). There are several approaches for authenticating users to SPAs, but the most common and comprehensive approach is to use an implementation based on the
  • OAuth 2.0 protocol
  • OpenID Connect (OIDC).
  • Authentication library

    Blazor WebAssembly supports authenticating and authorizing apps using OIDC via the Microsoft.AspNetCore.Components.WebAssembly.Authentication library. The library provides a set of primitives for seamlessly authenticating against ASP.NET Core backends. The library integrates ASP.NET Core Identity with API authorization support built on top of Duende Identity Server. The library can authenticate against any third-party Identity Provider (IP) that supports OIDC, which are called OpenID Providers (OP).
    The authentication support in Blazor WebAssembly is built on top of the OIDC Client Library (oidc-client.js), which is used to handle the underlying authentication protocol details.
    However, the engineering design of Blazor WebAssembly uses OAuth and OIDC as the best option for authentication in Blazor WebAssembly apps. Token-based authentication based on JSON Web Tokens (JWTs) was chosen over cookie-based authentication for functional and security reasons:
  • Using a token-based protocol offers a smaller attack surface area, as the tokens aren't sent in all requests.
  • Server endpoints don't require protection against Cross-Site Request Forgery (CSRF) because the tokens are sent explicitly. This allows you to host Blazor WebAssembly apps alongside MVC or Razor pages apps.
  • Tokens have narrower permissions than cookies. For example, tokens can't be used to manage the user account or change a user's password unless such functionality is explicitly implemented.
  • Tokens have a short lifetime, one hour by default, which limits the attack window. Tokens can also be revoked at any time.
  • Self-contained JWTs offer guarantees to the client and server about the authentication process. For example, a client has the means to detect and validate that the tokens it receives are legitimate and were emitted as part of a given authentication process. If a third party attempts to switch a token in the middle of the authentication process, the client can detect the switched token and avoid using it.
  • Tokens with OAuth and OIDC don't rely on the user agent behaving correctly to ensure that the app is secure.
  • Token-based protocols, such as OAuth and OIDC, allow for authenticating and authorizing hosted and standalone apps with the same set of security characteristics.
  • Authentication process with OIDC

    The Microsoft.AspNetCore.Components.WebAssembly.Authentication library offers several primitives to implement authentication and authorization using OIDC. In broad terms, authentication works as follows:
  • When an anonymous user selects the login button or requests a page with the [Authorize] attribute applied, the user is redirected to the app's login page (/authentication/login).
  • In the login page, the authentication library prepares for a redirect to the authorization endpoint. The authorization endpoint is outside of the Blazor WebAssembly app and can be hosted at a separate origin. The endpoint is responsible for determining whether the user is authenticated and for issuing one or more tokens in response. The authentication library provides a login callback to receive the authentication response.
  • If the user isn't authenticated, the user is redirected to the underlying authentication system, which is usually ASP.NET Core Identity.
  • If the user was already authenticated, the authorization endpoint generates the appropriate tokens and redirects the browser back to the login callback endpoint (/authentication/login-callback).
  • When the Blazor WebAssembly app loads the login callback endpoint (/authentication/login-callback), the authentication response is processed.
  • If the authentication process completes successfully, the user is authenticated and optionally sent back to the original protected URL that the user requested.
  • If the authentication process fails for any reason, the user is sent to the login failed page (/authentication/login-failed), and an error is displayed.
  • Authentication component

    The Authentication component (Pages/Authentication.razor) handles remote authentication operations and permits the app to:
  • Configure app routes for authentication states.
  • Set UI content for authentication states.
  • Manage authentication state..
  • Always perform authorization checks on the server within any API endpoints accessed by your client-side app.

    Require authorization for the entire app

    In the app's Imports file, add an @using directive for the Microsoft.AspNetCore.Authorization namespace with an @attribute directive for the [Authorize] attribute.
    _Imports.razor:
    @using Microsoft.AspNetCore.Authorization
    @attribute [Authorize]
    Allow anonymous access to the Authentication component to permit redirection to the identity provider. Add the following Razor code to the Authentication component under its @page directive.
    Pages/Authentication.razor:
    @using Microsoft.AspNetCore.Components.WebAssembly.Authentication
    @attribute [AllowAnonymous]
    Add the attribute to each Razor component in the Pages folder under their @page directives:
    @using Microsoft.AspNetCore.Authorization
    @attribute [Authorize]
    All source collected from https://learn.microsoft.com/en-us/aspnet/core/blazor/security/webassembly/?view=aspnetcore-6.0/

    12/28/2022

    .NET Multi-platform App UI (.NET MAUI)

    Asp.net Core Blazor - .NET MAUI
    What is .NET MAUI?
    .NET Multi-platform App UI (.NET MAUI) is a cross-platform framework for creating native mobile and desktop apps with C# and XAML. Using .NET MAUI, you can develop apps that can run on Android, iOS, macOS, and Windows from a single shared code-base. .NET MAUI is open-source and is the evolution of Xamarin.Forms, extended from mobile to desktop scenarios, with UI controls rebuilt from the ground up for performance and extensibility. Using .NET MAUI, you can create multi-platform apps using a single project, but you can add platform-specific source code and resources if necessary. One of the key aims of . NET MAUI is to enable you to implement as much of your app logic and UI layout as possible in a single code-base.
    Who .NET MAUI is for
    .NET MAUI is for developers who want to:
  • Write cross-platform apps in XAML and C#, from a single shared code-base in Visual Studio.
  • Share UI layout and design across platforms.
  • Share code, tests, and business logic across platforms.
  • How .NET MAUI works
    .NET MAUI unifies Android, iOS, macOS, and Windows APIs into a single API that allows a write-once run-anywhere developer experience, while additionally providing deep access to every aspect of each native platform.
    .NET 6 or greater provides a series of platform-specific frameworks for creating apps:
  • .NET for Android
  • .NET for iOS
  • .NET for macOS
  • Windows UI 3 (WinUI 3) library
  • These frameworks all have access to the same .NET Base Class Library (BCL). This library abstracts the details of the underlying platform away from your code. The BCL depends on the .NET runtime to provide the execution environment for your code. While the BCL enables apps running on different platforms to share common business logic, the various platforms have different ways of defining the user interface for an app, and they provide varying models for specifying how the elements of a user interface communicate and interoperate.
    For Android, iOS, and macOS, the environment is implemented by Mono, an implementation of the .NET runtime. On Windows, .NET CoreCLR provides the execution environment.
    .NET MAUI provides a single framework for building the UIs for mobile and desktop apps. The following diagram shows a high-level view of the architecture of a .NET MAUI app:
    .NET MAUI apps can be written on PC or Mac, and compile into native app packages:
  • Android apps built using .NET MAUI compile from C# into intermediate language (IL) which is then just-in-time (JIT) compiled to a native assembly when the app launches.
  • iOS apps built using .NET MAUI are fully ahead-of-time (AOT) compiled from C# into native ARM assembly code.
  • macOS apps built using .NET MAUI use Mac Catalyst, a solution from Apple that brings your iOS app built with UIKit to the desktop, and augments it with additional AppKit and platform APIs as required.
  • Windows apps built using .NET MAUI use Windows UI 3 (WinUI 3) library to create native apps that target the Windows desktop. For more information about WinUI 3
  • What .NET MAUI provides
  • An elaborate layout engine for designing pages.
  • Multiple page types for creating rich navigation types, like drawers.
  • Support for data-binding, for more elegant and maintainable development patterns.
  • The ability to customize handlers to enhance the way in which UI elements are presented.
  • Cross-platform APIs for accessing native device features. These APIs enable apps to access device features such as the GPS, the accelerometer, and battery and network states.
  • Cross-platform graphics functionality, that provides a drawing canvas that supports drawing and painting shapes and images, compositing operations, and graphical object transforms.
  • A single project system that uses multi-targeting to target Android, iOS, macOS, and Windows.
  • .NET hot reload, so that you can modify both your XAML and your managed source code while the app is running, then observe the result of your modifications without rebuilding the app.
  • All source of information collected from learn Microsoft page.

    Asp.net Core Blazor - Blazor Hybrid

    Asp.net Core Blazor - Blazor Hybrid
    Blazor Hybrid
    Blazor can also be used to build native client apps using a hybrid approach. Hybrid apps are native apps that leverage web technologies for their functionality. In a Blazor Hybrid app, Razor components run directly in the native app (not on WebAssembly) along with any other .NET code and render web UI based on HTML and CSS to an embedded Web View control through a local interop channel.
    Blazor Hybrid apps can be built using different .NET native app frameworks, including .NET MAUI, WPF, and Windows Forms. Blazor provides BlazorWebView controls for adding Razor components to apps built with these frameworks. Using Blazor with .NET MAUI offers a convenient way to build cross-platform Blazor Hybrid apps for mobile and desktop, while Blazor integration with WPF and Windows Forms can be a great way to modernize existing apps.
    The Blazor Hybrid hosting model offers several benefits:
  • Reuse existing components that can be shared across mobile, desktop, and web.
  • Leverage web development skills, experience, and resources.
  • Apps have full access to the native capabilities of the device.
  • The Blazor Hybrid hosting model has the following limitations:
  • Separate native client apps must be built, deployed, and maintained for each target platform.
  • Native client apps usually take longer to find, download, and install than accessing a web app in a browser.
  • All source of information collected from learn Microsoft page.

    Blazor Web Assembly (WASM)

    Blazor WebAssembly
  • When the Blazor WebAssembly app is created for deployment without a backend ASP.NET Core app to serve its files, the app is called a standalone Blazor WebAssembly app.
  • When the app is created for deployment with a backend app to serve its files, the app is called a hosted Blazor WebAssembly app.
  • A hosted Blazor WebAssembly app typically interacts with the server over the network using web API calls or SignalR.
  • Advantages:
  • There's no .NET server-side dependency. The app is fully functioning after it's downloaded to the client.
  • Client resources and capabilities are fully leveraged.
  • Work is offloaded from the server to the client.
  • The .NET code of a Blazor Server application runs on the server-side. It means that the .NET code remains on the server and will not be sent to the client. Therefore, business logic cannot be decompiled, and your sensitive business algorithms cannot be analyzed.
  • An ASP.NET Core web server isn't required to host the app. Serverless deployment scenarios are possible, such as serving the app from a Content Delivery Network (CDN).
  •  
    Limitations:
  • The app is restricted to the capabilities of the browser.
  • Capable client hardware and software (for example, WebAssembly support) is required.
  • Download size is larger, and apps take longer to load.
  • NET runtime and tooling support is less mature. For example, limitations exist in .NET Standard support and debugging.
  • All source of information collected from learn Microsoft Documentation page.

    Entity Framework Core

    MSDotnet Stack
    Entity Framework (EF) Core is a lightweight, extensible, open source and cross-platform version of the popular Entity Framework data access technology.
    EF Core can serve as an object-relational mapper (O/RM), which:
  • Enables .NET developers to work with a database using .NET objects.
  • Eliminates the need for most of the data-access code that typically needs to be written.
  • The model

    With EF Core, data access is performed using a model. A model is made up of entity classes and a context object that represents a session with the database. The context object allows querying and saving data
    With EF Core, data access is performed using a model. A model is made up of entity classes and a context object that represents a session with the database. The context object allows querying and saving data
  • Generate a model from an existing database.
  • Hand code a model to match the database.
  • Once a model is created, use EF Migrations to create a database from the model. Migrations allow evolving the database as the model changes.
  • Querying

    Instances of your entity classes are retrieved from the database using Language Integrated Query (LINQ). For more information, see Querying Data.

    Saving data

    Data is created, deleted, and modified in the database using instances of your entity classes. See Saving Data to learn more.

    EF O/RM considerations

    While EF Core is good at abstracting many programming details, there are some best practices applicable to any O/RM that help to avoid common pitfalls in production apps:
  • Intermediate-level knowledge or higher of the underlying database server is essential to architect, debug, profile, and migrate data in high performance production apps. For example, knowledge of primary and foreign keys, constraints, indexes, normalization, DML and DDL statements, data types, profiling, etc.
  • Functional and integration testing: It's important to replicate the production environment as closely as possible to: 1) Find issues in the app that only show up when using a specific versions or edition of the database server.
  • 2) Catch breaking changes when upgrading EF Core and other dependencies. For example, adding or upgrading frameworks like ASP.NET Core, OData, or AutoMapper. These dependencies can affect EF Core in unexpected ways.
  • Performance and stress testing with representative loads. The naïve usage of some features doesn't scale well. For example, multiple collections Includes, heavy use of lazy loading, conditional queries on non-indexed columns, massive updates and inserts with store-generated values, lack of concurrency handling, large models, inadequate cache policy.
  • Security review: For example, handling of connection strings and other secrets, database permissions for non-deployment operation, input validation for raw SQL, encryption for sensitive data.
  • Make sure logging and diagnostics are sufficient and usable. For example, appropriate logging configuration, query tags, and Application Insights.
  • Error recovery. Prepare contingencies for common failure scenarios such as version rollback, fallback servers, scale-out and load balancing, DoS mitigation, and data backups.
  • Application deployment and migration. Plan out how migrations are going to be applied during deployment; doing it at application start can suffer from concurrency issues and requires higher permissions than necessary for normal operation. Use staging to facilitate recovery from fatal errors during migration. For more information, see Applying Migrations.
  • Detailed examination and testing of generated migrations. Migrations should be thoroughly tested before being applied to production data. The shape of the schema and the column types cannot be easily changed once the tables contain production data. For example, on SQL Server, nvarchar(max) and decimal(18, 2) are rarely the best types for columns mapped to string and decimal properties, but those are the defaults that EF uses because it doesn't have knowledge of your specific scenario.
  • All source collected from https://learn.microsoft.com/en-us/ef/core/

    .Net Core

    MSDotnet Stack
    The .NET Core platform is a new .NET stack that is optimized for open source development and agile delivery on NuGet. .NET Core has two major components. It includes a small runtime that is built from the same codebase as the .NET Framework CLR.
  • The .NET Core runtime includes the same GC and JIT (RyuJIT), but doesn’t include features like Application Domains or Code Access Security.
  • .NET Core also includes the base class libraries. These libraries are largely the same code as the .NET Framework class libraries, but have been factored (removal of dependencies) to enable to ship a smaller set of libraries. These libraries are shipped as System.* NuGet packages on NuGet.org.
  • Flexible deployment: Can be included in your app or installed side-by-side user- or machine-wide.
  • Cross-platform: Runs on Windows, macOS and Linux; can be ported to other OSes. The supported Operating Systems (OS), CPUs and application scenarios will grow over time, provided by Microsoft, other companies, and individuals.
  • Command-line tools: All product scenarios can be exercised at the command-line.
  • Compatible: .NET Core is compatible with .NET Framework, Xamarin and Mono, via the .NET Standard Library.
  • Open source: The .NET Core platform is open source, using MIT and Apache 2 licenses. Documentation is licensed under CC-BY. .NET Core is a .NET Foundation project.
  • Supported by Microsoft: .NET Core is supported by Microsoft, per .NET Core Support
  • The SDK is all of the stuff that is needed/makes developing a .NET Core application easier, such as the CLI and a compiler.The runtime is the "virtual machine" that hosts/runs the application and abstracts all the interaction with the base operating system.
    Kestrel is the web server that is included by default in ASP.NET Core new project templates. If your application accepts requests only from an internal network, you can use Kestrel by itself.
    If you expose your application to the Internet, you must use IIS, Nginx, or Apache as a reverse proxy server.
  • A reverse proxy server receives HTTP requests from the Internet and forwards them to Kestrel after some preliminary handling.
  • The most important reason for using a reverse proxy for edge deployments (exposed to traffic from the Internet) is security. Kestrel is relatively new and does not yet have a full complement of defenses against attacks.
  • NET as whole now has 2 flavors:
  • .NET Framework
  • .NET Core
  • .NET Core and the .NET Framework have (for the most part) a subset-superset relationship. .NET Core is named “Core” since it contains the core features from the .NET Framework, for both the runtime and framework libraries. For example, .NET Core and the .NET Framework share the GC, the JIT and types such as String and List.
  • .NET Core was created so that .NET could be open source, cross platform and be used in more resource-constrained environments.
  • the core features on .Net core:
  • Cross-platform & container support.
  • High performance.
  • Asynchronous via async/await.
  • Unified MVC & Web API frameworks.
  • Multiple environments and development mode.
  • Dependency Injection.
  • WebSockets & SignalR.
  • Cross-Site Request Forgery (CSRF) Protection.
  • Self hosted Web Applications
  • Action Filters
  • Extensible Output Caching
  • Globalization and Localization
  • Swagger OpenAPI
  • Authorization filters
  • Resource filters:
  • OnResourceExecuting
  • OnResourceExecuted
  • Action Filters
  • Exception Filters
  • Result Filters
  • Filters support both synchronous and asynchronous implementations.Aynchronous filters can run code before (On-Stage-Executing) and after (On-Stage-Executed) their pipeline.
  • Global.JSON
  • Appsettings.JSON
  • Project.JSON
  • LaunchingSettings.JSON
  • Bower.JSON
  • Package.JSON
  • Hosting.JSON
  • app.Use may call next middleware component in the pipeline. On the other hand, middlware defined using app.Run will never call subsequent middleware.
    WebListener is also a web server for ASP.NET Core that runs only on Windows. It’s built on the Http.Sys kernel mode driver. WebListener is an alternative to Kestrel that can be used for direct connection to the Internet without relying on IIS as a reverse proxy server.
    ASP.NET Core Module (ANCM) lets you run ASP.NET Core applications behind IIS and it works only with Kestrel; it isn’t compatible with WebListener. ANCM is a native IIS module that hooks into the IIS pipeline and redirects traffic to the backend ASP.NET Core application. ASP.NET Core applications run in a process separate from the IIS worker process,ANCM also does process management. ANCM starts the process for the ASP.NET Core application when the first request comes in and restarts it when it crashes. In short, it sits in IIS and routes the request for ASP.NET Core application to Kestral.
    The host is responsible for application startup and lifetime management.Other responsibility of host’s includes ensuring the application’s services and the server are available and properly configured. The host is typically created using an instance of a WebHostBuilder, which builds and returns a WebHost instance.
    Asynchronous programming is a means of parallel programming in which a unit of work runs separately from the main application thread and notifies the calling thread of its completion, failure or progress.
    In simpler terms: Synchronous execution means the execution happens in a single series.
    A->B->C->D. If you are calling those routines, A will run, then finish, then B will start, then finish,then C will start, etc.
    With Asynchronous execution, you begin a routine, and let it run in the background while you start your next, then at some point, say "wait for this to finish". It's more like: Start A->B->C->D->Wait for A to finish
    If you use this Async modifier on a method or expression, it's referred to as an async method. An async method runs synchronously until it reaches its first await expression, at which point the method is suspended until the awaited task is complete.
    If the method that the async keyword modifies doesn't contain an await expression or statement, the method executes synchronously. A compiler warning alerts you to any async methods that don't contain await statements, because that situation might indicate an error.
  • Open-source and community-focused.
  • Ability to develop and run on Windows, macOS, and Linux.
  • Built-in dependency injection.
  • Ability to host on IIS, Nginx, Apache, Docker, or self-host in your own process.
  • A lightweight, high-performance, and modular HTTP request pipeline.
  • A unified story for building web UI and web APIs.
  • Architected for testability.
  • Integration of modern, client-side frameworks and development workflows.
  • A cloud-ready, environment-based configuration system.
  • Side-by-side app versioning when targeting .NET Core.
  • Middleware is software that's assembled into an app pipeline to handle requests and responses. Each component:
    Chooses whether to pass the request to the next component in the pipeline.Can perform work before and after the next component in the pipeline.
    Request delegates are used to build the request pipeline. The request delegates handle each HTTP request.
    Request delegates are configured using Run, Map, and Use extension methods. An individual request delegate can be specified in-line as an anonymous method (called in-line middleware), or it can be defined in a reusable class.
    These reusable classes and in-line anonymous methods are middleware, also called middleware components. Each middleware component in the request pipeline is responsible for invoking the next component in the pipeline.
    Create a middleware pipeline with IApplicationBuilder : The ASP.NET Core request pipeline consists of a sequence of request delegates, called one after the other.
    Each delegate can perform operations before and after the next delegate. Exception-handling delegates should be called early in the pipeline, so they can catch exceptions that occur in later stages of the pipeline.
    The simplest possible ASP.NET Core app sets up a single request delegate that handles all requests. This case doesn't include an actual request pipeline. Instead, a single anonymous function is called in response to every HTTP request.
    public class Startup { public void Configure(IApplicationBuilder app) { app.Run(async context => { await context.Response.WriteAsync("Hello, World!"); }); } }
    In particular, HTTP/1.0 allowed only one request to be outstanding at a time on a given TCP connection. HTTP/1.1 added request pipelining, but this only partially addressed request concurrency and still suffers from head-of-line blocking.
    Therefore, HTTP/1.0 and HTTP/1.1 clients that need to make many requests use multiple connections to a server in order to achieve concurrency and thereby reduce latency.
    HTTP/2 addresses these issues by defining an optimized mapping of HTTP's semantics to an underlying connection. Specifically, it allows interleaving of request and response messages on the same connection and uses an efficient coding for HTTP header fields. It also allows prioritization of requests, letting more important requests complete more quickly, further improving performance.
  • Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2).
  • HTTP/2 enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent exchanges on the same connection.
  • Endpoint Routing is a new feature from Asp.Net Core 2.2 and above versions. To consume Endpoint routing we need to configure two middlewares.
  • UseRouting
  • UseEndpoints
  • UseRouting : this middleware should be configured before any other middlewares like authentication, authorization or custom middlewares. UseRouting middleware populates the current Httpcontext with route values, controller metadata ( which is not available in the previous version like Asp.net 2.1 or above versions). So any middleware after the UseRouting middleware has the capability to access route values or MVC controller metadata.
    UseEndpoints : this middleware should be configured at last in the application. UseEndpoints consist of all conventional based URL's. UseEndpoints is a delegate that executes the route and returns the response.
    Example :
    app.UseEndpoints(endpoints => { endpoints.MapControllerRoute( name: "testRoute", pattern: "test/{actionName}", defaults: new { controller = "Test", action = "index" }); endpoints.MapControllerRoute( name: "default", pattern: "{controller=Home}/{action=Index}/{id?}"); });
    1) Windows Desktop Apps Explanation: The highlight of .NET Core 3 is support for Windows desktop applications, specifically Windows Forms, Windows Presentation Framework (WPF), and UWP XAML. You will be able to run new and existing Windows desktop applications on .NET Core
    2) Language improvements C# 8.0
    3) .NET Standard 2.1 Explanation: .NET Core 3.0 implements .NET Standard 2.1. However, the default dotnet new classlib template generates a project that still targets .NET Standard 2.0. To target .NET Standard 2.1.
    4) Blazor Server Explanation: With .NET Core 3.0, you can develop amazing interactive client-side UI with Blazor Server. Blazor Server can be used to write completely new apps or to complement existing MVC and Razor Pages apps. There’s no need to rewrite existing app logic. Blazor is designed to work together with MVC and Razor Pages, not to replace them. You can continue to use MVC and Razor Pages for your server-rendering needs while using Blazor for client-side UI interactions.
    Blazor Server is a great way to add client-side functionality to your existing and new web apps using your existing .NET skills and assets. Blazor Server is built to scale for all your web app needs. Blazor WebAssembly is still in preview but is expected to ship in May of next year. In the future, it is expected to continue to evolve Blazor to support PWAs, hybrid apps, and native apps. For now, we hope you’ll give Blazor Server a try by installing .NET Core 3.0.
    5) Windows desktop: Explanation: NET Core 3.0 supports Windows desktop applications using Windows Presentation Foundation (WPF) and Windows Forms. These frameworks also support using modern controls and Fluent styling from the Windows UI XAML Library (WinUI) via XAML islands. The Windows Desktop component is part of the Windows .NET Core 3.0 SDK. You can create a new WPF or Windows Forms app with the following dotnet commands: .NET Core CLI
  • dotnet new wpf
  • dotnet new winforms
  • 6) SerialPort for Linux: Explanation: .NET Core 3.0 provides basic support for System.IO.Ports.SerialPort on Linux. Previously, .NET Core only supported using SerialPort on Windows.
    7) Fast built-in JSON support Explanation: The new built-in JSON support is high-performance, low allocation, and based on Span.
    8) Cryptography ciphers Explanation: .NET 3.0 adds support for AES-GCM and AES-CCM ciphers, implemented with System.Security.Cryptography.AesGcm and System.Security.Cryptography.AesCcm respectively. These algorithms are both Authenticated Encryption with Association Data (AEAD) algorithms.
    1) It supports partial class for Razor components
    2) It passes parameters to top-level components
    3) It supports new component tag helper
    4) It prevents default actions for events in Blazor application
    5) It stops event propagation in Blazor application
    6) It gives detailed errors during Blazor application development
    7) It supports shared queues in HttpSysServer
    8) It has breaking changes for SameSite cookies
    9) It Support Different Operating Systems :
  • openSUSE: 15+
  • RHEL: 6+
  • Debian: 9+
  • Alpine: 3.10+
  • Ubuntu: 16.04+
  • Fedora: 29+
  • SUSE Enterprise Linux (SLES): 12 SP2+
  • macOS: 10.13+
  • Windows Server: 2012 R2+
  • Windows Client: 7, 8.1, 10 (1607+)
  • 10)The .NET Core 3.1 has removed the Win Forms controls such as:##
  • DataGrid
  • ContextMenu
  • Toolbar
  • Menu
  • MainMenu
  • 11) Chip Support
  • x86 on Windows
  • x64 on Windows, Linux, and macOS
  • ARM64 on Linux (Use Linux kernel version 4.14 or later)
  • ARM32 on Windows and Linux
  • Meaning: The fact that it's an interface is irrelevant. Applying the readonly modifier on a field prevents you (or someone else)to change its value after the object is constructed. It can only be assigned in the constructor.
    A readonly field means it can only be written in the ctor. Once that's completed, the reference can't be changed or destroyed. It's very useful for initializing state and enforcing immutability.
    The advantage of having readonly on the field is it's a clear declaration that the field will not change during the lifetime of the containing instance.
    All source collected from https://learn.microsoft.com/en-us/ef/core/

    12/26/2022

    Asp.net Core Blazor
    ASP.NET Core Blazor
    Blazor is a framework for building interactive client-side web UI with .NET:
  • Create rich interactive UIs using C# instead of JavaScript.
  • Share server-side and client-side app logic written in .NET.
  • Render the UI as HTML and CSS for wide browser support, including mobile browsers.
  • Integrate with modern hosting platforms, such as Docker.
  • Build hybrid desktop and mobile apps with .NET and Blazor.
  • Using .NET for client-side web development offers the following advantages:
  • Write code in C# instead of JavaScript.
  • Leverage the existing .NET ecosystem of .NET libraries.
  • Share app logic across server and client.
  • Benefit from .NET's performance, reliability, and security.
  • Stay productive on Windows, Linux, or macOS with a development environment, such as Visual Studio or Visual Studio Code.
  • Build on a common set of languages, frameworks, and tools that are stable, feature-rich, and easy to use.
  • Components
    Blazor apps are based on components. A component in Blazor is an element of UI, such as a page, dialog, or data entry form.
    Components are .NET C# classes built into .NET assemblies that:
  • Define flexible UI rendering logic.
  • Handle user events.
  • Can be nested and reused.
  • Can be shared and distributed as Razor class libraries or NuGet packages.
  • The component class is usually written in the form of a Razor markup page with a .razor file extension. Components in Blazor are formally referred to as Razor components, informally as Blazor components. Razor is a syntax for combining HTML markup with C# code designed for developer productivity. Razor allows you to switch between HTML markup and C# in the same file with IntelliSense programming support in Visual Studio.
    All source of information collected from learn Microsoft page.

     

    Blazor Server:

  • With the Blazor Server hosting model, the app is executed on the server from within an ASP.NET Core app.
  • UI updates, event handling, and JavaScript calls are handled over a SignalR connection
  • A Blazor Server application runs on an ASP.NET Core backend and can be accessed using a browser.
  • The ASP.NET Core application can either be hosted self-contained or running on IIS.
  • Blazor Server uses a small JavaScript file to run and HTML and CSS to rendering its user interface. Blazor Server does not use WebAssembly. On the server-side, the Blazor application contains the .NET code and handles a copy of the Document Object Model (short DOM) for every client. If the user interacts with the application, Blazor will send an event to the server using a persistent SignalR WebSocket connection. The server will decide how to react to the user input and return changes to the DOM or execute backend functionality.
  • Every interaction triggers a network communication between the client and the server. Unlike JavaScript web frameworks that handle the user interaction client-side, Blazor Server handles user interaction on the server-side.
  • Advantages:
    Blazor Server only sends data to the client that is needed at the moment of user interaction. When we launch the application in the browser, only the first page gets downloaded and rendered.
  • Let’s compare that to a typical React or Angular application. In a single page web application based on any popular JavaScript web framework, you bundle your application and send the entire application to the client before it runs. Depending on the application and framework size, you send a lot of data to the client.
  • Using Blazor Server, you only send the data required to render the application initially. In short, Blazor Server applications start very quickly because the client does not have to download and execute a lot of code to get started. Because the download size is small, the rendering is also quick. The browser does not have to initialize a big single page application. It just renders the HTML and CSS for the initial page.
  • Blazor Server supports every browser that supports HTML and CSS. It does not require WebAssembly support, which makes Internet Explorer 11 a supported browser. If you’re building corporate applications and still have the requirement to support Internet Explorer 11, Blazor Server is the only viable rendering model.
  • The .NET code of a Blazor Server application runs on the server-side. It means that the .NET code remains on the server and will not be sent to the client. Therefore, business logic cannot be decompiled, and your sensitive business algorithms cannot be analyzed.
  • Blazor Server provides a simple project structure and allows access to the business logic from your user interface classes directly. You don’t need to implement an API layer to access data from the database.
  • All in all, Blazor Server allows you to be very productive and create modern single-page web applications without worrying about installing hundreds of JavaScript packages. You can write the client and server code using C#.
    Disadvantages:
  • Usually, React, or Angular applications build to static HTML, CSS, and JavaScript files that can be hosted as static resources on any webserver. However, when you use Blazor Server, you need to run ASP.NET Core on the server because the application is not compiled into static artifacts. With every user interaction, the server evaluates the appropriate response to the client.
  • Another thing to keep in mind is that every user interaction triggers a network communication. As we learned, the server holds a copy of every client’s DOM, and for every user interaction decides what to render next. This architecture does not allow offline support.
  • A steady and reliable network connection is a requirement to run a Blazor Server application successfully. Every user interaction evaluates on the server-side, and the results need to be transmitted to the client afterward. Without a steady internet connection, this model does not work.
  • Last but not least, remember that the server handles the requests of every client. If running on Azure, a standard virtual machine for 50$ a month can handle around 5000 concurrent client connections. For a 200$ a month machine, you already can handle about 20’000 concurrent client connections.
  • All source of information collected from learn Microsoft Documentation page.