@jsakamoto

< 2018年 12月 ( 2 ) > この月の画像一覧

2018年 12月 28日

ASP.NET Core Web アプリの開発中、開発機の外から接続できるようにする

背景

Visual Studio や dotnet CLI + お好みのエディタなどを使っての、ASP.NET Core Web アプリを開発中の話。

開発中の ASP.NET Core Web アプリを、エミュレータではない実機のモバイル端末 (iOS や Android など) から接続して動作確認したいことはよくある。

その実現方法としては、例えば ngrok を使ってローカル開発中の ASP.NET Core Web アプリをインターネット上に晒し、そこにモバイル端末実機のブラウザから接続しにいくのもアリではある。

とはいえ、開発途上のものを、一時的とはいえインターネット上に晒すのは危険が伴う。

そもそも通信経路が長くなる上、ngrok の処理性能やモバイル回線の速度・帯域にも大きく左右されて、すばやい動作確認、トライ&エラーの繰り返しがやりにくい。

ということで、顧客に見てもらうなどの理由がない限りは、開発機と同一ローカルエリアネットワークに Wi-Fi 接続したモバイル端末実機から、同ネットワーク経由で接続するのが普通かと思う。

ただ、ASP.NET Core Web アプリの既定のプロジェクト構成では、開発中の ASP.NET Core Web アプリはローカルホスト (127.0.0.0/24, ::1) でしか待ち受けしていない。

なので、当該開発機の外部からは、そのままでは接続できない。

そこで、プロジェクト構成を変更する必要がある。

Visual Studio 上からの設定変更

Visual Studio で開発中の場合、お勧めの方法は以下のとおり。

まず実行形態を、IIS Express によるホスティングではなく、プロジェクト実行 (いわゆる、"dotnet run" 実行) を選択しておく。
Visual Studio 上で当該 ASP.NET Core Web アプリプロジェクトのプロパティ表示を開き、[デバッグ] カテゴリを開く。
この画面で、[ブラウザを起動] の設定で、「https://localhost:5001」というような絶対 URL を明記。
続けて [環境変数] のところに、[名前] が「ASPNETCORE_URLS」である項目を追加、[値] には「https://*:5001;http://*:5000」というように、ホスト名を「*」で指定した待ち受け URL を、複数ある場合はセミコロン (;) 区切りで設定する。
[アプリケーション URL] の欄は空欄にする。

以上で Ctrl+F5 で実行などすれば、当該開発機の外部からも、この ASP.NET Core Web アプリが接続を受理、応答を返すようになる。

なお、上記で行なった設定内容は、Properties フォルダ内にある、「launchSettings.json」というファイル名の JSON ファイルにその設定内容が保存されている。

例えば次のとおり。

{
  "iisSettings": ...,
  "profiles": {
    "IIS Express": ...,
    "WebApplication1": {
      "commandName": "Project",
      "launchBrowser": true,
      "launchUrl": "https://localhost:5001",
      "environmentVariables": {
        "ASPNETCORE_URLS": "https://*:5001;http://*:5000",
        "ASPNETCORE_ENVIRONMENT": "Development"
      },
      "applicationUrl": ""
    }
  }
}

"dotnet run" で実行する場合

dotnet CLI を用いた "dotnet run" による実行でも、上記 launchSettings.json に基づいて ASP.NET Core Web アプリを立ち上げる。

なので、 dotnet CLI を使っての開発中の場合でも、上記のように launchSettings.json を作成・記述しておけばそれだけでよい。

また、先の説明では端折ってしまったが、設定のキモは、環境変数 ASPNETCORE_URLS の設定である。

標準のプロジェクトテンプレートで作成された ASP.NET Core Web アプリであれば、環境変数 ASPNETCORE_URLS を見て、そこに設定されている待ち受け URL を採用するようにできているのだ。

先で説明している launchSettings.json の内容も、要するに環境変数 ASPNETCORE_URLS を設定しているわけである。

なので、launchSettings.json がなくても、コマンドプロンプト (ターミナル) で下記のように環境変数 ASPNETCORE_URLS を設定してから dotnet run を実行することでも OK だ。

