次の方法で共有

アプリケーションの移行

  • [アーティクル]

ASP.NET 1.1 アプリケーションを Visual Studio 2010 に移行する

Jonathan Waldman

ASP.NET を数年以上使用している方なら、おそらく、Visual Studio 2003 を使用して Microsoft .NET Framework 1.1 向けのソリューションを作成した経験がおありでしょう。さらに近年になると、より新しくて機能豊富な .NET Framework 2.0、3.0、および 3.5 が登場しました。皆さんは、信頼できる 1.1 フレームワーク アプリケーションをこれらのバージョンのいずれかにアップグレードすることに意味があるのか、また、適切なのかについて、疑問に思われたかもしれません。

現在、新しい .NET Framework 4 は世界中の開発者に受け入れられているため、皆さんはこれまで以上に、移行を真剣に検討したいと感じていらっしゃるのではないでしょうか。マイクロソフトは移行作業を容易にする便利なツールを提供し、.NET Framework の最新の革新を活用できる新しいバージョンの ASP.NET アプリケーションへのアップグレードを可能にしていますので、移行を決断された方はご安心ください。この記事では特に、ASP.NET 1.1 ソリューションを Visual Studio 2010 (Professional、Premium、または Ultimate) に移行し、ソリューションが .NET Framework 2.0、3.0、3.5、または 4 を対象にできるようにすることで、ASP.NET 1.1 ソリューションをよみがえらせる方法について説明します。

移行する理由

単に既存の ASP.NET 1.1 サイトを維持することを目標としている方もいらっしゃるかもしれませんが、サポートや拡張性のオプションはしだいに少なくなっています。1.1 開発者の皆さんは、マイクロソフトが 2008 年 10 月 14 日に Visual Studio 2003 のメインストリーム サポートを終了し、Visual Studio 2003 や .NET Framework 1.1 のサービス パックをこれ以上発行しないと明言したことを懸念していらっしゃるでしょう (ただし、Visual Studio 2003 の延長サポートは 2013 年 10 月 8 日まで提供されます)。

皆さんは、.NET Framework 1.1 に対して実行できるコンポーネントや Visual Studio 2003 IDE を拡張するコンポーネントの提供やサポートを中止するサードパーティ ベンダーが増えていることに、非常に不安を感じていらっしゃるでしょう。実際、.NET Framework 1.1 Web アプリケーションや Visual Studio 2003 IDE は久しく使用されず、忘れ去られつつあるのではないでしょうか。

移行する理由は他にもたくさんあります。.NET Framework、C# プログラミング言語や Visual Basic .NET プログラミング言語、および Visual Studio IDE には非常に多くの機能強化が加えられているため、.NET 1.1 サイトを .NET 2.0 以上のバージョンに移行すると、最新のツールとテクノロジ、および一流の .NET 開発者が既に利用している言語やフレームワークのさまざまな新機能 (マスター ページ、AJAX、Windows Communication Foundation (WCF)、Silverlight、LINQ、部分クラス、ジェネリック、ラムダ式、匿名メソッドなど) を使用して、サイトを強化することができるようになります。一般に、ASP.NET アプリケーションの対象フレームワーク バージョンを上位のものにすればするほど、アプリケーションの可能性と威力は大きくなります。また、マイクロソフト自体だけでなく (この記事の執筆時点では、マイクロソフトは、2.0 以上のフレームワーク バージョンすべてに対してメインストリーム サポートを提供しています)、活発な開発者フォーラムやサードパーティ ツール ベンダーからも、強力なサポートが提供されます。最新のテクノロジのあらゆる側面を扱った書籍も広く提供されており、ビデオベースのコース、ブログ、ホワイト ペーパーなどのトレーニング オプションを提供するサイトも多数存在します。

最新かつ最先端の Visual Studio 2010 IDE 自体が移行の理由になりうると言ってもほとんど過言ではありません。Visual Studio 2010 IDE は Visual Studio 2003 IDE より何世代も先を行っており、IntelliTrace などの新機能をサポートしています。また、Visual Studio 2010 IDE は、プログラミングの生産性を新しいレベルにほぼ間違いなく引き上げるさまざまな強力なサードパーティ製プラグインを使用して、拡張することができます。さまざまな理由で古いバージョンの Visual Studio を使い続ける必要があるユーザーもまれにいるでしょうが、Visual Studio 2010 を使用すると、Visual Studio 2005 や Visual Studio 2008 の並列実行は事実上、不要になります。Visual Studio 2010 は 2.0 以上のフレームワークを対象にすることができるためです。ですが、Visual Studio 2005 や Visual Studio 2008 と同様、Visual Studio 2010 は 1.1 フレームワークを対象にすることができません。つまり、引き続き Visual Studio 2003 を実行するか、ASP.NET 1.1 プロジェクトをより新しいフレームワークに移行する必要があるということです。

最後に、1.1 フレームワークしか使用した経験がない開発者は、単純に、2.0 以上のフレームワークを使用した経験がある開発者と比べて需要が低くなります。開発者の職は競争率が高いので、可能な限りすべての強みを身に付けておくのが望ましいでしょう。より新しいフレームワーク機能をコードに活用すると、プロのソフトウェア開発者としての適格性と信頼性が向上します。

移行上の問題

ではなぜ、皆、Visual Studio 2003 以降の複数回にわたる Visual Studio と .NET Framework のメジャー リリース中に、ASP.NET 1.1 から、より上位のバージョンに移行しなかったのでしょうか。開発者は、Visual Studio 2005 によって提供された、ASP.NET 1.1 から ASP.NET 2.0 への移行オプションを実装する必要があったというのが 1 つの理由です。このオプションも悪くはなさそうですが、Visual Studio 2005 が最初に売り出されたとき、Visual Studio 2005 では ASP.NET 1.1 プロジェクトをはやりの Web プロジェクトに変換する必要がありました。つまり、ASP.NET 1.1 サイトの構築に使用されたアーキテクチャ自体を苦労して修正し厳しく回帰テストする必要があったということです。多くの開発者は、このプロセスはサイトをゼロから作成し直すのに等しく、乗り越えられないコスト上および技術上の課題を提起するものであると考えました。そのため、多くの場合、意思決定者は ASP.NET 1.1 サイトをそのままにしました。

