検索
リンク
タグ
ASP.NET
AngularJS
WebMatrix
Fizz-Buzz
C#
ASP.NET MVC
Selenium
ライトニングトーク
ADO.NET Entity Framework
Azure
.NET
jQuery
SQL Server
ASP.NET Core
JavaScript
Visual Studio
Plone
LINQ
F#
AJAX
カテゴリ
最新の記事
最新のコメント
記事ランキング
最新のトラックバック
以前の記事
2019年 11月 2019年 10月 2019年 09月 2019年 08月 2019年 07月 2019年 06月 2019年 05月 2019年 04月 2019年 03月 2019年 02月 2019年 01月 2018年 12月 2018年 11月 2018年 10月 2018年 09月 2018年 08月 2018年 07月 2018年 06月 2018年 05月 2018年 04月 2018年 03月 2018年 02月 2018年 01月 2017年 12月 2017年 11月 2017年 10月 2017年 09月 2017年 08月 2017年 07月 2017年 06月 2017年 05月 2017年 04月 2017年 02月 2017年 01月 2016年 12月 2016年 11月 2016年 10月 2016年 09月 2016年 08月 2016年 07月 2016年 06月 2016年 05月 2016年 04月 2016年 03月 2016年 02月 2016年 01月 2015年 12月 2015年 11月 2015年 10月 2015年 09月 2015年 08月 2015年 07月 2015年 05月 2015年 04月 2015年 03月 2015年 02月 2015年 01月 2014年 12月 2014年 11月 2014年 10月 2014年 09月 2014年 08月 2014年 06月 2014年 04月 2014年 03月 2014年 02月 2014年 01月 2013年 12月 2013年 10月 2013年 09月 2013年 08月 2013年 07月 2013年 06月 2013年 05月 2013年 04月 2013年 03月 2013年 02月 2013年 01月 2012年 12月 2012年 11月 2012年 10月 2012年 09月 2012年 08月 2012年 07月 2012年 06月 2012年 05月 2012年 04月 2012年 03月 2012年 02月 2012年 01月 2011年 12月 2011年 11月 2011年 10月 2011年 09月 2011年 08月 2011年 07月 2011年 06月 2011年 05月 2011年 04月 2011年 03月 2011年 02月 2011年 01月 2010年 12月 2010年 11月 2010年 10月 2010年 09月 2010年 08月 2010年 07月 2010年 06月 2010年 05月 2010年 04月 2010年 03月 2010年 02月 2010年 01月 2009年 12月 2009年 10月 2009年 09月 2009年 07月 2009年 06月 2009年 05月 2009年 04月 2009年 03月 2009年 02月 2009年 01月 2008年 12月 2008年 11月 2008年 10月 2008年 09月 2008年 08月 2008年 07月 2008年 06月 2008年 05月 2008年 04月 2008年 03月 2008年 02月 2008年 01月 2007年 12月 2007年 11月 2007年 04月 2007年 03月 2007年 02月 2007年 01月 2006年 11月 2006年 10月 2006年 09月 2006年 08月 2006年 07月 ファン
ブログジャンル
画像一覧
|
1 2018年 12月 28日
背景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 で開発中の場合、お勧めの方法は以下のとおり。
![]() 以上で Ctrl+F5 で実行などすれば、当該開発機の外部からも、この ASP.NET Core Web アプリが接続を受理、応答を返すようになる。 なお、上記で行なった設定内容は、Properties フォルダ内にある、「launchSettings.json」というファイル名の JSON ファイルにその設定内容が保存されている。 例えば次のとおり。
"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 だ。
※ "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日
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" という語句を検索実行する例だ。
![]() 以上でビルド & 実行 (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# プロジェクトを新規作成する。
続けて、以下のコマンドで、Selenium.WebDriver、及び Selenium.WebDriver.ChromeDriver の両 NuGet パッケージの参照を追加する。
![]() これでプロジェクトができたので、適当なテキストエディタを使って C# プログラムを同じように書きあげればよい。 ![]() ビルドと実行はコンソール (ターミナル) に戻って「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. ![]() だがしかし、.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 ノード内に以下の記述を追加する。
![]() こうしてビルドすると、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" のあるフォルダを明示的に指定すれば良い。
![]() こうすれば、.csproj をいじらずとも、期待どおり実行されるようになる。 まとめC# なプログラミングにおいては、.NET Framework 版、.NET Core 版のいずれであっても、
の 3ステップで Selenium によるブラウザ操縦プログラムが実装できる。 このとき、WebDriver ファイルの手動による事前配置は不要で、NuGet パッケージ参照によって WebDriver ファイルは解決される。 ただ、.NET Core のときは .NET Framework のときと比べてちょっとだけ手を掛けてやらねばならず、
しないと実行時に WebDriver ファイルが見つからないエラーとなるので注意。 下記 Issue が参考になるかと思う。 以上。
▲
by developer-adjust
| 2018-12-09 00:00
| Selenium
|
Comments(0)
1 |
ファン申請 |
||