ASP.NET 1.x から ASP.NET 2.0 への移行

Jayesh Patel, Bryan Acker, Robert McGovern
Infusion Development

July 2004

適用対象 :
   Microsoft ASP.NET 2.0

概要 : ASP.NET 1.x から ASP.NET 2.0 になって新たに加わった機能を紹介します。ASP.NET 2.0 では、これらの新機能により、.NET Framework における Web 開発で利用できるオプションが強化されています。そのほか、コンパイルと配置の多彩なオプションを新たにサポートするために ASP.NET のアーキテクチャに加えられた変更についても解説します。

目次

はじめに
ASP.NET 2.0 の目標
ASP.NET 1.x からの移行
アーキテクチャの変更
プロバイダ モデル
ASP.NET 2.0 のコーディング モデル
構成とサイト保守
開発の変更
ASP.NET 2.0 アプリケーションのコンパイル
サイト ナビゲーション
データ アクセスとデータ ソース
モバイル デバイス用 Web アプリケーション
ASP.NET 2.0 の新機能
マスタ ページ
テーマとスキン
メンバシップ
プロファイル
Web パーツ
まとめ
参考書籍

はじめに

コンピュータの言語とフレームワークは、開発コミュニティのニーズと共に進化します。もちろん、Microsoft ASP.NET も例外ではありません。ASP.NET 2.0 は ASP.NET フレームワーク初のメジャー アップデートであり、ASP.NET 1.x でよく見られた問題が解決されているほか、.NET プラットフォームにおける Web 開発の柔軟性や機能性を大幅に強化する新機能が導入されています。

この記事では、アーキテクチャ上の主な変化と、ASP.NET アプリケーションの開発方法に加えられた変更について取り上げます。そのほか、ASP.NET 2.0 のいくつかの重要な新機能についても解説します。この記事のほとんどのトピックでは、ASP.NET 1.x の使用経験が前提となります。ASP.NET アプリケーションの開発経験がない方は、代わりに「ASP から ASP.NET 2.0 への移行」を読むことをお勧めします。

ASP.NET 2.0 の目標

ASP.NET 1.1 をベースとして、ASP.NET 2.0 の開発では以下の 4 つの目標に重点が置かれました。

  1. Web アプリケーションの信頼性および操作性を高める。

    現在、ほとんどの ASP.NET 1.x アプリケーションは、Microsoft インターネット インフォメーション サービス (IIS) 5.0 上で実行されています。ASP.NET 2.0 では、パフォーマンスとスケーラビリティの強化のために、IIS 6.0 の新機能を活用しています。たとえば、IIS 6.0 の新しいプロセス モデルでは、サーバーで複数のアプリケーションを真に独立した形でホストできるようになっています。各 ASP.NET アプリケーションにそれぞれ専用の分離プロセスが割り当てられるため、誤って他のアプリケーションに干渉することはありません。つまり、アプリケーションが互いを破壊するようなことはなくなります。各アプリケーションは、他のすべてのアプリケーションから完全に分離した形で実行されます。1 つのアプリケーションがクラッシュしても、他のアプリケーションに影響が及ぶことはありません。

    操作性の面では、マスタ ページやテーマなどの新機能により、一貫した構造を使用して大規模な Web アプリケーションを開発できます。構造の管理や構成も簡単に行えるようになっています。そのほか、ASP.NET 2.0 で加えられた変更により、モバイル デバイス用の Web ページを自動的に作成できます。Microsoft Mobile Internet Toolkit がコア フレームワークに完全に統合された結果、ASP.NET 2.0 は、企業で使用されるあらゆる種類のアプリケーションを開発できる完全なプラットフォームとなっています。

  2. 一般的なシナリオで記述しなければならないコードの量を減らす。

    ASP.NET 2.0 に含まれているウィザードやコントロールを使用すると、頻繁に実行されるタスク (データ アクセスなど) を、1 行もコードを書かずに実行できます。Microsoft Visual Studio 2005 のデザイナでは、データ連結テーブルを含む複雑なページのレイアウトや構成を行うことができます。これらのウィザードを使用することによって、開発者はよりすばやく、スマートに作業できます。

    ASP.NET 2.0 では、Microsoft .NET Framework の変更も活用されています。中でも部分クラスの概念は、ASP.NET 開発者にとってとりわけ有効です。部分クラスによって、開発者はコードの一部を記述するだけで済むようになります。残りの部分は、ASP.NET コンパイラによって必要に応じて記述されます。これにより、定型コードを目にすることも、それらを記述する必要もなくなります。

  3. Web アプリケーションをパーソナライズするためのユーザー機能を提供する。

    ASP.NET 2.0 には、ユーザー アカウントを管理したりアプリケーションのページの内容やレイアウトをパーソナライズしたりするのに役立つ組み込みコントロールが含まれています。まず、メンバシップ サービスが、ユーザーの追跡を可能にします。メンバシップ サービスに統合されている新しいログイン コントロールを使用すると、コードを一切記述することなく、アカウントの作成やユーザーのログインを自動化できます。新しい Web パーツ機能では、Web パーツと呼ばれるサブパネルを含む Web アプリケーションを作成できます。ユーザーは、それぞれの目的に応じて、Web ページに表示するパーツを選択したり、カスタマイズしたりできます。最後にプロファイル サービスが、宣言型の XML 構成ファイルによって、ユーザーの設定とデータの永続化を実現します。

  4. 一貫したレイアウトとデザインを生成するための高度なデザイン機能を提供する。

    ASP.NET 2.0 には、一貫したページ レイアウトとデザインを持つアプリケーションを構築するための機能として、マスタ ページテーマ、およびスキンが導入されています。実装や変更も容易なこれらの新機能によって、大規模なアプリケーションの管理性および保守性が大幅に強化されます。

ASP.NET 2.0 の新機能の多くは、これらの目標を実現するために導入されています。この記事の残りの部分では、個々の技術を取り上げて、ASP.NET 2.0 が ASP.NET 1.x をどのように拡張して、強力な Web アプリケーション開発プラットフォームを実現しているのかを見ていきます。

ASP.NET 1.x からの移行

ASP.NET 2.0 では、下位互換性が完全に確保されています。したがって、運用中の ASP.NET 1.x アプリケーションがある場合も、心配はいりません。既存の ASP.NET 1.x アプリケーションは、何も変更しなくても ASP.NET 2.0 で正常に動作します。しかし、実際に Visual Studio 2005 にアップグレードすると、さまざまな点が変更されていることがわかります。まず第 1 に、ASP.NET ページの既定の開発モデルが変更されています。また、ASP.NET 2.0 では、コンパイルと配置のさまざまなオプションが新たに追加されています。以下のセクションでは、これらすべての変更について詳しく説明します。

