Dockerコンテナ内でASP.NET Core 2.1 Webアプリをビルド・実行する

やりたかった事：

Macに.Net SDKを入れずにASP.NET Core 2.1のWebアプリを開発したい。

試した事：

Docker(Version 18.03.1-ce-mac64)でMS公式の.NET 2.1 SDKイメージを動かしてみました。

まずは、SDKの公式イメージからコンテナを起動します。

docker run --rm -it \
  -v `pwd`:/app/ \
  -w /app/aspnetapp \
  microsoft/dotnet:2.1-sdk

これを実行すると、Mac側のカレントディレクトリがコンテナの/app/ディレクトリにマウントされて、かつコンテナ内のカレントディレクトリが/app/aspnetapp になった状態でシェルが起動します。

ここから、

dotnet new webapi 

を実行すればWeb APIのひな形のコードが生成されます。

さらに、

dotnet run

を実行すればデフォルトの5000番ポートでWeb APIが実行されますが、このままだとポートマッピングの設定をしていないのでホスト側からはアクセス出来ません。

とりあえずこれはCtrl+Cで終了してコンテナを終了し、次にdocker runコマンドに -p オプションを付けた上で、シェルを開くのではなく「dotnet watch run」コマンドを実行してみます。

使ったコマンドはこちら。

PORT=8080
docker run --rm -it --name watcher \
  -p $PORT:$PORT \
  -v `pwd`:/app/ \
  -w /app/aspnetapp \
  microsoft/dotnet:2.1-sdk \
  dotnet watch run $PORT

任意のポート番号でアプリを動かせるように、事前にProgram.csファイルにちょっと細工をしておきました。

#########
#########

起動後、指定したポート番号でアプリが動いているのが分かります。

分かった事：

docker runでコンテナを起動する際に -v オプションでカレントディレクトリをコンテナ内のディレクトリにマウントしておけば、ソースコードはホスト（Mac本体）側で編集し、BuildやPublishはコンテナ内で行うという事が出来ました。

コンテナ内で動かすコマンドを「dotnet watch run」としておけばコードを変更したら自動でアプリを再起動してくれます。

これでMac本体に.Net SDKを入れずにASP.NET Core 2.1のWebアプリを開発するという目的が達成出来ました！

参考URL：

dotnet-docker/aspnet-docker-dev-in-container.md at master
https://github.com/dotnet/dotnet-docker/blob/master/samples/aspnetapp/aspnet-docker-dev-in-container.md
MS公式Dockerイメージを使って.NET Core開発を行う（Mac） - ryuichi111stdの技術日記
http://ryuichi111std.hatenablog.com/entry/2016/11/07/020326

.

GitLab CIを使ってWebAPIのPDFドキュメント生成を自動化する

前回は Web APIに組み込んだSwaggerが生成する swagger.json ファイルからコマンドラインでPDF形式のドキュメントを生成するところまで出来ました。

今回はこの一連の処理をGitLab CIを使って自動化してみようと思います。

大まかな流れは次のようになります。

1. GitLabにプロジェクトを作成する
2. 「.gitlab-ci.yml」ファイルを作成する
3. GitLabにプッシュしてCIが動作することを確認する
4. Web APIをAzure App Servicesに自動デプロイする
5. CIでPDFドキュメントを自動生成する
6. 生成されたPDFドキュメントをダウンロードする

1. GitLabにプロジェクトを作成する

CIサービスと言えば、Circle CIやTravis CI、Werkerなどたくさんありますが、今回は GitLab CI を使うことにしました。

まだ gitlab.com にアカウントが無い場合はユーザー登録しましょう。
ログイン後、「New Project」ボタンを押して新規プロジェクトを作成します。GitHubに既にプロジェクトがある場合はそちらからそっくりインポートする事も可能です。


2. 「.gitlab-ci.yml」ファイルを作成する

ソリューションの直下に .gitlab-ci.yml と言う名前のファイルを作成します。

Visual Studioを使っている場合はソリューションを右クリックして「追加」をすればSolution Itemsの下に表示されます。

ファイルの内容はとりあえずこんな感じにしておきます。




Dockerのベースイメージとして、Ubuntu 14.04 を使っています。

before_script の部分で apt-get コマンドを使ってJavaとRubyのインストールを行ない、script の部分で動作確認のためにJavaとRubyのバージョンを出力しています。

.gitlab-ci.ymlファイルの仕様は下のページに載っています。

https://docs.gitlab.com/ce/ci/yaml/README.html#gitlab-ci-yml

3. GitLabにプッシュしてCIが動作することを確認する

この状態でGitLabにプッシュして見ます。Pipelinesというメニューをクリックすると自動的にPipelineが作成されている事が分かります。

Jobsというサブメニューを開いて実行されたJobをクリックして詳細を表示すると、黒い画面でコンソール出力の結果を確認する事が出来ます。JavaとRubyのインストールが正常に行われて、最後にバージョン情報が表示されていれば成功です。

リポジトリへのPushを検知してGitLab側で自動的にDockerコンテナを起動して指定のコマンドを実行してくれているわけですね。

Circle CIなど他のサービスを使わずに、しかも無料でこれが出来るというのがGitLabの良い所だと思います。

ちなみに「CI Runner」というものを自前のサーバーにインストールしておけば、Dockerコンテナをそのサーバー上で起動させる様にする事も可能なようです。（むしろ元々は自前で用意するのが基本だったようです。）

4. Web APIをAzure App Servicesに自動デプロイする

Web APIのデプロイ先はAWSやGoogle Cloudなどどこでも構わないのですが、今回はAzure App Servicesを使います。

Azure App Servicesに自動デプロイするにはいくつかの方法がありますが、ここではTravis CIが作成している dpl コマンドを使ってみます。

GitLab CIのジョブでdplコマンドを実行するための設定は次のようになります。



Ubuntu 14.04を起動した後 Rubyをインストールし、さらに gem install dpl で dpl コマンドをインストールしています。

その後、dpl --provider=AzureWebApps で実行します。


ちなみに、

only:
    - /^release-.*$/

の部分は、「release-」で始まるタグ付きでプッシュされた時だけこのジョブが起動されるようにするための設定です。この2行を削除するとプッシュするたびに毎回起動されます。