この ASP.NET 1.1 から ASP.NET 2.0 への移行の課題をより正しく理解するには、すべての ASP.NET 1.1 Web プロジェクトが "プロジェクト主導" のファイル フォルダー構成を使用して整理されていることを理解することが重要です。このプロジェクトの種類は当初は "2003 Web プロジェクト モデル" と呼ばれており、現在は Web アプリケーション プロジェクト (WAP) として知られています。Visual Studio 2005 では、マイクロソフトは、.NET Framework 2.0 向けに設計された、"フォルダー主導" の新しいプロジェクトの種類を導入しました。このプロジェクトの種類は当初は "2005 Web プロジェクト モデル" と呼ばれており、現在は Web サイト プロジェクト (WSP) として知られています (ややこしいですね。簡単なこつをご紹介しましょう。"Visual Studio 2003 が Visual Studio 2005 より前なのと同様、WAP は WSP より前" というふうに、頭字語をアルファベット順に覚えるのです)。

ここでは、WAP と WSP について詳しくは説明しませんが、マイクロソフトは当初、移行された 1.1 Web アプリケーションすべてが、組み込みの変換ウィザードを通じて WSP になるようにするつもりだったとだけ言っておきましょう。懸念を持った開発者はすぐに抗議しました。元のプロジェクトの種類である WAP が提供していた技術上およびパフォーマンス上のメリットには、より新しいプロジェクトの種類である WSP では提供されないものがあったからです。その後すぐに、ASP.NET 開発者コミュニティで猛反発が起きました。開発者、管理者、および関係者が、マイクロソフトは ASP.NET 1.1 WAP から ASP.NET 2.0 WSP への移行オプションしか提供していないことを知り、また、この移行には時間とコストがかかる (少しでも複雑なサイトの場合、特に) ことがわかったためです。このような移行の間に発生する技術的な問題について詳しく説明するには、複数部構成の別個の記事が必要になってしまいます。詳細については、MSDN ライブラリの記事「Web プロジェクトの一般的な変換問題およびソリューション」(msdn.microsoft.com/library/aa479312) を参照してください。

さいわい、マイクロソフトは迅速に対応し、すぐに、Visual Studio 2005 SP1 で、改訂版の変換ウィザードを提供しました。今度の変換ウィザードでは、ASP.NET 1.1 WAP を ASP.NET 2.0 WAP に変換することができるようになりました。ですが、多くの開発者はこの移行オプションについて知らなかったため、このオプションを試しませんでした。Visual Studio 2010 の変換ウィザードでは、ASP.NET 1.1 WAP を ASP.NET 2.0 以上の WAP に変換することができ ("2.0 以上" とは、変換すると、2.0、3.0、3.5、または 4 を対象にすることができるようになるということです)、より古い Web アプリケーションの移行が依然として可能です (Visual Studio 2010 の変換ウィザードを使用して、ASP.NET 1.1 アプリケーションを WSP アプリケーションに変換することはできません。また、そのような変換が必要となる可能性は低いでしょう。このような変換を行うには、SP1 より前にリリースされた最初の Visual Studio 2005 の変換ウィザードを利用する必要があります)。

Visual Studio 2010 で新しいプロジェクトを開始するときはいつも、WAP または WSP のどちらを作成するか選択できます。マイクロソフトは、現在および今後すべての .NET Framework リリースで WAP と WSP のサポートを提供することを約束しています。

プロセス

Visual Studio 2010 を使用して ASP.NET 1.1 アプリケーションを移行する作業の大まかなステップは次のとおりです (各ステップの詳細については、後で説明します)。

  • 変換ウィザードを実行する
  • 対象のフレームワークとスタートアップ ページを設定する
  • コンパイルと修正を行う
  • ページやユーザー コントロールを部分クラスに変換する
  • コンパイルと修正を行う

変換ウィザードを実行する: 変換ウィザードを使用して、(今回の目標である、) 1.1 WAP から 2.0 以上の WAP への変換を行うには、Visual Studio 2010 セットアップ中に Visual Web Developer オプションをインストールする必要があります。Visual Studio 2010 セットアップ中に Visual Web Developer オプションをインストールしなかった場合、Visual Studio 2010 セットアップを再実行して、[Change or Remove Microsoft Visual Studio 2010] (Microsoft Visual Studio 2010 の変更または削除) オプションを使用し、[Add or Remove Features] (機能の追加または削除) を選択し、Visual Web Developer 機能のチェック ボックスがオンになっていることを確認して、Visual Web Developer オプションを追加する必要があります (図 1 参照)。

image: Ensure the Visual Web Developer Component Is Installed Before Launching the Conversion Wizard

図 1 変換ウィザードを起動する前に Visual Web Developer コンポーネントがインストールされていることを確認する

Visual Web Developer がインストールされていなくても、変換ウィザードは起動され、実行されます。その場合、ソリューション内のプロジェクトのうち、Web プロジェクト以外のものはすべて変換できます。また、Web プロジェクトを変換するには Visual Web Developer をインストールする必要があることを示すメッセージが表示されます。

