DEMO: Output Bindings
Start course

This course is an introduction to Azure Functions. It explains how Azure Functions are little bits of your application logic that live in the cloud. The course includes how to activate—or what we call trigger—your Azure Functions, how to pass data to and from them, and also how to tie different Azure Functions together using an extension of Azure Functions called Durable Functions. 

This course provides hands-on demonstrations of how to create different kinds of Azure Functions, how to create bindings to other Azure Services from those functions, and how to create a Durable Function to manage state from one Azure Function to the next.

If you have any feedback related to this course, please contact us at

Learning Objectives

  • Create Azure Functions with different types of Triggers
  • Implement input and output bindings to different types of data resources
  • Create Durable Functions to orchestrate related Azure Functions
  • Log the results with Dependency Injection

Intended Audience

Software developers who want to learn how to implement Azure Functions as a part of their cloud software design.


To get the most out of this course, you should have some experience will the following:

  • Event-driven programming
  • Servers and APIs
  • Coding with C# and JSON
  • Project creation in Visual Studio


The GitHub repository for this course can be found here.


Implementation of your output binding in your Azure Function inside of Visual Studio is very straightforward. All you're actually doing is adding an output parameter argument to your function signature and then applying an attribute to that argument to actually indicate the binding that you're looking to create.

So you can begin to see a pattern developing here. For example when we used the TimerTrigger attribute, we simply applied that attribute to our initial argument of the type that we want it to be using. And we're doing exactly the same thing in our second argument where we apply this binding attribute for the queue to the out message that we're going to be creating using our queue.

If the Visual Studio that you're using doesn't recognize this particular item, make sure that you have a couple of NuGet packages installed which would be the Microsoft.Azure.Storage.Queue and then the Microsoft.Azure.WebJobs.Extensions.Storage will give you everything that you're gonna need to be able to interact with your queue both presently and in the future if you're ever gonna be creating functions to peek into your queue or anything like that.

So those two namespaces will give you everything that you need. And then the only caveat here before we run our function would be to make sure that we actually have a queue that matches this name that exists because what our code is saying here is that when our trigger function runs, we will automatically be sending data.

Because it's an output binding, we're going to be sending data to the object specified here in this argument. So to make sure that our queue exists, we just pop open our local cloud explorer, and it will include a menu item for local, you may have other connections established, but initially all you're interested in for this project would be your local connection, using that as your WebJobs storage connection string. And you can see as you drill down that in your storage account you'll have blob containers and queues and tables and so on and so forth. And so in our case we're just checking our queues that we, yes, we do have an item in here called thequeue, and if we right-click on that queue, we can pop it open and we can actually see that there is nothing in it. Queue contains no messages.

So in theory when we run our function, we should be able to go back into that queue and see that this QMessage, Timer triggered, has been created. So you'll note that there is another name for the string value that we're passing to QMessage. I'll get into the details of this in just a second.

We're gonna use this when we do a combination of an input binding to combine with our output binding. But again right now our output binding simply acts as a receiver for data that we're gonna be sending, in this case it's our queue object and the particular message that we're going to be sending is Timer triggered. This should all happen automatically when our timer function runs.

So we'll just go ahead and run the function and see what we get. And so Visual Studio pops open our console as is typical for a local development Azure Function. It reports on its status in the usual way. And then we can see that our function has executed. So our Timer trigger function has executed and successfully.

So now in order to verify that everything worked properly with our queue, we just close that up, stop the host, head over to our queue, open it up, and we see that we have the first message successfully in there, Timer triggered. If you're curious about what that looks like inside your function.JSON file, here it is, here is your trigger binding with your queue output. 

Remember that Visual Studio takes care of all of this by simply creating the arguments properly with the attributes inside of your Azure Function. So typically you don't even have to see inside of your function JSON file, you don't have to make any changes to it. Azure and Visual Studio will automatically take care of all of those bindings for you. So you have successfully implemented your first output binding in an Azure Function.

About the Author

David Gaynes is a software and cloud architect for .NET, NodeJS, Azure and AWS. He has been developing .NET and Cloud software for more than 20 years, with some of that time spent at Microsoft, and has authored both technical and non-technical teaching materials as books and in other formats. He enjoys physics, meditation, and experiencing the natural wonders of Hawaii.