さて、上の設定ファイルではデプロイ先のURLやデプロイ用の認証情報などを一切指定していません。それらはGitLab内のプロジェクト毎の設定画面に「Secret variables」として登録しておきます。

dplコマンドは

• AZURE_WA_SITE
• AZURE_WA_USERNAME
• AZURE_WA_PASSWORD

の3つの設定を自動的に読み込んで処理してくれます。

この状態で実際にGitLabにプッシュして見るとAzure App ServicesにWeb APIが自動デプロイされます。下はデプロイ成功時のジョブのログを表示したところです。

念のためAzure側のURLを開いてみると確かにWebAPIとSwagger UIが動いています。

5. CIでPDFドキュメントを自動生成する

さて、次はいよいよWeb APIのPDFドキュメントを自動生成します。設定ファイルにpdfというジョブを追加しました。

stages:
  - deploy
  - pdf

となっているので、「deployというステージが終わってからpdfというステージを実行する」という意味になります。ひとつのステージには複数のジョブを含める事が出来ますが、その場合はステージ内の各ジョブが並列実行されます。今回の設定ではそれぞれのステージに同名のジョブを一つずつ含んでいるだけという形になっています。

それぞれのジョブは別個のDockerコンテナとして起動されるので、pdfジョブの方でも再度Rubyのインストールが必要になります。こちらのジョブではJavaのインストールも必要なのでdeployジョブよりも少し時間がかかります。

cd ./MySampleWebApi.Doc && chmod +x *.sh && ./build.sh $SWAGGER_JSON_URL

MySampleWebApi.DocフォルダにあらかじめダウンロードしておいたJavaのコマンド（swagger2markup-cli-1.3.1.jar）やスクリプトを格納してあるので、そのフォルダに移動して build.sh を実行しています。

これで前回に実行したのと同じ一連の処理が動いて ./MySampleWebApi.Doc/pdf フォルダにPDFファイルが作成されます。

この時にSecret Variablesの設定から $SWAGGER_JSON_URL の値を読み込んでスクリプトに渡しています。

こうしておけばAzure側のデプロイ先が変わっても柔軟に対応出来るので便利ですね。

6. 生成されたPDFドキュメントをダウンロードする

最新の成果物へは下の形式のURLでアクセス可能になっています。

https://gitlab.com/(ユーザー名またはグループ名)/(プロジェクト名)/-/jobs/artifacts/master/browse?job=(ジョブ名)

このURLへはGitLabにログインした状態でかつ権限があるユーザーでないとアクセス出来ないので、実運用では .gitlab-ci.yml にさらにジョブを追加してAWSやAzureなどのストレージにアップロードするような処理を追加することになると思います。


あと、この設定のままだとジョブが起動される度に素のUbuntuに対してJavaやRubyのインストールから行っているので、終了するまでにかなり(数分程度)時間がかかってしまいます。

出来ればJava/Rubyが既に入った状態のイメージを探してくるか自分で作成するかして、それをベースイメージに指定した方が良いと思います。



今回作成したサンプルプロジェクトの全ソースコードは下記で参照可能になっています。

https://gitlab.com/mikehibm/AspNetCoreWebApiSwagger

SwaggerのAPI定義からPDFドキュメントを生成する

前回はASP.NET CoreのWeb APIプロジェクトにSwaggerを組み込んでAPIのドキュメントをブラウザ上に表示させるところまで実行しました。

これはこれで手軽にAPIの仕様を確認出来て便利なのですが、受託開発の際の納品物としてお客様に渡すには少し不便です。「納品は紙（PDF）で」と言われる事がまだありますよね？

ブラウザに表示されているものを印刷して渡してしまっても良いかもしれませんが、それだと今ひとつ見栄えが良くないので出来ればもう少しきれいなPDF文書を自動生成したいところです。

そこで調べたところ、次のような事が分かりました。

● swagger2markup-cli を使えばSwaggerが生成するJSONファイルから静的なHTMLやMarkdown、AsciiDoc形式のドキュメントなどを生成する事が出来る。

● asciidoctor-pdf を使えばAsciiDoc形式のドキュメントをPDFファイルに変換する事が出来る。

参考：
goa tips: swagger-ui がサービスできないときのドキュメントどうする問題 - 押してダメならふて寝しろ

asciidocをPDFに変換してみた（asciidoctor-pdf）

今回はこれらを使って

swagger.json → AsciiDoc → PDF

という流れでドキュメントを生成する事にします。


まず前提条件として、swagger2markup-cliを使うにはJavaのインストールが必要で、asciidoctor-pdfを使うにはRubyのインストールが必要になります。

Macで開発しているのあれば通常は両方とも既に入っていると思います。Windowsの場合はchocolateyを使えば簡単にインストール出来ると思います。



1. swagger2markup-cliでAsciiDocファイルを生成する

下のURLからjarファイルをダウンロードします。

https://jcenter.bintray.com/io/github/swagger2markup/swagger2markup-cli/

ダウンロード後、コマンドラインから下記を実行します。

java -jar ./swagger2markup-cli-1.3.1.jar convert -i [swagger.jsonへのパス] -d ./adoc

[swagger.jsonへのパス]の部分は 「http://localhost:49879/swagger/v1/swagger.json」のようにURLを指定しても良いし、「./swagger.json」のようにあらかじめダウンロードしておいたJSONファイルを指定しても構いません。

エラーが出ずに成功すれば、adocフォルダには overview.adoc, paths.adoc, definitions.adoc, security.adoc の4つのファイルが出来ているはずです。ファイルが分かれていると次のステップで困るので、1ファイル(out.adoc)に結合しておきます。

cat adoc/overview.adoc adoc/paths.adoc adoc/definitions.adoc > adoc/out.adoc

(security.adocの内容は特に必要がなかったので除外しました。)




2. asciidoctor-pdfでPDFファイルを生成する

gemコマンドでasciidoctor-pdfをインストールします。

gem install --pre asciidoctor-pdf

あとは入力と出力を指定して実行するだけです。

asciidoctor-pdf -o pdf/out.pdf adoc/out.adoc

これでpdfフォルダにout.pdfファイルが生成されます。サンプルはこんな感じです。

デフォルトのスタイルが物足りなければ、テーマを自作して色々とカスタマイズ出来るようです。

asciidocをPDFに変換してみた（asciidoctor-pdf）