> rem 以下は Windows OS のコマンドプロンプトでの例
> cd \path\to\yourprojectdir
> set ASPNETCORE_URLS=https://*:5001;http://*:5000
> dotnet run

※ "dotnet run" を実行したコマンドプロンプト (ターミナル) 内で環境変数 ASPNETCORE_URLS を設定しつつ、 launchSettings.json でも環境変数 ASPNETCORE_URLS を設定していた場合は、 launchSettings.json の設定のほうが優先する。

補足: アプリケーション URL を設定すればよいのでは?

ホストアドレスに「0.0.0.0」を指定

実は、Visual Studio での設定時、環境変数 ASPNETCORE_URLS ではなく、[アプリケーション URL] に、「https://0.0.0.0:5001;http://0.0.0.0:5000」というように、ホストアドレスを「0.0.0.0」とした待ち受け URL を設定することでも、外部からの接続を受け付けるようになる。

但し上図の設定だと、IPv4 アドレスでのみ待ち受けすることになるので注意。

すなわち、開発機上のブラウザでアドレスバーに「https://localhost:5001」や「http://127.0.0.1:5001」と入力するぶんには当該 Web アプリにアクセスできるものの、IPv6 アドレスである「https://[::1]:5001」を入力すると、接続不能となるのである。

まぁ、「開発中の Web アプリをモバイル端末実機で確認」という用途であれば、IPv4 アドレスのみでの待ち受けで十分事足りる気もする。

なので、実際上は、上図のようなアプリケーション URL 設定による方式で十分かもしれない。

もっとも、IPv6 アドレスでも待ち受けさせることももちろん可能で、その場合はホストアドレスとして「[::]」を指定すればよい。

例えば「https://0.0.0.0:5001;http://0.0.0.0:5000;https://[::]:5001;http://[::]:5000」というようにアプリケーション URL を設定すれば、IPv4 でも IPv6 でも、外部からつながるようになる。

ただ、ちょっと設定が長すぎではある。

アプリケーション URL 設定で、ホストアドレスに「*」を指定しないのはなぜ?

アプリケーション URL 設定に、（環境変数 ASPNETCORE_URLS での設定と同じように）「https://+:5001」とか「https://*:5001」のように、ホストアドレスとして「+」や「*」を指定すれば、 IPv4 と IPv6 の設定を併記しなくて済むのでは? とも思われた。

試しにやってみたところ、 launchSettings.json を直接編集して "applicationUrl" に "https://*:5001" を設定し、dotnet run で実行するぶんにはうまくいった。

しかし launchSettings.json がこの状態で、当該プロジェクトを Visual Studio で開き、Ctrl+F5 実行すると、「Invalid URI: The hostname could not be parsed.」というエラーメッセージボックスを表示して起動してくれない。

また、Visual Studio 上からは、アプリケーション URL に + や * をホストアドレスとした URL を設定すると入力検証エラーになって設定できない。

加えて、先のとおり launchSettings.json を直接編集した状態でプロジェクトのプロパティ画面から [デバッグ] セクションを開いてしまうと、場合によっては入力検証エラーに阻まれ、プロパティ画面を閉じたり保存したりができなくなり、どうにもならない "詰んだ" 状況に陥ってしまう。

...これらのことから、環境変数 ASPNETCORE_URLS に待ち受け URL を設定する方式がいちばん一貫性もあり、自分のお勧めの方法と結論づけている。

補足: [ブラウザを起動] の URL を明記するのはなぜ?

dotnet run で実行するぶんには、 launchSettings.json の "launchUrl" は無くても (あるいは空文字であっても) なんら問題ない。

本稿作成時点では、dotnet run では、ブラウザの起動までは行なわないからだ。

しかし Visual Studio 上で開発・実行してブラウザも開きたいというケースでは、[ブラウザを起動] の URL を明記しておかないと厄介なことになる。

まず、環境変数 ASPNETCORE_URLS に待ち受け URL を設定する方式の場合、Ctrl+F5 実行すると、Web アプリのプロセスは起動するものの、Visual Studio がエラーメッセージボックスを出してブラウザ起動に至らない。

