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.