アーキテクチャの変更

ASP.NET の基本的なアーキテクチャは、常に柔軟性と拡張性を念頭に設計されてきました。 ASP.NET 2.0 においても、新機能の多くをサポートする新しいプロバイダ モデルを組み込むことによって、この伝統が踏襲されています。そのほか、サイトの保守や構成を容易にするために、新しいユーティリティや API が追加されています。これらの変更はすべて、ASP.NET 1.x の柔軟性と拡張性を維持しつつ、ASP.NET 2.0 アプリケーションの開発プロセスをよりすばやく効率的なものとするべく設計されています。

プロバイダ モデル

ASP.NET 2.0 の新機能の多くは、Web アプリケーションとデータ ストアの間の通信に依存しています。このデータ アクセスを一貫した形で提供するために、ASP.NET 2.0 では一連のプロバイダが使用されています。プロバイダはパターンであると同時に、開発者が ASP.NET 2.0 のフレームワークを特定のデータ ストアの要件に合わせて拡張するためのポイントでもあります。たとえば開発者は、新しいプロバイダを作成して、ユーザー識別システムをサポートしたり、パーソナライゼーション データを別のデータ ストアに格納したりできます。

カスタム プロバイダでは、データベース バックエンド システムとやり取りするのが一般的ですが、 プロバイダ モデルのインターフェイス仕様の要件を満たしている限り、任意のメディアやアルゴリズムを使って必要なプロバイダ メソッドやプロバイダ クラスを自由に実装できます。

ASP.NET 2.0 プロバイダ

プロバイダ モデルは、指定された要求の格納と取得を行うデータ永続化層に対する一連のインターフェイスとフックを定義します。こうしてプロバイダ モデルは、ASP.NET 2.0 がクライアント固有の問題に対応するためのプログラミング仕様として機能します。

ASP.NET 2.0 では、次のようにさまざまなプロバイダが使用されています。

  • メンバシップ。 メンバシップ プロバイダでは、ユーザー認証およびユーザー管理がサポートされます。
  • プロファイル。 プロファイル プロバイダでは、プロファイルにリンクしているユーザー固有のデータの格納と取得がサポートされます。
  • パーソナライゼーション。 パーソナライゼーション プロバイダでは、各ユーザーの Web パーツの構成とレイアウトの永続化がサポートされます。
  • サイト ナビゲーション。 サイト ナビゲーション プロバイダは、ASP.NET ページの物理的な格納場所を論理モデルにマップします。この論理モデルは、サイト内ナビゲーションのために使用したり、さまざまな新しいナビゲーション コントロールにリンクさせたりすることができます。
  • データ プロバイダ。 ADO.NET では、データベースと ADO.NET API との接続に常にプロバイダ モデルが利用されてきました。ASP.NET 2.0 では、ADO.NET データの呼び出しの多くをデータ ソースと呼ばれる新しいオブジェクトにカプセル化することによって、データ プロバイダが拡張されています。

各プロバイダは、それぞれ他の種類のプロバイダから独立して機能します。したがって、たとえばプロファイル プロバイダを置き換えても、メンバシップ プロバイダで問題が発生することはありません。

この記事の後半では、ASP.NET 2.0 のいくつかの新機能でプロバイダが実際にどのように使用されているのかを紹介します。

ASP.NET 2.0 のコーディング モデル

ASP.NET 1.x では、ASP.NET ページを 2 とおりの方法で開発できました。まず、ASP.NET タグを使ってコードを直接インラインで記述する方法があります。このコード インライン モデルは、従来の ASP やその他のスクリプト言語で広く採用されているコーディング モデルによく似ています。しかし、コード インライン モデルには、コードと HTML が混在するなど、いくつかの問題があります。これに代わるものとして ASP.NET 1.0 で導入されたのが、分離コード モデルです。分離コード モデルでは、コードは外部クラスに格納され、ASPX ページには HTML と ASP.NET のタグが含まれます。こうして分離コード モデルではコードとコンテンツが見事に分離されますが、その一方で継承についての興味深い問題が生じるほか、開発者は各 Web ページごとに 2 つのファイルを管理しなければならなくなります。

ASP.NET 2.0 ではこの 2 つのモデルが引き続きサポートされていますが、いくつかの重要な変更が加えられています。

コード インライン

Visual Studio 2005 では、コード インライン モデルが既定のモデルになっています。ページに追加したコードは、分離コード クラスではなく、ASPX ファイル内の <script> ブロックに自動的に追加されます。ただし、Visual Studio 2005 でも、コードはコード ビューに表示されます。要するに、Visual Studio の使用方法はこれまでと変わらず、ただコードが別のクラスではなく直接 ASPX ページに配置されるだけです。

Dd229411.migratefromaspnetto2_fig01a(ja-jp,MSDN.10).gif

Dd229411.migratefromaspnetto2_fig01b(ja-jp,MSDN.10).gif
図 1a および 1b. ビューの切り替え

<script> ブロックとファイル内の配置によって、コードはこれまでと同じようにコンテンツから分離されています。しかし、開発者は 2 つのファイルの同期の問題から解放されて、1 つのファイルに集中できるようになります。

分離コード

独立したコード ファイルを使用したい場合は、ASPX ページを作成するときにそのファイルを作成する必要があります。分離コード ファイルは、新しいページを作成するときにチェック ボックスをオンにするだけで簡単に作成できます。

Dd229411.migratefromaspnetto2_fig02(ja-jp,MSDN.10).gif
図 2. 分離コード ファイルの作成

ASP.NET 1.x と ASP.NET 2.0 の分離コード ファイルの最大の違いは、ASP.NET 2.0 の分離コード ファイルが部分クラスであり、ASPX ページを継承する完全なクラスではないことです。部分クラスは .NET の新しい構成要素で、これを使用すると、1 つのクラスを複数のソース ファイルで定義できます。この機能は、ASP.NET 2.0 の場合、特に分離コード ファイルで役に立ちます。というのも、部分クラスによって、従来の分離コード モデルに見られた継承関係を取り除くことができるからです。

Dd229411.migratefromaspnetto2_fig03(ja-jp,MSDN.10).gif
図 3. 新旧の分離コード

2 つの部分クラス (ASPX と分離コード) は、コンパイル時に 1 つのクラスにマージされます。これにより分離コード ファイルは、従来の分離コード モデルに付きものだったコントロールの宣言や継承の問題から完全に解放されます。違いが最も顕著に現れるのは分離コード ファイルそのもので、そこには、継承関係を維持するために従来必要とされていた自動生成コードが一切含まれていません。

従来の分離コード ファイルには、初期化領域と、ページ上のすべてのコントロールの初期化コードが含まれていました。

public class WebForm1 : System.Web.UI.Page
  {
    protected System.Web.UI.WebControls.Label Label1;
    private void Page_Load(object sender, System.EventArgs e) {    }
    #region Web Form Designer generated code
      override protected void OnInit(EventArgs e)
      {
        InitializeComponent();
        base.OnInit(e);
      }
      private void InitializeComponent()
      {    
        this.Load += new System.EventHandler(this.Page_Load);
      }
    #endregion
    void Page_Load(object sender, EventArgs e)
    {
      Label1.Text = "Hello ASP.NET 2.0";
    }
  }
}

新しいファイルでは、コントロールは ASPX ページ (もう一方の部分クラス) で宣言されるため、このコードがすべて取り除かれています。

namespace ASP {
  public partial class Webform1_aspx
  {
    void Page_Load(object sender, EventArgs e)
    {
      Label1.Text = "Hello ASP.NET 2.0";
    }
  }
}

このように、新しい分離コード ファイルの方が、はるかに整然として読みやすいものになっています。ASP.NET ページにコントロールを追加すると、自動的に分離コード ファイルからアクセスできるようになり、Visual Studio 2005 の IntelliSense や同期の機能も利用できるようになります。また、分離コード ファイルを使用している場合は Visual Studio でそのことが認識されて、イベントにアクセスするためにコントロールをダブルクリックすると、コード ビューではなく分離コード ファイルが開きます。

/Code ディレクトリ

コーディング モデルに対する最後の重要な変更は、ASP.NET の一般的な問題に直接対処するものです。ほとんどの Web アプリケーションは、1 つ以上のサポート クラスを必要とします。ASP.NET でよく使用される方法では、サポート クラスのためのプロジェクトを別に作成し、そのサポート プロジェクトへの参照を Web アプリケーションに追加します。別のプロジェクトを作成しないとしても、アプリケーション内で使用するすべての名前空間への参照を作成しなければなりません。比較的大規模で複雑なアプリケーションでは別のプロジェクトを用意する意味もありますが、1 つか 2 つの単純なクラスが必要なだけの開発者にとってはこれが苦痛となる場合がほとんどです。

ASP.NET 2.0 では、サポート コードを追加するための新しい方法として、/code ディレクトリが導入されています。/code ディレクトリは特殊なディレクトリで、自動的にコンパイルされ、ASP.NET アプリケーションによって参照されます。つまり、/code ディレクトリ内に配置したクラスは自動的に、アプリケーションの任意の ASPX ページからアクセスできるようになります。Visual Studio 2005 と ASP.NET コンパイラの両方で、これらのクラスから自動的にアセンブリが作成されて、そのアセンブリへの参照が Web アプリケーションに配置されます。

構成とサイト保守

ASP.NET 開発者にとってさらに困難な課題となっていたのが、web.config ファイルを正しく構成することです。ASP.NET 2.0 と Visual Studio 2005 には、この作業を支援する新機能がいくつか用意されています。

web.config の IntelliSense

まず、Visual Studio の IntelliSense 機能が拡張されて、有効なスキーマを持つ任意の XML ファイルで利用できるようになりました。つまり、web.config ファイルを Visual Studio で編集するときはいつでも、IntelliSense が完全にサポートされることになります。

Dd229411.migratefromaspnetto2_fig04(ja-jp,MSDN.10).gif
図 4. web.config の IntelliSense

IntelliSense は、ファイルの構成の誤りを防ぐのに役立ちます。ただし、ASP.NET 2.0 で新たに導入された管理 Web サイトと Microsoft 管理コンソールを使用すれば、構成作業がさらに簡単になります。

管理 Web サイト

ユーザー管理プロセスを簡略化するために、ASP.NET 2.0 には組み込みの Web サイト構成ツールが備えられています。Web サイト管理ツールは単純な Web サイトで、セキュリティで保護された接続を使用するか、直接ローカル ホストから接続しないとアクセスできません。このツールを使用することにより、管理者は、ユーザー管理、パーソナライゼーション プロバイダ、セキュリティ、プロファイルなどのサービスを構成して、アプリケーションを管理することができます。また、アプリケーションのデバッグや情報のトレースのためのカウンタも簡単に構成できます。

拡大するにはここをクリックしてください。
図 5. Web サイト管理ツール

Microsoft 管理コンソール スナップイン

ASP.NET 2.0 は、IIS 用の特殊な Microsoft 管理コンソール (MMC) スナップインを配置します。これを使用すると、どのアプリケーションにどのバージョンの .NET Framework が必要かがわかります。

拡大するにはここをクリックしてください。
図 6. MMC による ASP.NET アプリケーションの表示

MMC の [IIS] タブでは、アプリケーションで使用する ASP.NET のバージョンを選択できます。また、Web.config の場所も表示されます。

このコンソールでは、フレームワークのバージョンを管理できるだけではありません。[Edit configuration] ボタンをクリックすると、Web.config のほとんどの設定を視覚的に編集することができます。これにより、Web.config XML ファイルを直接操作する必要がなくなります。管理者にとってこの MMC スナップインは、1 つのサーバー上にある複数の ASP.NET アプリケーションの構成や管理を行ううえで非常に便利なツールとなります。

強化された構成 API

構成情報の取得や編集には、System.Configuration.Configuration クラスを使用することもできます。これらの API を使用すると、XML 構成ファイルにプログラムでアクセスできます。これにより、カスタム管理ツールを開発することができます。たとえば次のコードでは、ローカル コンピュータ上のアプリケーションで有効になっている認証の種類が表示されます。

// C#

Configuration cfg = Configuration.GetConfigurationForUrl("/Application_name"); 
Response.Write( cfg.Web.Authentication.Mode.ToString() );

Microsoft Visual Basic .NET

Dim cfg As Configuration = 
  Configuration.GetConfigurationForUrl("/Application_name") 
Response.Write( cfg.Web.Authentication.Mode.ToString() )

次のコードは、ローカル Web アプリケーションでフォーム ベースの認証を有効にします。

// C#

Configuration cfg = Configuration.GetConfigurationForUrl("/MyApp"); 
cfg.Web.Authentication.Mode = HttpAuthenticationMode.Forms; 
cfg.Update(); 

Visual Basic .NET

Dim cfg As Configuration = & _
  Configuration.GetConfigurationForUrl("/MyApp") 
cfg.Web.Authentication.Mode = HttpAuthenticationMode.Forms cfg.Update()

これら 4 つの機能 (IntelliSense 、管理 Web サイト、MMC スナップイン、および構成 API) はすべて、ASP.NET アプリケーションの構成に費やされる時間と労力の節約に役立ちます。

開発の変更

ASP.NET 2.0 と Visual Studio 2005 では、Web アプリケーション開発の日常的な側面も多数変更されています。ここでは、ASP.NET 1.x の機能が大幅に変更されている領域をいくつか取り上げて見ていきます。

サーバーへの接続

ASP.NET 1.x と以前のバージョンの Visual Studio .NET では、IIS インスタンスに接続するには Microsoft Front Page Server Extensions を使用しなければなりませんでした。また、開発者が新しい Web サイトを作成するには、IIS インスタンスに対する管理アクセス権が必要でした。社内ネットワークで余分な Web サーバーを実行することは、作成、監視、更新、および保守に伴う管理上の負担から、多くの企業で敬遠されていました。ASP.NET 2.0 では、サーバーへの接続に変更が加えられています。

開発サーバー

まず、Visual Studio 2005 では、開発者のために開発専用の Web サーバーが組み込まれています。この軽量な Web サーバーはローカルの要求にしか応答しないため、セキュリティ上の脅威にはなりません。しかし完全なデバッグ機能がサポートされているため、新しい Web アプリケーションを開発するためのツールとして使用できます。スケーラビリティやパフォーマンスをテストしたり運用環境に配置したりする準備ができたら、後はアプリケーションを IIS に移動するだけです。

運用サーバー

IIS インスタンスに接続する際には、接続方法を選択できるようになりました。Visual Studio .NET で Web アプリケーション プロジェクトを開くと、接続方法を選択するよう求められます。

Dd229411.migratefromaspnetto2_fig07(ja-jp,MSDN.10).gif
図 7. FTP による Web アプリケーションへの接続

Front Page Server Extensions、FTP、Share Point、およびその他のさまざまなメカニズムを使用して、ファイルをサーバーに転送し、コードを同期させることができます。

ASP.NET 2.0 アプリケーションのコンパイル

従来の ASP.NET 1.x に対するもう 1 つの重要な変更は、Web アプリケーションのコンパイル方法に関するものです。ASP.NET 1.x では、アプリケーションは初めて要求されたときにコンパイルされるか、起動時にバッチ モードでコンパイルされるかのいずれかでした。どちらの方法にも、それぞれ長所と短所があります。両者に共通する最大の欠点は、通常はコンパイルされていないコードを運用サーバーに配置しなければならないことです。このコードは運用サーバー上で直接操作できますが、このことは、セキュリティの要件しだいで長所にもなれば短所にもなります。

ASP.NET 2.0 の新しいコンパイル方法を使用すると、自分に所有権があるソース コードを配置用のバイナリ アセンブリにプリコンパイルできます。プリコンパイルされたアプリケーションは、厳密な名前および署名を付けることのできるアセンブリと、さまざまなリソース ファイル (攻撃者にとってはあまり価値のないイメージなど) で構成されています。したがって、プリコンパイルされたアプリケーションでは、標準の ASP.NET アプリケーションに比べて大幅にセキュリティが強化されます。

サイト ナビゲーション

Web サイトで快適なユーザー エクスペリエンスを提供するには、一貫したナビゲーションが欠かせません。従来の ASP アプリケーションでは、ハイパーリンクや、ハイパーリンクをカプセル化したユーザー コントロールを追加するしかありませんでした。これらのハイパーリンクは作成するのに時間がかかるうえ、アプリケーション内でページを新しい場所に移動した場合によく問題になります。ASP.NET 1.x ではこの問題に対する有効な解決策はなく、HTML タグや ASP.NET コントロールのプロパティにリンクをエンコードしなければなりませんでした。ASP.NET 2.0 には、サイト ナビゲーションを改善し、Web ページの物理的な場所の変更に伴う保守作業を軽減する、数々の新機能が導入されています。

ASP.NET 2.0 では、アプリケーションのナビゲーションを論理構造に基づいて定義できます。 ナビゲーションに論理構造を使用すると、サーバー上の各ページの物理的な場所に依存することなく、Web ページを互いに論理的に関連付けることによって、アプリケーションのナビゲーション パスを作成できます。ナビゲーションを論理的に編成することによって、コードを一切変更せずにアプリケーションのナビゲーションを再編成できるようになります。また、この論理構造を使用して、ツリー ビュー、メニュー、"ブレッドクラム" の経路などのナビゲーション補助機能を作成することもできます。

web.sitemap ファイル

ASP.NET 2.0 の SiteMap クラスは、Web サイトの論理構造を公開します。基になる構造は、ASP.NET 2.0 に含まれているサイト ナビゲーション プロバイダで XML を使用して定義することも、カスタム プロバイダで他のデータ形式を使用して定義することもできます。いったんレイアウトを定義したら、そのナビゲーション構造をさまざまな形で使用できます。

論理構造は、次の 2 段階の手順で簡単に作成できます。

  1. サイトのページの配置を階層構造で示す web.sitemap という XML ファイルを作成します。新しい .sitemap ファイルは、Visual Studio 2005 で作成できます ([新しい項目の追加] をクリックし、サイトマップ テンプレートを選択します)。.sitemap ファイルの編集時には、IntelliSense もサポートされます。

    <?xml version="1.0" encoding="utf-8" ?> 
    <siteMap>
       <siteMapNode title="Home" url="default.aspx">
              <siteMapNode title="Article 1"  
                url="~/articles/demoarticle1.aspx" />
              <siteMapNode title="Article 2"  
                url="~/articles/demoarticle2.aspx" />
    
       <siteMapNode title="Article 3"  
           url="~/articles/demoarticle3.aspx" />
       </siteMapNode>
       <siteMapNode title="Picture Gallery" 
          url="~/PhotoAlbum/PhotoAlbums.aspx">
              <siteMapNode title="Meetings" 
                url="~/PhotoAlbum/PictureAlbum.aspx?albumid=1"/>
              <siteMapNode title="Activities"
                url="~/PhotoAlbum/PictureAlbum.aspx?albumid=2"/>
              <siteMapNode title="Training" 
                url="~/PhotoAlbum/PictureAlbum.aspx?albumid=3"/>
    
       </siteMapNode>
       </siteMapNode>
    </siteMap>
    
  2. SiteMapDataSource コントロールをツールボックスからページ上にドラッグ アンド ドロップします。SiteMapDataSource コントロールは、web.sitemap ファイルに含まれている論理サイト構造に自動的に連結されます。

いったんページ上に配置した SiteMapDataSource コントロールは、treeview コントロールや menu コントロールなどの他のコントロールに簡単に連結できます。

<%@ page language="VB" master="~/Mysite.master" %>
  <asp:content id="Content1" contentplaceholderid="LeftSideContent">

    <H2>Navigation </h2>
    <asp:treeview id="Navigation tree" runat="server" 
        datasourceid="NavSource"/>
 </asp:content> 

このツリー ビューでは、app.sitemap ファイルの定義に基づいてサイト ナビゲーションが階層的に表示されます。

ナビゲーション コントロール

ASP.NET 2.0 には、サイト ナビゲーション サービスで使用できる一連のナビゲーション コントロールも導入されています。<asp:TreeView> コントロールや <asp:Menu> コントロールを使用すると、アプリケーションのナビゲーション構造を視覚化することができます。新しい <asp:SiteMapPath> コントロールでは、"ブレッドクラムの経路" のナビゲーション構造を生成できます。

Dd229411.migratefromaspnetto2_fig08(ja-jp,MSDN.10).gif
図 8. Home | Articles | Article 2 ページのブレッドクラムの経路

URL マッピング

URL マッピングもまた、ASP.NET 2.0 のナビゲーション関連の新機能の 1 つです。Web サイトでは、複雑に入り組んだ長い URL が必要になることがよくあります (MSDN の参照などはまさにそうです)。従来の ASP アプリケーションで URL を隠すには、カスタム ISAPI ハンドラを作成して要求を事前に処理しなければなりませんでした。ASP.NET 2.0 では、Web.config ファイルに URLMapping という構成セクションが追加されています。開発者は、実際の URL をユーザーにわかりやすい URL にマップすることによって、実際の URL を隠すマッピングを定義することができます。

<urlMappings enabled="true">
    <add url="~/Home.aspx" mappedUrl="~/Default.aspx?tabid=0" />
</urlMappings>

上の構成では、Home.aspx に対するすべての要求が Default.aspx?tabid=0 にマップ (およびリダイレクト) されます。ユーザーがブックマークに登録したりユーザーのブラウザに表示されたりするのは、短い方のリンクになります。

データ アクセスとデータ ソース

ASP.NET 1.x のデータ アクセスでは、ADO.NET の接続とコマンドを活用して、さまざまな ASP.NET コントロールにデータを連結することができました。ASP.NET 2.0 では、データ ソースの提供によって、ADO.NET との関係がさらに強化されています。データ ソースでは、接続とコマンドの両方を作成するコードが、Web.config ファイル内の 1 つの XML タグにカプセル化されています。これらのデータ ソースは、ASP.NET 1.x と同様に、Visual Studio 2005 のウィザードを使用して作成できます。ASP.NET 2.0 には、以下の要素に対応するデータ ソースが用意されています。

  • Microsoft Access。 access データ ソースを使用すると、自動的に Access データベースに接続してクエリを実行できます。
  • オブジェクトOjbectDataSource コントロールは、中間層やその他のオブジェクト セットの上位にあたるデータ層の抽象化です。1 つ以上のオブジェクトのセットを、データ連結コントロールにリンクするデータとして扱いたい場合に、オブジェクト データ ソースを使用できます。
  • データセットDataSetDataSource は、カンマ区切りのファイルや XML ファイルなど、一部が表形式になっているデータにリンクします。
  • XMLXmlDataSource は、XML ファイル内の階層データにリンクします。XmlDataSourceDataSetDataSource の主な違いは、XmlDataSourceTreeView などの階層コントロールとの連結に、DatasSetDataSourceDataGrid などの表形式のコントロールとの連結に、それぞれ適しているという点にあります。
  • サイト マップSiteMapDataSource は、ブレッドクラムなどのサイト ナビゲーション コントロールのデータ ソースを提供します。

データ ソースの詳細については、「ASP.NET 2.0 におけるデータ アクセス」を参照してください。

新しいデータ連結コントロール

ASP.NET 2.0 には、新しいデータ連結コントロールも 2 つ含まれています。1 つ目の GridView コントロールは、DataGrid コントロールを拡張したもので、セルの編集、複数ページでの行の表示、並べ替え、削除、選択、およびその他の一般的な動作のための構成可能なコードが用意されています。

Dd229411.migratefromaspnetto2_fig09(ja-jp,MSDN.10).gif
図 9. GridView の構成

もう 1 つの DetailsView コントロールは、GridViewDataGrid の両方を補完する詳細なビューを提供します。

Dd229411.migratefromaspnetto2_fig10(ja-jp,MSDN.10).gif
図 10: DetailsView コントロール

DetailsView コントロールでは一度に 1 つのレコードが表示されるため、レコードの表示、編集、削除、または作成の方法を従来よりはるかに細かく制御できます。

モバイル デバイス用 Web アプリケーション

ASP.NET 用の Web アプリケーションを開発したことがある方は、Microsoft Mobile Internet Toolkit (MMIT) や特殊なモバイル コントロールを目にしたことがあるでしょう。ASP.NET 2.0 では、MMIT とモバイル コントロールがメイン フレームワークに組み込まれています。ただし、ASP.NET 2.0 では標準のコントロールも、以前のモバイル コントロールと同じ動作を提供するアダプティング レンダリング モデルを使用するようになっています。ただ、従来より柔軟性が高く、使いやすいパッケージになっています。

ASP.NET 2.0 の新機能

API やフレームワークのメジャー アップデートでは、ほとんどの場合、既存機能の変更と新機能や拡張の両方が含まれます。ここでは、ASP.NET 2.0.x で使用できる新機能をいくつか取り上げて見ていきます。

マスタ ページ

マスタ ページは ASP.NET 2.0 で導入された新機能で、サイトで一貫したルック アンド フィールを維持するための 1 つの場所を定義することによって、Web アプリケーションの開発時間を短縮できます。マスタ ページを使用すると、アプリケーションの多くのページに共通のレイアウトを生成するためのテンプレートをデザインできます。

マスタ ページの第 1 の目標は、ページを毎回ゼロから作成したり、レイアウトのコードを繰り返し記述したりしなくても済むようにすることです。また、マスタ ページを使用すると、アプリケーションのページのレイアウトを変更する必要が生じた場合に、個々のページを更新しなくてもマスタ ページを更新するだけで済むというメリットもあります。この機能は、Microsoft Windows フォームのビジュアル継承に少し似ています。ビジュアル継承は、元のバージョンの .NET Framework で利用可能な機能で、デスクトップ アプリケーションの開発に使用されます。

マスタ ページは、拡張子 (.aspx ではなく .master) といくつかの特殊なコントロールやヘッダー フィールドを除いては、見た目は標準の ASP.NET Web ページと変わりません。マスタ ページには、<asp:ContentPlaceHolder> コントロールが 1 つ以上含まれている必要があります。これらのコントロールは、置き換え可能なコンテンツの領域を表します。基本的には、ContentPlaceHolder に含まれているものを除くすべての要素が、マスタ ページを使用するすべてのページに表示されます。

このコードの大半は Visual Studio 2005 によって自動的に作成されるため、ページのレイアウトのために複雑な HTML コードを記述する必要はありません。マスタ ページには、以下に示す既定のソース コードも含まれている必要があります。

<%@ master language="C#" compilewith="site.master.cs" 
     classname="ASP.site_master" %>
<html>
<head runat="server"><title>Untitled Page</title></head>

<body>
  <form runat="server">
    <asp:contentplaceholder id="ContentPlaceHolder1" runat="server">
    </asp:contentplaceholder>
  </form>
</body>
</html>

これらの重要な変更点のほか、マスタ ページには、標準の ASP.NET ページで見られるあらゆる HTML やコントロールを含めることができます。

マスタ ページはフレームと用途が似ていますが、マスタ ページの方がはるかに高機能です。マスタ ページでは、フレームとは違って、次のようなことが可能です。

  • ページをブックマークに登録して、既定のフレーム ページだけでなくそのページのすべての情報を再表示することができます。マスタ ページはフレームではありません。マスタ ページの照合コンテンツと、マスタを基に作成されたコンテンツ ページを含む、1 つのページです。したがって、その外観も動作も、フレームよりは 1 つの Web ページに似ています。
  • HTML ではなくコントロールやタグを使って作業することができます。Visual Studio を使用すれば、各フレームが正しく表示されるようにするために、フレーム タグの組み合わせに気を配ったり、無数の HTML 属性を変更したりする必要はありません。プレース ホルダを作成して、そのプロパティを Visual Studio で変更するだけで済みます。
  • Visual Studio のコード作成機能を活用して、視覚的にレイアウトをデザインしたりフレームを管理したりできます。コンテンツ ページをマスタ ページにリンクさせるための基礎コードを記述する必要もありません。新しいコンテンツを追加する場合も、ページ全体の HTML レイアウトへの影響を心配する必要はありません。

要するに、マスタ ページを使用することによって、Web アプリケーションの外観を統一する作業を、含まれるページの量に関係なく、大幅に簡略化できます。

コンテンツ ページ

マスタ ページにアタッチされるコンテンツ ページは、マスタ ページ内の ContentPlaceHolder コントロールのコンテンツを定義します。コンテンツ ページに含まれる <asp:content> コントロールは、ContentPlaceHolder ID を通じてマスタ ページの <asp:contentPlaceHolder> コントロールを参照します。コンテンツ ページとマスタ ページの組み合わせによって、1 つの応答が形成されます。

<%@ page language="VB" master="~/Mysite.master" %>
<asp:content id="Content1"  contentplaceholderid="LeftSideContent">
    <H2>Navigation </h2>
    <asp:treeview id="Navigation tree" runat="server" 
      datasourceid="NavSource"/>
</asp:content>
<asp:content id="Content1"  contentplaceholderid="RightSideContent">

    <asp:label runat="server">Support section</asp:label>
</asp:content>

ここでも、ユーザーが実際に要求するのはコンテンツ ページです。ASP.NET はマスタ ページへの参照を検出し、マスタ ページのコンテンツをコンテンツ ページと一緒に表示します。

入れ子になったマスタ ページ

サイトのレイアウトやスタイルをより細かく制御するために、マスタ ページを入れ子にしなければならなくなる場合もあります。たとえば、企業の Web サイトのすべてのページに共通のヘッダーとフッターがある場合に、経理部門で、IT 部門とは若干異なるテンプレートを使用するとします。

Dd229411.migratefromaspnetto2_fig11(ja-jp,MSDN.10).gif
図 11. 入れ子になったマスタ ページ

このような場合は、個々の部門のマスタ ページを最上位の企業のマスタ ページの中に入れ子にすることによって、各部門で高度な一貫性を実現しつつ、コンテンツ ページとマスタ ページでオーバーライドできる要素を制御できます。

ここで覚えておくべき重要な点は、アプリケーションのコンテンツが複数のマスタ ページとコンテンツ ページで構成されている場合でも、エンド ユーザーは 1 つのページを要求し、1 つのページを受け取るということです。

マスタ ページのオーバーライド

マスタ ページの目的は、アプリケーションのすべてのページに一貫したルック アンド フィールを提供することですが、特定のページで一部のコンテンツをオーバーライドする必要が生じることも考えられます。コンテンツ ページのコンテンツは、単純にコンテンツ コントロールを使用してオーバーライドできます。

マスタ ページを動的にオーバーライドするには、MasterPage クラスのパブリック プロパティを、自分で作成したものも含めて、プログラムで公開する必要があります。これにより、たとえば HTML ページの <head> セクションの <title> プロパティと <keyword> プロパティをオーバーライドしたい場合は、マスタ ページで設定されている既定のプロパティを編集するための関数を作成できます。

<head runat="server" id="Head1"> 
   <title><% =m_HtmlTitle %></title>

     <meta name="keywords" content="<% =GetKeywords() %>" > 
     <meta name="description" 
       content="A newsletter focused on meeting the needs of .NET
               developers, providing cool tips for the advanced 
               programmer, and keeping
               you informed on what's happening with .NET!" > 
     <LINK href="<% =Request.ApplicationPath %>/portal.css"
           type="text/css" rel="stylesheet">
</head> 

テーマとスキン

現在、ASP 開発者が Web サイトのルック アンド フィールを制御するには、カスケード スタイル シート (CSS) とインライン スタイルを使用するしかありません。これらの技術も役には立ちますが、この場合の一貫性は、主として、開発者が正しいスタイルを使用するかどうかにかかっています。ASP.NET 2.0 では、Web サイトのすべてのページとコントロールに一様に適用されるテーマとスキンを使用することによって、この点が改められています。

テーマ

テーマは、対象となるすべてのページに適用される共通の属性のセットを定義するという点では、CSS スタイル シートに似ています。しかしテーマは、次のような点でスタイル シートとは異なります。

  • 特定のスタイル プロパティのセットだけでなく、コントロールやページのさまざまなプロパティを定義できます。
  • CSS スタイル シートには含めることのできない補助的なファイル (グラフィックスなど) を含めることができます。
  • スタイル シートのようにカスケードしません (たとえば、テーマのプロパティ値は常にローカルのプロパティ値をオーバーライドします)。
  • スタイル シートの参照を含めることができます。

