Introduction
Hi readers! Hope you all have a good time. After presenting your content on .netcoreinterviewquestions, sqlinterviewquestions, c#partialclasses, MVC, and mobile app, now we'll focus on the latest advanced ASP.netcorefeatures. It will help developers with fundamental knowledge for developing ASP.NET Core apps, along with dependencyinjection (DI), configuration, middleware, and other features.
i) Use of Dependency injection (services)
ASP.NET Core contains dependency injection (DI) that gets configured services accessible throughout a specific app. Services are included with the DI container with ‘WebApplicationBuilder.Services’ builder.Services in the valuable code. Various ‘framework-provided services’ are included when the ‘WebApplicationBuilder’ is initiated. Here, ‘builder' is a ‘WebApplicationBuilder' in the code. Here is an article to learn more about MVC Dependency injection, here is Microsoft official link to learn more about dependency injection.
ii) Middleware
The request-controlling pipeline is organized as a chain of middleware elements. Each element conducts operations on an ‘HttpContext’ and either gather the next middleware in the pipeline or dismisses the request.
By pattern, a middleware element is included with the pipeline by gathering a ‘Use{Feature}’ extension procedure. Middleware connected to the app is brought out through the following code:
iii) Use of Program.cs file
ASP.NET Core apps developed with the web templates possess the app startup code in the Program.cs file. The ‘Program.cs' file is where the app's request controlling pipeline is well explained as a list of middleware components.
and services desired by the app are well configured.
The following app startup code supports:
- Razor Pages
- MVC controllers with views
- Minimal web APIs
- Web API with controller
iv) Host
In the beginning, an ASP.NET Core app builds a ‘HOST’. The host encased whole app resources, such as Middleware elements, an HTTP server enactment, Logging, DI services, and smooth Configuration.
Generally, there are 3 types of hosts available.
- .NET WebApplication Host (Minimal Host)
- ASP.NET Core Web Host
- .NET Generic Host
The .NET WebApplication Host is often utilized in all the templates of ASP.NET Core. The .NET Generic Host and .NET WebApplication Host share many templates of the same classes and interfaces. The ASP.NET Core Web Host is accessible only for backward comparison.
The following example initiates a WebApplication Host:
The ‘WebApplicationBuilder.Build' method configures a specific host with a set of default choices as follows:
- Loading configuration from environment variables, ‘appsettings.json', configuration sources, and command line arguments
- Utilizing Kestrel as the web server and enabling IIS integration
- Sending logging outcomes to the console and debug providers.
The Generic Host permits other categories of apps to utilize cross-cutting framework extensions, like logging, configuration, dependency injection (DI), and app lifetime management.
V) Servers
An HTTP server is utilized in the ASP.NET Core app to handle HTTP requests. The HTTP server forwards requests to the app as a set of request components composed into an ‘HttpContext'. Some servers are Windows, macOS, and Linux.
ASP.NET Core delivers the following implementations of the server.
- ‘IISHTTPServer'for Windows utilizes IIS. Throughout this server, the ASP.NET Core app and IIS run in a similar procedure.
- Kestrel, a cross-platform web server, runs in a reverse proxy configuration utilizing IIS. In ASP.NETCoreversion2.0 or the latest version, Kestrel can be operated as a public-serving edge server revealed directly to the Internet.
- HTTP.sys is a particular server for Windows that isn't utilized with IIS.
Vi) Configuration framework
ASP.NET Core renders a configuration framework that makes settings as name-value pairs from a specific ordered set of providers of configuration. The providers of Built-in configuration are accessible for different sources, like .xml files, .json files, command-line arguments, and environment variables.
You can also create your configuration providers to assist other sources.
Generally, ASP.NET Core apps get configured for reading from ‘appsettings.json', the command line, and environment variables, etc. When the configuration of the app is loaded, the values that are obtained from environment variables override values received from ‘appsettings.json'.
To handle confidential configuration information such as passwords, .NET Core facilitates the Secret Manager. For the generation of secrets, Azure Key Vault is recommended.
Vii) Environments
In ASP.NET Core, execution or performance environments, such as building, Staging, and creation, are available. Set the environment variable ‘ASPNETCORE_ENVIRONMENT' to mention the environment of a running app. That environment variable is read well by ASP.NET Core at app startup and gets stored the value in the implementation of an 'IWebHostEnvironment'. This implementation is accessible anywhere in an app through dependency injection (DI).
In the following example, know how to configure the exception controller and HSTS (HTTP Strict Transport Security Protocol) middleware when not running in the environment of Development :
VIII) Logging
ASP.NET Core assists with a logging API that functions with different built-in and 3rd-party logging providers.
Logging providers include Console, Event Tracing on Windows, Debug, Windows Event Log, Azure App Service, TraceSource, and Azure Application Insights
Resolve an ‘ILogger<TCategoryName>’ service from dependency injection to develop logs and call logging procedures such as ‘LogInformation’, For example:
IX) Routing
A route is a URL structure that is mapped to a controller. The controller is commonly a Razor page, an action procedure in middleware, or an MVC controller. ASP.NET Core routing allows you to handle the URLs utilized by your app.
The following code, created by the ASP.NET Core web app template, calls ‘UseRouting':
X) Error handling
ASP.NET Core possesses built-in features for controlling errors, such as A developer exception page, static status code pages, Custom error pages, and Startup exception controlling.
XI) Making HTTP requests
An application of 'IHttpClientFactory' is accessible for generating HttpClient instances. The factory performs the following.
- Renders a central area for naming and configuring logical instances of HttpClient. For instance, get registered and configured a specific GitHub client to access GitHub. For other purposes, get registered and configured a default client.
- Assists in registration and chaining of various delegating controllers to develop an outgoing middleware pipeline of requests. This structure is similar to the inbound middleware pipeline of ASP.NETCore. This pattern contributes a mechanism to handle cross-cutting interests for HTTP requests, including caching, error controlling, logging, and serialization.
- Controls the pooling and duration of underlying instances ‘HttpClientHandler' to prevent genuine DNS errors that happen while manually controlling HttpClientlifetimes.
- Combines with a third-party library ‘Polly' for transient error controlling.
- Includes configurable logging knowledge through 'ILogger' for all requests transmitted through clients established by the factory.
XII) Content root
The content root is the primary path for the following.
- The executable file for hosting the app (.exe).
- The Webroot, commonly the wwwroot folder.
- Compiled assemblies that constitute the app (.dll).
- Content files utilized by the app, such as Razor files (.cshtml, .razor), Data files (.db), and Configuration files (.json, .xml).
At the time of development, the content root directs to the root directory of the project by default. This directory is also the primary path for both the content files of the app and the Webroot. Set its path to mention a separate content root while developing the host.
XIII) Webroot
The web root is the primary path for public, static resource files including Stylesheets (.css), Images (.png, .jpg), and JavaScript (.js).
Generally, static files are provided only from the directory of webroot and its sub-directories. The web root path would be {content root}/wwwroot) by default. At the time of building the host, just mention another web root by writing its path.
You can restrict publishing files in wwwroot through the ‘<Content> project item' in that project file. The following example has shown how to restrict publishing content in the directory ‘wwwroot/local’ and its sub-directories:
In Razor ‘.cshtml' files, ~/ refers to the web root. A path starting with ~/ is determined as a virtual path.
Wrapping Up
Hope, the above article will give some valuable idea about various latest features like middle ware and dependency injections, etc, of ASP.net core. The developers will be able to develop the best competitive ASP.net core apps in comparison to other programming languages. The developers will definitely enjoy the development environment with these new features.
Post A Comment:
0 comments: