Microsoft has updated Azure’s main PaaS services with the latest release of .NET. Here’s the skinny on .NET 6 support in Azure Functions, Azure App Service, and Azure Static Web Apps.
The November 2021 launch of .NET 6 introduced the first Long Term Support (LTS) version of the new .NET Core-based unified platform. Supported until November 2024, .NET 6 is intended for production code that needs a stable foundation. You can build on .NET 6 now and be sure that your code won’t need significant changes until after the launch of .NET 8.
As a result, it’s not surprising to see Azure’s main PaaS (platform-as-a-service) tools adopt .NET 6 very quickly, with immediate, “day zero” support in Azure Functions, Azure App Service, and Azure Static Web Apps. We’ll walk through the .NET 6 support in these popular Azure services below.
Moving to .NET 6 makes sense for Azure, as the previous LTS release, .NET Core 3.1, drops out of support at the end of 2022. With a year overlap, there’s time to move your code to the current LTS release before support ends.
Build serverless functions with .NET 6
The most obvious .NET 6 transition comes with the release of Azure Functions 4.0. Microsoft’s serverless platform gets regular updates to add new versions of all its main runtimes. For Functions 4.0, these include Node.js 14 for JavaScript code, Python 3.7 and 3.9, Java 8 and 11, and the .NET Core 3.1-based PowerShell 7.0 (which will eventually be updated to the .NET 6-based PowerShell 7.2). With Azure Functions 4.0 the recommended runtime, you should consider it for all new code and as a target when updating existing applications.
It’s important to remember you don’t have to move code right away. Applications running in Azure Functions 3.x will still work, though it’s a good idea to keep an eye on Azure’s service announcements to ensure that you’re not relying on a specific minor version that’s being withdrawn. Azure Functions 1.x and 2.x are now in maintenance mode, which means they should only be used for existing code that requires specific .NET features and cannot be updated to run on newer releases.
Getting started with Azure Functions 4.0 shouldn’t be too difficult. Existing code written for Azure Functions 3.x will be based on either .NET Core 3.1 or .NET 5.0 and should migrate easily as there’s a lot of backward compatibility between the two releases. Older code may require some work, especially if you’re moving from .NET Framework 4 to the new open source version. Upgrades will require first updating local development and test environments before upgrading your application on Azure.
Updating older .NET Azure Functions
Start by updating your code’s TargetFramework and AzureFunctionsVersion to support .NET 6 and Azure Functions 4.0. At the same time, update libraries and packages from NuGet to ensure you’re running compatible versions. In Azure, use the CLI to switch your target Azure Functions version for your application.
You don’t have to make this a big bang and update all of your applications at the same time. You can update different applications at different times or even create new major versions of applications if you’re using Azure Functions to host APIs (allowing you to add new features at the same time as upgrading .NET and Azure Functions releases). Although maintaining different versions of an API can add to your workload, it will allow you to gracefully deprecate older endpoints and help your users migrate to new versions.
Some breaking changes affect moving from Azure Functions 3 to Azure Functions 4, mostly due to changes in the underlying .NET runtime. Some, like the removal of support for Aure Functions Proxies, require using alternate Azure services; others will require code or library changes. For example, Azure Functions now enforces minimum versions for extensions, so you will need to ensure that code is updated before being published to Azure.
One change that may cause some upset is the requirement to use separate storage accounts for apps that have the same computed hostname (usually as a result of their being too long and being automatically truncated, something on the order of 30% of apps running on Azure Functions 3), which can stop code from starting. In practice, it shouldn’t be too much of a problem, but it will now cause apps to error and fail, where previously it only generated a warning.
.NET 6 in Azure App Service
Azure Functions isn’t the only Azure PaaS to offer .NET 6 support. Azure App Service is using .NET 6 for its .NET-based tools. You can use Azure App Service to quickly roll out ASP.NET Core 6.0 application back ends, using familiar Visual Studio tools. Again, the advantage here is Long Term Support for your development and deployment environments, as well as cross-platform support for the .NET runtime so you can choose either Windows or Linux hosts for your code.
There’s support for both standard deployments with shared or self-contained runtimes and more portable container-based deployments. Choosing a self-contained deployment on Linux or Windows makes sense as you’re isolated from other applications, with your own runtime and libraries. However, you will need to make sure that you’re managing updates for your application, as this is no longer handled by Azure.
As Azure App Service is purely an ASP.NET host, you’ll have to migrate existing code yourself, though that shouldn’t be too much of an issue. Microsoft provides a good set of migration instructions, both for ASP.NET Core 3.1 and ASP.NET 5. There are some breaking changes as part of the new release, but these are well documented, and it shouldn’t be too difficult to make the appropriate changes.
Using .NET 6 for WebAssembly in Azure Static Web Apps
The other Azure service that got an at-launch .NET 6 release was Azure Static Web Apps. Here things are a little different. Instead of running .NET 6 on Azure’s servers, you’re running on your users’ browsers via .NET 6’s WebAssembly support using Blazor. It’s perhaps best thought of as a complement to either Azure Functions or Azure App Service, providing a front end to Azure-hosted APIs.
Like other Azure Static Web Apps, you’re building locally, using GitHub for CI/CD (continuous integration and continuous delivery) and Azure for hosting. However, instead of Jamstack pages, your web content will host .NET 6 applications with full support for technologies such as Uno’s WebUI components. Visual Studio’s Blazor tools simplify the process of taking existing .NET applications and porting them to the web, and you can use ahead-of-time compilation to deliver bytecode directly to browsers rather than an entire .NET runtime. You can even use the free plan to build and test Blazor applications before moving to a paid tier.
Rapid rollout of .NET 6 in Azure is good for developers wanting to take advantage of the latest features. With Long Term Support, we’ll see third parties and open source developers creating new libraries and components, ensuring that you’ll get the tools you need to deliver the apps your users are expecting. As Microsoft and the .NET team roll out interim update releases, we should see Azure pick them up as quickly, using early-release mechanisms to seed early adopters and then wider rollouts as part of regular image and container updates.
BDCC
Latest posts by BDCC (see all)
- Top Security Practices for DevOps Teams in 2025 - December 19, 2024
- Jenkins vs. GitLab vs. CircleCI: The Battle of CI/CD Tools - December 16, 2024
- Beyond the Pipeline: Redefining CI/CD Workflows for Modern Teams - December 13, 2024