💡 Presently sponsored by: ScriptRunner
Get your free PowerShell Security e-Book!
I recently had a few discussions about some heavily-loaded Blazor apps I've built. They are all running on .NET Core 3.1, but I am attempting to get them up to .NET 5 (Preview).
In these discussions, it came up that it wasn't at the time of our dialogs, possible to publish to Azure App Services with success. However, it seems that it works now - but again, it is a preview. Expect changes, perhaps even breaking changes, and don't ship to production just yet - at least that's what I'd recommend.
I have successfully upgraded two out of eight personal projects. Still, many dependencies fail in the remaining projects, and until that's a story of success, I'll happily share the process here, simplified with a new Blazor project.
Tag along for:
- Upgrading our existing projects from .NET Core 3.1 to .NET 5.
- Set up a brand new project and directly target .NET 5.
- What about breaking changes?
- Is it working in the cloud?
Install the .NET 5 SDK for Visual Studio 2019
During the initial draft of this blog post, I am targeting a preview version of .NET 5. As things mature, I will update this post with the released LTS version.
Get the SDK installer from the website:
When I publish this post, the SDK version is "v5.0.100-preview.4"
What to know about .NET 5 versus .NET Core
Something that has changed over the iterations of the preview and that seems to be reliable information finally is the naming of the target framework. Here's a quote from the Microsoft website:
Targeting API versions will be simpler with .NET going forward. We won’t have two families of TFMs, like:
netstandard2.0. Instead, we’ll have just one, like:
net6.0. That’s because there is just one .NET implementation going forward, so there is no longer a need for .NET Standard
What we need to know is:
- We don't need to use netcoreapp5.0 (as the earlier previews)
- We don't need to distinguish between netcoreapp and netstandard
- We specifically target net5.0 for both types of projects. Finally!
Upgrading an existing Web App to .NET 5
Currently, I am hosting all my Azure Web Apps with .NET Core 3.1. I intend to move them all over to .NET 5 in a separate branch to see how it works, so here goes.
For this blog post, I have created a new .NET Core 3.1 Web App that I will upgrade. My actual project contains dependencies that I know does not have any .NET 5 previews yet, unfortunately.
You can, of course, also create a new project and do the below steps to get up and running.
Updates in the .csproj file
To get my existing projects up and running, I will have to switch the target framework and any dependencies to the latest version of .NET 5 that I want to target.
- TargetFramework: Change to "net5.0"
My simplified .csproj file looks like this. You can set the TargetFramework directly in the file:
<Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <TargetFramework>net5.0</TargetFramework> <AzureFunctionsVersion>v3-prerelease</AzureFunctionsVersion> </PropertyGroup> <ItemGroup> <PackageReference Include="Microsoft.NET.Sdk.Functions" Version="3.0.7" /> </ItemGroup> <ItemGroup> <None Update="host.json"> <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory> </None> <None Update="local.settings.json"> <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory> <CopyToPublishDirectory>Never</CopyToPublishDirectory> </None> </ItemGroup> </Project>
You can also set the TargetFramework from the Project properties and look at the Target Framework:
I have many dependencies on many of my projects. My Azure Web Apps aren't always running only the Web App itself but have dependencies on other projects in the solutions, NuGet packages, and more.
Whether or not you can get all of your codebases up to the current version of .NET 5 is something you'll have to explore for your scenarios.
In one of my projects, it can look like this, where I make sure to update dependencies to the latest versions as well.
Be aware of breaking changes
I think tests should cover any code flying into a production environment. When you upgrade your projects, you'd see immediately if you have any noticeable breaking changes in your system due to changes in the SDKs.
Integration tests could be a way to ensure that the end-to-end flow works, as well.
An excellent way to stay ahead is to keep an eye on the ASP.NET Announcements GitHub repository. Filter the repository issues like this:
- Milestone: 5.0
- Label: "Breaking change"
You can use this URL to go directly to that filter: https://github.com/aspnet/announcements/issues?q=label%3A"Breaking+change"+milestone%3A5.0
Publish and run in Azure
Since the days of .NET 5 are early, and we're still in a preview as of writing this, there will be changes and improvements to this process.
For now, I am using a self-contained deployment that runs in an Azure App Service on Windows. Magically beautiful.
Configure self-contained deployment.
I like the "self-contained" deployment option. It packages your app in a self-contained executable that does not require .NET to be installed on the app service. Instead, the bundle comes with everything it needs to run.
Publish to Azure
I am publishing this from my Visual Studio project because it's a demo. My real projects are all running through GitHub Actions or Azure DevOps.
Per the usual deployment routine from Visual Studio, select Azure as the target:
Select Azure App Service (Windows), which is what I'll be doing here:
Next, next, finish!
Modify the Configuration, which we'll do to modify how we package the solution.
Next up, Publish to Azure and test out your web app. It should, if all things have gone well, run .NET 5 on your Azure App Service.
The new app is up and hosted in Azure, running .NET 5.
To re-iterate, we have now:
- Created an Azure App Service (Windows) in Azure.
- We created a publishing profile from Visual Studio for demo and dev purposes.
- Modified the configuration and set it to Self-Contained.
- Published to Azure.
- We have seen it in action in Azure.