| Info |
|---|
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
Choose the worker mode : isolated worker vs in-process
...
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.
...
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.
...
Publish to Azure : Develop Azure Functions using Visual Studio | Microsoft Learn
...
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.
Remote Debugging
Azure Functions: how to debug remotely in production – Stefano Demiliani