変換作業に取り掛かる前に、アプリケーションがビルドおよび実行できることだけでなく、できる限りすっきりと整理されていることも確認することをお勧めします。そのため、次の作業を行います。

  1. アプリケーションから不要なものを取り除きます (使用されていないファイルや不要なファイルをすべて削除し、Web アプリケーションが絶対に必要なコンポーネントだけで構成されるようにします)。
  2. ソリューション内のすべてのプロジェクトをコンパイルでき、コンパイル時のエラーが発生しないことを確認します。
  3. ソリューションがまだソース管理下にない場合はソリューションをソース管理に追加することをお勧めしますが、リポジトリから排他的にチェックアウトされているファイルがないことを必ず確認してください。ソリューションをソース管理下に置くと、変換プロセスの完了後にウィザードによって加えられた特定の変更を調べることができます。
  4. ソース管理下にないファイルやフォルダーが読み取り専用になっていないことを確認します。これにより、ウィザードでは、そのようなファイルやフォルダーを必要に応じて更新できるようになります。
  5. バックアップを作成します。ソリューションを仮想マシン内で実行する場合、単純に仮想マシン全体をバックアップする (または仮想マシンのスナップショットを作成する) のが最善の方法です。または、アプリケーション全体 (すべての依存関係を含む) をバックアップします。依存関係についてよくわからない場合は、アプリケーションのソリューション (.sln) ファイルおよび個々のプロジェクト (.proj) ファイルを確認することをお勧めします (これらは、内容を目で確認できるテキスト ファイルです)。多くの ASP.NET ソリューションには、ネットワークの場所を参照するプロジェクト、または、Web ルートやアプリケーション フォルダー以外のフォルダーを参照するプロジェクトが含まれています。このような依存関係をバックアップしないと、バックアップ ファイルからアプリケーションを復元しようとした場合に非常に面倒なことになる可能性があります。移行プロセス全体ではアプリケーションのすべてのプロジェクトに変更が加えられるので、移行プロセスを開始する前にアプリケーションの依存関係を理解しておくと好都合です。また、いくつかの ASP.NET 1.1 アプリケーション間で共有されているプロジェクトを使用している場合、このようなソリューションを移行すると、Visual Studio 2003 ではそのソリューションを開けなくなります。チーム環境で作業している場合、共有のプロジェクトに変更を加えるとチーム メンバーのソリューションにも影響し、チーム メンバーのソリューションが、変換後のプロジェクトを参照することになる場合があります。したがって、プロジェクトを共有する場合は、プロジェクト間で共有するかチーム間で共有するかにかかわらず、プロジェクトのコピーを作成し、開発ワークステーション上にローカル コピーが存在するようにすることで、共有のプロジェクトを切り離す必要があります。(プロジェクトの切り離しなどを目的として) プロジェクトを移動すると、ソリューション ファイルが変更されるので、ソリューション ファイルで参照されているプロジェクトに変更を加える前にソリューション ファイルをバックアップし、その後、プロジェクトの依存関係が適切に切り離された後 (なおかつ変換ウィザードを実行する前) に再びバックアップを行うことを検討します。最後に、変換プロセスが完了した後で元のソリューション ファイルにエラーが見つかる場合があります。変換前のソリューションのバックアップが手元にあれば、変換ウィザードを再実行する前に変換前のソリューションでこうしたエラーを修正するのが簡単になります。
  6. 並列環境の構築を検討します。Visual Studio 2003 と Visual Studio 2010 は同じコンピューター上で並列実行することができるので、ASP.NET 1.1 サイトを ASP.NET 2.0 以上のサイトと同時に実行することができます。これにより、移行後の QA テストが容易になります。

ウィザードを起動するには、Visual Studio 2010 で [ファイル] メニューの [開く] をポイントし、[プロジェクト/ソリューション] をクリックして Visual Studio 2003 ソリューション ファイルを開きます。すぐに、Visual Studio 変換ウィザードの導入ダイアログが表示されます (図 2 参照)。[次へ] をクリックします。

image: The Visual Studio Conversion Wizard Introductory Dialog

図 2 Visual Studio 変換ウィザードの導入ダイアログ

変換ウィザードで処理中に問題が見つかったため、バックアップからソリューションを復元し、いくつか変更を加えてプロセスを最初から再開する必要がある場合があります。このステップにより、ソリューションのすべての依存関係を指定したバックアップ フォルダー内に配置する場合でも (つまり、適切に復元するには、こうしたバックアップされたフォルダーの元の配置を知っているという 100% の確信がなければならないということです)、バックアップを簡単に作成することができます (図 3 参照)。

image: The Conversion Wizard Gives You an Opportunity to Create a Backup Before Proceeding

図 3 変換ウィザードでは先に進む前にバックアップを作成できる

これを踏まえ、このステップでソリューションをバックアップするには、フォルダー パスを指定するだけです。指定すると、ソリューションのファイルが配置される Backup という子フォルダーが作成されます。ソリューション内のすべてのプロジェクト (元のソリューションのルート以外の場所に作成されたプロジェクトを含む) が、Backup フォルダーの下の対応するサブフォルダーにバックアップされます。したがって、バックアップを成功させるには、プロジェクト名がソリューション内で一意となるようにすることが重要です。[次へ] をクリックします。

ソース管理と読み取り/書き込みアクセス許可に関するアドバイスが記載された最後のダイアログ ボックスが表示されます (図 4 参照)。

image: The Conversion Wizard Advises You Before Letting You Continue

図 4 変換ウィザードでは先に進む前にアドバイスが提供される

バックアップを実行することを選択した場合は、要求したバックアップの種類、およびバックアップ ファイルの書き込み先が表示されます。変換されるソリューションの名前とそのソリューションの全プロジェクトが一覧表示されます。すべてが正しく問題ないと思われる場合は、[完了] をクリックします。

プロジェクトをチェックアウトできるように、ソース管理リポジトリ (Visual SourceSafe など) のログオン資格情報の入力を求められる場合があります。

