All About ASP.NET and ASP.NET Core 2 Hosting BLOG

Tutorial and Articles about ASP.NET and the latest ASP.NET Core

ASP.NET Core Hosting :: How to Set Headers and HTTP Status Codes in ASP.NET Core

clock February 7, 2019 11:36 by author Jervis

I was working on an interesting issue in an ASP.NET Core recently. An external framework was responsible for creating an HTTP Response, and I was only in control of a little component that customized some internal behaviours (via a relevant extensibility point), without being able to influence the final response sent over HTTP.

This is common if you think about extending things like CMS systems or specialized services like for example Identity Server. In those situations, more often than not, the framework would be highly opinionated in what it is trying to do at the HTTP boundaries and as a result, trying to override the HTTP status codes or headers it produces may not be easy.

Let’s have a look at a simple generic workaround.

TL;DR

In ASP.NET Core you can hook a callback to the HTTP response object, which allows you to run arbitrary code just before the response starts getting sent or as soon as it has been sent. This allows you to override status code, headers or even change the response body even if your code is not responsible for flushing the response

// always set the status code to 418
response.OnStarting(() =>
{
    response.StatusCode = 418;
    return Task.CompletedTask;
});

The problem

To illustrate the problem better, let’s have a look at a concrete example – and I think Identity Server is a good choice here.

Identity Server allows you to register your own validators for various authentication grant types – for example client credentials grant, resource owner or even your own custom extension grant.

An implementation of such custom validator could like this:

public class MyResourceOwnerPasswordValidator : IResourceOwnerPasswordValidator
{
    public async Task ValidateAsync(ResourceOwnerPasswordValidationContext context)
    {
        var user = await UserStore.FindAndValidate(context.UserName, context.Password); 

        if (user == null || !user.IsValid())
        {
            // reject as the credentials are incorrect or account invalid
            context.Result = new GrantValidationResult(TokenRequestErrors.InvalidRequest, "Invalid username or password.");
            return;
        }        

        if (!user.IsCountrySupported())
        {
            // reject as the country of the user is not allowed
            context.Result = new GrantValidationResult(TokenRequestErrors.InvalidRequest, "Country not supported.");
            return;
        }        

        // allow
        context.Result = new GrantValidationResult(user.Id, "password", user.Claims, "idsrv");
    }
}

In other words, we validate the user, and allow the token to be issued if the username and password are correct. If not, we will produce a token request error; in addition to that we also produce a different error if the user credentials are correct but the country is not supported.

This is all nice and fine. We have no touchpoints to the HTTP response here, as Identity Server (or any other framework/service that we might be using) would take care of that for us. We only produce the result that we are mandated to produce by the contract – a GrantValidationResult in this case.

It works well in most situations. However, let’s imagine that we’d like to influence the HTTP status codes being returned from this validation code. At the moment the status codes are hidden from us, and it is the responsibility of Identity Server to produce them.

In our case, the Identity Server would actually be returning 2 different ones:

  • GrantValidationResult(user.Id, “password”, user.Claims, “idsrv”) would obviously produce a 200 and result in a token being sent to the user
  • GrantValidationResult(TokenRequestErrors.InvalidRequest, “{ERROR DESCRIPTION}”) would produce a 400 and convey the error description to the caller in the error_description JSON property of the response (as defined by the spec).

Now let’s imagine the situation, that for the code path of user.IsCountrySupported(), we’d like to use HTTP status code 451 instead. This is allowed by the spec, which states “the authorization server responds with an HTTP 400 (Bad Request) status code (unless specified otherwise)”. However, such status code customization is currently not supported by Identity Server.

Let’s have a look at addressing this via a neat ASP.NET Core feature. Before we get there – in case you don’t agree with this spec interpretation – remember that this is merely an example to illustrate that ASP.NET Core feature.

Wrong way to deal with it

There are several ideas of dealing with this, that come to mind straight away.

One naive approach would be to try to throw an exception, let it bubble up as far as possible and then handle it in a way that you can convert the response to the relevant HTTP status code (perhaps with a global handler registered in your Startup class). This, however, wouldn’t work with Identity Server, as it handles all exceptions in the pipeline on its own, without letting it bubble up. In fact, this would typically be the case with most frameworks or services of that sort, not to mention using exceptions for flow control is iffy at best.

Another approach could be to try to write a middleware component, that runs at the end of HTTP pipeline (so wraps the Identity Server middleware) and use it to change the status code. This seems like a great idea at first, but unfortunately it wouldn’t work.

The reason for that is that ASP.NET Core would flush the headers of the response as soon as the first body write happens, and Identity Server, in its pipeline, would start writing to the body already. This means that even though you can technically (there would be no exception thrown for that) change the status code on the response, or inject some headers into it using a custom middleware that runs at the end of the pipeline, that would have no effect on the response anymore, as it is simply too late. You can actually normally see that on the response object by inspecting the response.HasStarted property – at that moment status code and headers modifications are not possible anymore.

One other idea could be to hijack the response writing completely. Since you can inject IHttpContextAccessor to any class, anywhere in the ASP.NET Core application, you can fairly easily get a hold of the HttpResponse. This allows you to simply write to the HTTP response directly. Such approach could possibly work but it is not very elegant to say the least. It would require you to correctly produce the entire set of headers (also the more esoteric ones like Cache-Control and so on) and the status code correctly and flush it before Identity Server can do that, allowing it to only complete the response by writing the body. This is very error prone and very unmaintainable.

Simple solution

A simple and elegant solution is to leverage a little known feature of ASP.NET Core – the ability to register your own callback on the HttpResponse, that would run as soon as the response is started to be sent (or as soon as its completed).

The following hooks exist on the HttpResponse:

/// <summary>
/// Adds a delegate to be invoked just before response headers will be sent to the client.
/// </summary>
/// <param name="callback">The delegate to execute.</param>
/// <param name="state">A state object to capture and pass back to the delegate.</param>
public abstract void OnStarting(Func<object, Task> callback, object state); 

/// <summary>
/// Adds a delegate to be invoked just before response headers will be sent to the client.
/// </summary>
/// <param name="callback">The delegate to execute.</param>
public virtual void OnStarting(Func<Task> callback) => OnStarting(_callbackDelegate, callback); 

/// <summary>
/// Adds a delegate to be invoked after the response has finished being sent to the client.
/// </summary>
/// <param name="callback">The delegate to invoke.</param>
/// <param name="state">A state object to capture and pass back to the delegate.</param>
public abstract void OnCompleted(Func<object, Task> callback, object state); 

/// <summary>
/// Adds a delegate to be invoked after the response has finished being sent to the client.
/// </summary>
/// <param name="callback">The delegate to invoke.</param>
public virtual void OnCompleted(Func<Task> callback) => OnCompleted(_callbackDelegate, callback);

This means we can simply register a delegate that would change the HTTP Status Code, modify the headers and possibly even meddle with the response body, from any point in the ASP.NET Core application. Then, as soon as the response starts being sent (irrespective to the fact which component or part of the pipeline triggered that), our code would run, allowing us to influence the structure of that response.

It is extremely convenient, as we are able to create de facto extensibility points for 3rd party applications, frameworks or services (like Identity Server), in places where they normally don’t exist.

In our case, the final code looks like this:

public static class HttpResponseExtensions
{
    public static void SetHttpStatusCodeOverride(this HttpResponse response, int httpStatusCode)
    {
        response.OnStarting(() =>
        {
            response.StatusCode = httpStatusCode;
            return Task.CompletedTask;
        });
    }


public class MyResourceOwnerPasswordValidator : IResourceOwnerPasswordValidator
{
   private readonly IHttpContextAccessor _httpContextAccessor;  

   public MyResourceOwnerPasswordValidator(IHttpContextAccessor httpContextAccessor)
   {
       _httpContextAccessor = httpContextAccessor;
   } 

    public async Task ValidateAsync(ResourceOwnerPasswordValidationContext context)
    {
        var user = await UserStore.FindAndValidate(context.UserName, context.Password); 

        if (user == null || !user.IsValid())
        {
            // default 400
            // reject as the credentials are incorrect or account invalid
            context.Result = new GrantValidationResult(TokenRequestErrors.InvalidRequest, "Invalid username or password.");
            return;
        }        

        if (!user.IsCountrySupported())
        {
            // overridden to 451
            // reject as the country of the user is not allowed
           _httpContextAccessor.HttpContext.Response.SetHttpStatusCodeOverride(451);
            context.Result = new GrantValidationResult(TokenRequestErrors.InvalidRequest, "Country not supported.");
            return;
        }        

        // allow
        context.Result = new GrantValidationResult(user.Id, "password", user.Claims, "idsrv");
    }
}

I hope you will find this technique useful – I used Identity Server as an example, because it actually solves a real world problem here – but I think you could apply this approach in various places where you’d like to have a certain response-based extensibility point and it’s simply not available.



ASP.NET Core Hosting :: How to Implement Action Filters in ASP.NET Core

clock January 28, 2019 08:50 by author Jervis

Filters in .NET offer a great way to hook into the MVC action invocation pipeline. Therefore, we can use filters to extract code which can be reused and make our actions cleaner and maintainable. There are some filters that are already provided by .NET like the authorization filter, and there are the custom ones that we can create ourselves.

There are different filter types:

  • Authorization filters – They run first to determine whether a user is authorized for the current request
  • Resource filters – They run right after the authorization filters and are very useful for caching and performance
  • Action filters – They run right before and after the action method execution
  • Exception filters – They are used to handle exceptions before the response body is populated
  • Result filters – They run before and after the execution of the action methods result.

In this article, we are going to talk about Action filters and how to use them to create a cleaner and reusable code in our Web API’s.

Action Filters Implementation

To create an Acton filter, we need to create a class that inherits either from the IActionFilter interface or IAsyncActionFilter interface or from the ActionFilterAttribute class which is the implementation of the IActionFilterIAsyncActionFilter, and few different interfaces as well:

public abstract class ActionFilterAttribute : Attribute, IActionFilter, IFilterMetadata, IAsyncActionFilter, IResultFilter, IAsyncResultFilter, IOrderedFilter

In our examples, we are going to inherit from the IActionFIlter interface because it has all the method definitions we require.

To implement the synchronous Action filter that runs before and after action method execution, we need to implement OnActionExecuting and OnActionExecuted methods:

namespace ActionFilters.Filters
{
    public class ActionFilterExample : IActionFilter
    {
        public void OnActionExecuting(ActionExecutingContext context)
        {
            // our code before action executes
        } 

        public void OnActionExecuted(ActionExecutedContext context)
        {
            // our code after action executes
        }
    }
}

We can do the same thing with an asynchronous filter by inheriting from IAsyncActionFilter, but we only have one method to implement the OnActionExecutionAsync:

namespace ActionFilters.Filters
{
    public class AsyncActionFilterExample : IAsyncActionFilter
    {
        public async Task OnActionExecutionAsync(ActionExecutingContext context, ActionExecutionDelegate next)
        {
            // execute any code before the action executes
            var result = await next();
            // execute any code after the action executes
        }
    }
}

The Scope of Action Filters

Like the other types of filters, the action filter can be added to different scope levels: Global, Action, Controller.

If we want to use our filter globally, we need to register it inside the AddMvc() method in the ConfigureServices method:

services.AddMvc(
  config =>
  {
     config.Filters.Add(new GlobalFilterExample());
  });

But if we want to use our filter as a service type on the Action or Controller level, we need to register it in the same ConfigureServices method but as a service in the IoC container:

services.AddScoped<ActionFilterExample>();
services.AddScoped<ControllerFilterExample>();

Finally, to use a filter registered on the Action or Controller level, we need to place it on top of the Controller or Action as a ServiceType:

namespace AspNetCore.Controllers
{
    [ServiceFilter(typeof(ControllerFilterExample))]
    [Route("api/[controller]")]
    public class TestController : Controller
    {
        [HttpGet]
        [ServiceFilter(typeof(ActionFilterExample))]
        public IEnumerable<string> Get()
        {
            return new string[] { "example", "data" };
        } 

    }
}

Order of Invocation

The order in which our filters are executed is as follows:

Of course, we can change the order of invocation by adding an additional property Order to the invocation statement:

namespace AspNetCore.Controllers
{
    [ServiceFilter(typeof(ControllerFilterExample), Order=2)]
    [Route("api/[controller]")]
    public class TestController : Controller
    {
        [HttpGet]
        [ServiceFilter(typeof(ActionFilterExample), Order=1)]
        public IEnumerable<string> Get()
        {
            return new string[] { "example", "data" };
        } 

    }
}

Or something like this on top of the same action:

[HttpGet]
[ServiceFilter(typeof(ActionFilterExample), Order=2)]
[ServiceFilter(typeof(ActionFilterExample2), Order=1)]
public IEnumerable<string> Get()
{
    return new string[] { "example", "data" };
}

Improving the Code with Action Filters

If we open the starting project from the AppStart folder from our repository, we can find the MoveController class in the Controllers folder. This controller has an implementation for all the CRUD operations. For the sake of simplicity, we haven’t used any additional layers for our API. 

Our actions are quite clean and readable without try-catch blocks due to global exception handling, but we can improve them even further.

The important thing to notice is that our Movie model inherits from the IEntity interface:

[Table("Movie")]
public class Movie: IEntity
{
    [Key]
    public Guid Id { get; set; }
    [Required(ErrorMessage = "Name is required")]
    public string Name { get; set; }
    [Required(ErrorMessage = "Genre is required")]
    public string Genre { get; set; }
    [Required(ErrorMessage = "Director is required")]
    public string Director { get; set; }
}

So let’s start with the validation code from the POST and PUT actions.

Validation with Action Filters

If we look at our POST and PUT actions, we can notice the repeated code in which we validate our Movie model:

if (movie == null)
{
     return BadRequest("Movie object is null");


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

We can extract that code into a custom Action Filter class, thus making this code reusable and the action cleaner.

So let’s do that.

Let’s create a new folder in our solution explorer, and name it ActionFilters. Then inside that folder, we are going to create a new class ValidationFilterAttribute:

using Microsoft.AspNetCore.Mvc.Filters; 

namespace ActionFilters.ActionFilters
{
    public class ValidationFilterAttribute : IActionFilter
    {
        public void OnActionExecuting(ActionExecutingContext context)
        {            

        } 

        public void OnActionExecuted(ActionExecutedContext context)
        {            

        }
    }
}

Now we are going to modify the OnActionExecuting method to validate our model:

using ActionFilters.Contracts;
using Microsoft.AspNetCore.Mvc;
using Microsoft.AspNetCore.Mvc.Filters;
using System.Linq; 

namespace ActionFilters.ActionFilters
{
    public class ValidationFilterAttribute : IActionFilter
    {
        public void OnActionExecuting(ActionExecutingContext context)
        {
            var param = context.ActionArguments.SingleOrDefault(p => p.Value is IEntity);
            if(param.Value == null)
            {
                context.Result = new BadRequestObjectResult("Object is null");
                return;
            }            

            if(!context.ModelState.IsValid)
            {
                context.Result = new BadRequestObjectResult(context.ModelState);
            }
        } 

        public void OnActionExecuted(ActionExecutedContext context)
        {          
        }
    }
}

Next, let’s register this action filter in the ConfigureServices method:

public void ConfigureServices(IServiceCollection services)
{
       services.AddDbContext<MovieContext>(options =>
           options.UseSqlServer(Configuration.GetConnectionString("sqlConString"))); 

       services.AddScoped<ValidationFilterAttribute>(); 

       services.AddMvc();
}

Finally, let’s remove that validation code from our actions and call this action filter as a service:

[HttpPost]
[ServiceFilter(typeof(ValidationFilterAttribute))]
public IActionResult Post([FromBody] Movie movie)
{
     _context.Movies.Add(movie);
     _context.SaveChanges(); 

     return CreatedAtRoute("MovieById", new { id = movie.Id }, movie);


[HttpPut("{id}")]
[ServiceFilter(typeof(ValidationFilterAttribute))]
public IActionResult Put(Guid id, [FromBody]Movie movie)
{
    var dbMovie = _context.Movies.SingleOrDefault(x => x.Id.Equals(id));
    if (dbMovie == null)
    {
        return NotFound();
    } 

    dbMovie.Map(movie); 

    _context.Movies.Update(dbMovie);
    _context.SaveChanges(); 

    return NoContent();
}

Excellent.

This code is much cleaner and more readable now without the validation part. And furthermore, the validation part is now reusable as long as our model classes inherit from the IEntity interface, which is a quite common behavior.

If we send a POST request for example with the invalid model we will get the BadRequest response:

Dependency Injection in Action Filters

If we take a look at our GetById, POST and PUT actions, we are going to see the code where we fetch the move by id from the database and check if it exists:

var dbMovie = _context.Movies.SingleOrDefault(x => x.Id.Equals(id));
if (dbMovie == null)
{
     return NotFound();
}

That’s something we can extract to the Action Filter class as well, thus making it reusable in all the actions.

Of course, we need to inject our context in a new ActionFilter class by using dependency injection.

So, let’s create another Action Filter class ValidateEntityExistsAttribute in the ActionFilters folder and modify it:

using System.Linq; 

namespace ActionFilters.ActionFilters
{
    public class ValidateEntityExistsAttribute<T> : IActionFilter where T: class, IEntity
    {
        private readonly MovieContext _context; 

        public ValidateEntityExistsAttribute(MovieContext context)
        {
            _context = context;
        } 

        public void OnActionExecuting(ActionExecutingContext context)
        {
            Guid id = Guid.Empty; 

            if (context.ActionArguments.ContainsKey("id"))
            {
                id = (Guid)context.ActionArguments["id"];
            }
            else
            {
                context.Result = new BadRequestObjectResult("Bad id parameter");
                return;
            } 

            var entity = _context.Set<T>().SingleOrDefault(x => x.Id.Equals(id));    
            if(entity == null)
            {
                context.Result = new NotFoundResult();
            }
            else
            {
                context.HttpContext.Items.Add("entity", entity);
            }
        }

        public void OnActionExecuted(ActionExecutedContext context)
        {
        }
    }
}

We’ve created this Action Filter class to be generic so that we could reuse it for any model in our project. Furthermore, if we find the entity in the database, we store it in HttpContext because we need that entity in our action methods and we don’t want to query the database two times (we would lose more than we gain if we double that action).

Now let’s register it:

services.AddScoped<ValidateEntityExistsAttribute<Movie>>();

And let’s modify our actions:

[HttpGet("{id}", Name = "MovieById")]
[ServiceFilter(typeof(ValidateEntityExistsAttribute<Movie>))]
public IActionResult Get(Guid id)
{
    var dbMovie = HttpContext.Items["entity"] as Movie; 

    return Ok(dbMovie);
}
[HttpPut("{id}")]
[ServiceFilter(typeof(ValidationFilterAttribute))]
[ServiceFilter(typeof(ValidateEntityExistsAttribute<Movie>))]
public IActionResult Put(Guid id, [FromBody]Movie movie)
{
    var dbMovie = HttpContext.Items["entity"] as Movie; 

     dbMovie.Map(movie); 

     _context.Movies.Update(dbMovie);
     _context.SaveChanges(); 

     return NoContent();


[HttpDelete("{id}")]
[ServiceFilter(typeof(ValidateEntityExistsAttribute<Movie>))]
public IActionResult Delete(Guid id)
{
    var dbMovie = HttpContext.Items["entity"] as Movie; 

     _context.Movies.Remove(dbMovie);
     _context.SaveChanges(); 

     return NoContent();
}

Awesome.

Now our actions look great without code repetition, try-catch blocks or additional fetch request towards the database.

Conclusion

Thank you for reading this article. We hope you have learned new useful things.

As we already said, we always recommend using Action Filters because they give us reusability in our code and cleaner code in our actions as well.



ASP.NET Core Hosting :: How to Add Custom Processing to Request in ASP.NET

clock January 22, 2019 08:57 by author Jervis

When a request comes in to your ASP.NET site, it's routed through a series of message handlers (in ASP.NET Web API) or modules (in ASP.NET MVC), each of which performs some operation on the request. After a request is processed (presumably, by one of your Controllers), the response from your request goes through those handlers or modules again on its way back to the client.

Putting code in a handler or module allows you to perform some operation on every inbound request or outbound response. So, for example, if you want to customize security for your site, a good way to do that is to add your own module or handler to this chain. Alternatively, if you wanted to check data leaving your Web API site for "sensitive" information, a module or handler would be a good choice for that task, also.

The Limitations of ASP.NET Modules

Of the two technologies, ASP.NET MVC's HttpModules are the most limited. In many ways, modules are legacy technology dating from the beginnings of ASP.NET. However, this is the only option if you really do want to process every request to your site (including, for example, requests for image files and CSS files). You can even use HttpModules in Web API application.

The problem here is that the methods in a module are passed an HttpApplication object that has Context, Request and Response properties. These properties give you access to information about the request being made to your site and the response your site is returning. These are the same objects you have access to in your Controllers and, as in your Controllers, most of the properties on these objects are read-only. So, in an HttpModule you're limited to reading the incoming request or response or adding/removing headers on them.

Creating an HttpModule

Creating a module is a bit of a pain, also. First, you need to declare a class that implements the IHttpModule interface and give it a property called ModuleName that returns the name of your class as a string. You'll also need a Dispose method. Here's the start of a typical module:

public class GenericHttpModule : IHttpModule
{
  public String ModuleName
  {
    get
    {
      return "GenericHttpModule";
    }
  }
  public void Dispose() { }

Your next step is to add the Init method, which returns nothing but accepts an HttpApplication object. In this method, to process incoming requests, you need to wire up a method of your own to the HttpApplication object's BeginRequest method; if you want to process the outbound Response, you'll wire up your method to the object's EndRequest method. Here's an Init method that does both:

public void Init(HttpApplication application)
{
  application.BeginRequest += (new EventHandler(Inbound));
  application.EndRequest += (new EventHandler(Outbound));
}

The signatures of both the BeginRequest and EndRequest methods are the same: The methods are passed two parameters, one of type object and one of type EventArgs. The first parameter is the interesting one because it holds a reference to the HttpApplication object that holds the Context, Request and Response properties. The two methods I would need to work with the code in my Init method would look like this:

private void Inbound(Object source, EventArgs e)
{
  HttpApplication application = (HttpApplication)source;
  // ... process inbound request ...
}
private void Outbound(Object source, EventArgs e)
{
  HttpApplication application = (HttpApplication)source;
  // ... process outbound request ...            
}

You have one final thing to do: To have ASP.NET actually use your module, you need to tell your application about it. You do that in your web.config file with an add element, inside its modules element (IIS 7.0) or its httpModules element (IIS 6.0/IIS 7.0 running in Classic mode). The add element must reference both the name of your class and its type. This element would tie my sample module into the chain in IIS 7.0 (and would do the same in the httpModules element):

<modules> <add name="GenericHttpModule" type="HttpModulesAPI.GenericHttpModule"/>

The Basics of Handlers

Creating an ASP.NET Web API handler is, comparatively speaking, much simpler.

First, you must create a class that inherits from DelegatingHandler. Once you've done that, you override your class's SendAsync method. When a request hits your site, your SendAsync method will be passed the incoming request as an HttpRequestMessage. You have more flexibility here than you do with modules: you can add or remove headers or replace the message's content.

When you've done whatever you want with the incoming request, you call the base class's SendAsync method, passing the request message (there's also a cancellation token involved but I'll ignore it for simplicity's sake). Calling the base SendAsync method passes the request on to the next handler in the chain and, eventually, to your controller.

After your Controller has processed your request, the response message will be returned back through the chain of handlers as an HttpResponseMessage object. That means that your call to the base SendAsync method will, eventually, return the response from your Controller to your handler. Again, you can add or remove headers or replace the message's Content before returning the message to the ASP.NET process that called your delegating handler in the first place. Eventually, that response message will be delivered to the client that made the original request.

Here's the skeleton of a typical handler:

public class GenericMessageHandler : DelegatingHandler
{
  protected async override System.Threading.Tasks.Task<HttpResponseMessage>
          SendAsync(HttpRequestMessage request,
          System.Threading.CancellationToken cancellationToken)
  {
    //...work with HttpRequestMessage...
    HttpResponseMessage resp = await base.SendAsync(request, cancellationToken);
    //...work with HttpReqponseMessage
    return resp;
  }
}

And, in fact, you don't have to call the base SendAsync method at all -- there's nothing stopping you from creating an HttpResponseMessage in your SendAsync method and returning that.

Adding Your Handler to the Pipeline

To have your application use your handler, go to your App_Start folder, open the WebApiConfig file and add your new handler class to the config parameter's MessageHandlers class. This code, for example, adds my handler to the pipeline:

config.MessageHandlers.Add(new GenericMessageHandler());

But I have to be honest here: My experience has been that (outside of security) there are very few operations that I want to perform on every request to my ASP.NET Web API site. As a result, my typical handler begins with a bunch of If statements that check to see if this is a request that my handler should work with. In those scenarios, ASP.NET Web API gives me alternative: I can add the relevant handler just to the specific routes where it's needed.

To do that, I go to ASP.NET Web API's WebApiConfig file in the App_Start folder and add a fifth parameter to the MapHttpRoute method used to define routes (to use this parameter, you must provide a value for the constraints parameter on the method, even if all you provide is null). The handler parameter allows me to specify a DelegatingHandler to be used in processing requests and responses in that route. Here's an example with my GenericMessageHandler added to a route that grabs requests for my Customer controller (as this code shows, to tie my handler into the processing pipeline I also have to set its InnerHandler property to HttpControllerDispatcher):

config.Routes.MapHttpRoute(
                name: "CustomerApi",
                routeTemplate: "api/Customer/{id}",
                defaults: new { id = RouteParameter.Optional },
                constraints: null,                            
                handler: new GenericMessageHandler(){InnerHandler = new HttpControllerDispatcher(config) }
            );

I can, of course, selectively add this handler to multiple routes.

So if you want to add processing to every request that your site gets (or even just some of them), then you don't have to add code to every Controller or Action method in your project. You can, instead, bundle that code into either a module (for ASP.NET MVC) or a handler (for ASP.NET Web API).



ASP.NET Hosting :: Alternative Localization for Asp.Net Core Applications

clock January 16, 2019 10:41 by author Jervis

Asp.Net Core Built-In Support

This is code fragment from official documentation how to localize content using built-in functionality.

App Content Localization

[Route("api/[controller]")]
public class AboutController : Controller
{
    private readonly IStringLocalizer<AboutController> _localizer;

    public AboutController(IStringLocalizer<AboutController> localizer)
    {
        _localizer = localizer;
    }

    [HttpGet]
    public string Get()
    {
        return _localizer["About Title"];
    }
}

And if you are working with Html content that shouldn't be escaped during rendering - you are using IHtmlLocalizerimplementation that returns LocalizedHtmlString instance.

public class BookController : Controller
{
    private readonly IHtmlLocalizer<BookController> _localizer;

    public BookController(IHtmlLocalizer<BookController> localizer)
    {
        _localizer = localizer;
    }

    public IActionResult Hello(string name)
    {
        ViewData["Message"] = _localizer["<b>Hello</b><i> {0}</i>", name];

        return View();
    }
}

View Localization

For the view localization - there is another injectable interface IViewLocalizer.

@inject IViewLocalizer Localizer

@{
    ViewData["Title"] = Localizer["About"];
}

Alternative: Strongly-Typed DbLocalizationProvider

Where is my problem with built-in providers? They all are "stringly-typed". You have to provide string as either key or translation of the resource. I'm somehow more confident strongly-typed approach where I can use "Find All Usages", "Rename" or do any other static code operation that's would not be entirely possible in built-in approach.

Over the time I've been busy developing alternative localization provider for Asp.Net and Episerver (it's brilliant content management system) platforms specifically.

Thought getting that over to Asp.Net Core should not be hard. And it wasn't. So here we are - DbLocalizationProviderfor Asp.Net Core.

Getting Started

There are couple of things to setup first, before you will be able to start using strongly-typed localization provider.

First, you need to install the package (it will pull down other dependencies also).

PM> Install-Package LocalizationProvider.AspNetCore

Second you need to setup/configure services.
In your Startup.cs class you need to stuff related to Mvc localization (to get required services into DI container - service collection).

And then services.AddDbLocalizationProvider(). You can pass in configuration settings class and setup provider's behavior.

public class Startup
{
    public Startup(IConfiguration configuration)
    {
        Configuration = configuration;
    }

    public void ConfigureServices(IServiceCollection services)
    {
        services.AddLocalization();

        services.AddMvc()
                .AddViewLocalization()
                .AddDataAnnotationsLocalization();

        services.AddDbLocalizationProvider(cfg =>
        {
            cfg...
        });
    }
}

After then you will need to make sure that you start using the provider:

public class Startup
{
    public Startup(IConfiguration configuration)
    {
        Configuration = configuration;
    }

    public void ConfigureServices(IServiceCollection services)
    {
        ...
    }

    public void Configure(IApplicationBuilder app, IHostingEnvironment env)
    {
        ...

        app.UseDbLocalizationProvider();
    }
}

Using localization provider will make sure that resources are discovered and registered in the database (if this process will not be disabled via AddDbLocalizationProvider() method).

App Content Localization

Localizing application content via IStringLocalizer<T> is similar as that would be done for regular Asp.Net applications.

You have to define resource container type:

[LocalizedResource]
public class SampleResources
{
    public string PageHeader => "This is page header";
}

Then you can demand IStringLocalizer<T> is any place you need that one (f.ex. in controller):

public class HomeController : Controller
{
    private readonly IStringLocalizer<SampleResources> _localizer;

    public HomeController(IStringLocalizer<SampleResources> localizer)
    {
        _localizer = localizer;
    }

    public IActionResult Index()
    {
        var smth = _localizer.GetString(r => r.PageHeader);
        return View();
    }
}

As you can see - you are able to use nice strongly-typed access to the resource type: _localizer.GetString(r => r.PageHeader);.

Even if you demanded strongly-typed localizer with specified container type T, it's possible to use also general/shared static resources:

[LocalizedResource]
public class SampleResources
{
    public static string SomeCommonText => "Hello World!";
    public string PageHeader => "This is page header";
}

public class HomeController : Controller
{
    private readonly IStringLocalizer<SampleResources> _localizer;

    public HomeController(IStringLocalizer<SampleResources> localizer)
    {
        _localizer = localizer;
    }

    public IActionResult Index()
    {
        var smth = _localizer.GetString(() => SampleResources.SomeCommonText);
        return View();
    }
}

View Localization

Regarding the views, story here is exactly the same - all built-in approach is supported:

@model UserViewModel
@inject IViewLocalizer Localizer
@inject IHtmlLocalizer<SampleResources> HtmlLocalizer

@Localizer.GetString(() => SampleResources.SomeCommonText)
@HtmlLocalizer.GetString(r => r.PageHeader)

Data Annotations

Supported. Sample:

[LocalizedModel]
public class UserViewModel
{
    [Display(Name = "User name:")]
    [Required(ErrorMessage = "Name of the user is required!")]
    public string UserName { get; set; }

    [Display(Name = "Password:")]
    [Required(ErrorMessage = "Password is kinda required :)")]
    public string Password { get; set; }
}

View.cshtml:

@model UserViewModel

<form asp-controller="Home" asp-action="Index" method="post">
    <div>
        <label asp-for="UserName"></label>
        <input asp-for="UserName"/>
        <span asp-validation-for="UserName"></span>
    </div>
    <div>
        <label asp-for="Password"></label>
        <input asp-for="Password" type="password"/>
        <span asp-validation-for="Password"></span>
    </div>
    ...
</form>

Localization in Libraries

You can either rely on IStringLocalizer implementation that's coming from Microsoft.Extensions.Localizationnamespace and demand that one in your injections:

using Microsoft.Extensions.Localization;
public class MyService
{
    public MyService(IStringLocalizer localizer)
    {
       ...
    }
}

Or you can also depend on LocalizationProvider class defined in DbLocalizationProvider namespace:

using DbLocalizationProvider;
public class MyService
{
    public MyService(LocalizationProvider provider)
    {
       ...
    }
}

Both of these types provide similar functionality in terms how to retrieve localized content.

Changing Culture

Sometimes you need to get translation for other language and not primary UI one.
This is possible either via built-in method:

@inject IHtmlLocalizer<SampleResources> Localizer

Localizer.WithCulture(new CultureInfo("no"))
         .GetString(() => SampleResources.SomeCommonText)

Or via additional extension method:

@inject IHtmlLocalizer<SampleResources> Localizer
Localizer.GetStringByCulture(() => SampleResources.SomeCommonText, new Culture("no"))

Stringly-Typed Localization

For backward compatibility or even if you wanna go hardcore and supply resource keys manually (for reasons) stingly-typed interface is also supported:

using Microsoft.Extensions.Localization;

public class MyService
{
    public MyService(IStringLocalizer localizer)
    {
       var header = localizer["MyProject.Resources.Header"];
    }
}

 



ASP.NET Core Hosting :: 5 Reasons to Use ASP.NET Core

clock January 9, 2019 08:33 by author Jervis

When it comes to web application development, there are multiple technologies available to choose from. There are open-source technologies like Java & PHP, and then, there is closed-source technology ASP.NET MVC.

While millions of web developers use ASP.NET MVC to build web applications, but the latest ASP.NET Core framework offers far more benefits than the ASP.NET MVC for web application development.

ASP.NET Core is an open-source, cross-platform framework developed by both the Microsoft and its community. Basically, it is a complete reform of ASP.NET that combines MVC structure and Web API into a single framework.

Why Use ASP.NET Core for Web Application Development?

ASP.NET Core is an emerging, robust, and feature-rich framework that provides features to develop super-fast APIs for web apps.

Let’s take a look at the elements that make ASP.NET Core a right choice for Enterprise app development

1 — The MVC Architecture

Back in the days of the classic ASP.NET, developers had to worry about IsPostBack & ViewState. But with MVC, web application development has become more natural and the workflow also more efficient. In addition, the latest ASP.NET Core framework further helps in developing web APIs & web applications testable in better way, by achieving a clear separation of concerns.

In simple terms, ASP.NET Core makes it easier for developers to code, compile, and test something in either model, view, or the controller.

2 — Razor Pages

Razor Pages is a new element of ASP.NET Core that makes programming page-focused scenarios more productive. In technical terms, Razor Pages is a page-based coding model that makes building web UI easier.

If you’ve ever worked on ASP.NET MVC framework before, then you already know that the controller classes are filled with a large amount of actions. And not only that, but they also grow as the new things are added.

With Razor Pages, each web page becomes self-contained with its View component, and the code is also organized well together.

3 — Provides Support for Popular JavaScript Frameworks

Unlike ASP.NET MVC, the new .NET Core framework provides build-in templates for two most popular JavaScript frameworks — Angular & React (plus Aurelia).

The JavaScriptServices in the new ASP.NET Core provides an infrastructure that developers need to develop client-side apps using the above mentioned JavaScript frameworks.

The JavaScriptServices basically aims to eliminate underlying plumbing to allow developers start coding applications sooner, making it possible to build feature-rich front-end web applications.

4 — Improved Collaboration & Cross-Platform Support

ASP.NET Core is a cross-platform framework, meaning the apps build using this framework can run on Windows, Linux, and Mac Operating systems. In addition, the developers are also free to choose their development OS as well.

In simple terms, your developers can work across Linux, MacOS, or Windows and they can still collaborate on the same project. This is possible with unified experience offered by the Visual Studio IDE.

In short, the ASP.NET Core framework has the capacity to build & run web applications on Windows, Linux, and Mac OS.

5 — In-Built Dependency Injection Support

ASP.NET Core framework provides an in-built dependency injection, meaning you do not need rely on third-party frameworks like Ninject or AutoFactor anymore.

Dependency Injection is basically a pattern that can help developer distinguish the different pieces of their apps. Before the release of ASP.NET Core, the only way to get Dependency injection in any application was by using the above mentioned frameworks (Ninject, AutoFactor). But in ASP.NET Core, the dependency injection is treated as a first-class citizen. What this means is that developers are no longer limited to web applications, and they can leverage new libraries in more event-driven apps such as AWS Lambda or Azure Functions.

Overall, the dependency injection in the ASP.NET Core framework improves the testability and extensibility of web applications. 



ASP.NET Core Hosting :: How to Use StructureMap with ASP.NET Core

clock January 8, 2019 10:26 by author Jervis

This example shows how to use Structuremap dependency injection framework with ASP.NET Core instead of framework-level dependency injection.

ADDING STRUCTUREMAP TO ASP.NET CORE PROJECT

For Structuremap support in ASP.NET Core application we need two NuGet packages

  • StructureMap - core StructureMap package
  • StructureMap.Microsoft.DependencyInjection - adds support for ASP.NET Core

These packages are enough for getting StructureMap up and running.

DEMO SERVICES

For demo purposes let's define primitive messaging service interface and couple of implementations.

public interface IMessagingService
{
    string GetMessage();
}

public class BuiltInDiMessagingService : IMessagingService
{
    public string GetMessage()
    {
        return "Hello from built-in dependency injection!";
    }
}

public class StructuremapMessagingService : IMessagingService
{
    public string GetMessage()
    {
        return "Hello from Structuremap!";
    }
}

We need two implementations to demonstrate how built-in dependency injection is replaced by StructureMap.

DEFINING STRUCTUREMAP REGISTRY

StructureMap uses registry classes for defining dependencies. Direct definitions are also supported but for more complex applications we will write registries anyway. Here is our registry class.

public class MyStructuremapRegistry : Registry
{
    public MyStructuremapRegistry()
    {
        For<IMessagingService>().LifecycleIs(Lifecycles.Container)
                                .Use<StructuremapMessagingService>();
    }
}

ATTACHING STRUCTUREMAP TO ASP.NET CORE APPLICATION

StructureMap is attached to ASP.NET Core when application is starting up. We have to make three updates to ConfigureServices() method of StartUp class:

  • initialize and configure StructureMap container
  • make ConfigureServices return IServiceProvider
  • return IServiceProvider by StructureMap

public IServiceProvider ConfigureServices(IServiceCollection services)
{
    services.AddMvc();

    services.AddTransient<IMessagingService, BuiltInDiMessagingService>();

    var container = new Container();

    container.Configure(config =>
    {
        config.AddRegistry(new MyStructuremapRegistry());
        config.Populate(services);
    });

    return container.GetInstance<IServiceProvider>();
}

Notice that there is also dependecy definition for framework-level dependency injection. Let's see which implementation wins.

TRYING OUT STRUCTUREMAP WITH ASP.NET CORE 2.0

Let's make some minor updates to Home controller and Index view to get message from injected service and display it on home page of sample application.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Threading.Tasks;
using ASPNETCoreTemplate.Services;
using Microsoft.AspNetCore.Mvc;

namespace ASPNETCoreTemplate.Controllers
{
    public class HomeController : Controller
    {
        private readonly IMessagingService _messagingService;

        public HomeController (IMessagingService messagingService)
        {
            _messagingService = messagingService;
        }

        public IActionResult Index()
        {
            ViewData["Message"] = _messagingService.GetMessage();

            return View();
        }

        public IActionResult Error()
        {
            return View();
        }
    }
}



ASP.NET Core Hosting :: Differences Between Kestrel and IIS Features

clock December 21, 2018 08:47 by author Jervis

The Kestrel web server is a new web server as part of ASP.NET Core. It is now the preferred web server for all new ASP.NET applications. In this article, we will review what it is, how to use it, and the differences between Kestrel vs IIS.

Why Do We Need the New Kestrel Web Server? What about IIS?

If you have been developing ASP.NET applications for a while, you are probably familiar with Internet Information Services (IIS). It does literally anything and everything as a web server. It is infinitely configurable with ASP.NET handlers & modules via the ASP.NET integrated pipeline. It has robust management APIs for configuration and deployment. It is even an FTP server.

The same codebase that has to support the original “.asp” pages from 15+ years ago now also handles new technologies like async ASP.NET. Like most software, as it ages it gets modified over time, they carry a lot of weight and bloat. IIS does everything, but it is not the fastest web server around. Lightweight web servers like Node.js and Netty make IIS look old and slow.

A Chance to Start Over

By creating the Kestrel web server, the .NET community was able to start over from scratch. They no longer had to worry about backward compatibility for technologies that were 15+ years old. They could take all of their past knowledge to build the simplest and fastest web server possible. That is exactly what they did. Kestrel and ASP.NET Core were built for speed.

Kestrel is more than just a new web server. ASP.NET Core & Kestrel combined are a whole new request pipeline for how ASP.NET requests work. Things like HTTP modules & handlers have been replaced with simple middleware. The entire System.Web namespace is gone. Another big advantage is designing a web server to take advantage of async from the ground up. Performance is now a feature of ASP.NET.

Built for Speed

One of the big problems with IIS and the existing ASP.NET pipeline was the performance of it. For most real world applications, the performance is perfectly fine. However, it lagged way behind in benchmarks. The combination of Kestrel & ASP.NET Core has been shown to be many times faster. It is great to see the team putting performance as a top priority.

Granted, benchmarking an ASP.NET request that says “hello world” is not comparable to most real applications that do multiple SQL queries, cache calls, and web service calls in a single request. ASP.NET makes it easy to do most I/O operations asynchronously. ASP.NET Core & Kestrel have been designed from the ground up to take advantage of async. Most real world apps should perform better if the developers follow good best practices around using async.

Cross Platform

If the goal was to get ASP.NET running on Linux, that meant porting IIS to Linux or making ASP.NET work without IIS. Kestrel solved this problem. As a developer, I can write my ASP.NET application and deploy it to Windows or Linux either one. Kestrel works as my web server on both. However, it is still recommended to use IIS, Apache, or NGINX as a reverse proxy in front of it. Next, we will discuss why that is.

Comparing Kestrel Web Server vs IIS

IIS does almost everything. Kestrel does as little as possible. Because of this, Kestrel is much faster but also lacks a lot of functionality. I would think of Kestrel as really more of an application server. It is recommended to use another web server in front of it for public web applications. Kestrel is designed to run ASP.NET as fast as possible. It relies on a full fledged web server to do deal with things like security, management, etc.

Feature Comparison for Kestrel vs IIS

Here is an IIS vs Kestrel comparison of some key features. This should help you better understand the limitations of Kestrel. You can overcome these limitations by pairing it up with IIS or NGINX.



ASP.NET Hosting :: How to Setup URL Redirection

clock November 15, 2018 07:07 by author Jervis

We have so many clients asking about this issue. So, we decide to write this tutorial and hope this information can help other people too. In this review, we will write simple tutorial about how to setup http/https redirection in IIS.

There are lots of routing options accessible in ASP.NET but still it comes a time when you need to manipulate a URL and manipulating it outside a code comes handy. When this happens, the best you can do id to use IIS Rewrite Module. Transforming various URL’s out of code enables you to do various things including performing redirections for archive or transferred content without interfering with the code, you can easily implement SEO optimizations and tweaks quickly and easily without code and many more. Below is a collection of useful IIS rewrite rules that will help you understand IIS rewrites.

Useful IIS Rewrite Rules

Adding www Prefix

This is a basic rule that adds prefix “www” to any URL you need. This is a requirement for SEO.

Redirection from Domain 1 to Domain 2

This rule comes handy when you change the name of your site or may be when you need to catch and alias and direct it to your main site. If the new and the old URLs share some elements, then you could just use this rule to have the matching pattern together with the redirect target being.

HTTPS/HTTP Redirection

Redirecting users from HTTP to HTTPS is one of the reasons that you need to apply useful IIS rewrite rules. It can lead to conditional statements while looking for dev/test mode in your code. This rules allows you to handle the redirection without much statements which is tidier.

There is a pair of rules in this case each for one of the two ways. In both the rules, a check is performed to verify that the protocol used is http/https. The rules work on the same URL patterns or the similar lists of pages to match. For the redirect to HTTP, it is not about matching the pages; it is a reverse of the first rule and usually have a number of .NET/site paths that are excluded.

Setup Redirection Using IIS

Above steps is to setup URL redirection via your code. But, if you manage your own server, you can also setup redirection via IIS. The following is the steps

1. Download and install the “URL Rewrite” module.

2. Open the “IIS Manager” console and select the website you would like to apply the redirection to in the left-side menu:



3. Double-click on the “URL Rewrite” icon.

4. Click “Add Rule(s)” in the right-side menu.

5. Select “Blank Rule” in the “Inbound” section, then press “OK”:

6. Enter any rule name you wish.

7. In the “Match URL” section:

- Select “Matches the Pattern” in the “Requested URL” drop-down menu 
- Select “Regular Expressions” in the “Using” drop-down menu 
- Enter the following pattern in the “Match URL” section: “(.*)” 
- Check the “Ignore case” box

 

 

8. In the “Conditions” section, select “Match all” under the “Logical Grouping” drop-down menu and press “Add”.

9. In the prompted window:

- Enter “{HTTPS}” as a condition input 
- Select “Matches the Pattern” from the drop-down menu 
- Enter “^OFF$” as a pattern 
- Press “OK”

10. In the “Action” section, select “Redirect” as the action type and specify the following for “Redirect URL”:

https://{HTTP_HOST}/{R:1}

11. Check the “Append query string” box.

12.Select the Redirection Type of your choice. The whole “Action” section should look like this:

 

NOTE: There are 4 redirect types of the redirect rule that can be selected in that menu: 

- Permanent (301) – preferable type in this case, which tells clients that the content of the site is permanently moved to the HTTPS version. Good for SEO, as it brings all the traffic to your HTTPS website making a positive effect on its ranking in search engines. 
- Found (302) – should be used only if you moved the content of certain pages to a new place *temporarily*. This way the SEO traffic goes in favour of the previous content’s location. This option is generally not recommended for a HTTP/HTTPS redirect. 
- See Other (303) – specific redirect type for GET requests. Not recommended for HTTP/HTTPS. 
- Temporary (307) – HTTP/1.1 successor of 302 redirect type. Not recommended for HTTP/HTTPS.

13. Click on “Apply” on the right side of the “Actions” menu.

The redirect can be checked by accessing your site via http:// specified in the URL. To make sure that your browser displays not the cached version of your site, you can use anonymous mode of the browser.

The rule is created in IIS, but the site is still not redirected to https://

Normally, the redirection rule gets written into the web.config file located in the document root directory of your website. If the redirection does not work for some reason, make sure that web.config exists and check if it contains the appropriate rule.

To do this, follow these steps:

1. In the sites list of IIS, right-click on your site. Choose the “Explore” option:

 

2. “Explore” will open the document root directory of the site. Check if the web.config file is there.

3. The web.config file must have the following code block:

<configuration> 
<system.webServer> 
<rewrite> 
<rules> 
<rule name="HTTPS force" enabled="true" stopProcessing="true"> 
<match url="(.*)" /> 
<conditions> 
<add input="{HTTPS}" pattern="^OFF$" /> 
</conditions> 
<action type="Redirect" url="https://{HTTP_HOST}/{R:1}" redirectType="Permanent" /> 
</rule> 
</rules> 
</rewrite> 
</system.webServer> 
</configuration>

4. If the web.config file is missing, you can create a new .txt file, put the aforementioned code there, save and then rename the file to web.config.

 

 



ASP.NET Core Hosting :: How to Fix Error "An error occurred while starting the application" in ASP.NET Core

clock November 9, 2018 09:43 by author Jervis

Previously, we have written tutorial about how to fix 502.5 error that you face when publishing your ASP.NET Core application. Another issue that you might face when publishing your .net Core application is:

“An error occurred while starting the application.  .NET Framework <version number> | Microsoft.AspNetCore.Hosting version <version number> | Microsoft Windows <version number>”

It looks like:

What happened?

It basically means something really bad happened with your app.  Some things that might have gone wrong:

  • You might not have the correct .NET Core version installed on the server.
  • You might be missing DLL’s
  • Something went wrong in your Program.cs or Startup.cs before any exception handling kicked in

Event Viewer (Probably) Won’t Show You Anything

If you’re running on Windows and behind IIS, you might immediately go to the Event Viewer to see what happened based on your previous ASP.NET knowledge.  You’ll notice that the error is not there.  This is because Event Logging must be wired up explicitly and you’ll need to use the Microsoft.Extensions.Logging.EventLog package, and depending on the error, you might not have a chance to even catch it to log to the Event Viewer.

How to figure out what happened (if running on IIS)

Instead of the Event Viewer, if you’re running behind IIS, we can log the request out to a file.  To do that:

  1. Open your web.config
  2. Change stdoutLogEnabled=true
  3. Create a logs folder
    - Unfortunately, the AspNetCoreModule doesn’t create the folder for you by default. If you forget to create the logs folder, an error will be logged to the Event Viewer that says: Warning: Could not create stdoutLogFile \\?\YourPath\logs\stdout_timestamp.log, ErrorCode = -2147024893.
    -
    The “stdout” part of  the value “.\logs\stdout” actually references the filename not the folder.  Which is a bit confusing.
  4. Run your request again, then open the \logs\stdout_*.log file

Note – you will want to turn this off after you’re done troubleshooting, as it is a performance hit.

So your web.config’s aspNetCore element should look something like this

 <aspNetCore processPath=”.\YourProjectName.exe” stdoutLogEnabled=”true” stdoutLogFile=”.\logs\stdout” />

Doing this will log all the requests out to this file and when the exception occurs, it will give you the full stack trace of what happened in the \logs\stdout_*.log file

 

Hope this helps. In case, you need ASP.NET Core hosting, you can always try our services start from $1.00/month.



ASP.NET Core 2 Hosting :: How to Fix Error 502.5 When Deploy Your ASP.NET Core

clock November 7, 2018 08:25 by author Jervis

I decide to make this tutorial as most of our users also experience same problem when deploying their ASP.NET Core application.

I recently hit this problem after manually modifying the web.config file. Fortunately, the problem is easy to fix.

In this post, we see two different causes of this error, two different solutions for the first cause, a solution for the second cause, and learn what needs to be in web.config for ASP.NET Core to operate.

The Error

Here is a screenshot of the HTTP Error 502.5 - Process Failure error. You'll see this, in your browser, when making a request to your ASP.NET Core application, after deployment, if you have this issue.

Why do I get the error?

 

The HTTP Error 502.5 - Bad Gateway and HTTP Error 502.5 - Process Failure error messages occur in ASP.NET Core when IIS fails to execute the dotnet process.

I've seen this error happen for two different reasons:

  • .NET Core Runtime is not installed
  • web.config file has not been transformed

How to Fix This Error?

This is very simple and easy to fix this issue. What you need to make sure is that your hosting provider support or already installed the latest ASP.NET Core on their hosting environment.

1. Install Latest .NET Core Runtime

You can download the latest .NET Core runtime from Microsoft's .NET download page.

For Windows, you'll usually want the latest .NET Core runtime (currently v2.1.1), as highlighted in the following screenshot:

This will get you the Windows Hosting Bundle Installer, which will install both the x86 and x64 runtimes on Windows Server.

2. Publish a Self-Contained Deployment

If you don't want to install the .NET Core Runtime. An alternative for .NET Core web applications is to publish them in the Self-Containeddeployment mode, which includes the required .NET Runtime files alongside your application.

You can select this option from the advanced publish settings screen in Visual Studio: 

If you go with this option, you'll also need to choose a target runtime: win-x86, win-x64, osx-x64, or linux-x64. Because self-contained deployments are not portable.

3. Transform your web.config file

Another reason for this error to occur is when you deploy an untransformed web.config file. This is likely to be your issue if you had a previously working web application and merely deployed a new version of it.

ASP.NET Core Web Config

In ASP.NET Core applications, the web.config file contains a handler that directs requests to the AspNetCoreModule and an aspNetCoreelement that defines and configures the ASP.NET Core process to execute your web application.

Here is a minimal web.config file for an ASP.NET Core application:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
 
<system.webServer>
   
<handlers>
     
<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />
   
</handlers>
   
<aspNetCore processPath="%LAUNCHER_PATH%" arguments="%LAUNCHER_ARGS%" stdoutLogEnabled="true"
       
stdoutLogFile=".\logs\stdout" forwardWindowsAuthToken="false"/>
 
</system.webServer>
</configuration>

Note that it's possible that you don't have a web.config file in your ASP.NET Core project. If you do not, one will be generated for you when publishing the project, as IIS and IIS Express require a web.config file when hosting an ASP.NET Core web app.

The Issue

The untransformed web.config contains the variables %LAUNCHER_PATH% and %LAUNCHER_ARGS% rather than the correct paths. When IIS tries to run ASP.NET Core, it uses %LAUNCHER_PATH% and %LAUNCHER_ARGS% rather than the correct path and arguments.

To fix the HTTP Error 502.5 in ASP.NET Core, you need to transform the web.config and replace the untransformed web.config file on the IIS web server.

How do I transform web.config?

This transformation takes place when you choose to publish your web application. The transformed web.config ends up in the published output folder. Therefore, you simply need to publish your web application and copy the resulting web.config file onto the server.

In a transformed web.config file, the aspNetCore element will look something like this:

<aspNetCore processPath="dotnet" arguments=".\MyApplication.dll" stdoutLogEnabled="true"
    stdoutLogFile=".\logs\stdout" forwardWindowsAuthToken="false" />

%LAUNCHER_PATH% has been replaced by dotnet and %LAUNCHER_ARGS% has been replaced by the path to the main web application dll .\MyApplication.dll.



Cheap ASP.NET 4.5 Hosting

We’re a company that works differently to most. Value is what we output and help our customers achieve, not how much money we put in the bank. It’s not because we are altruistic. It’s based on an even simpler principle. "Do good things, and good things will come to you".

Success for us is something that is continually experienced, not something that is reached. For us it is all about the experience – more than the journey. Life is a continual experience. We see the Internet as being an incredible amplifier to the experience of life for all of us. It can help humanity come together to explode in knowledge exploration and discussion. It is continual enlightenment of new ideas, experiences, and passions


Author Link

 photo ahp banner aspnet-01_zps87l92lcl.png

 

Corporate Address (Location)

ASPHostPortal
170 W 56th Street, Suite 121
New York, NY 10019
United States

Tag cloud

Sign in