Comment exécuter une application Azure Function sur un port différent dans Visual Studio

Question

Je définis le port hôte local dans local.setting.json. En référence à la documentation de Microsoft https://docs.microsoft.com/fr-fr/azure/azure-functions/functions-run-local

Le fichier ressemble à ceci

{
  "IsEncrypted": false,
  "Values": {
    "AzureWebJobsStorage": "",
    "AzureWebJobsDashboard": ""   
  },
  "Host": {
    "LocalHttpPort": 7073
  }
}

Lorsque j'exécute/débogue la solution, VS héberge toujours l'application sur le port par défaut (7071)

J'ai vérifié le répertoire bin, le fichier local.setting.json est bien présent avec les paramètres ci-dessus. L'exécution de Azure Function CLI (func host start) depuis le répertoire bin lit correctement le numéro de port.

Il semble que VS n'utilise pas le port "LocalHttpPort". Y a-t-il d'autres changements nécessaires dans les paramètres. J'ai Visual Studio 2017 Preview (2)

Answer 1

Je suis en train d'utiliser la version CLI 1.2.1, et le paramètre suivant Arguments de l'application dans Propriétés du projet -> Déboguer a fonctionné pour moi.

host start --port 7074 --nodeDebugPort 5860

Answer 2

Mise à jour: Si vous cherchez simplement à modifier le port, vous n'avez pas à le définir à travers le fichier spécifié dans la question. Consultez la réponse de Thuc Nguyen

Réponse originale:

la ligne de commande prend le pas sur le fichier de paramètres, le problème est que VS passe un port explicite sur la ligne de commande.

la solution de contournement est de passer par projet -> propriétés -> Débogage, puis sous Arguments de l'application prendre le contrôle des arguments. vous pouvez taper host start --pause-on-error

Modification de ravinsp:

Mise à jour pour le projet de fonction .Net Core 2.0:

Les arguments de ligne de commande que vous devez passer sont différents. Vous devez passer en premier le chemin d'accès vers un fichier dll. Comme ceci : %AppData%\..\Local\Azure.Functions.V2.Cli\2.0.1-beta.22\Azure.Functions.Cli.dll host start --pause-on-error Vous pouvez le voir par vous-même en exécutant la fonction dans Visual Studio et en utilisant l'explorateur de processus pour voir les arguments de ligne de commande du processus dotnet.exe.

éditer: un mot

Answer 3

Met à jour les propriétés du projet -> Debug sur le suivant

host start --port 7073 --pause-on-error

Answer 4

Réponse correcte pour le projet Azure Functions .NET Core 2.0 / .NET Standard 2.0 dans Visual Studio 2017 lorsque vous avez installé Azure Functions Core Tools 2.x Runtime via NPM

J'ai suivi la réponse de @ahmelsayed et en particulier, les commentaires de @ravinsp pour les commentaires sur .net core 2.0. Bien que très utiles et m'ayant mis sur la bonne voie, cela n'a pas fonctionné pour moi sans une modification cruciale et non intuitive, donc j'ajoute une nouvelle réponse.

TL;DR;

Si vous avez utilisé NPM pour installer Azure Functions Core Tools 2.x Runtime, alors vous devrez peut-être définir Project/Properties/Debug/Application Arguments sur :

C:\Users\\AppData\Roaming\npm\node_modules\azure-functions-core-tools\bin\func.dll host start --port 8888 --pause-on-error

La réponse longue suit...

Ma configuration

Pendant cet exercice, ma configuration est entièrement à jour (au moment de l'écriture) et comme suit :

• Visual Studio 2017 Professional : 15.6.2
• Outils Azure Functions and Web Job : 15.0.40215.0
• Windows 10 10.0.16299 Build 16299

• Azure Functions Core Tools (installé selon le document Develop and run Azure functions locally de Microsoft) affiche (dans Git Bash) :

  me@MYDESKTOP ~ $ func Azure Functions Core Tools (2.0.1-beta.24) Function Runtime Version: 2.0.11587.0

Pour ce que ça vaut, l'onglet Paramètres de l'application Functions pour cette application Functions sur Azure indique :

Version de runtime : 2.0.11587.0 (beta)

Mon problème

Lorsque j'exécute mon projet de fonctions (sans arguments d'application), j'obtiens ceci dans la sortie de la console :

[17/03/2018 21:06:38] Starting Host (HostId=MYMACHINE, Version=2.0.11353.0, ProcessId=
Listening on http://localhost:7071/

Cela en soi pourrait ne pas être un problème, mais j'ai des problèmes ennuyeux de type "ça marche sur ma machine, ça échoue lors de la publication sur Azure", donc je veux m'assurer que l'exécution locale utilise le même runtime de fonctions qu'Azure (c'est-à-dire 2.0.11587.0 qui, selon les notes de configuration ci-dessus, est/devrait être bon, n'est-ce pas ?)

Ainsi, sur la base des instructions de @ravinsp, j'ai exécuté une recherche sur mon lecteur C pour localiser Azure.Functions.Cli.dll - il n'y en a qu'un seul, et il se trouve à C:\Users\\AppData\Local\Azure.Functions.V2.Cli\2.0.1-beta\Azure.Functions.Cli.dll ce qui est très cohérent avec la réponse de @ravinsp.

J'ai donc ajouté les arguments d'application suivants dans Projet/Propriétés/Débogage :

C:\Users\\AppData\Local\Azure.Functions.V2.Cli\2.0.1-beta\Azure.Functions.Cli.dll host start --port 8888 --pause-on-error

puis j'ai bien obtenu le port 8888, mais le runtime est bizarrement toujours rapporté comme 2.0.11353.

[17/03/2018 21:13:02] Starting Host (HostId=MYMACHINE, Version=2.0.11353.0, ProcessId=
Listening on http://localhost:8888/

Solution

Étant donné que l'exécution de func depuis Git Bash comme indiqué ci-dessus a montré un runtime de 2.0.11587.0, j'ai essayé which func qui a renvoyé /c/Users//AppData/Roaming/npm/func . J'ai fait un cat dessus et en résumé j'ai pu voir qu'il exécutait en fin de compte C:\Users\\AppData\Roaming\npm\node_modules\azure-functions-core-tools\bin\func.exe, et que dans ce même répertoire il y avait un func.dll.

J'ai donc essayé les arguments d'application suivants dans Projet/Propriétés/Débogage :

C:\Users\\AppData\Roaming\npm\node_modules\azure-functions-core-tools\bin\func.dll host start --port 8888 --pause-on-error

puis enfin j'obtiens...

[17/03/2018 21:16:29] Starting Host (HostId=MYMACHINE, Version=2.0.11587.0, ProcessId=
Listening on http://localhost:8888/

et, de manière cruciale, l'erreur que je recevais lors de la publication sur Azure commence également à se manifester localement.

Bon, maintenant que les runtimes sont tous synchronisés, il est temps de fixer mon bug réel :)

Answer 5

J'ai utilisé la réponse acceptée mais j'ai quand même eu une erreur lorsque le port du débogueur essayait de se lier car les deux applications fonctionnaient en essayant de se lier à 5858.

Pour contourner cela, j'ai ajouté un autre attribut aux arguments de l'application dans les paramètres du projet et mes arguments ressemblent à ceci:

host start --pause-on-error --nodeDebugPort 5860