Skip to end of metadata
Go to start of metadata

You are viewing an old version of this content. View the current version.

Compare with Current View Version History

« Previous Version 9 Current »

Applied to Visual Studio Development : we’d rather run the In-process model (function code runs in the same process as the Functions host process, using .NET runtime) than the Isolated worker process (function code runs in a separate .NET worker process.).

Develop Azure Functions using Visual Studio | Microsoft Learn

  1. Choose the worker mode : isolated worker vs in-process

  1. Work with app settings locally

During local development, these settings are instead added to the Values collection in the local.settings.json file. The local.settings.json file also stores settings used by local development tools.

Visual Studio doesn't automatically upload the settings in local.settings.json when you publish the project. To make sure that these settings also exist in your function app in Azure, upload them after you publish your project.

Remark : The values in a ConnectionStrings collection are never published.

  1. Configure project for local dev

The Functions runtime uses an Azure Storage account internally. For all trigger types other than HTTP and webhooks, set the Values.AzureWebJobsStorage key to a valid Azure Storage account connection string.

To use the emulator, set the value of AzureWebJobsStorage to UseDevelopmentStorage=true. Change this setting to an actual storage account connection string before deployment.

  1. Add Function to project

Creation will generate the Run code in C#.

using System;
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Host;
using Microsoft.Extensions.Logging;

namespace FunctionApp1
{
    public static class Function1
    {
        [FunctionName("QueueTriggerCSharp")]
        public static void Run([QueueTrigger("myqueue-items", Connection = "QueueStorage")]string myQueueItem, ILogger log)
        {
            log.LogInformation($"C# Queue trigger function processed: {myQueueItem}");
        }
    }
}
  1. Add bindings

Install-Package Microsoft.Azure.WebJobs.Extensions.<BINDING_TYPE> -Version <TARGET_VERSION>

Replace <BINDING_TYPE> with the name specific to the binding extension and <TARGET_VERSION> with a specific version of the package, such as 3.0.0-beta5.

Finally, add the appropriate binding attribute to the method signature.

public static class SimpleExampleWithOutput
{
    [FunctionName("CopyQueueMessage")]
    public static void Run(
        [QueueTrigger("myqueue-items-source", Connection = "AzureWebJobsStorage")] string myQueueItem, 
        [Queue("myqueue-items-destination", Connection = "AzureWebJobsStorage")] out string myQueueItemCopy,ILogger log)
    {
        log.LogInformation($"CopyQueueMessage function processed: {myQueueItem}");
        myQueueItemCopy = myQueueItem;
    }
}
  1. Run functions locally

When you press F5 to debug a Functions project, the local Functions host (func.exe) starts to listen on a local port (usually 7071).

  1. Publish to Azure : Develop Azure Functions using Visual Studio | Microsoft Learn

  1. Manage Function app settings

Visual Studio doesn't upload these settings automatically when you publish the project. Any settings you add in the local.settings.json you must also add to the function app in Azure.

By default, the local.settings.json file is not checked into source control. This means that if you clone a local Functions project from source control, the project doesn't have a local.settings.json file. In this case, you need to manually create the local.settings.json file in the project root so that the Application settings dialog works as expected.

  1. Remote Debugging

Azure Functions: how to debug remotely in production – Stefano Demiliani

  • No labels