Shulou(Shulou.com)06/02 Report--

This article introduces the knowledge of "how to use HostBuilder and Generic Host in NET Core microservices". In the operation of practical cases, many people will encounter this dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

Introduction

Since the release of ASP.NET Core 1.0, we have the WebHostBuilder class, which allows us to configure and build WebHost. Then, when the server (Kestrel) accepts and processes the HTTP request, it handles the life cycle of the application. In ASP.NET Core 2.0, WebHostBuilder has been further improved and simplified. WebHostBuilder allows us to perform things such as configuring services using dependency injection containers; usually containers provided by Microsoft as part of ASP.NET Core. WebHostBuilder also allows us to load configurations from multiple sources into the final configuration representation of key / value pairs.

This works very well for ASP.NET Core Web applications, but so far there are no similar options in the frameworks of other types of applications!

Note: keep in mind that this article is based on ASP.NET Core 2.1Preview 1. Therefore, during the public preview and before the final release of 2.1, things may change based on the feedback received during the preview.

Introduction to IHost and HostBuilder

The new option available to developers using .NET Core 2.1 is the new "generic" host, which makes it easy for developers to set crosscutting concerns, such as logging, configuration, and dependency injection for non-Web focus applications. The team has realized that binding hosts to HTTP concerns may not be an ideal solution because many of these things are common requirements for other application types.

An example of where you can use this place is in a console application that needs to run background processing tasks, such as possible processing of messages in queues. These types of services are now common in cloud-based, local container-based architectures.

In the current version 2.0 of the .NET Core, logging, configuration, and DI libraries can of course be used in console applications. In our work, we have many micro-services that handle messages and data-rich tasks from queues. We must manually include and set up these frequently asked questions ourselves. While this is possible, setting things like DI settings in your application requires some plumbing.

Set up a host

To create a host, we can use a new HostBuilder with a set of methods and extensions similar to the existing WebHostBuilder. Therefore, anyone using ASP.NET Core should be familiar with these patterns.

There is a major difference to be aware of. HostBuilder does not provide extension methods, which allow you to use startup classes as you would with WebHostBuilder. The main purpose of this decision is to avoid creating two separate DI containers behind the scenes. Using a generic host, configure a single collection of services, which is then used to build the final service provider.

In the Main method of your application, you can first create a HostBuilder, then use the extension method to register the service with DI, read the logging required to configure and configure your application.

The best way to explain this feature is to give an example. If you want to see the complete sample code, you can get it from GitHub.

If we look at the Main method of this console application, we can explore creating a Host for our application.

If you have already used ASP.NET Core and have seen the WebHost builder, especially in the 1. 0 time frame, this may seem familiar. We first create a HostBuilder, and then we can use it to define the host we want to create. The first method in this example is the ConfigureAppConfiguration method. This approach allows us to configure which configuration provider should be used to construct a final representation of the configuration value for our application.

This is the same way you can customize the configuration when using WebHostBuilder. In this example, we have already said that we want to first read the configuration values from the appsettings.json file, then the environment variables, and finally any parameters passed to the application.

Next we call ConfigureServices, just like WebHostBuilder, which allows us to register the service with ServiceCollection. Performing registrations using the extension method on ServiceCollection, once completed, will enable us to obtain instances of these registrations wherever DI is available in our application.

In this case, the first one adds the ASP.NET Core Options service, and the second one sets the registration for the IOptions binding. The final service registration is what I will talk about later.

In the last section, ConfigureLogging sets up logging for the application as you would expect. In this case, we add console logging, which uses the values in the application configuration to determine what to record.

The logging configuration in this example is the same as in the default ASP.NET Core Web application created using templates.

The final step is to call RunConsoleAsync on the HostBuilder that builds and starts the application. It will run until CTRL + C is used to trigger it to shut down.

Complete a task

If we leave it here, the service won't be very good. At this point we're just running a console application, but we're not actually doing anything useful. So we need a way to define what the application should do.

The recommended pattern for this service style is to take advantage of the new IHostedService functionality, which was first introduced in ASP.NET Core 2.0.

Here we have a basic IHostedService implementation that will run in this service.

I won't delve into the code, but I'll summarize what it's doing. When the application starts, it will call StartAsync on this service. In this method, we create a timer that performs work every 5 seconds.

The work itself is defined in DoWork. It's just that the user records the ILogger as information. This includes messages retrieved from the application configuration. This is accessed by the IOptions object passed to the service through DI.

On shutdown, the StopAsync is called and the service cleans up a bit before the application is terminated. This is a very artificial example, but I want to simply put things together and focus on how these parts fit together.

By defining the IHostedService implementation, we simply register it with the DI container using the following common operations in ConfigureServices (which we saw earlier).

Services.AddSingleton ()

If we need to run various things in this service, we can add multiple managed services.

Summary

There are many cases in which this new "generic" host concept is used. In this article, we have explored a very basic example, but I don't need much work to simplify some micro-services in our environment. It is very popular to have a common mode for Web applications and services, and easy access to features such as DI, logging, and configuration.

This is the end of "how to use HostBuilder and Generic Host in the. NET Core microservice". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.