CHAPTER 31<\/p>\n
Diving Into ASP.NET Core<\/p>\n
This chapter takes a deep look into the new features in ASP.NET Core. As you learn about the features, you will add them to the projects created in the previous chapter, Introducing ASP.NET Core.<\/p>\n
What\u2019s New in ASP.NET Core
\nIn addition to supporting the base functionality of ASP.NET MVC and ASP.NET Web API, Microsoft has added a host of new features and improvements over the previous frameworks. In addition to the unification of frameworks and controllers, a new style of web applications is now supported using Razor pages. Listed here are some additional improvements and innovations:
\n\u2022Razor Page based web applications
\n\u2022Environment awareness
\n\u2022Minimal templates with top level statements
\n\u2022Cloud-ready, environment-based configuration system
\n\u2022Built-in dependency injection
\n\u2022The Options pattern
\n\u2022The HTTP Client Factory
\n\u2022Flexible development and deployment models
\n\u2022Lightweight, high-performance, and modular HTTP request pipeline
\n\u2022Tag helpers (covered in a later chapter)
\n\u2022View components (covered in a later chapter)
\n\u2022Vast improvements in performance
\n\u2022Integrated logging<\/p>\n
Razor Pages
\nAnother option for creating web applications with ASP.NET Core is using Razor pages. Instead of using the MVC pattern, Razor page applications are (as the name suggests) page-centric. Each Razor page consists of two files, the page file (e.g. Index.cshtml) is the view, and the PageModel C# class (e.g. Index.cshtml.cs), which serves as the code behind file for the page file.<\/p>\n
\u00a9 Andrew Troelsen, Phil Japikse 2022 1355<\/p>\n \u25a0Note Razor page based web applications also support partial and layout views, which will be covered in detail in later chapters.<\/p>\n The Razor Page File The PageModel Class Table 31-1. Some of the Helper Methods Provided by the Controller Class<\/p>\n Helper Method Meaning in Life Table 31-1. (continued)<\/p>\n Helper Method Meaning in Life Table 31-2. Some of the HTTP Status Code Helper Methods Provided by the PageModelClass<\/p>\n Helper Method HTTP Status Code Action Result Status Code You might be surprised to see some familiar methods from the Controller class. Razor page based applications share many of the features of MVC style applications as you have seen and will continue to see throughout these chapters.<\/p>\n Page Handler Methods public class DeleteModel : PageModel public async Task The names of the handler methods can be changed, and multiple handler methods for each HTTP verb can exist, however overloaded versions with the same name are not permitted. This will be covered in Chapter 34.<\/p>\n Environmental Awareness Table 31-3. The IWebHostEnvironment Properties<\/p>\n Property Functionality Provided In addition to accessing the relevant file paths, IWebHostEnvironment is used to determine the runtime environment.<\/p>\n Determining the Runtime Environment public static class Environments The HostEnvironmentEnvExtensions class provides extensions methods on the IHostEnvironment for working with the environment name property. Table 31-4 lists the convenience methods available.<\/p>\n Table 31-4. The HostEnvironmentEnvExtensions Methods<\/p>\n Method Functionality Provided These are some examples of using the environment setting: if (!app.Environment.IsDevelopment()) Update this block to flip it around:<\/p>\n if (app.Environment.IsDevelopment()) Next, add the developer exception page into the pipeline when the app is running development. This provides debugging details like the stack trace, detailed exception information, etc. The standard exception handler renders a simple error page.<\/p>\n if (app.Environment.IsDevelopment()) Update the AutoLot.Web project block to the following (notice the different route for the error handle in the Razor page based application):<\/p>\n if (app.Environment.IsDevelopment()) The AutoLot.Api project is a little different. It is checking for the development environment, and if it is running in development, Swagger and SwaggerUI are added into the pipeline. For this app, we are going to move the Swagger code out of the if block so it will always be available (leave the if block there, as it will be used later in this chapter):<\/p>\n if (app.Environment.IsDevelopment()) Since there isn\u2019t a UI associated with RESTful services, there isn\u2019t any need for the developer exception page. Swagger will be covered in depth in the next chapter.<\/p>\n \u25a0Note Whether the Swagger pages are available outside of the development environment is a business decision. We are moving the Swagger code to run in all environments so that the Swagger page is always available as you work through this book. Swagger will be covered in depth in the next chapter.<\/p>\n You will see many more uses for environment awareness as you build the ASP.NET Core applications in this book.<\/p>\n The WebAppBuilder and WebApp \u25a0Note prior to .net 6 and C# 10, a WebHost was created in the Main() method of the Program.cs file and configured for your application in the Startup.cs file. With the release of .net 6 and C# 10, the aSp.net Core template uses top level statements in the Program.cs file for creation and configuration and doesn\u2019t have a Startup.cs file.<\/p>\n The Program.cs File with RESTful Services var builder = WebApplication.CreateBuilder(args); app.UseHttpsRedirection(); app.UseAuthorization(); app.MapControllers();<\/p>\n app.Run();<\/p>\n If you are coming from a previous version of ASP.NET Core, the preceding code was split between the Program.cs file and the Startup.cs file. With ASP.NET Core 6, those file are combined into top level statements in the Program.cs file. The code before the call to builder.Build() was contained in the the WebApplicationBuilder and registering services in the dependency injection container. The code including the builder.Build() call and the rest of the code in the file was contained in the Configure() method and is responsible for the configuration of the HTTP pipeline. \u25a0Note When adding services into the Dependency injection container, make sure to add them into the top level statements using the comment \/\/Add services to the container.they must be added before the builder.Build() method is called.<\/p>\n The builder.Build() method generates the WebApplication and sets up the next group of method calls to configure the HTTP pipeline. The Environment section was discussed previously. The next set of calls ensures all requests use HTTPS, enables the authorization middleware, and maps the controllers to their endpoints. Finally, the Run() method starts the application and gets everything ready to receive web requests and respond to them.<\/p>\n The Program.cs File with MVC Style Applications var builder = WebApplication.CreateBuilder(args);<\/p>\n \/\/ Add services to the container. builder.Services.AddControllersWithViews(); var app = builder.Build(); app.UseHttpsRedirection(); app.UseRouting();<\/p>\n app.UseAuthorization();<\/p>\n app.MapControllerRoute( name: "default", app.Run();<\/p>\n The first difference is the call to AddControllersWithViews(). ASP.NET Core RESTful services use the same controller\/action method pattern as MVC style applications, just without views. This adds support for views into the application. The calls for Swagger and the API Explorer are omitted, as they are used by API service. The Program.cs File with Razor Page Based Applications var builder = WebApplication.CreateBuilder(args); builder.Services.AddRazorPages(); \/\/ Configure the HTTP request pipeline. if (app.Environment.IsDevelopment()) There are only three differences between this file and the initial file for the AutoLot.Mvc application. Instead of adding support for controllers with views, there is a call to AddRazorPages() to add support for Razor pages, add routing for razor pages with the call to the MapRazorPages() method, and there isn\u2019t a default route configured.<\/p>\n Application Configuration { The template also creates an appsettings.Development.json file. The configuration system works in conjunction with the runtime environment awareness to load additional configuration files based "ConnectionStrings": { \u25a0Note each item in the JSon must be comma delimited. When you add in the ConnectionStrings item, make sure to add a comma after the curly brace that proceeds the item you are adding.<\/p>\n Next, copy each of the appsettings.Development.json files to a new file named appsettings. "ConnectionStrings": { "AutoLot": "It\u2019s a secret" This shows part of the power of the new configuration system. The developers don\u2019t have access to the secret production information (like connection strings), just the non-secret information, yet everything can still be checked into source control.<\/p>\n \u25a0Note in production scenarios using this pattern, the secrets are typically tokenized. the build and release process replaces the tokens with the production information.<\/p>\n All configuration values are accessible through an instance of IConfiguration, which is available through the ASP.NET Core dependency injection system. In the top level statements prior to the web application being built, the configuration is available from the WebApplicationBuilder like this:<\/p>\n var config = builder.Configuration;<\/p>\n After the web application is built, the IConfiguration instance is available from the WebApplication var config = app.Configuration;<\/p>\n Settings can be accessed using the traditional methods covered in Chapter 16. There is also a shortcut for getting application connection strings.<\/p>\n config.GetConnectionString("AutoLot")<\/p>\n Additional configuration features, including the Options pattern, will be discussed later in this chapter.<\/p>\n Built-in Dependency Injection Table 31-5. Lifetime Options for Services<\/p>\n Lifetime Option Functionality Provided \u25a0Note if you want to use a different dependency injection container, aSp.net Core was designed with that flexibility in mind. Consult the docs to learn how to plug in a different container: https:\/\/docs.microsoft<\/a><\/a><\/a>. com\/en-us\/aspnet\/core\/fundamentals\/dependency-injection.<\/p>\n Services are added into the DI container by adding them to the IServiceCollection for the application. var app = builder.Build();<\/p>\n \u25a0Note in pre-.net 6 web applications, the startup process involved both a Program.cs class and another class named Startup.cs (by convention). in .net 6, all of the configuration is done in top level statements in the Program.cs file. this will be covered in the section Configuring the Web application.<\/p>\n Adding Web App Support To The Dependency Injection Container var builder = WebApplication.CreateBuilder(args); RESTful service web applications don\u2019t use views but do need controller support, so they use the AddControllers() method. The API template for ASP.NET Core also adds in support for Swagger (a .NET implementation of OpenAPI) and the ASP.NET Core end point explorer:<\/p>\n var builder = WebApplication.CreateBuilder(args); \u25a0Note Swagger and openapi will be covered in the next chapter.<\/p>\n Finally, Razor page based applications must enable Razor page support with the var builder = WebApplication.CreateBuilder(args); Adding Derived DbContext Classes into the DI Container global using AutoLot.Dal.EfStructures; global using AutoLot.Dal.Initialization; global using Microsoft.EntityFrameworkCore;<\/p>\n The following code (which must be added into each of the Program.cs files in the web projects) gets the connection string from the JSON configuration file and adds the ApplicationDbContext as a pooled resource into the services collection:<\/p>\n var connectionString = builder.Configuration.GetConnectionString("AutoLot"); builder.Services.AddDbContextPool Now, whenever an instance of the ApplicationDbContext is needed, the dependency injection (DI) system will take care of the creation (or getting it from the pool) and recycling of the instance (or returning it to the pool). builder.Services.AddSqlServer Note that the minimal API doesn\u2019t have the same level of capabilities. Several features, like DbContext pooling are not supported. For more information on the minimal APIs, refer to the documentation located here: https:\/\/docs.microsoft.com\/en-us\/ef\/core\/what-is-new\/ef-core-6.0\/<\/a><\/a><\/a> whatsnew#miscellaneous-improvements.<\/p>\n Adding Custom Services To The Dependency Injection Container services.AddScoped<ICarRepo, CarRepo>();<\/p>\n The previous example added a scoped service (AddScoped<>()) into the DI container specifying the service type (ICarRepo) and the concrete implementation (CarRepo) to inject. You could add all of the repos into all of the web applications in the Program.cs file directly, or you can create an extension method to encapsulate the calls. This process keeps the Program.cs file cleaner. global using AutoLot.Dal.Repos; global using AutoLot.Dal.Repos.Base; global using AutoLot.Models.Entities; global using AutoLot.Models.Entities.Base;<\/p>\n global using Microsoft.AspNetCore.Builder;<\/p>\n global using Microsoft.Extensions.DependencyInjection; global using Microsoft.Extensions.Configuration; global using Microsoft.Extensions.Hosting; global using Serilog; global using System.Data; Next, create a new folder named DataServices in the AutoLot.Services project. In this folder, create a new public static class named DataServiceConfiguration. Update this class to the following: services.AddScoped<ICustomerRepo, CustomerRepo>(); services.AddScoped<IDriverRepo, DriverRepo>(); services.AddScoped<IMakeRepo, MakeRepo>(); services.AddScoped<IOrderRepo, OrderRepo>(); services.AddScoped<IRadioRepo, RadioRepo>(); return services; Next, add the following to the GlobalUsings.cs file in each web application (AutoLot.Api, AutoLot.Mvc, AutoLot.Web):<\/p>\n global using AutoLot.Services.DataServices;<\/p>\n Finally, add the following code to the top level statements in each of the web applications, making sure to add them above the line that builds the WebApplication:<\/p>\n builder.Services.AddRepositories();<\/p>\n Dependency Hierarchies Injecting Dependencies \/\/Controller \/\/PageModel public CreateModel(ICarRepo repo) Method injection is supported for action methods and page handler methods. To distinguish between a binding target and a service from the DI container, the FromServices attribute must be used:<\/p>\n \/\/Controller \/\/PageModel \u25a0Note You might be wondering when you should use constructor injection vs method injection, and the answer, of course, is \u201cit depends\u201d. i prefer to use constructor injection for services used throughout the class and method injection for more focused scenarios.<\/p>\n To inject into an MVC view or a Razor page view, use the @inject command:<\/p>\n @inject ICarRepo Repo<\/p>\n Getting Dependencies in Program.cs In addition to the traditional DI techniques, services can also be retrieved directly from the application\u2019s ServiceProvider. The WebApplication exposes the configured ServiceProvider through the Services property. To get a service, first create an instance of the IServiceScope. This provides a lifetime container "RebuildDatabase": true,<\/p>\n Next, add the following line to each of the appsettings.Production.json files in each of the web projects:<\/p>\n "RebuildDatabase": false,<\/p>\n In the development block of the if statement in Program.cs, if the configured value for RebuildDatabase is true, then create a new IServiceScope to the an instance of the ApplicationDbContext and use that to call the ClearAndReseedDatabase() method (example shown from the AutoLot.Mvc project):<\/p>\n if (env.IsDevelopment()) Make the exact same changes to the Program.cs file in the AutoLot.Web project. The Program.cs file update in the AutoLot.Api project is shown here:<\/p>\n if (app.Environment.IsDevelopment()) Build the Shared Data Services The Interfaces namespace AutoLot.Services.DataServices.Interfaces;<\/p>\n public interface IDataServiceBase The IMakeDataService interface simply implements the IDataServiceBase namespace AutoLot.Services.DataServices.Interfaces;<\/p>\n public interface IMakeDataService : IDataServiceBase The ICarDataService interface implements the IDataServiceBase Add the following global using statement into the GlobalUsing.cs file:<\/p>\n global using AutoLot.Services.DataServices.Interfaces;<\/p>\n The AutoLot.Dal Direct Implementation namespace AutoLot.Services.DataServices.Dal.Base;<\/p>\n public abstract class DalDataServiceBase Add a constructor that takes in an instance of the IBaseRepo protected readonly IBaseRepo Recall that all of the create, read, update, and delete (CRUD) methods on the base interface were defined as Task or Task public async Task<IEnumerable The final method resets the ChangeTracker on the context, clearing it out for reuse:<\/p>\n public void ResetChangeTracker() Add the following global using statements into the GlobalUsings.cs file:<\/p>\n global using AutoLot.Services.DataServices.Dal; global using AutoLot.Services.DataServices.Dal.Base;<\/p>\n Add a new class named MakeDalDataService.cs in the Dal directory and update it to match the following:<\/p>\n namespace AutoLot.Services.DataServices.Dal;<\/p>\n public class MakeDalDataService : DalDataServiceBase Finally, add a class named CarDalDataService.cs and update it to match the following, which implements the one extra method from the interface:<\/p>\n namespace AutoLot.Services.DataServices.Dal;<\/p>\n public class CarDalDataService : DalDataServiceBase The API Initial Implementation namespace AutoLot.Services.DataServices.Api.Base;<\/p>\n public abstract class ApiDataServiceBase public async Task<IEnumerable public async Task DeleteAsync(TEntity entity, bool persist = true) Add the following global using statement into the GlobalUsings.cs file:<\/p>\n global using AutoLot.Services.DataServices.Api; global using AutoLot.Services.DataServices.Api.Base;<\/p>\n Add a new class named MakeDalDataService.cs in the Dal directory and update it to match the following:<\/p>\n namespace AutoLot.Services.DataServices.Api;<\/p>\n public class MakeApiDataService : ApiDataServiceBase Finally, add a class named CarDalDataService.cs and update it to match the following, which implements the one extra method from the interface:<\/p>\n namespace AutoLot.Services.DataServices.Api;<\/p>\n public class CarApiDataService : ApiDataServiceBase public async Task<IEnumerable Adding the Data Services to the DI Container "RebuildDatabase": false, Add the following global using statements to the GlobalUsings.cs file in both the AutoLot.Mvc and AutoLot.Web projects:<\/p>\n global using AutoLot.Services.DataServices.Api; global using AutoLot.Services.DataServices.Dal;<\/p>\n Finally, add a new public static method named AddDataServices() to the DataServiceConfiguration class. In this method, check the value of the UseApi configuration flag, and if it is set to true, add the API versions of the data services classes into the services collection. Otherwise use the data access layer versions:<\/p>\n public static IServiceCollection AddDataServices( this IServiceCollection services, ConfigurationManager config) Call the new extension method in the top level statements in Program.cs in the AutoLot.Mvc and AutoLot.Web projects:<\/p>\n builder.Services.AddRepositories(); The Options Pattern in ASP.NET Core Table 31-6. Some of the IOptions Interfaces<\/p>\n Interface Description Using the Options Pattern { Next, we need to create a view model to hold dealer information. Create a new folder named ViewModels in the AutoLot.Services project. In that folder, add a new class named DealerInfo.cs. Update the class to the following:<\/p>\n namespace AutoLot.Services.ViewModels; public class DealerInfo \u25a0Note the class to be configured must have a public parameterless constructor and be non-abstract. properties are bound but fields are not. Default values can be set on the class properties.<\/p>\n Next, add the following global using statements to the AutoLot.Mvc and AutoLot.Web GlobalUsings. cs files:<\/p>\n global using AutoLot.Services.ViewModels; global using Microsoft.Extensions.Options;<\/p>\n The Configure<>() method of the IServiceCollection maps a section of the configuration files to a specific type. That type can then be injected into classes and views using the options pattern. In the builder.Services.Configure Now that the DealerInfo is configured, instances are retrieved by injection one of the IOptions interfaces into the class constructor, controller action method, or Razor page handler method. Notice that what is injected in is not an instance of the DealerInfo class, but an instance of the IOptions public IActionResult Index([FromServices] IOptionsMonitor The following example replicates the process for the Index Razor page in the Pages folder in the AutoLot.Web project. Instead of passing the instance to the view, it is assigned to a property on the page. Update the Index.cshtml.cs by adding the same injection into the OnGet() method:<\/p>\n public DealerInfo DealerInfoInstance { get; set; } \u25a0Note For more information on the options pattern in aSp.net Core, consult the documentation: https:\/\/docs.microsoft.com\/en-us\/aspnet\/core\/fundamentals\/configuration\/<\/a><\/a><\/a> options?view=aspnetcore-6.0.<\/p>\n The HTTP Client Factory \u25a0Note For information on generating clients, consult the documentation: https:\/\/docs.microsoft<\/a><\/a><\/a>. com\/en-us\/aspnet\/core\/fundamentals\/http-requests?view=aspnetcore-6.0.<\/p>\n Basic Usage builder.Services.AddHttpClient();<\/p>\n Then in the class that needs an HttpClient, inject the IHttpClientFactory into the constructor, and then call CreateClient(): Named Clients using AutoLot.Services.DataServices.Api.Examples; builder.Services.AddHttpClient(NamedUsageWithIHttpClientFactory.API_NAME, client => Then in the class that needs an HttpClient, inject the IHttpClientFactory into the constructor, and then call CreateClient() passing in the name of the client to be created. The configuration from the AddHttpClient() call is used to create the new instance: Typed Clients public class ApiServiceWrapperExample : IApiServiceWrapperExample With the interface and the class in place, they can be added to the service collection as follows:<\/p>\n builder.Services.AddHttpClient<IApiServiceWrapperExample,ApiServiceWrapperExample>();<\/p>\n Inject the IApiServiceWrapper interface into the class that needs to make calls to the API and use the methods on the class instance to call to the API. This pattern completely abstracts the HttpClient away from the calling code: public TypedUsageWithIHttpClientFactory(IApiServiceWrapperExample serviceWrapper) In addition to the configuration options in the constructor of the class, the call to AddHttpClient() can also configure the client:<\/p>\n builder.Services.AddHttpClient<IApiServiceWrapperExample,ApiServiceWrapperExample>(client=> The AutoLot API Service Wrapper Update the Application Configuration "ConnectionStrings": { \u25a0Note Make sure the port number matches your configuration for autoLot.api.<\/p>\n Create the ApiServiceSettings Class public string ApiVersion \u25a0Note api versioning will be covered in depth in Chapter 32.<\/p>\n Add the following global using statement to the GlobalUsings.cs file in the AutoLot.Service project:<\/p>\n global using AutoLot.Services.ApiWrapper.Models;<\/p>\n Register the ApiServiceSettings Class Add the following global using statement to the GlobalUsings.cs file for both the AutoLot.Mvc and AutoLot.Web projects:<\/p>\n global using AutoLot.Services.ApiWrapper.Configuration;<\/p>\n Add the following to the top level statements in Program.cs (in both AutoLot.Mvc and AutoLot.Web) before the call to builder.Build():<\/p>\n builder.Services.ConfigureApiServiceWrapper(builder.Configuration);<\/p>\n The API Service Wrapper Base Class and Interface The IApiServiceWrapperBase Interface namespace AutoLot.Services.ApiWrapper.Interfaces;<\/p>\n public interface IApiServiceWrapperBase Add the following global using statement to the GlobalUsings.cs file for the AutoLot.Services project:<\/p>\n global using AutoLot.Services.ApiWrapper.Interfaces;<\/p>\n The ApiServiceWrapperBase Class global using AutoLot.Services.ApiWrapper.Base; global using Microsoft.Extensions.Options; global using System.Net.Http.Headers; Create a new folder named Base in the ApiWrapper directory of the AutoLot.Services project and add a class named ApiServiceWrapperBase. Make the class public and abstract and implement the namespace AutoLot.Services.ApiWrapper.Base;<\/p>\n public abstract class ApiServiceWrapperBase protected ApiServiceWrapperBase( Configuring the HttpClient in the Constructor public ApiServiceWrapperBase( The Internal Support Methods The Post and Put Helper Methods internal async Task internal async Task The HTTP Delete Helper Method Call internal async Task The HTTP Get Calls public async Task<IList public async Task Notice the improvement in serializing the response body into an item (or list of items). Prior versions of ASP.NET Core would have to use the following code instead of the shorter ReadFromJsonAsync() method:<\/p>\n var result = await JsonSerializer.DeserializeAsync<IList The HTTP Post Call public async Task var location = response.Headers?.Location?.OriginalString; There are two lines of note. The first is the line getting the location. Typically, when an HTTP Post call is successful, the service returns an HTTP 201 (Created at) status code. The service will also add the URI of the newly created resource in the Location header. The preceding code demonstrates getting the Location header but isn\u2019t using the location in the code process. The HTTP Put Call public async Task The HTTP Delete Call public async Task DeleteEntityAsync(TEntity entity) The Entity Specific Interfaces \/\/ICarApiServiceWrapper.cs public interface ICarApiServiceWrapper : IApiServiceWrapperBase \/\/IMakeApiServiceWrapper.cs public interface IMakeApiServiceWrapper : IApiServiceWrapperBase The Entity Specific Classes \/\/CarApiServiceWrapper.cs public class CarApiServiceWrapper : ApiServiceWrapperBase \/\/MakeApiServiceWrapper.cs public class MakeApiServiceWrapper : ApiServiceWrapperBase The MakeApiServiceWrapper only needs the methods exposed in the ApiServiceWrapperBase to do its job. The CarApiServiceWrapper class has one additional method to get the list of Car records by Make. The method follows the same pattern as the base class\u2019s HTTP Get methods but uses a unique end point:<\/p>\n public async Task<IList As a last step, register the two typed clients by updating the ConfigureApiServiceWrapper method in the ServiceConfiguration class to the following:<\/p>\n public static IServiceCollection ConfigureApiServiceWrapper(this IServiceCollection services, IConfiguration config) Complete the API Data Services Complete the ApiDataServiceBase Class protected readonly IApiServiceWrapperBase The implementation for each of the CRUD methods calls the related method on the ServiceWrapper:<\/p>\n public async Task<IEnumerable public async Task DeleteAsync(TEntity entity, bool persist = true) public async Task Complete the Entity Specific Classes public class CarApiDataService : ApiDataServiceBase public class MakeApiDataService : ApiDataServiceBase The GetAllByMakeIdIdAsync() method determines if a value was passed in for the makeId parameter. public async Task<IEnumerable Deploying ASP.NET Core Applications Lightweight and Modular HTTP Request Pipeline Logging public static class LoggerExtensions public static void LogTrace(this ILogger logger, EventId eventId, Exception exception, string message, params object[] args) public static void LogInformation(this ILogger logger, EventId eventId, Exception exception, string message, params object[] args) public static void LogWarning(this ILogger logger, EventId eventId, Exception exception, string message, params object[] args) public static void LogError(this ILogger logger, EventId eventId, Exception exception, string message, params object[] args) public static void LogCritical(this ILogger logger, EventId eventId, Exception exception, string message, params object[] args) public static void Log(this ILogger logger, LogLevel logLevel, string message, params object[] args) Add Logging with Serilog The Logging Settings public class GeneralSettings public class FileSettings $"{Drive}{Path.VolumeSeparatorChar}{Path.DirectorySeparatorChar}{FilePath}{Path. DirectorySeparatorChar}{FileName}"; Add the following global using statement to the GlobalUsings.cs file in the AutoLot.Service project.<\/p>\n global using AutoLot.Services.Logging.Settings;<\/p>\n Next, use the following JSON to replace the scaffolded Logging details in the appsettings. "AppLoggingSettings": { "MSSqlServer": { "File": { "Drive": "c", Next, add the following AppName node to each of the files, customized for each app:<\/p>\n \/\/AutoLot.Api "AppName":"AutoLot.Api - Dev"<\/p>\n \/\/AutoLot.Mvc "AppName":"AutoLot.Mvc - Dev"<\/p>\n \/\/AutoLot.Web "AppName":"AutoLot.Web - Dev"<\/p>\n For reference, here is the complete listing for each project (notice the extra line at the beginning of the AutoLot.Web file \u2013 that will be covered in chapter 34):<\/p>\n \/\/AutoLot.Api \/\/AutoLot.Mvc "TableName": "SeriLogs", "Schema": "Logging", "ConnectionStringName": "AutoLot" \/\/AutoLot.Web "ApiServiceSettings": { The final step is to clear out the Logging section of each of the appsettings.json files, leaving just the AllowedHosts entry in the AutoLot.Api project, and the AllowedHosts and the DealerInfo in the AutoLot. Mvc and AutoLot.Web projects:<\/p>\n \/\/AutoLot.Api \/\/AutoLot.Mvc \/\/AutoLot.Web The Logging Configuration Serilog uses sinks to write to different logging targets. With this mechanism, a single call to SeriLog will write to many places. The targets we will use for logging in the ASP.NET Core apps are a text file, the internal static readonly string OutputTemplate = The SQL Server sink needs a list of columns identified using the SqlColumn type. Add the following code to configure the database columns:<\/p>\n internal static readonly ColumnOptions ColumnOptions = new ColumnOptions Swapping the default logger with Serilog is a three-step process. The first is to clear the existing provider, the second is to add Serilog into the WebApplicationBuilder, and the third is to finish configuring Serilog. Add a new method named ConfigureSerilog(), which is an extension method for the WebApplicationBuilder. The first line clears out the default loggers, and the last line adds the fully configured Serilog framework into the WebApplicationBuilder\u2018s logging framework.<\/p>\n public static void ConfigureSerilog(this WebApplicationBuilder builder) SchemaName = schema, TableName = tableName, var log = new LoggerConfiguration() With everything in place, it\u2019s time to create the logging framework that will use Serilog.<\/p>\n The AutoLot Logging Framework The IAppLogging Interface void LogAppError(string message, [CallerMemberName] string memberName = "", [CallerFilePath] string sourceFilePath = "", [CallerLineNumber] int sourceLineNumber = 0);<\/p>\n void LogAppCritical(Exception exception, string message, [CallerMemberName] string memberName = "", [CallerFilePath] string sourceFilePath = "", [CallerLineNumber] int sourceLineNumber = 0);<\/p>\n void LogAppCritical(string message, [CallerMemberName] string memberName = "", [CallerFilePath] string sourceFilePath = "", [CallerLineNumber] int sourceLineNumber = 0);<\/p>\n void LogAppDebug(string message, [CallerMemberName] string memberName = "", [CallerFilePath] string sourceFilePath = "", [CallerLineNumber] int sourceLineNumber = 0);<\/p>\n void LogAppTrace(string message, [CallerMemberName] string memberName = "", [CallerFilePath] string sourceFilePath = "", [CallerLineNumber] int sourceLineNumber = 0);<\/p>\n void LogAppInformation(string message, [CallerMemberName] string memberName = "", [CallerFilePath] string sourceFilePath = "", [CallerLineNumber] int sourceLineNumber = 0);<\/p>\n void LogAppWarning(string message, [CallerMemberName] string memberName = "", [CallerFilePath] string sourceFilePath = "", [CallerLineNumber] int sourceLineNumber = 0); The attributes CallerMemberName, CallerFilePath, and CallerLineNumber inspect the call stack to get the values they are named for from the calling code. For example, if the line that calls LogAppWarning() is in the DoWork() function, in a file named MyClassFile.cs, and resides on line number 36, then the call:<\/p>\n _appLogger.LogAppError(ex, "ERROR!");<\/p>\n is converted into the equivalent of this:<\/p>\n _appLogger.LogAppError(ex,"ERROR","DoWork ","c:\/myfilepath\/MyClassFile.cs",36);<\/p>\n If values are passed into the method call for any of the attributed parameters, the values passed in are used instead of the values from the attributes. global using AutoLot.Services.Logging.Interfaces;<\/p>\n The AppLogging Class namespace AutoLot.Services.Logging;<\/p>\n public class AppLogging public AppLogging(ILogger Serilog enables adding additional properties into the standard logging process by pushing them onto the LogContext. Add an internal method to log an event with an exception and push the MemberName, FilePath, and LineNumber properties. The PushProperty() method returns an IDisposable, so the method disposes everything before leaving the method.<\/p>\n internal static void LogWithException(string memberName, Repeat the process for log events that don\u2019t include an exception:<\/p>\n internal static void LogWithoutException(string memberName, string sourceFilePath, int sourceLineNumber, string message, Action<string, object[]> logAction) logAction(message, null); foreach (var item in list) For each type of logging event, call the appropriate help method to write to the logs:<\/p>\n public void LogAppError(Exception exception, string message, [CallerMemberName] string memberName = "", [CallerFilePath] string sourceFilePath = "", [CallerLineNumber] int sourceLineNumber = 0) public void LogAppError(string message, [CallerMemberName] string memberName = "", [CallerFilePath] string sourceFilePath = "", [CallerLineNumber] int sourceLineNumber = 0) public void LogAppCritical(Exception exception, string message, [CallerMemberName] string memberName = "", public void LogAppCritical(string message, [CallerMemberName] string memberName = "", [CallerFilePath] string sourceFilePath = "", [CallerLineNumber] int sourceLineNumber = 0) public void LogAppDebug(string message, [CallerMemberName] string memberName = "", [CallerFilePath] string sourceFilePath = "", [CallerLineNumber] int sourceLineNumber = 0) public void LogAppTrace(string message, [CallerMemberName] string memberName = "", [CallerFilePath] string sourceFilePath = "", [CallerLineNumber] int sourceLineNumber = 0) public void LogAppInformation(string message, [CallerMemberName] string memberName = "", [CallerFilePath] string sourceFilePath = "", [CallerLineNumber] int sourceLineNumber = 0) public void LogAppWarning(string message, [CallerMemberName] string memberName = "", [CallerFilePath] string sourceFilePath = "", [CallerLineNumber] int sourceLineNumber = 0) Final Configuration public static IServiceCollection RegisterLoggingInterfaces(this IServiceCollection services) Next, add the following global using statement to the GlobalUsings.cs file in each web project:<\/p>\n global using AutoLot.Services.Logging.Configuration; global using AutoLot.Services.Logging.Interfaces;<\/p>\n Next, add both of the extension methods to the top level statements in the Program.cs file. Note that the ConfigureSerilog() method extends off of the WebAppBuilder (the builder variable) and the RegisterLoggingInterfaces() method extends off of the IServiceCollection:<\/p>\n \/\/Configure logging builder.ConfigureSerilog(); builder.Services.RegisterLoggingInterfaces();<\/p>\n Add Logging to the Data Services Update the Base Classes \/\/ApiDataServiceBase.cs \/\/DalDataServiceBase.cs Next, update each of the constructors to take an instance of IAppLogging \/\/CarApiDataService.cs protected ApiDataServiceBase(IAppLogging \/\/MakeApiDataService.cs protected DalDataServiceBase(IAppLogging Update the Entity Specific Data Services Classes \/\/CarApiDataService.cs \/\/MakeApiDataService.cs \/\/CarDalDataService.cs \/\/MakeApiDataService.cs Next, update the constructors to take the instance of IAppLogging Test-Drive the Logging Framework
\nA. Troelsen and P. Japikse, Pro C# 10 with .NET 6, https:\/\/doi.org\/10.1007\/978-1-4842-7869-7_31<\/a><\/a><\/a><\/p>\n
\nJust like MVC based web applications, the Razor page file is responsible for rendering the content of the page, and receiving input from the user. It should be lightweight, and hand off work to the PageModel class. Razor page files will be explored in depth in Chapter 34.<\/p>\n
\nLike the Controller class for MVC style applications, the PageModel class provides helper methods for Razor page based web applications. Razor pages derive from the PageModel class, and are typically named with the Model suffix, like CreateModel. The Model suffix is dropped when routing to a page. Table 31-1 lists the most commonly used methods and Table 31-2 lists the HTTP Status Code Helpers.<\/p>\n
\nHttpContext Returns the HttpContext for the currently executing action.
\nRequest Returns the HttpRequest for the currently executing action.
\nResponse Returns the HttpResponse for the currently executing action.
\nRouteData Returns the RouteData for the currently executing action (routing is covered later in this chapter).
\nModelState Returns the state of the model in regard to model binding and validation (both covered later in this chapter).
\nUrl Returns an instance of the IUrlHelper, providing access to building URLs for ASP.NET Core MVC applications and services.
\nViewData TempData Provide data to the view through the ViewDataDictionary and
\nTempDataDictionary
\nPage Returns a PageResult (derived from ActionResult) as the HTTP response.
\nPartialView Returns a PartialViewResult to the response pipeline.
\nViewComponent Returns a ViewComponentResult to the response pipeline.
\nOnPageHandlerSelected Executes when a page handler method is selected but before model binding.
\nOnPageHandlerExecuting Executes before a page handler method executes.
\nOnPageHandlerExecutionAsync Async version of OnPageHandlerExecuting.
\nOnPageHandlerExecuted Executes after a page handler method executes.
\n(continued)<\/p>\n
\nOnPageHandlerSelectionAsync Async version of OnPageHandlerSelected.
\nUser Returns the ClaimsPrincipal user.
\nContent Returns a ContentResult to the response. Overloads allow for adding a content type and encoding definition.
\nFile Returns a FileContentResult to the response.
\nRedirect A series of methods that redirect the user to another URL by returning a
\nRedirectResult.
\nLocalRedirect A series of methods that redirect the user to another URL only if the URL is local. More secure than the generic Redirect methods.
\nRedirectToAction RedirectToPage RedirectToRoute A series of methods that redirect to another action method, Razor Page, or named route. Routing is covered later in this chapter.
\nTryUpdateModelAsync Used for explicit model binding.
\nTryValidateModel Used for explicit model validation.<\/p>\n
\nNotFound NotFoundResult 404
\nForbid ForbidResult 403
\nBadRequest BadRequestResult 400
\nStatusCode(int)StatusCode(int, object) StatusCodeResultObjectResult Defined by the int parameter.<\/p>\n
\nAs discussed in the routing section, Razor pages define handler methods to handle HTTP Get and Post requests. The PageModel class supports both synchronous and asynchronous handler methods. The verb handled is based on the name of the method, with OnPost()\/OnPostAsync() handling HTTP post requests, and OnGet()\/OnGetAsync() handling HTTP get requests. The async versions are listed here:<\/p>\n
\n{
\npublic async Task
\n{
\n\/\/handle the get request here
\n}<\/p>\n
\n{
\n\/\/handle the post request here
\n}
\n}<\/p>\n
\nASP.NET Core applications\u2019 awareness of their execution environment includes host environment variables and file locations through an instance of IWebHostEnvironment, which implement the IHostEnvironment interface. Table 31-3 shows the properties available through these interfaces.<\/p>\n
\nApplicationName Gets or sets the name of the application. Defaults to the name of the entry assembly.
\nContentRootPath Gets or sets the absolute path to the directory that contains the application content files.
\nContentRootFileProvider Gets or sets an IFileProvider pointing to the ContentRootPath.
\nEnvironmentName Gets or sets the name of the environment. Sets to the value of the ASPNETCORE_ ENVIRONMENT environment variable.
\nWebRootFileProvider Gets or sets an IFileProvider pointing at the WebRootPath.
\nWebRootPath Gets or sets the absolute path to the directory that contains the web-servable application content files.<\/p>\n
\nASP.NET Core automatically reads the value of the environment variable named ASPNETCORE_ENVIRONMENT
\nto set the runtime environment. If the ASPNETCORE_ENVIRONMENT variable is not set, ASP.NET Core sets the value to Production. The value set is accessible through the EnvironmentName property on the IWebHostEnvironment.
\nWhile developing ASP.NET Core applications, this variable is typically set using the launchSettings. json file or the command line. Downstream environments (staging, production, etc.) typically use standard operating system environment variables.
\nYou are free to use any name for the environment or the three that are supplied by the Environments
\nstatic class.<\/p>\n
\n{
\npublic static readonly string Development = "Development"; public static readonly string Staging = "Staging";
\npublic static readonly string Production = "Production";
\n}<\/p>\n
\nIsProduction Returns true if the environment variable is set to Production (case insensitive)
\nIsStaging Returns true if the environment variable is set to Staging (case insensitive)
\nIsDevelopment Returns true if the environment variable is set to Development (case insensitive)
\nIsEnvironment Returns true if the environment variable matches the string passed into the method (case insensitive)<\/p>\n
\n\u2022Determining which configuration files to load
\n\u2022Setting debugging, error, and logging options
\n\u2022Loading environment-specific JavaScript and CSS files
\nExamine the Program.cs file in the AutoLot.Mvc project. Near the end of the file, the environment is checked to determine if the standard exception handler and HSTS (HTTP Strict Transport Security Protocol) should be used:<\/p>\n
\n{
\napp.UseExceptionHandler("\/Home\/Error"); app.UseHsts();
\n}<\/p>\n
\n{
\n}
\nelse
\n{
\napp.UseExceptionHandler("\/Home\/Error"); app.UseHsts();
\n}<\/p>\n
\n{
\napp.UseDeveloperExceptionPage();
\n}
\nelse
\n{
\napp.UseExceptionHandler("\/Home\/Error"); app.UseHsts();
\n}<\/p>\n
\n{
\napp.UseDeveloperExceptionPage();
\n}
\nelse
\n{
\napp.UseExceptionHandler("\/Error"); app.UseHsts();
\n}<\/p>\n
\n{
\n\/\/more code to be placed here later
\n}
\napp.UseSwagger(); app.UseSwaggerUI();<\/p>\n
\nUnlike classic ASP.NET MVC or ASP.NET Web API applications, ASP.NET Core applications are .NET console applications that create and configure a WebApplication, which is an instance of IHost. The creation of configuration of the IHost is what sets the application up to listen and respond to HTTP requests.
\nThe default templates for ASP.NET Core 6 MVC, Razor, and Service application are minimal. These files will be added to as you progress through the ASP.NET Core chapters.<\/p>\n
\nOpen the Program.cs class in the AutoLot.Api application, and examine the contents, shown here for reference:<\/p>\n
\n\/\/ Add services to the container. builder.Services.AddControllers();
\n\/\/ Learn more about configuring Swagger\/OpenAPI at https:\/\/aka.ms\/aspnetcore\/swashbuckle<\/a><\/a><\/a> builder.Services.AddEndpointsApiExplorer();
\nbuilder.Services.AddSwaggerGen(); var app = builder.Build();
\n\/\/ Configure the HTTP request pipeline. if (app.Environment.IsDevelopment())
\n{
\n\/\/more code to be placed here later
\n}
\napp.UseSwagger(); app.UseSwaggerUI();<\/p>\n
\nProgram.cs file and the ConfigureServices() method in the Startup.cs file and is responsible for creating<\/p>\n
\nThe CreateBuilder() method compacts the most typical application setup into one method call. It configures the app (using environment variables and appsettings JSON files), it configures the default logging provider, and it sets up the dependency injection container. The returned WebApplicationBuilder is used to register services, add additional configuration information, logging support, etc.
\nThe next set of methods adds the necessary base services into the dependency injection container for building RESTful services. The AddControllers() method adds in support for using controllers and action methods, the AddEndpointsApiExplorer() method provides information about the API (and is used by Swagger), and AddSwaggerGen() creates the basic OpenAPI support.<\/p>\n
\nOpen the Program.cs class in the AutoLot.Mvc application, and examine the contents, shown here for reference (with differences from the AutoLot.Api application\u2019s file in bold):<\/p>\n
\n\/\/ Configure the HTTP request pipeline.
\nif (app.Environment.IsDevelopment())
\n{
\napp.UseDeveloperExceptionPage();
\n}
\nelse
\n{
\napp.UseExceptionHandler("\/Home\/Error"); app.UseHsts();
\n}<\/p>\n
\napp.UseStaticFiles();<\/p>\n
\npattern: "{controller=Home}\/{action=Index}\/{id?}");<\/p>\n
\nThe next difference is the call to UserExceptionHandler() when the application is not running in a development environment. This is a user friendly exception handler that displays simple information
\n(and no technical debugging data). That is followed by the UseHsts() method, which turns on HTTP Strict Transport Security, preventing users to switch back to HTTP once they have connected. It also prevents them from clicking through warnings regarding invalid certificates.
\nThe call to UseStaticFiles() enables static content (images, JavaScript files, CSS files, etc.) to be rendered through the application. This call is not in the API style applications, as they don\u2019t typically have a need to render static content. The final changes add end point routing support and the default route to the application.<\/p>\n
\nOpen the Program.cs class in the AutoLot.Web application, and examine the contents, shown here for reference (with the differences from the AutoLot.Mvc application shown in bold):<\/p>\n
\n\/\/ Add services to the container.<\/p>\n
\nvar app = builder.Build();<\/p>\n
\n{
\napp.UseDeveloperExceptionPage();
\n}
\nelse
\n{
\napp.UseExceptionHandler("\/Error"); app.UseHsts();
\n}
\napp.UseHttpsRedirection(); app.UseStaticFiles(); app.UseRouting(); app.UseAuthorization(); app.MapRazorPages(); app.Run();<\/p>\n
\nPrevious versions of ASP.NET used the web.config file to configure services and applications, and developers accessed the configuration settings through the System.Configuration class. Of course, all configuration settings for the site, not just application-specific settings, were dumped into the web.config file making it a (potentially) complicated mess.
\nASP.NET Core leverages the new .NET JSON-based configuration system first introduced in Chapter 16.
\nAs a reminder, it\u2019s based on simple JSON files that hold configuration settings. The default file for configuration is the appsettings.json file. The initial version of appsettings.json file (created by the ASP. NET Core web application and API service templates) simply contains configuration information for the logging, as well as allowing all hosts (e.g. https:\/\/localhost:xxxx<\/a><\/a><\/a>) to bind to the app:<\/p>\n
\n"Logging": {
\n"LogLevel": {
\n"Default": "Information", "Microsoft.AspNetCore": "Warning",
\n}
\n},
\n"AllowedHosts": "*"
\n}<\/p>\n
\non the runtime environment. This is accomplished by instructing the configuration system to load a file named appsettings.{environmentname}.json after the appSettings.json file. When running under Development, the appsettings.Development.json file is loaded after the initial settings file. If the environment is Staging, the appsettings.Staging.json file is loaded, etc. It is important to note that when more than one file is loaded, any settings that appear in both files are overwritten by the last file loaded; they are not additive.
\nFor each of the web application projects, add the following connection string information (updating the actual connection string to match your environment from Chapter 23 into the appsettings.Development. json files:<\/p>\n
\n"AutoLot": "Server=.,5433;Database=AutoLot;User ID=sa;Password=P@ssw0rd;"
\n}<\/p>\n
\nProduction.json into each of the web application projects. Update the connection string entries to the following:<\/p>\n
\n},<\/p>\n
\ninstance:<\/p>\n
\nDependency injection (DI) is a mechanism to support loose coupling between objects. Instead of directly creating dependent objects or passing specific implementations into classes and\/or methods, parameters are defined as interfaces. That way, any implementation of the interface can be passed into the classes or methods and classes, dramatically increasing the flexibility of the application.
\nDI support is one of the main tenets in the rewrite ASP.NET Core. Not only do the top level statements in the Program.cs file (covered later in this chapter) accept all the configuration and middleware services through dependency injection, your custom classes can (and should) also be added to the service container to be injected into other parts of the application. When an item is configured into the ASP.NET Core DI container, there are three lifetime options, as shown in Table 31-5.<\/p>\n
\nTransient Created each time they are needed.
\nScoped Created once for each request. Recommended for Entity Framework DbContext objects.
\nSingleton Created once on first request and then reused for the lifetime of the object. This is the recommended approach versus implementing your class as a Singleton.<\/p>\n
\nWhen using the top level statements template in .NET 6 web applications, the IServiceCollection is instantiated by the WebApplicationBuilder, and this instance is used to add services into the container.
\nWhen adding services to the DI container, make sure to add them before the line that builds the
\nWebApplication object:<\/p>\n
\nWhen creating MVC based web applications, the AddControllersWithView() method adds in the necessary services to support the MVC pattern in ASP.NET Core. The following code (in the Program.cs file of the AutoLot.Mvc project) accesses the IServiceCollection of the WebApplicationBuilder and adds the required DI support for controllers and views:<\/p>\n
\n\/\/ Add services to the container. builder.Services.AddControllersWithViews();<\/p>\n
\n\/\/ Add services to the container. builder.Services.AddControllers(); builder.Services.AddEndpointsApiExplorer(); builder.Services.AddSwaggerGen();<\/p>\n
\nAddRazorPages() method:<\/p>\n
\n\/\/ Add services to the container. builder.Services.AddRazorPages();<\/p>\n
\nRegistering a derived DbContext class in an ASP.NET Core application allows the DI container to handle the initialization and lifetime of the context. The AddDbContext<>()\/AddDbContextPool() methods add a properly configured context class into the DI container. The AddDbContextPool() version creates a pool of instances that are cleaned between requests, ensuring that there isn\u2019t any data contamination between
\nrequests. This can improve performance in your application, as it eliminates the startup cost for creating a context once it is added to the pool.
\nStart by adding the following global using statements into the GlobalUsings.cs for the AutoLot.Api, AutoLot.Mvc, AutoLot.Web projects:<\/p>\n
\noptions => options.UseSqlServer(connectionString,
\nsqlOptions => sqlOptions.EnableRetryOnFailure().CommandTimeout(60)));<\/p>\n
\nEF Core 6 introduced a set of minimal APIs for adding derived DbContext classes into the services collection. Instead of the previous code, you can use the following short cut:<\/p>\n
\n{
\noptions.EnableRetryOnFailure().CommandTimeout(60);
\n});<\/p>\n
\nApplication services (like the repositories in the AutoLot.Dal project) can be added into the DI container using one of the lifetime options from Table 31-5. For example, to add the CarRepo as a service into the DI container, you would use the following<\/p>\n
\nBefore creating the extension method, update the GlobalUsings.cs file in the AutoLot.Services project to the following:<\/p>\n
\nglobal using AutoLot.Dal.Repos.Interfaces;<\/p>\n
\nglobal using Microsoft.Extensions.Logging;<\/p>\n
\nglobal using Serilog.Context;
\nglobal using Serilog.Core.Enrichers; global using Serilog.Events;
\nglobal using Serilog.Sinks.MSSqlServer;<\/p>\n
\nglobal using System.Runtime.CompilerServices;<\/p>\n
\nnamespace AutoLot.Services.DataServices; public static class DataServiceConfiguration
\n{
\npublic static IServiceCollection AddRepositories(this IServiceCollection services)
\n{
\nservices.AddScoped<ICarDriverRepo, CarDriverRepo>(); services.AddScoped<ICarRepo, CarRepo>(); services.AddScoped<ICreditRiskRepo, CreditRiskRepo>();
\nservices.AddScoped<ICustomerOrderViewModelRepo, CustomerOrderViewModelRepo>();<\/p>\n
\n}
\n}<\/p>\n
\nWhen there is a chain of dependencies, all dependencies must be added into the DI container, or a run- time error will occur when the DI container tries to instantiate the concrete class. If you recall from our repositories, they each had a public constructor that took an instance of the ApplicationDbContext, which was added into the DI container before adding in the repositories. If ApplicationDbContext was not in the DI container, then the repositories that depend on it can\u2019t be constructed.<\/p>\n
\nServices in the DI container can be injected into class constructors and methods, into Razor views, and Razor pages and PageModel classes. When injecting into the constructor of a controller or PageModel class, add the type to be injected into the constructor, like this:<\/p>\n
\npublic class CarsController : Controller
\n{
\nprivate readonly ICarRep _repo; public CarsController(ICarRepo repo)
\n{
\n_repo = repo;
\n}
\n\/\/omitted for brevity
\n}<\/p>\n
\npublic class CreateModel : PageModel
\n{
\nprivate readonly ICarRepo _repo;<\/p>\n
\n{
\n_repo = repo;
\n}
\n\/\/omitted for brevity
\n}<\/p>\n
\npublic class CarsController : Controller
\n{
\n[HttpPost] [ValidateAntiForgeryToken]
\npublic async Task
\n{
\n\/\/do something
\n}
\n\/\/omitted for brevity
\n}<\/p>\n
\npublic class CreateModel : PageModel
\n{
\npublic async Task
\n{
\n\/\/do somethng
\n}
\n\/\/omitted for brevity
\n}<\/p>\n
\nYou might be wondering how to get dependencies out of the DI container when you are in the top level statements in the Program.cs file. For example, if you want to initialize the database, you need an instance of the ApplicationDbContext. There isn\u2019t a constructor, action method, page handler method, or view to inject the instance into.<\/p>\n
\nto hold the service. Then get the ServiceProvider from the IServiceScope, which will then provide the services within the current scope.
\nSuppose you want to selectively clear and reseed the database when running in the development environment. To set this up, first add the following line to the appsettings.Development.json files in each of the web projects:<\/p>\n
\n{
\napp.UseDeveloperExceptionPage();
\n\/\/Initialize the database
\nif (app.Configuration.GetValue
\n{
\nusing var scope = app.Services.CreateScope();
\nvar dbContext = scope.ServiceProvider.GetRequiredService
\n}
\n}<\/p>\n
\n{
\n\/\/Initialize the database
\nif (app.Configuration.GetValue
\n{
\nusing var scope = app.Services.CreateScope();
\nvar dbContext = scope.ServiceProvider.GetRequiredService
\n}
\n}<\/p>\n
\nTo wrap up the discussion on dependency injection, we are going to build a set of data services that will be used by both the AutoLot.Mvc and AutoLot.Web projects. The goal of the services is to present a single set of interfaces for all data access. There will be two concrete implementations of the interfaces, one that will call into the AutoLot.Api project and another one that will call into the AutoLot.Dal code directly. The concrete implementations that are added into the DI container will be determined by a project configuration setting.<\/p>\n
\nStart by creating a new directory named Interfaces in the DataServices directory of the AutoLot.Services project. Next, add the following IDataServiceBase
\n{
\nTask<IEnumerable
\nTask
\n\/\/implemented ghost method since it won\u2019t be used by the API data service void ResetChangeTracker() {}
\n}<\/p>\n
\n{
\n}<\/p>\n
\nnamespace AutoLot.Services.DataServices.Interfaces; public interface ICarDataService : IDataServiceBase
\n{
\nTask<IEnumerable
\n}<\/p>\n
\nStart by creating a new directory named Dal in the DataServices directory, and add a new directory named Base in the Dal directory. Add a new class named DalServiceBase, make it public abstract and implement the IDataServiceBase
\n{
\n\/\/implementation goes here
\n}<\/p>\n
\nprotected DalDataServiceBase(IBaseRepo
\n{
\nMainRepo = mainRepo;
\n}<\/p>\n
\nThe base methods call the related methods in the MainRepo:<\/p>\n
\n=> MainRepo.GetAllIgnoreQueryFilters();
\npublic async Task
\npublic async Task
\n{
\nMainRepo.Update(entity, persist); return entity;
\n}
\npublic async Task DeleteAsync(TEntity entity, bool persist = true)
\n=> MainRepo.Delete(entity, persist);
\npublic async Task
\n{
\nMainRepo.Add(entity, persist); return entity;
\n}<\/p>\n
\n{
\nMainRepo.Context.ChangeTracker.Clear();
\n}<\/p>\n
\n{
\npublic MakeDalDataService(IMakeRepo repo):base(repo) { }
\n}<\/p>\n
\n{
\nprivate readonly ICarRepo _repo;
\npublic CarDalDataService(ICarRepo repo) : base(repo)
\n{
\n_repo = repo;
\n}
\npublic async Task<IEnumerable
\n? _repo.GetAllBy(makeId.Value)
\n: MainRepo.GetAllIgnoreQueryFilters();
\n}<\/p>\n
\nMost of the implementation for the API version of the data services will be completed after you create the HTTP client factory in the next section. This section will just create the classes to illustrate toggling
\nimplementations for interfaces. Start by creating a new directory named Api in the DataServices directory, and add a new directory named Base in the Api directory. Add a new class named ApiServiceBase, make it public abstract and implement the IDataServiceBase
\n{
\nprotected ApiDataServiceBase()
\n{
\n}<\/p>\n
\n=> throw new NotImplementedException();
\npublic async Task
\n{
\nthrow new NotImplementedException();
\n}<\/p>\n
\n=> throw new NotImplementedException();
\npublic async Task
\n{
\nthrow new NotImplementedException();
\n}
\n}<\/p>\n
\n{
\npublic MakeApiDataService():base()
\n{
\n}
\n}<\/p>\n
\n{
\npublic CarApiDataService() :base()
\n{
\n}<\/p>\n
\n}<\/p>\n
\nThe final step is to add the ICarDataService and IMakeDataService into the services collection. Start by adding the following line into the appsettings.Development.json and appsettings.Production.json files in the AutoLot.Mvc and AutoLot.Web project:<\/p>\n
\n"UseApi": false,<\/p>\n
\n{
\nif (config.GetValue
\n{
\nservices.AddScoped<ICarDataService, CarApiDataService>(); services.AddScoped<IMakeDataService, MakeApiDataService>();
\n}
\nelse
\n{
\nservices.AddScoped<ICarDataService, CarDalDataService>(); services.AddScoped<IMakeDataService, MakeDalDataService>();
\n}
\nreturn services;
\n}<\/p>\n
\nbuilder.Services.AddDataServices(builder.Configuration);<\/p>\n
\nThe options pattern provides a mechanism to instantiate classes from configured settings and inject the configured classes into other classes through dependency injection. The classes are injected into another class using one of the versions of IOptions
\nIOptionsMonitor
\nIOptionsMonitorCache
\nIOptionsSnaphot
\nIOptionsFactory
\nIOptions
\nA simple example is to retrieve car dealer information from the configuration, configure a class with that data, and inject it into a controller\u2019s action method for display. By placing the information into the settings file, the data is customizable without having to redeploy the site.
\nStart by adding the dealer information into the appsettings.json files for the AutoLot.Mvc and AutoLot.Web projects:<\/p>\n
\n"Logging": {
\n"LogLevel": {
\n"Default": "Information", "Microsoft.AspNetCore": "Warning"
\n}
\n},
\n"AllowedHosts": "*",
\n"DealerInfo": {
\n"DealerName": "Skimedic's Used Cars", "City": "West Chester",
\n"State": "Ohio"
\n}
\n}<\/p>\n
\n{
\npublic string DealerName { get; set; } public string City { get; set; } public string State { get; set; }
\n}<\/p>\n
\nProgram.cs files for the AutoLot.Mvc and AutoLot.Web Program.cs files, add the following after the line used to configure the repositories:<\/p>\n
\n(IOptionsSnapshot
\n{
\nvar vm = dealerMonitor.CurrentValue;
\nreturn View(vm);
\n}<\/p>\n
\npublic void OnGet([FromServices]IOptionsMonitor
\n{
\nDealerInfoInstance = dealerOptions.CurrentValue;
\n}<\/p>\n
\nASP.NET Core 2.1 introduced the IHTTPClientFactory, which can be used to create and configure HttPClient instances. The factory manages the pooling and lifetime of the underlying HttpClientMessageHandler instance, abstracting that away from the developer. It provides four mechanisms of use:
\n\u2022Basic usage
\n\u2022Named clients,
\n\u2022Typed clients, and
\n\u2022Generated clients.
\nAfter exploring the basic, named client, and typed client usages, we will build the API service wrappers that will be utilized by the data services built earlier in this chapter.<\/p>\n
\nThe basic usage registers the IHttpClientFactory with the services collection, and then uses the injected factory instance to create HttPClient instances. This method is a convenient way to refactor an existing application that is creating HttPClient instances. To implement this basic usage, add the following line into the top level statements in Program.cs (no need to actually do this, as the projects will use Typed clients):<\/p>\n
\nnamespace AutoLot.Services.DataServices.Api.Examples; public class BasicUsageWithIHttpClientFactory
\n{
\nprivate readonly IHttpClientFactory _clientFactory;
\npublic BasicUsageWithIHttpClientFactory(IHttpClientFactory clientFactory)
\n{
\n_clientFactory = clientFactory;
\n}
\npublic async Task DoSomethingAsync()
\n{
\nvar client = _clientFactory.CreateClient();
\n\/\/do something interesting with the client
\n}
\n}<\/p>\n
\nNamed clients are useful when your application uses distinct HttpClient instances, especially when they are configured differently. When registering the IHttpClientFactory, a name is provided along with any specific configuration for that HttpClient usage. To create a client named AutoLotApi, add the following into the top level statements in Program.cs (no need to actually do this, as the projects will use Typed clients):<\/p>\n
\n{
\n\/\/add any configuration here
\n});<\/p>\n
\nnamespace AutoLot.Services.DataServices.Api.Examples; public class NamedUsageWithIHttpClientFactory
\n{
\npublic const string API_NAME = "AutoLotApi"; private readonly IHttpClientFactory _clientFactory;
\npublic NamedUsageWithIHttpClientFactory(IHttpClientFactory clientFactory)
\n{
\n_clientFactory = clientFactory;
\n}
\npublic async Task DoSomethingAsync()
\n{
\nvar client = _clientFactory.CreateClient(API_NAME);
\n\/\/do something interesting with the client
\n}
\n}<\/p>\n
\nTyped clients are classes that accept an HttpClient instance through injection into its constructor. Since the typed client is a class, it can be added into the service collection and injected into other classes,
\nfully encapsulating the calls using an HttpClient. As an example, suppose you have a class named
\nApiServiceWrapper that takes in an HttpClient and implements IApiServiceWrapper as follows:
\nnamespace AutoLot.Services.DataServices.Api.Examples; public interface IApiServiceWrapperExample
\n{
\n\/\/interesting methods places here
\n}<\/p>\n
\n{
\nprotected readonly HttpClient Client;
\npublic ApiServiceWrapperExample(HttpClient client)
\n{
\nClient = client;
\n\/\/common client configuration goes here
\n}
\n\/\/interesting methods implemented here
\n}<\/p>\n
\nnamespace AutoLot.Services.DataServices.Api.Examples; public class TypedUsageWithIHttpClientFactory
\n{
\nprivate readonly IApiServiceWrapperExample _serviceWrapper;<\/p>\n
\n{
\n_serviceWrapper = serviceWrapper;
\n}
\npublic async Task DoSomethingAsync()
\n{
\n\/\/do something interesting with the service wrapper
\n}
\n}<\/p>\n
\n{
\n\/\/configuration goes here
\n});<\/p>\n
\nThe AutoLot API service wrapper uses a typed base client and entity specific typed clients to encapsulate all of the calls to the AutoLot.Api project. Both the AutoLot.Mvc and AutoLot.Web projects will use the service wrapper through the data services classes stubbed out earlier in this chapter and completed at the end of this section. The AutoLot.Api project will be finished in the next chapter.<\/p>\n
\nThe AutoLot.Api application endpoints will vary based on the environment. For example, when developing on your workstation, the base URI is https:\/\/localhost:5011<\/a><\/a><\/a>. In your integration environment, the URI might be https:\/\/mytestserver.com<\/a><\/a><\/a>. The environmental awareness, in conjunction with the updated configuration system, will be used to add these different values.
\nThe appsettings.Development.json file will add the service information for the local machine. As code moves through different environments, the settings would be updated in each environment\u2019s specific file to match the base URI and endpoints for that environment. In this example, you only update the settings for the development environment. In the appsettings.Development.json files in the AutoLot.Mvc and AutoLot.Web projects, add the following after the ConnectionStrings entry (changes in bold):<\/p>\n
\n"AutoLot": "Server=.,5433;Database=AutoLot;User ID=sa;Password=P@ssw0rd;"
\n},
\n"ApiServiceSettings": {
\n"Uri": "https:\/\/localhost:5011\/<\/a><\/a><\/a>", "UserName": "AutoLotUser", "Password": "SecretPassword", "CarBaseUri": "api\/v1\/Cars", "MakeBaseUri": "api\/v1\/Makes", "MajorVersion": 1,
\n"MinorVersion": 0, "Status": ""
\n}<\/p>\n
\nThe service settings will be populated from the settings the same way the dealer information was populated. In the AutoLot.Service project, create a new folder named ApiWrapper and in that folder, create a new folder named Models. In this folder, add a class named ApiServiceSettings.cs. The property names of the class need to match the property names in the JSON ApiServiceSettings section. The class is listed here:
\nnamespace AutoLot.Services.ApiWrapper.Models; public class ApiServiceSettings
\n{
\npublic ApiServiceSettings() { } public string UserName { get; set; } public string Password { get; set; } public string Uri { get; set; }
\npublic string CarBaseUri { get; set; } public string MakeBaseUri { get; set; } public int MajorVersion { get; set; } public int MinorVersion { get; set; } public string Status { get; set; }<\/p>\n
\n=> $"{MajorVersion}.{MinorVersion}" + (!string.IsNullOrEmpty(Status)?$"-
\n{Status}":string.Empty);
\n}<\/p>\n
\nWe are once again going to use an extension method to register everything needed for the API service wrapper, including configuring the ApiServiceSettings.cs using the Options pattern. Create a new folder named Configuration under the ApiWrapper folder, and in that folder create a new public static class named ServiceConfiguration, as shown here:
\nnamespace AutoLot.Services.ApiWrapper.Configuration; public static class ServiceConfiguration
\n{
\npublic static IServiceCollection ConfigureApiServiceWrapper(this IServiceCollection services, IConfiguration config)
\n{
\nservices.Configure
\n}
\n}<\/p>\n
\nThe ApiServiceWrapperBase class is a generic base class that performs create, read, update, and delete (CRUD) operations against the AutoLot.Api RESTful service. This centralizes communication with the service, configuration of the HTTP client, error handling, and so on. Entity specific classes will inherit from this base class, and those will be added into the services collection.<\/p>\n
\nThe AutoLot service wrapper interface contains the common methods to call into the AutoLot.Api service. Create a directory named Interfaces in the ApiWrapper directory. Add a new interface named IApiServiceWrapper.cs and update the interface to the code shown here:<\/p>\n
\n{
\nTask<IList
\n}<\/p>\n
\nBefore building the base class, add the following global using statements to the GlobalUsings.cs file:<\/p>\n
\nglobal using System.Net.Http.Json; global using System.Text;
\nglobal using System.Text.Json;<\/p>\n
\nIApiServiceWrapperBase interface. Add a protected constructor that takes an instance of HttpClient and IOptionsMonitor
\nlike this:<\/p>\n
\n: IApiServiceWrapperBase
\n{
\nprotected readonly HttpClient Client; private readonly string _endPoint;
\nprotected readonly ApiServiceSettings ApiSettings; protected readonly string ApiVersion;<\/p>\n
\nHttpClient client, IOptionsMonitor
\n{
\nClient = client;
\n_endPoint = endPoint;
\nApiSettings = apiSettingsMonitor.CurrentValue; ApiVersion = ApiSettings.ApiVersion;
\n}
\n}<\/p>\n
\nThe constructor adds the standard configuration to the HttpClient that will be used by all methods, including an AuthorizationHeader that uses basic authentication. Basic authentication will be covered in depth in the next chapter, Restful Services with ASP.NET Core, so for now just understand that basic authentication takes a username and password, concatenates them together (separated by a colon) and Base64 encodes them. The rest of the code sets the BaseAddress for the HttpClient and specifies that the client is expecting JSON.<\/p>\n
\nHttpClient client, IOptionsMonitor
\n{
\nClient = client;
\n_endPoint = endPoint;
\nApiSettings = apiSettingsMonitor.CurrentValue; ApiVersion = ApiSettings.ApiVersion; Client.BaseAddress = new Uri(ApiSettings.Uri);
\nclient.DefaultRequestHeaders.Accept.Add(new MediaTypeWithQualityHeaderValue("application\/ json"));
\nvar authToken = Convert.ToBase64String(Encoding.UTF8.GetBytes($"{apiSettingsMonitor. CurrentValue.UserName}:{apiSettingsMonitor.CurrentValue.Password}")); client.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("basic", authToken);
\n}<\/p>\n
\nThe class contains four support methods that are used by the public methods.<\/p>\n
\nThese methods wrap the related HttpClient methods.<\/p>\n
\n{
\nreturn await Client.PostAsync(uri, new StringContent(json, Encoding.UTF8, "application\/ json"));
\n}<\/p>\n
\n{
\nreturn await Client.PutAsync(uri, new StringContent(json, Encoding.UTF8, "application\/ json"));
\n}<\/p>\n
\nThe final helper method is used for executing an HTTP delete. The HTTP 1.1 specification (and later) allows for passing a body in a delete statement, but there isn\u2019t yet an extension method of the HttpClient for doing this. The HttpRequestMessage must be built up from scratch.
\nThe first step is to then create a request message using object initialization to set Content, Method, and RequestUri. Once this is complete, the message is sent, and the response is returned to the calling code. The method is shown here:<\/p>\n
\n{
\nHttpRequestMessage request = new HttpRequestMessage
\n{
\nContent = new StringContent(json, Encoding.UTF8, "application\/json"), Method = HttpMethod.Delete,
\nRequestUri = new Uri(uri)
\n};
\nreturn await Client.SendAsync(request);
\n}<\/p>\n
\nThere are two Get calls: one to get all records and one to get a single record. They both follow the same pattern. The GetAsync() method is called to return an HttpResponseMessage. The success or failure of the call is checked with the EnsureSuccessStatusCode() method, which throws an exception if the call did not return a successful status code. Then the body of the response is serialized back into the property type
\n(either as an entity or a list of entities) and returned to the calling code. The endpoint is constructed from the settings, and the ApiVersion is appended as a query string value. Each of these methods is shown here:<\/p>\n
\n{
\nvar response = await Client.GetAsync($"{ApiSettings.Uri}{_endPoint}?v={ApiVersion}"); response.EnsureSuccessStatusCode();
\nvar result = await response.Content.ReadFromJsonAsync<IList
\n}<\/p>\n
\n{
\nvar response = await Client.GetAsync($"{ApiSettings.Uri}{_endPoint}\/{id}?v={ApiVersion}"); response.EnsureSuccessStatusCode();
\nvar result = await response.Content.ReadFromJsonAsync
\n}<\/p>\n
\nThe method to add a record uses an HTTP Post request. It uses the helper method to post the entity as JSON and then returns the record from the response body. The method is listed here:<\/p>\n
\n{
\nvar response = await PostAsJsonAsync($"{ApiSettings.Uri}{_endPoint}?v={ApiVersion}", JsonSerializer.Serialize(entity));
\nif (response == null)
\n{
\nthrow new Exception("Unable to communicate with the service");
\n}<\/p>\n
\nreturn await response.Content.ReadFromJsonAsync
\n}<\/p>\n
\nThe second line of note is reading the response content and creating an instance of the updated record. The service wrapper method needs to get the updated instance from the service to guarantee server generated values (like Id and TimeStamp) and are updated in the client app. Returning the updated entity in the response from HTTP post calls is not a guaranteed function of a service. If the service doesn\u2019t return the entity, then the method uses the GetEntityAsync() method. It could also use the URI from the location if
\nnecessary, but since the GetEntityAsync() supplies everything needed, getting the location value is merely
\nfor demo purposes.<\/p>\n
\nThe method to update a record uses an HTTP Put request by way of the PutAsJsonAsync() helper method. This method also assumes that the updated entity is in the body of the response, and if it isn\u2019t, calls the GetEntityAsync() to refresh the server generated values.<\/p>\n
\n{
\nvar response = await PutAsJsonAsync($"{ApiSettings.Uri}{_endPoint}\/{entity. Id}?v={ApiVersion}",
\nJsonSerializer.Serialize(entity)); response.EnsureSuccessStatusCode();
\nreturn await response.Content.ReadFromJsonAsync
\n}<\/p>\n
\nThe final method to add, is for executing an HTTP Delete. The pattern follows the rest of the methods: use the helper method and check the response for success. There isn\u2019t anything to return to the calling code since the entity was deleted. The method is shown here:<\/p>\n
\n{
\nvar response = await DeleteAsJsonAsync($"{ApiSettings.Uri}{_endPoint}\/{entity. Id}?v={ApiVersion}",
\nJsonSerializer.Serialize(entity)); response.EnsureSuccessStatusCode();
\n}<\/p>\n
\nIn the Interfaces directory, create two new interfaces named ICarApiServiceWrapper.cs and
\nIMakeApiServiceWrapper.cs. Update the interfaces to the following:<\/p>\n
\nnamespace AutoLot.Services.ApiWrapper.Interfaces;<\/p>\n
\n{
\nTask<IList
\n}<\/p>\n
\nnamespace AutoLot.Services.ApiWrapper.Interfaces;<\/p>\n
\n{
\n}<\/p>\n
\nIn the ApiWrapper directory, create two new classes named CarApiServiceWrapper.cs and MakeApiServiceWrapper.cs. The constructor for each class takes an instance of HttpClient and IOptions
\nnamespace AutoLot.Services.ApiWrapper;<\/p>\n
\n{
\npublic CarApiServiceWrapper(HttpClient client, IOptionsMonitor
\n: base(client, apiSettingsMonitor, apiSettingsMonitor.CurrentValue.CarBaseUri) { }
\n}<\/p>\n
\nnamespace AutoLot.Services.ApiWrapper;<\/p>\n
\n{
\npublic MakeApiServiceWrapper(HttpClient client, IOptionsMonitor
\n: base(client, apiSettingsMonitor, apiSettingsMonitor.CurrentValue.MakeBaseUri) { }
\n}<\/p>\n
\n{
\nvar response = await Client.GetAsync($"{ApiSettings.Uri}{ApiSettings.CarBaseUri}\/bymake\/
\n{id}?v={ApiVersion}"); response.EnsureSuccessStatusCode();
\nvar result = await response.Content.ReadFromJsonAsync<IList
\n}<\/p>\n
\n{
\nservices.Configure
\nreturn services;
\n}<\/p>\n
\nNow that the API service wrappers are complete, it\u2019s time to revisit the API data services and complete the class implementations.<\/p>\n
\nThe first step to complete the base class is to update the constructor to receive an instance of the IApiServic eWrapperBase
\nprotected ApiDataServiceBase(IApiServiceWrapperBase
\n{
\nServiceWrapper = serviceWrapperBase;
\n}<\/p>\n
\n=> await ServiceWrapper.GetAllEntitiesAsync();
\npublic async Task
\n=> await ServiceWrapper.GetEntityAsync(id);
\npublic async Task
\n{
\nawait ServiceWrapper.UpdateEntityAsync(entity); return entity;
\n}<\/p>\n
\n=> await ServiceWrapper.DeleteEntityAsync(entity);<\/p>\n
\n{
\nawait ServiceWrapper.AddEntityAsync(entity); return entity;
\n}<\/p>\n
\nThe CarApiDataService and MakeApiDataService classes need their constructors updated to receive their entity specific derived instance of the IApiServiceWrapperBase
\nbase class:<\/p>\n
\n{
\npublic CarApiDataService(ICarApiServiceWrapper serviceWrapper) : base(serviceWrapper) { }
\n}<\/p>\n
\n{
\npublic MakeApiDataService(IMakeApiServiceWrapper serviceWrapper):base(serviceWrapper) { }
\n}<\/p>\n
\nIf there is a value, the relevant method on the ICarApiServiceWrapper is called. Otherwise, the base
\nGetAllAsync() is called:<\/p>\n
\n=> makeId.HasValue
\n? await ((ICarApiServiceWrapper)ServiceWrapper). GetCarsByMakeAsync(makeId.Value)
\n: await GetAllAsync();<\/p>\n
\nPrior versions of ASP.NET applications could only be deployed to Windows servers using IIS as the web server. ASP.NET Core can be deployed to multiple operating systems in multiple ways, using a variety of web servers. ASP.NET Core applications can also be deployed outside of a web server. The high-level options are as follows:
\n\u2022On a Windows server (including Azure) using IIS
\n\u2022On a Windows server (including Azure app services) outside of IIS
\n\u2022On a Linux server using Apache or NGINX
\n\u2022On Windows or Linux in a container
\nThis flexibility allows organizations to decide the deployment platform that makes the most sense for them, including popular container-based deployment models (such as using Docker), as opposed to being locked into Windows servers.<\/p>\n
\nFollowing along with the principles of .NET, you must opt in for everything in ASP.NET Core. By default, nothing is loaded into an application. This enables applications to be as lightweight as possible, improving performance, and minimizing the surface area and potential risk.<\/p>\n
\nLogging in ASP.NET Core is based on an ILoggerFactory. This enables different logging providers to hook into the logging system to send log messages to different locations, such as the Console. The ILoggerFactory is used to create an instance of ILogger
\n{
\npublic static void LogDebug(this ILogger logger, EventId eventId, Exception exception, string message, params object[] args)
\npublic static void LogDebug(this ILogger logger, EventId eventId, string message, params object[] args)
\npublic static void LogDebug(this ILogger logger, Exception exception, string message, params object[] args)
\npublic static void LogDebug(this ILogger logger, string message, params object[] args)<\/p>\n
\npublic static void LogTrace(this ILogger logger, EventId eventId, string message, params object[] args)
\npublic static void LogTrace(this ILogger logger, Exception exception, string message, params object[] args)
\npublic static void LogTrace(this ILogger logger, string message, params object[] args)<\/p>\n
\npublic static void LogInformation(this ILogger logger, EventId eventId, string message, params object[] args)
\npublic static void LogInformation(this ILogger logger, Exception exception, string message, params object[] args)
\npublic static void LogInformation(this ILogger logger, string message, params object[] args)<\/p>\n
\npublic static void LogWarning(this ILogger logger, EventId eventId, string message, params object[] args)
\npublic static void LogWarning(this ILogger logger, Exception exception, string message, params object[] args)
\npublic static void LogWarning(this ILogger logger, string message, params object[] args)<\/p>\n
\npublic static void LogError(this ILogger logger, EventId eventId, string message, params object[] args)
\npublic static void LogError(this ILogger logger, Exception exception, string message, params object[] args)
\npublic static void LogError(this ILogger logger, string message, params object[] args)<\/p>\n
\npublic static void LogCritical(this ILogger logger, EventId eventId, string message, params object[] args)
\npublic static void LogCritical(this ILogger logger, Exception exception, string message, params object[] args)
\npublic static void LogCritical(this ILogger logger, string message, params object[] args)<\/p>\n
\npublic static void Log(this ILogger logger, LogLevel logLevel, EventId eventId, string message, params object[] args)
\npublic static void Log(this ILogger logger, LogLevel logLevel, Exception exception, string message, params object[] args)
\npublic static void Log(this ILogger logger, LogLevel logLevel, EventId eventId, Exception exception, string message, params object[] args)
\n}<\/p>\n
\nAny provider that supplies an ILoggerFactory extension can be used for logging in ASP.NET Core, and Serilog is one such logging framework. The next sections cover creating a logging infrastructure based on Serilog and configuring the ASP.NET Core applications to use the new logging code.<\/p>\n
\nTo configure Serilog, we are going to use the application configuration files in conjunction with a C# class. Start by adding a new folder named Logging to the AutoLot.Service project. Create a new folder named Settings in the Logging folder, and in that new folder, add a class named AppLoggingSettings. Update the code to the following:
\nnamespace AutoLot.Services.Logging.Settings; public class AppLoggingSettings
\n{
\npublic GeneralSettings General { get; set; } public FileSettings File { get; set; }
\npublic SqlServerSettings MSSqlServer { get; set; }<\/p>\n
\n{
\npublic string RestrictedToMinimumLevel { get; set; }
\n}
\npublic class SqlServerSettings
\n{
\npublic string TableName { get; set; } public string Schema { get; set; }
\npublic string ConnectionStringName { get; set; }
\n}<\/p>\n
\n{
\npublic string Drive { get; set; } public string FilePath { get; set; } public string FileName { get; set; } public string FullLogPathAndFileName =><\/p>\n
\n}
\n}<\/p>\n
\nDevelopment.json files for the AutoLot.Api, AutoLot.Mvc, and AutoLot.Web projects:<\/p>\n
\n"TableName": "SeriLogs", "Schema": "Logging", "ConnectionStringName": "AutoLot"
\n},<\/p>\n
\n"FilePath": "temp", "FileName": "log_AutoLot.txt"
\n},
\n"General": {
\n"RestrictedToMinimumLevel": "Information"
\n}
\n},<\/p>\n
\n{
\n"AppLoggingSettings": { "MSSqlServer": {
\n"TableName": "SeriLogs", "Schema": "Logging", "ConnectionStringName": "AutoLot"
\n},
\n"File": { "Drive": "c",
\n"FilePath": "temp", "FileName": "log_AutoLot.txt"
\n},
\n"General": {
\n"RestrictedToMinimumLevel": "Information"
\n}
\n},
\n"ConnectionStrings": {
\n"AutoLot": "Server=.,5433;Database=AutoLot;User ID=sa;Password=P@ssw0rd;"
\n},
\n"RebuildDatabase": true, "AppName": "AutoLot.Api - Dev"
\n}<\/p>\n
\n{
\n"AppLoggingSettings": { "MSSqlServer": {<\/p>\n
\n},
\n"File": { "Drive": "c",
\n"FilePath": "temp", "FileName": "log_AutoLot.txt"
\n},
\n"General": {
\n"RestrictedToMinimumLevel": "Information"
\n}
\n},
\n"ConnectionStrings": {
\n"AutoLot": "Server=.,5433;Database=AutoLot;User ID=sa;Password=P@ssw0rd;"
\n},
\n"RebuildDatabase": true, "UseApi": false, "ApiServiceSettings": {
\n"Uri": "https:\/\/localhost:5011\/<\/a><\/a><\/a>", "UserName": "AutoLotUser", "Password": "SecretPassword", "CarBaseUri": "api\/v1\/Cars", "MakeBaseUri": "api\/v1\/Makes"
\n},
\n"AppName": "AutoLot.Mvc - Dev"
\n}<\/p>\n
\n{
\n"DetailedErrors": true, "AppLoggingSettings": {
\n"MSSqlServer": { "TableName": "SeriLogs", "Schema": "Logging",
\n"ConnectionStringName": "AutoLot"
\n},
\n"File": { "Drive": "c",
\n"FilePath": "temp", "FileName": "log_AutoLot.txt"
\n},
\n"General": {
\n"RestrictedToMinimumLevel": "Information"
\n}
\n},
\n"ConnectionStrings": {
\n"AutoLot": "Server=.,5433;Database=AutoLot;User ID=sa;Password=P@ssw0rd;"
\n},
\n"RebuildDatabase": true, "UseApi": false,<\/p>\n
\n"Uri": "https:\/\/localhost:5011\/<\/a><\/a><\/a>", "UserName": "AutoLotUser", "Password": "SecretPassword", "CarBaseUri": "api\/v1\/Cars", "MakeBaseUri": "api\/v1\/Makes"
\n},
\n"AppName": "AutoLot.Web - Dev"
\n}<\/p>\n
\n{
\n"AllowedHosts": "*"
\n}<\/p>\n
\n{
\n"AllowedHosts": "*", "DealerInfo": {
\n"DealerName": "Skimedic's Used Cars", "City": "West Chester",
\n"State": "Ohio"
\n}
\n}<\/p>\n
\n{
\n"AllowedHosts": "*", "DealerInfo": {
\n"DealerName": "Skimedic's Used Cars", "City": "West Chester",
\n"State": "Ohio"
\n}
\n}<\/p>\n
\nThe next step is to configure Serilog. Get started by adding a new folder named Configuration in the Logging folder of the AutoLot.Service project. In this folder add a new class named LoggingConfiguration. Make the class public and static, as shown here:
\nnamespace AutoLot.Services.Logging.Configuration; public static class LoggingConfiguration
\n{
\n}<\/p>\n
\ndatabase, and the console. The text file and database sinks require configuration, an output template for the text file sink, and a list of fields for the database sink.
\nTo set up the file template, create the following static readonly string:<\/p>\n
\n@"[{Timestamp:yy-MM-dd HH:mm:ss} {Level}]{ApplicationName}:{SourceContext}{NewLine} Message:{Message}{NewLine}in method {MemberName} at {FilePath}:{LineNumber}{NewLine}
\n{Exception}{NewLine}";<\/p>\n
\n{
\nAdditionalColumns = new List
\n{
\nnew SqlColumn {DataType = SqlDbType.VarChar, ColumnName = "ApplicationName"}, new SqlColumn {DataType = SqlDbType.VarChar, ColumnName = "MachineName"},
\nnew SqlColumn {DataType = SqlDbType.VarChar, ColumnName = "MemberName"}, new SqlColumn {DataType = SqlDbType.VarChar, ColumnName = "FilePath"}, new SqlColumn {DataType = SqlDbType.Int, ColumnName = "LineNumber"},
\nnew SqlColumn {DataType = SqlDbType.VarChar, ColumnName = "SourceContext"}, new SqlColumn {DataType = SqlDbType.VarChar, ColumnName = "RequestPath"}, new SqlColumn {DataType = SqlDbType.VarChar, ColumnName = "ActionName"},
\n}
\n};<\/p>\n
\n{
\nbuilder.Logging.ClearProviders(); var config = builder.Configuration;
\nvar settings = config.GetSection(nameof(AppLoggingSettings)).Get
\nvar connectionString = config.GetConnectionString(connectionStringName); var tableName = settings.MSSqlServer.TableName;
\nvar schema = settings.MSSqlServer.Schema;
\nstring restrictedToMinimumLevel = settings.General.RestrictedToMinimumLevel; if (!Enum.TryParse
\n{
\nlogLevel = LogEventLevel.Debug;
\n}
\nvar sqlOptions = new MSSqlServerSinkOptions
\n{
\nAutoCreateSqlTable = false,<\/p>\n
\n};
\nif (builder.Environment.IsDevelopment())
\n{
\nsqlOptions.BatchPeriod = new TimeSpan(0, 0, 0, 1);
\nsqlOptions.BatchPostingLimit = 1;
\n}<\/p>\n
\n.MinimumLevel.Is(logLevel)
\n.Enrich.FromLogContext()
\n.Enrich.With(new PropertyEnricher("ApplicationName", config.GetValue
\n.Enrich.WithMachineName()
\n.WriteTo.File(
\npath: builder.Environment.IsDevelopment()? settings.File.FileName : settings.File. FullLogPathAndFileName,
\nrollingInterval: RollingInterval.Day, restrictedToMinimumLevel: logLevel, outputTemplate: OutputTemplate)
\n.WriteTo.Console(restrictedToMinimumLevel: logLevel)
\n.WriteTo.MSSqlServer( connectionString: connectionString, sqlOptions, restrictedToMinimumLevel: logLevel, columnOptions: ColumnOptions);
\nbuilder.Logging.AddSerilog(log.CreateLogger(),false);
\n}<\/p>\n
\nThe AutoLot logging framework leverages the built-in logging capabilities of ASP.NET Core to simplify using Serilog. It starts with the IAppLogging interface.<\/p>\n
\nThe IApplogging
\nnamespace AutoLot.Services.Logging.Interfaces; public interface IAppLogging
\n{
\nvoid LogAppError(Exception exception, string message, [CallerMemberName] string memberName = "", [CallerFilePath] string sourceFilePath = "", [CallerLineNumber] int sourceLineNumber = 0);<\/p>\n
\n}<\/p>\n
\nAdd the following global using statement to the GlobalUsings.cs file in the AutoLot.Services project:<\/p>\n
\nThe AppLogging class implements the IAppLogging interface. Add a new class named AppLogging to the Logging directory. Make the class public and implement IAppLogging
\n{
\nprivate readonly ILogger
\n{
\n_logger = logger;
\n}
\n}<\/p>\n
\nstring sourceFilePath, int sourceLineNumber, Exception ex, string message, Action<Exception, string, object[]> logAction)
\n{
\nvar list = new List
\n{
\nLogContext.PushProperty("MemberName", memberName), LogContext.PushProperty("FilePath", sourceFilePath), LogContext.PushProperty("LineNumber", sourceLineNumber),
\n};
\nlogAction(ex,message,null); foreach (var item in list)
\n{
\nitem.Dispose();
\n}
\n}<\/p>\n
\n{
\nvar list = new List
\n{
\nLogContext.PushProperty("MemberName", memberName), LogContext.PushProperty("FilePath", sourceFilePath), LogContext.PushProperty("LineNumber", sourceLineNumber),
\n};<\/p>\n
\n{
\nitem.Dispose();
\n}
\n}<\/p>\n
\n{
\nLogWithException(memberName, sourceFilePath, sourceLineNumber, exception, message, _ logger.LogError);
\n}<\/p>\n
\n{
\nLogWithoutException(memberName, sourceFilePath, sourceLineNumber, message, _logger. LogError);
\n}<\/p>\n
\n[CallerFilePath] string sourceFilePath = "", [CallerLineNumber] int sourceLineNumber = 0)
\n{
\nLogWithException(memberName, sourceFilePath, sourceLineNumber, exception, message, _ logger.LogCritical);
\n}<\/p>\n
\n{
\nLogWithoutException(memberName, sourceFilePath, sourceLineNumber, message, _logger. LogCritical);
\n}<\/p>\n
\n{
\nLogWithoutException(memberName, sourceFilePath, sourceLineNumber, message, _logger.LogDebug);
\n}<\/p>\n
\n{
\nLogWithoutException(memberName, sourceFilePath, sourceLineNumber, message, _logger. LogTrace);
\n}<\/p>\n
\n{
\nLogWithoutException(memberName, sourceFilePath, sourceLineNumber, message, _logger. LogInformation);
\n}<\/p>\n
\n{
\nLogWithoutException(memberName, sourceFilePath, sourceLineNumber, message, _logger. LogWarning);
\n}<\/p>\n
\nThe final configuration is to add the IAppLogging<> interface into the DI container and call the extension method to add SeriLog into the WebApplicationBuilder. Start by creating a new extension method in the LoggingConfiguration class:<\/p>\n
\n{
\nservices.AddScoped(typeof(IAppLogging<>), typeof(AppLogging<>)); return services;
\n}<\/p>\n
\nWith Serilog and the AutoLot logging system in place, it\u2019s time to update the data services to add logging capabilities.<\/p>\n
\nStarting with the ApiDataServiceBase and DalDataServiceBase classes, update the generic definition to also accept a class that implements IDataServiceBase
\npublic abstract class ApiDataServiceBase<TEntity, TDataService> : IDataServiceBase
\nwhere TDataService : IDataServiceBase
\n{
\n\/\/omitted for brevity
\n}<\/p>\n
\npublic abstract class DalDataServiceBase<TEntity, TDataService> : IDataServiceBase
\nwhere TDataService : IDataServiceBase
\n{
\n\/\/omitted for brevity
\n}<\/p>\n
\nprotected readonly IApiServiceWrapperBase
\nprotected readonly IAppLogging
\nIApiServiceWrapperBase
\n{
\nServiceWrapper = serviceWrapperBase;
\nAppLoggingInstance = appLogging;
\n}<\/p>\n
\nprotected readonly IBaseRepo
\nprotected readonly IAppLogging
\n{
\nMainRepo = mainRepo;
\nAppLoggingInstance = appLogging;
\n}<\/p>\n
\nEach of the entity specific classes need to change their inheritance signature to use the new generic parameter and also take an instance of IAppLogging in the constructor and pass it to the base class. Here is the code for the updated classes:<\/p>\n
\npublic class CarApiDataService : ApiDataServiceBase<Car,CarApiDataService>, ICarDataService
\n{
\npublic CarApiDataService( IAppLogging
\n: base(appLogging, serviceWrapper) { }
\n\/\/omitted for brevity
\n}<\/p>\n
\npublic class MakeApiDataService
\n: ApiDataServiceBase<Make,MakeApiDataService>, IMakeDataService
\n{
\npublic MakeApiDataService( IAppLogging
\n: base(appLogging,serviceWrapper) { }
\n}<\/p>\n
\npublic class CarDalDataService : DalDataServiceBase<Car,CarDalDataService>,ICarDataService
\n{
\nprivate readonly ICarRepo _repo;
\npublic CarDalDataService(IAppLogging
\n{
\n_repo = repo;
\n}
\n\/\/omitted for brevity
\n}<\/p>\n
\npublic class MakeDalDataService : DalDataServiceBase<Make,MakeDalDataService>,IMakeD ataService
\n{
\npublic MakeDalDataService(IAppLogging
\n: base(appLogging, repo) { }
\n}<\/p>\n
\nTo close out the chapter, let\u2019s test the logging framework. The first step is to update the HomeController in the AutoLot.Mvc project to use the new logging framework. Replace the ILogger