Tech Point Fundamentals

Sunday, December 4, 2022

.Net Core Interview Questions and Answers - Part 14

ASP.Net Core Interview Questions and Answers - Part 14

AspDotNetCoreInterviewQuestionsAndAnswers

Are you preparing for the .Net Core Interview? If yes, then you are at the right place. This is the ASP.Net Core Interview Questions and Answers article series. Here we will see the Top 150+ .Net Core Interview Questions with Answers. 

Please visit our YouTube Channel for Interviews and other videos by the below link:




Please read the complete Design Pattern, C#, MVC, WebAPI, and .Net Framework Interview Questions and Answers article series here.




Introduction


This is the 14th part of the .Net Core Interview Questions and Answers article series. Each part contains ten .Net Core Interview Questions. Please read all the .Net Interview Questions list here.

I will highly recommend to please read the previous parts over here before continuing the current part:






ASP.Net Core Interview Questions and Answers - Part 14


Q135. How does logging work in .Net Core? What are the different log providers in .Net Core?

The .Net Core has inbuild support for logging. The .NET Core SDK is a lightweight SDK that includes a bare minimum set of features required to build an application. Microsoft provides .NET APIs as .NET Extensions. 

.NET Extensions is an open-source, cross-platform set of APIs for commonly used programming patterns and utilities, such as dependency injection, logging, and app configuration. All the extensions are included under Microsoft.Extensions namespace.

The Logging API is included in Microsoft.Extensions.Logging package. The Logging API does not work as a standalone. It works with one or more logging providers that store or display logs to a particular medium such as Console, Debug, TraceListeners, etc. Microsoft.Extensions.Logging includes the necessary classes and interfaces for logging like ILogger, ILoggerFactory, ILoggerProvider interfaces, and the LoggerFactory class.

So, there are two important building blocks for implementing logging in a .NET Core: Logging API and Logging Providers. The logging API in Microsoft.Extensions.Logging works on the .NET Core-based applications whether it is ASP.NET Core or EF Core.



ILoggerFactory: The ILoggerFactory is the factory interface for creating an appropriate ILogger type instance and also for adding the ILoggerProvider instance. 

The Logging API includes the built-in LoggerFactory class that implements the ILoggerFactory interface. We can use it to add an instance of type ILoggerProvider and to retrieve the ILogger instance for the specified category.

public interface ILoggerFactory : IDisposable
{
ILogger CreateLogger(string categoryName);
void AddProvider(ILoggerProvider provider);
}

ILogger: The ILogger interface includes methods for logging to the underlying storage. There are many extension methods that make logging easy. 