ソリューションの各プロジェクトが変換されるのに合わせて進行状況バーが表示されます。ソリューション内のプロジェクトごとに処理が繰り返されるので、このプロセスには数分かかることがあります。

最初のステップが完了したこと、および Web アプリケーションを変換する必要があることを示すメッセージが変換ウィザードに表示されます (図 5 参照)。

image: The Conversion Wizard Lets You Know that You Will Need to Convert Your Web Project in Order to Complete the Migration

図 5 変換を完了するには Web プロジェクトを変換する必要があることが変換ウィザードによって通知される

続いて、最初のプロセスが完了したことを示すメッセージが表示されます (図 6 参照)。

image: The Conversion Wizard Alerts You When the Conversion Is Complete

図 6 変換が完了すると変換ウィザードによって通知される

その後、"変換レポート" テンプレートを使用して変換ログを確認することができます。このファイル (UpgradeLog.XML) は、ソリューションの .sln ファイルと同じフォルダーに配置されます。アップグレード ログでは、変換されたプロジェクト ファイルが示され、関連するエラーと警告メッセージがすべて表示されます。また、役立つコメントや、各プロジェクトの対象となるフレームワーク バージョンに関するコメントも含まれます。このレポートからの抜粋を 図 7 に示します。

image: The Conversion Log Shows Details About the Converted Web Application

図 7 変換ログでは変換された Web アプリケーションに関する詳細が示される

すべての警告とエラーを確認する必要があります。警告 (バックアップ パスの相対パスが変更されたなど) は一般に、比較的重要でない技術的な問題に関するもので、通常、さらなる処置を行わなくても、変換したソリューションを正常にコンパイルすることができます。しかし、エラー メッセージ (ファイル参照が見つからないなど) は一般に、変換したソリューションを正常にコンパイルするうえで妨げとなる問題に関するものなので、慎重に確認し対処する必要があります。エラーが多数あっても、変換ログでは、どのような処置を行えばよいかが明確に表現されます。また、通常、Visual Studio 2010 のヘルプ ファイルやさまざまな技術的 Web サイトからたくさんの役立つ追加情報を得ることができます。場合によっては、変換ログのエラーをメモして、変換後のソリューションではなく元の Visual Studio 2003 プロジェクト ファイル内で対処するのが最善の方法です (ここで、作成したバックアップが役に立ちます)。いつでも、変更を加えた Visual Studio 2003 ソリューションに対して変換ウィザードを再実行することができます。

すべての警告を確認しすべてのエラーを解決したら、変換ウィザードの最後の画面を閉じることができます。これで、変換ウィザードの処理が完了しました。ソリューション (.sln) ファイルとそのプロジェクト (.proj) ファイルは Visual Studio 2010 形式になりました。しかし、移行を完了するには、まだ他にも必要な作業が残っています。

対象のフレームワークとスタートアップ ページを設定する: 変換ウィザードが完了すると、Visual Studio 2003 Web プロジェクトは .NET Framework 4 に対して実行されるように構成され、一方、ソリューションの他のプロジェクトは .NET Framework 2.0 に対して実行されるように設定されています。さまざまなフレームワーク バージョンを組み合わせてもかまいませんが、Web ホスティング会社や組織のインフラストラクチャによる制約がない限り、ソリューションのすべてのプロジェクトで 1 つの対象のフレームワークを使用することをお勧めします (Visual Studio 2010 では、アクティブなプロジェクトで有効になっている対象のフレームワークに応じて、IDE の機能セットが調整されます。対象とするフレームワーク バージョンがプロジェクトによって異なる場合、プロジェクトを切り替えた際に IDE の動作に混乱することがあります。すべてのプロジェクトの対象のフレームワークを同じフレームワーク バージョンにすると、すべてのプロジェクトで IDE のインターフェイスが一貫性のあるものになります。また、一貫したフレームワークに基づいてプログラミングを行うことができます)。

変換されたプロジェクトの対象のフレームワークを変更する場合は、ソリューション エクスプローラーでプロジェクト ルートを右クリックし、[プロパティ] をクリックします。表示される構成ページ (図 8 参照) で、[アプリケーション] タブをクリックし、対象のフレームワークの値を 2.0 以上のいずれかのフレームワークに変更します。

image: Change the Target Framework for Any Project to 2.0, 3.0, 3.5 or 4

図 8 プロジェクトの対象のフレームワークを 2.0、3.0、3.5、または 4 に変更する

最後に、Web プロジェクトのスタート ページを設定します。これを行うには、ソリューション エクスプローラーで目的のページを探し出し、右クリックし、[スタート ページに設定] をクリックします。

コンパイルと修正を行う: ソリューション ファイルとプロジェクト ファイルが Visual Studio 2010 形式にアップグレードされたので、ASP.NET 2.0 以上の WAP をコンパイルする準備ができました。ソリューション内のすべてのプロジェクトを強制的にビルドするために、[ビルド] メニューの [ソリューションのリビルド] を使用して Visual Studio 2010 内でコンパイルすることをお勧めします。リビルドが完了したら、[エラー一覧] ウィンドウを表示して ([表示] メニューの [エラー一覧] をクリックすると表示されます)、ビルドに関する問題を確認することができます。[エラー一覧] ウィンドウには、エラー、警告、およびメッセージが表示されます ([エラー]、[警告]、[メッセージ] のいずれかのボタンをクリックして切り替えることで、この 3 つのどれをウィンドウに表示するかを指定することができます)。Visual Studio 2010 では通常、[エラー一覧] ウィンドウ内の項目を解決する方法に関する明確なガイダンスが提供されます。エラー/警告/メッセージのテキストを理解できない場合は、[エラー一覧] ウィンドウ内の該当行を選択し、F1 キーを押します。問題に関するより詳細な情報が記載されたヘルプ ウィンドウが表示されます (ローカル ヘルプをインストールしていない場合は、インターネットに接続してこの情報を確認することができます)。しかし、表示されるエラーのほとんどは、独自に記述したコードとの名前の競合を発生させる、フレームワークへの変更に関するものです。通常、参照を名前空間で完全修飾することで、こうしたエラーを解決することができます。また、表示される警告のほとんどは、古い形式の メンバーに関するものです。古い形式のメンバーは依然として使用できますが、より上位のバージョンの .NET Framework ではサポートされない可能性が高いことにご注意ください。現在は 2.0 フレームワークを対象にしており、古い形式のメンバーが存在するとします。その場合、3.x フレームワークまたは 4 フレームワークを対象にすることに決めると、そのメンバーを使用できなくなる可能性があります。

