Welp – another interesting error encountered while deploying Azure Functions to Azure. So, everything runs nicely locally, but when you deploy your well-tested, functional and pretty code to run them in the cloud, you’ll just get these ugly and unfriendly errors. Long story short, “Function compilation error” is what you’re faced with.
Example error below:
Function compilation error Microsoft.CodeAnalysis.Scripting.CompilationErrorException : Script compilation failed. at async Microsoft.Azure.WebJobs.Script.Description.DotNetFunctionInvoker.CreateFunctionTarget(CancellationToken cancellationToken) at C:\azure-webjobs-sdk-script\src\WebJobs.Script\Description\DotNet\DotNetFunctionInvoker.cs : 314 at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at async Microsoft.Azure.WebJobs.Script.Description.FunctionLoader`1.GetFunctionTargetAsync[T](Int32 attemptCount) at C:\azure-webjobs-sdk-script\src\WebJobs.Script\Description\FunctionLoader.cs : 55 at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at async Microsoft.Azure.WebJobs.Script.Description.DotNetFunctionInvoker.GetFunctionTargetAsync(Boolean isInvocation) at C:\azure-webjobs-sdk-script\src\WebJobs.Script\Description\DotNet\DotNetFunctionInvoker.cs : 183
This stops any and all of your functions in this particular Azure Functions App from running.
Okay – so how to fix this?
Solution: Fix your Azure Functions runtime version!
Okay – this one was annoyingly simple, but still – since the error message is not that clear, could take a while to figure out. My issue started when deploying to Azure, which was kind of a big hint. I started going through the settings of my Azure Fnctions app, and realized that since I had
Change your Azure Functions runtime from 2.x to 1.x.
Sounds easy, right? But it isn’t, not necessarily at least!
As far as you have any Azure Functions in your Functions app, you can’t change the runtime version. Basically, you’ll have to remove the functions before you can upgrade or downgrade your application runtime.
If you were just publishing your Azure Functions and had nothing really configured, you can just remove the Function app and recreate it. Be mindful to use the right runtime version before deploying the functions this time!
However, if you have already configured authentication, set up a ton of application settings or done some other configuration on the app, and don’t want to completely destroy it, there is actually a way to change the runtime version without completely removing the Function app!
If you remove all of your Azure Functions from your Azure Functions app (love the terminology!), you’ll be able to change the runtime version without nuking the whole app, and will avoid redoing the configuration work you might’ve already done. To achieve this, you’ll need to remove the files and folders of the Azure Functions on the hosted IIS site – see the article below, on how to do this!
I highly doubt you’ll encounter this completely out of the blue in Azure – rather, you’ll encounter it locally by running the wrong Azure Functions runtime version, or alternatively by deploying your v1 Azure Functions to a v2 Azure Function App.
The latter is unfortunately really easy to achieve. After all, you can deploy Azure Functions built on v2 to an Azure Functions app built on v1 with no checks done – no matter whether you’re deploying from Visual Studio, ftp or probably from version control either (haven’t tried the latter one, though!)
Luckily, the fix is also simple :)
He's been a developer from 2004 (starting with PHP and Java), and he's been bending and twisting SharePoint into different shapes since MOSS. Nowadays he's not only working on SharePoint, but also on .NET projects, Azure, Office 365 and a lot of other stuff.
This is his personal professional (e.g. professional, but definitely personal) blog.
Latest posts by Antti K. Koskela (see all)
- SPFx webpart fails with “Failed to load component – – There was a network error.” - June 19, 2019
- Thanks for coming to my session at SPS Nashville 2019! - June 17, 2019
- The boring version of browser wars is upon us - June 13, 2019