Today I stumbled about a Tweet that suggest to not use IOptions because it is a bad idea. IOption<T> is a bad idea and should not be used: https://t.co/FKlIa9iFlN — .NET Junkie (@dot_NET_Junkie) January 24, 2018 The tweet refers to a documentation page of SimpleInjector arguing why it is a bad idea to use IOptions. In this post I want to investigate the arguments and describe my opinions on those.
This is a short reminder post, mostly for my self, since I stumbled across this issue several times. If you are missing all user claims in the id_token, check if the property AlwaysIncludeUserClaimsInIdToken is set to true on the client.
Since the Azure Function runtime is now ported to .NET Core (currently in Beta) you are now able to develop and RUN Azure Function cross platform. The current core tools also come with docker support, which means you are able to run Azure Function inside a Docker container. To get the latest core tools, follow the steps in the announcement. Creating the docker container It is very easy to create your function with docker support.
In my daily job I need to create console applications quite often. The default Visual Studio 2017 console application template for .NET Core is very minimal and just contains the usual “Hello World”. But most of the time I need dependency injection, logging, want to have an async main, etc. I also like the structure of ASP.NET Core applications with its Startup class where you can configure your services. Therefor I created my own project template so I do not need to setup all this every time by myself.
I have completely rewritten this post. You can find the original post here. Out of the box it is only possible to secure your Azure Functions via Function Keys (API-Keys), which sometimes might not fit into your requirements. When using HttpTrigger we luckily have access to the current request and are therefor able to implement our own custom authentication/authorization methods. You could for example use JWT access tokens issued by an OpenID provider to control authentication/authorization.
In my last post you learned how to implement dependency injection in Azure Functions on function level. While this works for services registered as transient or singleton, it does not work with services registered as scoped. In this post you will learn how we can implement proper dependency injection with scopes! Inject attribute We again start with the Inject attribute. Since we are going to change how to resolve bindings, the attribute can now be empty.
This solution only supports transient and singleton scoped services. Please see my follow up post where you learn how to implement proper dependency injection with support for scoped services. Out of the box Azure Functions does not come with dependency injection support you can use in your functions. There are quite a lot of ways to add dependency injection, but most of them rely on the Service Locator (anti-)pattern. In this post you will learn how to implement dependency injection on function level using the extensions API without the Service Locator (anti-)pattern.
With Azure Functions you can quickly build simple web applications. In this example you learn how to create a simple photo gallery with just three little functions. We will use Azure Blob Storage to store the files and Azure Table Storage to save metadata. You can find the example at GitHub. Creating thumbnails Since we do not want use the original picture as a thumbnail, we will create a function that creates proper thumbnails.
With the upcoming version (2.1) of the Application Insights package for ASP.NET Core all requests made with HttpClient (and probably other clients) will have addition request headers, contain correlation ids. This is part of the dependency tracking feature. These headers are Request-Context, Request-Id, x-ms-request-id and x-ms-request-root-id. While this is usually not a problem, it might break functionality in some cases. For example in 2.1.0-beta2 it broke the request signature for Azure Storage requests.