さて、ここまででWeb APIからPDFドキュメントを生成する事が出来ました。ただ、APIに変更が発生する度にコマンドを打ち込んでPDFを再生成するのはちょっと面倒です。

そこで次回は、今流行りの「Continuous Integration（CI）」なるものを使ってソースコードの変更をプッシュするだけで自動的にPDFドキュメントが更新される、という事にチャレンジしてみたいと思います。

次回： GitLab CIを使ってWebAPIのPDFドキュメント生成を自動化する

ASP.NET WebAPIにSwaggerを組み込む

1. ASP.NET Core Web APIを新規作成する

Visual Studio 2017でASP.NET CoreのWeb APIプロジェクトを新規作成します。

デフォルトでControllersフォルダの中にValuesControllerがあるので、この名前をProductsControllerに変更し、さらにUsersControllerを追加します。

新規にResourcesフォルダを作成してその中にProductクラスとUserクラスを作成しておきます。

その後ProductsControllerとUsersControllerを編集してダミーのデータをJSONで返す様にした状態のソースコードが下記になります。（コミットにbefore-swaggerタグが付いています。）

https://github.com/mikehibm/AspNetCoreWebApiSwagger/tree/before-swagger

Ctrl+F5キーで実行すると商品とユーザーの情報がJSONで返って来るのが分かります。

この状態でWeb APIとしては動いているので、次にSwaggerを組み込んでAPIのドキュメント（メタ情報）に外部からアクセス出来るようにしてみます。

2. Swaggerを組み込む

Visual Studio内でPackage Managerコンソールを開いて、次のコマンドを打ち込みます。

Install-Package Swashbuckle.AspNetCore

その後、下のサイトを参考にStartup.csファイルを編集します。と言っても数行を追加するだけなので簡単です。

ASP.NET Web API Help Pages using Swagger

編集後の Startup.cs は下の状態になります。




この状態でCtrl+F5キーを押して実行し、http://localhost:xxxxxxx/swagger/ のURLを開くと、Swagger UIの画面が開いてAPIのドキュメントを閲覧する事が出来るようになっています。

ただこの段階ではせっかくソースコードに書き込んだコメントが反映されていないので、次にそれらが反映されるようにします。

3. XMLコメントをSwaggerに反映させる

まず、プロジェクトの設定で「XMLドキュメントファイル」の自動生成を有効化しておく必要があります。

この状態で一旦プロジェクトをビルドすると、指定したファイル名でXMLファイルが出来るはずです。このファイルをVisual Studioのソリューションエクスプローラ上で右クリックして、「プロジェクトに含める」を選択しておきます。

さらに、XMLファイルを選択した状態でF4キーを押してプロパティウインドウを表示し、下のようにプロパティを変更しておきます。これは後でこのプロジェクトをPublishする際に必要になります。

次に、Startup.csファイルの中で services.AddSwaggerGen() メソッドを呼んでいる箇所があるので、そのブロック内に下の3行を追加します。

var basePath = PlatformServices.Default.Application.ApplicationBasePath;
var xmlPath = Path.Combine(basePath, "MySampleWebApi.xml");
c.IncludeXmlComments(xmlPath);

これで再度実行するとソースコード内でクラス単位やメソッド単位で「///」を使って書いたコメントがSwagger UIの画面にも反映されます。

4. まとめ

ASP.NET CoreのWeb APIプロジェクトにSwaggerを組み込んでAPIのドキュメントを表示させるようにする事は、上の通りかなり手軽に出来ます。

ASP.NET Coreでなく従来のASP.NET MVCのプロジェクトでもほぼ同じ手順でSwaggerの組み込みが可能です。

次回はSwaggerが生成した情報を使ってPDFドキュメントを生成する方法を書いてみたいと思います。

ASP.NET CoreとEntityFrameworkで最速でWeb APIを作るには

ASP.NET Core, EntityFrameworkとVisual Studio Codeを使ってデータベースから情報を取得してJSONで返すWeb APIを作ります。

コードファーストは使わず、既存のデータベースが存在するという前提で作ります。
とりあえず Northwind というサンプルのデータベースが存在すると仮定してコーディングしていますが、データベース名、テーブル名やモデルクラスの内容は適宜手元の環境に合わせて読み替えて下さい。

以下ステップ０から８までに分けましたが、おそらく20分もあれば全部出来ると思います。


ステップ０ - .NET Core SDKとVS Codeをインストール
ステップ１ - プロジェクトを作成する
ステップ２ - 依存パッケージを追加する
ステップ３ - モデルクラスを作成する
ステップ４ - DbContextクラスを作成する
ステップ５ - リポジトリクラスを作成する
ステップ６ - 設定ファイルにDB接続文字列を追加する
ステップ７ - Startupクラスに設定を追加する
ステップ８ - Controllerを作成する

ステップ０ - .NET Core SDKとVS Codeをインストール

下のサイトからインストールして下さい。

https://www.microsoft.com/net/core

https://code.visualstudio.com

VS Codeをインストールした後、C#用の拡張機能をインストールしておいて下さい。

ステップ１ - プロジェクトを作成する

dotnet new mvc --auth None --framework netcoreapp1.1 -o MySampleWeb
cd MySampleWeb
dotnet restore
code .

VS Codeでフォルダを開いて、拡張子が.csのファイルを表示すると2〜３秒後にダイアログが表示されるので、「Yes」をクリックします。

プロジェクトフォルダ直下に.vscodeフォルダが作られ、ビルドやデバッグ実行用の設定ファイルが自動的に作成されます。

この時点でShift+Ctrl+B（MacではShift+Cmd+B）を押すとビルドが実行されるのでエラーが無いことを確認しておきます。

ステップ２ - 依存パッケージを追加する

dotnet add package Microsoft.EntityFrameworkCore.SqlServer

上のコマンドを実行すると「MySampleWeb.csproj」ファイルにEntityFrameworkでSqlServerに接続するためのパッケージ参照のエントリが追加されます。

ステップ３ - モデルクラスを作成する

プロジェクト直下にDataというフォルダを作って、そこにCustomer.csファイルを作成します。

ステップ４ - DbContextクラスを作成する

コンストラクタのパラメータでoptionsを受け取るようになっている点に注意して下さい。これを忘れるとデータベースに接続出来ずエラーになります。

