ASP.NET で HTTP ハンドラーを作成する

以前に投稿した静的コンテンツへの要求を動的に処理するという記事に関連して、
今回は HTTP ハンドラーを作成する方法を紹介します。

ASP.NET で HTTP 要求に対して応答を返す方法としては、
IHttpHandler インターフェイスを実装したクラスを作成する方法があり、
.aspx や MVC を使うよりも原始的です (最も原始的な方法は Global.asax)。
ProcessRequest メソッドの引数で HttpContext オブジェクトが渡されます。
HTTP 要求の情報はここからすべて取得でき、応答もこのオブジェクトに格納します。
これにより、任意の処理を実装できます。

IHttpHandler インターフェイスを利用する方法として、
.ashx ファイルを作成する方法もありますが、これでは拡張子が .ashx に固定されてしまいます。
任意の拡張子を利用するには、通常のクラスとして IHttpHandler インターフェイスを実装し、
Web.config で拡張子や HTTP メソッド (GET など) とのマッピングを指定します。

以下では、.txt へのアクセスに対する HTTP ハンドラーを実装します。

サンプルの全体は HttpHandlerWeb (GitHub) にあります。
なお、このサンプルでは Web アプリケーション プロジェクトではなく、Web サイトを利用しています。
そのため、App_Code フォルダーの下にクラスを配置しています。

これで、.txt へのアクセスを受け付けられるようになりました。

file1.txt

 

以前のバージョン (IIS 6.0 以前?) では、Web.config の system.web/httpHandlers セクションで設定していました。

 

前回:静的コンテンツへの要求を動的に処理する

作成したサンプル
HttpHandlerWeb (GitHub)

バージョン情報
.NET Framework 4.5

参照
チュートリアル : 同期 HTTP ハンドラーの作成 (MSDN)

広告
カテゴリー: .NET Framework. タグ: . 1 Comment »

ランダムなデータを生成する JSON API

Random Data Web API というものを作成しました (正確には、2014 年に作成したものを最近改修しました)。
ランダムなデータを生成するための JSON Web API です。以下のデータを生成できます。

  • アルファベット
  • アルファベットと数字
  • バイト列
    • 16進数形式、Base64 形式
  • UUID (GUID)
  • 時刻順の ID
    • 現在の時刻をもとに、並べ替え可能な GUID を生成
    • SQL Server の uniqueidentifier 型にも対応

内容自体はとくに変哲のない API です。時刻順の ID は少し珍しいかもしれませんが。
また、仕様が記述されたヘルプページ、および jQuery を利用したテストページが付属しています。

Test page

さて、従来の一般的な Web API の問題点として、利用する開発者の意思に反してサービスが終了してしまうということがよくあります。
無償・有償を問わずサービスが永久に提供されるとは限らないため、
なるべく自身のアプリをそれに依存させず、自身でサービスを運用することが望ましいでしょう。

そこでこの Web API では、ソースコードをオープンソース ライセンスのもとで提供し、
それを利用する開発者自身がサービスをホストすることを想定します。
例えば Azure Web App などの PaaS を利用すれば GitHub から直接ビルドおよびデプロイができるため、
簡単な手順でサービスの運用を開始させることができます。
またこの場合は継続的デプロイが構成され、fork したリポジトリが更新されれば Azure Web App も自動的に更新されます。

詳細の方法については Azure Web App にデプロイする手順にまとめてあります。
なお、randomdata.azurewebsites.net は配置例として提供しているものです。このサイトに保証・サポートはありません。

Deployment Option

技術的な特徴としては、以下が挙げられます。

  • ASP.NET Web API
    • XML Formatter を無効化して、JSON 形式のみをサポート
  • ASP.NET Web API Help Page
    • ソースコード内のコメントから自動生成
    • いろいろカスタマイズして利用
  • ASP.NET Web API Cross-Origin Support
    • CORS (Cross-Origin Resource Sharing)
  • HTTPS 必須化

ヘルプページの多言語対応については、ブラウザーの翻訳機能を利用すれば何とかなるでしょう。

Help Translation

バージョン情報

  • .NET Framework 4.5
  • ASP.NET Web API 5.2.3
  • ASP.NET Web API Help Page 5.2.3
  • ASP.NET Web API Cross-Origin Support 5.2.3
  • Blaze 1.1.10

参照

ASP.NET Web API の Tips (2)

ASP.NET Web API を利用する際の注意点や備忘録です。ほぼ箇条書きです。
基本的な説明は省略しています。
(ASP.NET Core Web API 版も書きました。)

例外処理

  • 戻り値が HttpResponseMessage または IHttpActionResult の場合、Request.CreateErrorResponse メソッドなどで HttpResponseMessage を生成する
  • 戻り値が HttpResponseMessage でも IHttpActionResult でもない場合、HttpResponseException を返すことで同様の効果が得られる
  • HttpError を利用して、JSON のエラー メッセージを含めることができる