また、アプリケーション URL にホストアドレス 0.0.0.0 で設定する方式の場合、Ctrl+F5 実行すると、ブラウザは起動するものの、「https://0.0.0.0:5001」という URL を開いてしまってアクセスできない結果となる。

なので、少なくとも Visual Studio 上での実行でブラウザも同時に開きたいケースでは、ちゃんと [ブラウザを起動] の URL を明記しておくに越したことはない。

補足: IIS Express での実行時について書かれてないけど?

需要と余力があれば調べて試して本ブログに投稿する...かもしれない。

▲ by developer-adjust | 2018-12-28 22:37 | .NET | Comments(0)

2018年 12月 09日

はじめての C# からの Selenium、そして NET Core ではエラーになる場合

Selenium とは

ここで言う Selenium とは、Web ブラウザをプログラミング言語から自動操縦することを可能にするソフトウェアだ。

本稿では、C# から Selenium の .NET バインディングを使用して Web ブラウザを操縦できるようになるまでの手順を紹介する。

なお、Selenium は、Firefox や Google Chrome などなど、各種 Web ブラウザを操縦可能だが、話を簡単にするためにとりあえず今回は Google Chrome を操縦することとする。

.NET Framework + Visual Studio の場合

まずは Visual Studio を起動し、プロジェクトの新規作成から適当な C# プロジェクトを作成する。

ここではコンソールアプリとしたが、必要に応じて WinForms などの GUI プロジェクトや単体テストプロジェクトでも構わない。

続けて、NuGet パッケージマネージャーから、以下の 2 つのNuGet パッケージをこの C# プロジェクトに追加する。

ちなみに、Firefox を操縦したければ Selenium.WebDriver.GeckoDriver NuGet パッケージをプロジェクトに追加すればよい。

あとはブラウザを操縦する C# プログラムを記述すればよい。

下記は Chrome で Bing 検索を開き、"Selenium WebDriver" という語句を検索実行する例だ。

using OpenQA.Selenium.Chrome;
...
using (var driver = new ChromeDriver())
{
  driver.Navigate().GoToUrl("https://www.bing.com/");

  driver
    .FindElementById("sb_form_q")
    .SendKeys("Selenium WebDriver");

  driver
    .FindElementById("sb_form_go")
    .Click();

  Console.WriteLine("OK");
  Console.ReadKey(intercept: true);
}

以上でビルド & 実行 (Visual Studio 上で Ctrl + F5)　すれば、そのとおり実行される。

以上である。

上記手順にあるとおり、ブラウザを Selenium 経由で操縦するための通訳を行なうプログラム、"WebDriver" も NuGet パッケージで配布されていて、これを参照する格好となっている。

例えば Google Chrome 用の WebDriver は (Windows OS の場合) "chromedriver.exe" というプログラムファイルである。

この "chromedriver.exe" が NuGet パッケージ参照によって、ビルド先の出力フォルダに自動でコピーされるのだ。

このため、

「このプロジェクトを git clone してビルド & 実行するには、事前に自分で WebDriver プログラムをダウンロードして、Path の通った適当なフォルダに解凍しておいてね」

みたいな事前の環境整備が不要である。

.NET Core + dotnet CLI の場合

.NET Core がインストールされている環境で、dotent コマンドを使い、同じようにやってみることにしよう。

コンソール (ターミナル) を開き、まずは適当な作業フォルダを作成しよう。

カレントディレクトリをこうして作成した作業フォルダの中に移動し、以下のコマンドで .NET Core なコンソールアプリの C# プロジェクトを新規作成する。

> dotnet new console

続けて、以下のコマンドで、Selenium.WebDriver、及び Selenium.WebDriver.ChromeDriver の両 NuGet パッケージの参照を追加する。

> dotnet add package Selenium.WebDriver
> dotnet add package Selenium.WebDriver.ChromeDriver

これでプロジェクトができたので、適当なテキストエディタを使って C# プログラムを同じように書きあげればよい。

ビルドと実行はコンソール (ターミナル) に戻って「dotnet run」コマンドを実行だ。

dotnet run

これで Google Chrome が起動...

