Blogs

Probably there’s no need for me to say why .NET Core 3.0 is a big deal. There are enough articles on that. For a great write-up see Announcing .NET Core 3.0. From the inception of the .NET Core project, we’ve added around fifty thousand .NET Framework APIs to the platform. .NET Core 3.0 closes much of the remaining capability gap with .NET Framework 4.8. Introducing .NET 5 Next to adding this massive amount of .

Yesterday I was working with one of our customers to fix an issue with an ASP.NET application throwing an error. That application threw the error on the first request coming in through Azure Front Door. When we sent a request to the original (back end) URL, the application worked fine and never threw the exception. 🤔 Time to investigate…! Finding the cause 🧐 First step of course was to find the cause of the exception.

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.

Some time ago Oscar van Tol and I started creating video content for the community. We call them #Betatalks and create them because of two very important reasons: We believe in sharing knowledge It’s. So. Much. Fun. 🤣 We talk about a lot of developer stuff: from “Microsoft Build 2019 Highlights” in episode 1 to “C# 8, What’s new?” in episode 4. The most recent #Betatalks is episode 5: “All about configuration in Azure”.

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.

Calling an API from a Logic App is pretty straightforward. You open up the Logic App Designer and add an HTTP Action. Specify the method to use and the URI you want to call and you’re good to go! When the API you want to call uses Cookie Authentication, this seems pretty straightforward too. After all, the HTTP Action has an Authentication property you can set. However, this property doesn’t include Cookie authentication.

I am humbled and very proud to be awarded a Microsoft Azure MVP award today. A big “thank you” to all who helped me get here. 🙏🏻 A special thank you to my employer Betabit who supports me putting lots of effort into the community and helps organize or sponsor events. It’s strange but very cool to see social media ‘explode’ (at least according to my standards) after my announcement. But I’m still just Rick, a guy who loves to do fun things with code, in the cloud.

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:

We’re hosting a VS2019 Launch Event at the Betabit The Hague office. Join us for some Visual Studio 2019 goodness! And maybe even some swag… ? Join us on April 2 for the launch of Visual Studio 2019. Learn about how Visual Studio 2019 is more productive, modern, and innovative, participate in live Q&As, and be the first to take the latest version for a spin. https://visualstudio.microsoft.com/vs2019-launch/ The agenda is as follows:

To start things off: yes. There’s some pretty decent documentation on all the available Triggers & Bindings in Azure Functions. Like this overview page. And you can also find documentation on specific bindings, like the Service Bus Binding. Nevertheless, I wanted to add to that documentation with some simple, real-world examples using triggers & bindings. So here goes. Writing to Blob Storage Consider this very simple BlobTriggered Azure Function. It copies the triggering file into a different container in Azure Blob Storage: