Migrating Azure Functions from portal to Visual Studio

Azure Functions are a great addition to the whole family of Azure resources. Azure Functions are my number one workhorses. The fact that I can execute code, triggered by ‘whatever’, gives me so much power for a fraction of the costs.

And the beauty of it is, you can write those nifty pieces of code directly into the Azure portal using nothing more than a browser.

But as always, with great power comes great responsibilities!

The code I write in the portal is not supporting any version control. And I cannot debug this code.

Although I am up-and-running with Azure Functions in a few hours, I want to debug and put my code in version control too!

Luckily, I can create Azure Function in Visual Studio too. And this gives me the power of debugging and version control. But what are the drawbacks?

Let’s explore om how to migrate your Azure Function, written in the portal, into Visual Studio.

Note: the first drawback is that, after migrating, you will lose the ability to edit the code in the portal, You will not even see the code read-only. What you deploy is a DLL which is hosted in the Azure Function App. My personal opinion is that starting in the portal and migrating to Visual Studio is the natural thing to do. And having version control and debugging abilities will always win in a professional environment.

So you start with your carefully written Azure Function in the portal.

I have written a simple function which receives telemetry from an IoTHub:

And the telemetry is coming in, shown in the log windows:

So let’s check out how to migrate this function to Visual Studio.

The Visual Studio extension

Before we get started with Azure Functions in Visual Studio, we need to install the “Azure Functions and Web Jobs tools” extension:

You can download it here.

So start a new project/solution using this template.

A new project is created which represents a ‘Function App’. So there is no Azure Function yet.

Before we add our own Azure Function, we first check out if we can actually run the Function App locally.

Yes, the Function App is hosted on your development machine using a version (1.0.7. ) of the Azure Functions CLI tools. Just start the new project and see what happens. It is likely you get the following message:

Just accept this dialog and the newest version of the Azure Functions CLI tools is installed. Right after that, you will be asked to open up the firewall for the communication between the Function App running locally and resources in your Cloud subscription. Please accept that one too.

Now you will see a Dos Box appear:

The yellow message can be confirmed, we have not added a function yet. But we now know we are capable to run one or two!

So close this dialog and let’s add a Function.

Adding an Azure Function

Add a new item to the project in Visual Studio. Select the Azure Function:

This will be the actual function. But as you know there are a lot of different triggers, so we select the Event Trigger using the next dialog:

For me, this dialog is a bit confusing. There are twee textboxes, what do I have to fill in?

If we compare this to the Azure Function dialog for our function in the Azure portal, it becomes a bit more clear.

We will deploy this function to in the Azure portal. And we want to receive data from an EventHub (an IoTHub in this case). So we have to provide the ‘connection key’ of the Function App application setting which contains (or will contain) the actual connection string to the EventHub.

In the Azure Function App, a connection ‘AfMigrate-ih_events_IOTHUB’ is already available. So we take that one for ‘Connection’. And we can leave the ‘Path’ for what is it (we are referencing an IoTHub, not an EventHub).

A new Azure Function is created:

using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Host;
using Microsoft.Azure.WebJobs.ServiceBus;

namespace MigrationFunctionApp
{
    public static class IoTHubDebugFunction
    {
        [FunctionName("IoTHubDebugFunction")]
        public static void Run([EventHubTrigger("samples-workitems", 
                                  Connection = "AfMigrate-ih_events_IOTHUB")]string myEventHubMessage, 
                               TraceWriter log)
        {
            log.Info($"C# Event Hub trigger function processed a message: {myEventHubMessage}");
        }
    }
}

This is the part where you should migrate your code from the portal Azure Function into this Azure Function.

Fixing the settings

Right now, the function will NOT run. We still have to fix some things.

Storage accounts connection strings

Azure Function Apps make use of storage. We need to add storage account keys to your local Function App too.

Look at the file named ‘local.settings.json’:

{
    "IsEncrypted": false,
    "Values": {
        "AzureWebJobsStorage": "",
        "AzureWebJobsDashboard": ""
    }
}

As you can see, the ‘AzureWebJobsStorage’ and the ‘AzureWebJobsDashboard’ have to be filled in. Compare these with the Application Settings of your Function app in the Azure portal:

Do you see the resemblance?

Just copy the two values and paste them into the local settings.

Now the Azure Function App is able to run functions locally.

IoTHub connection string

Remember the connection string ‘AfMigrate-ih_events_IOTHUB’ which was filled in with your function?

The value is stored in the Application Settings of the Function app in the portal.

We have to add that connection string to the local settings too:

{
  "IsEncrypted": false,
  "Values": {
    "AzureWebJobsStorage": "DefaultEndpointsProtocol=https;AccountName=afmigratefastorage;AccountKey=[a key]",
    "AzureWebJobsDashboard": "DefaultEndpointsProtocol=https;AccountName=afmigratefastorage;AccountKey=[a key]",
    "AfMigrate-ih_events_IOTHUB": "Endpoint=sb://ihsuproddbres051dednamespace.servicebus.windows.net/;SharedAccessKeyName=iothubowner;SharedAccessKey=[another key];EntityPath=iothub-ehub-afmigrate-287237-80a4731c58"
  }
}

Now we have everything in place for debugging the function!

Let’s start debugging

So put a breakpoint on that code and start your app:

As you can see, your host is running.

Now send some telemetry to your IoTHub and see how the breakpoint is activated:

This is very promising. You can actually debug your Azure Function with live data!

Now hit F5 so the function is executed. You can see this in the output:

The only thing left is deployment.

Deploying the Azure Function App

Stop the app and open the ‘Publish’ dialog (right-click the project):

Make sure you check the ‘Select Existing’ before you press Publish, we want to merge our new Function App with the one already existing.

In the next dialog, you will have to select your actual Function App and press OK:

Visual Studio will now create a Publish profile for reuse. So press Publish to start the deploy:

And once this deployment is finished, check the Azure portal for the updated Azure Functions App (refresh the list of functions if needed):

Yes, the local azure function is now deployed to the cloud (1). And we see the telemetry coming in, as expected (2). And yes, this Azure Function is neither editable readable (3). It is deployed as DLL (4).

But there is a side effect, the whole Function App is now read-only (5)!

How to fix the read-only Azure Function App

The complete Function App is blocked, no changes can be made anymore:

It’s not possible to temporarily disable functions, an option I often use.

Luckily, Microsoft will fix this issue soon. For now, you can fix this yourself by making a little change using the App Service Editor (go to the Platform Features in the Function App):

A new page is opened in the browser, showing the raw files on ‘disk’ for the Azure Function App. Check out the ‘function.json’ in our newly added function. Look for the ‘GeneratedBy’ row in the JSON:

Just remove this single line. The file will be saved automatically.

And now, our Azure Functions written in the cloud are editable again. And we can disable/enable functions:

Conclusion

Migrating your Azure Functions to a new or existing Azure Functions App is made simple. You just have to dare to let loose.

 

Advertenties