次の方法で共有

Visual Studio 2005 の機能強化

  • [アーティクル]

作成者: Microsoft

Visual Studio 2005 では、Web アプリケーション開発者向けに、Web プロジェクトに対する機能の改善と強化を数多く提供します。

Visual Studio 2005 では、Web アプリケーション開発者向けに、Web プロジェクトに対する機能の改善と強化を数多く提供します。 Visual Studio .NET 2002 や 2003 と同等の強力な機能を備えてはいるものの、Web プロジェクトを扱う場合の処理においては、改善を要する多くの指摘がありました。 Visual Studio 2005 では、これらの指摘に対処するよう、多数の新機能が追加されています。 Visual Studio .NET 2003 で Web アプリケーションのコンパイルの処理に使用される方法のほうが望ましい場合は、「Web アプリケーション プロジェクト」を参照してください。

このモジュールでは、Web プロジェクトの作成、管理、開発の機能強化について説明します。 この後のモジュールでは、Web プロジェクトのビルドとデプロイに関する機能強化について説明します。

FrontPage Server Extensions

Visual Studio .NET 2002 および 2003 では、Web プロジェクトを作成したりビルドしたりするには、FrontPage Server Extensions が必要でした。 開発者には、2 つの異なるアクセス モード (FrontPage Server Extensions またはファイル アクセス モード) の選択肢がありましたが、これらはいずれも、IIS でのアプリケーション ルートの設定などのタスクを実行するのに FrontPage Server Extensions を使用していました。

Visual Studio 2005 では、ローカル プロジェクトにおいては FrontPage Server Extensions に依存しないようになります。 Visual Studio 2005 では、FrontPage Server Extensions を使用するのではなく、IIS メタベースに直接アクセスするようになりました。 Visual Studio 2005 では FTP のサポートも追加されています。これにより、リモート プロジェクトへのアクセスに FrontPage Server Extensions が不要となります。

プロジェクトで FrontPage Server Extensions を使用する開発者は、このオプションを引き続き使用できます。 ただし、ASP.NET 開発者コミュニティからの強力なフィードバックに基づいて、これは要件とはなっていません。

Note

FrontPage Server Extensions は、リモート プロジェクトを作成したり開いたりするために、引き続き必要です。

ASP.NET 開発サーバーの概要

Visual Studio 2005 には、ASP.NET 開発サーバーという新しい Web サーバーが付属しています。 (この Web サーバーは、以前は Cassini と呼れていたものです。)

ASP.NET 開発サーバーにはいくつかの利点があります。

  • 管理者でないユーザーが Web サーバーに対して開発、デバッグが可能になりました。
  • ASP.NET 開発サーバーでは、仮想ディレクトリをファイル システム内の任意の場所に動的にマップします。これにより、プロジェクトの場所に柔軟性がもたらされます。
  • 既に IIS を使用している Windows XP Professional のユーザーは、IIS の既定の Web サイトのファイルまたはフォルダー構造に影響を与えない新しい Web アプリケーションを作成できるようになりました。

ASP.NET 開発サーバーを利用するために特別な構成は必要ありません。 ファイル システムにホストされている Web プロジェクトがデバッグされたり参照されたりすると、Visual Studio 2005 は、要求を処理するランダムなポートで、ASP.NET 開発サーバーのインスタンスを自動的に開始します。

ASP.NET 開発サーバーについては、このモジュールの後半で詳細に説明します。

ファイル管理の機能改善

