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
Debugging one Function app
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:
Use these settings (V2, HTTP Trigger, Anonymous):
Stick a break point in the Function:
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:
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:
Click Continue and see the output of the Function 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 multiple Function apps at the same time
Running one Function app locally is cool, but running multiple is even cooler!
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
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 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:
Debugging multiple Function apps in VS2017
Running multiple Function apps is good, but debugging them is even good-er!
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:
- Put break points in the HTTP triggers for both Function apps
- Start the first Function app without debugging
- 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
func.exeprocess will be greyed out; this is the one that is currently running through the debugger. Select the other one and click Attach.
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.