Failed to load the dll from [%localappdata%\AzureFunctionsTools\Releases\3.30.1\cli_x64\hostpolicy.dll], HRESULT: 0x800700C1

When Visual Studio 2022 went GA, I jumped on the new shiny and updated (from 2022 Preview) as soon as I woke up. Once done I went back to developing my isolated Azure Function app and when debugging it would not load with the following message: Failed to load the dll from [%localappdata%\AzureFunctionsTools\Releases\3.30.1\cli_x64\hostpolicy.dll], HRESULT: 0x800700C1 Now HRESULT: 0x800700C1 relates to differences in bitness, but I can’t see how anything had changed compared to when I was running this on 2022 Preview the day before.

Azure Pipelines Error NETSDK1045: The current .NET SDK does not support targeting .NET 6.0

I’ve just finished doing a bunch of work in an Azure Function app targetting .NET 5.0 Now that .NET 6.0 is GA, .NET 5.0 will reach end of support in May 2022. So I upgraded it to .NET 6.0 and Functions v4. This was all very straightforward, except when building my App in Azure Pipelines, where I got the following error: Error NETSDK1045: The current .NET SDK does not support targeting .

Error "The input content is invalid because the required properties - 'id; ' - are missing" when using CosmosDB

I’ve been working on an Azure Functions project in the .NET 5 isolated model, and while I am loving the experience, there are a few small annoyances along the way. One of those is when using the Microsoft.Azure.Cosmos Nuget package, which is currently at 3.x and relies on Newtonsoft.Json for serialization of CosmosDB documents. See, from .NET Core 3.0 and above, JSON serialization has been available through the System.Text.Json namespace, and although they are still working on parity of features, since .

OAuth 2.0 Authorization Code Flow with Azure Functions and Microsoft Identity - Part 3: Validating the ID token

This is part three in a three part series on Authorization Code Flow with Microsoft Identity. If you haven’t started at Part 1, I would suggest you do as it would make more sense than starting from here. One thing that was pointed out in the previous post, though, was that any id token for any app on that AzureAD tenant could be used to get a refreshed access token, and that isn’t very secure.

OAuth 2.0 Authorization Code Flow with Azure Functions and Microsoft Identity - Part 2: ID Tokens and Refresh Tokens

This is part two in a three part series on Authorization Code Flow with Microsoft Identity. If you haven’t started at Part 1, I would suggest you do as it would make more sense than starting from here. Previously I had written about how to use Azure Functions to create an OAuth 2.0 Authentication Code flow to work with your static front-ends. This discussed a backend service taking an authentication code, using it to validate against the Microsoft Identity service, and returning an access token back to the user.

OAuth 2.0 Authorization Code Flow with Azure Functions and Microsoft Identity - Part 1: Getting an Access Token

This is part one in a three part series on Authorization Code Flow with Microsoft Identity. You can also follow through to Part 2 and Part 3. Single Page Applications (SPAs) are a great. For me, they are cheap front-end as they are just static files that don’t need a whole web server/service and there for can be run for basically nothing. I generally run mine on an Azure CDN and it costs me about $0.