{"id":6575,"date":"2016-09-19T15:12:47","date_gmt":"2016-09-19T22:12:47","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/dotnet\/?p=6575"},"modified":"2021-09-30T11:51:05","modified_gmt":"2021-09-30T18:51:05","slug":"custom-asp-net-core-middleware-example","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/dotnet\/custom-asp-net-core-middleware-example\/","title":{"rendered":"Custom ASP.NET Core Middleware Example"},"content":{"rendered":"

One of the great things about ASP.NET Core is its extensibility. The behavior of an ASP.NET Core app’s HTTP request handling pipeline can be easily customized by specifying different middleware<\/a> components. This allows developers to plug in request handlers like MVC middleware, static file providers, authentication, error pages, or even their own custom middleware. In this article, I will walk you through how to create custom middleware to handle requests with simple SOAP payloads.<\/p>\n

A Disclaimer<\/h3>\n

Hopefully this article provides a useful demonstration of creating custom middleware for ASP.NET Core in a real-world scenario. Some users might also find the SOAP handling itself useful for processing requests from old clients that previously communicated with a basic WCF endpoint. Be aware, though, that this sample does not provide general WCF host support for ASP.NET Core<\/strong>. Among other things, it has no support for message security, WSDL generation, duplex channels, non-HTTP transports, etc. The recommended way of providing web services with ASP.NET Core is via RESTful web API solutions. The ASP.NET MVC<\/a> framework provides a powerful and flexible model for routing and handling web requests with controllers and actions.<\/p>\n

Getting Started<\/h2>\n

To start, create a .NET Core library (the project type is under web templates and is called Class Library (package)<\/code>). Throughout this article I will be using the Preview 2 version of the .NET Core tools<\/a>.<\/p>\n

\"\"<\/p>\n

ASP.NET Core middleware uses the explicit dependencies principle<\/a>, so all dependencies should be provided through dependency injection via arguments to the middleware’s constructor. The one dependency common to most middleware is a RequestDelegate<\/code> object representing the next delegate in the HTTP request processing pipeline. If our middleware does not completely handle a request, the request’s context should be passed along to this next delegate. Later, we’ll specify more dependencies in our constructor but, for now, let’s add a basic constructor to our middleware class.<\/p>\n

Add a dependency to Microsoft.AspNetCore.Http.Abstractions<\/code> to your project.json (since that’s the contract containing RequestDelegate<\/code>), give your class a descriptive name (I’m using SOAPEndpointMiddleware<\/code>), and create a constructor for the middleware class like this:<\/p>\n