Use nginx running in Docker container to serve .NET sites running on Kestrel both in host and Docker containers

In one of my previous articles I made brief introduction to Docker – containerization technology which gives more control over infrastructure. Suppose that we have number of .NET sites running on Kestrel in Linux and published via nginx to the internet like shown on the following schema (ports numbers are only for example here):

And we want to move all our infrastructure to Docker (backend, database, nginx itself, etc) so it will look like this:

On practice however this switch will take time and at some time period we will have both sites running still in the Linux host and sites running in Docker containers, and we will need to serve both types:

Since only one app may listen to 80 port we need to decide whether we want to keep nginx service running on the host or move nginx to Docker and configure it to serve both sites from the host and sites from Docker containers. In this article I will describe this last option.

Since nginx is running in Docker there won’t be many problems with hosting sites running also in Docker. Just run these sites and nginx container in the same network:

#docker-compose-nginx.yml
name: myservice
services:
  nginx:
    image: nginx:latest
    ports:
      - 80:80
    …
    networks:
      - mynetwork

and nginx will be able to resolve containers by names. I.e. if site’s container name is mysite-web-1 you may specify nginx.conf like this:

server {
	listen 80;
	listen [::]:80;
	server_name mysite.ru www. mysite.ru;
	location / {
		proxy_pass http://mysite-web-1:80;
		…
	}
}

However with sites running in host it is not that straightforward. Since nginx is running in Docker container which has own IP address we need to instruct it to which IP it should forward requests if they came for sites running on the host.

We can do that by adding special extra host host.docker.internal to nginx docker compose:

name: myservice
services:
  nginx:
    image: nginx:latest
    ports:
      - 80:80
    restart: always
    networks:
      - mynetwork
    extra_hosts:
      - host.docker.internal:host-gateway

If we will check /etc/hosts file inside nginx container we will see that host.docker.internal points to 172.17.0.1 IP address which is default IP used by Docker for host:

docker exec -it myservice-nginx-1 sh
more /etc/hosts
…
host.docker.internal 172.17.0.1

Next step is to instruct nginx to forward request to the host if it came for site running there. For doing that we need to modify nginx.conf and specify host.docker.internal with appropriate port in proxy_pass property:

server {
	listen 80;
	listen [::]:80;
	server_name mysite.ru www.mysite.ru;
    	location / {
		proxy_pass http://host.docker.internal:5000;
		…
    	}
}

However that is still not enough. If your .NET site is running on Kestrel you most probably configured to run it as a daemon via the following commands:

systemctl enable mysite.ru.service
systemctl start mysite.ru.service

where mysite.ru.service file contains the following line:

Environment=ASPNETCORE_URLS=http://localhost:5000

With our current configuration if we will open shell inside our nginx container and try to reach our site via curl we will get Connection refused:

docker exec -it myservice-nginx-1 sh
curl -X GET http://host.docker.internal:5000
Connection refused

The problem here is that Kestrel is currently listening only for localhost IP (127.0.0.1). We can check it on the host using the following command:

netstat -tulpn | grep 5000
tcp        0      0 127.0.0.1:5000          0.0.0.0:*               LISTEN      22496/dotnet
tcp6       0      0 ::1:5000                :::*                    LISTEN      22496/dotnet

but request from nginx container goes to 172.17.0.1. To solve that we need to modify /etc/systemd/system/mysite.ru.service and add http://172.17.0.1:5000 to ASPNETCORE_URLS after semicolon:

Environment=ASPNETCORE_URLS=http://localhost:5000;http://172.17.0.1:5000

and reload the service:

systemctl stop mysite.ru.service
systemctl daemon-reload
systemctl start mysite.ru.service
systemctl status mysite.ru.service

After that check that it listen 5000 port also on 172.17.0.1:

netstat -tulpn | grep 5000
tcp        0      0 172.17.0.1:5000         0.0.0.0:*               LISTEN      22496/dotnet
tcp        0      0 127.0.0.1:5000          0.0.0.0:*               LISTEN      22496/dotnet
tcp6       0      0 ::1:5000  

And now if we go inside container shell and try to reach the site connection should be successful:

docker exec -it myservice-nginx-1 sh
curl -X GET http://host.docker.internal:5000
Connection successful

which means that nginx is now able to serve sites running both in containers and on the host itself.

