ASP.NET MVC – テスターですが何か？

ASP.NET MVCのクラスの作り方を考えてみた(4)

前回のブログエントリーでUnityでのインターフェースと型のマッピングがC#には書けず、設定ファイルに書かなければならないという内容を書きましたが、実はC#にもマッピングの設定を記述することができます。あまりに自分が無知ですみません。このブログエントリーを見て気づきました。

IoCフレームワーク、クラスとConfigファイルの両方から設定する (miso_soup3さん)

設定方法は、UnityContainer.ResisterTypeでインターフェースと型を登録します。C#で設定を行うのでintellisenseが効いてタイプミスを防ぐことができます。Global.asax.csのApplication_Startにはこのように記述します。UnityContainer.LoadConfigurationをコメントアウトしているのは、設定ファイルを作成しているとこのメソッドを呼び出した際に設定が上書きされてしまうためです。

IUnityContainer container = new UnityContainer();

// Unity用マッピング設定

container.RegisterType<IHogeWorkerService, HogeWorkerService>();

container.RegisterType<IHogeDao, HogeDao>();

//container.LoadConfiguration();

IDependencyResolver resolver = new UnityDependencyResolver(container);

DependencyResolver.SetResolver(resolver);

C#でUnityのマッピング設定を行うことができることがわかったので、もう使わない手はないですね。DIなしで単体テストを行うなんて狂気の沙汰ですから。（単体テストを行わないなんてもっと以下略） #if debugを使用すればテスト用とRelease用の設定も分けることが（たぶん）できるでしょうし。やっぱり個人的にはUnityを使う場合はC#でマッピングの設定を書きたいですね、設定ファイル地獄はC#の文化には合わないと思います。

今回はUnityをテーマに書きました。作成したソースはSkyDriveにアップしてあります。「MvcHogeApp_v4」をダウンロードしてください。サイズを抑えるため、アセンブリ類は削除してあるのでVisual Studio 2012 Express for Webがインストールされた環境で開いてください。

ASP.NET MVCのクラスの作り方を考えてみた(3)

何回シリーズになるか分かりませんが、「プログラミング ASP.NET MVC」を読んでASP.NET MVCのクラス構成について考えた記事を書いています。これまで2回書いており、内容は以下の通りです。

第3回目はpatterns&practicesのProject Silkで利用されているUnityを利用したDIについて書きます。Unityは制御の反転(IoC:Inversion of Control)を実現するためのフレームワークです。IoCとはDIの1つ上、抽象化された概念だと思ってください。IoCを実現するための実装の1つがDIになります。（用語や概念を厳密に説明できるほど理解が進んでいないです）詳しいことを知りたい方は、以下のページを良く読んでください。

制御の反転

Unity におけるポリシーの挿入

Project SilkやUnityについてはすでにブログで書いている方がいらっしゃるので、最大限参考にさせていていただきました。

ASP.NET MVC 3 と Unity の組み合わせを試し中 (shibayanさん)

Project SilkにならってUnityを使ってみる (miso_soup3さん)

今回は(2)で作成したソースをUnityに対応させたいと思います。まずはNugetでインストールします。

PM> Install-Package Unity
依存関係 ‘CommonServiceLocator (≥ 1.0)’ の解決を試みています。
‘CommonServiceLocator 1.0’ が正常にインストールされました。
Unity を Microsoft patterns & practices からダウンロードします。このライセンス条項は http://www.opensource.org/licenses/ms-pl で参照できます。固有のライセンス条項がある追加の依存関係がパッケージに含まれていないかどうかを確認してください。パッケージおよび依存関係を使用することで、該当するライセンス条項に同意したものとみなされます。ライセンス条項に同意しない場合は、関係のあるコンポーネントをデバイスから削除してください。
‘Unity 2.1.505.0’ が正常にインストールされました。
‘CommonServiceLocator 1.0’ が MvcHogeApp に正常に追加されました。
‘Unity 2.1.505.0’ が MvcHogeApp に正常に追加されました。

Web.configにインターフェースと実装クラスのマッピング設定を記述します。

<?xml version="1.0" encoding="utf-8"?>

</configSections>

</container>

</unity>

</configuration>

Project SilkではWeb.configではなく専用の設定ファイル(Unity.config)にマッピング情報を記載していました。また<register>タグで指定するマッピング情報では名前空間を省略せずに書いてありました。

次にリゾルバの設定です、なぜかIDependencyResolverインターフェースを実装した、欲しいインスタンスを取得するリゾルバが提供されていないので、自分でコードを書く必要があります。今回はProjet Silkで実装されている「UnityDependencyResolver.cs」をそのまま利用しました。このとき知ったのは、Unity関連のクラスはMicrosoft.Practices.Unity名前空間にあるんですね。Unityがルートじゃないんですね。

そしてリゾルバの設定です、Global.asax.csのApplication_Startに設定を行います。

protected void Application_Start()

{

IUnityContainer container = new UnityContainer();

container.LoadConfiguration();

IDependencyResolver resolver = new UnityDependencyResolver(container);

DependencyResolver.SetResolver(resolver);

}

こうすることで、引数なしのコンストラクタが不要になります。Web.configに記載したマッピングの設定にしたがってUnityがインスタンスを取得してくれるためです。コードはこうなります。（わかりやすくするために、以前のコードも残してあります）多少コードがすっきりしたことがわかると思います。

public class HogeWorkerService : IHogeWorkerService

