Local.setting.jsonでローカルホストポートを設定しています。 Microsoftドキュメントの参照 https://docs.Microsoft.com/en-us/Azure/azure-functions/functions-run-local
ファイルは次のようになります
{
"IsEncrypted": false,
"Values": {
"AzureWebJobsStorage": "",
"AzureWebJobsDashboard": ""
},
"Host": {
"LocalHttpPort": 7073
}
}
ソリューションを実行/デバッグするとき、VSは引き続きデフォルトポートでアプリをホストします(7071)
Binディレクトリを確認しましたが、local.setting.json
ファイルは上記の設定でそこに到達しています。 binディレクトリからAzure Fucntion CLI(func Host start
)を実行すると、ポート番号が正しく読み取られます。
VSは"LocalHttpPort
"ポートを使用していないようです。設定に他の変更が必要ですか。VisualStudio 2017 Preview(2)があります
コマンドラインは設定ファイルよりも優先されます。問題は、VSがコマンドラインで明示的なポートを渡すことです。
回避するには、_project -> properties -> Debug
_を通過し、_Application arguments
_の下で引数を制御します。 _Host start --pause-on-error
_と入力できます
ravinspから編集:
。Net Core 2.0関数プロジェクトの更新:
渡す必要があるコマンドライン引数は異なります。前のDLLへのパスを渡す必要があります。このように:_%AppData%\..\Local\Azure.Functions.V2.Cli\2.0.1-beta.22\Azure.Functions.Cli.dll Host start --pause-on-error
_ Visual Studioで関数を実行し、プロセスエクスプローラーを使用してdotnet.exeプロセスへのコマンドライン引数を確認することにより、自分で確認できます。
編集:Word
CLIバージョン1.2.1を使用していますが、Application arguments
の次のProject Properties -> Debug
設定が機能しました。
Host start --port 7074 --nodeDebugPort 5860
NPM経由でAzure Functions Core Tools 2.x Runtimeをインストールした場合のVisual Studio 2017での.NET Core 2.0/.NET Standard 2.0 Azure Functionsプロジェクトの正しい回答
@ahmelsayedの回答、特に.net core 2.0コメントに対する@ravinspのコメントに従いました。非常に有用であり、私を正しい方向に導いてくれましたが、決定的で非直感的な修正なしでは機能しませんでしたので、新しい答えを追加します。
NPMを使用してAzure Functions Core Tools 2.x Runtimeをインストールした場合、Project/Properties/Debug/Application Argumentsを次のように設定する必要がある場合があります。
_C:\Users\<myuserid>\AppData\Roaming\npm\node_modules\Azure-functions-core-tools\bin\func.dll Host start --port 8888 --pause-on-error
_
長い答えが続きます...
この演習中、私のセットアップは(執筆時点で)完全に最新であり、次のとおりです。
Azure Functionsコアツール( Azure機能をローカルで開発および実行する Microsoftのドキュメントに従ってインストール)レポート(Git Bash内):
me@MYDESKTOP ~ $ func <snip/> Azure Functions Core Tools (2.0.1-beta.24) Function Runtime Version: 2.0.11587.0
fwiw、Azure上のこのFunctionsアプリのFunctions App設定タブには以下が表示されます:
_Runtime version: 2.0.11587.0 (beta)
_
関数プロジェクトを(アプリケーション引数なしで)実行すると、コンソール出力に次のように表示されます。
_[17/03/2018 21:06:38] Starting Host (HostId=MYMACHINE, Version=2.0.11353.0, ProcessId=<snip/>
Listening on http://localhost:7071/
_
これ自体は問題ではないかもしれませんが、迷惑な「私のマシンで動作し、Azureに公開すると失敗する」というタイプの問題が発生するため、ローカル実行でAzureと同じ関数ランタイムを使用していることを確認したい2.0.11587.0、上記のセットアップノートによると、そうである/そうあるべきでしょう?)
したがって、@ ravinspの指示に基づいて、Cドライブでfindを実行してAzure.Functions.Cli.dllを見つけます。これは1つだけで、_C:\Users\<myuserid>\AppData\Local\Azure.Functions.V2.Cli\2.0.1-beta\Azure.Functions.Cli.dll
_にあります。これは@ravinspの答えと非常に一致しています。
そこで、次の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
_
その後、ポート8888を取得しますが、ランタイムは妙にstill2.0.11353として報告されます。
_[17/03/2018 21:13:02] Starting Host (HostId=MYMACHINE, Version=2.0.11353.0, ProcessId=<snip/>
Listening on http://localhost:8888/
_
上記のようにGit Bashからfuncを実行すると、2.0.11587.0のランタイムが示されることを考えて、_which func
_を返して_/c/Users/<myuserid>/AppData/Roaming/npm/func
_を返しました。私はそれに猫をしました、そして、長い話は短く、最終的にそれは_C:\Users\<myuserid>\AppData\Roaming\npm\node_modules\Azure-functions-core-tools\bin\func.exe
_を実行しており、その同じディレクトリに_func.dll
_があったことがわかりました。
そこで、次のProject/Properties/Debug/Application Argumentsを試しました。
_C:\Users\<myuserid>\AppData\Roaming\npm\node_modules\Azure-functions-core-tools\bin\func.dll Host start --port 8888 --pause-on-error
_
そして最後に私は得る...
_[17/03/2018 21:16:29] Starting Host (HostId=MYMACHINE, Version=2.0.11587.0, ProcessId=<snip/>
Listening on http://localhost:8888/
_
そして、決定的に重要なのは、Azureへの発行時に発生していたエラーが、ローカルでも顕在化することです。
さて、今ではすべてのランタイムが同期しました。実際のバグの修正に取り掛かる時間です。
受け入れられた答えを使用しましたが、両方の機能アプリが5858にバインドしようとしたため、デバッガーポートがバインドしようとしたときにエラーが発生しました。
それを回避するために、プロジェクト設定のアプリケーション引数にもう1つの属性を追加しました。引数は次のようになります。
Host start --pause-on-error --nodeDebugPort 5860