Use PowerShell in Visual Studio build events when build Docker image for .Net app

Imagine that we have .NET application and created Docker file for it which often contains build and runtime stages (in this example I use .Net6 but it is also valid for higher versions):

# build stage
FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build
COPY ...
RUN dotnet restore ...
RUN dotnet publish ...

# runtime stage
FROM mcr.microsoft.com/dotnet/aspnet:6.0 AS final
...

and that our VS solution contains build steps which use PowerShell (assume that it is cross platform PowerShell v.7.x). These steps will run during "dotnet publish" step on build stage. You may face with the following error:

powershell command not found

Quick way to fix it is to use "pwsh" command instead of "powershell". It will work because PowerShell became part of .Net SDK docker images since 3.0 preview like described in the following article: Installing PowerShell with one line as a .NET Core global tool. Note also that .Net SDK images are Linux based where "pwsh" command is usual for running PowerShell.

If because of some reason you don't want to change "powershell" to "pwsh" in the code (e.g. if you need to build apps both on Windows and Linux) you may use the following approach: in Docker file add the following command:

RUN ln -s pwsh /usr/bin/powershell

It will add symlink "powershell" which in turn will run pwsh. After that your powershell commands in build events will work both on Windows and Linux including Docker images.

Bind complex view model objects in ASP.Net Core using ComplexObjectModelBinder

The way how view model objects are bound has been changed in ASP.Net Core. Now we need to create custom model binder class which inherits IModelBinder interface and implement binding logic there (in ASP.Net Core there is no DefaultModelBinder base class anymore which we may inherit in custom binders). However for most cases binding logic itself will be the same still - only custom logic will differ (like validation specific to view model class). Instead of implementing this binding logic for each view model class by ourselves we may use builtin ComplexObjectModelBinder which will do actual work for us. In this post I will show how to do that.

Let's say we have RequestModel view model class which can be used for asking contact information (name, email, phone):

public class RequestModel
{
    public string Name { get; set; }
    public string Email { get; set; }
    public string Phone { get; set; }
}

For binding this model we need to implement some infrastructural classes. First of all we need custom model binder provider which inherits IModelBinderProvider. But instead of creating own binder provider for each view model class let's create generic ComplexModelBinderProvider class which can be used with any view model:

public class ComplexModelBinderProvider<TModel, TBinder> : IModelBinderProvider
{
    private ComplexObjectModelBinderProvider complexObjectBinderProvider;

    public ComplexModelBinderProvider(ComplexObjectModelBinderProvider complexObjectBinderProvider)
    {
        this.complexObjectBinderProvider = complexObjectBinderProvider;
    }

    public IModelBinder GetBinder(ModelBinderProviderContext context)
    {
        if (context.Metadata.ModelType == typeof(TModel))
        {
            return (IModelBinder)Activator.CreateInstance(typeof(TBinder),
                new object[] { complexObjectBinderProvider.GetBinder(context) });
        }
        return null;
    }
}

It use 2 generic types: one for view model class (TModel) and another for its model binder which will be used for binding objects of TModel. Note that when it creates model binder it passes instance of ComplexObjectModelBinder to constructor (complexObjectBinderProvider.GetBinder(context)).

We also need custom model binder class RequestModelBinder for our view model - but instead of implementing binding logic there we will just call ComplexObjectModelBinder which was injected in constructor and which will do all complex work (get values from form values, query string params, etc):

public class RequestModelBinder : IModelBinder
{
    protected IModelBinder complexObjectBinder;
	
    public RequestModelBinder(IModelBinder complexObjectBinder)
    {
	    this.complexObjectBinder = complexObjectBinder;
    }

    public async Task BindModelAsync(ModelBindingContext bindingContext)
    {
        var model = new RequestModel();
        bindingContext.Model = model;
        await this.complexObjectBinder.BindModelAsync(bindingContext);
		
		// add custom logic there if needed
    }
}

Now we just need to link all of that together in Program.cs:

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddControllersWithViews(
    o =>
    {
        var complexObjectBinderProvider = o.ModelBinderProviders.First(p => p is ComplexObjectModelBinderProvider) as ComplexObjectModelBinderProvider;
        o.ModelBinderProviders.Insert(0, new ComplexModelBinderProvider<RequestModel, RequestModelBinder>(complexObjectBinderProvider));
        // add more ComplexModelBinderProvider instances for other view models
        ...
    });

