検索
リンク
タグ
WebMatrix
ASP.NET Core
ASP.NET
AngularJS
ライトニングトーク
C#
AJAX
ASP.NET MVC
Selenium
.NET
jQuery
Fizz-Buzz
ADO.NET Entity Framework
Azure
JavaScript
LINQ
SQL Server
Plone
Visual Studio
F#
カテゴリ
最新の記事
最新のコメント
記事ランキング
最新のトラックバック
以前の記事
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月 ファン
ブログジャンル
画像一覧
|
2017年 09月 08日
ブラウザと https で接続しているのかどうかを判定するにはASP.NET Core 1.1 アプリにて、現在の要求が https 接続であるか否かを判定するには、要求クラス Microsoft.AspNetCore.Http.HttpRequest の IsHttps プロパティを参照するとよい。 このプロパティが true であれば、クライアントとは https でつながっている、ということを示している。 IsHttps プロパティは、例えば ASP.NET Core MVC のアクションメソッド内などであれば、そのコントローラクラスの Request プロパティ経由で参照できる。
このプロパティは Microsoft Azure の Web Apps Service に配置して実行されたときも、適切に true または false を返す。 たとえば foobar というアプリ名で Azure Web Apps 上に配置した場合、IsHttps プロパティは、
となる。 Docker コンテナ内では...?ところが、である。 同じ ASP.NET Core 1.1 アプリを Docker イメージにパッケージし、この Docker イメージを Azure Web Apps on Linux や Heroku の Docker コンテナ機能で稼働させると、
の https スキーマの URL でアクセスしても、その要求を受け取った ASP.NET Core アプリ内では、IsHttps プロパティは常に false となってしまうのだ。 まぁたしかに、Docker コンテナ内では ASP.NET Core アプリは、ポート 80 番で TLS 暗号化されていない素の http 通信で動いてるに過ぎない。 そのいっぽうで外界とは https で通信できてるのは、ポートフォワーディングやロードバランサ、リバースプロクシといった、クラウドサービス側のインフラによって実現されてるからである。 そうである以上、Docker コンテナ内に棲息している ASP.NET Core アプリの立場としては、"クライアント" というのはそれらエッジ側に配置されたサービスのことであり、「え、クライアントとは暗号化通信なんかしてないんですけど?」といって IsHttps プロパティが false になるのも理解できる。 ※Azure Web Apps も、実のところ ARR などがエッジ側にあるはずなのだが、そのあたりはうまく連携されているようだ。そのおかげで最終的に外界と HTTPS でつながっているのか否かをアプリ上で正しく判定できるっぽい。 とはいえ、このままでは「で、最終的にブラウザとは https でつながってるの? どうなの?」ということを ASP.NET Core アプリ内で判定したい場合、困ったことになる。 X-Forwarded-Protoそこで参照するとよいのが X-Forwarded-Proto サーバー環境変数である。 Azue Web App on Linux ないしは Heroku の Docket コンテナにおいて、ユーザーエージェントとはどんなプロトコル (http なのか https なのか) で接続しているのかを、この環境変数に設定してくれるのだ。 ASP.NET Core アプリ上は、この X-Forwarded-Proto サーバー環境変数は、要求ヘッダとして参照できる。 そこで、
という手順でスキーマ参照し、スキーマが "https" か否かで判定ができる。 具体的なコードとしてはこんな感じ。 (実際にはコントローラクラス/アクションメソッドにこんな風に直書きせず、何かミドルウェアとか実装して、そこで https でなかったら要求を HTTP 403 で拒否するとか https な URL にリダイレクトするとかやるのだろうけれど、とりあえずサンプルコードなので)。
このコードはもちろん、Azure Web Apps 上に配置した場合も正しく機能する。 これで、Docker コンテナ内で稼働する ASP.NET Core アプリであっても、ユーザーエージェントと https でつながってるのかどうかを判定できるようになった。 ▲
by developer-adjust
| 2017-09-08 23:04
| .NET
|
Comments(0)
2017年 09月 08日
Visual Studio 2017 による Docker サポートVisual Studio 2017 では、ASP.NET Core 1.1 Web アプリを開発する際、Docker イメージを生成するよう構成することができる。 新規プロジェクト作成時に、プロジェクト作成のダイアログで Docker サポートの追加を選択するか、 ![]() あるいは既存の ASP.NET Core プロジェクトをソリューションエクスプローラ内からの右クリックで Docker サポートの追加を行うことができる。 ![]() Docker サポートが追加されると、ソリューションの下に、主体である ASP.NET Core プロジェクトとは別に、Docker Compose のプロジェクト (.dcproj ファイル) が追加される。 ![]() Docker Compose のノードをスタートアッププロジェクトに指定して F5 実行すれば、IIS Express や dotnet コマンド実行ではなく、Docker イメージの作成とそのイメージからの Docker コンテナの開始でアプリが実行される。 もちろん Visual Studio 上でいつもと変わらずデバッグも可能だ。 作成される Docker イメージには プロジェクト名の名前空間 + dev のタグ名が付く。
ただしこの dev タグ付きの Docker イメージは、単純に docker run しても、下記のようなメッセージを吐くだけで実行できなかった。
たぶん、Visual Studio から起動されるときは、何かしらの追加のオプションが指定されて実行されているのだろう (詳しくは調べていない)。 Release モードにして Docker Compose プロジェクトをビルドを実行すれば、単純な docker run でちゃんと稼働する Docker イメージが作成される。 ![]() Release モードで作成される Docker イメージには、プロジェクト名の名前空間 + latest のタグ名が付く。
ところで、Visual Studio 2017 のプロジェクトテンプレートから作成した ASP.NET Core アプリのコーディングだと、環境変数 ASPNETCORE_URLS で指定したポート・URL でリッスンするようにできている。 それを踏まえつつ、"docker inspect {イメージID}" で件の Docker イメージの設定内容を確認してみると、環境変数 ASPNETCORE_URLS に「http://+:80」の設定が施されていて、それで TCP ポート 80 でリッスンするのだな、ということがわかる。 (どうやらこの環境変数設定は、元となっている「microsoft/aspnetcore:1.1」イメージにて設定が盛り込まれているようだ) ![]() 以上のことから、このイメージ内で稼働する ASP.NET Core アプリは、docker run での開始時にとくに指定がなければ、TCP ポート 80 でリッスンしている。 そこで、docker run 時に、-p オプションでポートフォワーディング指定をすることで、指定のポート番号経由でブラウザからアクセスが可能となる。 > docker run -p 32768:80 chomadproblemserver:latest この Docker イメージは、このように手元のローカルの Docker 環境だけでなく、Microsoft Azure の Web Apps on Linux に配置しても稼働する。 Docker Hub にこの Docker イメージを push してそれを Azure の Web Apps on Linux に配置することも可能だ。 ![]() ちなみに、この Docker イメージを Docker Hub に公開するには、docker tag コマンドを使って Docker Hub の自分のアカウントの名前空間で別名を付与し、これを docker push すればよい。
...以上の話題は、今年 2017 年に開催されたマイクロソフトの開発者向けイベント「de:code 2017」の TL04 セッション「.NET 15 周年の今こそ考えるクラウド ネイティブ アプリケーションと .NET の活用」の動画でも知ることができる。
Heroku の Docker コンテナサポートさて話は変わって、PaaS の老舗(?)、Heroku での話。 Heroku も時流に遅れることなく、Docker イメージを push して稼働させることが可能だ。 Heroku 上には registry.heroku.com という Docker リポジトリが用意されている。 このリポジトリに、Heroku 上のアプリ名の名前空間 + /web という名前空間で Docker イメージを push すれば、それで Docker コンテナが開始される。 Heroku CLI がインストール済みの環境であれば、下記要領となる。 まずは準備。 いちど済ませてあれば毎回行う必要はない。
次に、Heroku 上にアプリ枠を作る。 アプリ名が "foobar" だとすると、こんな感じ。
もちろん、このアプリ作成の手順は、heroku.com の Web コンソールから作っても構わない。 あとは、この foobar アプリとして配置したい Docker イメージに、Heroku の Docker リポジトリを指す、アプリ名 + /web を名前空間とした別名を付与して、push するだけだ。
これで、docker push が完了すると、Heroku 上でこのイメージから Docker コンテナが自動で開始される。 "heroku open -a foobar" を実行すれば、手軽に当該アプリをデフォルトブラウザで開いてくれもする。 しかし VS2017 で生成したイメージでは Heroku で動かないところがところが、Visual Studio 2017 の機能で生成した ASP.NET Core アプリの Docker イメージは、この方法では Heroku 上に配置しても以下のようにエラーとなって稼働してくれない。
どういうことかというと、Heroku による Docker コンテナサポートには、以下の2つの制約がある。
先のエラーは、メッセージからも読み取れるとおり、上記制約のうち最初のひとつめ (CMD 指定が必要) に抵触したことによるものだ。 これを踏まえつつ、Visual Studio 2017 の機能で生成された Docker イメージを見てみると次のとおりとなっている。
そこで、Visual Studio 2017 の機能で生成された Dockerfile を以下のように書き換えてビルドし直し・Docker イメージを作成しなおしすればよい。
以上を反映した Dockerfile は下記となる。({ASP.NET Core プロジェクト出力 .dll 名} の部分は実際の名前に置き換わる)
この Dockerfile に基づいて生成された Docker イメージであれば、Heroku に配置・稼働させることができるようになる。 もちろんこの変更を加えても、ローカルでの実行や、Visual Studio からのデバッグ、Azure Web Apps on Linux への配置など、これまでと同じ要領で変わらず実行可能だ。 補足・Dockerfile の変更・イメージの再作成ができない場合例えば他の人が作成・公開したような既存の ASP.NET Core アプリの Docker イメージで、且つ、前述のような対 Heroku 問題を抱えているイメージを、Heroku の Docker コンテナに配置したい場合はどうするか。 その Docker イメージの "再作成" は手が届かないとしても、ENTRYPOINT 指定を "上書き" した、レイヤーを重ねた新 Docker イメージを作成することで実現可能だ。 具体的には、以下のような Dockerfile を作り、
その Dockerfile があるフォルダで以下のように Docker イメージのビルドを行えばよい。
こうして作成した Docker イメージなら、docker push して Heroku 上に配置しても、期待どおり動作してくれるようになる。 以上! ▲
by developer-adjust
| 2017-09-08 21:42
| .NET
|
Comments(0)
2017年 07月 10日
前回の投稿で、ASP.NET Web API (.NET Core ではなく) において、バイナリコンテンツを返すにはどう実装するのかについてまとめた。 たかだかバイナリコンテンツを返すだけなのに、決して少ないとは言えない量のコードを記述する必要があることがわかり、もやっとする印象であった。 ASP.NET Core での実装はどうなる?さてところで、ASP.NET Core における Web API からバイナリコンテンツを返す場合はどうなるか。 ASP.NET Core からは、ASP.NET MVC と ASP.NET Web API は、その実装が統一化された。 旧来の ASP.NET では、MVC のコントローラクラス (System.Web.Mvc.Controller) と、Web API のコントローラクラス (System.Web.Http.ApiController) とは別物であった。 しかし ASP.NET Core MVC からは両者は統一され、MVC コントローラと API コントローラで区別がなくなり、いずれも同じ Microsoft.AspNetCore.Mvc.Controller クラスからの派生となる。 その結果、バイナリコンテンツの返し方は、旧来の ASP.NET MVC と同じ、File() メソッド呼び出しを返すだけでよくなった!
まとめASP.NET Core ならとてもシンプルである。 これならはじめから ASP.NET Core で実装しておけばよかったと反省である。 ▲
by developer-adjust
| 2017-07-10 16:51
| .NET
|
Comments(0)
2017年 06月 30日
表題の件、毎回やり方を忘れてはネット検索しているので、自分用にメモ。 なお、ASP.NET Core ではなく、従来からの ASP.NET における話題。 まずは結論からASP.NET Web API コントローラにてバイナリコンテンツを返すには、API コントローラのアクションメソッドについて、以下のようなコードを書けばよい。
うまくいかない例ちなみに下記コードでは期待した動作とならない。
上記コードだと、返したいバイナリコンテンツのバイト列が、JSON (ないしは XML) 形式で返されてしまうからである。 もちろん、たいていの場合、ASP.NET Web API コントローラの仕組みとしては、任意の型の戻り値が JSON (or XML) で返却されるのはうれしい仕様である。 しかし、今回のようにバイナリコンテンツを返したい場合には融通が利かず、先に書いたとおりの実装を記述しなければならないようだ。 もっとうまい方法がありますか?それにしても、たかだかバイナリコンテンツを返すだけなのに記述量がちょっと多い気がする。 もしかしてもっとスマートに実装できるのだろうか? 個人的には下記の妄想例のように、アクションメソッドに属性指定することで、バイナリコンテンツを返すことができたらいいのにな、とか思ってしまった。
そもそも API コントローラでバイナリコンテンツを返す?ところで、そもそも API コントローラでバイナリコンテンツを返す需要があるのか、はたまた、API コントローラからはバイナリコンテンツを返すべきではないのでは、といった議論もあろうかと思う。 まず需要についてだが、昨今の SPA (Single Page Application) 実装におけるクライアント側からサーバー側 API の呼び出しにおいて「チケットの QR コード画像を動的生成して返したい」であるとか、「現在ログインユーザーのプロフィール画像を返したい」など需要はあるように思う。 MVC コントローラから返すなら容易だけれども...そうしたときに、ASP.NET MVC コントローラであれば、File 拡張メソッドで容易にバイナリコンテンツを返すことができる。 よって、Web API コントローラでの実装にこだわらずに、MVC コントローラで実装すればいいのかもしれない。 しかし昨今の SPA 実装だと、サーバー側実装は MVC コントローラは無くて、Web API コントローラだけ、ということも多い。 そんな背景下、バイナリコンテンツを返すためだけに MVC コントローラを追加実装するのもどうかと思う次第。 CDN とか使うのでは?また、それなりのアクセス数・負荷が見込まれるような Web アプリ・サイトの場合、そのようなバイナリコンテンツはこれらコントローラ類で処理していると性能が追い付かないであろう。 このようなケースでは、CDN にそのようなバイナリコンテンツを配信しておいて処理を移譲する、といったような策を打つべきだろう。 とはいえ、中小社内向けや B2B でユーザー数が限定されているよううな場合は、CDN をはじめあまり連携サービスを増やさずに Web アプリ本体だけで完結していることも、サーバーへの配置などの取り扱いが簡潔になるので、それはそれで価値があると思う。 2017年7月10日 追記ASP.NET Core ならもっと簡単だった。詳しくはこちら。 ▲
by developer-adjust
| 2017-06-30 10:13
| .NET
|
Comments(1)
2017年 06月 19日
(.NET Core ではないクラシカルな) ASP.NET Web アプリ開発と、Azure Web App への配置における、データベース接続文字列をどこにどう設定するのか、の話題。 本投稿では、SQL Server データベースに接続して、何かしらデータベースに読み書きする ASP.NET Web アプリを想定している。 そしてデータベースアクセスライブラリには Entity Framework を用い、Code Fist スタイルで実装するものとする。 まずはおさらいから。 開発環境では...開発環境、およびバージョン管理システムにコミットされる内容としては、web.config の connectionStrings セクションに、SQL Server LocalDB によってプロジェクトフォルダ以下にデータベースファイルができあがるように、データベース接続文字列をインラインで記述する。
このコード・構成ファイルをバージョン管理システムにコミットしておくことで、このリポジトリを clone (あるいはチェックアウト) した他のメンバーも、ビルドして実行するだけで、データベースも新規構築されてその ASP.NET Web アプリを動かすことができる。 もっとも、最低限、いずれのメンバーの開発環境にも、同じバージョンの SQL Server LocalDB が事前にインストール済みである必要はある。 とはいえ、そもそも ASP.NET Web アプリ開発のために Visual Studio が必要という程度には各メンバーの開発環境をそろえる手間をかけているはず。 なので、さらに SQL Server LocalDB についても環境をそろえることは大したコスト、問題にはならないと思う。 実行環境では...さてこうして開発した ASP.NET Web アプリを、Azure Web App として配置するとしよう。 上記手順で開発したとすれば、接続先データベースに LocalDB が指定された web.config が配置されることになる。 しかし当然のことながら、一般的(?)なケースであれば、実行環境用のデータベースは LocalDB ではなく Azure 上の SQL Database サービスなどを別途用意済みで、そちらに接続するようにしたいはずだ。 このような目的で、Azure Web App のアプリケーション構成の中に、データベース接続文字列をポータル上から指定できるようになっている。 ![]() web.config の connectionStrings セクションと、この Azure のポータル設定とで同じ名前のエントリがあると、Azure のポータルで設定したデータベース接続文字列のほうが優先して採用されるのだ。 この仕掛けにより、
体制とすることができる。 開発環境側で、異なるデータベース接続がしたい!...と、ここまではおさらい。 それなりに ASP.NET Web アプリ開発や Azure への配置を手掛けている経験があれば、ここまでの内容は半ば "常識" かもしれない。 さて、以上の仕組み・体制で大抵の場合は問題ない。 しかし稀ではあるものの、開発環境においてデータベース接続文字列を変更したい需要がある。 いくつかの面倒なシナリオがあるのだが、わかりやすい例としては、開発環境にインストールされている SQL Server LocalDB のバージョンが合っていなかった、という例が挙げられる。 久々に古いプロダクトのコードを開いて実行してみたら、開発機を入れ替える前のコードで、現在の開発機にはそのプロダクトが指している古いバージョンの SQL Server LocalDB がインストールされていなかった、とかである。
まぁ普通に考えると、指定のバージョンの SQL Server LocalDB をインストールすればよいのだろう。 しかしながら、いろんなバージョンの SQL Server LocaDB が開発機にインストールされるのは (しかもそのようなレアなプロダクトの保守のためだけに)、気持ち悪いかもしれない。 そんなことから指定バージョンの SQL Server LocalDB のインストールを嫌って、web.config にインラインで記載されているデータベース接続文字列を、自身の開発機にインストールされている SQL Server LocalDB バージョンに合わせて書き換えてしまい、これをコミットしてしまうと、あまり致命的ではないとはいえ (どうせ Azure に配置するときにはポータルで設定された接続文字列が使われるので問題ない)、開発メンバー間で面倒なことになりかねない。 「あいつのコミットをマージしたら、自分の環境で動かなくなったー!」みたいに、である。 ということで、最近編み出した手法を紹介する。 解決方法まず、データベース接続文字列は、web.config にインラインで記述せず、web.config 中からは (例えば) "connectionStrings.config" という、もうひとつ外部の構成ファイルを参照するように変更する。
いっぽうで、バージョン管理システムには、ファイル "connectionStrings.config" がバージョン管理下に含まれないようにしておく。 git であれば .gitignore に "connectionStrings.config" の1行を加筆しておくことになるだろう。 さてこれだけだと、新たにバージョン管理リポジトリからプロジェクト一式を clone しても、"connectionStrings.config" がないので、ビルドや実行時エラーになってしまう。 そこで、ビルドイベントの「ビルド前に実行」されるバッチスクリプトとして、 「もし "connectionStrings.config" がプロジェクトフォルダに存在しなければ、既定の内容で生成」 というバッチスクリプトをプロジェクトファイルに組み込んでおくのだ (下記例)。 ![]()
※上記例以外にも、別途既定の構成の "connectionStrings.config" ファイルをバージョン管理下にはあるがプロジェクトフォルダの外に「テンプレート」として配置しておき、プロジェクトフォルダになければコピー、といった仕組みとすることもできるだろう。 あとは、"connectionStrings.config" をプロジェクトに含め発行対象となるようにしておけばよい。 ![]() こうしておくことで、
といったことができる。 まとめここで紹介したやり方は、実のところ、あまり美しいやり方とは言えないと思う。 実際、もしも Azure Web App への配置が CI/CD の仕組みではなく手動による配置だと、配置を行うメンバーが "connectionStrings.config" を既定とは違う内容に書き換えていたら、それが Azure 上に配置されてしまうという気持ち悪さもある。 (どのみち、ポータルで設定されたデータベース接続文字列に上書きされて動作するはずなので、実害はないはずだが) とはいえ、本記事で取り上げたような需要 ― 既定のデータベース接続文字列を開発者間で共有しつつ、自分独自のデータベース接続文字列に書き換えたいときがある ― を、とにかくは満たしてはいる。 広く勧める技法ではないが、同じような需要に迫られてお困りの方の一助になれば幸いである。 よりクールでスマートなやり方・運用があればご教示いただければ嬉しい限り。 最後に補足として、ASP.NET Core ではアプリケーション構成の仕組みが変わっているので本記事は参考にならないと思うので悪しからず。 ▲
by developer-adjust
| 2017-06-19 22:05
| .NET
|
Comments(0)
2017年 05月 02日
先に結論書いておくと、
テストの実行設定は「Auto (自動)」ではなく、「Script」>「CMD」で cd <テストプロジェクトがあるサブフォルダ> を指定しましょう。AppVeyor というのは、.NET 系フレンドリーなインターネット上の CI サービスである。![]() |
ファン申請 |
||