public interface ILogger
{
void Log<TState>(LogLevel logLevel, EventId eventId, TState state, Exception exception, Func<TState, Exception, string> formatter);

bool IsEnabled(LogLevel logLevel);
IDisposable BeginScope<TState>(TState state);



ILoggerProvider: The ILoggerProvider manages and creates an appropriate logger, specified by the logging category. We can create our own logging provider by implementing the ILoggerProvider interface. 

public interface ILoggerProvider : IDisposable
{
ILogger CreateLogger(string categoryName);
}

Logging Providers: A logging provider displays or stores logs to a particular medium such as a console, a debugging event, an event log, a trace listener, and others. Microsoft provides various logging providers as NuGet packages.

Microsoft has also collaborated with various logging framework teams (including third parties like NLog, Serilog, Logger, Log4Net, and others) to extend the list of providers compatible with Microsoft.Extensions.Logging.




Q136. What are log levels? What are the different log levels available in .Net Core?

Log levels indicate the importance or severity of log messages and each log level has different Severity. 

public enum LogLevel
{
Trace = 0,
Debug = 1,
Information = 2,
Warning = 3,
Error = 4,
Critical = 5,
}

Built-in log providers include extension methods to indicate log levels.

log-levels

We can use extension methods to indicate the level of the log messages:

ILoggerFactory loggerFactory = new LoggerFactory().AddConsole((_, __) => true);
ILogger logger = loggerFactory.CreateLogger<Program>();

logger.LogError("Log Error info.");
logger.LogWarning("Log Warning info.");



You could specify that by default, Debug or higher level logs are written to providers, but for logs written by services in the Microsoft namespace, only logs of at least Warning level or above are written. With this approach, you can control the amount of logging produced by the various libraries in your application, increasing logging levels for only those areas that need them.

For example, we can filter out Warning logs in the Microsoft namespace but keep other logs at the Debug level. With the default ASP.NET Core 1.X template, all you need to do is change the appsettings.json file, and set the log levels to Warning as appropriate:

{
  "Logging": {
"IncludeScopes": false,
"LogLevel": {
  "Default": "Debug",
  "System": "Warning",
  "Microsoft": "Warning"
}
  }
}

It is a good idea to instrument your code with as many log messages are useful, and you can filter out the most verbose Trace and Debug log levels. These filtering capabilities are a really useful way of cutting through the cruft, but there's one particular downside.

You can check whether the particular log level is enabled for the current logger, before trying to write to it.

if(_logger.IsEnabled(LogLevel.Debug))
{
_logger.LogDebug("Calling HomeController.Index");
}



Q137. How can you configure logging in ASP.Net Core applications? 

ASP.NET Core uses the same logging mechanism as .NET Core logging. When you create the ASP.NET Core MVC web application in Visual Studio 2017 (or later), it automatically includes the NuGet package for Microsoft.Extensions.Logging and some required logging providers (Console, Debug, EventSource, TraceSource) under Microsoft.AspNetCore.App NuGet package. 

To enable Logging in the initial versions of ASP.Net Core (.Net Core 1.x), it is required to add dependency within Project.json or .csproj file and needs some configuration under the startup class to add into DI. Also if we want to add any third-party provider or configure filtering, we need to add a configuration in the startup class. But in the new versions (.Net Core 2.0 and later) of the framework, Logging is added into the DI system by default. 

When you create the ASP.NET Core MVC web application in Visual Studio 2017 (or later), it automatically includes the NuGet package for Microsoft.Extensions.Logging and all the required logging providers (Console, Debug, EventSource, TraceSource) under Microsoft.AspNetCore.App NuGet package.



In the ASP.NET Core MVC application, the call to the WebHost.CreateDefaultBuilder(args) method in the Program.cs internally adds the Console, Debug, and EventSource logging providers.

 public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>
WebHost.CreateDefaultBuilder(args)
   .UseStartup<Startup>();

But if you want to use other providers or any default provider, then you need to remove all the existing providers and add the provider of your choice. To configure logging providers, call the ConfigureLogging() extension method of IWebHostBuilder:

public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>
WebHost.CreateDefaultBuilder(args)
.ConfigureLogging(logBuilder =>
{
logBuilder.ClearProviders(); 
logBuilder.AddConsole();  
logBuilder.AddTraceSource("Information, ActivityTracing"); 
})
.UseStartup<Startup>();

You can also configure the logging provider using ILoggerFactory in the Configure() method of the Startup class.



Q138. How can you write the log files in the text file in ASP.Net Core applications using logger?

In order to store logs in a file, install the NuGet package Serilog.Extensions.Logging.File. The Serillog includes an extension method for ILoggerFactory but not for ILogBuilder. You can also use log4net as well.

So, go to the Startup.cs file and add the ILoggerFactory parameter in the Configure() method. Then, call the AddFile() extension method to add Serillog file provider:

public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory) 
{
logBuilder.ClearProviders();
loggerFactory.AddFile("Logs/mylog-{Date}.txt");
}




After that, we can use ILogger or ILoggerFactory anywhere in an application using ASP.NET Core DI.

 public class UserController : Controller
{
private readonly ILogger _logger;

public HomeController(ILogger<UserController> logger){
_logger = logger;
}
public IActionResult Index()
{
_logger.LogInformation("Log message in the Index() method");

return View();
}
}

Here passing UserController as the generic type for the ILogger<UserController>, will be used as a category.   When a logger is created, a category name must be provided. The category name specifies the source of the logging events.

After specifying ILogger<UserController> it will display a fully qualified name AspDotNetCoreMvcApp.Controllers.UserController in the logs:

info: AspDoteNetCoreMvcApp.Controllers.UserController[0]
Log message in the Index() method



Q139. What is LoggerMessage in ASP.Net Core? How it is different from Logger?

One of the hidden but powerful features in ASP.NET Core is LoggerMessage, which has reduced overhead compared to the Logger extension methods. The static LoggerMessage class is available in Microsoft.Extensions.Logging.Abstractions package, and contains a number of static, generic Define methods that return an Action<> which in turn can be used to create strongly-typed logging extensions.