Here we added our generic ComplexModelBinderProvider for RequestModel view model which during binding will create instance of RequestModelBinder which in turn will bind model by delegating work to ComplexObjectModelBinder. The more view models we have in the code the more advantages this approach will bring since we will just reuse the same binding logic for all models.

Run ASP.Net Core Web API on Kestrel dev web server with https on Windows

In this post I will describe how to run ASP.Net Core Web API on Kestrel development web server under https. First of all we need to create self-signed SSL certificate. We may generate it with PowerShell (see Use self-signed SSL certificate for web API hosted in Azure App service) or openssl tool:

openssl req -x509 -nodes -days 3650 -newkey rsa:2048 -keyout test.key -out test.crt -config test.conf -passin pass:123
openssl pkcs12 -export -out test.pfx -inkey test.key -in test.crt -passout pass:123

For running above commands we will need config file test.conf with information about domain name. It may look like that:

[req]
default_bits = 2048
default_keyfile = test.key
distinguished_name = req_distinguished_name
req_extensions = req_ext
x509_extensions = v3_ca

[req_distinguished_name]
countryName =
countryName_default =
stateOrProvinceName =
stateOrProvinceName_default =
localityName =
localityName_default =
organizationName = Test
organizationName_default = Test
organizationalUnitName = organizationalunit
organizationalUnitName_default = Development
commonName = api.example.com
commonName_default = api.example.com
commonName_max = 64

[req_ext]
subjectAltName = @alt_names

[v3_ca]
subjectAltName = @alt_names

[alt_names]
DNS.1 = api.example.com

Once private key (pfx) is created we may install it to the local certificates store: double click pfx, and follow certificate installation wizard with default settings:

We will also need to provide password for private key in this wizard (in above example "123").

Once certificate is installed to the certificates store we need to set the following parameters in appsettings.json file of our ASP.Net Core Web API project:

{
  "Kestrel": {
    "Endpoints": {
      "Http": {
        "Url": "http://api.example.com:5057"
      },
      "HttpsInlineCertStore": {
        "Url": "https://api.example.com:5058",
        "Certificate": {
          "Subject": "api.example.com",
          "Store": "My",
          "Location": "CurrentUser",
          "AllowInvalid": true
        }
      }
    }
  }
}

(since in our example self-signed certificate is used we need to set AllowInvalid: true parameter). If everything is done correctly Web API will run on local Kestrel dev server under https.

Generate action urls from C# lambda expressions in ASP.Net MVC Core: good news for those who missed it there

In ASP.Net MVC (on top on .Net Framework) there was useful mechanism for generating actions urls from C# lambda expressions. Let's say we have controller UserController for managing users which has List action with 3 params:

• page number (in case if users list is large and we need to use pagination)
  
• sort by (first name, last name, etc)
  
• sort direction (asc or desc)
  

public enum SortDirection
{
    Asc,
    Desc
}

public class UserController : Controller
{
    public ActionResult List(int pageNumber, string sortBy, SortDirection sortDirection)
    {
        ...
    }
}

In this case we could generate url for this action using generic ActionLink<T> method like this:

Html.ActionLink<UserController>(c => c.List(0, "FirstName", SortDirection.Asc), "All users")

which will generate the following url:

/user/list?pageNumber=0&sortBy=FirstName&sortDirection=SortDirection.Asc

That is convenient method since we have compile-time check for the code. Compare it with classic way:

Html.ActionLink("All users", "List", "Users", new { pageNumber = 0, sortBy = "FirstName", sortDirection = SortDirection.Asc })

In the last case if e.g. action name, parameters names or number of params will be changed we won't get any errors or warning during compilation. Instead we may get unexpected behavior or runtime error (e.g. if new parameter was added it will have default value if we won't explicitly add it to link generation code).

The problem is that strongly-typed method is not available in ASP.Net Core. Don't know what was the reason for not adding it there (except mentioned advantage of having compile-time check it may also be a problem during migration of old ASP.Net MVC app to ASP.Net Core) but fortunately it is possible to get it back there.