ステップ５ - リポジトリクラスを作成する

とりあえずGetAll()とFind()のみ実装しておきます。

CustomerRepositoryクラスのコンストラクタでNorthWindContextのインスタンスを受け取れるようになっている点に注目です。

ASP.NET CoreではDbContextなどのインスタンスはこの様にDependency Injection（DI）で受け取るというのが原則です。

ステップ６ - 設定ファイルにDB接続文字列を追加する

SQLサーバーの指定、ユーザーID、パスワードの指定は適宜変更して下さい。

ステップ７ - StartupクラスにDIの設定を追加する

AddDbContext()

このメソッドでDbContextのDIを設定しています。


AddScoped()

このメソッドでリポジトリクラスのDIを設定しています。「ICustomerRepositoryのインスタンスがどこかで要求されたら、CustomerRepositoryのインスタンスを生成して注入してね」という意味になります。

AddSingleton()やAddTransient()などもありますが、それぞれ注入されるインスタンスが維持される期間が異なります。

Dependency Injection in ASP.NET Core | Microsoft Docs
https://docs.microsoft.com/en-us/aspnet/core/fundamentals/dependency-injection

AddScoped()の場合はひとつのHTTPリクエストについてひとつのインスタンスが生成されます。リポジトリクラスの中で使っているEntityFrameworkはスレッドセーフではないので AddSingleton() はここでは使えません。

ステップ８ - Controllerを作成する

ControllersフォルダにCustomersController.csファイルを新規作成します。



コンストラクタでリポジトリクラスのインスタンスを受け取るようになっています。ここでステップ７で設定したDIが効いてきます。

通常のWebアプリケーションとして動いている場合は、このDIのおかげでASP.NET Coreが自動的にCustomerRepositoryのインスタンスを生成してコントローラに渡してくれます。

でも単体テストでコントローラの動作をテストしたい場合などでは、自前でモックのインスタンスを生成してコントローラに渡すことが出来ます。DIを使うことでクラス同士が疎結合になっているわけですね。

密結合と疎結合の概念やDIについては下のページの説明がとても分かりやすいと思います。

ASP.NET - 依存関係の挿入による ASP.NET Core でのクリーンなコードの作成

これでカスタマーの情報を取得するWeb APIが出来ました。

VS Code上でF5またはCtrl+F5(MacではCmd+F5)を押して実行して見てください。ブラウザが開いてデフォルトのHomeページが表示されるので、下のURLを手入力します。

先頭から3件取得
http://localhost:5000/api/customers?offset=0&limit=3

カスタマーIDを指定して取得
http://localhost:5000/api/customers/ANATR

データベースから取得した情報がJSON形式で表示されれば成功です！


これからは.NETでのWeb開発といえば「ASP.NET Core」という事になって行くと思います。

WindowsでもMacでもLinuxでも全く同じように開発が出来るのがいい感じです。


今回のソースコードはこちらにあります。

https://github.com/mikehibm/AspNetCore-MySampleWeb



参考URL：

ASP.NET Core MVC with Entity Framework Core - Tutorial 1 of 10

チュートリアル: ASP.NET Core MVC で Web API を作成する | Microsoft Docs 

　

リバースプロキシを使っているWebサイトでHTTPからHTTPSに自動的にリダイレクトさせるための設定

IIS 8.5 での設定方法です。

まず、Webサーバーに「URL Rewrite」モジュールをインストールします。

URL Rewrite : The Official Microsoft IIS Site
https://www.iis.net/downloads/microsoft/url-rewrite

次に、該当のサイト直下のWeb.configを編集してsystem.webServerセクションにrewriteの設定を追加します。

リバースプロキシ（例えばAzureのApplication Gatewayなど）を使っていない場合は、こちらのサイトにある方法で問題無いと思います。

WebサイトでHTTPSへリダイレクトさせる | たんたか
http://blogs.gine2.jp/taka/archives/2790

リバースプロキシを使っている場合は、この方法だとリダイレクトが無限ループになってしまいます。

そこで下のように書き換えます。




これで無事思った通りにHTTPからHTTPSにリダイレクトしてくれるようになります。


リバースプロキシから送られてくるX_FORWARDED_PROTOヘッダの値をチェックして、「https」でない場合だけリダイレクトするという条件になっています。


また{REQUEST_URI}を使った場合は「appendQueryString="false"」を付けておかないと、REQUEST_URI自体が既にクエリー文字列を含んでいるためにURLの「?」以降の部分が2回重複して追加されてしまうようです。

URL Rewriteモジュールを使うとプログラムを書き換えずに対応出来るので便利ですね！

MSBuildでVisual Studioのプロジェクトをビルドした時に参照しているDLLが出力フォルダにコピーされない問題の対処法

表題の通りの問題にぶつかって、今日は解決策を見つけるまでに数時間もかかってしまいました。せっかくなのでメモしておきます。


事の発端は、あるASP.NET MVCのプロジェクトでActiveReportsのバージョンを更新したことでした。ライブラリの参照やソースコードを自動で更新してくれるツールがあるのでそれを使ってプロジェクトを更新しました。

するとその直後から、MSBuild.exeを使ってコマンドラインからビルドした場合にアウトプット先のフォルダにActiveReportsのDLLファイルがコピーされないという現象が発生しだしました。

Visual Studio の中でビルドを行った場合には全く問題ありません。


色々調べましたが結局、該当のプロジェクトファイル(.csproj)をエディタで開いて以下のように直接書き換えることで解決しました。

変更前

変更後

<Reference>タグの中に<Private>True</Private>という記述を追加すればOKです。

この設定は Visual StudioのSolution Explorer の表示上は「Copy Local」というプロパティに当たる部分になります。

問題は、これが初期状態だと「True」と表示されているのに、実際にはプロジェクトファイルでは上の画像の変更前の状態にあるとおり、<Private>True</Private>という記述が無いということです。このせいでMSBuild.exeが正しく動作しなかったという事みたいです。

プロジェクトファイルを直接書き換える他にも、Visual Studio上で「Copy Local」を一旦Falseにして保存して、Trueに戻してからもう一度プロジェクトを保存する、という手順でも同様の効果がある様です。



参考URL：
visual studio - MSBuild doesn't copy references (DLL files) if using project dependencies in solution - Stack Overflow






　

Azure Blob StorageにJavaScriptから直接アップロードする

Azure Blob Storageにブラウザ(JavaScript)から直接アップロードする必要があったので、簡単なサンプルを作ってみました。

https://github.com/mikehibm/AzureDirectUploader

JavaScriptでHTML5のFile APIを使ってフォルダ内のファイル一覧を表示し、「Upload」ボタンを押すと選択されたファイルを一つずつAzure Storageにアップロードします。


ブラウザから直接アップロードするとは言っても、最初に一度だけサーバー側の処理を呼び出す必要があります。ASP.NET WebAPIはそのためだけに使っています。

これはAzure Storageアカウントのアクセスキーをクライアント側に渡さずに、一時的に「Shared Access Signature（共有アクセス署名）」というものを生成してそれをクライアント側で使える様にするためです。

一度SASを取得してしまえば、有効期限が切れるまでそれを使ってブラウザからAzure Storageにアップロード出来ます。サンプルでは有効期限が切れたら再度SASを取得し直してアップロードを継続する様になっています。

クライアント側から直接アップロード出来ればサーバー側の負荷が減って便利ですね。






.

ブラウザさえあればASP.NETアプリの開発が出来る時代に既になっていたという話

『Visual Studio Online Monaco』の開発環境が素晴らしい。

まずは、Azure Web Siteの管理画面でVisual Studio Onlineを有効にする。

「Edit in Visual Studio Online」というメニューが有効になるのでそれをクリック。

1. ブラウザ内でソースコードの編集が出来る。

サクサク動くし、もちろんコード補完もバッチリ。

2. ブラウザ内でコンソールを開いて各種コマンドが使える。

gitコマンドで色々出来る。node が入っているので npm も使えるし gulp や bower も使える。まだそんなに使い込んでないですが、とりあえず色々出来そうな予感。

3. gitの差分はGUIで見やすく表示してくれる。

4. コンソール内で「msbuild」と打ち込めばクラウド上でソリューションをビルドしてくれる。

5. 一つのWebサイト内に複数のアプリケーションを配置出来る。

メインのサイトと管理用サイトを分けたり、WebAPIだけ別アプリケーションにしたり出来る。

6. DB接続文字列やアプリケーション設定はAzureの管理画面から上書き出来る。

ソース上のWeb.configファイルにはとりあえず仮の値を入れておいて、別途Azure Web Siteの管理画面から設定すれば実行時にはそちらの値で上書きされる。これは便利。

正直、特に4番のビルドについては「Visual Studio Online (MonacoではないTFSのオンライン版)」のCI機能を使わないと出来ないとさっきまで誤解していました。

この動画を見て初めて知りました。

Getting started with ASP.NET | Visual Studio Online "Monaco" | Channel 9

ブラウザ内のコンソールで「msbuild」と打てばクラウド上でビルドが出来るなんて！
衝撃でした。笑)

ソリューション内に複数のアプリケーションがある場合はAzure Web Siteの管理画面で仮想アプリケーションとしてそれぞれのフォルダを指定してやるだけでOK。

ローカル環境にVisual Studioを入れなくてもブラウザだけでここまで出来るんなら、もうPC無しでいいんじゃない？ という気がしてくる。

Visual Studio Online Monaco、すごい！





* 4/16/2015 追記:

もう少し「Monaco」を使ってみて気付いた点です。

- コード補完はまあまあだけどやっぱりローカルのVisual Studioの方が快適。

- Monacoではソリューションファイル(*.sln)やプロジェクトファイル(*.csproj)の作成・変更が難しい。

例えばC#のソースファイルを新規作成してプロジェクトに追加したいと思っても、ローカルのVisual Studioの様に右クリックして「プロジェクトに含める」を選ぶ様な事は出来ません。プロジェクトファイルを手動で編集すればなんとかならない事はないですがかなり面倒です。

この辺りが今後改善されればさらに便利になりそうですね。
(と言っても次期のASP.NETではプロジェクトファイル自体が必要無くなるらしいので、別に気にしなくてもいいのかも。)








　.

Azure仮想マシンのIIS8.0でFTPSを設定した時のメモ

色々と問題があったので忘れない様にメモ。

ローカルユーザーの設定

• サーバーにFTP用のローカルユーザーを作成する。
• FTP用ユーザーにアクセス対象ディレクトリへの権限を付与する。

IISのFTP設定

ルートレベル

• 「FTP Firewall Support」でPassive接続に使うポート範囲を指定。
• 「FTP SSL Setting」でSSL証明書を指定。

各サイトレベル

• 「FTP Firewall Support」でPassive接続に使うグローバルIPアドレスを指定。
• 「FTP SSL Setting」でSSL証明書を指定。(ルートレベルで設定したのと同じもの)
• 「Bindings」でホスト名を指定。（複数のホスト名がある場合）
• 「FTP Authentication」でBasic認証を有効化。
• 「FTP Authorization」でアクセス許可するユーザーを指定。

ここまでの設定後「Microsoft FTP Service」のリスタートが必要なので注意。

Azure管理サイトでの設定

仮想マシンのEndpointsにFTP用の設定を追加。
Passive接続用のポートを許可するのを忘れない事。

「530 Valid Hostname is expected」エラーへの対処

• 複数のホスト名で複数のFTPサイトを作成している時に発生する。
• ログイン時のユーザー名を 「サイト名|ユーザー名」と指定すれば解決する。

http://www.net24.co.nz/kb/article/AA-00201/25/Virtual-Private-Servers/Windows/Error-530-Valid-Hostname-is-expected-using-FTP-to-IIS7.html

FileZillaからアップロード出来ない問題の対処

• ファイルをアップロードすると、転送完了後にエラーになってファイルがサーバー側から消えてしまう。
• IIS8.0の不具合らしい。

https://forum.filezilla-project.org/viewtopic.php?f=2&t=27898&start=120

• 対策１ WinSCPを使ってTLS1.0で接続する。(非推奨)  
• 対策２ サーバー側にHotFixを適用する。

http://support.microsoft.com/kb/2888853

以上、長かった！







.

ASP.NET MVCでリフレクションを使って任意のオブジェクトの一覧をCSV形式で返す

ASP.NET MVCで任意のオブジェクトのIEnumerableを受け取ってCSVファイルを出力するクラスを作ったので、久しぶりにGitHubに上げておこうと思う。

