This post was most recently updated on July 29th, 2020.Reading Time: 6 minutes.
Have you ever run into a situation, where you just wanted to remove the currently standing function definitions from your app service without actually nuking the whole Functions app? I have!
App Service configuration is usually easy to manage programmatically or by scripting, so even if you need to redo the deployment, it should be fairly straightforward. But what if you don’t have the setup scripted, and have already configured everything the way you like it – you’d really like to NOT nuke the whole Functions app in that case!
One good example of such case is changing between major versions of the Azure Functions runtime. I’m guessing Microsoft thought there’s not going to be a lot of demand to make this easy – so they didn’t make this easy. And probably rightly so: Changing between the major versions of the runtime is pretty drastic. You shouldn’t normally do that. But what if you want to do it anyway?
Well, let’s see how we can get it done!
My Azure Functions blocked me from updating Azure Functions runtime version!
My first instinct was to just jump on the case and change the Azure Functions app service runtime version from the “Function app settings” page, but it’s not that easy. I guess that’s for a good reason, though!
In the screenshot below, you can see how the page looks like when you have Azure Functions deployed: the “Runtime version” switch is disabled. It’s worth noting, though, that it does show which version you have active, it’s just not obvious: dark grey means you have selected that runtime version. Below, “~2” version has been selected.
Helpfully, the page tells you why the control is disabled: you cannot upgrade (or downgrade) as long as you have existing functions. So you need to get rid of them, even if you’re just going to upload the same functions, just slightly adjusted to work with different version of the runtime.
Although, it might be worthwhile to note at this point, that the adjustments between the runtime versions v1, v2 and v3 might not exactly be slight. But that’s a topic for another post.
Let’s remove the functions, then. Should be easy, right?
Okay – at least we can just browse to functions-view in the app service, and remove the function (app)s from there, right?
Well, we can go there, but everything’s going to be disabled. The page is in read-only mode, so you can’t remove the functions.
Funnily enough, you CAN disable them. But you still can’t remove them even when they’re disabled, and you can’t change the major version even with disabled functions. Funnily enough, while the control to enable or disable the functions does exist and work, the control for removing them doesn’t!
I also tried connecting to the Azure subscription from my Visual Studio – but even that tool doesn’t give any options on how to remove the functions. The best I could do was to tweak the publishing settings to remove all of the files when publishing a project, but that’s not helping me here, is it?
I did find a solution, though. Or actually a couple of solutions!
How to remove Azure Functions from an App Service (or an Azure Function App – or whatever its name is now!) without nuking the whole app
I could figure out 2 ways you can remove the functions without breaking anything in the app service – I’ll list them all and describe the fastest and easiest (I just went with that!) Additionally, I tried with Azure Cloud shell – but I don’t think it’s possible there.
1. The old-school way: FTP
Fire up your Filezilla (or other FTP client of choice), and traverse the directory structure like this:
Then remove the folders that are named like your functions.
And you should be good! While you can just leave the “bin” folder and the .json files be, they’ll be overwritten by any zip uploads, Visual Studio deployments and overwritable with ftp as well – so for most of the scenarios, you won’t need them.
Your Azure Functions App might require a restart before it lets you change the runtime version, though!
2. The easy way: Kudu
Ohh, I like this. Easy’s good.
Using the Kudu console (often referred to as “Advanced tools” in Azure), we can simply click through the same file & folder structure as in the above example, and remove the folders in essentially the same way.
Open up your Kudu console – that’s possible by either navigating to your Function App’s Platform Settings and selecting Kudu from there (see the screenshot below), or by just adding “.scm” (that’s short for Service Control Manager) between the name of your web service and the .azurewebsites.net -ending.
For example, if your Azure Functions live under
your Kudu instance will be accessible at:
Or from the link through the web UI, as shown below:
In any case, you should end up on the home page of your Kudu console. Navigate to “Debug Console” -> “PowerShell”.
In the File Explorer and the PowerShell console below it you can traverse the site structure and modify it. Go ahead and change your directory (by clicking on folder names or by using the console) to \home\site\wwwroot. Now you should be in the directory with your Azure Functions – feel free to nuke them as you see fit! You can recognize them by their names, again, it’s not necessary to remove the host.json and bin folders, although it shouldn’t hurt either.
Just like the last time, the Azure Functions App might require a restart before it lets you change the runtime version.
The way that would be the coolest but didn’t work: Azure Cloud Shell (or alternatively Azure CLI)
Azure Shell is available in 2 flavors (kind of) – as a Cloud Shell, and a CLI that you can install locally. In this particular case, I’m using the Azure Cloud Shell, that’s available directly in Azure Portal.
While it’s a phenomenal tool, I did not find a way to remove a function from inside a Function App – if you found a way to do it, feel free to let me know in the comments below!
After removing the Azure Functions, and possibly restarting your Function App, you can next browse back to your Function app settings and change the runtime version!
And if you were just changing the runtime version because you just deployed your v1.0 Azure Functions to an Azure Functions app running on v2.0 or v3.0, just go ahead and deploy your functions back to the app!