連載 ASP→ASP.NET移行テクニック 第2回　移行インパクトのツボを探る 山田 祥寛 2004/05/22

Page1 Page2 Page3 Page4

　

≪今回の内容≫ 　・組み込みオブジェクトの変更点 　・そのほかの構成要素の変更点

　前回は、移行方式の類型化を試みると同時に、われわれがその中のどの類型パターンを選択するべきかといった、移行に関する指針を示した。また、移行に当たって、まず注目すべきレガシーASP／ASP.NETにおける構造上の変更点を概説した。

　今回はさらにブレイク・ダウンして、ASPの主要な構成要素である「組み込みオブジェクト」や「ディレクティブ」、「Global.asa」などの変更点について概観してみることにしたい。これら主要な構成要素に関する変更点を知ることで、移行時のアクション・アイテム（工数）がより明確になるはずだ。

組み込みオブジェクトの変更点

　レガシーASPには、インストール時に自動で組み込まれるビルトイン・オブジェクト（組み込みオブジェクト）が7種類ある。組み込みオブジェクトは、HTTPリクエストやレスポンスの処理をはじめ、ASPプログラミングにおける基本的な機能を担うものであり、恐らくASPアプリケーションのすべてが組み込みオブジェクトに依存しているはずである。

　これから実際に移行作業を行っていこうとしている読者諸兄にとって、組み込みオブジェクトがASP.NETにおいてどのような扱いになったのかという点は（恐らく）最大の関心事であるに違いない。組み込みオブジェクトの互換性いかんで、移行に伴うインパクトは大きく左右されるからだ。

　結論からいおう。

ASP.NETにおいて、旧来の組み込みオブジェクトは「ほとんどそのまま」利用することができる。

　ちょっと難しい裏の話をすれば、これは、Webフォーム・ページ（「.aspx」ファイル）の実体であるPageクラス（System.Web.UI名前空間）が旧来の組み込みオブジェクトと同名のプロパティを公開しているためだ（正確には、Webフォーム・ページはPageクラスの派生クラス）。これらのプロパティは、それぞれ旧来の組み込みオブジェクト相当の機能を提供するオブジェクトを返す。

プロパティ	戻り値の型
Application	HttpApplicationStateクラス（System.Web名前空間）
Session	HttpSessionStateクラス（System.Web.SessionState名前空間）
Request	HttpRequestクラス（System.Web名前空間）
Response	HttpResponseクラス（System.Web名前空間）
Server	HttpServerUtilityクラス（System.Web名前空間）
レガシーASPの組み込みオブジェクトと同名なPageクラスのプロパティ

　Webフォーム・ページ内の任意のコード・ブロックでは、Pageクラスから継承しているプロパティやメソッドに対して直接アクセスすることができる。すなわち、以下のコードはいずれも構文的にはまったく等価である。

Page.Response.Write("Y.Yamada")

　

Response.Write("Y.Yamada")

　

Dim res As HttpResponse=Page.Response res.Write("Y.Yamada")

　もっとも、2番目の構文が有効である以上、あえてより冗長な1番目と3番目の構文を採用するメリットは考えにくい。2番目の構文を利用することで、あたかもレガシーASP同様の「組み込みオブジェクト」なるものが存在するかのように、Webフォーム・ページ内でそれぞれのオブジェクトにアクセスできるというわけだ。

○変更・廃止されたオブジェクト／メソッド

　ただし、すべてのプロパティやメソッドが必ずしも完全な互換性を保証しているわけではなく、部分的に変更が加えられている（または廃止された）個所もある。以下では、これらについて主要なものを挙げておくことにしよう。

●Application.Removeメソッド

　レガシーASPにおいては、Application.Removeメソッドはパラメータとして、アプリケーション変数のキー名、インデックス番号、いずれでも指定することができる。よって、以下の2つのコードは、レガシーASPにおいては問題なく動作する。

パラメータとして「キー名」を指定した場合： Application.Remove("wings")

　

パラメータとして「インデックス番号」を指定した場合： Application.Remove(0)

　しかし、ASP.NETでは、パラメータとしてインデックス番号を指定した場合、Removeメソッドは正常に動作しない。しかも、明示的なエラーが出てくれればまだしも、VB.NETでは、暗黙的に文字列に変換されて処理されるため、明確なエラーとはならない（デフォルトではOption StrictがOffになっている）。ただ、キー名として「0」というキーは存在しないはずなので、削除処理も行わず、何事もなかったかのように以降のコードを継続してしまうのである。これは注意すべきポイントだ。

　なお、ASP.NETにおいて、インデックス番号で削除の対象を指定したい場合には、RemoveAtメソッドを使用すればよい。

Application.RemoveAt(0)

●Session.SessionIDプロパティ

　レガシーASPにおける同名のプロパティは、戻り値として長整数型（Long値）を返していた。しかし、ASP.NETではセッションID（Session.SessionID）は文字列型として返される。

Response.Write(Session.SessionID)

　このコードを実行すると、以下のような出力が得られる。

ASP 3.0（長整数型）：299702650
ASP.NET（文字列型）：zckdykbwt3horo45ori24b55

　余談であるが、この結果からも、前回説明したように「レガシーASPとASP.NETでセッションを共有することはできない」ことが確認できるだろう。たとえ、同一の仮想ディレクトリ上で同時に実行しているアプリケーションであっても、レガシーASPとASP.NETのセッションはまったく別物のキーで管理されているのである。

●Session.Removeメソッド

　Application.Removeメソッドと同様だ。レガシーASPでは、パラメータとして削除対象となるセッション変数のキー名、インデックス番号いずれでも指定することができたが、ASP.NETではキー名しか指定することができない。インデックス番号で指定したい場合には、Session.RemoveAtメソッドを使用すること。

INDEX
	ASP→ASP.NET移行テクニック
	第2回 移行インパクトのツボを探る
	1．変更・廃止されたオブジェクト／メソッド
	2．推奨されないメソッド／プロパティ
	3．ディレクティブ構文／Global.asax／構成ファイルの変更点
	4．SSI／Server.Executeメソッドについて

　

「ASP→ASP.NET移行テクニック」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）