{

private IHogeDao Dao;

// 通常のコンストラクタ

//public HogeWorkerService()

//{

// Dao = new HogeDao();

//}

// DI用(コンストラクタインジェクション)コンストラクタ

public HogeWorkerService(IHogeDao dao)

{

Dao = dao;

}

// コントローラーから呼び出されるメソッド

public HogeViewModels MakeHoge()

{

// 省略

}

今まで通り、引数付きのコンストラクタは単体テスト用に必要です。

Unityを使った感想ですが、それほどDIフレームワークを利用するメリットが思いつかないです。コードがややすっきりするのは確かですが、デフォルトコンストラクタがなくなるだけなので、それほど劇的に変わりません。逆に、設定ファイルに型・インターフェース名を文字列として記載するのでタイプミスでエラーが発生してハマるリスクのほうが大きい気が．．．（昔S2Containerのdiconファイルの記述でハマった悪夢が蘇りました）

ただ、Release/Debug用に設定ファイルを分けることで、取得するインスタンスを切り替えることができますし、単体テストプロジェクトにも設定ファイルを作成して、リゾルバを設定することで引数付きコンストラクタもなくすことができると思います。(Project Silkではそこまでやっていませんでしたが）使うのであれば、プロダクションコード、テストプロジェクトまで徹底的に使わないと、使い方を覚えるコストをペイできないんじゃないかなぁ、と思いました。手放しで「素晴らしい！」とは言えませんでした。う～ん。

Unityの単純な使い方ではなくて、シナリオがあってUnityを使うとこんなに素晴らしくなるという説明を誰かブログに書いてくれないですかねぇ。自分は書けませんでした。

今回はUnityをテーマに書きました。作成したソースはSkyDriveにアップしてあります。「MvcHogeApp_v3」をダウンロードしてください。サイズを抑えるため、アセンブリ類は削除してあるのでVisual Studio 12 Express for Webがインストールされた環境で開いてください。

ASP.NET MVCのクラスの作り方を考えてみた(2)

前回のエントリーでざっくりしたクラス構成を作成しました、今回はそれに対する単体テストコードを作成します。

前回作ったASP.MVCのコードは以下の構成になっていました。

Controllerが呼び出すコーディネーター的な役割のWorkerServiceクラスを作成
DI(コンストラクタインジェクション)でインターフェースと実装を分離

今回単体テストを実装するにあたっての前提は以下のとおりです

単体テストフレームワークはMSTestを使用します(Visual Studio 2012 Express for Webに同梱)
Mock用フレームワークはMoqを使用します

本当、ホビープログラマーがVisual Studioから単体テストを実行できる時代が来るとは思いませんでした。Visual Studio 2012 Expressには単体テスト機能が含まれています、Visual Web Developer 2010+Nunitで開発するなら、Visual Studio 2012 Express for Webを使いましょう。

まずはNugetを使ってソリューション作成時にあわせて作成したテストプロジェクトにパッケージをインストールします。

PM> Install-Package Moq
‘Moq 4.0.10827’ は既にインストールされています。
‘Moq 4.0.10827’ が MvcHogeApp.Tests に正常に追加されました。

まずはControllerのテスト(HogeControllerTest.cs)を作成します

[TestClass]

public class HogeConrtollerTest

{

// Moqを使ったテスト

[TestMethod]

public void TestMethod1()

{

// mockの作成

var Mock = new Mock<IHogeWorkerService>();

Mock.Setup(m => m.MakeHoge()).Returns(new HogeViewModels

{

HogeId = 1,

HogeName = "HogeHoge"

});

// アクションメソッドの呼び出し

var Target = new HogeController(Mock.Object);

var Result = Target.Index() as ViewResult;

var ViewModel = Result.ViewData.Model as HogeViewModels;

// assert

Assert.AreEqual(1, ViewModel.HogeId);

Assert.AreEqual("HogeHoge", ViewModel.HogeName);

}

ServiceWorkerクラスは各種ビジネスロジッククラス、データアクセスクラスなどを呼び出します。そのため、単純にServiceWorkerクラスのメソッドを呼び出してしまうと、それら各種ビジネスロジッククラス、データアクセスクラスの都合に引っ張られてしまいます。簡単な例としては単体テストを実行する環境にデータベースが作成されていて、テーブルが作成されていて、テストの条件に必要なデータが全部揃っている必要があります。また、呼び出し先のクラスメソッドが実装されていて、そのクラスにはバグがない状態でなければServiceWorkerクラスのテストができません。ServiceWorkerクラスのバグなのか、呼び出し先のクラスのバグなのか切り分けが必要になってしまいます。

そのため、呼び出し先クラスのmockを作成して、テストされるクラスにとって都合のいい（テスト条件に合った）固定の戻り値を返すように設定します。この場合はHogeWorkerService.MakeHogeメソッドの戻り値HogeViewModelsが固定値になるようにします。そしてこのモックをテスト対象クラスのコンストラクタの引数に指定します。これが、前回DIを採用した理由です。

ネット上にあふれている単体テストの記事を見ていると、単体テストができそうな気がするかもしれません。ただ、クラスの呼び出しは階層化されており単体テストをしたいクラス・メソッドから呼び出しているメソッドの戻り値を考慮しなければならず、これが現実の単体テストを難しくしている、ハードルを高くしている原因だと思います。なので（自分の身の回りでは）、単体テストは行われていません、UIを操作して手動でテストしたほうがはるかに簡単と考えられています。しかし、MockとDIを採用することで現実的な難しさまでハードルを下げることができると思います。

そして、WorkerSeriveの単体テストコードはこのようになります。

[TestClass]

public class HogeWorkerServiceTest

{

[TestMethod]

public void TestMethod1()

{

// mockの作成

var Mock = new Mock<IHogeDao>();

Mock.Setup(m => m.GetHogeList()).Returns(

new List<HogeModels>

{ new HogeModels { Id=1, HogeName="HogeHoge"}}

);

// メソッドの呼び出し

var Target = new HogeWorkerService(Mock.Object);

var Result = Target.MakeHoge();

// assert

Assert.AreEqual(1, Result.HogeId);

Assert.AreEqual("HogeHoge", Result.HogeName);

}

現実のクラスはMock作成時の戻り値設定はこんなに簡単には行かないでしょうが。それでも「単体テスト」といいつつ、階層的に呼び出しを行ってテストをすることに比べれははるかに簡単になると思います。

今回は単体テストをテーマに書きました。作成したソースはSkyDriveにアップしてあります。「MvcHogeApp_v2」をダウンロードしてください。サイズを抑えるため、アセンブリ類は削除してあるのでVisual Studio 12 Express for Webがインストールされた環境で開いてください。

次はUnityを使ったDependectyResolverについて書きたいですね。

// なんで単体テストクラスのテンプレートに

// using System.Collections.Generic;

// using System.Linq;

// が含まれていないんだろう？軽くはまりましたわ。単体テストクラスのテンプレートはかなりすっきりしたのに、ちょっと残念

ASP.NET MVCのクラスの作り方を考えてみた(1)

以前のエントリーで紹介した「プログラミングASP.NET MVC」を読んだこと、.NETラボ勉強会でMVVMの話を聞いたこともあって、ASP.NET MVCでどのようにクラスを作っていくのかを考えてみました。プロジェクトテンプレートにはControllerクラスしかありませんし、スキャフォールドで作成したコードはControllerが直接データアクセスクラスを呼び出しいているし。ネットには超単純なシナリオにしか（現実的にありえないような）対応出来ないコードだし。

ネットで公開されているようなコードはわかりやすく・単純化するために仕方がないと思います。確かに新機能の説明や「ASP.NET MCとは」という内容に200～300行書かれても読む気がなくなってしまいますから。しかし、patterns&practicesで公開されている「Project Silk」や「Project Liike」のコード、現実のアプリケーション開発のコードはそれらネット上のサンプルからの乖離（飛躍）が非常に大きく、サンプルと現実の溝を少しだけ埋めてみようかなと思った次第です。

一発で「こうだ」というコードが公開できるとは考えていないので、ブログを書きつつ、考えつつ、軌道修正していくので複数回のブログになると思います。あと、前もって断っておきますが書籍「プログラミング ASP.NET MVC」の内容の自分なりの理解内容を発言することになると思います。とくにオリジナリティはないと思います。

今回はControllerクラスの設計について考えてみました。具体的には、この3つのテーマです。

Controllerクラスには何を記述すべきか
クラス同士の依存性をいかにして弱くするか
MVCの「C」と「M」の境目はどこになるのか

Controllerクラスには何を記述すべきか

Controllerの責務はクライアントからHTTPリクエストを受け取って、HTTPレスポンスを返す(Viewを返す)ことです。それ以上でもそれ以下でもありません。建物の出入口に当たる部分になり、クライアントの都合に引っ張られる部分になります。そして、セッション管理などのWeb/HTTPに依存する処理は担当するものの、いわゆるビジネスロジックと呼ばれる部分はコントローラーには記述しません。その役目はModelの部分が担います。Modelはなるべくクライアントアーキテクチャーに依存しないように作成したほうが、汎用性/再利用性が増すため、Webというアーキテクチャーに依存する部分はControllerに記述すべきだと考えます。ViewはModelのことを知らないですし、ModelはViewのことを知らないわけですから、クライアントアーキテクチャーに依存する部分はControllerが担当するのは自然なことだと思います。

そしてControllerに対して1つのWorkerServiceと呼ばれるクラスを作成します。ControllerとWorkerServiceは1対1で紐付き、Controllerで受け取ったHTTPリクエストに対する処理を行います。Controllerから必ず1つのWorkerServiceを呼び出します。複数のControllerから共通のWorkerServiceを呼び出しても構いません。そして、WorkerServiceはコーディネーターとしての役割を担います、WorkerService自体にはいわゆるビジネスロジックは記載せずに、複数のビジネスロジッククラスを呼び出して処理を行います。そして処理結果をViewModelとしてControllerに返します。Controllerは自分が知っている1人のWorkerServiceに処理を委ねます、WorkerServiceは自分が知っている複数のビジネスロジッククラスを呼び出して、処理結果をViewModelとしてControllerに返します。ConrotollerはHTTPリクエストの受付、WorkerServiceはビジネスロジックの実行を受け付けます。

図にするとこうなります。

クラス同士の依存性をいかにして弱くするか

クラス同士の依存性を弱くすると何が嬉しいのか、何なんでしょうねぇ．．．一番のメリットはテストがしやすくなることです。コードを変更せずに依存するクラスを変更することができれば、Mockを使ったテストがやりやすくなります。それ以外のメリットは．．．すみませんよくわかりません。個人的な実装と実行の分離の現実界は、DI(Dependency Injection)の利用かなとおもいます。実装クラスにに対してインターフェースを用意し、コンストラクタで依存性を注入するやり方です（コンストラクタインジェクション）。

このやり方の最も現実的なところは、依存性の型情報をC#のコードとして記述できることです。DIコンテナとしてSearsarプロジェクトのS2Containerを利用したことがありますが、設定ファイルに文字列として型情報のマッピングを記載しています。個人的にはtypoまみれになるので設定ファイルの利用が嫌いです、マッピングを文字列ではなく型情報をとしてコードで記述できれば、インテリセンスが効きますしtypoをかなり防ぐことができます。設定ファイルにマッピング情報を記述してtypoでハマると悲惨ですよ．．．ハイ。なのでS2Cotainer.NETのQuillの考え方はすごく好きです。ASP.NET MVC+C#の考え方なら、設定ファイルでゴリゴリ書くよりもコードで書くほうが合うと思うんですよね。

あと、プロダクションコードではDI目的のインターフェースと実装クラスは1対1になるので同じファイルに書いてしまったほうがコードの見通しが良くなると思います。

Unityも確か設定ファイルにマッピン情報を記載したはずです。Project Silkのコードをしっかり読んでないとか、Unityについてほとんど調べてないです、すみません．．．

MVCの「C」と「M」の境目はどこになるのか

ControllerとServiceWorkerの話が出現すると、「C」と「M」の境目はどこなのか、ServiceWorkerは「C」なのか「M」なのかという話題になるかもしれません。個人的には

「(´・ω・`)知らんがな」

です。「C」と「M」って論理的な考え方なので、物理的なクラスがどちらに属するかを真剣に議論してもねぇ。論理的な考えに基づいてきちんとクラスの責務が決められていればいいと思うんですよ。敢えてどちらかと言えば「C」かと思います、ServiceWorker自体はビジネスロジッククラスの呼び出しを行なってViewModelを作っているだけなので、「C」なのかな、と。

そして出来上がったコードはこのようになりました

Controller

public class HogeController : Controller

{

private IHogeWorkerService WorkerService;

// 通常のコンストラクタ

public HogeController()

{

WorkerService = new HogeWorkerService();

}

// DI用(コンストラクタインジェクション)

public HogeController(IHogeWorkerService workerService)

{

WorkerService = workerService;

}

// アクションメソッド

public ActionResult Index()

{

// コントローラーはHTTPリクエストを受け取って

// HTTPレスポンス(View)を返すのみ

// Webに依存する部分（セッション管理など）のみを担当する

// アクションフィルタでできることはアクションフィルタで済ませる

// アプリケーションとしての処理はすべてWorkerServiceに委ねる

// ViewModelの作成もWorkerServiceに任せる

// 1つのアクションメソッドで1つのWorkerServiceの呼び出しを行う

// コントローラーはこのようなすっきりとしたものになるはず

var ViewModel = WorkerService.MakeHoge();

return View(ViewModel);

}

WorkerService

// DIのためのインターフェース、実装クラスと1対1なので同じファイルにしてしまってもいいと思う

public interface IHogeWorkerService

{

HogeViewModels MakeHoge();

}

// WorkerServiceクラス、コントローラーから処理を任される

// このクラスから各種ビジネスロジッククラスを呼び出して

// アプリケーションの仕様を実現する

public class HogeWorkerService : IHogeWorkerService

{

private IHogeDao Dao;

// 通常のコンストラクタ

public HogeWorkerService()

{

Dao = new HogeDao();

}

// DI用(コンストラクタインジェクション)コンストラクタ

public HogeWorkerService(IHogeDao dao)

{

Dao = dao;

}

// コントローラーから呼び出されるメソッド

public HogeViewModels MakeHoge()

{

// この例ではデータベースアクセスを行う処理だけを呼び出しているが

// 現実はもっとたくさんのメソッド呼び出しを行うはず

var Hoge = Dao.GetHogeList().First();

// ViewModelの作成はこのクラスで担当する

return new HogeViewModels

{

HogeId = Hoge.Id,

HogeName = Hoge.HogeName

};

}

Model(データアクセスクラスのみ)

// DIのためのインターフェース、実装クラスと1対1なので同じファイルにしてしまってもいいと思う

public interface IHogeDao

{

IEnumerable<HogeModels> GetHogeList();

}

// データアクセスクラス「XXXRepository」という名前にするのは違和感がある

// 「Models」ディレクトリでいいんだろうか．．．

public class HogeDao : IHogeDao

{

public IEnumerable<HogeModels> GetHogeList()

{

using (var db = new MvcHogeAppContext())

{

return db.HogeModels.ToList();

}

作成したソース（ソリューション一式）はSkyDriveにアップしてあります、「MvcHogeApp」をダウンロードしてください。サイズを抑えるため、アセンブリ類は削除してあるのでVisual Studio 12 Express for Webがインストールされた環境で開いてください。

「プログラミングASP.NET MVC」読みました

4月のWindows Developer Daysで買った「プログラミングASP.NET MVC」をやっと読み終えました。自分自身に対して「今さらかよ」と突っ込みたくなりますが…素晴らしい本でした。

本書の対象はASP.NET MVCの開発経験がある、または、サンプルソースを読んだことがあり、このフレームワークを利用してどのようにプログラムを記述するかを理解している人、さらに、包括的に、深くASP.NET MVCについて理解したい人だと思います。

「ASP.NET MVCとは」や「そもそもWebFormとは何が違うの？」についてはほぼ触れられていないため、初心者ではなく中級者がより理解を深めるために読む内容になっています。自分も個人的に簡単なアプリを作成したことがあり、（ちょっとサバを読むと）自称中級者なので、この本の対象としてはぴったりだったかもしれません。

本書の中で一貫して書かれていることは、ASP.NET MVCの柔軟性です。素の機能をだけを使用しても、これまでのASP.NET以上にアプリケーションが作りやすくなっていますが、それに加えてASP.NET MVCはほぼすべての要素が使いやすくカスタマイズすることができます。ビューエンジン、ルーティング、モデルバインダー、HTMLヘルパー、属性といったありとあらゆる要素に対して、カスタムモジュールを追加・標準モジュールを置き換えることができます。「第1部 ASP.NET MVCの基礎」では、標準機能の説明を行ったあとにあるシナリオにもとづいてカスタム機能をどのように実装するかについて触れています。

個人的に読んでいて興味を持ったのは、第2部(7章、8章）のコントローラーの設計の部分についてです。MVCの「C」部分にはどんな処理を書くべきか、その延長上にMVCの「M」とは何か、について記載があります。自分のようなレベルの低いエンジニアの書くプログラムは（しかもサンデープログラマーなので書く前にちゃんと設計しない）コントローラーに処理（ロジック）を記載してしまいます、で、Mの部分はデータアクセスのみ。ネット上に大量にあふれているサンプルコードもこのように書かれているケースが多いですが、サンプルのような超シンプルなシナリオだから破綻しないだけで、通常のシナリオではコードが破綻します。自分の経験上、比較的簡易なシナリオでもコントローラーに処理が満載になってしまって我に返ることがあります。コントローラーはHTTPリクエストの受付と、レスポンスの返却を行います、モデルバインダ経由で受け取ったViewModelをどう扱うかは、Modelに任せます。それがWebアプリケーションのMVCのパターンです。（たぶん）あまり長く書くとボロが出るので、この辺に興味がある方はこの本の7章、8章を読むといいと思います。キーワードとしては「ぜい肉のないコントローラー」「iPODDパターン」「ServiceLocatorモデル」でしょうか。

この本は現実にはありえないような超シンプルなシナリオではなく、より現実に即したシナリオにも適用できるべく記述されているため、読んだ内容が次々に頭に入ってくるというわけではありません。もともと中級者以上向けの内容に加えて、現実にありあり得るパターンに対応しようとすると、自分のCPU（脳みそ）では知恵熱が出てしまいます。わかったような…わからないような…中途半端な気分になります。

そして、ふとこんなつぶやきをしてしまいました。

すると意外に反応があって、この本の内容、もしくは中級者以上向けのフォローの場って需要があるんだなと感じました。読書会は定期的に複数回開催されるもののようなので難しいですが、自分も中級者以上向けの勉強会というかイベントには参加してみたいです。

ということでこんな内容を聞いてみたいと妄想してみました。他の方のブログやプレゼンテーションを引用させていただいています、問題がある場合はTwitter(@david9142)または、ブログのコメントで連絡ください。

タイトルは

「ぼく/わたしのかんがえたさいきょうのえーえすぴーどっとねっとえむぶいしー」

初心者は完全に置き去り、中級者に対してLevel5の方たちが「オラオラ!! オレのテールに食らいついてこい!!!」と煽る場にしたいですね。そんなドMなLevel2,3なエンジニアが集まる場にしたいです。個人的に聞いてみたい話は以下のブログ・プレゼンテーションの内容です、しかも、上級者向けにカスタマイズされたものを。

MVCの「M」と「C」とは

年末だからこそ ASP.NET MVC のモデルの作り方について考えてみる (@shibayanさん)

ぜい肉のないコントローラをめざそう！ (@miso_soup3さん)

Patterns&Practice

Project Liike: モダンモバイル Web アプリ開発ガイダンス＆サンプルコード公開です！ (@chack411さん)

モダンブラウザのためのクライアントサイド Web 開発ガイダンス～ Project Silk リリース (@chack411さん)

単体テスト

基礎から見直す ASP.NET MVC の単体テスト自動化方法 (@normalian さん)

オープンソース

ASP.NET Open Sourcing Discussion with Scott Hanselman (@shanselman)

自分の知り得る情報は限られたものなので、ASP.NET MVC界はもっともっと有名な方がいらっしゃるのかもしれません。自分の言いたかったことは、この本をきっかけに

「わたしの戦闘力は530000です」

という人達(MS社員も含む)の全力のプレゼンテーションを聞いてみたいなぁ、という個人的な好奇心が生まれました。こういう場を設けるためには何をやったらいいんでしょうか？「自分はこんな内容を聞いてみたい」という意見が色々とあると思います。Twitterは苦手なので、ブログで会話しませんか？「ぼく/わたしのかんがえたさいきょうのえーえすぴーどっとねっとえむぶいしー」というタイトルで、このブログエントリー・プレゼンテーションの全力のを聞いてみたい、という内容をブログで書きましょう。で、書いたら #aspnetjp のハッシュタグをつけて、ブログ書きましたとつぶやいてみるのはどうでしょうか。きっと誰かが…こういう場を設けてくれるはず…何とかしてこういう場を設けたいです、はい、本気です。

「ASP.NET Open Sourcing Discussion with Scott Hanselman」をやっと観ました

ずっとまえから観ようと思ってRead It Later(Pocket)に登録しておいた動画「ASP.NET Open Sourcing Discussion with Scott Hanselman」をやっと観ました。.NETラボ6月勉強会でこの内容に近いことを話す機会をいただいたのでやっと踏ん切りがつきました。

ASP.NET Open Sourcing Discussion with Scott Hanselman

ASP.NET MVC4のオープンソース化について基本は以下のブログに書かれていることが中心です。

ScottGu’s Blog:
ASP.NET MVC, Web API, Razor and Open Source

Scott Hanselman’s Blog:
ASP.NET MVC 4, ASP.NET Web API and ASP.NET Web Pages v2 (Razor) now all open source with contributions

ただ、ブログに書かれていない興味深い内容についてもしゃべっています。しゃべっている内容を全部まとめるにはガッツが足りないので、個人的に興味を持った部分を抜粋してメモを残しておきます。（英語のスキルには自信がないので、一部内容が間違っているかもしれません）

ソースを公開するだけのオープンソース化ではない、ASP.NET MVCはオープンな開発を行う
Folks, PullRequestができるようになったし、ユーザーとディスカッションを行うことができる
誰でもコミットできるわけではない、PullRequestの内容をみてASP.NET MVC開発チームで判断する
PullRequestに対しては内容を見てディスカッションを行い、取り込むべきと判断したらコミットする
ASP.NET MVC開発チームは内部のTFSではなく、パブリックなGitリポジトリにコミットする
フィードバックやバグフィックスのリリースサイクルをもっと短くしたい
CodePlexがGitをサポートした、これでTFS/Subversion/Mercurial/Gitに対応したことになる
CodePlexはTFSのチームと密接に関わっている？

ASP.NET MVCはChromeやFireFoxのように短い周期でどんどんリリースされていくのかもしれません。しかも、WebPIやダウンロードセンターで入手するのではなく、Nugetで配布される気が。4.0.1、4.0.2、4.1.0とか登場すると胸がアツくなりますね、ただ、どのバージョンを使うかでいろいろと問題になる気も。

Channel9ってしゃべってる内容を英語でいいから字幕をつけてくれないかな…デモなしで淡々としゃべっている動画は英語圏じゃない人には辛すぎる。ただの睡眠導入動画になってしまいます。（興味があってみてるんだから寝るな、というツッコミもありますが）

【日本語訳】ASP.NET MVC4 Beta Relaese Note(3)

日本時間の2/17に ASP.NET MVC4 Betaのリリースノートが公開されています（こちら）。もちろん英語なのでざっくり日本語訳したいと思います。長くなるので3回に分けたいと思います。

Installation Note ～ Upgrading an ASP.NET MVC3 Project to ASP.NET MVC4
New Features in ASP.NET MVC4 Beta(Azure SDK まで）
New Features in ASP.NET MVC4 Beta(Known Issures and Breaking Changes）

※この文章は個人が勝手に訳した文章であり、正しさを保証するものではありません。違和感を感じた場合は、必ず原文に当たってください。新機能の部分は未検証なので一部日本語訳に自信がありません。

今回はNew Features in ASP.NET MVC4 Beta(Known Issures and Breaking Changes）です。

Known Issures and Breaking Changes（既知の問題と重大な変更）

Visual Basic プロジェクトでArea内でControllerの追加を行うと、間違った名前空間のコードが生成される。Visual Basicを使用しているASP.NET MVCプロジェクトでArea内にControllerの追加を行うと、アイテムテンプレートが間違った名前空間をコントロラーに生成してしまいます。コントローラーのアクションメソッドを実行すると ”file not found” エラーが発生します。

生成された名前空間は、ルート以降の名前空間が抜けてしまいます。例として、RootNamespace.Areas.AreaName.Controllers という名前空間が生成されるべきところ、Rootnamespaceという名前空間が生成されてしまいます。

Ravor View Engineに関する重大な変更。Razorのパーサー書き換えの一部として、以下の型が System.Web.Mvc.Razor から削除されました。

ModelSpan
MvcVBRazorCodeGenerator
MvcCShartRazorCodeGenerator
MvcVBRazorCodeParser

以下のメソッドも削除されています。

MvcCSharpRazorCodeParser.ParseInheritsStatement(System.Web.Razor.Parser.CodeBlockInfo)
MvcWebPageRazorHost.DecorateCodeGenerator(System.Web.Razor.Generator.RazorCodeGenerator)
MvcVBRazorCodeParser.ParseInheritsStatement(System.Web.Razor.Parser.CodeBlockInfo)

ASP.NET MVC4アプリケーションの bin ディレクトリに WebMatrix.WebData.dll が含まれていると、form認証URLが上書きされてしまう。アプリケーションにアセンブリ WebMatrix.WebData.dll を追加すると、（例として、配置可能な依存関係の追加ダイアログで「ASP.NET WebPages with Razor Syntax」を選択する）ログイン認証のURLをASP.NET MVC Account Controllerの /account/login から /account/logon へオーバーライドしてしまいます。この事象を回避し、web.configのauthenticationセクションで定義されているURLを使用するためには、appSettingに「PreserveLoginUrl」を追加して値を「true」に設定します。

</appSettings>

ASP.NET MVC4とVisual Studio 2010/Visual Web Developer 2010を同時にインストールすると、Nuget package managerのインストールに失敗する。ASP.NET MVC4のインストールは、Visual Studioのインストール後に実行する必要があります。
必要なソフトウェアがアンインストールされた状態では、ASP.NET MVC4のアンインストールが失敗する。ASP.NET MVC4をアンインストールするためには、Visual Studioよりも先にアンインストールする必要があります。
デフォルトのWeb APIプロジェクトを実行すると、ルーティングの追加に存在しないメソッド「RegistarApis」を使うという、ユーザーに間違った手順を示してしまう。ルーティングの追加ASP.NETルーティングテーブルを使用して RegisterRoues で追加しなければなりません。
ASP.NET MVC4 Betaをインストールすると、ASP.NET MVC3 RTMアプリケーションが壊れてしまう。RTMリリースで作成されたアプリケーションは(ASP.NET MVC3 Tools Updateは対象ではありません)、ASP.NET MVC4と並行して実行するために以下の変更が必要です。以下の変更を行わずないとプロジェクトはビルドエラーになります。

1.プロジェクトのルートにある Web.configファイルに、新規に<appSettings>エントリーを追加してkeyに「WebPages:Version」、valueに「1.0.0.0」を指定します。

</appSettings>

2.ソリューションエクスプローラーから、プロジェクト名を右クリックして「プロジェクトのアンロード」を実行します。そして、再度右クリックし、「編集 [プロジェクト名].csproj」を選択します。

3.以下の参照アセンブリ部分へ移動します。

以下のように置き換えます。

<Reference Include="System.Web.WebPages, Version=1.0.0.0,

Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL "/>

<Reference Include="System.Web.Helpers, Version=1.0.0.0,

Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL" />

4.変更を保存して、プロジェクトファイル(.csproj)を閉じます。プロジェクトを右クリックして、「プロジェクトの再ロード」を選択します。

【日本語訳】ASP.NET MVC4 Beta Relaese Note(2)

Installation Note ～ Upgrading an ASP.NET MVC3 Project to ASP.NET MVC4
New Features in ASP.NET MVC4 Beta(Azure SDK まで）
New Features in ASP.NET MVC4 Beta(Known Issures and Breaking Changes）

今回はNew Features in ASP.NET MVC4 Beta(Azure SDK まで）です。

New Feature in ASP.NET MVC4 Beta

このセクションでは、ASP.NET MVC4 Betaの新機能の紹介を行います。

ASP.NET Web API

ASP.NET MVC4はASP.NET Web APIを提供しています。これはHTTPサービスを作るための新しいフレームワークで、ブラウザやモバイル端末など幅広いクライアントからアクセス可能です。また、ASP.NET Web APIはRESTfullサービスの作成に理想的なプラットフォームとなっています。

ASP.NET Web APIは以下の機能をサポートしています。

Modern HTTP programming model: 新しい、強く型付けされたHTTP オブジェクトモデルを使用してHTTPリクエスト・レスポンスに直接アクセスして扱うことができます。
Full support for routes: Web APIはルーティング機能をフルサポートしています。さらに、アクションへのマッピングは規約で完全にサポートされているので、クラスやメソッドに[HttpPost]などの属性を適用する必要はありません。
Content negotiation: クライアント・サーバーのどちらからでもAPIが返すデータのフォーマットを指定することができます。デフォルトでXML, JSON, URLエンコードフォーマットをサポートし、独自にフォーマットを追加したり、デフォルトのcontent negotiationを置き換えることもできます。
Model binding and validation: Model binderによってHTTPリクエストからデータを抜き出して、Web APIのアクションで使用される.NETのオブジェクトへ変換することが容易になります。
Fileters: Web APIはよく知られた[Authorize]など、フィルター機能をサポートします。認証や例外処理用に、独自のフィルターを記述してアクションに埋め込むことができます。
Query composition: シンプルにIQueryable<T>型を返すことで、Web APIはOData URL記法をサポートします。
Improved testability of HTTP details: 静的なコンテキストオブジェクトにHTTPの詳細を設定しなくても、Web APIのアクションは、HttpRequestMessageとHttpResponseMessageのインスタンスで動作することができます。HTTP型に加えて、独自の型で動作させるためにジェネリック版も用意されています。
Improved Inversion of Control(IoC) via Dependency Resolver: Web APIはインスタンスを他のフレームワークから取得するために MVC dependency resolver で実装された service locator pattern を使用しています。
Code-based configuration: Web APIの設定はコードで行われます、そのためconfigファイルを綺麗に保つことができます。
Self-host: Web APIはIISに加えて独自のプロセスでホストさせることができます。独自プロセスの場合で会ってもルーティングなどのフル機能を使用することができます。

Web APIに関する詳細情報は、http://www.asp.net/web-api を参照してください。

ASP.NET Single Page Application

ASP.NET MVC4はJavaScriptとWeb APIを使用したクライアントサイドでのインタラクティブはアプリケーションの作成をサポートしています。

キャッシュデータを使用してローカルで動作するよりリッチなアプリケーションを作成するためのJavaScriptのライブラリ群
作業ユニットとDALのサポートのための追加のWebAPIコンポーネント
短期間で開始できるように、MVCプロジェクトテンプレートとスキャフォールディング機能の提供

Single Page ApplicationのMVC4サポートに関する詳細は http://www.asp.net/single-page-application を参照してください。

Enhancements to Default Project Template

ASP.NET MVC4プロジェクトの作成に使われるテンプレートは、より現代風にアップデートされました。

見栄えの改善だけでなく、新しいプロジェクトテンプレートは機能性も改善されています。テンプレートはadaptive Renderingというテクニックを使用しており、カスタマイズすることなくデスクトップブラウザからもモバイルブラウザからも閲覧しやすくなっています。

adaptive renderingの動作を確認したい場合は、モバイルエミュレーターを使用するか、デスクトップブラウザのウィンドウを小さくリサイズします。ブラウザのサイズが小さくなると、ページレイアウトが変わります。

もう一つのプロジェクトテンプレートの新機能は、リッチなUIをつくつためのJavaScriptの利用です。テンプレートの「Login」と「Register」リンクはリッチなログイン画面をjQuery UI Dialogを使用して実現するサンプルになっています。

Mobile Project Template

新しいプロエジェクトを立ち上げて、モバイル端末やタブレット端末用のサイトを作成するときに、Mobile Application プロジェクトテンプレートを使用することができます。このテンプレートはオープンソースのタッチ操作に最適化されたUIを実現するjQuery Mobileを使用しています。

このテンプレートはInternet Applicatinテンプレートと同じ構造になっています（コントローラーのコードも同一です）が、jQuery Mobileを使用しているので、タッチベースの端末に最適なされたスタイルになっています。モバイルプロジェクトテンプレートの構造やUIについてはjQuery Mobile project websiteを参照してください。

デスクトップ向けのサイトを作成済みで、モバイル向けのビューを追加したい場合や、1つのサイトでデスクトップとモバイルで異なるスタイルのビューを提供したい場合は、Display Modes機能で実現することができます。(次のセクションで説明します)

Display Modes

Display Modesとはリクエストのあったブラウザに応じでViewを切り替える機能です。例えば、デスクトップブラウザからのリクエストの場合は Views\Home\Index.cshtml を使用し、モバイルブラウザからのリクエストの場合は Views\Home\Index.mobile.cshtml を使用するということです。

LayoutsやPartial でもブラウザに応じてViewをオーバーライドすることができます。

Views\Shared フォルダに _Layout.cshtml と _Layout.mobil.cshtml を置きます。アプリケーションはモバイルブラウザからリクエストがあった場合には _Layout.mobile.cshtml を、他のブラウザからのリクエストは _Layout.cshml を使用します。

フォルダに _MyPartial.cshtml と _MyPartial.mobile.cshtml を置きます。@Html.Partial(“_MyPartial”)という記述だけで、モバイルブラウザからのリクエストには _MyPartial.cshtml を、その他のブラウザからのリクエストには _MyPartial.cshtml を使用します。

さらにデバイスに特化したView,Layout,Partial Viewを使用したい場合は、リクエストが特定の条件を満たした場合に検索する名前を決める DefaultDisplayMode インスタンスを登録します。例えば、Global.asaxファイルのApplication_Startメソッドに以下のコードを追加し、”iPhone”という文字列をDisplay ModeとしてApple iPhoneブラウザからリクエストがあった場合に使用する文字列とします。

DisplayModeProvider.Instance.Modes.Insert(0, new

DefaultDisplayMode("iPhone")

{

ContextCondition = (context => context.GetOverriddenUserAgent().IndexOf

("iPhone", StringComparison.OrdinalIgnoreCase) >= 0)

});

このコードを実行すると、iPhoneブラウザからのリクエストがあった場合、アプリケーションは Views\Shared\_Layout.iPhone.cshtml レイアウトを使用します。

jQuery Mobile, the View Switcher, and Browser Overriding

jQuery Mobileとはタッチ操作に最適化されたWeb UIを実現するオープンソースライブラリです。ASP.NET MVC4でjQuery Mobileを使用したい場合は、NuGet パッケージをダウンロードして利用することができます。インストールはVisual Studio Package Manager Consoleから、以下のコマンドを実行します。

Install-Package jQuery.Mobile.MVC

このコマンドでjQuery Mobileといくつかのヘルパーファイルなど、以下の内容がインストールされます。

jQuery Mobileベースのレイアウトファイル Views\Shared\_Layout.Mobile.cshtml
partial view Views\Shared\_ViewSwithcer.cshtml と、コントローラー ViewSwitcherController.cs からなるvew-switcherコンポーネント

パッケージのインストール後にモバイルブラウザからアクセスすると（FireFoxのアドオン「User Agent Switcher」などを使用しても可）、jQuery Mobileのレイアウトとスタイルが適用されて、見た目が大きく変わっていることがわかります。この機能を利用するためには、以下のことを行います。

モバイル用のViewを作成し、前のセクションで説明した Displa Modes 機能を使用する(例: モバイルブラウザ用にViews\Home\Index.mobile.cshtml を追加して、Views\Home\Index.cshtml をオーバーライドする）
jQuery Mobile documentation を読んで、モバイル用ビューにタッチ操作に最適化したUIの作成方法を学ぶ

モバイル端末に最適化されたページの決まりとして、デスクトップ用、モバイル用といったユーザーにモードの切り替えを可能にするためのリンクを追加する方法があります。jQuery.Mobile.MVCパッケージにはサンプルのview-swithcerコンポーネントが含まれており、これを実現することが可能です。デフォルトでは Views\Shared\_Layout.Mobile.cshtml が使用され、以下のように表示されます。

サイトの訪問者がリンクをクリックすると、同じページのデスクトップ用が表示されます。

デスクトップ用のレイアウトファイルにはデフォルトでview-switcherが含まれていないので、サイト訪問者はモバイル用のページに行くことができません。そのため、デスクトップ用レイアウトファイルの<body>タグに _ViewSwitcher への参照を追加します。

<body>

@Html.Partial("_ViewSwitcher")

view-switcherはBrowser Overridingと呼ばれる新機能を使用しています。この機能はアプリケーションが実際のブラウザとは別のブラウザ(user agent)からリクエストが来たと認識させています。以下の表はBrowser Overriding機能を提供しているメソッドの一覧です。

HttpContext.SetOverriddenBrowser(userAgentString)	リクエストをオーバーライドして、user agent文字列を書き換える。
HttpContext.GetOverriddenUserAgent()	オーバーライドされたuser agent文字列を取得する。オーバーライドされていない場合は、実際のuser agent文字列を返す。
HttpCotext.GetOverrriddenBrowser()	オーバーライドされたuser agent 文字列に対応するHttpBrowserCapabilitiesBaseインスタンスを返す。このインスタンスのプロパティ(例:IsMobileDevice)を利用可能。
HttpContext.ClearOverridenBrowser()	オーバーライドされたuser agent文字列を削除する。

Browser OverridingはASP.NET MVC4のコア機能で、JQuery.Mobile.MVCパッケージをインストールしていなくても利用することができます。しかし、view, layout, partial-viewでのみ利用可能が、他のRequest.Browserオブジェクトに依存するASP.NETの機能では利用することができません。

デフォルトではオーバーライドされたuser agent文字列はcokieに保存されます。データベースなど他の場所に保存したい場合は、デフォルトのプロバイダ(BrowserOverrideStores.Current)を置き換えて対応することができます。このプロバイダーに関するドキュメントは後のASP.NET MVCのリリース時に利用可能になるます。

Recipes for Code Generation in Visual Studio

新機能RecipesとはNuGetを使ってインストールしたパッケージをもとにソリューションに特化したコードを生成するVisual Studioの機能です。Recipes Frameworkによって、開発者はコード生成プラウグインを簡単に作成することができるようになります。例えば、ビルトインコード生成機能である、Area, Controller, Viewの追加機能を置き換えることができます。RecipesあはNugetパッケージとして配置されるため、ソース管理リポジトににチェックインしてプロジェクトの開発者全員で共有することができます。

Task Support for Asynchronous Controller

Task型、またはTask<ActionResult>型を返す非同期アクションメソッドを1つのメソッドとして記述することができます。

例えば、C#5(または、Async CTP)を使用して、以下のような非同期アクションメソッドを記載することができます。

public async Task<ActionResult> Index(string city) {

var newsService = new NewsService();

var sportsService = new SportsService();

return View("Common",

new PortalViewModel {

NewsHeadlines = await newsService.GetHeadlinesAsync(),

SportsScores = await sportsService.GetScoresAsync()

});

}

上記アクションメソッドでは、newsService.GetHeadlinesAsync と sportsService.GetScoresAsync は非同期で呼び出され、スレッドプールをブロックすることはありません。

Taskインスタンスを返す非同期アクションメソッドはタイムアウトを他ポートします。アクションメソッドをキャンセル可能にするには、アクションメソッドの署名に CancellationTOken型の引数を追加します。以下の例は、タイムアウトを2500ミリ秒に設定し、タイムアウトが発生した場合はTimeOut viewを表示するサンプルです。

[AsyncTimeout(2500)]

[HandleError(ExceptionType = typeof(TaskCanceledException), View = "TimedOut")]

public async Task<ActionResult> Index(string city,

CancellationToken cancellationToken) {

var newsService = new NewsService();

var sportsService = new SportsService();

return View("Common",

new PortalViewModel {

NewsHeadlines = await newsService.GetHeadlinesAsync(cancellationToken),

SportsScores = await sportsService.GetScoresAsync(cancellationToken)

});

}

Azure SDK

ASP.NET MVC4 Betaは2011年9月にリリースされた Windows Azure SDK 1.5をサポートしています。

【日本語訳】ASP.NET MVC4 Beta Relaese Note(1)

Installation Note ～ Upgrading an ASP.NET MVC3 Project to ASP.NET MVC4
New Features in ASP.NET MVC4 Beta(Azure SDK まで）
New Features in ASP.NET MVC4 Beta(Known Issures and Breaking Changes）

※この文章は個人が勝手に訳した文章であり、正しさを保証するものではありません。違和感を感じた場合は、必ず原文に当たってください。

Installation Note

ASP.NET MVC4 Beta for Visual Studio 2010は Web Platform Installerを使用して ASP.NET 4 home page からインストールすることができます。

ASP.NET MVC4 Betaのインストールの前に、ASP.NET MVC4 Developer Previewをアンインストール剃る必要があります。

ASP.NET MVC4 Betaは.NET Framework 4.5 Developer Previewと互換性がありません。インストールの前に.NET 4.5 Developer Previewをアンインストール剃る必要があります。

ASP.NET MVC4はMVC3と混在させることが可能です。

Documentataion

ASP.NET MVC4 Betaに関するドキュメントは以下MSDNのサイトから利用可能です

http://go.microsoft.com/fwlink/?LinkID=243043

チュートリアル・ASP.NET MVCに関するその他の情報はASP.NETサイトのMVC4ページから利用可能です。

http://www.asp.net/mvc/mvc4

Support

プレビュー版のリリースであり、公式なサポートを受けることはできません。このリリース版の動作に関する質問は、ASP.NET MVC forum(http://forums.asp.net/1146.aspx)へ投稿してください。こちらでASP.NET コミュニティーメンバから非公式のサポート（回答）を受けることができます。

Software Requirements

ASP.NET MVC4 for Visual Studio 2010には、PowerShell 2.0とVisual Studio sp1/ Visual Web Developer 2010 sp1が必要です。

Upgrading an ASP.NET MVC3 Project to ASP.NET MVC4

ASP.NET MVC4はMVC3と同一コンピュータ上で混在させることができます。つまり、アプリケーションをMVC3からMVC4へ移行する時期を柔軟に選択することができます。

最も簡単なアップグレード方法はASP.NET MVC4プロジェクトを新規作成し、既存のMVC3プロジェクトからすべてのView, Controller、コンテンツファイルをコピーし、アセンブリの参照設定を新しいプロジェクトに合わせて変更することです。MVC3プロジェクトのWeb.configファイルに変更を加えている場合は、MVC4プロジェクトのWeb.configファイルとマージする必要があります。

手動でのMVC3からMVC4へのアップグレード手順は以下のとおりです。

１．プロジェクトのWeb.configファイル（ルートに1つ、Viewフォルダに1つ、Viewフォルダの各エリアに1つあります）の以下の敵捨つを置き換えます。

System.Web.Mvc, Version=3.0.0.0

System.Web.WebPages, Version=1.0.0.0

System.Web.Helpers, Version=1.0.0.0

System.Web.Helpers.Razor, Version=1.0.0.0

以下のように置換します。

System.Web.Mvc, Version=4.0.0.0

System.Web.WebPages, Version=2.0.0.0

System.Web.Helpers, Version=2.0.0.0

System.Web.Helpers.Razor, Version=2.0.0.0

２．プロジェクトのルートのWeb.configファイルの「webpages:Version」要素を「2.0.0」に更新し、新しい「PreserveLoginUrl」キーと値を「true」追加します。

</appSettings>

３．ソリューションエクスプローラーから、System.Web.MVC(Version3)の参照を削除し、Sytem.Web.Mvc(v4.0.0.0)の参照を追加します。そして、以下のとおり参照設定を変更します。

削除する参照設定

System.Web.MVC (v3.0.0.0)
System.Web.WebPages (v1.0.0.0)
System.Web.Razor (v1.0.0.0)
System.Web.WebPages.Development (v1.0.0.0)
System.Web.WebPages.Razor (v1.0.0.)

追加する参照設定

System.Web.MVC (v4.0.0.0)
System.Web.WebPages (v2.0.0.0)
System.Web.Razor (v2.0.0.0)
System.Web.WebPages.Development (v2.0.0.0)
System.Web.WebPages.Razor (v2.0.0.0)

４．ソリューションエクスプローラからプロジェクト名を右クリックして、「プロジェクトのアンロード」を選択します。そして、再度プロジェクト名を右クリックして「編集 [プロジェクト名].csproj」を選択します。

５．ProjectTypeGuikdsへ移動し、{E53F8FEA-EAE0-44A6-8774-FFD645390401} を {E3E379DF-F4C6-4180-9B81-6769533ABE47}に置換します。

６．変更を保存し、プロジェクトファイル(.csproj)を閉じます。プロジェクトを右クリックして、「プロジェクトの再ロード」を選択します。

７．プロジェクトが以前のバージョンのASP.NET MVCを使用してビルドされたサードパーティ製アセンブリを参照している場合は、プロジェクトのルートのWeb.configファイルを開いて configuration セクションにある以下3つの bindingRedirect 要素を追加します。

<!–… elements deleted for clarity …–>

<assemblyIdentity name="System.Web.Helpers"

publicKeyToken="31bf3856ad364e35" />

</dependentAssembly>

<assemblyIdentity name="System.Web.Mvc"

publicKeyToken="31bf3856ad364e35" />

</dependentAssembly>

<assemblyIdentity name="System.Web.WebPages"

publicKeyToken="31bf3856ad364e35" />

</dependentAssembly>

</assemblyBinding>

</runtime>

</configuration>

ASP.NET MVC4 beta がリリースされました

2月上旬からMVC4 betaが噂されていましたが、米国時間の2/14にASP.NET MVC4 betaがリリースされました。バレンタインプレゼントでしょうか。こちらのページからダウンロード可能です。

ASP.NET MVC4 Beta (Microsoft Download Center)

リリースされたといっても、ダウンロード可能になっているだけでリリースノートもチュートリアルもサンプルコードもありません。Scott HanselmanがTwitterで「ASP.NET MVC4のニュースやドキュメントは明日 http://asp.net/vnext をみてね」とつぶやいていたので、日本時間2/17の早朝に公開されると思います。

ダウンロードページのOverview(概要）を読むと、前半はASP.NET MVCの概要、Display Modesの説明、後半はASP.NET Web APIという聞き慣れないことばが登場しています。RestアーキテクチャースタイルのWebサービス(API)が作れるようです、今までのMVC3でもコントローラーからJSON形式やXML形式のデータを返せばWebAPIを作ることが出来ましたが、より簡単にできるようになるのでしょうか。

そして、システム要件