LoggerMessage features create cacheable delegates that require fewer object allocations and reduced computational overhead compared to logger extension methods, such as LogInformation() and LogDebug(). For high-performance logging scenarios, use the LoggerMessage pattern.

LoggerMessage vs Logger:

1. Logger extension methods require "boxing" for value types, such as int, into the object. But the LoggerMessage pattern avoids boxing by using static Action fields and extension methods with strongly-typed parameters.

2. Logger extension methods must parse the message template (named format string) every time a log message is written. LoggerMessage only requires parsing a template once when the message is defined.



LoggerHelper.Define() method:

LoggerMessage.Define creates an Action delegate for logging a message. Define() method overloads permit passing up to six type parameters to a named format string (template).

The purpose of the static LoggerMessage.Define<T> method is:

  1. Encapsulate the if statement to allow performant logging
  2. Enforce the correct strongly-typed parameters are passed when logging the message
  3. Ensure the log message contains the correct number of placeholders for parameters

The string provided to the Define method is a template and not an interpolated string. Placeholders are filled in the order that the types are specified. 

Placeholder names in the template should be descriptive and consistent across templates. They serve as property names within structured log data.



public static class LoggerMessage
{
public static Action<ILogger, T1, Exception> Define<T1>( LogLevel logLevel, EventId eventId, string formatString)
{
    var formatter = CreateLogValuesFormatter( formatString, expectedNamedParameterCount: 1);
return (logger, arg1, exception) =>
{
if (logger.IsEnabled(logLevel))
{
ogger.Log(logLevel, eventId, new LogValues<T1>(formatter, arg1), exception,                 LogValues<T1>.Callback);
}
};
}
}

Each log message is an Action held in a static field created by LoggerMessage.Define. The Action is invoked through a strongly-typed extension method. 



Q140. What is the model state? What is the difference between model binding and model validation in ASP.Net MVC Core?

The model state represents errors that come from two subsystems: model binding and model validation.

Errors that originate from model binding are generally data conversion errors, for example, an "x" is entered in an integer field. 

Model validation occurs after model binding and reports errors where data doesn't conform to business rules, for example, a 0 is entered in a field that expects a rating between 1 and 5.
 
Both model binding and model validation occurs before the execution of a controller action or a Razor Pages handler method. 






Q141. What is model validation in ASP.Net Core?

Model Validation is a process to ensure that the data received from the View is appropriate to bind the Model. If it is not, then appropriate error messages are displayed on the View, and that will help the user to rectify the problem.

Model Validation in Web App:

Both model binding and model validation occurs before the execution of a controller action or a Razor Pages handler method. For web apps, it's the app's responsibility to inspect ModelState.IsValid and react appropriately. 

The ModelState.IsValid is a property that returns true if all the model properties are valid and return false otherwise.

if (!ModelState.IsValid)
{
return Page();
}

Model Validation feature adds the CSS class called input-validation-error to all the controls that have failed the validation checks i.e. whenever some error message is recorded for a property by the method – ModelState.AddModelError().



Model Validation in ASP.NET Core REST API:

To implement model validation in an ASP.NET Core REST API, just decorate the respective properties with the validation attributes. Web API controllers don't have to check ModelState.IsValid if they have the [ApiController] attribute. In that case, an automatic HTTP 400 response containing error details is returned when a model state is invalid. 

In an ASP.NET Core REST API, there is no need to explicitly check if the model state is valid. Since the controller class is decorated with the [ApiController] attribute, it takes care of checking if the model state is valid and automatically returns 400 responses along with the validation errors.



Returning Custom Validations by using TryValidateModel():

Validation is automatic, but you might want to repeat it manually. Sometimes you want to check. For example, you might compute a value for a property and want to re-run validation after setting the property to the computed value. 

To rerun validation, call ModelStateDictionary.ClearValidationState to clear validation specific to the model being validated followed by TryValidateModel:

 ModelState.ClearValidationState(nameof(Employee));
if (!TryValidateModel(Employee, nameof(Employee)))
{
return Page();
}






Q142. What is Model Level Error Message in ASP.Net Core? How can you add a custom model error?

Adding Custom Model Error:

