As a .NET developer, the yearly release cycle is always one of my most anticipated event. This years edition is no exception, as it brings .NET 9 to the forefront with its load of improvements. However, it also marks the end of support for .NET 6, meaning it’s time to think about upgrade and migration plan.
Over time, I’ve developed and continue to maintain a several of Azure Functions projects built on .NET 6 using the In-Process model. With .NET 6 reaching its end of life and the In-Process model being slowly deprecated (End of life Nov 2026), I decided it was the perfect timing to upgrade my projects to a newer .NET version, but also to make the switch to the Isolated Worker model.
During the process I encountered a nasty bug on Http-triggered functions, here’s how I uncovered and resolved the issue.
🤒The symptoms
I chose to upgrade my projects to .NET 8 Isolated worker mode. The migration path from In-Process to Isolated worker model is well documented (see link below) and I was able to adjust the code and Azure infrastructure without too much problems.
🔗Migrate .NET function apps from the in-process model to the isolated worker model | Microsoft Learn
As I began to test my new and improved functions, most of them worked on first attempt —Service Bus triggers, Timer triggers, Durable Functions all performed as expected. Unfortunately that was not the case for my HTTP-triggered functions.
For an unknown reason I kept receiving a 500 Internal server error with logs indicating some kind of timeout error. The same behavior was observed whether I ran the function locally or deployed in Azure.
The most frustrating part was that if I spun up a new project in Isolated Mode and created an HTTP-triggered function from scratch, it worked perfectly fine without any issues.
After a couple of hours of going around in circles and loosing what’s left of my hair, I stumbled upon this comment in an issue on the Azure Functions GitHub repo. The moment I read it, I knew I had found the culprit.
Indeed, there were some commented lines in my host.json file 😳, remnants of a test I made long time ago.
🧑⚕️The diagnostic
Removing these commented lines and deploying the project fixed the issue instantly and the HTTP-triggered function started to work as intended.
It seems that even if comments are not supported in the JSON specification, the In-Process model used to ignore and skip these commented line in the host file. That doesn’t seem to be the case with the Isolated worker model.
I later discovered several threads like the one below, where others have encountered the same issue. However, there doesn’t seem to be a fix on the horizon.
💊The fix
Since the compiler will not prevent the deployment of a function app project with a host.json with commented lines, this can lead to big problems.
For example, if a developer inadvertently commit a commented host file and deploys the function app, HTTP trigger issues will only be caught at runtime and might take a while to diagnose.
Sometimes, there might actually be a good reason for these commented lines. For instance, developers might want to test certain host configurations or toggle parameters on and off without losing track of their original settings.
Here’s how I updated my project build configurations and release pipeline to ensure this never happens, whether running locally or deployed in Azure.
The goal is to remove the host.json file commented lines in the build output folder while allowing them in source control. Special mention to GitHub Copilot who took care of crafting the regex and Powershell scripts for me. Thank you buddy 😉!
For this to work locally, I added this PostBuild command in the projects .cdsproj file.
<Target Name="PostBuild" AfterTargets="PostBuildEvent">
<Exec Command="powershell -NoProfile -ExecutionPolicy Bypass -Command "Get-ChildItem -Path '$(TargetDir)' -Recurse -Filter 'host.json' | ForEach-Object { (Get-Content $_.FullName) | Where-Object { $_ -notmatch '^\s*//'} | Set-Content $_.FullName }"" />
</Target>
For it to work in my Azure Devops release pipeline, I had to run this powershell script before the build step of the pipeline
- pwsh: |
Get-ChildItem -Path '$(Build.SourcesDirectory)' -Recurse -Filter 'host.json' | ForEach-Object {
Write-Host "Processing file: $($_.FullName)"
(Get-Content $_.FullName) | Where-Object { $_ -notmatch '^\s*//' } | Set-Content $_.FullName
}
displayName: 'Remove commented lines from host.json files'
And that’s it, I don’t have to worry anymore about breaking my HTTP triggered Azure Functions because of invalid host files.
Hope this helps.
Links
.NET 6 will reach end of support on Nov 12, 2024. After that, Microsoft will no longer provide updates for .NET 6. Security fixes and technical support will no longer be available for .NET 6. You’ll need to update to .NET 8 before this date to stay supported. Commercial support for…
Be First to Comment