Lets check steps which are needed for generating action url from expression: we need to get controller name (/user), action name (/list), list action parameters names (or get route values from expression how it is called in ASP.Net MVC) and (most tricky one) get value of each parameter passed to expression. And then concatenate all parts to one string. First 3 steps are relatively easy: they can be done by basic reflection. But last step (get values of parameters passed to lambda expression) needs extra attention. In the past I already faced with that need in Camlex.NET (open source library for Sharepoint developers which I maintain in free time): Runtime evaluation of lambda expressions. We can use the same technique here as well. Also (as I found out during experiments) code for generating routing values from expression (list parameters names) can be reused with small changes from internal method of ASP.Net MVC Microsoft.Web.Mvc.Internal.ExpressionHelper.GetRouteValuesFromExpression in ASP.NET Core - it will help to save our time.

Now if we will combine all of this we may create helper class for generating urls from expressions in ASP.Net Core:

public static class HtmlHelperExtensions
{
    public static string ActionLink<TController>(this IHtmlHelper html, Expression<Action<TController>> actionExpression)
    {
        return ActionLink(actionExpression, GetRouteValuesFromExpression(actionExpression));
    }

    public static string ActionLink<TController>(this IHtmlHelper html, Expression<Action<TController>> actionExpression, RouteValueDictionary routeValues)
    {
        return ActionLink(actionExpression, routeValues);
    }

    public static string ActionLink<TController>(Expression<Action<TController>> actionExpression, RouteValueDictionary routeValues)
    {
        string controllerName = typeof(TController).GetControllerName();
        string actionName = actionExpression.GetActionName();
        var sb = new StringBuilder($"/{controllerName}/{actionName}");
        if (routeValues != null)
        {
            bool isFirst = true;
            foreach (var routeValue in routeValues)
            {
                sb.Append(isFirst ? "?" : "&");
                sb.Append($"{routeValue.Key}={routeValue.Value}");
                isFirst = false;
            }
        }
        return sb.ToString();
    }

    private static string GetControllerName(this Type controllerType)
    {
        return controllerType.Name.Replace("Controller", string.Empty);
    }

    private static string GetActionName(this LambdaExpression actionExpression)
    {
        return ((MethodCallExpression)actionExpression.Body).Method.Name;
    }

    // copy of Microsoft.Web.Mvc.Internal.ExpressionHelper.GetRouteValuesFromExpression
    private static RouteValueDictionary GetRouteValuesFromExpression<TController>(
        Expression<Action<TController>> action)
    {
        if (action == null)
            throw new ArgumentNullException(nameof(action));
        if (!(action.Body is MethodCallExpression body))
            throw new ArgumentException("MustBeMethodCall");
        string name = typeof(TController).Name;
        string str = name.EndsWith("Controller", StringComparison.OrdinalIgnoreCase)
            ? name.Substring(0, name.Length - "Controller".Length)
            : throw new ArgumentException("TargetMustEndInController");
        if (str.Length == 0)
            throw new ArgumentException("CannotRouteToController");
        string targetActionName = GetTargetActionName(body.Method);
        var rvd = new RouteValueDictionary();
        AddParameterValuesFromExpressionToDictionary(rvd, body);
        return rvd;
    }

    private static void AddParameterValuesFromExpressionToDictionary(
        RouteValueDictionary rvd,
        MethodCallExpression call)
    {
        ParameterInfo[] parameters = call.Method.GetParameters();
        if (parameters.Length <= 0)
            return;
        for (int index = 0; index < parameters.Length; ++index)
        {
            Expression expression = call.Arguments[index];
            object obj = !(expression is ConstantExpression constantExpression)
                ? Expression.Lambda<Func<object, object>>((Expression)Expression.Convert(expression, typeof(object)), Expression.Parameter(typeof(object), "_unused")).Compile().Invoke((object)null)
                : constantExpression.Value;
            rvd.Add(parameters[index].Name, obj);
        }
    }

    private static string GetTargetActionName(MethodInfo methodInfo)
    {
        string name = methodInfo.Name;
        ActionNameAttribute actionNameAttribute = !methodInfo.IsDefined(typeof(NonActionAttribute), true)
            ? methodInfo.GetCustomAttributes(typeof(ActionNameAttribute), true).OfType<ActionNameAttribute>().FirstOrDefault<ActionNameAttribute>()
            : throw new InvalidOperationException("CannotCallNonAction");
        if (actionNameAttribute != null)
            return actionNameAttribute.Name;
        return name;
    }
}