To add a custom model validation error, use AddModelError() method of the ModelState object. The AddModelError() method is used to record a Model Validation error for a specified property.

var user = employeeRepository.GetEmployeeByEmail(employee.Email);
if(user != null)
{
ModelState.AddModelError("email", "User email already in use");
return BadRequest(ModelState);
}



Model-Level Error Messages:

Model-Level Error Messages are those that are applicable to the model as a whole and not to individual properties. You can apply then providing an empty string (“”) to the property parameter of the AddModelError() method:

ModelState.AddModelError("", "Some Model-Level error"); 

Also, you need to go to the Index View and change the asp-validation-summary to ModelOnly:

<div asp-validation-summary="ModelOnly" class="text-danger"></div>



Q143. How can you create a Custom Model Validation Attribute in ASP.Net Core?

You can also create your own Custom Model Validation Attribute that does the validation of values in the manner defined by you. The Custom Validator is very powerful, you can create validation for names preventing some users with a particular name or any other things as well. 

For this you have to create a class and inherit it from 2 classes: Attribute and IModelValidator.

The IModelValidator interface defines Validate() method which you have to implement in your class. In this method, you write your custom validation logic.

Inside this method, you receive information about the property (that is to be validated) through an instance of the ModelValidationContext class.

The ModelValidationContext class contains three properties: Model, Container, and ActionContext. The Model returns the property value that is to be validated while Container returns the object that contains the property. The ActionContext provides the context data.



namespace CustomModelBindingValidation.Infrastructure
{
public class CustomDate : Attribute, IModelValidator
{
public IEnumerable<ModelValidationResult> Validate(ModelValidationContext context)
{
 
if (Convert.ToDateTime(context.Model) > DateTime.Now)
return new List<ModelValidationResult> {
new ModelValidationResult("", "Date of Birth cannot be in the future")
};
else if (Convert.ToDateTime(context.Model) < new DateTime(1980, 1, 1))
return new List<ModelValidationResult> {
new ModelValidationResult("", "Date of Birth should not be before 1980")
};
else
return Enumerable.Empty<ModelValidationResult>();
}
}
}

After this you can use this for any DateTime fields:

[CustomDate]
public DateTime DOB { get; set; }



Q144. What is the Validation attribute? What are Data Annotations? 

Validation attributes let you specify validation rules for model properties. There is another way to do Model Validations which is by the use of Validation Attributes in the Model class. This process is known as Model Validation from Data Annotation and is very easy, fast, and removes code duplication.

ASP.NET Core provides several built-in attributes for model validation.  The complete list of validation attributes can be found in the System.ComponentModel.DataAnnotations namespace. 






To Be Continued Part-15...


Recommended Articles






Thanks for visiting this page. Please follow and join us on LinkedInFacebookTelegramQuoraYouTubeTwitterPinterestTumbler, and VK for regular updates.

    

Sunday, November 27, 2022

.Net Core Interview Questions and Answers - Part 13

ASP.Net Core Interview Questions and Answers - Part 13

AspDotNetCoreInterviewQuestionsAndAnswers

Are you preparing for the .Net Core Interview? If yes, then you are at the right place. This is the ASP.Net Core Interview Questions and Answers article series. Here we will see the Top 150+ .Net Core Interview Questions with Answers. 

Please visit our YouTube Channel for Interviews and other videos by below link:




Please read the complete Design Pattern, C#, MVC, WebAPI, and .Net Framework Interview Questions and Answers article series here.




Introduction


This is the 13th part of the .Net Core Interview Questions and Answers article series. Each part contains ten .Net Core Interview Questions. Please read all the .Net Interview Questions list here.

I will highly recommend to please read the previous parts over here before continuing to the current part:






ASP.Net Core Interview Questions and Answers - Part 13


Q124. What are the different ways to handle Errors and Exceptions in .Net Core applications? 

There are different ways to handle the errors and exceptions in ASP.Net Core applications.  ASP.NETCore middleware pipeline is always bidirectional:

  • The request is first entered into the ExceptionHandler middleware. While entering it is almost ignored, but while sending the response back it is the last middleware so that if the response contains any errors, modify the response and send a friendly message back to the client or execute the pipeline again. 
  • If ExceptionHandler not handling the errors webserver returns a status code to the user.

