Posted in:

Thanks to the Azure Functions CLI, it’s possible to debug your Azure Functions running locally, which is a great way to troubleshoot your functions before sending them live.

But did you know it’s also possible to debug them remotely? This works because Azure App Service, which Azure Functions is built on top of, already has remote debugging support built-in.

Setting Up

First of all, a few things you’ll want installed. You need Visual Studio 2015 Update 3. Currently it seems VS 2017 is not supported, but I suspect that will only be a matter of time. Also, install the Visual Studio Tools for Azure Functions (not 100% sure this is necessary, but useful anyway if you’re going to be using Azure Functions with Visual Studio), and make sure you have the Cloud Explorer extension installed (I think you get this automatically when you install the Azure SDK for VS).

Finally, there are a couple of debug settings you need to change. In the Debug | Options dialog, deselect “Enable Just My Code” and “Require source files to exactly match the original version”

image

Attaching the Debugger

Now in the Cloud Explorer window, navigate to the function app that you want to debug, and in the Files node, find the source code for the function you want to debug. Please note that at the moment, I understand that you can only remote debug C# functions. Hopefully this will change in the near future. I haven’t tried remote debugging other languages myself.

image

Now we can double-click on the run.csx file to download it from Azure and set up your breakpoints.

image

Now we need to attach the debugger. This is done in the Cloud Explorer by right-clicking on the app service and selecting “Attach Debugger

image

This will take a while, and will open a web-page that you don’t need (the home-page for your app service), but the important thing is that the debug symbols get loaded. You should see a bunch of dialogs saying that the symbols are loading.

If all is well, the breakpoint you set will appear as a solid red circle indicating that it can be hit. If not (which sadly seems to happen quite regularly), I have found that stopping and restarting the app service before attaching the debugger usually helps.

Debugging your Function

Finally, you need to trigger your function with a HTTP Request or posting a message into a queue etc. When the breakpoint hits, you can do all the usual stuff you’d expect in the debugger, including hovering over to see the values of variables, stepping through the code, and changing the values of variables with the Immediate window.

The whole remote debugging function experience is a little on the flakey side at the moment. Hopefully as the tooling matures it will become more reliable. In many cases you shouldn’t need to use this at all, but it’s nice to know that should the need arise you can still remotely attach to the servers your “serverless” code is running on and find out exactly what is going on.

Want to learn more about how easy it is to get up and running with Azure Functions? Be sure to check out my Pluralsight courses Azure Functions Fundamentals and Microsoft Azure Developer: Create Serverless Functions

Comments

Comment by John Berry

Remote debugging appears not to be supported with Azure Functions on a Consumption Plan. No debug is available in Cloud Explorer. Is this a confirmed limitation?

John Berry
Comment by Mark Heath

I'm pretty sure I was on the consumption plan when I tested this - I do a demo in my Pluralsight course if you have access. But things are rapidly changing, with the new support for VS2017 and precompiled functions, it might be best to ask over at the azure functions github project about what the current status is

Mark Heath
Comment by Alan Jones Rios

When you publish from visual studio, it build to a WebService.dll, after that its not possible to edit or remote debug. That's sad :(

Alan Jones Rios
Comment by Mark Heath

That's a shame - I haven't tried remote debugging with the new precompiled functions yet, but I would expect that to work. I'll try it out next time I'm doing some functions work and will blog about it if I can get it going

Mark Heath
Comment by Tsahi Asher

I have a class library C# function, and the above procedure didn't work for me. But I didn't restore the debug settings to their checked state, and that prevented me from debugging locally. It took me nearly two work days to realize what was going on!

Tsahi Asher