https://github.com/mikehibm/CSVResult


何も大した事はしていないけれど、リフレクションを使った例として今度の勉強会で使おうかと思っている。

上の様なデータが

この様にCSV形式でダウンロードされる。上はExcel 2010で開いた所。

CSV形式と言うと、データの中に引用符（ダブルクォート）やカンマが含まれていた場合の処理が面倒だ。

今回は

• ダブルクォートは二重化する。（"→""）
• カンマは全角に変換する。
• 改行コードは「|」に変換する。

というとりあえずのルールで実装してみた。

検索して調べた限りではカンマが含まれる場合は項目全体をダブルクォートで囲めば良いと書いてあるケースが多かったけれども、それだとExcel 2010でどうしても列がずれてしまうので、苦肉の策として全角にしてしまった。^^;

改行コードについても同じく、ダブルクォートで囲むだけではExcel 2010では上手く行かないみたいなので適当に「|」に変換する事にした。まあ実際に使う際には適宜仕様に合わせて変更すればいいかなと思う。

　

ロードバランサーを使って複数のWebサーバーでASP.NET MVCアプリケーションを動かした時のメモ

ハードウェアの構成

ロードバランサー1台
Webサーバー3台
DBサーバー1台

ソフトウェアの構成

Webサーバー
　Windows Server 2008 R2
　IIS7.5
　ASP.NET MVC 4

　IISではひとつのWebサイトの下に複数のASP.NET MVCアプリケーションを配置。

DBサーバー
　Windows Server 2008 R2
　Microsoft SQLServer 2008

パターン1 - それぞれのWebサーバー内でSessionを管理

ロードバランサーが「セッション維持機能」を持っている事が前提。

Session管理は State Service を使う。

State Service を使う為のweb.configの設定

<sessionstate mode="StateServer">      stateConnectionString="tcpip=127.0.0.1:42424"
      stateNetworkTimeout="10" />

各Webサーバーで「ASP.NET State Service」が自動起動する様に設定しておく事。

パターン1で発生した問題

ロードバランサーのセッション維持機能が上手く動いていない！
そのため時々Webサーバーが切り替わってログイン画面が表示されてしまう。

ロードバランサーのベンダーに調査してもらっても「設定に特に問題は見つかりません。アプリ側の問題では？」との事で、解決せず。

教訓：しょぼいロードバランサーは使わない！

今回のプロジェクトではロードバランサーは自分達の管理下にはないので、パターン1はあきらめる。

パターン2 - SQLServerでSessionを管理

ロードバランサーのセッション維持機能に頼らずにSession情報をDBに格納してWebサーバー間で共有する事にする。これならWebサーバーが任意のタイミングで切り替わっても大丈夫。

1. SQLサーバーにSession情報を保存するためのデータベースを作成する。

　aspnet_regsql.exe -S server -U username -P password -ssadd -sstype p

　※tempdbに保存するのではなく永続化するために -sstype pオプションが必要。

このコマンド一発でデータベースの作成、テーブルの作成、期限切れのSession情報を削除するためのJobの登録まで行なってくれる。

　aspnet_regsql.exeのヘルプはこちら


2. MachineKeyの設定を共通化する。

全てのWebサーバーでMachineKeyを共通化しておかないと、認証クッキーやその他さまざまなデータの暗号化・復号化の処理がWebサーバーが切り替わった時に上手く行かなくなる。

IIS7.5の管理画面で該当のアプリケーションを選択すると、「MachineKey」という項目があるのでそれを開く。

画面右側の「Generate Keys」をクリックして「Apply」するとweb.configファイルのsystem.webセクションに下の様な設定が追加される。

<machineKey decryptionKey="xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" validationKey="xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" />

あとはこの部分をコピーして他の2台のWebサーバーのweb.configにペーストすればOK。

参考URL：How To: ASP.NET 2.0 で MachineKey を構成する方法

3. IIS Metabase上のSite IDを共通化する。

これをしておかないと、Webサーバーが切り替わった時にSQLServer側で別アプリケーションとして認識されてしまって、Session情報の共有が出来なくなってしまう。今回はこれでハマった。。。


対策としてはSQLServerのストアドプロシージャを修正するという方法もあるみたいだけど、IIS7.5以降なら下の方法で簡単にIDを共通化出来るみたい。

IIS上で何度かWebサイトを作成したり削除したりしているとIdの値が変わってしまうので、該当のWebサイトを選択した上で「Advanced Settings」を開いてIDの欄に他のサイトと重複しない値を入力する。

他の2台のWebサーバーでも該当のサイトが同じIDを持つ様に入力する。

この設定を行った後は、IISを再起動する必要があるので注意。

おまけ：Forms認証を使う場合の注意点

• 一つのWebサイトの下に複数のアプリケーションを配置する場合は、アプリケーション毎に認証クッキーの名前を変える事。


• 認証クッキーのパスは「/」から変更しない方が良い。
  （ブラウザはクッキーのパスについては大文字小文字を区別するが、サーバーはURLの大文字小文字を区別しない為。）

.

Entity Framework 6では非同期DB処理がこんなに簡単に書ける!

MicrosoftのScott Guthrie氏のブログで Entity Framework 6 の Alpha 2 がダウンロード可能になったと報告されている。

Entity Framework 6: Alpha2 Now Available - ScottGu's Blog

改善点としてまっさきに挙げられているのは「非同期処理のサポート」。

.NET 4.5 introduced the Task-Based Asynchronous Pattern that uses the async and await keywords to help make writing asynchronous code easier. EF 6 now supports this pattern. This is great for ASP.NET applications as database calls made through EF can now be processed asynchronously – avoiding any blocking of worker threads. This can increase scalability on the server by allowing more requests to be processed while waiting for the database to respond.
The following code shows an MVC controller that is querying a database for a list of location entities:

（以下意訳）