Using this helper class we may again generate actions links from C# expressions in ASP.Net Core.

Custom logger for .Net Core for writing logs to Azure BLOB storage

If you create .Net Core app you may use standard console logger (from Microsoft.Extensions.Logging.Console nuget package). For development it works quite well but if app goes to production you probably want to store logs in some persistent storage in order to be able to check them when needed. In this post I will show how to create custom logger which will write logs to Azure BLOB storage.

At first need to mention that there is BlobLoggerProvider from MS (from Microsoft.Extensions.Logging.AzureAppServices nuget package) which creates BatchingLogger which in turn stores logs to BLOB storage as well. However it has dependency on Azure App Services infrastructure so on practice you may use it only if your code is running inside Azure App Service. If this limitation is important we may go with custom logger implementation.

First of all we need to implement logger itself which inherits Microsoft.Extensions.Logging.ILogger interface and writes logs to the BLOB:

public class BlobLogger : ILogger
{
	private const string CONTAINER_NAME = "custom-logs";
	private string connStr;
	private string categoryName;

	public BlobLogger(string categoryName, string connStr)
	{
		this.connStr = connStr;
		this.categoryName = categoryName;
	}

	public void Log<TState>(LogLevel logLevel, EventId eventId, TState state, Exception? exception,
		Func<TState, Exception?, string> formatter)
	{
		if (!IsEnabled(logLevel))
		{
			return;
		}

		using (var ms = new MemoryStream(Encoding.UTF8.GetBytes($"[{this.categoryName}: {logLevel,-12}] {formatter(state, exception)}{Environment.NewLine}")))
		{
			var container = this.ensureContainer();
			var now = DateTime.UtcNow;
			var blob = container.GetAppendBlobClient($"{now:yyyyMMdd}/log.txt");
			blob.CreateIfNotExists();
			blob.AppendBlock(ms);
		}
	}

	private BlobContainerClient ensureContainer()
	{
		var container = new BlobContainerClient(this.connStr, CONTAINER_NAME);
		container.CreateIfNotExists();
		return container;
	}

	public bool IsEnabled(LogLevel logLevel) => true;

	public IDisposable BeginScope<TState>(TState state) => default!;
}