公式解説: Exception Handling in ASP.NET Web API

Help Page

コードの XML ドキュメントから、ユーザー向けのヘルプ ページを自動的に生成する機能です。
Visual Studio でプロジェクトを作成するときに Web API を選択すると、Help Page もインストールされます。
あとから追加するには、NuGet で Microsoft.AspNet.WebApi.HelpPage をインストールします。

ただし、既定では機能が有効になっていません。

  • 有効にする手順:
    • プロジェクトのプロパティで、XML ドキュメントの出力を有効にする
    • HelpPageConfig.cs のコメントアウトを解除する ( // を取る)

SetDocumentationProvider

  • アクション メソッドの戻り値が HttpResponseMessage または IHttpActionResult の場合、
    [ResponseType(typeof(string))] のように属性でデータの型を指定する
  • Areas\HelpPage にソースコードがあるため、カスタマイズ可能
  • ヘルプ ページ (Help/Index) を既定のページに設定するには、HelpPageAreaRegistration.cs でルーティングの設定を追加するとよい
  • ASP.NET Core Web API では、Help Page を使えない
    • Swashbuckle (Swagger の .NET 向け実装) を使う

HelpPage

公式解説: Creating Help Pages for ASP.NET Web API

Web API の呼び出し

.NET アプリケーションから Web API を呼び出すには、HttpClient クラスを利用するとよいでしょう。
また、サービス側で実装されたカスタム データ型も、サービス コントラクトとして利用できます。
すなわち、応答メッセージに対して response.Content.ReadAsAsync<T>() を呼び出せば T 型としてデシリアライズできます。

公式解説: Call a Web API From a .NET Client (C#)

CORS

  • NuGet で Microsoft.AspNet.WebApi.Cors をインストールする
  • WebApiConfig.cs で config.EnableCors メソッドを呼び出すことで機能を有効にする
    • 引数に EnableCorsAttribute を渡すとグローバルに設定できる
    • コントローラー、アクションのレベルでは [EnableCors] を指定する

CORS が機能しているかどうかをテストする方法については ASP.NET Core Web API の Tips に書きました。

公式解説: Enabling Cross-Origin Requests in ASP.NET Web API 2

JSONP

未検証。

  • MediaTypeFormatter を利用する
    • WebApiContrib.Formatting.Jsonp など

フォーマット

ASP.NET Web API は、既定で JSON と XML をサポートします。
要求の Accept ヘッダーに何が指定されているかで結果のフォーマットが変わります。
Google Chrome 上で Web API を直接呼び出すと結果が XML 形式で返ってきます。
これは、要求の Accept ヘッダーに application/xml が含まれているためと考えられます。
これを JSON 形式にするには、text/html が含まれている場合に JSON を返す設定や XML 形式を無効にする設定が考えられます。

解説: How do I get ASP.NET Web API to return JSON instead of XML using Chrome?

 

前回: ASP.NET Web API の Tips (1)

作成したサンプル

バージョン情報

  • .NET Framework 4.5
  • ASP.NET Web API 5.2.3
  • ASP.NET MVC 5.2.3
  • ASP.NET Web API Help Page 5.2.3
  • ASP.NET Web API CORS 5.2.3

参照

カテゴリー: .NET Framework. タグ: , . 1 Comment »

ASP.NET Web API の Tips (1)

ASP.NET Web API を利用する際の注意点や備忘録です。ほぼ箇条書きです。
基本的な説明は省略しています。
(ASP.NET Core Web API 版も書きました。)

ルーティング

WebApiConfig.cs にルーティングの設定が記述されています。
既定のテンプレートは api/{controller}/{id} となっており、REST スタイルを想定したものとなっています。
ただし、ASP.NET MVC と同様に {action} も利用可能であり、RPC スタイルの API も構成できます。

  • [RoutePrefix], [Route], [ActionName] などの属性を利用することで柔軟に構成できる
  • [Route] を複数設定できる

公式解説: Web API Routing

HTTP メソッド

  • 主に REST スタイルの場合、Get、Post などのメソッド名で解決される (CoC)。
    この場合、[HttpGet] などの属性を指定する必要はない
  • 主に RPC スタイルで任意のアクション名を利用するには、[HttpGet] などの属性を指定する

引数

  • DateTime, Guid などの型も扱える
  • 引数の [FromBody] は、エンティティ型なら付ける必要はない
  • ルーティングで {i:int:range(0,100)} のような制約を追加できる
  • 引数に既定値を指定すると、URL のパラメーターを省略可能
    • ルーティングで指定する場合は {i:int?} のようにする
    • range などを使う場合、省略可能にできない
      • int? と range は同時に指定できない
  • 引数で / を使う場合、引数名の前に * を指定する (下の DateTime 型の例)

公式解説: Attribute Routing in ASP.NET Web API 2

戻り値

戻り値として、通常のデータ型以外に次のものを指定できます。

  • HttpResponseMessage
    • 生の応答データ
  • IHttpActionResult
    • HttpResponseMessage をラップしたインターフェイス

これらを利用することにより、応答データを柔軟に設定できます。

  • JSON や XML に限らず、テキストや画像などの任意の形式のコンテンツを返せる
  • 主な IHttpActionResult の実装は System.Web.Http.Results 名前空間で定義されている

以下は、テキスト (Content-Type: text/plain) を返す例です。

公式解説: Action Results in Web API 2

 

次回: ASP.NET Web API の Tips (2)

作成したサンプル

バージョン情報

  • .NET Framework 4.5
  • ASP.NET Web API 5.2.3

参照

カテゴリー: .NET Framework. タグ: , . 3 Comments »

ビルドして ZIP にする PowerShell スクリプト

以前に .NET ビルド小技集 (4) という記事を書き、
PowerShell でバージョンをインクリメントしてビルドする方法を紹介しました。
今回は、そのツールを改良したうえで NuGet で公開しました。

Visual Studio のプロジェクトに対して、NuGet で KTools.ZipRelease をインストールすると、
次の PowerShell ファイルがプロジェクトに追加されます。

  • KTools.VersionIncrement.ps1
  • KTools.ZipRelease.ps1

image

エクスプローラー上で PowerShell スクリプトを実行できます。

image

KTools.ZipRelease.ps1 により、以下の処理が実行されます。

  • バージョン番号のインクリメント (KTools.VersionIncrement.ps1 の呼び出し)
  • MSBuild.exe を利用して Release ビルド
  • ビルドの結果を ZIP ファイルにする
    • ファイル名は「AssemblyName-x.y.z.zip」の形式
    • 既定ではプロジェクト フォルダーの下の「zip」フォルダーに作成される

image

 

KTools.VersionIncrement.ps1 により、AssemblyInfo.cs 内の
AssemblyVersion 属性および AssemblyFileVersion 属性の値のビルド番号を 1 だけ増加させています。
例えば、1.0.2.0 が 1.0.3.0 に、1.0.2 が 1.0.3 に、1.0.2-alpha が 1.0.3-alpha に変わります。

ちなみに、バージョン番号は .exe および .dll ファイルのプロパティに反映されます。

image

PowerShell スクリプトのため、各自の要件に合わせてカスタマイズできるでしょう。
また、バージョン番号のインクリメントについては、
KTools.VersionIncrement として単独でインストールして使うことができます。

 

技術的には、以下の特徴が挙げられます。
ソースコードは Build Release (GitHub) にあります。

  • PowerShell の中で C# を利用
  • 値を変更する処理で正規表現を利用
  • .csproj ファイルからの値の読み込みに XPath を利用
  • MSBuild.exe のパスを探索 (たいへん)
    • .NET Framework 付属の MSBuild より Visual Studio 付属の MSBuild を優先

 

追記: ビルド用のスクリプトを Visual Studio の「外部ツール」に登録すると便利です。
また、.NET Core プロジェクト形式向けのビルド スクリプトも追加しました。

作成したツール
Build Release (GitHub)

参照
.NET ビルド小技集 (4)
.NET Framework の正規表現
.nuspec リファレンス
NuGet Package Version Reference

Azure と VSTS で継続的デプロイ (2017)

以前に Azure と GitHub で継続的インテグレーション
Azure と Visual Studio Online (Git) で継続的インテグレーションなどの記事を書きましたが、
情報が古くなっているため、現在の環境で改めて検証しました。

現在の Azure Web App でバージョン管理システムからの継続的デプロイ (Continuous Deployment, CD) を構成する方法としては、

  • [デプロイ オプション] を設定する
  • [継続的配信] を設定する (ただしプレビュー)

の 2 種類があり、いずれかを選択することになります。

image

いずれの方法でも、バージョン管理システムとして Visual Studio Team Services (VSTS) も GitHub もサポートしています。
この 2 つの主な違いは、

  • [デプロイ オプション] では、リポジトリ内に含められる Web アプリケーションは 1 つ。
  • [継続的配信] では、対象の .sln を指定できるため、リポジトリ内に Web アプリケーションが複数存在してもよい。
    その他にも、細かい設定ができる。

です。

 

[デプロイ オプション] を設定する方法については前回の Azure と GitHub で継続的デプロイ (2017) で書きました。
今回は Visual Studio Team Services (VSTS) の Git リポジトリに対して [継続的配信] を設定してみます。

まず VSTS の Git リポジトリに Web アプリケーションを commit/push します。
今回は例として、ASP.NET MVC Web アプリケーションとします。
リポジトリに bin フォルダーなどを含める必要はありません。

image

 

次に、Azure で Web App を作成します。

image

作成が完了したら、その Web App の [継続的配信] を構成していきます。

image

ソースとして VSTS を選択し、アカウント、リポジトリ、ブランチを選択します。

image

 

基本的な設定はこれだけです。設定完了と同時に、ビルドとデプロイが開始されます。

image

以降も、ソースコードを変更してリポジトリに commit/push するだけで、自動的にビルドとデプロイが実行されます。 
開発時には、開発用のブランチおよび Web App を利用するとよいでしょう。

image

VSTS のリポジトリの [Services] で、Azure Web App と連携していることを確認できます。

image

 

VSTS の Web 画面で、ビルド定義の表示・編集ができます。詳細の設定はここでできます。
なお、Visual Studio 上での表示・編集はできなくなっているようです。

主に使われる設定としては以下が挙げられるでしょう。

  • ビルド定義の名前の変更
  • .sln ファイルのパスの指定
  • ブランチの変更
  • 継続的デプロイか、手動デプロイか (Enable continuous integration)
  • ビルド番号の形式

image

image

image

ビルドで生成された実行ファイルは [Artifacts] で取得できます。

image

[Release] から、過去のバージョンを選択して再デプロイすることもできます。

image

 

注意点:

  • VSTS 以外の Git (GitHub など) でも同様の手順で構成できますが、
    ビルド定義を VSTS のリポジトリに保存するため、VSTS のアカウントが必要です。
  • 管理者権限を与えられた別の Azure アカウントだと、エラーが発生して [継続的配信] を設定できませんでした。

 

前回:Azure と GitHub で継続的デプロイ (2017)

参照
Build and deploy to an Azure Web App

Azure と GitHub で継続的インテグレーション (旧版)
Azure と Visual Studio Online (Git) で継続的インテグレーション (旧版)

Azure と GitHub で継続的デプロイ (2017)

以前に Azure と GitHub で継続的インテグレーション
Azure と Visual Studio Online (Git) で継続的インテグレーションなどの記事を書きましたが、
情報が古くなっているため、現在の環境で改めて検証しました。

現在の Azure Web App でバージョン管理システムからの継続的デプロイ (Continuous Deployment, CD) を構成する方法としては、

  • [デプロイ オプション] を設定する
  • [継続的配信] を設定する (ただしプレビュー)

の 2 種類があり、いずれかを選択することになります。

image

いずれの方法でも、バージョン管理システムとして Visual Studio Team Services (VSTS) も GitHub もサポートしています。
この 2 つの主な違いは、

  • [デプロイ オプション] では、リポジトリ内に含められる Web アプリケーションは 1 つ。
  • [継続的配信] では、対象の .sln を指定できるため、リポジトリ内に Web アプリケーションが複数存在してもよい。
    その他にも、細かい設定ができる。

です。
Web アプリケーションが 1 つしか含まれていないリポジトリをシンプルに運用したいのであれば、[デプロイ オプション] でよいでしょう。

 

以下では GitHub のリポジトリに対して [デプロイ オプション] を設定してみます。
なお、GitHub 以外の Git (VSTS など) でも同様の手順で構成できます。
[継続的配信] については次回の Azure と VSTS で継続的デプロイ (2017) で書いています。

まず GitHub のリポジトリに Web アプリケーションを commit/push します。
今回は例として、ASP.NET MVC Web アプリケーションとします。
リポジトリに bin フォルダーなどを含める必要はありません。

image

リポジトリはパブリックでもプライベートでもかまいませんが、
自分が所有しているリポジトリでなければならないため、他の人のリポジトリであれば fork しておきます。

 

次に、Azure で Web App を作成します。

image

作成が完了したら、[デプロイ オプション] を構成します。
ソースとして GitHub を選択すると、アカウント承認の画面が現れます。
さらにリポジトリとブランチを選択します。

image

 

必要な設定はこれだけです。設定完了と同時に、ビルドとデプロイが開始されます。
[継続的配信] では数分かかるのに対して、かなり早く完了します。

image

以降も、ソースコードを変更してリポジトリに commit/push するだけで、自動的にビルドとデプロイが実行されます。
開発時には、開発用のブランチおよび Web App を利用するとよいでしょう。

image

過去のバージョンを選択して再デプロイすることもできます。

image

GitHub のリポジトリの [Settings] – [Webhooks] で、Azure Web App と連携していることを確認できます。

image

 

次回:Azure と VSTS で継続的デプロイ (2017)

参照
Azure App Service への継続的なデプロイ

Azure と GitHub で継続的インテグレーション (旧版)
Azure と Visual Studio Online (Git) で継続的インテグレーション (旧版)

カテゴリー: ALM, クラウド. タグ: , . 3 Comments »