Partager via

Développer Azure Functions localement à l’aide de Core Tools

  • Article

Azure Functions Core Tools vous permet de développer et de tester vos fonctions sur votre ordinateur local. Lorsque vous êtes prêt, vous pouvez également utiliser Core Tools pour déployer votre projet de code sur Azure et utiliser les paramètres de l’application.

Vous consultez la version C# de cet article. Veillez à sélectionner votre langage de programmation Azure Functions préféré en haut de l'article.

Si vous souhaitez commencer immédiatement, suivez l’article de démarrage rapide Core Tools.

Vous consultez la version Java de cet article. Veillez à sélectionner votre langage de programmation Azure Functions préféré en haut de l'article.

Si vous souhaitez commencer immédiatement, suivez l’article de démarrage rapide Core Tools.

Vous consultez la version JavaScript de cet article. Veillez à sélectionner votre langage de programmation Azure Functions préféré en haut de l'article.

Si vous souhaitez commencer immédiatement, suivez l’article de démarrage rapide Core Tools.

Vous consultez la version PowerShell de cet article. Veillez à sélectionner votre langage de programmation Azure Functions préféré en haut de l'article.

Si vous souhaitez commencer immédiatement, suivez l’article de démarrage rapide Core Tools.

Vous consultez la version Python de cet article. Veillez à sélectionner votre langage de programmation Azure Functions préféré en haut de l'article.

Si vous souhaitez commencer immédiatement, suivez l’article de démarrage rapide Core Tools.

Vous consultez la version TypeScript de cet article. Veillez à sélectionner votre langage de programmation Azure Functions préféré en haut de l'article.

Si vous souhaitez commencer immédiatement, suivez l’article de démarrage rapide Core Tools.

Installer Azure Functions Core Tools

La méthode recommandée pour installer Core Tools dépend du système d’exploitation de votre ordinateur de développement local.

Les étapes suivantes utilisent un programme d’installation Windows (MSI) pour installer Core Tools v4.x. Pour plus d’informations sur les autres programmes d’installation basés sur des packages, consultez le fichier Lisezmoi des outils principaux.

Téléchargez et exécutez le programme d’installation de Core Tools, selon votre version de Windows :

Si vous avez précédemment utilisé Windows installer (MSI) pour installer Core Tools sur Windows, vous devez désinstaller l’ancienne version de la fonction Ajout/suppression de programmes avant d’installer la dernière version.

Pour obtenir de l’aide sur les problèmes liés aux versions, consultez Versions de Core Tools.

Créer votre projet local

Important

Pour Python, vous devez exécuter les commandes Core Tools dans un environnement virtuel. Pour plus d’informations, consultez Démarrage rapide : Créer une fonction Python dans Azure à partir de la ligne de commande.

Dans la fenêtre de terminal ou à partir d’une invite de commandes, exécutez la commande suivante pour créer un projet dans le MyProjFolder dossier :

func init MyProjFolder --worker-runtime dotnet-isolated

Par défaut, cette commande crée un projet qui s’exécute in-process avec l’hôte Functions sur l’actuelle version du support à long terme (LTS) de .NET Core. Vous pouvez utiliser l’option --target-framework pour cibler une version spécifique prise en charge de .NET, y compris .NET Framework. Pour plus d’informations, consultez les informations de référence sur func init.

Pour une comparaison entre les deux modèles de processus .NET, consultez l’article comparaison des modes de processus.

Java utilise un archétype Maven pour créer le projet Functions local, ainsi que votre première fonction déclenchée par HTTP. Plutôt que d’utiliser func init et func new, suivez les étapes décrites dans le démarrage rapide sur la ligne de commande.

func init MyProjFolder --worker-runtime javascript --model V4

Cette commande crée un projet JavaScript qui utilise la version du modèle de programmation souhaitée.

func init MyProjFolder --worker-runtime typescript --model V4

Cette commande crée un projet JavaScript qui utilise la version du modèle de programmation souhaitée.

func init MyProjFolder --worker-runtime powershell

func init MyProjFolder --worker-runtime python --model V2

Cette commande crée un projet Python qui utilise la version du modèle de programmation souhaitée.

Quand vous exécutez func init sans l’option --worker-runtime, vous êtes invité à choisir la langue de votre projet. Pour en savoir plus sur les options disponibles pour la func init commande, consultez la func init référence.