.NET 4.5ではTaskベースの非同期実行のパターンが追加されました。このパターンでは async と await キーワードを使って非同期に実行されるコードを容易に記述する事が出来ます。EF6 も今回このパターンをサポートしました。
EF経由のデータベース呼び出しを非同期で実行する事が可能になるので、これはASP.NETアプリケーションにとっては非常に望ましい事です。 - つまりワーカスレッドをブロックせずともよくなるのです。これによってデータベースからの応答を待つ間に他のリクエストを処理出来るので、サーバー側でのスケーラビリティの向上に寄与します。
次のコードはLocationエンティティの一覧をデータベースから取得するMVCコントローラの例です。


    public class HomeController : Controller
    {
        LocationContext db = new LocationContext();

        public async Task<ActionResult> Index()
        {
            var locations = await db.Locations.ToListAsync();

            return View(locations);
        }
    }

上のコードを見ると、青字の部分が変わっただけで、他は今までと同じ。とても読みやすい。これだけでコントローラ側が非同期処理になるとは、素晴らしいの一言。

最近は Node.js がかなり注目されているけれども、その理由の一つが「非同期処理によるスケーラビリティの向上」にある。Entity Framework 6で非同期なDB処理がここまで簡潔に書ける様になると、ASP.NETもその方向にまた一歩近づいたという事になると思う。




　

ASP.NET MVCでDbContextのトランザクションと独自SQL 処理のトランザクションを同一のスコープにする

最近毎日 ASP.NET MVC4 でWebアプリケーションを作っている。

今まで独自のO/Rマッパを使っていたので Entity Framework を使い出したのは実はごく最近。

これでSQLを書かなくてもデータの取得や更新が簡単に出来る様になったのは嬉しいのだけれど、当然ストアドプロシージャを呼んだり自分で書いたSQL文を実行したりしたいという場面も結構ある。

そこでいくつかのDBアクセスのパターンを試していて、独自SQLの実行とDbContext経由でのデータ更新を同一のトランザクション内で行いたい、という場合にちょっと困ったので対処方法をメモしておきたい。

とりあえず問題ない例

上の例では別のContextを使っているのでこれはエラーにはならない。 ただしこれだと1つめの更新処理と２つめの更新処理を同一のトランザクション内で実行出来ない。

問題になる例

上の例の様にDbContextからの更新処理をADO.NETのTransaction内に入れた場合は次のようなエラーが起きる。

対処の方法

1. 生成済みのDbConnectionを渡してDbContextを生成する。

DbContextのインスタンスを生成する時に、コンストラクタに既存のDbConnectionを渡すとDbContextで勝手にCloseされる事が無くなる。

これをするためには、DbContextのクラスにDbConnectionパラメータを受け取るコンストラクタを追加する必要がある。



    public class MyEntities : DbContext {

        public MyEntities()
            : base("DefaultConnection") {
        }

        public MyEntities(DbConnection existingConnection)  
            : base (existingConnection, false){ 
        }

        public DbSet<Product> Products { get; set; }
    }

2. EntityConnectionを使ってコネクションをOpenする。

DbContextのDatabase.Connectionは素のSqlConnectionを返す。ただしこれを自分で直接OpenしてしまうとEFの管理情報と一致しなくなる。

DbContextをIObjectContextAdapter型にキャストしてそこからObjectContextを取得し、そのConnectionプロパティ(実態はEntityConnection)に対してOpenを実行すればEFの管理内で処理される。

3. EntityConnectionに対してBeginTransationする。

1、２の後、EntityConnectionに対してBeginTransationしてトランザクションを開始すれば、独自のSQL処理とDbContextのSaveChangesメソッドによる内部的なトランザクションとが同一のスコープで実行可能になる。

対処後の例

動作確認可能な全ソースを含んだサンプルプロジェクトはこちら。

参考にしたURL

This SqlTransaction has completed; it is no longer usable. Entity Framework Code First - Stack Overflow

task parallel library - Entity Framework, SqlCommand and TransactionScope - Stack Overflow

Exception from DbContext API: EntityConnection can only be constructed with a closed DbConnection - Diego Vega - Site Home - MSDN Blogs

EntityConnection can only be constructed with a closed DbConnection

2011 7月 « Do Design Space

.net - Frequent saves with entity framework - Stack Overflow

entity framework - EF Code First DBContext and Transactions - Stack Overflow

　

ASP.NETのWCFサービスでDbContextから取得したオブジェクトを返そうとするとエラーになる場合の対策

先日、ASP.NETのWCFサービスでEntityFrameworkのDbContext経由で取得したモデルクラスのオブジェクトを返そうとして、壁にぶつかった。

発生したエラーの内容はこんな感じ。

Test method ServiceTest.CustLoadData threw exception:
System.ServiceModel.CommunicationException:
An error occurred while receiving the HTTP response to http://localhost:60741/MyService.svc.
This could be due to the service endpoint binding not using the HTTP protocol.
This could also be due to an HTTP request context being aborted
by the server (possibly due to the service shutting down).
See server logs for more details.
---> System.Net.WebException: The underlying connection was closed:
An unexpected error occurred on a receive.
---> System.IO.IOException:
Unable to read data from the transport connection:
An existing connection was forcibly closed by the remote host.

上記のエラーはWCFサービスの呼び出し側で表示されるエラーなので実際に起こっているエラーの原因はちょっと違う部分にある。

いろいろデバッグに苦労したけれど、とりあえずどうやらWCFサービス内でオブジェクトを返すためにシリアライズしようとしている所でエラーが起きているらしい、という事が分かった。

原因は、DbContextの動作原理としてPOCOに対する変更追跡と遅延ローディングを実現するために内部的に「動的プロキシクラス」というものを生成している事にあるらしい。

動的に生成されたプロキシクラスはシリアライズ対象に出来る「既知のクラス」として認識されないのでエラーになってしまう様だ。

POCO エンティティの使用 (Entity Framework)
『Windows Communication Foundation (WCF) では、プロキシを直接、シリアル化または逆シリアル化できません。その理由は、DataContractSerializer では既知の型のみのシリアル化または逆シリアル化ができますが、プロキシ型は既知の型ではないためです。』

結局対策としては

this.Configuration.ProxyCreationEnabled = false;

の１行をDbContextクラスのコンストラクタ内に入れる事で解決した。
これでデータ取得時に動的プロキシが作成されずに純粋なPOCOが返って来るので、シリアライズ時に問題が発生しなくなる。


ちなみにMSDN内の下のページには「シリアル化中にProxyDataContractResolver クラスを使用してプロキシ型を POCO 型にマップ」する方法が載っている。でもちょっと試してみたところ上手く行かなかったので今回はパスした。