と思ったら起動せずに下記エラーになってしまった。

Unhandled Exception: OpenQA.Selenium.DriverServiceNotFoundException: The chromedriver.exe file does not exist in the current directory or in a directory on the PATH environment variable.

"chromedriver.exe" が見つからない!?

だがしかし、.NET Framework 版のときと同じように、"chromedriver.exe" はたしかに出力フォルダにコピーされている。

.NET Framework 版と同じように作成したのに、一体何故!?

Selennium が WebDriver を探す場所

実は Selenium が WebDriver ファイルを探す場所は、環境変数 PATH が指すフォルダ群の他には、Selenium の .NET アセンブリファイルである WebDriver.dll が配置されているフォルダが対象となっている。

いっぽうで、.NET Core では NuGet パッケージ参照しているアセンブリファイル (.dll) は、出力フォルダにコピーされないのが既定の仕様である。

出力フォルダにコピーされない代わりに、%HOMEPATH%\.nuget\packages フォルダ以下に共有して保存されているアセンブリファイルが実行時にプロセスに読み込まれる仕組みだ。

そのため、.NET Core 版プロジェクトでは、Selenium の WebDriver.dll アセンブリがある場所 = (プロジェクトの出力フォルダではなく) %HOMEPATH%\.nuget\packages\...\selenium.webdriver\... みたいな場所で、"chromedriver.exe" を探してしまい、しかしもちろん、そんなところに "chromedriver.exe" は存在しないから件のエラーになってしまうという顛末である。

回避策 A - 出力フォルダにコピーしちゃう

C# プロジェクトファイル .csproj 内に指定を追記することで、.NET Core なプロジェクトであっても、参照している NuGet パッケージのアセンブリファイルを出力フォルダにコピーすることが可能だ。

具体的には、.csproj ファイル内の PropertyGroup ノード内に以下の記述を追加する。

<CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>

こうしてビルドすると、WebDriver.dll が (.NET Framework のときと同じように) プロジェクトの出力フォルダにコピーされ、この状態であれば "chromedriver.exe" が見つかるので、無事実行できるようになる。

ただ、.NET Core なプログラムだと、小さな NuGet パッケージをたくさん参照する傾向がありがちで、発行時はさすがにともかくも、通常のデバッグビルド・デバッグ実行のたびに大量の .dll が出力フォルダに毎回コピーされるのもどうかという気がしないでもない。

回避策 B - Selenium に明示的に教える

.NET Core なプロジェクトで、出力フォルダを確実に指す実行時情報がある。

AppDomain クラスの BaseDirectory プロパティだ。

そして幸い、Google Chrome 用 Web Driver "chromediver.exe" との通信を司る ChromeDriver クラスのコンストラクタは、"chromediver.exe" のありかを指定する1引数をもつオーバーロードバージョンがある。

この2者を組み合わせて以下のように "chromediver.exe" のあるフォルダを明示的に指定すれば良い。

var baseDir = AppDomain.CurrentDomain.BaseDirectory;
var driver = new ChromeDriver(baseDir);

こうすれば、.csproj をいじらずとも、期待どおり実行されるようになる。

まとめ

C# なプログラミングにおいては、.NET Framework 版、.NET Core 版のいずれであっても、

プロジェクト作成
NuGet パッケージ参照追加
コーディング

の 3ステップで Selenium によるブラウザ操縦プログラムが実装できる。

このとき、WebDriver ファイルの手動による事前配置は不要で、NuGet パッケージ参照によって WebDriver ファイルは解決される。

ただ、.NET Core のときは .NET Framework のときと比べてちょっとだけ手を掛けてやらねばならず、

プロジェクト設定を書き換えて、NuGet パッケージのアセンブリファイルをすべて出力フォルダにコピーするようにするか、
ソースコード上で、WebbDriver ファイルのあるフォルダを明示するか

しないと実行時に WebDriver ファイルが見つからないエラーとなるので注意。

下記 Issue が参考になるかと思う。

以上。

▲ by developer-adjust | 2018-12-09 00:00 | Selenium | Comments(0)


	ファン申請 ※ メッセージを入力してください