Créer une fonction

Pour ajouter une fonction à votre projet, exécutez la func new commande à l’aide de l’option --template permettant de sélectionner votre modèle de déclencheur. L'exemple suivant crée un déclencheur HTTP nommé MyHttpTrigger :

func new --template "Http Trigger" --name MyHttpTrigger

Cet exemple crée un déclencheur de file d’attente de stockage nommé MyQueueTrigger :

func new --template "Azure Queue Storage Trigger" --name MyQueueTrigger

Vous devez tenir compte des points suivants lors de l'ajout de nouveaux objets :

  • Quand vous exécutez func new sans l’option --template, vous êtes invité à choisir un modèle.

  • Utilisez la commande func templates list pour afficher la liste complète des modèles disponibles pour chaque langage pris en charge.

  • Lorsque vous ajoutez un déclencheur qui se connecte à un service, vous devez également ajouter un paramètre d’application qui référence une chaîne de connexion ou une identité managée au fichier local.settings.json. L’utilisation des paramètres d’application de cette façon vous évite d’avoir à incorporer des informations d’identification dans votre code. Pour plus d’informations, consultez Utiliser des paramètres d’application localement.

  • Core Tools ajoute également une référence à l’extension de liaison spécifique à votre projet C#.

Pour en savoir plus sur les options disponibles pour la func new commande, consultez la func new référence.

Ajoutez une liaison à votre fonction

Azure Functions fournit un ensemble de liaisons d’entrée et de sortie spécifiques au service, qui facilitent la connexion de votre fonction à d’autres services Azure sans avoir à utiliser les SDK clients spécifiques au service. Pour plus d’informations, consultez Concepts des déclencheurs et liaisons Azure Functions.

Pour ajouter une liaison d’entrée ou de sortie à une fonction existante, vous devez mettre à jour manuellement la définition de fonction.

L’exemple suivant montre la définition de la fonction après l’ajout d’une liaison de sortie de Stockage File d’attente à une fonction déclenchée par HTTP :

Parce qu’une fonction déclenchée par HTTP renvoie également une réponse HTTP, la fonction renvoie un objet MultiResponse, qui représente à la fois la sortie HTTP et la sortie de file d’attente.