チュートリアル: WCF による POCO プロキシのシリアル化 (Entity Framework)

他の解決策として、動的プロキシの作成を抑止せずにWCFサービスでオブジェクトを返す前に手動でPOCOにデータを詰め替えるという方法もある。

データを詰め替えるのはAutomapperなどのライブラリを使えば簡単に出来るので、ProxyCreationEnabled を falseにするという解決策を取りたくない場合はそちらでも良いかも知れない。



その他参考になりそうなURL：

Entity Framework 4, WCF & Lazy Loading Tip | .NET Zone


Entity Framework v4 POCO templates: repository returns object of incorrect type - Stack Overflow

　

DotInstallのTodoアプリケーションをASP.NET MVC4/C#で作りなおしてみた

元のレッスンはこちら。

PHP/jQueryで作るToDoアプリ (全20回) - ドットインストール

作ったものはこちら。

Todo_ASPNETMVC4 - GitHub

Zipダウンロード 

元のアプリケーションがシンプルなだけに特に引っかかる箇所もなくサクサク進んだので楽しかった。

jQuery UIの sortable を使った事がなかったので良い練習になった！

あっ、そう言えば最初の準備段階でこんな問題があったりしてちょっと引っかかった。けどASP.NET MVC4のCode Firstの練習にもなった。^^



　

gitで既にコミットしてしまったファイルを無視する様に変更したい場合は

今日、ASP.NET MVC4の Code Firstを試していてgitでつまづいたので将来の自分用にメモ。

Code FirstでDbContextクラスを作ってモデルクラスを作って、Package Managerコンソールから「Update-Database」を実行すると、無事App_Dataフォルダにデータベースファイルが作成された。

モデルクラスに対応したテーブルも自動的に作成されていて、素晴らしい!

と感動したものの、考えてみるとこのデータベースファイルは出来ればgitの管理下には置きたくない。

ところが気付いた時点では既にGitHubにデータベースファイルもろともpushした後だった。

あわてて .gitignoreファイルに
*.mdf
*.ldf
の２行を追加した。

それから git rm -f *.mdfしてみたり試行錯誤してみたけれども、どうも上手く行かない。

まだまだ git の事を理解していない証拠だな～、とちょっと落ち込む。

とりあえず検索して何とか答えが見つかった。
pushした後に.gitignoreに追加したのが良くなかったみたいだ。

git - Visual Studio gitignore and mdf, ldf files - Stack Overflow

1.  一旦.gitignoreから*.mdf, *.ldfの設定をコメントアウトする。
2. git rm --cached -- *.mdf を実行。
3. git rm --cached -- *.ldf　を実行。
4. git commit -m "コミットメッセージ" を実行。
5. 1でコメントアウトした.gitignoreの設定を戻す。

この操作で無事データベースファイルが除外された。




　

ASP.NET MVC4のBasicテンプレートから作成したプロジェクトでWebGridヘルパーが使えない場合の対処

Visual Studio 2012 + ASP.NET MVC4でWebGridヘルパーが使えないという問題に遭遇した。

プロジェクトを作成する時にテンプレートを選ぶ画面で、EmptyかInternetを選択すると、問題は発生しない。

Basicテンプレートを選択した時のみこの問題が発生する。

そこでEmptyテンプレートから作成したプロジェクトとBasicテンプレートから作成したプロジェクトの違いを調べた結果、次の方法で解決出来る事が分かった。


1. Solution ExplorerのReferenceを右クリックして、「Add Reference」を選択。

2. 「System.Web.Helpers」のVersion 2.0.0.0を選択して追加する。


3. 追加したDLL参照のプロパティを開いて「Copy Local」をTrueに変更する。

この「Copy Local」をTrueにする、というのがミソらしい。


これで無事WebGridヘルパーが使える様になった。


多分近いうちに修正される不具合だとは思うけれど、もし他にもBasicテンプレートを使ったプロジェクトで何か上手く行かなかった場合はこれで治るかも知れない。








.

ASP.NET MVC 4 BetaでWebページを編集中にVisual Studioがフリーズする件

Visual Studio 2010 SP1 + ASP.NET MVC 4 Betaという環境でコピー＆ペーストしようとするとIDEがフリーズしてしまうという現象に遭遇した。

再現手順は次の通り。

1. 新規でASP.NET MVC4 Web Applicationプロジェクトを作成。






テンプレートは「Empty」を選択



2. Solution ExplorerでControllersを右クリックしてコントローラクラスを追加。



3. 作成されたクラスのIndexメソッド上で右クリックしてViewを追加。



4. Index.cshtmlファイルが作成され自動的にその編集画面が開くので、HTMLタグなどを適当に入力して、コピー＆ペーストを実行。



5. Visutal Studioがフリーズして、その後強制終了（再起動）してしまう!



場合によってはコピー＆ペーストをしなくても編集中にフリーズする。

いろいろ検索して、唯一見つけた同様のケースの情報がこれだった。

VS 2010 freezes when pasting text into the editor | Microsoft Connect

一つの回避策として、.cshtmlファイルを開く際に右クリックして「Open With...」というメニューからデフォルトのRazer EditorではなくHTML Editorを選べばエラーが出ないとの情報が得られた。

確かにその通り、HTML Editorで開くと問題ない様だ。
でも毎回その操作をするのは面倒なのでなんとか解決したい。

まずはVS.NETの拡張機能を片っ端からDisableしたりUninstallしたりして試す。
それでもダメなので、ASP.NET MVC 4 Betaを再インストール。まだ直らないのでこの際MVC3, MVC2もアンインストール。

VS.NETのSP1もアンインストールした。すると今度はアンインストールに失敗してしまい、だんだん雲行きが怪しくなって来る。嫌なパターンだ。

結局、案の定Visual Studio 2010全体を最初から入れ直すはめになってしまった。
2010の再インストール後、SP1、MVC3, MVC4 Betaと順に再インストール。
その後気を取り直して、また上記の手順でMVC 4のプロジェクトを新規作成して試すと....

またまたフリーズ！ 再インストールの苦労は一体何だったのか...。

と数時間に渡る格闘の末、ようやく解決策を見つけ出した。
その解決策とは...

『プロジェクトを新規作成した後、ALT + B, U または CTRL+Shift+B を押して一旦ビルドしておく事!』



これで万事OKだ。







.