Visual Studio 2002 および 2003 では、プロジェクト ファイル (VB.NET の場合は .vbproj、C# の場合は .csproj) には Web アプリケーション内のすべてのファイルに関する情報が格納されていました。 ソリューション エクスプローラー表示は、プロジェクト ファイル内のファイル情報に基づいています。 このため、外部エディターが使用された場合、ソリューション エクスプローラーで表示される情報が正確でない場合があります。 Visual Studio 2002 および 2003 では、ファイルの変更が上書きされたり、最新バージョンのファイルが表示されなくなったりする場合がありました。

Visual Studio 2005 ではプロジェクト ファイルを使用しません。 代わりに、ファイルとフォルダーの情報がディスクから直接読み取られ、その結果、プロジェクト内のファイルが正確に表示されます。 Visual Studio 2002 および 2003 の References フォルダーは Web アプリケーション内の実際のフォルダーを表していないため、Visual Studio 2005 でも、References フォルダーがソリューション エクスプローラーに表示されません。 Visual Studio 2005 でプロジェクトの参照にアクセスするには、プロジェクトの Property ページを使用します。

Web プロジェクトの作成

Web 開発者向けに、Visual Studio 2005 でプロジェクトを作成するための新しいオプションが多数用意されています。 ファイル システム内の任意の場所に Web サイトを作成し、新しい ASP.NET 開発サーバーを使用してデバッグしたり参照したりできるようになりました。 開発者は、FTP を使用して新しい Web サイトを作成することもできます。

Visual Studio 2005 で Web プロジェクトを作成するビデオ チュートリアルを表示するには、ここをクリックしてください。

全画面表示でビデオを開く

ファイル システム プロジェクト

ビデオ チュートリアルの説明にあったように、ローカル コンピューター上に、またはリモートの場所にファイル共有を介して、ファイル システム上に Web サイトを作成する選択が可能です。 ファイル システム上に作成された Web サイトは、ASP.NET 開発サーバーを使用して参照したりデバッグしたりすることができます。

Note

ASP.NET 開発サーバーでは、お客様にとって混乱しかねない点があります。 WEB プロジェクトが IIS のディレクトリ構造 (c:/inetpub/wwwroot など) のファイル システム上に作成された場合でも、Visual Studio 2005 内から起動すると、ASP.NET 開発サーバーを介して Web サイトが参照されます。 そのため、IIS の構成 (認証方法など) は適用対象外です。

既定の Web プロジェクトでは、Default.aspx ページ、default.cs ファイル、App/_Data フォルダーのみが含まれるため、オーバーヘッドも大幅に削減されます。 web.config フォルダーと特別なフォルダー (app/_code など) が、必要に応じて追加されます。 Web プロジェクトには、必要なファイルとフォルダーのみが含まれます。

HTTP プロジェクト

HTTP プロジェクトには、ローカルの IIS Web サイト上に作成されるプロジェクトの場合と、リモート Web サイト上に作成されるプロジェクトの場合があります。 既定のプロジェクトの場所は http://localhost です。 [参照] ボタンをクリックすると、[ローカル IIS] と [リモート サイト] の 2 つの HTTP オプションがあります。 これら 2 つのオプションの主要な違いは、[場所の選択] ダイアログに Web サイト情報を表示する方法と、ファイルを Web サーバーにコピーする方法です。

[ローカル IIS] オプションでは、ローカル コンピューター上のメタベースからサイト情報を読み取り、ファイルはファイル システムを使用してコピーされます。 [リモート サイト] オプションでは FrontPage Server Extensions が使用され、サイト情報とファイルは HTTP および FrontPage Server Extensions RPC 呼び出しを使用してコピーされます。

Note

vs###/_tmp.htm ファイルと get/_aspx/_ver.aspx は、バージョン情報の判定に使用されなくなりました。

既定の HTTP オプションは [ローカル IIS] です。 このオプションでは、IIS メタベースを読み取って、使用可能なサイトとコンテンツを作成する場所を決定します。 ツリー ビューで別のフォルダーまたは仮想ディレクトリを選択することができます。 新しい仮想ディレクトリを作成したり、フォルダーをアプリケーションとしてマークしたり、既存の仮想ディレクトリをこのダイアログ ボックスから削除したりすることもできます。

The Choose Location Dialog

図 1: [場所の選択] ダイアログ

以前のバージョンの Visual Studio とは異なり、[Secure Sockets Layer を使用する] チェック ボックスをオンにして、SSL 証明書が参照している URL と一致しない場合は、続行するかどうかを確認する [セキュリティ アラート] ダイアログが表示されます。 Visual Studio .NET 2003 を使用すると、証明書が一致するものでない場合、プロジェクトの作成は失敗していました。

Security Alert Regarding SSL Certificate

図 2: SSL 証明書に関するセキュリティ アラート

ホスト ヘッダーに関する注意事項

特定の IP にバインドされたサイトで Web アプリケーションを作成している場合は、ホスト ヘッダーが構成されていることを確認する必要があります。 そうしないと、Visual Studio によってサイトが http://localhost に作成されますが、サイトが IDE 内から参照されたりデバッグされる場合に、IP アドレスが正しく解決されません。

[リモート サイト] オプションを選択すると、ダイアログが変化し、新しい Web サイトの宛先 URL を入力できるようになります。 この URL は、FrontPage Server Extensions が有効になっているサーバー上にある必要があります。 FrontPage Server Extensions を使用してローカル Web サーバーを操作する場合は、[リモート サイト] オプションを使用してローカル URL を指定できます。

Creating a Web Site on a Remote Server

図 3: リモート サーバー上への Web サイトの作成

SSL を使用してリモート サイト上にアプリケーションを作成する際に、SSL 証明書が一致しない場合は、確認ダイアログは、[ローカル IIS] オプションを使用するときに表示されるダイアログと若干異なります。

The Remote Site Security Alert

図 4: [リモート サイト] セキュリティアラート

FTP

Visual Studio 2005 では、FTP 経由で Web サイトを作成するオプションが導入されています。 このオプションを使用すると、IDE によってユーザーの一時フォルダーにファイルがローカルに作成され、FTP を使用してファイルが FTP の場所に移動されます。

Note

一時フォルダーの場所は c:/Documents と Settings/<User>/Local Settings/Temp/VWDWebCache/<Server>/_<application name> です。

FTP オプションを使用すると、[場所の選択] ダイアログが表示されます。 次に示すように、必要な FTP 接続情報をこのダイアログに入力します。

The Choose Location Dialog for FTP

図 5: FTP 用の [場所の選択] ダイアログ

ラボ: FTP サイトをセットアップし、プロジェクトを作成する

次の手順では、ユーザーが、自身のみが FTP 経由でアップロードできる場所があるように、FTP サイトを構成します。

FTP サービスをインストールする

  1. [プログラムの追加と削除] を開き [Windows コンポーネントの追加と削除] を選択します。
  2. [インターネット インフォメーション サービス] (Windows 2003 のアプリケーション サーバー) を選択し、[詳細] をクリックします。
  3. [ファイル転送プロトコル (FTP) サービス] をオンにし、[OK] をクリックします。
  4. [次へ] をクリックして FTP サービスをインストールします。

コンテンツ用の新しいフォルダーを作成する

  1. Windows エクスプローラーで、c:/inetpub/wwwroot 内に User1 という名前の新しいフォルダーを作成します。

フォルダーと、フォルダーについてのアクセス許可を構成します。

  1. [管理ツール] から [インターネット インフォメーション サービス スナップイン] を開きます。 これで、コンピューター名ノードの下に FTP サイト フォルダーが作成されます。
  2. [FTP サイト] を展開します。
  3. 既定の FTP サイトを右クリックし、[新規]、[仮想ディレクトリ] の順に選択し、[次へ] をクリックします。
  4. 仮想ディレクトリ名として「User1」と入力し、[次へ] をクリックします。
  5. パスに「c:/inetpub/wwwroot/User1」と入力し、[次へ] をクリックします。
  6. [次へ] をクリックし、[完了] をクリックして、ウィザードを完了します。
  7. [既定の FTP サイト] で User1 仮想ディレクトリを右クリックし、[プロパティ] を選択します。
  8. [書き込み] チェックボックスをオンにし、[OK] をクリックしてダイアログを閉じます。
  9. [既定の FTP サイト] を右クリックし、[プロパティ] を選択します。
  10. [セキュリティ アカウント] タブで、[匿名接続を許可する] のチェックをオフにします。
  11. 続行を確認するダイアログボックスで[はい] をクリックします。
  12. [OK] をクリックしてダイアログ ボックスを閉じます。
  13. [Web サイト] ノードの下にある [既定の Web サイト] を展開します。
  14. User1 ディレクトリを右クリックし、[プロパティ] を選択します。
  15. [アプリケーション 設定] セクションで [作成] をクリックして、フォルダーをアプリケーションとしてマークします。
  16. [OK] をクリックしてダイアログ ボックスを閉じます。
  17. [インターネット インフォメーション サービス スナップイン] を閉じます。

Web プロジェクトを作成する

  1. Visual Studio 2005 を開きます。
  2. [ファイル] メニューで、[新しい Web サイト] を選択します。
  3. [場所] ドロップダウンで [FTP] を選択します。
  4. [参照] をクリックします。
  5. [サーバー]テキストボックスに「localhost」と入力します。
  6. [ディレクトリ] テキストボックスに「User1」と入力します。
  7. 開く をクリックします。 FTP の場所が [新しい Web サイト] ダイアログに入力されます。
  8. OK をクリックします。
  9. [FTP ログオン] ダイアログで [匿名ログオン] のチェックをオフにし、資格情報を入力して [OK] をクリックします。
  10. プロジェクトの URL を指定します。 (プロジェクトの URL とはソリューション エクスプローラーに表示されるものです)。
  11. [ビルド] メニューの [Web サイトのビルド] または [ソリューションのビルド] を選択します。
  12. ソリューション エクスプローラーで Default.aspx を右クリックし、[ブラウザーで表示] を選択します。
  13. [Web サイトの URL が必要です] ダイアログで、URL に http://localhost/user1 を入力し、[OK] をクリックします。

Note

型 /_Default を読み込めないことを示すエラーが発生する場合は、Web サイトでASP.NET 2.0 (以前のバージョンではなく) を実行していることを確認してください。 これは、インターネット インフォメーション サービスの [ASP.NET] タブから確認できます。

Web プロジェクトを開く

Web プロジェクトを開くのは、プロジェクトの作成と似ています。 次のセクションでは、IDE 内で作業しているときに注意が必要な領域について説明します。 また、HTTP と FTP を使用した Web プロジェクトでの作業についても説明します。

Web プロジェクトを開くには、[ファイル] メニューから [Web サイトを開く] を選択します。 前に説明した内容と同様に [場所の選択] ダイアログが表示され、[ファイル システム]、[ローカル IIS]、[FTP]、[リモート サイト] の 4 つのオプションを使用できます。

ファイル システム

このモジュールで既に示したように、Visual Studio ではプロジェクト ファイルを使用しなくなりました。 そのため、ファイル システムから Web サイトを開く場合は、選択したフォルダーが Visual Studio で最初に Web プロジェクトとして作成されたものではなくても、実際には任意のフォルダーを選択できます。 たとえば、[マイ ドキュメント] フォルダーを Web サイトとして開くことを選択すると、問題なく Visual Studio で開かれ、ファイルが次に示すように表示されます。

My Documents Opened As a Web Site

図 6: Web サイトとして開かれた "マイ ドキュメント"

Visual Studio では必要な場合にのみ追加のファイルとフォルダーが作成されるため、開いている場所に追加のファイルやフォルダーは追加されません。 このアーキテクチャの副作用は、ファイル システム上で Web サイトを入れ子にできないようになることです。 たとえば、次のようなディレクトリ構造を考えてみます。

C:/MyWebSite にある Web プロジェクト

C:/MyWebSite/Nested にある別の Web プロジェクト

c:/MyWebSite にある Web サイトを開くと、入れ子になったフォルダーはそのアプリケーションのサブフォルダーとして表示されます。

HTTP

HTTP 経由で Web サイトを開くと、IIS メタベース (ローカル IIS の場合) または FrontPage Server Extensions (リモート サイトの場合) から設定が読み取られます。入れ子になった Web アプリケーションがある場合、それらはアプリケーションとして識別するアイコンと共に表示されます。 FrontPage での Web アプリケーションの作業に慣れている場合、Visual Studio 2005 の動作は似ています。

Visual Studio では、IDE 内で現在開かれているアプリケーションの下に入れ子になっているアプリケーションのアイコンが表示されますが、展開してコンテンツを表示することはできません。 ただし、ダブルクリックすれば開くことができます。 これを行うと、Web アプリケーションを開く (現在開いているソリューションを置き換える) か、Web アプリケーションを現在のソリューションに追加するかを求めるダイアログが表示されます。

Double-clicking a nested application icon presents you with this dialog

図 7: 入れ子になったアプリケーション アイコンをダブルクリックすると、このダイアログが表示される

FTP サイト

FTP 経由でサイトを開くと、ファイルはすべてローカルの一時フォルダーにコピーされます。 ローカル ストレージの場所の完全なパスは、プロジェクトの [プロパティ] ウィンドウに表示され、次の形式で作成されます。

C:/Documents and Settings/<User>/Local Settings/Temp/VWDWebCache/<Server>/_<application name>

FTP を使用する場合、Visual Studio では、プロジェクトのベース URL を指定する必要があります。これにより、次に示すように表示できます。 ベース URL を指定しない場合、Visual Studio では、Web サイト内のページを初めて表示しようとするときに要求されます。

Specifying a Base URL for FTP Sites

図 8: FTP サイトのベース URL の指定

コンパイルの機能強化

Visual Studio 2005 での Web アプリケーションに関する作業は、以前のバージョンよりも著しく高速です。 その大きな要因は、コンパイル アーキテクチャの変更です。

Visual Studio 2002 および 2003 では、Web アプリケーションは /bin フォルダーに存在する 1 つのプライマリ アセンブリにコンパイルされました。 Visual Studio 2005 では、App/_Code フォルダーが追加されました。 クラスと他の UI 以外のコードは、App/_Code フォルダーに追加されます。 Visual Studio でプロジェクトのビルドを行うと、App/_Code フォルダー内のすべてのファイルが 1 つの App/_Code.dll ファイルにコンパイルされます。 この変更の結果、後続のビルドは以前のバージョンよりもはるかに高速になります。

Note

MSBuild コマンド ライン ユーティリティを使用して、ASP.NET Web アプリケーションをビルドすることもできます。 このツールについては、モジュール 9 で説明します。

もう 1 つのコンパイルの機能強化は、[ビルド] メニューの新しい [ビルド ページ] オプションです。 この機能により、開発者は現在のページのみをリビルドするだけで、変更をより迅速にコンパイルできるようになります。もちろん、これには依存関係も含まれます。 C# では IntelliSense などの更新を目的とするバックグラウンド コンパイルが提供されないため、この機能の利点は非常に大きくなります。単一のページをリビルドするだけで IntelliSense を迅速に更新できるためです。

プロジェクトの Build プロパティを使用すると、スタートアップ ページが実行される前に発生するビルドの種類を構成できます。 開発者には、現在のページのみをビルドするよう選択できます。これにより、コードの変更後に Visual Studio でアプリケーションのデバッグをより迅速に開始できます。

The Build Page Start Action

図 9: Build ページの開始アクション

Visual Studio と ASP.NET アーキテクチャのもう 1 つの優れた機能強化は、エディット コンティニュという領域にあります。 Visual Studio 2005 では、開発者はデバッガーをデタッチすることなくプロジェクトのデバッグを開始し、プロジェクトでコードを変更できます。 実際のところ、本当にそのままの意味で、プロジェクトのデバッグを開始し、新しいクラスを追加し、そのクラスにコードを追加し、そのクラスの新しいインスタンスを作成するコードをページに追加し、そのクラスのメソッドを実行することができます。すべて、デバッガーをデタッチする必要はありません。 新しいコードの実行は、ブラウザーの表示を更新するのと本当に同じくらい簡単です。

Visual Studio 2005 のエディット コンティニュ機能のビデオ チュートリアルについては、ここをクリックしてください。

全画面表示でビデオを開く

ASP.NET 2.0 と Visual Studio 2005 の堅牢なエディット コンティニュ機能は、ASP.NET アプリケーションのアーキテクチャの変更によるものです。 ASP.NET 1.x では、Visual Studio 2002/2003 で作成されたアプリケーションは、/bin フォルダーに格納されたプライマリ アセンブリにコンパイルされました。 アプリケーションのすべてのクラス、ページなどが、その 1 つの DLL にコンパイルされました。 そして実行時に、ASP.NET はページ内のすべてのコントロール、マークアップ、ASP.NET コードをコンパイルし、それらの DLL を ASP.NET 一時フォルダーにコピーしました。

ASP.NET 2.0 を使用する Visual Studio 2005 では、上記の 2 つのコンパイル モデル アウトライン (Visual Studio 用と実行時の ASP.NET 用) が 1 つの共通のコンパイル モデルにマージされています。 これにより、すべてのコンパイルの問題が、実行時ではなく開発段階で捕捉されます。 また、ユーザー コントロールやマスター ページなどの機能に対するデザイナーと IntelliSense のサポートも可能となっています。

ユーザー コントロールに対するデザイナー サポートのビデオ チュートリアルを表示するには、ここをクリックしてください。

全画面表示でビデオを開く

Note

ユーザー コントロールがページから削除されると、@Register ディレクティブがマークアップ内に残り、そのユーザー コントロールが Web サイトから削除された場合にパーサー エラーを回避するために手動で削除する必要があります。

Visual Studio のコンパイル モデルのもう 1 つの改善点は、Web サイトの発行機能です。 発行機能により Web サイトがプリコンパイルされるため、開発者はオンデマンドでのコンパイルが一切必要ないという新たなメリットを享受できます。 また、App/_Code フォルダー内のすべてのソース コードを DLL にプリコンパイルすることで、ソース コードをデプロイする必要がなくなります。

The Publish Web Site Dialog

図 10: [Web サイトの発行] ダイアログ

Note

aspnet/_compile.exe ユーティリティを使用して、ASP.NET Web アプリケーションをプリコンパイルすることもできます。 このツールについては、モジュール 9 で説明します。

Web サイトを発行すると、次に示すように、プリコンパイルされたファイルは Temporary ASP.NET Files フォルダーに格納されます。 .compiled ファイル拡張子の付いたファイルは、特定の DLL の依存関係を定義する XML ファイルです。 Web フォームやユーザー コントロールは、App/Web/ で始まるランダムな DLL にコンパイルされます。

[このプリコンパイル済みサイトを更新可能にする] チェックボックスをオンのままにすると、Web フォームとユーザー コントロールの中のマークアップは DLL にプリコンパイルされず、デプロイ後に変更を加えることができるようになります。 デプロイされたコンテンツへの変更が許可されないようにマークアップをロックダウンするには、このチェックボックスをオフにします。

[固定名およびシングル ページ アセンブリを使用する] を使用すると、バッチ コンパイルを無効にして、各ページが固定の名前のアセンブリにコンパイルされるようにすることができます。 このボックスをオフのままにすると、バッチ コンパイルを利用できます。

[プリコンパイル済みアセンブリで厳密な名前を有効にする] チェックボックスを使用すると、プリコンパイル済みアセンブリに厳密な名前を付けられます。

Note

ASP.NET 1.x では、厳密な名前のアセンブリをグローバル アセンブリ キャッシュ (GAC) にインストールする必要がありました。 ASP.NET 2.0 では、厳密な名前のアセンブリを GAC にインストールする必要はありません。

An ASP.NET Applications Pre-Compiled Files

図 11: ASP.NET アプリケーションのプリコンパイル 済みファイル

Note

上記のアプリケーションでは、web.config ファイルはありませんでした。 存在していた場合は、Web サイトの発行プロセスの後は PrecompiledApp.config という名前になっていたでしょう。

デプロイの機能強化

Visual Studio 2002 および 2003 と同様に、Visual Studio 2005 にはプロジェクトのコピー機能が用意されています。 ただし、この機能は Visual Studio 2005 で強化され、現在は Web サイトのコピーと呼ばれています。

[Web サイトのコピー] ダイアログは、左フレームと右フレームに分かれています。 左側のフレームは [ソース Web サイト]、右側のフレームは [リモート Web サイト] と呼ばれます。 開発者にとっては混乱してしまうかもしれませんが、右側のフレームに表示されるサイトは実際にはリモート サイトとは限りません。 ローカル ファイル システム上のファイルであったり、IIS のローカル インスタンス上のファイルであったりします。 また、左側のフレームに表示されるサイトが必ずしもソース Web サイトであるとは限りません。ダイアログでは [リモート Web サイト] から [ソース Web サイト] への発行も可能です。

リモート Web サイトにプロジェクトをコピーする場合は、そのサイトに FrontPage Server Extensions がインストールされている必要があります。 インストールされていない場合は、FTP を使用して接続する必要があります。 いっぽうで、プロジェクトをローカル IIS インスタンスにコピーする場合は、FrontPage Server Extensions は必要ありません。

Note

ローカル IIS インスタンスに新しい Web サイトを作成しようとして、FrontPage 2002 Server Extensions がインストールされている場合は、SharePoint サーバー上での Web サイトの作成がサポートされていないことを示すエラー メッセージが表示されます。 その場合は、FrontPage 2000 Server Extensions をインストールするか、FrontPage Server Extensions を削除するかを選択します。

Web サイトのコピー機能のビデオ チュートリアルについては、ここをクリックしてください。

Screenshot of the video walkthrough of the Copy Web Site feature in Visual Studio.

全画面表示でビデオを開く

デバッグの機能強化

Visual Studio 2005 のデバッグには、4 つの主な機能強化があります。

  • 管理者以外としてのローカルでのデバッグは、すぐに使用できます。
  • Compilation 要素の Debug 属性が既定で false になりました。
  • リモート デバッグのセットアップと構成は、従来よりも簡単です。
  • FTP の場所を介して開かれた Web サイトをデバッグできるようになりました。

非管理者としてのデバッグ

ASP.NET 開発サーバーを追加することで、管理者でないユーザーが、すぐに ASP.NET アプリケーションを簡単にデバッグできるようになります。 ローカル ファイル システムで実行されている ASP.NET アプリケーションがデバッグされると、ログオンユーザーのコンテキストで ASP.NET 開発サーバーが Visual Studio により起動されます。 続いて、そのユーザーは、そのアプリケーションをデバッグできます。追加の構成は不要です。

Debug は既定で False

ASP.NET 1.x では、web.config ファイルの compilation 要素の debug 属性は既定で true に設定されていました。 開発者は、アプリケーションを運用環境にデプロイする前にこの属性を false に設定することが常に推奨されていましたが、ほとんどの開発者はデバッグ属性を true に設定したままにした場合の結果を完全に理解しておらず、往々にしてそのまま放置していました。

debug 属性を true に設定しておくことで生じる最も重大な問題は、これにより ASP.NET のバッチ コンパイル モデルが無効になることです。 そのため、各ページは別個の DLL にコンパイルされます。 Web アプリケーションが何千ものページで構成されている場合 (決してない話ではありません)、そのアプリケーションによって数千の小さな DLL が作成されることを意味します。 これらの DLL はサイズが小さいとはいえ、メモリ内の特定の場所には読み込まれません。 そのため、システム メモリで断片化が発生し、OutOfMemoryException が発生する可能性があります。

ASP.NET 2.0 では、debug 属性は既定で false に設定されています。 既に説明したように、開発者が Visual Studio 2005 で ASP.NET アプリケーションをデバッグすると、デバッグが有効になっている web.config ファイルを追加するように求められます。 そうしてしまうと、ASP.NET 1.x で存在していたものと同じ欠点が発生しますが、アプリケーションを運用環境に移行する前に、属性を false にリセットする必要があることを開発者に対して明確な警告が行われるようになりました。

リモート デバッグのセットアップと構成

Visual Studio 2002/2003 では、リモート デバッグはマシン デバッグ マネージャー (mdm.exe) とvs7jit.exe プロセスに依存していました。 そのため、リモート デバッグの問題のトラブルシューティングは、多くの場合、お客様にとってブラック ボックスであり、PSS にとっても決してよいとはいえませんでした。

Visual Studio 2005 では、mdm.exeプロセスとvs7jit.exe プロセスへの依存がなくなります。 代わりに、リモート デバッグ モニター サービス (msvsmon.exe) を使用するようになりました。

Visual Studio 2005 でリモートでデバッグを行う際の要件は非常に単純です。 デバッグの前に、リモート サーバーで msvsmon.exe を実行する必要があります。 Visual Studio CD からリモート デバッグ モニターをインストールすることも、Web サーバーに何もインストールすることなく、共有から msvsmon.exe を実行することもできます。

msvsmon.exe を実行すると、リモート デバッグ用のポートがブロックされているという問題がある旨のメッセージが返されると思われます。 ただ、次に示すように、警告ダイアログ内からポートのブロックは簡単に解除できます。

Notification that Windows Firewall is Blocking Remote Debugging

図 12: Windows ファイアウォールがリモート デバッグをブロックしていることを示す通知

デバッグに必要なポートのブロックを解除すると、次に示すようにリモート デバッグ モニターが表示されます。 このインターフェイスから、接続を監視し、デバッグのアクセス許可を簡単に変更できます。

The Remote Debugging Monitor

図 13: リモート デバッグ モニター

FTP 経由で開かれた Web アプリケーションをリモートでデバッグすることもできます。 手順は、ここまでに説明したものと同じです。 ただし、このモジュールで前述したように、FTP プロジェクトを参照するためのベース URL を指定する必要があります。

ラボ 2

Visual Studio 2005 を使用したリモート デバッグ

このラボでは、Visual Studio 2005 を使用したリモート デバッグについて説明します。

このラボのビデオ チュートリアルについては、ここをクリックしてください。

Screenshot of the video walkthrough of remote debugging in Visual Studio.

全画面表示でビデオを開く

このラボでは、2 台のコンピューターが必要です。Visual Studio 2005 を実行しているコンピューターが 1台、IIS 5 以降を実行しているコンピューターが 1台です。

  1. Visual Studio 2005 を開き、リモート サーバーに新しい Web サイトを作成します。

Note

Web サイトは、リモート IIS インスタンス上に、または FTP を使用して作成できます。

  1. リモート Web サーバーから、UNC パスを使用して開発用コンピューター上の msvsmon.exe を見つけて実行します。
    msvsmon.exe の既定の場所は、//server/c$/Program Files/Microsoft Visual Studio 8/Common7/IDE/Remote Debugger/x86 です。
  2. リモート デバッグ用にポートのブロックを解除するように求められたら、そのとおり行います。
  3. 開発マシンから Default.aspx のコードビハインドを開き、Page/_Load メソッドにブレークポイントを設定します。
  4. 開発用コンピューターからデバッグを開始します。

想定のとおりにブレークポイントがヒットするはずです。

ASP.NET 開発サーバーの起動

既に説明したように、Visual Studio 2005 には、ASP.NET 開発サーバーと呼ばれる Web サーバーが付属しています。 (ASP.NET 開発サーバーは、Cassini と呼ばれることもあります)。この Web サーバーは、ファイル システムで実行されている Web アプリケーションを参照してデバッグするのに便利な手段です。

ASP.NET 開発サーバーは制限のある Web サーバーです。 リモート接続は許可されず、Web サーバーを起動したユーザー以外のユーザーからの要求は受け付けません。 また、ASP ページを提供する機能も備えていません。 提供されるのは ASP.NET リソースと HTML リソース (画像、CSS ファイルなど) のみです。

ASP.NET 開発サーバーは、c:/Windows/Microsoft.NET/Framework/v2.0./////* にある WebDev.WebServer.exe ファイルを実行することで、コマンド ラインから起動できます。 使用可能なパラメーターが次のダイアログに表示されています。

Screenshot of Visual Studio dialogue box displaying the parameters for launching A S P dot net Development server from the command line.

図 14

Note

ASP.NET 開発サーバーは、コマンド ラインを使用して明示的に起動した場合はサポートされません。