Running and Debugging Azure Functions

Test and debug locally with Rider

You got your first functions added? Great! With the Azure Toolkit you'll see an icon next to each function in the editor gutter to run or debug either all or just the single function. You’ll also see that there is a run configuration available in the run widget. The default run configuration is based on the launchSettings.json file and executes all functions:

Running from Editor Gutter and Run Widget

Tip: From the Edit Configurations dialog you can make customizations to the way how your functions are executed. For instance, you can change the port, add environment variables, run additional tasks before the launch, or even open your browser at a specific endpoint:

Edit Run Configuration

Once you run or debug your functions, the Run window will open at the bottom. From here you can see how Rider is invoking the Azure Functions Core Tools (including the port) and what functions the runtime discovers in your project. Note that you can restart or stop the current execution from both the run widget and the tool window:

Console Output in Run Window

Tip: If you’re running your app in debug mode, you can take advantage of hot reload. This allows you to make modifications and apply them to the running application without restarting the debug session. Changes are taking effect on the next debugging step or when you resume the execution.

Hot Reload after Changes

Triggering Functions

Of course, you don’t want to wait for the specific event that triggers a function to actually debug it. The gutter icon on the left is an entry point to invoke any of your functions:

Triggering Functions

Rider then creates a .http scratch file (temporary file) for you that acts as a fully-featured HTTP client to send requests and inspect their responses. Similar to functions, you can run a request from the editor gutter or run widget. The result of the execution is displayed in the Services window:

HTTP Client

Warning: There is a known issue where the port in the generated scratch file is not taken from the launchSettings.json file. Make sure to look up the port either from that file or from the Run window output.

Below you can examine some HTTP requests that would fit our previously discussed functions. Through the administrative endpoint, you can even run non-HTTP-triggered functions:

### HTTP Trigger

@action=fail
GET http://localhost:7071/api/HttpTrigger/

### Timer Trigger

POST http://localhost:7071/admin/functions/TimerTrigger
Content-Type: application/json

{}

### Queue Trigger

POST http://localhost:7071/admin/functions/QueueTrigger
Content-Type: application/json

{
  "input": "This is the message"
}

Tip: Make sure to dive deeper into Rider’s integrated HTTP client to learn about all its features. Those include, among other things, the ability to:

Endpoints Window

The Azure Toolkit integrates with the Endpoints window, which you might already know if you’ve worked with ASP.NET Web APIs. HTTP-triggered functions are automatically discovered and you can use the integrated HTTP client as discussed above:

Endpoints Window


Now it's time to deploy your functions and bring them to the global network of Azure.