Skip to content

Azure Functions – Part 5: Deploying to Azure from VSCode

Last updated on 2018-11-18

Previous Tutorial: Azure Functions – Part 4: Working with Visual Studio Code and Persisting Data

Continuing from the previous tutorial, we’ll deploy the function we created to Azure. First thing we want to do is replace the storage account used to store the UserData (the default storage is a good way to start, but we probably want to have a separate account). We do this by defining a new application setting containing the connection string to the storage account, and annotating the function with this setting. It’s a good practice NOT to store credentials and connections strings directly in code, and Azure Functions pushes us to use that best practice by requiring an application setting name. The local.settings.json file acts as a local storage for application settings, so we’ll take the value we have in AzureWebJobsStorage and create a new setting called MyStorageAccount with the same value:

"IsEncrypted": false,
"Values": {
"AzureWebJobsStorage": "AccountName=devstoreaccount1;AccountKey=Eby8vdM02xNOcqFlqUwJPLlmEtlCDXJ1OUzFT50uSRZ6IFsuFq2UVErCz4I6tq/K1SZFPTOtr/KBHBeksoGMGw==;DefaultEndpointsProtocol=http;BlobEndpoint=;QueueEndpoint=;TableEndpoint=;",
"MyStorageAccount": "AccountName=devstoreaccount1;AccountKey=Eby8vdM02xNOcqFlqUwJPLlmEtlCDXJ1OUzFT50uSRZ6IFsuFq2UVErCz4I6tq/K1SZFPTOtr/KBHBeksoGMGw==;DefaultEndpointsProtocol=http;BlobEndpoint=;QueueEndpoint=;TableEndpoint=;",

view raw


hosted with ❤ by GitHub

We now go to the Function code and define the name of the setting to use by adding a StorageAccount annotation to the class, function, or parameter. We’ll add the annotation it at the class level. The new C# file now looks like this:

using System;
using System.IO;
using System.Threading.Tasks;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Extensions.Http;
using Microsoft.AspNetCore.Http;
using Microsoft.Extensions.Logging;
using Newtonsoft.Json;
namespace Vainolo.AzureFunctionsTutorial.Part4
public class UserData
public string PartitionKey { get; set; }
public string RowKey { get; set; }
public string Text { get; set; }
public static class SavingUserInput
public static IActionResult Run(
[HttpTrigger(AuthorizationLevel.Anonymous, "get", "post", Route = null)] HttpRequest req,
[Table("UserData")] out UserData ud,
ILogger log)
log.LogInformation("C# HTTP trigger function processed a request.");
string text = req.Query["text"];
string requestBody = new StreamReader(req.Body).ReadToEnd();
dynamic data = JsonConvert.DeserializeObject(requestBody);
text = text ?? data?.text;
ud = new UserData
PartitionKey = "1",
RowKey = DateTime.Now.Ticks.ToString(),
Text = text
return text != null
? (ActionResult)new OkObjectResult($"Hello, {text}")
: new BadRequestObjectResult("Please pass some text on the query string or in the request body");

view raw


hosted with ❤ by GitHub

Hit F5 in VSCode and make sure that everything is still working by invoking the function with some query parameter and checking that the value appears in the local storage emulator.

Now let’s deploy the function to Azure. Open the Azure Functions activity in VSCode and click on the “Deploy to Function App” button:


This will open in the command palette a list of the Function apps that are in the Azure subscriptions we have configured:


For this tutorial we’ll create a new app called “VainoloAzureFunctionsTutorial” instead of reusing an existing one. Follow the prompts to create/use a resource group, and storage account like in the first tutorial. After answer all the questions the deployment process begins:


And after a couple of seconds/minutes the process finishes:


We can go the azure portal to see the new Function App. One important thing to notice is that the code is now read-only in the portal, with a good explanation on why this is the case.


So there is no mixing and matching between editing in the Azure portal and editing on an IDE. Good to know.

Let’s test the function by navigating to its URL… we get an HTTP ERROR 500! That is because we forgot one thing – remember we defined a special value for the storage account used by the Function? We need to update its value in the Azure App application settings with a connection string to a real account in Azure. So let’s navigate back to the Function App in the portal and click on “Application Settings”:


Find the section named “Application settings” (did you know that naming things is one of the biggest problems in software engineering?) and add a new setting named MyStorageAccount with the connection string to the Azure storage as the setting value:


Let’s go back to the top of the page click “Save”, and try again to execute the function again:


Works! And with the storage explorer we can confirm that the function is using the right storage and writing to it.

Now that we have a local environment ready that is also easy to deploy, we can start investigating all the functionality that is available in Azure Functions. Until then, happy coding!

Next Tutorial: Azure Functions – Part 6: HTTP and Timer Triggers

Published inProgramming

Be First to Comment

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.