最近、お客様からお問い合わせが多くなってきているのが、VS 2005のWeb プロジェクトに関してです。すでにお使いいただいて開発が進んでいるのを聞いて嬉しく思いつつ、頂いた質問に関して即答するだけのシナリオを調査しきれていないことも多くて申し訳なく思うこともあります。
変更があった部分なので、お客様のシナリオが十分に網羅されているかについては、非常に気にかかる部分です。Redmond側の開発と、このプロジェクト システムに関して質問とシナリオの確認をしていたのですが、タイムリーな形でScott Guthrieからblogとして情報が出てきましたので、日本語のものを参考訳としてこちらに書いておきたいと思います。
極めて長文なので、２回に分けますが、もしご意見などがございましたら、トラックバックにてお寄せ下さい。
VS 2005 Web プロジェクト システム: Web プロジェクト システムとは。そして、なぜこうしたのか。
VS 2005から導入された新しいWebのプロジェクト システムに関して、最近オンラインで多くの議論が行われています。いったいWeb プロジェクト システムとは何かということについて、若干のご説明をこの投稿によっていたしたいと思います。
Web プロジェクトとは？
Web プロジェクトとはVisual Studio 2005 中でASP.NETアプリケーションを構築するために使われます。単一のプロジェクト中にアプリケーションが存在するようなスタンドアロンのもの、クラスライブラリ、データ、Webサービス、単体テストやその他のVisual Studioのソリューションの一部のプロジェクトとしてのもの、どちらでもありえます。VSソリューション内の参照とプロジェクトのビルド順序が完全にサポートされています。今日VS 2003を使って行うのと同様に、プロジェクト間の関係を.slnソリューション ファイルによって、それらを設定し管理します。（例えば、３～４のクラス ライブラリ プロジェクトによって構築するクラス ライブラリ アセンブリがWebプロジェクトで使われるような場合です）。
Webソリューションの発行の準備が整ったら、新しい"発行"のオプションを使い、Webサーバーへ配置可能なディレクトリ構造を生成します。これは、VS2005でWinFormsクライアントのアプリケーション プロジェクトの場合に取られるワークフローの手順と論理的な違いはありません（発行のオプションが、Webサイトの代わりに、クライアントの"Click-Once"のパッケージを生成します）。コマンド ラインや自動化されたビルド サーバーのシナリオ用に新しいMSBuildのシステム（後述）によってWebプロジェクトのビルド操作を自動化することができます。
VS 2005 Webプロジェクトの新機能とは？
VS 2005の新しいWeb プロジェクト サポートはVS 2002とVS 2003からの数々の新しい機能拡張をしています。開発者に適した大きな改善点は:
FrontPage サーバー 拡張の要件が不要
これまでリリースされたVisual Studioとは違い、VS 2005は、Webプロジェクトの作成、ビルドのために、FPSE （FrontPageサーバー拡張）をインストールする必要がありません。
FPSEがなくてもローカルのIISアプリケーションやvdirを参照、作成、開くことができます。VS 2005はIISのメタベース構成ストアをサポートし、サイト、アプリケーション、仮想ディレクトリと関連付けられた物理パスへの連結を認識、接続することができます。また、ファイルシステムからWeb プロジェクトを編集、または開いたり、FTPを使って遠隔地からアクセスすることができます。
FPSEも必要な方のためにサポートされています。しかし、これまでのフィードバックによると95%超の方が必要ではないようですし、_vti_ ディレクトリはもう必要なくなるでしょう。
開発用Webサーバーを備える（IISが不要 & 標準ユーザーとしてデバッグ可能）
IISによるWebプロジェクトの開発とテストの提供に加えて、開発用のWebサーバーが付きました。このテスト用WebサーバーはIISがインストールされていない、またはITポリシーがデスクトップでの配置を限定しているような場合に適しています。
このWebサーバーは、セキュリティ上の理由（開発中のアプリケーションに、他の場所からのアクセスをさせません）からローカルの要求のみをハンドルし、Webプロジェクトを閉じたときに自動的にシャットダウンします。また、開発者に非管理者権限である標準ユーザーのアカウントとして実行していてる状況でのアプリケーションのデバックを可能にします。一旦アプリケーションの構築ができた後、ローカルのIISで実行するか、リモートのサーバーにアプリケーションを配置しテストと検証を行います。また、Webサイトをリモート サーバーにコピーする、組み込みの"Web コピー" ウィザードがあり、FTPとFPSEをコピーのためのプロトコルとしてサポートします。
当然ながらIISディレクトリに対してのWebプロジェクトのビルドを完全にサポートしています。（メモ: 入れ子のvdirとサブアプリケーションをソリューションとしてビルドする場合、必要となります。）
柔軟性のあるファイル管理とツール間のコラボレーションのサポート
他の種類のアプリケーション プロジェクトと比較して、Web プロジェクトには以下の特徴があります。
１）ほぼ常にといっていいほど、他のまったく別なツールと併用してWeb プロジェクトは作られます。イメージの編集には他社の有名なツールが使われますし、CSSやASPX/.HTMのコンテンツのレイアウトはまた別な製品やFrontPageといったものが使われます。コードにはVSが使われます。これらの違う種類のリソースの統合や共同作業に多大なコストがかかっています。ひとりの担当者が上記の全ての作業をおこなうこともありますが、一般的に大きなプロジェクトでは複数の担当者に分担されます。
VS2002/2003に対してよく聞く不満として、このようなツール間のワークフローを管理することが大変であるということがありました。特に、VS以外のツールでFPSEを使うことができなかったり、VSのプロジェクト ファイルとの統合ができない点がありました。例えば、デザイン担当が新しい背景イメージを使うためにCSSファイルをWeb プロジェクトでアップデートしたとします。仮に、VS 2003を使うWeb開発者が、古いイメージを削除し新しいイメージを追加することをプロジェクト ファイルのマニフェストに書く変更を怠った場合、開発時には大丈夫だったものが、新しい場所で構築した際、新しいイメージがコピー／配置されないため運用に失敗します。
2) Webプロジェクトは、Web アプリケーションからページ、イメージ、CSS スタイルシートや他の項目のレイアウトが直接エンド ユーザーにWebブラウザを通して提供される点でもまた特徴的です。ファイルのレイアウトは、ほぼ常に階層的であり、作業の大半や注目はここに集まります。典型的なWebサイトでは、ファイル数は簡単に数百、もしくは数千にも上ります。VS 2002/2003でよく聞かれた不満が、IDEからこの管理が非常に難しいことでした。とりわけ、ソース管理を使った際に共通のプロジェクト ファイルをチェックアウトしチェックインする作業を、レイアウトが変更になったりファイルの追加、名前の変更、削除が行われる度に行わなくてはなりませんでした。
この双方のシナリオをより良くサポートするために、VS 2005のWeb プロジェクトでは、一元的なWebプロジェクトのマニフェスト ファイルに全てのファイルの一覧を保存することを止めました。その代わりに、Webプロジェクトのコンテンツやレイアウトは、Webプロジェクト フォルダのファイル レイアウトとファイルのコンテンツから導かれます。 Webプロジェクトでのファイルの追加、削除、移動作業は、競合の元となる一元的なプロジェクト ファイルを必要としません。これによって、ファイル システムを使って作業をするVS以外のどのようなツールでも容易に使うことができます。また、ソース管理下で使う場合でも、移動や変更をする際に、プロジェクト ファイルをロックしてから更新する必要がありません。
Webプロジェクトにおけるソリューション エクスプローラ下のプロジェクト レイアウトも、Webプロジェクトのファイル システムの表示をするように変更しました。このことによって、開発者は、実際にWebプロジェクトのファイル レイアウトとコンテンツがどのように見えるかを、常に100%正確な形で見ることになります （VS 2003では違います）。メモ: "参照"のツリーは、ファイル システムで表現できないため、Webプロジェクトのルート ノードのところで表示されません。代わりに、プロジェクトの参照リストをプロジェクトのプロパティ ページ（ソリューション エクスプローラ内でプロジェクトを右クリックすると、早くたどり着けます）から呼び出し、"参照の追加"メニューかコンテキスト メニューによって新規の参照をプロジェクトに直に追加することができます。
Webプロジェクトはソース管理も当然サポートしています。ソース 管理下でプロジェクト内のファイルを移動、もしくは名前の変更をした場合、VS 2005は移動、名前の変更をソース管理貯蔵所で（履歴を残しながら）適宜行います。プロジェクトのマニフェストをチェックインとチェックアウトし明示的に更新する必要はありません。
大きなWebプロジェクトのよりよいサポート
大きなWebプロジェクトをVS 2003で作業している開発者の方々から、多量なファイルとコンテンツを扱う環境ではIDEとワークフロー環境は上手くスケールしないというご不満を聞いていました。大きなWebサイトを開くには数分、変更を行ってリビルドを行い実行するまでに、非常に長い時間がかかります。
VS 2005では、この何百、何千といった項目をWebプロジェクトで扱うスケーラビリティの問題に対して目覚しい改善があります。例えとして、ローカルのデスクトップ コンピュータ（P4 3Ghz)で、9,000のファイル（250の項目を含む36のディレクトリに分散された5,000の.aspxページと4,000のイメージ）を開くテストをしてみました。VS 2005で開くのに３秒以下です。そして任意のディレクトリの任意の.aspx ページを、一旦停止も遅れることもなく、すぐに編集開始することができました。これは、以前のどのVS（このサイズのプロジェクトを開くのに数分かかります）のバージョンと比較しても極めて高速です。
この9,000の項目があるWebサイトを初めてクリーンな状態からビルドするのに約42秒ほど私のコンピュータでかかります。VS 2003もほぼ同じです。Webプロジェクトをビルドした後、この5,000のうちの任意のページを開き、ページに変更を加え、リビルドを行い、Ctrl-F5で実行とテストを行うのに2秒以下です。
こういったことを容易にするために、若干アーキテクチャの変更を行いました。もっとも大きなものは、Webプロジェクト内のものを全て１つのDLLにコンパイルする（VS 2002とVS 2003でサポートしている唯一のモードです）ことを止めました。代わりにWebプロジェクトを複数の細かなアセンブリに区切っています。
Webプロジェクト中にある、すべてのコードビハインドではないクラス、データセット、WebサービスとそのほかのUIではないコードは、共通のアセンブリに今回コンパイルされます。ページ、ユーザー コントロールは別々の細かなアセンブリにコンパイルされます。Webプロジェクトの各ディレクトリは既定で別々なアセンブリにコンパイルされます。Webプロジェクトはソリューションの一部として他のクラス ライブラリ プロジェクトを参照もできます。この場合は今日と同様に、プロジェクトのアセンブリとしてコンパイルします。
このさらに細かくしたモデルの最大の利点は、変更が行われる度に、Webサイト全体を再コンパイルする必要が無いことです。何を変更したか、変更によるダウン レベルのビルド依存関係は何か、リビルドに対して影響を受ける部分によって、コンパイルの範囲が簡単に計算できるようになりました。
VS 2005の開発者は"ビルド"メニュー中に今回より多くの選択があります。ソリューション全体を強制的にビルドすることができたり（現在のWebプロジェクトとソリューション中の他のプロジェクト全てを含みます）、Webプロジェクトのみをビルドまたはリビルドできたり、また新しい"ページのビルド" の選択をし作業編集している現在のページをビルドまたはリビルドしたりできます（そして変更された使用しているユーザー コントロールといった任意の依存するリソースも）。完全ビルドとは関係ないローカルで行っている数個のファイルに対する変更を簡単に検証するのに有効です。これによって、VBのような背景でのコンパイルする機能がないC#を使っている開発者にとっては、完全なリビルドをせずに、IntelliSenseの更新がかかる方法を提供します。
開発者はF5とCtrl-F5の実行オプションによってどのレベルのコンパイル エラー チェックを行うかを構成することができ、このキーによるWebアプリケーションの立ち上げの際にエラーのチェックがなされます。既定では今までどおりWebサイトの変更されたページに全て関してコンパイルされます。大きなWebアプリケーションを取り扱っている際には、効果的な構成オプションは現在作業しているページやリソースに対してコンパイルすることです。これによって、最初に全ての他のものもコンパイルすることを避け、9,000ものファイルがあるWebアプリケーションを３秒で開いて、任意のページを２秒でコンパイルし実行するといったことが可能になります。
今回は、ここまでです。後半はできるかぎり早くお届けしたいと思っていますのが、少々お待ち下さい。なにしろ長いもので・・・。
皆様、コメントをいただきまして、ありがとうございます。
Moo さん、補足いただきましてありがとうございます。基礎部分の知識やスキルは継続的に応用ができますし、ゴールとしてASP.NET 1.x 向けに作られたWeb アプリケーションとの互換性100%を目指しています。新製品の常として、より良くお客様の実使用シナリオをサポートできることを考慮し、さらに快適にお使いいただくために、改善を継続的に行っています。
どっとねっとふぁんさん、ご要望をありがとうございます。blogの翻訳のご要望は一般的に多いのですが、開発作業と並行して行うのは大変難しくなります。日本の開発チームとしては、開発作業の一環として、日本でBetaに取り組まれて問題にぶつかっていらっしゃるお客様からの問い合わせへの全般的な回答に当たるものに関して、できる限り行いたいと思っています。ぜひ、ご遠慮なく MSDN Product Feedback Center などでBetaでの開発中に見つかるBugやSuggestionをお寄せ下さい。
[2005/08/27 更新] HTMLの貼り付けの際に下線の付いた部分が重複していたのを修正。若干の用語の修正。
[2005/08/29 更新] コメントへの返信の追加。
[2005/09/09 更新] MSDN Product Feedback CenterのURLを直接のものから日本語の解説のものに変更。