[エラー一覧] ウィンドウに表示されるこうした問題の解決に時間を割く覚悟をしておいてください。次のステップに進む前に、すべてのエラー、および (すべてとは言わないまでも) ほとんどの警告を解決する必要があります。

ページやユーザー コントロールを部分クラスに変換する: 次のステップには、"Web アプリケーションに変換" (以下 "CWA") コマンドの実行が含まれます。個々のページやユーザー コントロールに対してこのコマンドを実行して、どのような変更が加えられるかをつかむこともできますが、ソリューション全体に対して実行する方が手っ取り早く済みます。これを行うには、ソリューション エクスプローラーでソリューション ノードを右クリックし、[Web アプリケーションに変換] をクリックします。これにより、次のような処理が行われます。

  1. ページやユーザー コントロール用の新しい "デザイナー" ドキュメントが追加されることによって、部分クラスが実装されます。
  2. ページやユーザー コントロールの AutoEventWireup が設定されます。
  3. ページやユーザー コントロール上の各コントロールに、宣言型のイベント ハンドラーが追加されます。

ASP.NET 1.1 アプリケーションには、開発者が記述したコードと Web フォーム デザイナーによって生成されたコードの両方を含む分離コード モジュール (C# の場合は aspx.cs と ascx.cs、Visual Basic .NET の場合は aspx.vb と ascx.vb) があります。Visual Studio 2003 でページやユーザー コントロールを作成し、Web フォーム デザイナーを使用してそこにコントロールを追加すると、追加したコントロールを参照できるように、IDE によって protected インスタンス フィールドが分離コード モジュールに追加されます。CWA コマンドを実行すると、ページやユーザー コントロールごとにデザイナー ドキュメントが表示されるようになります (ソリューション エクスプローラーにこのファイルが表示されるのは、[すべてのファイルを表示] オプションが有効になっている場合のみです)。デザイナー ファイルの名前は、ページやユーザー コントロールと同じ名前に designer.cs (C#) または designer.vb (Visual Basic .NET) という拡張子が付いたものであることがわかります。

たとえば、MyPage.aspx という C# のページがある場合、MyPage.aspx.designer.cs という新しいドキュメントが表示されます。このデザイナー ドキュメントには、以前は分離コード モジュール内にあった protected インスタンス フィールドが含まれます。こうしたフィールドはデザイナー モジュールに移動されたので、独自に記述されたコードと混在しなくなります。これが可能なのは、デザイナー モジュールが部分クラスだからです。つまり、CWA コマンドでは、対応するページやユーザー コントロールの分離コードも部分クラスに変換するということです。

たとえば、Visual Studio 2003 プロジェクトの分離コード ドキュメントでは、C# および Visual Basic .NET のインスタンス フィールドは次のとおりです。

[VB]
Protected WithEvents MyButton As System.Web.UI.WebControls.Button

[C#]
protected System.Web.UI.WebControls.Button MyButton;
The CWA command moves each to a corresponding designer file:
[VB]
Protected WithEvents MyButton As Global.System.Web.UI.WebControls.Button

[C#]
protected global::System.Web.UI.WebControls.Button MyButton;

(global:: は、System を探すための名前空間検索がグローバル名前空間レベルで開始される必要があることを示すので、これを指定すると、フレームワークの System 名前空間が独自に作成された System 名前空間によって隠されてしまうことがなくなります。)

デザイナー ファイルは動的に作成され、いつでも再生成することができます。そのため、ソリューション エクスプローラーで目的のページやユーザー コントロールのノードを右クリックし、そのページやユーザー コントロールに対して CWA コマンドを再実行するだけで、designer.cs ドキュメントや designer.vb ドキュメントを問題なく削除して再生成する (ドキュメントがなくなった場合は復元する) ことができます。CWA コマンドでは、ページやユーザー コントロールの HTML マークアップをスキャンしてサーバー コントロールを探し、デザイナー部分クラス ファイル内に必要なインスタンス変数を生成します。続いて、独自の分離コード ファイル (aspx.cs、ascx.cs、aspx.vb、または ascx.vb) 内にまだ存在するインスタンス変数をすべて削除します。

部分クラスを使用すると、1 つのクラス、構造体、またはインターフェイスのソース コードを 1 つの名前空間内の複数の物理ファイルにまたがって記述することができます。コンパイラが後でこうした部分定義を統合して、それぞれの型の 1 つの定義にします。部分クラスは依然として、開発者が記述したコードを IDE によって生成されたコードから手際よく分離するために Visual Studio で使用されている事実上のメカニズムですが、開発者は分離コード モジュールでも部分クラスを活用します (特に、チーム環境で作業する場合)。

部分クラスは ASP.NET 2.0 以上のアプリケーション向けの標準なので、ASP.NET 1.1 クラスを分割して部分クラスにする必要があります。このステップを省略しても、ページやユーザー コントロールは機能し続けますが、ページ (.aspx) 上やユーザー コントロール (.ascx) 上のコントロールに変更を加えた場合、分離コード ファイル内のコントロール フィールドの宣言を手動で更新する必要があります。

CWA コマンドでは、AutoEventWireup の値、およびイベントを宣言し関連付ける方法も変更されます。その影響は重要なので、詳しく説明しましょう。AutoEventWireup は、Page オブジェクト イベント ハンドラーの関連付けが暗黙的に行われるか (True の場合)、それとも明示的に行われるか (False の場合) を指定するブール属性です。ページの場合、AutoEventWireup は @Page タグ内で設定されます。ユーザー コントロールの場合、AutoEventWireup は @Control タグ内で設定されます。CWA コマンドを実行すると、C# のページやユーザー コントロールでは AutoEventWireup が True に設定され、Visual Basic .NET のページやユーザー コントロールでは False に設定されます。

開発者によって好みは違います。また、ASP.NET 1.1 アプリケーション内の一部のページやユーザー コントロールで、AutoEventWireup が True または False に設定されたり、AutoEventWireup がまったく指定されなかったりする可能性は大いにあります (まったく指定されない場合は、web.config で指定されている値が既定値として使用されます。web.config で値が指定されていない場合は、machine.config で指定されている値が既定値として使用されます)。CWA コマンドを実行すると AutoEventWireup の値が変更される可能性があることにご注意ください。この変更によって、予期せぬ動作が発生することがあります (ページ イベントが 2 回実行されるなど)。これが最もよく起こるのは、ASP.NET 1.1 アプリケーション内で Page オブジェクト イベント用に独自の名前付け規則を作成した場合です。たとえば、次の C# コードについて考えてみましょう。このコードでは、Page_Load2 ハンドラーが Page.Load イベント デリゲートに関連付けられています。

this.Load += new System.EventHandler(this.Page_Load2);

AutoEventWireup が False の場合、イベントは予想どおり 1 回実行されます。これは、Page_Load という分離コード関数が存在する場合でも同様です。しかし、AutoEventWireup が True の場合は、両方のイベントが実行されます (ここで示した明示的な関連付けコードの分が 1 回、Page_Load イベント ハンドラーを Page.Load イベントにサブスクライブする暗黙的な関連付けコードの分が 1 回)。図 9 のコードについて考えてみましょう。

図 9 AutoEventWireup の動作をテストする

public partial class _Default : System.Web.UI.Page
{
  override protected void OnInit(EventArgs e)
  {
    InitializeComponent();
    base.OnInit(e);
  }

  private void InitializeComponent()
  {
    this.Load += new System.EventHandler(this.Page_Load2);
  }

  protected void Page_Load()
  {
    Response.Write("In Page_Load().<br />");
  }

  protected void Page_Load2(object sender, EventArgs e)
  {
    Response.Write("In Page_Load2().<br />");
  }
}

図 9 のコードを実行すると、次のような出力結果が得られます。

In Page_Load().
In Page_Load2().
Top of Form 1
Bottom of Form 1

AutoEventWireup が True に設定されている場合、Visual Basic .NET でも同じことが起こります。次のコードについて考えてみましょう。

Private Sub Page_Load(ByVal sender As System.Object, ByVal e As System.EventArgs)

  Response.Write("In Page_Load.<br />")

End Sub

Private Sub Page_Load2(ByVal sender As System.Object, _
  ByVal e As System.EventArgs) Handles MyBase.Load

  Response.Write("In Page_Load2.<br />")

End Sub

AutoEventWireup が True の場合、両方のイベント ハンドラーが実行され、ページには次のような内容が表示されます。

In Page_Load2.
  In Page_Load.

2 つのイベント ハンドラーが実行されるだけでなく、(他のすべてのマルチキャスト デリゲートと同様、) 2 つの実行順序が予想と異なる場合があることがわかります。最後に、AutoEventWireup が True の場合、適切な関数名 (Page_Load など) の付いたページ イベント ハンドラーは、引数を指定して定義しても指定せずに定義しても実行されることにご注目ください。以下に例を示します。

protected void Page_Load()
  {
    Response.Write("In Page_Load().<br />");
  }

上記のコードは次のコードと同じです。

protected void Page_Load(object sender, EventArgs e)
  {
    Response.Write("In Page_Load().<br />");
  }

両方が存在する場合は、引数が指定されている方だけが実行されます。これも、トラブルシューティングを行う際に考慮する必要がある問題の 1 つです。したがって、一般に、ページやユーザー コントロールをテストする際は注意が必要です。特に、CWA コマンドによって AutoEventWireup の設定が変更された場合はご注意ください。

最後に、CWA コマンドを実行すると、コントロール イベントを関連付ける明示的な C# コードや Visual Basic .NET コードは削除され、代わりに、ページやユーザー コントロールのマークアップ内にある宣言型のイベント属性が使用されます。たとえば、ASP.NET 1.1 では、ボタンのクリック イベントは一般に、分離コード内にイベント ハンドラーを持ちます。たとえば、次のようなイベント ハンドラーが考えられます。

this.MyButton.Click += new System.EventHandler(this.MyButton_Click);

CWA コマンドを実行すると、このコードは削除され、代わりに、次のようにサーバー コントロール宣言に OnClick 属性が追加されます。

<asp:Button ID="MyButton" runat="server" Text="MyButton" onclick="MyButton" />

Visual Basic .NET では、宣言型のイベントは追加されません。代わりに、分離コードに Handles キーワードが追加されます。したがって、Button コントロールのマークアップは次のようになります。

<asp:Button ID="MyButton" runat="server" Text="Button" />

一方、分離コードでは、次のようにコントロールをハンドラーに関連付けます。

Protected Sub MyButton_Click(
  ByVal sender As Object, ByVal e As EventArgs) _
Handles MyButton.Click

End Sub

このような宣言型イベント ハンドラー コンストラクターのイベント デリゲートはコンパイル時に作成されます。

コンパイルと修正を行う: これで、移行は完了しました。ソリューションをリビルドし、コンパイラによって表示されるエラーや警告が残っている場合はそれに対処することをお勧めします。Web プロジェクトを正常にビルドしたり、移行した Web サイトをブラウザーで表示したりするには、コンパイル エラーを解決する必要があります。コンパイル警告にも対処する必要がありますが、コンパイル警告は重大とは見なされず、未解決でも Web アプリケーションを使用することができます。最後に、すべてのコンパイラ メッセージに注目します。コンパイラ メッセージでは一般に、時間が許すのであれば実装を検討するとよい改善についての役立つアドバイスが提供されるためです。エラーと警告への対処に加えて、移行したコードの回帰テストと QA テストを行うことも重要です。特に、イベントが予想どおりに実行されることを注意深く確認する必要があります。

移行後の考慮事項

これで、ASP.NET プロジェクトはより新しいフレームワークを対象とするようになり、より新しいバージョンの IDE の下で実行されるようになったので、知っておく必要がある追加の問題がいくつかあります。

ASP.NET 1.1 ソリューションを 32 ビット OS から 64 ビット OS に移行する場合、IIS 6.0 およびそれ以降では 32 ビットと 64 ビットの両方の動作モードがサポートされていることを理解する必要があります。ASP.NET 1.1 は 32 ビット モードでのみ動作するので、変換後の ASP.NET アプリケーションは依然として 32 ビットに依存する場合があり (COM や P/Invoke の呼び出しなど)、移行後は適切に機能しなくなる可能性があります。これを修正するには、アプリケーションの [Application Pool] (アプリケーション プール) の [Advanced Settings] (詳細設定) にアクセスし、[Enable 32-bit Applications] (32 ビット アプリケーションの有効化) の値を True に設定します。

Visual Studio 2010 は、Web ページが XHTML に準拠していることを想定しています。ASP.NET 1.1 から移行したページは XHTML に準拠していない可能性が高いため、ほとんどのページで XHTML 検証警告が表示されるでしょう (こうした警告を確認するには、ページをソース モードまたはデザイン モードで表示し、[表示] メニューの [エラー一覧] をクリックします)。このような警告が表示されてもページを実行することはできますが、このような警告は、新しいバージョンのブラウザーでページが適切にレンダリングされない場合があることを示します。時間が許すのであれば、XHTML に準拠するようにページやユーザー コントロールを更新することをお勧めします。XHTML に準拠するよう更新すると、ページやユーザー コントロールは新しいバージョンのブラウザーで適切にレンダリングされるようになります。Web アプリケーションが古いバージョンのブラウザーを明確にターゲットとしている場合、または、現時点ではマークアップ検証エラーに煩わされたくない場合は、マークアップの検証方法を変更することができます。これを行うには、[ツール] メニューの [オプション] をクリックし、[テキスト エディター] ノードに移動し、ターゲットを Internet Explorer 6 に変更します (図 10 参照)。このアプローチは、Internet Explorer 6 をターゲットとする必要がある開発者にのみ適しています。アプリケーションが企業イントラネット アプリケーションの場合などは、これに該当する可能性があります。これにより、実質上、レンダリング検証レベルが、Visual Studio 2003 で使用していた可能性の高いレベルと似たレベルに設定されます。

image: You Can Suppress XHTML Validation Errors by Changing the HTML Validation Target to Internet Explorer 6

図 10 HTML 検証のターゲットを Internet Explorer 6 に変更して XHTML 検証エラーが表示されないようにすることができる

Internet Explorer 以外のブラウザーまたは Version 6 よりも上のバージョンの Internet Explorer で適切に表示される必要があるアプリケーションの場合、XHTML マークアップ エラーを引き続き HTML エディターに表示し、.NET Framework 4 の controlRenderingCompatibilityVersion という新しい構成設定を利用する必要があります。以下に示すように、この設定は、Web.config の system.web セクションでプロパティとして使用することができます。

<system.web>
  <pages controlRenderingCompatibilityVersion="4.0"/>
</system.web>

Web.config 内で controlRenderingCompatibilityVersion が設定されていない場合、実行中の ASP.NET のバージョンが既定値として使用されます。しかし、controlRenderingCompatibilityVersion の値を指定する場合は、"3.5" または "4.0" に設定することができます (変換ウィザードではこの値が "3.5" に設定されます。その場合、ページは ASP.NET 3.5 の場合と同じようにレンダリングされます)。この設定により、.aspx ファイル内で指定されたマークアップが、最終的にどのようにブラウザーにレンダリングされるかが決まります。Visual Studio 2010 オンライン ヘルプから例を挙げてみましょう。controlRenderingCompatibilityVersion が "3.5" に設定されている場合、IsEnabled プロパティが false に設定された、サーバー側の ASP.NET Label コントロールは、"disabled" 属性が "disabled" に設定された HTML span 要素をレンダリングします。controlRenderingCompatibilityVersion が "4.0" に設定されている場合、span 要素には、CSS クラスを参照する "class" 属性が含まれます。

"4.0" という設定を使用すると、新しいバージョンの XHTML マークアップが生成されるため、ASP.NET 1.1 バージョンのページで適切に機能していたクライアント スクリプトや CSS ルールが機能しなくなり、レンダリングされるコンテンツの動作や外観に影響を与える場合があることにご注意ください。したがって、有効な XHTML が生成されると完全に確信できるまでは、controlRenderingCompatibilityVersion を "3.5" に設定することをお勧めします。また、この "3.5" という設定を使用する場合、xhtmlConformance について知っておく必要があります。xhtmlConformance は controlRenderingCompatibilityVersion が "3.5" に設定されている場合にのみ適用され、設定可能な値は "Legacy"、"Strict"、または "Transitional" です (既定値は "Transitional" です)。"Strict" の場合、XHTML 1.0 Strict マークアップがレンダリングされます。"Transitional" の場合、XHTML 1.0 Transitional マークアップがレンダリングされます。"Legacy" の場合、ASP.NET 1.1 の場合と同じように HTML がレンダリングされます (ただし、必ずしもまったく同じとは限りません)。

<system.web>
  <pages controlRenderingCompatibilityVersion="4.0"/>
  <xhtmlConformance mode="Transitional"/>
</system.web>

私の経験では、"Legacy" モードを使用すると ASP.NET AJAX の UpdatePanel が適切に機能しなくなる場合があるので、"Legacy" モードの使用は避けるべきです。また、controlRenderingCompatibilityVersion の値によって変化するのは ASP.NET コントロールのレンダリング方法だけであり、Web ページの DOCTYPE は変化しないことにもご注意ください。したがって、ページを適切にレンダリングするための主な要因は、controlRenderingCompatibilityVersion、xhtmlConformance、DOCTYPE の値の組み合わせ、およびターゲット ブラウザーの種類と使用されるバージョンです。

検討が必要な問題がもう 1 つあります。新たに移行したサイトの実行場所となる仮想ディレクトリの変更が必要な場合があります (特に、このサイトを ASP.NET 1.1 バージョンと並列実行する予定の場合、これが必要になります)。これを行うには、ソリューション エクスプローラーで Web プロジェクトを右クリックし、[プロパティ] をクリックし、[Web] タブにアクセスします。[サーバー] の下に、[IIS Web サーバーの使用] というオプションがあります。このオプションが選択されていることを確認し、プロジェクトの URL (http://localhost/mysitemigrated など) を指定します。仮想ディレクトリが存在しない場合は [仮想ディレクトリの作成] をクリックします。

ASP.NET 1.1 アプリケーションは、Windows ASPNET ユーザーを使用して、仮想ルートの下にあるファイルやフォルダーに対する特権を割り当てます。ASP.NET 2.0 以上では、NETWORK SERVICE ユーザーが使用されます。たとえば、ASP.NET が特定のファイルやフォルダーへの書き込みアクセス権限を持つことをアプリケーションが要求する場合、NETWORK SERVICE ユーザーにこのような権限を与えることが重要です。どのユーザーにこのアクセス権を与える必要があるのか確信が持てない場合は、ASP.NET アプリケーションの実行中に Envionment.UserName プロパティの値を調べることで、そのユーザー名を確認することができます。

サードパーティ製のアドオンや依存関係を使用する場合は、(バイナリとして使用するかソースとして使用するかにかかわらず) ベンダーに問い合わせて、最新のバージョンを使用していることを確認します。たとえば、人気のログ プログラム NLog では、1.1 と 2.0 のライブラリ ビルドが提供されています。1.1 のコードを自分で移行しなくて済むように、2.0 ビルドを入手してください。また、ベンダーは、Visual Studio IDE 向けに設計された生産性アドオンの更新プログラムを提供します。アップグレードして、新しい Visual Studio 2010 IDE 用にこうした製品の最新バージョンを入手するようにしてください。

ASP.NET 1.1 Web アプリケーションを移行したら、2 つのメリットにすぐ気付かれるでしょう。第 1 に、サイトを強化するために Front Page Server Extensions (FPSE) を使用する必要はなくなります (使用を継続したい場合は別ですが)。第 2 に、Visual Studio 2010 は独自の組み込みの ASP.NET 開発サーバーを提供するので、開発用コンピューターに IIS をインストールしておく必要はなくなります。また、(QA やデバッグなどのために) Visual Studio 2003 ASP.NET アプリケーションを引き続き Visual Studio 2010 ASP.NET アプリケーションと並列で実行することはできますが、変換された Visual Studio 2010 ASP.NET アプリケーションを実行するには、Visual Studio 2003 は必要なく、また、.NET Framework 1.1 にアクセスする必要もありません。

C# 開発者の方は、デザイナー モードで表示したときに、ページやユーザー コントロールのイベントが [プロパティ] ウィンドウに黄色のいなずまアイコンとして表示されなくなったことに気付かれるかもしれません。Visual Studio 2003 のようにこうしたイベントを表示/作成するには、ソリューション エクスプローラーでページ (.aspx) またはユーザー コントロール (.ascx) を右クリックし、[コンポーネント デザイナー表示] をクリックする必要があります。ここで、なじみのあるイベント一覧を含む [プロパティ] ウィンドウが表示されます。一覧内の任意のイベントをダブルクリックして、イベント プロシージャやデリゲートの関連付けコードを作成することができます (作成したコードは、InitializeComponent 関数に追加されます)。

サイトをホストするときが来たら、どの CLR が必要かを理解している必要があります。.NET Framework 3.0 および 3.5 を使用する場合は、CLR 2.0 に対して実行することになります。.NET Framework 4 を使用する場合は、CLR 4.0 に対して実行することになります。ホスティング会社は、ASP.NET 4.0 ソリューションをホストするには、CLR 4.0 をサポートしている必要があります。

この記事が、Visual Studio 2003 ASP.NET アプリケーションを Visual Studio 2010 に移行するうえでお役に立てばさいわいです。移行すると、まったく新しいプログラミング テクノロジの世界を自由に利用できるようになります。この技術的決断は比較的苦労を伴わず、後悔することもないでしょう。

Jonathan Waldman は、『PC Magazine』の記事の執筆経験を持つ上級マイクロソフト認定プロフェッショナルです。.NET Framework テクノロジを活用してデスクトップと Web のためのカスタマイズされたソフトウェア ソリューションを熱心に作成しています。連絡先は jonathan.waldman@live.com (英語のみ) です。

この記事のレビューに協力してくれた技術スタッフの Scott Hanselman に心より感謝いたします。