[Function("HttpExample")]
public static MultiResponse Run([HttpTrigger(AuthorizationLevel.Function, "get", "post")] HttpRequest req,
    FunctionContext executionContext)
{

Voici un exemple de définition de l’objet MultiResponse qui comprend la liaison de sortie :

public class MultiResponse
{
    [QueueOutput("outqueue",Connection = "AzureWebJobsStorage")]
    public string[] Messages { get; set; }
    public IActionResult HttpResponse { get; set; }
}

Lorsque vous appliquez cet exemple à votre propre projet, vous risquez de devoir remplacer HttpRequest par HttpRequestData et IActionResult par HttpResponseData, selon que vous utilisez l'Intégration ASP.NET Core ou non.

Ces messages sont envoyés à la file d’attente lorsque la fonction se termine. La manière dont vous définissez la liaison de sortie dépend de votre modèle de processus. Pour plus d’informations, notamment concernant des liens vers des exemples de code de liaison auxquels vous pouvez vous référer, consultez Ajouter des liaisons à une fonction.

@FunctionName("HttpExample")
public HttpResponseMessage run(
        @HttpTrigger(name = "req", methods = {HttpMethod.GET, HttpMethod.POST}, authLevel = AuthorizationLevel.ANONYMOUS) 
        HttpRequestMessage<Optional<String>> request, 
        @QueueOutput(name = "msg", queueName = "outqueue", 
        connection = "AzureWebJobsStorage") OutputBinding<String> msg, 
        final ExecutionContext context) {

Pour plus d’informations, notamment concernant des liens vers des exemples de code de liaison auxquels vous pouvez vous référer, consultez Ajouter des liaisons à une fonction.

Exemple de liaison pour un modèle v4 Node.js non encore disponible.

La manière dont vous définissez la liaison de sortie dépend de la version de votre modèle Node.js. Pour plus d’informations, notamment concernant des liens vers des exemples de code de liaison auxquels vous pouvez vous référer, consultez Ajouter des liaisons à une fonction.

$outputMsg = $name
Push-OutputBinding -name msg -Value $outputMsg

Pour plus d’informations, notamment concernant des liens vers des exemples de code de liaison auxquels vous pouvez vous référer, consultez Ajouter des liaisons à une fonction.

@app.route(route="HttpExample")
@app.queue_output(arg_name="msg", queue_name="outqueue", connection="AzureWebJobsStorage")
def HttpExample(req: func.HttpRequest, msg: func.Out [func.QueueMessage]) -> func.HttpResponse:
    logging.info('Python HTTP trigger function processed a request.')

La manière dont vous définissez la liaison de sortie dépend de la version de votre modèle Python. Pour plus d’informations, notamment concernant des liens vers des exemples de code de liaison auxquels vous pouvez vous référer, consultez Ajouter des liaisons à une fonction.

Exemple de liaison pour un modèle v4 Node.js non encore disponible.

La manière dont vous définissez la liaison de sortie dépend de la version de votre modèle Node.js. Pour plus d’informations, notamment concernant des liens vers des exemples de code de liaison auxquels vous pouvez vous référer, consultez Ajouter des liaisons à une fonction.

Les considérations suivantes s’appliquent lors de l’ajout de liaisons à une fonction :

  • Lorsque vous ajoutez des liaisons qui se connectent à un service, vous devez également ajouter un paramètre d’application qui référence une chaîne de connexion ou une identité managée au fichier local.settings.json. Pour plus d’informations, consultez Utiliser des paramètres d’application localement.
  • Lorsque vous ajoutez une liaison prise en charge, l’extension doit déjà être installée lorsque votre application utilise une offre groupée d’extensions. Pour plus d’informations, consultez Bundles d’extension.
  • Lorsque vous ajoutez une liaison qui nécessite une nouvelle extension de liaison, vous devez également ajouter une référence à cette extension de liaison spécifique dans votre projet C#.

Pour plus d’informations, notamment concernant des liens vers des exemples de code de liaison auxquels vous pouvez vous référer, consultez Ajouter des liaisons à une fonction.

Pour plus d’informations, notamment concernant des liens vers des exemples de code de liaison auxquels vous pouvez vous référer, consultez Ajouter des liaisons à une fonction.

Pour plus d’informations, notamment concernant des liens vers des exemples de code de liaison auxquels vous pouvez vous référer, consultez Ajouter des liaisons à une fonction.

Pour plus d’informations, notamment concernant des liens vers des exemples de code de liaison auxquels vous pouvez vous référer, consultez Ajouter des liaisons à une fonction.

Pour plus d’informations, notamment concernant des liens vers des exemples de code de liaison auxquels vous pouvez vous référer, consultez Ajouter des liaisons à une fonction.

Pour plus d’informations, notamment concernant des liens vers des exemples de code de liaison auxquels vous pouvez vous référer, consultez Ajouter des liaisons à une fonction.

Démarrer le runtime Functions

Avant de pouvoir exécuter ou déboguer les fonctions de votre projet, vous devez démarrer l’hôte Functions à partir du répertoire racine de votre projet. L’hôte active les déclencheurs pour toutes les fonctions du projet. Utilisez cette commande pour démarrer le runtime local :

mvn clean package 
mvn azure-functions:run

func start

func start

npm install
npm start

Cette commande doit être exécutée dans un environnement virtuel.

Lorsque l’hôte Functions démarre, il génère une liste de fonctions dans le projet, y compris les URL de toutes les fonctions déclenchées par HTTP, comme dans cet exemple :

Found the following functions:
Host.Functions.MyHttpTrigger

Job host started
Http Function MyHttpTrigger: http://localhost:7071/api/MyHttpTrigger

Gardez à l’esprit les considérations suivantes lors de l’exécution de vos fonctions localement :

  • Par défaut, l’autorisation n’est pas appliquée localement pour les points de terminaison HTTP. Cela signifie que toutes les demandes HTTP locales sont gérées de manière authLevel = "anonymous". Pour plus d’informations, consultez Niveau d’autorisation. Vous pouvez utiliser l’option pour exiger une --enableAuth autorisation lors de l’exécution locale. Pour plus d’informations, consultez func start

  • Vous pouvez utiliser l’émulateur Azurite local lorsque vous exécutez localement des fonctions qui nécessitent un accès au service de stockage Azure (Stockage File d’attente, Stockage Blob et Stockage Table), sans avoir à vous connecter à ces services dans Azure. Lorsque vous utilisez l’émulation locale, veillez à démarrer Azurite avant de démarrer l’hôte local (func.exe). Pour plus d’informations, consultez Émulation du stockage local.

  • Vous pouvez utiliser l’émulation Azurite locale pour répondre aux besoins de stockage du worker Python v2.

  • Vous pouvez déclencher des fonctions non HTTP localement sans vous connecter à un service en direct. Pour plus d’informations, consultez Exécuter des fonctions localement.

  • Lorsque vous incluez vos informations de connexion Application Insights dans le fichier local.settings.json, les données de journal local sont écrites dans le instance Application Insights spécifique. Pour séparer les données de télémétrie locales des données de production, envisagez d’utiliser une instance Application Insights distincte pour le développement et le test.

  • Lorsque vous utilisez la version 1.x de Core Tools, utilisez plutôt la func host start commande pour démarrer le runtime local.

Exécuter une fonction locale

Une fois votre hôte Functions local (func.exe) en cours d’exécution, vous pouvez maintenant déclencher des fonctions individuelles pour exécuter et déboguer votre code de fonction. La façon dont vous exécutez une fonction individuelle dépend de son type de déclencheur.

Remarque

Les exemples de cette rubrique utilisent l’outil cURL pour envoyer des requêtes HTTP à partir du terminal ou d’une invite de commandes. Vous pouvez utiliser un outil de votre choix pour envoyer les requêtes HTTP au serveur local. L’outil cURL est disponible par défaut sur les systèmes Linux et Windows 10 Build 17063 et versions ultérieures. Avec les anciennes versions de Windows, vous devez d’abord télécharger et installer l’outil cURL.

Les déclencheurs HTTP sont démarrés en envoyant une requête HTTP au point de terminaison et au port locaux, comme indiqué dans la sortie func.exe, qui a le format général suivant :

http://localhost:<PORT>/api/<FUNCTION_NAME>

Dans ce modèle d’URL, <FUNCTION_NAME> est le nom de la fonction ou de la route et <PORT> est le port local sur lequel func.exe écoute.

La commande cURL suivante déclenche la fonction de démarrage rapide MyHttpTrigger à partir d’une demande GET avec le paramètre namepassé dans la chaîne de requête :

curl --get http://localhost:7071/api/MyHttpTrigger?name=Azure%20Rocks

Cet exemple est la même fonction appelée à partir d’un nom de transmission de requête POST dans le corps de la requête, affiché pour l’interpréteur de commandes Bash et la ligne de commande Windows :

curl --request POST http://localhost:7071/api/MyHttpTrigger --data '{"name":"Azure Rocks"}'

curl --request POST http://localhost:7071/api/MyHttpTrigger --data "{'name':'Azure Rocks'}"

Les considérations suivantes s’appliquent lors de l’appel de points de terminaison HTTP localement :

  • Notez que vous pouvez passer des requêtes GET depuis un navigateur en passant des données dans la chaîne de requêtes. Pour toutes les autres méthodes HTTP, vous devez utiliser un outil de test HTTP qui sécurise également vos données. Pour découvrir plus d’informations, consultez Outils de test HTTP.

  • Vérifiez que vous utilisez le même nom de serveur et le même port que celui où l’hôte Functions écoute. Vous voyez cela dans la sortie générée lors du démarrage de l’hôte Fonctions. Vous pouvez appeler cette URL en utilisant n’importe quelle méthode HTTP prise en charge par le déclencheur.

Publier sur Azure

Les Azure Functions Core Tools prennent en charge trois types de déploiement :

Type de déploiement Commande Description
Fichiers projet func azure functionapp publish Déploie les fichiers de projet de fonction directement dans votre application de fonction à l’aide d’un déploiement zip.
Azure Container Apps func azurecontainerapps deploy Déploie une application de fonction conteneurisée dans un environnement Azure Container Apps.
Cluster Kubernetes func kubernetes deploy Déploie votre application de fonction Linux en tant que conteneur docker client sur un cluster Kubernetes.

Vous devez avoir installé localement Azure CLI ou Azure PowerShell pour pouvoir publier sur Azure à partir de Core Tools. Par défaut, Core Tools utilise ces outils pour s’authentifier auprès de votre compte Azure.

Si vous n’avez pas installé ces outils, vous devez obtenir un jeton d’accès valide à utiliser pendant le déploiement. Vous pouvez présenter un jeton d’accès à l’aide de l’option --access-token dans les commandes de déploiement.

Déployer des fichiers de projet

Pour publier votre code local dans une application de fonction sur Azure, utilisez la commande func azure functionapp publish :

func azure functionapp publish <FunctionAppName>

Cette commande publie des fichiers projet du répertoire actif en <FunctionAppName> tant que package de déploiement .zip. Si le projet nécessite une compilation, elle est effectuée à distance pendant le déploiement.

Java utilise Maven pour publier votre projet local sur Azure au lieu de Core Tools. Utilisez la commande Maven suivante pour publier votre projet sur Azure :

mvn azure-functions:deploy

Lorsque vous exécutez cette commande, les ressources Azure sont créées pendant le déploiement initial en fonction des paramètres de votre fichier pom.xml. Pour plus d’informations, consultez Déployer le projet de fonction sur Azure.

Les remarques suivantes s’appliquent à ce type de déploiement :

  • La publication remplace les fichiers existants dans le déploiement de l’application de fonction distante.

  • Vous devez avoir déjà créé une application de fonction dans votre abonnement Azure. Core Tools déploie votre code de projet sur cette ressource d’application de fonction. Pour découvrir comment créer une application de fonction à partir de l’invite de commandes ou d’une fenêtre de terminal à l’aide d’Azure CLI ou d’Azure PowerShell, consultez Créer une application de fonction pour une exécution serverless. Vous pouvez également créer ces ressources dans le Portail Azure. Vous obtiendrez une erreur si vous tentez de publier sur une application <FunctionAppName> qui n’existe pas dans votre abonnement.

  • Un dossier de projet peut contenir des fichiers et des répertoires spécifiques à une langue qui ne doivent pas être publiés. Les éléments exclus sont listés dans un fichier .funcignore situé dans le dossier racine du projet.

  • Votre projet est déployé de sorte qu’il s’exécute à partir du package de déploiement. Pour désactiver ce mode de déploiement recommandé, utilisez l’option --nozip.

  • Une compilation distante est effectuée sur les projets compilés. Ceci peut être contrôlé par l’option --no-build.

  • Utilisez l’option --publish-local-settings pour créer automatiquement des paramètres d’application dans votre application de fonction selon les valeurs dans le fichier local.settings.json.

  • Pour publier sur un emplacement nommé spécifique dans votre application de fonction, utilisez --slotl’option.

Déployer des conteneurs

Core Tools vous permet de déployer votre application de fonction en conteneur dans des environnements Azure Container Apps managés et des clusters Kubernetes que vous gérez.

Utilisez la commande suivante func azurecontainerapps deploy pour déployer une image conteneur existante dans un environnement Container Apps :

func azurecontainerapps deploy --name <APP_NAME> --environment <ENVIRONMENT_NAME> --storage-account <STORAGE_CONNECTION> --resource-group <RESOURCE_GROUP> --image-name <IMAGE_NAME> [--registry-password] [--registry-server] [--registry-username]

Lorsque vous déployez dans un environnement Azure Container Apps, les considérations suivantes s’appliquent :

  • L'environnement et le compte de stockage doivent déjà exister. La chaîne de connexion du compte de stockage que vous fournissez est utilisée par l’application de fonction déployée.

  • Vous n’avez pas besoin de créer une ressource d’application de fonction distincte lors du déploiement sur Container Apps.

  • Les chaînes de connexion de stockage et les autres informations de connexion au service sont des secrets importants. Assurez-vous de stocker en sécurité les fichiers de script à l’aide de func azurecontainerapps deploy et de ne pas les stocker dans un contrôle de code source accessible publiquement. Vous pouvez chiffrer le fichier local.settings.json pour plus de sécurité.

Pour plus d’informations, consultez Hébergement Azure Container Apps d’Azure Functions.

Utiliser les paramètres d’application localement

Lors de l’exécution dans une application de fonction dans Azure, les paramètres requis par vos fonctions sont stockés de manière sécurisée dans les paramètres de l’application. Lors du développement local, ces paramètres sont, à la place, ajoutés à la collection Values dans le fichier local.settings.json. Le fichier local.settings.json stocke également les paramètres utilisés par les outils de développement locaux.

Les éléments de la collection Values dans le fichier local.settings.json de votre projet sont destinés à refléter des éléments des paramètres d’application de votre application de fonction dans Azure.

Les considérations suivantes s’appliquent lors de l’utilisation du fichier de paramètres local :

  • Étant donné que le fichier local.settings.json peut contenir des secrets, tels que des chaînes de connexion, vous ne devez jamais le stocker dans un référentiel distant. Core Tools vous aide à chiffrer ce fichier de paramètres local pour une sécurité améliorée. Pour en savoir plus, voir Fichier de paramètres locaux. Vous pouvez chiffrer le fichier local.settings.json pour plus de sécurité.

  • Par défaut, ces paramètres ne sont pas migrés automatiquement lorsque le projet est publié dans Azure. Utilisez l’option --publish-local-settings lors de la publication pour vous assurer que ces paramètres sont ajoutés à l’application de fonction dans Azure. Les valeurs de la section ConnectionStrings ne sont jamais publiées. Vous pouvez également charger des paramètres à partir du fichier local.settings.json à tout moment.

  • Vous pouvez télécharger et remplacer les paramètres de votre fichier local.settings.json avec les paramètres de votre application de fonction dans Azure. Pour plus d’informations, consultez la section Télécharger les paramètres d’application.

  • Ces valeurs de paramètres d’application de fonction peuvent aussi être lues dans votre code en tant que variables d’environnement. Pour en savoir plus, voir Variables d’environnement.
  • Ces valeurs de paramètres d’application de fonction peuvent aussi être lues dans votre code en tant que variables d’environnement. Pour en savoir plus, voir Variables d’environnement.
  • Ces valeurs de paramètres d’application de fonction peuvent aussi être lues dans votre code en tant que variables d’environnement. Pour en savoir plus, voir Variables d’environnement.
  • Ces valeurs de paramètres d’application de fonction peuvent aussi être lues dans votre code en tant que variables d’environnement. Pour en savoir plus, voir Variables d’environnement.
  • Ces valeurs de paramètres d’application de fonction peuvent aussi être lues dans votre code en tant que variables d’environnement. Pour en savoir plus, voir Variables d’environnement.

Télécharger les paramètres de l’application

À la racine du projet, utilisez la commande suivante pour télécharger tous les paramètres de l’application à partir de l’application myfunctionapp12345 dans Azure :

func azure functionapp fetch-app-settings myfunctionapp12345

Cette commande remplace tous les paramètres existants dans le fichier local.settings.json par des valeurs d’Azure. Lorsqu’ils ne sont pas déjà présents, de nouveaux éléments sont ajoutés à la collection. Pour plus d'informations, consultez la commande func azure functionapp fetch-app-settings.

Télécharger une chaîne de connexion de stockage

Core Tools facilite également l’obtention de la chaîne de connexion de n’importe quel compte de stockage auquel vous avez accès. À la racine du projet, utilisez une des commandes suivantes pour télécharger la chaîne de connexion à partir d’Azure mystorage12345.

func azure storage fetch-connection-string mystorage12345

Cette commande ajoute un paramètre nommé mystorage12345_STORAGE au fichier local.settings.json, qui contient la chaîne de connexion du mystorage12345 compte. Pour plus d'informations, consultez la commandefunc azure storage fetch-connection-string .

Pour améliorer la sécurité pendant le développement, envisagez de chiffrer le fichier local.settings.json.

Charger des paramètres locaux dans Azure

Lorsque vous publiez vos fichiers projet sur Azure sans utiliser l’option --publish-local-settings , les paramètres du fichier local.settings.json ne sont pas définis dans votre application de fonction. Vous pouvez toujours réexécuter avec func azure functionapp publish l’option --publish-settings-only de charger uniquement les paramètres sans republier les fichiers projet.

L’exemple suivant charge uniquement les paramètres de la Values collection dans le fichier local.settings.json vers l’application de fonction dans Azure nommée myfunctionapp12345:

func azure functionapp publish myfunctionapp12345 --publish-settings-only

Chiffrer le fichier de paramètres locaux

Pour améliorer la sécurité des chaînes de connexion et d’autres données précieuses dans vos paramètres locaux, Core Tools vous permet de chiffrer le fichier local.settings.json. Lorsque ce fichier est chiffré, le runtime déchiffre automatiquement les paramètres si nécessaire, de la même façon qu’il le fait avec le paramètre d’application dans Azure. Vous pouvez également déchiffrer un fichier chiffré localement pour utiliser les paramètres.

Utilisez la commande suivante pour chiffrer le fichier de paramètres locaux pour le projet :

func settings encrypt

Utilisez la commande suivante pour déchiffrer un paramètre local chiffré afin de pouvoir l’utiliser :

func settings decrypt

Lorsque le fichier de paramètres est chiffré et déchiffré, le paramètre du IsEncrypted fichier est également mis à jour.

Configurer des extensions de liaison

Les déclencheurs de fonctions et les liaisons sont mis en œuvre sous la forme de paquets d'extension .NET (NuGet). Pour pouvoir utiliser une extension de liaison spécifique, cette extension doit être installée dans le projet.

Cette section ne s’applique pas à la version 1.x du runtime Functions. Dans la version 1.x, les liaisons prises en charge étaient incluses dans l’extension du produit principale.

Pour les projets de bibliothèque de classes C#, ajoutez des références aux packages NuGet spécifiques pour les extensions de liaison requises par vos fonctions. Le projet de script C# (.csx) doit utiliser des bundles d’extension.

Functions fournit des bundles d’extensions pour faciliter l’utilisation des extensions de liaison dans votre projet. Les bundles d’extensions, qui sont avec version et définis dans le fichier host.json, installent un ensemble complet de packages d’extensions de liaison compatibles pour votre application. Les bundles d’extensions de votre fichier host.json doivent déjà être activés. Si, pour une raison quelconque, vous devez ajouter ou mettre à jour le bundle d’extensions dans le fichier host.json, consultez Bundles d’extensions.

Si vous devez utiliser une extension de liaison ou une version d’extension qui n’est pas dans un bundle pris en charge, vous devez installer manuellement les extensions. Pour de tels scénarios rares, consultez la commandefunc extensions install.

Versions de Core Tools

Les versions principales de Azure Functions Core Tools sont liées à des versions principales spécifiques du runtime Azure Functions. Par exemple, la version 4.x de Core Tools prend en charge la version 4.x du runtime Functions. Il s’agit de la version recommandée du runtime Functions et des Core Tools. Vous pouvez déterminer la dernière version de Core Tools dans le dépôt Azure Functions Core Tools.

À partir de la version 4.0.6517 de Core Tools, les projets de modèles in-process doivent référencer Microsoft.NET.Sdk.Functions version 4.5.0 ou ultérieure. Si une version antérieure est utilisée, la commande func start génère une erreur.

Exécutez la commande suivante pour déterminer la version de votre installation actuelle de Core Tools :

func --version

Sauf indication contraire, les exemples de cet article concernent la version 4.x.

Les considérations suivantes s’appliquent aux installations de Core Tools :

  • Vous ne pouvez installer qu’une seule version de Core Tools sur un ordinateur donné.

  • Lors de la mise à niveau vers la dernière version de Core Tools, vous devez utiliser la même méthode que celle utilisée pour l’installation d’origine afin d’effectuer la mise à niveau. Par exemple, si vous avez utilisé une msi sur Windows, désinstallez la MSI actuelle et installez la dernière. Ou si vous avez utilisé npm, réexécutez le npm install command.

  • Les versions 2.x et 3.x de Core Tools ont été utilisées avec les versions 2.x et 3.x du runtime Functions, qui ont atteint leur date limite de prise en charge. Pour plus d’informations, consultez Vue d’ensemble des versions du runtime Azure Functions.

  • La version 1.x de Core Tools est requise lors de l’utilisation de la version 1.x du runtime Functions, qui est toujours prise en charge. Cette version de Core Tools ne peut être exécutée que localement sur des ordinateurs Windows. Si vous exécutez actuellement sur la version 1.x, vous devez envisager de migrer votre application vers la version 4.x dès aujourd’hui.

Étapes suivantes

Découvrez comment développer, tester et publier des fonctions Azure à l’aide d’Azure Functions Core Tools. Azure Functions Core Tools est disponible en open source et hébergé sur GitHub. Pour enregistrer un bogue ou une demande de fonctionnalité, créez un problème GitHub.