Functions

Azure .NET 5 Functions A lot has been said about .NET 5 support for Azure Functions. The most important news: it is now officially supported! 🥳 To enable running Azure Functions with .NET 5, the new Isolated Model enables Functions to run as an out-of-process language worker separate from the Azure Functions runtime. This way you’ll have full control over the Function’s dependencies on one hand, and new features like a middleware pipeline on the other.

After my two previous posts Azure Static Web Apps: a first look and Azure Static Web Apps: quirks & gotchas, let’s have an updated look at ASWA in this post. Support for new languages 👩🏻‍💻 Announced at Microsoft Ignite this year, Blazor and C# APIs now supported in Azure Static Web Apps. This enables .NET developers to build and deploy full stack .NET applications with Static Web Apps. Blazor support Since ASWA is a static hosting option, which means we don’t have a server component*, the Blazor support for ASWA means support for Blazor WebAssembly.

After playing around with Azure Static Web Apps (ASWA) for some time I found some quirks and gotchas. Of course Static Web Apps are still in preview. Most of these are probably because of that fact. Despite that, it might still be interesting to know about them. That way if you run into any of them, you’ll at least know it’s not you … 😉 🏭 Creating an Azure Static Web App It all starts when you want to create an ASWA: searching for it in the list of resources in the Azure portal doesn’t show it.

Although the two have a lot in common, even including parts of the name, there are a few very clear differences between Static website hosting in Azure Storage and Static Web Apps. We’ll have a look at what those differences are and take a first look at the most recent of the two: Static Web Apps. Static website hosting in Azure Storage Static website hosting is a feature you can enable free of charge on a storage account.

My post Using Triggers & Bindings in Azure Functions V2 drew quite some attention over the past months. But there is a lot more to say about them. Time for a small follow up 😁 Covered previously ⌚ In my previous post we covered relative simple things like writing to blob storage and putting messages on a Service Bus. But the bindings for Azure Functions are so much more powerful.

Azure App Configuration is a powerful way to manage and store application configuration on a central location. Integrating it into for instance ASP.NET (Core) is pretty straightforward. This post gives you an introduction to Azure App Configuration and a simple example of how to integrate it in ASP.NET Core. Creating an Azure App Configuration 🆕 Of course there are several ways to create a specific resource in the Azure Portal. One of the simplest is to go to the portal, open up App Configuration and click the Add button.

Here’s a short post I didn’t want to hold from you. As you may already know I wrote a blogpost on Using Triggers & Bindings in Azure Functions. It handles quite a few nice possibilities of using triggers and bindings in Azure Functions (if I may say so myself… 😳). Fortunately, you learn something new every day. So I learned about Property Binding recently… Property Binding Like in the HttpTriggerReturnBinding example in the functions-triggers-bindings-example GitHub repository, let’s say we have a model RequestModel that we’re receiving through a POST on an HttpTriggered Function.

This post is part of a series on Managed Identity. For an introduction, see Managed Identity – Part I. For a post that shows you how to connect your application to different types of Azure resources using Managed Identity see Managed Identity – Part II. Stay tuned for future posts. Introduction Elaborating on Part I and Part II, this blog post will show you how to debug your Managed Identity enabled application locally.

Next week my colleague Daniël te Winkeland I will do a session at Techorama 2019 titled Getting sh*t done with Azure Functions (on AKS!). Or GSDwAF for short 🤓 We will talk about running Azure Functions in a Kubernetes deployment using Managed Identities and implementing Dependency Injection. And, even better, we’ll show you how! Who will we see Tuesday, October 1 • 3:00pm – 4:00pm • room 3? UPDATE That. Was.

This post is part of a series on Managed Identity. For an introduction, see Managed Identity – Part I. Stay tuned for future posts. Introduction Elaborating on Part I, this blog post will show you how to connect your application to different types of Azure resources using Managed Identity. To use the Managed Identity to actually connect to Azure Resources, you’re going to need the NuGet package Microsoft.Azure.Services.AppAuthentication. This package enables a service to authenticate to Azure services using the developer’s Azure Active Directory/ Microsoft account during development, and authenticate as itself (using OAuth 2.

This post is part of a series on Managed Identity. Stay tuned for future posts. Introduction Connecting your application to a resource like Storage or a SQL database used to involve a connection string. This isn’t very secure. These settings are available through the Azure portal. So they might get compromised. With the introduction of Azure Key Vault, we got a way of separating these secrets from our application configuration. We can store them in a safe, secure place.

Last week one of my colleagues had a question: Is there a performance penalty when you add multiple Azure Blob storage bindings in an Azure Function? Or is the connection only established when you access one of those blobs? Answering this grew into a way to have Dynamic output bindings in Azure Functions. This post elaborates on [blog/using-triggers-bindings-in-azure-functions-v2](Using Triggers & Bindings in Azure Functions V2). First try The idea was simple: