ASP.NET 2.0 への移行の概要
更新 : 2007 年 11 月
以前のバージョンの ASP.NET で採用されていたプログラミング概念の多くが、ASP.NET Version 2.0 でもそのまま採用されているため、ASP.NET 1.x のユーザーであれば ASP.NET 2.0 でも簡単にアプリケーションを開発できます。ASP.NET 2.0 は、ASP.NET 1.x アプリケーションを実行する場合と同じオペレーティング システムとハードウェアで実行します。たとえば、Microsoft Windows 2000 と Microsoft Internet Information Services (IIS) 5.0、Microsoft Windows XP と IIS 5.1、および Microsoft Windows Server 2003 と IIS 6.0 などです。
既存の Web アプリケーションを ASP.NET に移行する場合、ASP.NET 2.0 の新機能について確認しておく必要があります。最も重要な変更点としては、ページ分離コード モデル、Web アプリケーションのフォルダ構造、およびページ コンパイル モデルがあります。
移行する前に、ASP.NET 1.x アプリケーションが、開発したときの .NET Framework のバージョンでコンパイルおよび実行できることを確認しておく必要があります。また、移行を開始する前に、Microsoft .NET Framework Version 2.0 がインストールされ動作していることを確認します。
このトピックでは、移行前に考慮しておく必要のある一般的な事項について説明します。このトピックでは、次のセクションについて解説します。
移行の利点
ページ モデル
ASP.NET バージョン間でのデータの共有
ASP.NET バージョン間でのフォーム認証
名前の競合
マークアップのコンパイル
HttpOnly とクロスサイト スクリプティング
移行の利点
Web アプリケーションを ASP.NET 2.0 に移行すると、向上したマークアップとコードとの分離、予約済みアプリケーション フォルダ、自動コード コンパイルなど多くの新しい機能を利用できるようになります。
部分クラスに基づく新しい分離コード モデルにより、マークアップとコードとの分離が向上し、分離コード ファイル内のコントロール宣言とイベント ワイヤアップ コードが不要になります。ASP.NET ページ コンパイル モデルにより、分離コード ファイルは、実行時、対応する .aspx ファイルに対する最初の要求時に複数のアセンブリにコンパイルされます。
ASP.NET では、現在、予約済みフォルダに基づく高度な Web アプリケーション構造が採用されています。これらのフォルダには特定の内容が格納されるので、アプリケーションを効率的に編成できます。一部の予約済みフォルダ (App_Data など) は、Web 要求に対する応答としてはその内容を提供しませんが、アプリケーション コードからアクセスできます。詳細については、「ASP.NET Web サイトの構造」を参照してください。
Web サイト上のリソースが要求されると、アプリケーション コードとその依存リソースが ASP.NET 2.0 コンパイラにより自動的にコンパイルされます。たとえば、ASP.NET 2.0 上で既存の Web ページまたは依存リソースへの変更を保存して、そのページを再度要求するだけで、そのページとリソースを再コンパイルできます。この動作は、App_Code フォルダのコード ファイル、App_GlobalResources フォルダと App_LocalResources フォルダのリソース ファイル、および App_Themes フォルダのテーマに適用されます。ページ コンパイル モデルの詳細については、「ASP.NET コンパイルの概要」を参照してください。
大きなアプリケーションを移行する場合、Visual Web Developer 2005、Visual Web Developer 2005 Express Edition、Visual Studio 2005、または Visual Studio 2005 Team System の使用をお勧めします。それぞれに移行ウィザードがあり、移行に必要な数多くのタスクが自動化されています。移行ウィザードにより、ASP.NET 1.x Web アプリケーションを ASP.NET 2.0 に変換するために必要な変更が自動的に行われます。
ASP.NET 2.0 は高い下位互換性を持つため、Web アプリケーションを移行する必要はありません。移行しなくても、.NET Framework 2.0 を使用している限り、Web アプリケーション内の ASP.NET 2.0 の多くの機能を使用できます。既存の Web アプリケーションで .NET Framework 2.0 を使用するように構成する方法については、「方法 : .NET Framework 2.0 で ASP.NET 1.x アプリケーションを実行する」を参照してください。
ページ モデル
ASP.NET 分離コード Web ページ モデルでは、1 つの .aspx ファイルに Web ページのマークアップを格納し、別のファイル (分離コード ファイル) にプログラム コードを格納できます。ASP.NET 2.0 の分離コード モデルは、部分クラスと呼ばれる新しい言語機能を使用する点で以前のバージョンとは異なります。ASP.NET 2.0 の新しい分離コード モデルでは、以前のバージョンの ASP.NET よりマークアップとコードとの分離が向上しています。
@ Page ディレクティブの CodeBehind 属性に基づく古い分離コード モデルを使用する Web ページは、ASP.NET 2.0 上で引き続き動作します。ただし、向上したマークアップとコードとの分離と自動ページ コンパイルを利用する場合は、これらのページを、@ Page ディレクティブの CodeFile 属性と分離コード ファイルの部分クラス定義を使用する新しい分離コード モデルに移行することをお勧めします。古い分離コード モデルを使用する Web ページは、手動でコンパイルする必要があります。
「方法 : CodeBehind 属性を使用する ASP.NET 1.1 Web ページを ASP.NET 2.0 に移行する」で説明するように、手動で変更することもできますし、Visual Web Developer 2005 Express Edition など、移行ウィザードが組み込まれている Microsoft Visual Studio 2005 エディションを使用することもできます。
また、ASP.NET Version 1.1 は、@ Page ディレクティブの CodeBehind 属性が Src 属性に置き換えられるバリアントの分離コード モデルもサポートしています。Src 属性を使用する Web ページは、ASP.NET 2.0 上で引き続き動作します。実行するのに修正を加える必要はありません。
分離コード モデルの代替方法である単一ファイル ページ モデルは、ページのマークアップとプログラム コードを同じ物理 .aspx ファイル内に配置します。以前のバージョンの ASP.NET の単一ファイル ページは、ASP.NET 2.0 で引き続き動作します。実行するのに修正を加える必要はありません。
ASP.NET バージョン間でのデータの共有
Web サイトの一部だけを ASP.NET 2.0 に移行して、その他の部分は変更せずにおくことができます。Web サイトが複数の独立した Web アプリケーションに分割され、それらが一緒に動作して Web サイトを構成している場合、特定のアプリケーションのみ移行できます。このシナリオでは、移行したアプリケーションと移行しなかったアプリケーション間でのアプリケーション状態の共有はできなくなります。同様に、セッション状態についても、ASP.NET 1.x ページと ASP.NET 2.0 ページの両方からアクセスできるカスタム セッション状態ソリューションを用意しない限り、アプリケーション間で共有されなくなります。詳細については、「セッション状態ストア プロバイダの実装」を参照してください。
ASP.NET バージョン間でのフォーム認証
フォーム認証では、独自のコードを使用し、認証トークンを Cookie またはページ URL に保存してユーザーを認証できます。あるバージョンが発行した認証チケットを他のバージョンから使用できるように、異なる ASP.NET バージョンで実行するアプリケーション間でも適切に機能するように ASP.NET フォーム認証を構成できます。
異なる ASP.NET バージョン間で適切に機能するように認証を構成する方法は、Web サーバーのネットワーク (Web ファーム) 間で認証を構成するプロセスに似ています。どちらの場合でも、認証チケットを共有するアプリレーションに対して明示的に machineKey 要素の validationKey 属性と decryptionKey 属性を同じキーで設定します。ASP.NET バージョン間での認証をサポートするには、さらに、ASP.NET 2.0 アプリケーションの Web.config ファイルで machineKey 要素の decryption 属性を 3DES に設定する必要があります。ASP.NET 2.0 での既定の暗号化は AES ですが、以前のバージョンの ASP.NET では 3DES を使用しています。詳細については、「ASP.NET フォーム認証の概要」を参照してください。
名前の競合
移行する前に、Web アプリケーションをスキャンして、.NET Framework 2.0 の機能クラスや名前空間と競合している名前がないか確認しておくことをお勧めします。.NET Framework でも使用されている cache、membership、profile、role などの一般的な名前を Web アプリケーション内でも使用している場合に名前の競合が発生します。名前の競合を回避するには、コード内の該当する名前への参照を探し、それぞれに完全修飾参照を使用します。
ASP.NET 2.0 は、以前のバージョンとは異なる Web サイト レイアウトを使用します。ASP.NET では、内容の種類別に使用できる特定のフォルダ名とファイル名が予約されており、Web アプリケーションを簡単に操作できるようになっています。予約済みフォルダの内容は、その Web 要求には提供されないので、これが既存のアプリケーションで問題になる場合があります。したがって、個々のアプリケーション ファイルを移行する前に、ASP.NET 2.0 の予約済みのフォルダ名またはファイル名と競合するアプリケーションのフォルダ名またはファイル名を変更しておくことをお勧めします。ASP.NET Web サイト レイアウトの予約済みフォルダの詳細については、「ASP.NET Web サイトのレイアウト」を参照してください。
マークアップのコンパイル
既定では、ASP.NET、および ASP.NET に含まれる Web サーバー コントロールが生成するすべてのマークアップは XHTML 1.0 Transitional 標準に準拠します。これが、移行後に、HTML の表示に関する問題の原因になる可能性があります。Web アプリケーションを移行するために、Web.config ファイルで xhtmlConformance 要素の mode 属性を Legacy に設定できます。これは、移行プロセスにおける一時的なステップです。長期的には、xhtmlConformance 要素の mode 属性を Transitional に設定したアプリケーションを実行することをお勧めします。また、DOCTYPE 要素を移行したページに追加することをお勧めします。Web ページを XHTML 準拠にする利点の詳細については、「ASP.NET と XHTML」を参照してください。
HttpOnly とクロスサイト スクリプティング
HttpCookie クラスの HttpOnly プロパティは .NET Framework 2.0 で新たに追加されました。このプロパティを true に設定すると、クロスサイト スクリプティングの脅威を軽減できます。HttpOnly プロパティは、フォームの認証 Cookie とセッション ID Cookie の場合、自動的に true に設定されます。これは、これらの Cookie がクライアント側スクリプトでは使用できないためです。移行した Web ページから NullReferenceException 例外がスローされる場合、HttpOnly プロパティが true に設定されたために、クライアントのセッションが失われたことを示す可能性があります。この場合、次の解決方法のいずれかを使用できます。
Global.asax ファイルの HttpApplication クラスの EndRequest イベント ハンドラで、各 Cookie の HttpOnly プロパティを false に設定します。
クライアント スクリプトで操作できるように、Cookie を他の Cookie にコピーするカスタム モジュールを記述し、HttpOnly プロパティをクリアします。
HttpOnly プロパティを true に設定しないカスタム セッション ID マネージャを記述します。
クロスサイト スクリプティングの軽減の詳細については、「Mitigating Cross-site Scripting with HTTP-only Cookies」を参照してください。