Debugging multiple Azure Functions apps at the same time

Jim Bennett
Nov 13, 2018 · 5 min read

I recently built a demo app with two Azure Functions projects in it: one using the new V2 Functions runtime and written in C#, and one using the old V1 runtime so that it can access some .NET framework bits and written in F#.

One of the really cool features that Azure Functions offers is the ability to run your functions locally with a full debugging experience, and this is supported in Visual Studio 2017 as well as in VS Code. (This post focuses on how to do this in VS2017. For VS Code, follow these instructions.)

In this post, we’ll cover:

  • Debugging one Function app
  • Running multiple Function apps at the same time
  • Debugging multiple Function apps at the same time using Visual Studio 2017

First, create a new Azure Functions app in Visual Studio, add a breakpoint in the HTTP trigger, and then start debugging.

The Azure Function app will launch in a local Functions host, and your trigger will be available locally on http://localhost:7071/api/Function1 (so listening on port 7071). You can launch your favorite browser, navigate to this URL and your break point will be hit, giving a full debugging experience with watch, edit and continue and all the bells and whistles.

Create a new Function app:

Creating a new Azure Functions project from the Visual C#->Cloud section of the File->New dialog

Use these settings (V2, HTTP Trigger, Anonymous):

Configuring the Azure Function to use V2, an HTTP trigger with anonymous access rights

Stick a break point in the Function:

Adding a breakpoint to line 22

Start debugging the Function the same way you would with any normal app (you may need to grant firewall access). This will launch a console window with the functions host running — you’ll see some cool ASCII art then the functions output including the HTTP URLs for all HTTP triggers:

The Functions app running in a console window

Now launch your favorite browser and navigate to the Function1 URL. The Function will run and your break point will be hit. This is a full debug session with edit and continue:

The breakpoint being hit

Click Continue and see the output of the Function in your browser:

The function output in your browser

There is also a storage emulator that you can run locally so you can read/write to blobs, tables and queues and even use triggers. Read more here.

Running one Function app locally is cool, but running multiple is even cooler!

Stock photo of a cool looking rubber duck — cos why not!

Add a new Function app to your project, then run it without debugging using Debug->Start without debugging. This will spin up the local Azure Functions host and start listening on port 7071.

You will notice this is the same port as the first Functions app. By default, the local Functions host listens for HTTP requests on port 7071.But if you now launch the first Functions app it will fail, giving you a really weird error:

Cannot access a disposed object.
Object name: 'IServiceProvider'.

The error shown when multiple local functions hosts run on the same port.

The fix for this is to tell the Functions host to run on a different port, and this can be done by adding arguments to the command line that is run when the Function app is debugged. Kill all the Functions hosts, and open the properties for the second Function app. Head to the Debug tab, and set the Application arguments to be:

host start --pause-on-error --port 5860

This will start the Functions host listening on port 5860. You can use any port you wish for this of course.

These settings are not saved in the project itself, just in your user settings so this won’t be in source control.

Now if you run the second Function app it will be listening on a different port:

The Azure Functions local host running on port 5860

Running multiple Function apps is good, but debugging them is even good-er!

Bad stock photo of people high-fiving

Although Visual Studio 2017 can’t launch multiple apps at the same time, you can launch one then attach it to the others. To do this:

  1. Put break points in the HTTP triggers for both Function apps
  2. Start the first Function app without debugging
  3. Then start the second Function app through the debugger

Now, attach the debugger to the first Function app like so:

  • Select Debug->Attach to process…
  • Search for func
  • One func.exe process will be greyed out; this is the one that is currently running through the debugger. Select the other one and click Attach.
Finding the func process in the attach dialog

You should now be able to open http://localhost:7071/api/Function1 in your browser and hit the breakpoint in your first Function app, and open http://localhost:5860/api/Function1 to hit the breakpoint in the second function app.

You don’t get edit and continue in the Function app you attached to, only in the one run through the original debugger. If you want edit and continue, make sure the Function app you want to use this for is run through the debugger, and attach to the others.


Want to learn more about Azure Functions? Well we have a learning path for that as part of Microsoft Learn. Check it out here.

Microsoft Azure

Any language. Any platform. Our team is focused on making the world more amazing for developers and IT operations communities with the best that Microsoft Azure can provide. If you want to contribute in this journey with us, contact us at medium@microsoft.com

Jim Bennett

Written by

Cloud Developer Advocate at Microsoft, Xamarin Certified Developer, blogger, author of Xamarin In Action, speaker, father, husband. Opinions are my own. He/him

Microsoft Azure

Any language. Any platform. Our team is focused on making the world more amazing for developers and IT operations communities with the best that Microsoft Azure can provide. If you want to contribute in this journey with us, contact us at medium@microsoft.com