各アプリケーションに 1 つずつ Themes ディレクトリがあり、そこに各テーマごとに専用のサブディレクトリがあります。スタイルに適用されるスキン ファイルやその他のファイルは、このサブディレクトリに含まれています。

テーマの定義

テーマとスキンを定義して、Themes ディレクトリから分岐するサブディレクトリに配置することができます。各サブディレクトリが 1 つのテーマを構成します。テーマ サブディレクトリには、.skin ファイルやその他のリソース (テーマで使用するイメージ ファイルやスタイル シートなど) が含まれています。

Dd229411.migratefromaspnetto2_fig12(ja-jp,MSDN.10).gif
図 12. Themes ディレクトリのサブディレクトリ

実際のスキン定義は .skin ファイルに含まれており、ASPX ファイルでコントロール インスタンスの宣言に使用するタグによく似ています。

例として、Themes ディレクトリに Pink というサブディレクトリを作成してみましょう。このテーマの .skin ファイルは、ファイルに次のコードを追加して Pink ディレクトリに保存するだけで簡単に作成できます。

<asp:DropDownList runat="server" BackColor="hotpink" 
  ForeColor="white" />
<asp:DataGrid runat="server" BackColor="#CCCCCC" BorderWidth="2pt"
    BorderStyle="Solid" BorderColor="#CCCCCC" GridLines="Vertical"
    HorizontalAlign="Left">
      <HeaderStyle ForeColor="white" BackColor="hotpink" />

      <ItemStyle ForeColor="black" BackColor="white" />
      <AlternatingItemStyle BackColor="pink" ForeColor="black" />
</asp:DataGrid>

これで、このテーマをアプリケーションのページに適用できます。もちろんこのテーマでは、データ グリッドの背景が ピンクに変わります (お望みの効果ではないかもしれませんが)。

テーマの使用

テーマは次のような形で適用できます。

  • 1 つのタグを使ってページ レベルで適用する (例: <% @page language="VB" theme="Pink" %>)。
  • Web.config ファイル内の構成要素を使ってサイト全体で適用する (例 : <pages theme="Pink" />)。Web.config ファイルは、各 ASP.NET アプリケーションのマスタ構成ファイルです。

ここで、図 13 の一般的なカレンダー コントロールを使って、テーマの効果を確認してみましょう。

Dd229411.migratefromaspnetto2_fig13(ja-jp,MSDN.10).gif
図 13. Basic Blue テーマを設定したカレンダー

このバージョンのカレンダーは Basic Blue テーマを使用しています。テーマの属性を変更するだけで、このカレンダーの外観が一変します (図 14を参照)。

Dd229411.migratefromaspnetto2_fig14(ja-jp,MSDN.10).gif
図 14. Smoke and Glass テーマを設定したカレンダー

スキン

スキンとはプロパティとテンプレートのセットであり、これを使用して、ページ上のコントロールのサイズ、フォント、およびその他の特性を標準化できます。スキンを使用してコントロールの表示設定をあらかじめ定義しておき、実行時に適切なスキンを適用できます。たとえば、ユーザー設定に基づいてスキンを選択したり、ページへのアクセスに使用されているブラウザに基づいて適切なスキンを判断したりできます。定義済みのコントロールにオプションのスキンを適用するには、SkinId プロパティを設定します。

<!- Default Skin -->!>
<asp: label runat="server" Font-names="verdana, arial" font-size="10pt"
      ForeColor= "#000066" BackColor="transparent"
/>
<!- Title Skin -->!>
<asp: label runat="server" id="foo" skinid="Title" 
      Font-names="verdana, arial"
      font size="18pt" ForeColor= "#000066" 
      BackColor="transparent" font-bold="true"
      font-underline="true"
/>

いったん定義したスキンは、ページ上のすべてのコントロールに適用することも、テーマと SkinID プロパティを使用して特定のコントロールに適用することもできます。このプロパティは、すべてのスキン対応コントロールに組み込まれています。

コントロールへのスキンの適用

既定のスキンが存在し、ページがテーマによって定義されている場合は、自動的に既定のスキンがコントロールに適用されます。コントロールの SkinID プロパティを定義すると、既定のスキンが、SkinID プロパティで参照されているスキンに置き換わります。このプロパティは、開発時に構成することも、実行時に構成することもできます (ページの更新を使用)。

メンバシップ

ASP 開発の大きな欠点の 1 つは、ユーザー管理の枠組みをゼロから作成しなければならないことです。このプロセスは複雑なだけでなく、多くの時間を必要とします。ASP.NET 2.0 では、メンバシップ プロバイダとログイン コントロールを使用して、統一された方法でユーザー情報を管理できます。

ユーザーがアプリケーションにログインするたびに、そのユーザーの ID と基本的なユーザー情報が自動的に参照されます。ユーザーの資格情報は、バックエンドのユーザー データベースに安全に格納されます。このデータベースは、Web.config ファイルで構成できます。ASP.NET 2.0 には Microsoft Access と Microsoft SQL Server の両方のプロバイダが用意されていますが、カスタム プロバイダを作成すれば、あらゆる種類のバックエンド データ ストアを使用できます。既存のアカウント データベースを ASP.NET のメンバシップ機能と一緒に使用したい場合などには、この拡張性が大いに役立ちます。アプリケーションのメンバシップを構成できたら、ASP.NET 2.0 のログイン コントロールを使用して、ユーザーの登録とパスワードの取得を自動化できます。

ログイン コントロール

ASP.NET 2.0 の新しいログイン コントロールを使用すると、コードを一切記述せずにユーザー アカウントの作成や管理を行うことができます。<asp:CreateUserWizard> コントロールをページ上にドラッグするだけで、ユーザー登録フォームを作成できます。このフォームは、ステップ バイ ステップのウィザードでユーザーに登録プロセスを案内します。

新しいログイン コントロールでは、直感的なインターフェイスを使って、コントロールをアプリケーションのデザインに合わせてフォーマットできます。プロパティ ウィンドウでは、各プロパティのラベル、値、およびエラー メッセージ検証要素にアクセスできます。LoginName コントロールと LoginStatus コントロールを使用すると、ユーザーごとに異なるウェルカム メッセージを表示したり、コードを一切記述せずにログイン/ログアウト機能を作成したりできます。

LoginView コントロールでは、どのユーザーに対してどのコンテンツを表示すればよいかを、1 行もコードを書かずに特定できます。各ユーザーの状態とロールから適切なビューを特定することによって、コンテンツが表示されます。従来の ASP アプリケーションでこれを行うには、現在のユーザーを識別するためのコード、ユーザーの状態を確認するためのコード、ユーザーに基づいてコンテンツを表示するためのコードなど、多くのコードを記述しなければなりません。

