web-dev-qa-db-fra.com

Comment exécuter l'application Azure Function sur un autre port de Visual Studio

Je configure le port de l'hôte local dans local.setting.json. Référence de la documentation Microsoft https://docs.Microsoft.com/en-us/Azure/azure-functions/functions-run-local

Le fichier ressemble à ci-dessous

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

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

J'ai vérifié le répertoire bin, le local.setting.json le fichier y arrive avec les paramètres ci-dessus. En cours d'exécution CLI Azure Fucntion (func Host start) du répertoire bin lit correctement le numéro de port.

On dirait que VS n'utilise pas le "LocalHttpPort "port. Des modifications supplémentaires sont-elles nécessaires dans les paramètres? J'ai Visual Studio 2017 Preview (2)

azurevisual-studio-2017azure-functions
38
Ramkumar Singh

la ligne de commande a priorité sur le fichier de paramètres, le problème est que VS transmet un port explicite sur la ligne de commande.

contourner est de passer par project -> properties -> Debug, puis sous Application arguments prendre le contrôle des arguments. vous pouvez taper Host start --pause-on-error

enter image description here

Edit from ravinsp:

Mise à jour du projet de fonction .Net Core 2.0:

Les arguments de ligne de commande que vous devez transmettre sont différents. Vous devez passer dans le chemin vers une DLL en face. Comme ça: %AppData%\..\Local\Azure.Functions.V2.Cli\2.0.1-beta.22\Azure.Functions.Cli.dll Host start --pause-on-error Vous pouvez le constater en exécutant la fonction dans Visual Studio et en utilisant l'explorateur de processus pour afficher les arguments de ligne de commande du processus dotnet.exe.

modifier: un mot

66
ahmelsayed

J'utilise la version 1.2.1 de la CLI et la suivante Application arguments réglage dans Project Properties -> Debug a travaillé pour moi.

Host start --port 7074 --nodeDebugPort 5860

29
Thuc Nguyen

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

J'ai suivi la réponse de @ ahmelsayed et en particulier les commentaires de @ ravinsp pour les commentaires .net core 2.0. Bien que très utiles et me mettant sur la bonne voie, ils ne fonctionnaient pas pour moi sans une modification cruciale et non intuitive, j'ajoute donc une nouvelle réponse.

TL; DR;

Si vous avez utilisé NPM pour installer le runtime Azure Functions Core Tools 2.x, vous devrez peut-être définir les arguments Projet/Propriétés/Débogage/Application sur:

C:\Users\<myuserid>\AppData\Roaming\npm\node_modules\Azure-functions-core-tools\bin\func.dll Host start --port 8888 --pause-on-error

Réponse longue suit ...

Ma configuration

Au cours de cet exercice, ma configuration est entièrement à jour (au moment de la rédaction) et se présente comme suit:

  • Visual Studio 2017 Professional: 15.6.2
  • Fonctions Azure et outils de travail Web: 15.0.40215.0
  • Windows 10 10.0.16299 Build 16299

  • Azure Functions Core Tools (installé conformément aux rapports développement et exécution de fonctions Azure localement document de Microsoft) (dans Git Bash):

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

par exemple, l’onglet Fonctions de l’application Fonctions de cette application Fonctions sur Azure se lit comme suit:

Runtime version: 2.0.11587.0 (beta)

Mon problème

Quand j'exécute mon projet de fonctions (sans argument d'application), je reçois ceci dans la sortie de la console:

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

Cela en soi n’est peut-être pas un problème, mais je deviens ennuyeux. Des problèmes de type "fonctionne sur ma machine, échoue lors de la publication au format Azure". Je souhaite donc m'assurer que l'exécution locale utilise les mêmes fonctions que Azure 2.0.11587.0 qui, conformément aux notes de configuration ci-dessus, est/devrait être, non?)

Donc, en suivant les instructions de @ ravinsp, je lance une recherche sur mon lecteur C pour localiser Azure.Functions.Cli.dll - il n'y en a qu'un, et il se trouve à C:\Users\<myuserid>\AppData\Local\Azure.Functions.V2.Cli\2.0.1-beta\Azure.Functions.Cli.dll, Ce qui semble être tout à fait compatible avec la réponse de @ ravinsp.

J'ajoute donc les arguments suivants: Projet/Propriétés/Débogage/Application:

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

puis j'obtiens le port 8888, mais le temps d'exécution est bizarrement toujours étant signalé comme étant 2.0.11353.

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

Solution

Étant donné que fonctionner avec Git Bash comme indiqué ci-dessus a montré une exécution de 2.0.11587.0, j'ai essayé which func, Qui a renvoyé /c/Users/<myuserid>/AppData/Roaming/npm/func. J'ai fait un chat dessus et une longue histoire, j'ai pu voir que finalement il tournait C:\Users\<myuserid>\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 suivants: Projet/Propriétés/Débogage/Application:

C:\Users\<myuserid>\AppData\Roaming\npm\node_modules\Azure-functions-core-tools\bin\func.dll Host start --port 8888 --pause-on-error

puis finalement je reçois ...

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

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

Ok, maintenant les runtimes sont tous synchronisés, il est temps de s'attaquer à mon bug :)

7
ubienewbie

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 fonctionnelles essayaient de se lier à 5858.

Pour contourner ce problème, j'ai ajouté un attribut supplémentaire aux arguments de l'application dans les paramètres du projet et mes arguments se présentent comme suit:

Host start --pause-on-error --nodeDebugPort 5860
5
jlafay