BlobLogger creates new container "custom-logs" (if it doesn't exist yet) in specified BLOB storage. Inside this container it also creates folders using current date as folder name yyyyMMdd (own folder for each day) and writes messages to the log.txt file inside this folder. Note that for working with Azure BLOB storage we used BlobContainerClient class from Azure.Storage.Blobs nuget package since. It will allow us to use instance of our logger as singleton (see below) because instance methods of this client class are guaranteed to be thread safe:

Thread safety
We guarantee that all client instance methods are thread-safe and independent of each other (guideline). This ensures that the recommendation of reusing client instances is always safe, even across threads.

In order to create BlobLogger we need to pass connection string to Azure storage and logging category name. It will be done in logger provider which will be responsible for creating BlobLogger:

public class BlobLoggerProvider : ILoggerProvider
{
	private string connStr;

	public BlobLoggerProvider(string connStr)
	{
		this.connStr = connStr;
	}

	public ILogger CreateLogger(string categoryName)
	{
		return new BlobLogger(categoryName, this.connStr);
	}

	public void Dispose()
	{
	}
}

Now everything is ready for using our logger in .Net Core app. If we want to use our BLOB logger together with console logger (which is quite convenient since logging is done both into console and into BLOB storage) we may use LoggingFactory and pass both standard ConsoleLoggerProvider and our BlobLoggerProvider:

var configuration = builder.GetContext().Configuration;
var azureStorageConnectionString = configuration.GetValue<string>("AzureWebJobsStorage");
var logger = new LoggerFactory(new ILoggerProvider[]
{
	new ConsoleLoggerProvider(new OptionsMonitor<ConsoleLoggerOptions>(new ConsoleLoggerOptions())),
	new BlobLoggerProvider(azureStorageConnectionString)
}).CreateLogger("CustomLogger");
builder.Services.AddSingleton(logger);

For creating instance of ConsoleLoggerProvider I used OptionsMonitor<T> helper class from How to create a ConsoleLoggerProvider without the full hosting framework (don't know why MS didn't provide this option OTB and made it so complex there):

public class OptionsMonitor<T> : IOptionsMonitor<T>
{
	private readonly T options;

	public OptionsMonitor(T options)
	{
		this.options = options;
	}

	public T CurrentValue => options;

	public T Get(string name) => options;

	public IDisposable OnChange(Action<T, string> listener) => new NullDisposable();

	private class NullDisposable : IDisposable
	{
		public void Dispose() { }
	}
}

After that you will have logs both in console and in Azure BLOB storage.

Update 2023-06-22: wrote another post how to add support of logging scopes which work in task-based asynchronous pattern (TAP) and multithread code: Custom logger for .Net Core for writing logs to Azure BLOB storage.

Add basic authentication to ASP.Net Core Web API

Basic authentication is probably simplest authentication type for Web API when HTTP requests are authenticated using username and passwords provided in HTTP request headers. In this post I will describe how to add basic authentication to ASP.Net Core Web API.

At first we need to add reference to idunno.Authentication.Basic nuget package. It contains infrastructure for basic authentication ready to be used in ASP.Net Core/.NET Core projects. Also we will need simple validation service which will check provided username/password and based on that will authenticate/reject requests:

public interface IBasicAuthValidationService
{
    bool AreCredentialsValid(string username, string password);
}

public class BasicAuthValidationService : IBasicAuthValidationService
{
    private string username;
    private string password;

    public BasicAuthValidationService(string username, string password)
    {
        this.username = username;
        this.password = password;
    }

    public bool AreCredentialsValid(string username, string password)
    {
        return string.Compare(this.username, username, true) == 0 && this.password == password;
    }
}

In our example BasicAuthValidationService simply compares credentials coming from HTTP request with predefined allowed username/password.

Then in Web API's Program.cs we need to configure basic authentication itself. Since username and password are sent in HTTP request headers it is important to force using HTTPS for securing communication with our API. We will do that by adding RequireHttpsAttribute filter and UseHttpsRedirection middleware:

builder.Services.AddScoped<IBasicAuthValidationService>(c =>
{
    // get allowed username and password to authenticate requests
    string username = ...;
    string password = ...;
    return new BasicAuthValidationService(uername, password);
});

// add basic auth
builder.Services.AddAuthentication(BasicAuthenticationDefaults.AuthenticationScheme)
    .AddBasic(options =>
    {
        options.Realm = "Test.Api";
        options.Events = new BasicAuthenticationEvents
        {
            OnValidateCredentials = context =>
            {
                var validationService = context.HttpContext.RequestServices.GetService<IBasicAuthValidationService>();
                if (validationService.AreCredentialsValid(context.Username, context.Password))
                {
                    var claims = new[]
                    {
                        new Claim(ClaimTypes.NameIdentifier, context.Username, ClaimValueTypes.String, context.Options.ClaimsIssuer),
                        new Claim(ClaimTypes.Name, context.Username, ClaimValueTypes.String, context.Options.ClaimsIssuer)
                    };

                    context.Principal = new ClaimsPrincipal(new ClaimsIdentity(claims, context.Scheme.Name));
                    context.Success();
                }

                return Task.CompletedTask;
            }
        };
    });

builder.Services.Configure<MvcOptions>(options =>
{
    options.Filters.Add(new RequireHttpsAttribute());
});

var app = builder.Build();
...
app.UseHttpsRedirection();

Our Web API is now ready to be used with basic authentication. If you use Swagger for generating client for Web API (see Generate strongly-typed C# client for ASP.Net Core Web API with OpenAPI (swagger) support running on localhost) then you may configure your Web API client for basic authentication like this:

services.AddHttpClient<HttpClient>();
services.AddSingleton<IApiClient>(c =>
{
    string baseUrl = ...;
    string username = ...;
    string password = ...;
    var httpClientFactory = c.GetRequiredService<IHttpClientFactory>();
    var httpClient = httpClientFactory.CreateClient();
    httpClient.DefaultRequestHeaders.Authorization = new BasicAuthenticationHeaderValue(username, password);
    return new ApiClient(baseUrl, httpClient);
});

Now both server and client sides support basic authentication.

Add OpenAPI (Swagger) support to ASP.Net Core Web API

OpenAPI (swagger) support gives many advantages to your web api. One of them is possibility to generate strongly typed clients for calling web api so instead of developing calls from scratch (with HttpClient, building requests, deserialize response, etc) we get ready for use client with POCO classes for requests and response data. In one of my previous articles I wrote how to generate such client for public web api with OpenAPI support: Generate C# client for API with Swagger (OpenAPI) support. In this article I will show how to add OpenAPI support to your own web api project.

We will use ASP.Net Core Web API project for code samples and the following simple controller:

[ApiController]
[Route("[controller]")]
public class UserController : ControllerBase
{
    public UserController()
    {
    }

    [HttpGet]
    [Route("List")]
    public IEnumerable<User> List()
    {
        throw new NotImplementedException();
    }

    [HttpGet]
    [Route("Details")]
    public User Details(int id)
    {
        throw new NotImplementedException();
    }

    [HttpPost]
    [Route("Save")]
    public void Save(User user)
    {
        throw new NotImplementedException();
    }

    [HttpDelete]
    [Route("Delete")]
    public void Delete(int id)
    {
        throw new NotImplementedException();
    }
}

public class User
{
    public int Id { get; set; }
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public string Email { get; set; }
}

First of all we need to add extra nuget package
Swashbuckle.AspNetCore
https://www.nuget.org/packages/Swashbuckle.AspNetCore

It is also possible to add OpenAPI support to web api project from beginning by checking "OpenAPI support" checkbox in create project dialog:

 

Now we need to add few extra lines to Program.cs for configuring Swagger endpoint (lines 7-10 and 15-19):

using Microsoft.OpenApi.Models;

var builder = WebApplication.CreateBuilder(args);

// Add services to the container.
builder.Services.AddControllers();
builder.Services.AddSwaggerGen(c =>
{
    c.SwaggerDoc("v1", new OpenApiInfo { Title = "TestApi", Version = "v1" });
});

var app = builder.Build();

// Configure the HTTP request pipeline.
app.UseSwagger();
app.UseSwaggerUI(c =>
{
    c.SwaggerEndpoint("/swagger/v1/swagger.json", "TestApi v1");
});

app.UseAuthorization();

app.MapControllers();

app.Run();

Next we need to decorate actions of our controller with additional attributes which will describe which HTTP status codes may be returned from each endpoint, which data can be returned, etc.:

[ApiController]
[Route("[controller]")]
public class UserController : ControllerBase
{
    public UserController()
    {
    }

    [HttpGet]
    [Route("List")]
    [ProducesResponseType(StatusCodes.Status200OK, Type = typeof(List<User>))]
    [ProducesResponseType(StatusCodes.Status500InternalServerError)]
    [ProducesDefaultResponseType]
    public IEnumerable<User> List()
    {
        throw new NotImplementedException();
    }

    [HttpGet]
    [Route("Details")]
    [ProducesResponseType(StatusCodes.Status200OK, Type = typeof(User))]
    [ProducesResponseType(StatusCodes.Status404NotFound)]
    [ProducesResponseType(StatusCodes.Status500InternalServerError)]
    [ProducesDefaultResponseType]
    public User Details(int id)
    {
        throw new NotImplementedException();
    }

    [HttpPost]
    [Route("Save")]
    [ProducesResponseType(StatusCodes.Status200OK)]
    [ProducesResponseType(StatusCodes.Status500InternalServerError)]
    [ProducesDefaultResponseType]
    public void Save(User user)
    {
        throw new NotImplementedException();
    }

    [HttpDelete]
    [Route("Delete")]
    [ProducesResponseType(StatusCodes.Status200OK)]
    [ProducesResponseType(StatusCodes.Status404NotFound)]
    [ProducesResponseType(StatusCodes.Status500InternalServerError)]
    [ProducesDefaultResponseType]
    public void Delete(int id)
    {
        throw new NotImplementedException();
    }
}

With these declarations Swagger sees that e.g. /details endpoint will return User object if everything went well (when HTTP status code is 200 Ok). Also it may return 404 Not found if user with specified id not found and 500 Internal server error if something went wrong in backend.

Now if we will run our web api and go to http://localhost:{port}/swagger/index.html we will see fancy automatically generated documentation for our api:

We may also expand endpoints and get more information about each of them:

Using these steps we've added OpenAPI support in our ASP.Net Core Web API project. In the next post I will show how to generate api client for this web api running on localhost (update 2023-03-29: see Generate strongly-typed C# client for ASP.Net Core Web API with OpenAPI (swagger) support running on localhost).