1. UseDeveloperExceptionPage() middleware: It is generally used for handling exceptions in the dev environment.


2. ExceptionHandler() middleware: It can be used for both prod and non-prod environments.



if (env.IsDevelopment())
{
   app.UseDeveloperExceptionPage();
}
else
{
   app.UseExceptionHandler("/Error");
   app.UseHsts();
}


For the development environment, the Developer exception page displays detailed information about the exception. You should place this middleware before any other middleware for which you want to catch exceptions. For prod environments, UseExceptionHandler middleware loads the proper Error page.



3. Lambda Exception Handler:

An alternative to a custom exception handler page is to provide a lambda to UseExceptionHandler. Using a lambda allows access to the error before returning the response.

app.UseExceptionHandler(exceptionHandlerApp =>
{
exceptionHandlerApp.Run(async context =>
{
context.Response.StatusCode = StatusCodes.Status500InternalServerError;           
context.Response.ContentType = Text.Plain;

await context.Response.WriteAsync("An exception was thrown.");

var exceptionHandlerPathFeature =
context.Features.Get<IExceptionHandlerPathFeature>();

if (exceptionHandlerPathFeature?.Error is FileNotFoundException)
{
await context.Response.WriteAsync(" The file was not found.");
}

if (exceptionHandlerPathFeature?.Path == "/")
{
await context.Response.WriteAsync(" Page: Home.");
}
});




You can also configure error code-specific pages in the Startup class Configure method:

app.Use(async (context, next) =>
{
    await next();
    if (context.Response.StatusCode == 404)
    {
        context.Request.Path = "/Not-Found";
        await next();
    }

if (context.Response.StatusCode == 403 || context.Response.StatusCode == 503 ||             context.Response.StatusCode == 500)
    {
        context.Request.Path = "/Home/Error";
        await next();
    }
});





Q125. What is the use of app.UseDeveloperExceptionPage() middleware in .Net Core applications? 

The Developer Exception Page displays detailed information about unhandled request exceptions. ASP.NET Core apps enable the developer exception page by default when running in the Development environment.

The developer exception page runs early in the middleware pipeline so that it can catch unhandled exceptions thrown in the middleware that follows. It can be only used in the dev because detailed exception information shouldn't be displayed publicly when the app runs in the Production environment. 

if (env.IsDevelopment())
{
   app.UseDeveloperExceptionPage();
}




The Developer Exception Page shows detailed stack traces for server errors. It uses DeveloperExceptionPageMiddleware to capture synchronous and asynchronous exceptions from the HTTP pipeline and to generate error responses. 

When the Developer Exception Page detects an unhandled exception, it generates a default plain-text response. But if the client requests an HTML-formatted response, the Developer Exception Page generates a response similar to HTML. The Developer Exception Page can include the following information about the exception and the request:



  1. Stack trace
  2. Query string parameters, if any
  3. Cookies, if any
  4. Headers

dev-exp-page

The Developer Exception Page isn't guaranteed to provide any information. So Logging is always required for complete error information. Also, don't enable the Developer Exception Page unless the app is running in the Development environment.




Q126. What is the difference between UseDeveloperExceptionPage and UseExceptionHandler?

In non-development environments, we use Exception Handling Middleware to produce an error payload (in API App) or an error response (in Web App). To configure a custom error handling page for the Production environment, the UseExceptionHandler is used.

The UseExceptionHandler exception handling middleware:

  1. Catches and logs unhandled exceptions.
  2. Re-executes the request in an alternate pipeline using the path indicated. The request isn't re-executed if the response has started. The template-generated code re-executes the request using the /Error path.
  3. But if the alternate pipeline throws an exception of its own, Exception Handling Middleware rethrows the original exception.

if (!app.Environment.IsDevelopment())
{
app.UseExceptionHandler("/Error");
app.UseHsts();
}



The Razor Pages app template provides an Error page (.cshtml) and PageModel class (ErrorModel) in the Pages folder. For an MVC app, the project template includes an Error action method and an Error view for the Home controller.

The exception-handling middleware re-executes the request using the original HTTP method. If an error handler endpoint is restricted to a specific set of HTTP methods, it runs only for those HTTP methods. 

For web APIs that use Swagger / OpenAPI, mark the error handler action with the [ApiExplorerSettings] attribute and set its IgnoreApi property to true. This attribute configuration excludes the error handler action from the app's OpenAPI specification:

[ApiExplorerSettings(IgnoreApi = true)]

Allow anonymous access to the method if unauthenticated users should see the error.

The ExceptionHandling Middleware can also be used in the development environment as well to produce a consistent payload format across all environments.

if (app.Environment.IsDevelopment())
{
app.UseExceptionHandler("/error-dev");
}
else
{
app.UseExceptionHandler("/error");
}




Q127. What is the app.UseStatusCodePages() middleware  in ASP.NETCore?

By default, an ASP.NET Core app doesn't provide a status code page for HTTP error status codes, such as 404 - Not Found. When the app sets an HTTP 400-599 error status code that doesn't have a body, it returns the status code and an empty response body. By using this middleware you can get different responses for different status codes. 

So to enable default text-only handlers for common error status codes, you need to call UseStatusCodePages in Program.cs:

if (!app.Environment.IsDevelopment())
{
app.UseExceptionHandler("/Error");
app.UseHsts();
}

app.UseStatusCodePages();



Please note that you have to call UseStatusCodePages before request handling middleware. For example, call UseStatusCodePages before the Static File Middleware and the Endpoints Middleware.

When UseStatusCodePages isn't used, navigating to a URL without an endpoint returns a browser-dependent error message indicating the endpoint can't be found. When UseStatusCodePages is called, the browser returns the following response:

Status Code: 404; Not Found

UseStatusCodePages isn't typically used in production because it returns a message that isn't useful to users. The status code page middleware does not catch exceptions. To provide a custom error handling page, use the exception handler page.

To customize the response content type and text, use the overload of UseStatusCodePages that takes a content type and format string:

app.UseStatusCodePages(Text.Plain, "Status Code Page: {0}");

Here the {0} is a placeholder for the error code. UseStatusCodePages with a format string isn't typically used in production because it returns a message that isn't useful to users.



Q128. What is UseStatusCodePagesWithRedirects middleware? What is the difference between UseStatusCodePages and UseStatusCodePagesWithRedirects?

The UseStatusCodePagesWithRedirects() extension method:

  1. Sends a new 302 - Found status code to the client.
  2. Then it Redirects the client to the error-handling endpoint provided in the URL template. The error handling endpoint typically displays error information and returns HTTP 200.

This method is commonly used when the app:

  1. Should redirect the client to a different endpoint, usually in cases where a different app processes the error. For web apps, the client's browser address bar reflects the redirected endpoint.
  2. Shouldn't preserve and return the original status code with the initial redirect response.

app.UseStatusCodePagesWithRedirects("/StatusCode/{0}");

The URL template can include a {0} placeholder for the status code. If the URL template starts with ~ (tilde), the ~ is replaced by the app's PathBase.  When specifying an endpoint in the app, create an MVC view or Razor page for the endpoint.






Q129. What is UseStatusCodePagesWithReExecute middleware? What is the difference between UseStatusCodePagesWithReExecute and UseStatusCodePagesWithRedirects? 

The UseStatusCodePagesWithReExecute extension method:

  1. Returns the original status code to the client.
  2. Generates the response body by re-executing the request pipeline using an alternate path.

This method is commonly used when the app should:

  1. Process the request without redirecting to a different endpoint. For web apps, the client's browser address bar reflects the originally requested endpoint.
  2. Preserve and return the original status code with the response.

If an endpoint within the app is specified, create an MVC view or Razor page for the endpoint.

app.UseStatusCodePagesWithReExecute("/StatusCode/{0}");

The URL template must start with / and may include a placeholder {0} for the status code. To pass the status code as a query-string parameter, pass a second argument into UseStatusCodePagesWithReExecute. 

app.UseStatusCodePagesWithReExecute("/StatusCode", "?statusCode={0}");

The endpoint that processes the error can get the original URL that generated the error.







Q130. What is the SkipStatusCodePages attribute in ASP.Net MVC Core?

To disable status code pages for an MVC controller or action method, use the [SkipStatusCodePages] attribute.

[SkipStatusCodePages]
MyController()
{
}

To disable status code pages for specific requests in a Razor Pages handler method or in an MVC controller, use IStatusCodePagesFeature:

public void OnGet()
{
var statusCodePagesFeature =
HttpContext.Features.Get<IStatusCodePagesFeature>();

if (statusCodePagesFeature is not null)
{
statusCodePagesFeature.Enabled = false;
}
}



Q131. What is AddDatabaseDeveloperPageExceptionFilter() in ASP.Net Core Application?

The Database developer page exception filter AddDatabaseDeveloperPageExceptionFilter captures database-related exceptions that can be resolved by using Entity Framework Core migrations.

When these exceptions occur, an HTML response is generated with details of possible actions to resolve the issue. This page is enabled only in the Development environment. 

builder.Services.AddDatabaseDeveloperPageExceptionFilter();
builder.Services.AddRazorPages();



Q132. What is the difference between Exception filters and built-in UseExceptionHandler middlewares in ASP.Net Core?

In MVC Exception filters handle any unhandled exceptions that occur during the execution of a controller action or another filter.

In MVC apps, exception filters can be configured globally or on a per-controller or per-action basis. In Razor Pages apps, they can be configured globally or per page model.

Exception filters are useful for trapping exceptions that occur within MVC actions, but they're not as flexible as the built-in exception-handling middleware i.e UseExceptionHandler

Microsoft recommends using UseExceptionHandler unless you need to perform error handling differently based on which MVC action is chosen.






Q133. How can you handle model validation errors and exceptions in ASP.Net Core applications?

The model state represents errors that come from two subsystems: model binding and model validation. Errors that originate from model binding are generally data conversion errors.

Both model binding and model validation occurs before the execution of a controller action or a Razor Pages handler method. For web apps, it's the app's responsibility to inspect ModelState.IsValid and react appropriately. Web apps typically redisplay the page with an error message.

For ASP.NET Core MVC with controllers and views:

if (!ModelState.IsValid)
{
return Page();
}



Web API controllers don't have to check ModelState.IsValid if they have the [ApiController] attribute. In that case, an automatic HTTP 400 response containing error details is returned when the model state is invalid. 

For Web API controllers, MVC responds with a ValidationProblemDetails response type when model validation fails. MVC uses the results of InvalidModelStateResponseFactory to construct the error response for a validation failure.

The following example replaces the default factory with an implementation that also supports formatting responses as XML, in Program.cs:

builder.Services.AddControllers()
.ConfigureApiBehaviorOptions(options =>
{
options.InvalidModelStateResponseFactory = context =>
new BadRequestObjectResult(context.ModelState)
{
ContentTypes =
{
// using static System.Net.Mime.MediaTypeNames;
Application.Json,
Application.Xml
}
};
})
.AddXmlSerializerFormatters();







Q134. How can you handle client responses for the user-defined custom exceptions? What is ProblemDetailsFactory middleware?

ASP.NET Core doesn't produce a standardized error payload when an unhandled exception occurs. For scenarios where it's desirable to return a standardized ProblemDetails response to the client, the ProblemDetails middleware can be used to map exceptions and 404 responses to a ProblemDetails payload.

The exception-handling middleware can also be used to return a ProblemDetails payload for unhandled exceptions.

In ASP.Net Core an error result is defined as a result with an HTTP status code of 400 or higher. For Web API controllers, MVC transforms an error result to produce a ProblemDetails.

MVC uses Microsoft.AspNetCore.Mvc.Infrastructure.ProblemDetailsFactory to produce all instances of ProblemDetails and ValidationProblemDetails. This factory is used for:



  1. Client error responses
  2. Validation failure error responses
  3. ControllerBase.Problem and ControllerBase.ValidationProblem

To customize the problem details response, register a custom implementation of ProblemDetailsFactory in Program.cs:

builder.Services.AddControllers();
builder.Services.AddTransient<ProblemDetailsFactory, SampleProblemDetailsFactory>();

Use the ClientErrorMapping property to configure the contents of the ProblemDetails response.  For example, to update the Link property for 404 responses:

builder.Services.AddControllers()
.ConfigureApiBehaviorOptions(options =>
{
options.ClientErrorMapping[StatusCodes.Status404NotFound].Link =
"https://httpstatuses.com/404";
});







To Be Continued Part-14...


Recommended Articles






Thanks for visiting this page. Please follow and join us on LinkedInFacebookTelegramQuoraYouTubeTwitterPinterestTumbler, and VK for regular updates.