Web パーツの詳細については、「ASP.NET 2.0 のパーソナライゼーション機能」を参照してください。

プロファイル

ASP.NET 2.0 のプロファイル機能を使用すると、Web サイトを訪問するユーザーに関連付けられた情報の定義、保存、および取得を行うことができます。従来の ASP アプリケーションでは、ユーザーに関するデータを収集し、ユーザー セッションの間そのデータをセッションに格納し、ユーザーが Web サイトを離れたらそのデータを永続的なデータ ストアに保存するためのコードを、独自に開発しなければなりません。ASP.NET 2.0 では、これらすべての機能が、プロファイルによって自動化されています。プロファイルの本質は、ユーザーに関連付けられた情報のバケットです。この情報には、すべての ASPX ページからアクセス可能な Profile オブジェクトを通じて直接アクセスできます。

プロファイルの定義

プロファイルは、machine.config または Web.config で、各ユーザーの名前、請求先住所、電子メール アドレスなどの情報を表す <property> 値を使って定義できます。論理プロパティのグループを作成することも可能です。

<profile>
  <group name="BillingAddress">
    <add name="Street" type="System.String" />

    <add name="City" defaultValue="Toronto" type="System.String" />
    <add name="StateProv" type="System.String" />
    <add name="ZipPostal" type="System.String" />
  </group>
</profile>

いったんプロファイルを定義すれば、後は ASP.NET とプロファイル プロバイダによってその情報が自動的に管理されます。要求時の読み込みやユーザーがサイトを離れるときの格納も自動的に行われます。

プロファイルの使用

プロファイルを定義すると、Visual Studio 2005 によってプロファイルのプロパティが Profile オブジェクトを通じて自動的に公開されます。

Dd229411.migratefromaspnetto2_fig15(ja-jp,MSDN.10).gif

図 15. プロファイルの使用

また、Visual Studio 2005 では、プロファイルで IntelliSense が完全にサポートされます。プロファイルの定義を変更した場合も、Web.config ファイルを保存するとすぐ、自動的に正しい IntelliSense が提供されるようになります。

Web パーツ

デスクトップ アプリケーションでは、構成可能な複数のコンポーネントを簡単に含めることができます。この点はこれまで、Web アプリケーションとデスクトップ アプリケーションの重要な違いの 1 つとなっていました。Visual Studio IDE 自体を例に考えてみましょう。Visual Studio IDE では、どのウィンドウを表示し、ウィンドをどのように配置するかを、ユーザーが決めることができます。同様の機能を Web サイトで開発するのは容易なことではありません。

ASP.NET 2.0 では、Web パーツという形でこの問題が解決されています。Web パーツは、必要なものだけを使用して生産性の高いインターフェイスを作成するために、ユーザーが自由に取り入れて配置することができるモジュール コンポーネントです。ユーザーは、たとえば次のようなことを行うことができます。

  • 表示するパーツの選択
  • 任意の順序または配置でのパーツの構成
  • 複数の Web セッション間でのビューの保存
  • 特定の Web パーツの外観のカスタマイズ

これらの機能はどれも、通常の Web アプリケーションで実装することは実質的に不可能です。

Web パーツは、Web ページのモジュール ブロックと見なすことができます。各ブロックは、実行時に動的に Web ページに追加したりページから削除したりすることができます。Web パーツの編成や操作に使用するコードは、ASP.NET 2.0 に組み込まれています。レイアウトの追加、削除、および構成を行う機能はすべて、Web パーツ システムにより自動的に処理されます。プログラマは、単に Web パーツを構築して、Web パーツ ゾーンに割り当てます。ユーザーは Web パーツを組み合わせて使用したり、任意の順序で表示することができます。変更した構成は、他のサイトを表示した後も維持されます。

Web パーツの使用

たとえば病院用の Web パーツ アプリケーションでは、患者の現在の状態から薬の相互作用に関する警告に至るさまざまな表示コンポーネントを、ユーザーが選択して表示できるようにすることができます。各ユーザーは、表示するパーツをカタログから選択します。

Dd229411.migratefromaspnetto2_fig16(ja-jp,MSDN.10).gif
図 16. Web パーツ カタログ

その後、コントロールをドラッグして、それぞれのニーズに合った形で配置できます。

拡大するにはここをクリックしてください。
図 17. Web パーツの配置

レイアウトと構成は、ユーザーが次に訪れるときのために自動的に保存されます。Web パーツの詳細については、「ASP.NET 2.0 のパーソナライゼーション機能」を参照してください。

まとめ

ASP.NET 2.0 は、ASP.NET 1.x の跡を継いで、スケーラビリティと拡張性に優れた構成可能な Web アプリケーション開発フレームワークを提供します。ASP.NET のコア アーキテクチャには、コンパイルと配置の多彩なオプションを新たにサポートするための変更が加えられています。また開発者にとっては、Visual Studio 2005 の新しいコントロール、新しいウィザード、および新しい機能によって、主な作業の多くを簡単に行えるようになっていることも見逃せません。最後に、ASP.NET 2.0 では、パーソナライゼーション、テーマとスキン、およびマスタ ページのための新しい革新的なコントロールが導入されており、その豊富なオプションがさらに拡充されています。ASP.NET 2.0 では、ASP.NET 1.1 のフレームワークをベースとするこれらすべての機能強化により、.NET Framework における Web 開発のオプションがさらに強化されています。

参考書籍

執筆者紹介

Jayesh Patel は、.NET および Java テクノロジの開発者です。パターン ベース プログラミングとアジャイル方法論を中心とする研究に取り組んでいます。

Bryan Acker は Infusion Development のテクニカル ライターです。ASP および ASP.NET の Web 開発や Web ホスティングに関する豊富な経歴を持っています。

Robert McGovern は Infusion Development のシニア ライターであり、開発者兼プロジェクト マネージャでもあります。『CodeNotes for ASP.NET』や『JSP to ASP.NET migration guide』など、さまざまな ASP.NET プロジェクトに参加しています。

Microsoft 公認ソリューション プロバイダの Infusion Development Corporation は、金融サービス業を中心とする Fortune 1000 の企業を対象に、カスタマイズ ソフトウェアの開発、トレーニング、コンサルティングなどのサービスを提供しています。ニューヨークとトロントに拠点を置く同社は、金融サービス、証券取引、およびソフトウェア開発の各業界における世界有数の企業を始めとする、国際的な顧客ベースを確立しています。Infusion Development の従業員は、CodeNotes シリーズの書籍の執筆や制作にも携わっています。