studio - porta azure

Cómo ejecutar la aplicación Azure Function en un puerto diferente en Visual Studio

Question

Estoy configurando el puerto de host local en local.setting.json. Referir el documento de Microsoft https://docs.microsoft.com/en-us/azure/azure-functions/functions-run-local

El archivo se ve a continuación.

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

Cuando ejecuto / depuro la solución, VS aún aloja la aplicación en el puerto predeterminado (7071)

He revisado el directorio bin, el archivo local.setting.json está llegando allí con la configuración anterior. Ejecución de la CLI de Azure Fucntion ( func host start ) desde el directorio bin, lea correctamente el número de puerto.

Parece que VS no está utilizando el puerto "LocalHttpPort ". ¿Hay algún otro cambio requerido en la configuración. Tengo Visual Studio 2017 Preview (2)

Answer 1

Respuesta correcta para el proyecto .NET Core 2.0 / .NET Standard 2.0 Azure Functions en Visual Studio 2017 cuando haya instalado Azure Functions Core Tools 2.x Runtime a través de NPM

Seguí la respuesta de @ahmelsayed y, en particular, los comentarios de @ ravinsp para los comentarios de .net core 2.0. Aunque fueron muy útiles y me pusieron en el camino correcto, no funcionaron para mí sin una modificación crucial y no intuitiva, así que estoy agregando una respuesta nueva.

TL; DR;

Si ha usado NPM para instalar Azure Functions Core Tools 2.x Runtime, es posible que deba configurar Project / Properties / Debug / Application Arguments en:

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

La respuesta larga sigue ...

Mi configuración

Durante este ejercicio, mi configuración está completamente actualizada (en el momento de escribir esto) y de la siguiente manera:

• Visual Studio 2017 Professional: 15.6.2
• Funciones de Azure y herramientas de trabajo web: 15.0.40215.0
• Windows 10 10.0.16299 Build 16299

• Las herramientas principales de las funciones de Azure (instaladas según los documentos Desarrollar y ejecutar las funciones de Azure localmente desde Microsoft) reportan (en Git Bash):

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

Fwiw, la pestaña de configuración de la aplicación Funciones para esta aplicación en Azure dice:

Runtime version: 2.0.11587.0 (beta)

Mi problema

Cuando ejecuto mi proyecto de funciones (sin argumentos de aplicación), obtengo esto en la salida de la consola:

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

Esto en sí mismo puede no ser un problema, pero estoy teniendo problemas molestos "funciona en mi máquina, falla al publicar en Azure", así que quiero asegurarme de que la ejecución local esté usando las mismas funciones en tiempo de ejecución como azure (es decir, 2.0.11587.0 que, según las notas de configuración anteriores, es / debería ser, ¿verdad?)

Entonces, basado en las instrucciones de @ ravinsp, ejecuto un hallazgo en mi disco C para localizar Azure.Functions.Cli.dll: solo hay uno, y está ubicado en C:/Users/<myuserid>/AppData/Local/Azure.Functions.V2.Cli/2.0.1-beta/Azure.Functions.Cli.dll que parece muy consistente con la respuesta de @ ravinsp.

Entonces, agrego los siguientes argumentos de Project / Properties / Debug / 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

luego sí obtengo el puerto 8888, pero el tiempo de ejecución, extrañamente, aún se informa como 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/

Solución

Dado que la función en ejecución de Git Bash según lo anterior mostró un tiempo de ejecución de 2.0.11587.0, probé which func que devolvió /c/Users/<myuserid>/AppData/Roaming/npm/func . Hice un gato con él y en una larga historia, pude ver que en última instancia estaba ejecutando C:/Users/<myuserid>/AppData/Roaming/npm/node_modules/azure-functions-core-tools/bin/func.exe , y que en ese mismo directorio había un func.dll .

Entonces, probé los siguientes argumentos de Project / Properties / Debug / Application:

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

entonces finalmente consigo ...

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

y, de manera crucial, el error que estaba recibiendo al publicar en Azure comienza a manifestarse localmente también.

Ok, ahora que los tiempos de ejecución están sincronizados, es hora de arreglar mi error real :)

Answer 2

Estoy usando la versión 1.2.1 de la CLI y la siguiente configuración de Application arguments en Project Properties -> Debug funcionó para mí.

host start --port 7074 --nodeDebugPort 5860

Answer 3

La línea de comandos tiene prioridad sobre el archivo de configuración, el problema es que VS pasa un puerto explícito en la línea de comandos.

trabajar alrededor es ir a través de project -> properties -> Debug , luego, bajo los Application arguments tome el control de los Application arguments . puede escribir host start --pause-on-error

Editar desde ravinsp:

Actualización para el proyecto de función .Net Core 2.0:

Los argumentos de línea de comando que tienes que pasar son diferentes. Tienes que pasar en el camino a una dll en frente. De esta manera: %AppData%/../Local/Azure.Functions.V2.Cli/2.0.1-beta.22/Azure.Functions.Cli.dll host start --pause-on-error Puede verlo por sí mismo ejecutando la función en Visual Studio y usando el explorador de procesos para ver los argumentos de la línea de comandos al proceso dotnet.exe.

editar: una palabra

Answer 4

Utilicé la respuesta aceptada, pero aun así recibí un error cuando el puerto del depurador intentaba vincularse porque ambas aplicaciones de función intentaban vincularse a 5858.

Para evitarlo, agregué un atributo más a los argumentos de la aplicación en la configuración del proyecto y mis argumentos se parecen a esto:

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