.NET インフラストラクチャ & サービス.NET 展開ガイドFernando G. Guerreroホワイト ペーパー概要Microsoft .NET Framework は、ソフトウェア開発の新しいパラダイムを切り開きます。既存のインフラストラクチャの中で、これらの新しいアプリケーションとコンポーネントの管理と展開をどう進めていくのかが、IT 技術者にとっての当面の課題となっています。このガイドには、Microsoft .NET Framework に基づいたアプリケーションとコンポーネントを展開するうえで必要な情報とガイドラインが収録されています。このガイドでは、.NET アプリケーションのロールアウトを成功させるための詳細な手順を述べると共に、詳細な情報が記載されているドキュメントへのリンクを示します。トピックはじめに.NET Framework の概要展開プロジェクト計画の作成Visual Studio .NET の展開プロジェクト.NET Framework の展開サーバー側の展開クライアント側の展開Web サービスの展開.NET アプリケーションで使用する SQL Server データベースの展開要約はじめにこのガイドでは、IT マネージャ、ソリューション設計者、および IT サポート エンジニアを主な読者と想定し、.NET Framework 用に開発されたアプリケーションとコンポーネントを展開するうえで助けとなる情報を示します。展開手順の技術詳細を述べると共に、ソリューション設計者およびシステム設計者がこの新しいプラットフォームを効率的にサポートできるように、設計上のガイドラインの例を示します。ただし、このガイドでは、.NET Framework および Visual Studio .NET プログラミング環境に関する包括的な情報を示すことを目的とはしていません。.NET Framework および Visual Studio .NET プログラミング環境の詳細については、.NET Framework SDK および Microsoft Visual Studio .NET のドキュメントと MSDN Web サイト (http://www.microsoft.com/japan/msdn/net/) を参照してください。ページのトップへ.NET Framework の概要.NET Framework は、ローカル エリア ネットワーク (LAN) およびインターネット上で稼動する分散型エンタープライズ アプリケーションを高い整合性と効率性でサポートする新しい開発プラットフォームです。この新しいプラットフォームには、主に以下のような特長があります。•整合性の取れた言語非依存のオブジェクト指向開発環境であり、開発者が今までに培ってきたプログラミングの知識と経験を活かすことができます。•関連するコンポーネントとの間でのバージョン管理に煩わされることなく、効率的にソフトウェアを開発できます。•ストレージの場所に依存しない、柔軟な実行環境を提供します。ローカルに保存されたコンポーネントをローカルに実行することも、リモートに保存されたコンポーネントをローカルに実行することもでき、さらに、リモートに保存されたコンポーネントをインターネット上でリモートに実行できます。•今日の組織のセキュリティ ニーズを満たす優れたセキュリティ設定を提供し、コード実行の安全性を確保します。•Windows アプリケーションと Web アプリケーションを同じプログラミング環境で開発できます。•Windows 環境と Web 環境のどちらについても効率的なコード コンパイルができるようになっており、Windows アプリケーションと Web アプリケーションの実行パフォーマンスが向上します。•各種通信規格に準拠しており、.NET アプリケーションを他のアプリケーションやプラットフォームと共存または統合できます。.NET Framework には、以下の 2 つの主要なコンポーネントがあります。•共通言語ランタイム (CLR)•.NET Framework クラス ライブラリCLR は、.NET コードを実行および管理するシステム エージェントです。このエージェントは、メモリ管理、スレッド管理、エラー制御、型保証などの基本的なシステム サービスを受け持ちます。開発者は、任意の .NET 互換プログラミング言語を使用してアプリケーションのコードを開発できます。開発したコードは、開発者が使用している特定のコンパイラによって中間言語 (IL) コードにコンパイルされます。CLR では、効率性に優れたジャスト イン タイム (JIT) コンパイルによって、言語に依存しない IL コードをその実行先となるデバイスのコンピュータ コードに変換します。マネージ コードは、常にコンパイル済みモードで実行され、現在のプラットフォームに最適化されますが、一般的な実行エラーを防止するように管理されることに代わりありません。この新しいプログラミング モデルは、プログラムの実行を従来より緊密に制御できるため、分散型アプリケーションの実行プラットフォームとしての堅牢性に優れています。.NET Framework クラス ライブラリは、どのアプリケーション、サービス、またはコンポーネントを開発する場合にも使用できるオブジェクト指向データ型の包括的なコレクションです。このクラス ライブラリは、C++ 開発で広く使用されてきた Microsoft Foundation Classes (MFC) に置き換わるもので、拡張しやすい設計になっており、現時点では独自仕様のアプリケーション プログラミング インターフェイス (API) しか用意されていない .NET Enterprise Servers など、他のサービスに対するオブジェクト指向プログラミング サポートを提供するように拡張できます。.NET Framework は、インターネット上でのコンポーネント共有に門戸を開きます。.NET Framework の Web サービスは、Windows ベースのアプリケーションから使用できるだけでなく、TCP/IP、HTTP、XML、SOAP などのインターネット規格に準拠したアプリケーションであれば、他のプラットフォーム上で動作するアプリケーションからも使用できます。.NET Framework 用に開発されたアプリケーションでも COM コンポーネントを使用できるため、これまでに開発に費やしてきた投資が無駄になりません。ただし、COM コンポーネントを使用する場合は、両方の標準の間での変換が必要になるため、その分、パフォーマンスが犠牲になります。したがって、COM コンポーネントから、.NET アプリケーションがネイティブに使用できるマネージ コードに移行すると、パフォーマンスを大幅に向上できます。アーキテクチャ図図 1 のアーキテクチャ図は、『.NET Framework 開発者ガイド』に収録されており、MSDN (http://www.microsoft.com/japan/msdn/library/ja/cpguide/html/cpovrintroductiontonetframeworksdk.asp) にも掲載されています。この図は、アプリケーション開発のシナリオとして、以下の 3 つを示しています。•CLR を通じてマネージ コードを実行するアプリケーション•アンマネージ マシン語コードを実行するアプリケーション•ASP.NET を通じてマネージ コードを実行する Web アプリケーションおよび Web サービス.NET Framework のマネージ アプリケーションは、同じコンピュータ上でアンマネージ アプリケーションと共存できます。さらに、プログラミング言語によっては、マネージ コードとアンマネージ コードの両方をニーズに合わせて作成できます。図 1: .NET アーキテクチャ図.NET Framework では、以下のようなさまざまな種類のアプリケーションを開発者が設計できます。•Windows アプリケーション•クラス ライブラリ•Windows コントロール ライブラリ•ASP.NET Web アプリケーション•ASP.NET Web サービス•Web コントロール ライブラリ•コンソール アプリケーション•Windows サービス•セットアップ プロジェクト•Web セットアップ プロジェクト•Visual Studio .NET アドイン展開手順は、アプリケーションの種類によって異なります。ここでは、主な選択肢を取り上げます。.NET アセンブリ.NET Framework では、アプリケーションとコンポーネントの展開を簡略化する "アセンブリ" の概念が採用されています。アセンブリは、.NET プラットフォームにおける再使用、バージョン管理、セキュリティ、および展開の単位となります。複数のファイルをまとめて展開する必要がある場合は、ファイル タイプの違いにかかわらず、それらを 1 つのアセンブリにグループ化できます。DLL または実行可能アプリケーションとしてパッケージ化されたコンポーネントのように、単一のファイルがアセンブリとなることもありますが、HTML ページ、XML ファイル、マルチメディア ファイル、その他の任意のタイプのファイルなど、関連する他のファイルをアセンブリに含めることができます。開発者は、アセンブリを使用することで、展開するパッケージの物理構成から展開の論理単位を分離できます。これらのアセンブリは、単一のアプリケーションの一部として、そのアプリケーションと共に展開することも、複数のアプリケーションの間で共有することもできます。各アセンブリには、そのアセンブリのメタデータ情報を格納するマニフェストが自動的に組み込まれます。Visual Studio .NET IDE では、ソリューションが自動的に .EXE ファイルまたは .DLL ファイルにビルドされます。.NET Framework SDK に含まれている ildasm.exe ツールを使うと、アセンブリのマニフェストを表示できます。このツールを単純な HelloWorld VB.NET アプリケーションに適用した例を次の図に示します。図 2:アセンブリのマニフェストを ildasm.exe でのディスアセンブル.NET の XCOPY 展開.NET アセンブリの展開が従来と比べて、どれだけ簡単であるかを如実に示す概念として、XCOPY 展開があります。XCOPY 展開とは、アプリケーション ディレクトリをインストール先に単純にコピーするだけで .NET アプリケーションを展開できることを意味します。この簡単な展開手順は、以下の .NET 機能によって実現されます。•アセンブリには、その内容を定義するメタデータが格納されているため、どのアセンブリも自己完結していることになります。これにより、従来のように新しいコンポーネントを追加するたびに、際限なくレジストリ エントリでパブリック インターフェイスを定義する必要がなくなります。•.NET アセンブリに含まれている各コンポーネントのインストール場所が標準化されているため、レジストリ内の特定のエントリでインストール場所を定義する必要がありません。•特定のコンポーネントのインストール場所を構成ファイルで変更できますが、アセンブリは、それらの構成ファイルを標準の場所から検索するため、不要な登録処理が発生しません。しかし、以下のように、展開プロセスが複雑になるシナリオもあります。•.NET アプリケーションと COM コンポーネントの相互運用には、従来どおり登録処理が必要です。•リモート コンピュータ上でアセンブリをネイティブ コードにプリコンパイルするには、ファイルをインストール先ディレクトリに単純にコピーする場合より多くの処理が要求されます。•リモート コンピュータのグローバル アセンブリ キャッシュにアセンブリをインストールするには、そのアセンブリをグローバル共有アセンブリにするための手順が別途必要になります。•.NET Framework で開発された Windows サービスをインストールするときは、ターゲット システム上でサービスを Windows サービスとして登録する必要があります。•Active Directory、Internet Information Server、.NET Enterprise Servers など、他のサービスでオブジェクトをセットアップする必要がある .NET アプリケーションの場合は、それらのオブジェクトを作成して構成するための別のアプリケーションまたはスクリプトをセットアップ プロセスで実行する必要があります。•スタート メニューの項目、デスクトップ ショートカット、コントロール パネル アプレット、フォルダのカスタマイズ、Office アドインなど、ユーザー環境の設定をカスタマイズする場合は、それらのカスタマイズ要素をすべて作成するためのセットアップ アプリケーションが必要になります。Windows インストーラによる .NET 展開Windows インストーラを使うと、あらゆる種類のアプリケーションとコンポーネントを統一性の取れた方法で展開できます。Windows インストーラによる展開では、アプリケーションのインストールに関して、以下の説明情報を格納した Windows インストーラ ファイル (.msi ファイル) を使用します。•すべてのアプリケーション ファイル (圧縮モード)•インストール プロセスを通じて使用できるすべてのオプション (グラフィカル ユーザー インターフェイスによるインストールと自動無人モードによるインストールのどちらについても)•アプリケーション ファイルの場所•ユーザー環境の設定 (スタート メニューの項目やデスクトップ上のショートカットおよびアイコンなど)•アンインストール情報•登録要件 (必要な場合)•アプリケーションのインストールと登録を正常に完了するために必要なその他の構成設定値.NET アプリケーションを展開するには、Windows インストーラ 2.0 以上が必要です。これは、Windows 2000、Windows XP、Windows Server 2003 のすべてのエディションに付属しています。その他のプラットフォームにおける Windows インストーラの最新版の詳細については、後に説明します。.msi ファイルを作成するには、サードパーティ ツールを使用する必要があります。InstallShield Software Corporation (www.installshield.com)、Wise Solutions、Inc. (www.wise.com) などの独立系ソフトウェア ベンダから、.msi パッケージの作成に使用できる製品が提供されています。これらのツールを使用する代わりに、このホワイト ペーパーで後に述べるように、Microsoft Visual Studio .NET を使用することもできます。MSI データベースユーティリティWindows プラットフォーム SDK に含まれている Windows インストーラ SDK では、既存の .msi パッケージを ORCA.EXE ツールで表示および編集ができます。この SDK は、http://www.microsoft.com/msdownload/platformsdk/sdkupdate/ からダウンロードできます。この SDK に含まれている msidb.exe ツールを使うと、データベース テーブルとストリームのエクスポートおよびインポート、複数の .msi データベースの結合、Windows インストーラ データベースへのトランスフォーム適用を行うことができます。ORCA ツールおよび MSIDB ツールの詳細については、Windows インストーラ SDK のドキュメントを参照してください。Microsoft Application Center による .NET 展開Application Center 2000 には、負荷分散された Web ファームまたはサーバーのフェールオーバー クラスタに .NET アプリケーションを展開するためのツールが用意されています。Application Center 2000 では、クラスタ内のすべてのサーバーを単一のサーバーとして管理します。参加しているすべてのサーバーにアプリケーションのイメージを自動的に複製するように、クラスタを同期します。どのサービスもシャットダウンせずにサーバー アプリケーションをアップグレードできるため、可用性が向上します。Application Center 2000 では、開発ワークステーションから新しいアプリケーションや新しいバージョンを展開したり、展開の失敗時にそれらの変更をロールバックしたりするなどの作業を効率的に実行できます。また、Application Center 2000 には包括的な API が用意されているため、スクリプト言語を使用して展開プロセスを自動化できます。Application Center 2000 の機能の詳細については、このホワイト ペーパーでは述べません。この製品の詳細については、http://www.microsoft.com/japan/applicationcenter/ を参照してください。Microsoft System Management Server による .NET 展開Microsoft System Management Server (SMS) を使うと、Windows インストーラ パッケージに付加的な機能を追加できます。これは、特に、Windows .NET アプリケーションをクライアント コンピュータに配布するときや、Web サービスを複数の .NET Web サーバーに配布するときに役立ちます。SMS には、以下のような利点があり、変更作業や構成作業を効率的に進めることができます。•事前定義の管理規則に基づいてインテリジェントに、ターゲット ユーザーとターゲット コンピュータにソフトウェアを配布できます。•ターゲット システムがハードウェアとソフトウェアの必要条件を満たしているかどうかを事前にチェックできます。•高度なソフトウェア メータリングによりソフトウェアの使用状況を追跡して、実際の作業負荷と予想作業負荷に応じたインフラストラクチャの設計に役立てることができます。•高度な診断ツールおよびトラブルシューティング ツールにより、システムとネットワーク インフラストラクチャを細かく調整できます。SMS 2.0 を使用して Windows インストーラ セットアップ パッケージを展開するには、以下のタスクを実行する必要があります。•Windows インストーラ ランタイムをすべてのターゲット コンピュータ上で使用できることを確認します。•Windows インストーラの管理インストール機能を使用してパッケージ ソース ディレクトリをセットアップします。•パッケージを作成します。•さまざまなリソースを構成します (省略可能)。•Windows インストーラのコマンド ライン構文を使ってパッケージ用のプログラムを作成します。•パッケージの配布ポイントを指定します。•パッケージのアクセス アカウントを指定します (省略可能)。•提供情報を作成します。SMS による Windows インストーラ セットアップ パッケージ展開の詳細については、「Deploying Windows Installer Setup Packages with Systems Management Server 2.0」(http://www.microsoft.com/smserver/techinfo/deployment/20/deployosapps/deploymsi.asp) (英語) を参照してください。ただし、クラスタまたは Web ファームに Web サービスと ASP.NET アプリケーションを展開するには、Microsoft Application Center を使用することをお勧めします。ページのトップへ展開プロジェクト計画の作成.NET アプリケーションの展開を論理的に進行するには、展開プロジェクトを計画することが重要なステップになります。業務のインフラストラクチャと必要条件を満たすようにプロジェクト計画を設計する必要があります。展開プロセスのガイドラインは、MOF (Microsoft Operations Framework) に記載されています。MOF の詳細については、MOF Web サイト (www.microsoft.com/mof) を参照してください。プロジェクト計画の構築時には、以下のステップを考慮する必要があります。•プロジェクト計画概要の作成•プロジェクトの適用範囲と目的の定義•適切な展開タイムラインの決定•MOF の全般的なガイドラインに準拠した展開計画の作成•リソースおよび人員の必要条件の確認•プロジェクト チームの作成•現在の環境に関する情報の収集•標準およびガイドラインの確立•リスク管理•トレーニング•テストおよびパイロット (試運転) の概要•技術上の考慮事項と依存関係の確認•プロジェクト計画の確定異なる .NET ソリューションをほぼ同様な手順で展開できることが多く、.NET ソリューションの展開プロセスは繰り返しタスクになる傾向があります。しかし、ほとんどのソリューションの間で展開プロセスが似通っていても、ビジネスへのリスクを最小限に抑えながら展開を成功するためには、個々のソリューションに応じた展開計画を立てる必要があります。展開管理構造を構築するにあたっては、現在の管理構造との親和性を確保すると同時に、以下のフェーズの管理に適した構造を構築してください。•.NET ソリューションの展開計画の作成•.NET ソリューションの展開をテストするための .NET テスト ラボの設計と管理•本稼動環境への最終展開の完了プロジェクト計画プロセスの確立.NET ソリューションの展開は、目標と対象の定義から本稼動環境への最終展開に至るまでのライフ サイクルをたどることになります。展開プロジェクトの計画時には、展開プロセス中に従うべき妥当な指針を提示し、あらゆる活動項目を設計、実装、テスト、修正、および実行する方法を詳細に定義します。目標と対象の定義計画プロセスのこのフェーズでは、展開する .NET ソリューションの主要な論理構成を決定する必要があります。特に、ソリューションの機能のセキュリティと可用性に重点を置きます。業務を遂行するうえで必要なセキュリティと機能はネットワーク インフラストラクチャを通じて提供されることになるため、このフェーズではネットワーク インフラストラクチャが重要な役割を担います。このフェーズの目的は、展開プロジェクトの進行承認を組織上層部から得ることができるように、展開プロジェクトのフレームワークを定義することにあります。この第 1 フェーズでは、展開プロジェクトに関して、以下のような点を明確化する必要があります。•組織がこの .NET ソリューションを展開する理由。•このソリューションが使用できるようになる時期。•このプロジェクトの詳細な適用範囲。•このプロジェクトによってだれが影響を受けるのか。•展開が成功したと判断する基準。•システム内に既に実装されている .NET ソリューションがあるかどうか。.NET ソリューションが既に実装されている場合は、既存のソリューションとこれから展開するソリューションを互いに連携させるかどうか。•このソリューションを展開することにより影響を受けるアプリケーション、システム、またはソフトウェアが他に存在するかどうか。存在する場合は、それらを新しいソリューションと統合する必要があるかどうか。必要がある場合は、どのように統合するのか。•どのようなリスクがあるのか。•このプロセスにだれが関与するのか。このマイルストーンでは、以下のドキュメントを作成することになります。•目標と対象を定義するドキュメント•現在の環境の概要•リスク分析このフェーズは、展開ロードマップを作成するうえで重要となります。関与するすべてのチームに対して、このソリューションを展開する理由、現在の環境に及ぼす影響、および展開の方法を明確に示す必要があります。論理プロジェクトの概要 : 組織上の問題典型的な .NET ソリューションは、以下の複数のエンティティに影響を及ぼします。•バック エンド サーバー•アプリケーション サーバー•Web サーバー•エンド ユーザー アプリケーション•ユーザー図 3 は、.NET ソリューションの典型的なネットワーク トポロジを示しています。図 3:典型的な .NET ソリューションユーザーには内部ユーザーと外部ユーザーがありますが、どちらの場合も、ユーザーがこのソリューションの機能にどの程度までアクセスできるようにするのかを決定することが重要です。内部ユーザーについては、このソリューションに関して各ユーザーがどのレベルのアクセス権を持つのかに応じて、ユーザーを複数の役割にグループ化します。外部ユーザーについては、顧客、取引業者、パートナーを区別する必要があり、社員がネットワーク外から接続する場合も考慮する必要があるため、グループ化がやや複雑になります。各グループが、何を使用でき、何を使用できないようにするのかを定義するには、入念な計画が必要です。多くの場合は、Web サーバー上でホストされている ASP.NET ベースのアプリケーションがエンド ユーザー アプリケーションとなります。したがって、内部ファイアウォールの後方にある内部 Web サーバーから使用できる機能と、内部ファイアウォールの外から外部ユーザーが使用できる機能を明確に定義する必要があります。.NET Web サービスが提供する機能をエンド ユーザーの ASP.NET アプリケーションや Windows アプリケーションから使用できる場合があります。その場合は、どのサービスをローカル専用 (イントラネット ユーザーにだけ提供されるサービス) にし、どの Web サービスをイントラネット外からアクセスできるようにするのかを決定することが重要です。しかし、決定プロセスは、これで終わりではありません。Web サービスが使用できるようにすると言っても、あらゆる用途で使用できるようにするわけではありません。つまり、プライベート サービスとパブリック サービスを明確に区別することが必要です。したがって、Web サービスは、以下のような複数の主要グループにグループ化することが考えられます。•選択した Web サーバー上で稼動する特定の ASP.NET アプリケーションだけから使用できるプライベート Web サービス。•特定の .NET Windows アプリケーションだけから使用できるプライベート Web サービス。ASP.NET アプリケーションと Windows アプリケーションは単に同じ Web サービスのコンシューマと見なすことができるので、このグループは上のグループと概念的には同等です。•イントラネット上で動作するように設計されているあらゆるアプリケーションから使用できるプライベート Web サービス。•選択したパブリック Web サーバー上で稼動する特定の ASP.NET アプリケーションだけから使用でき、その他のアプリケーションからは使用できないプライベート Web サービス。•サービスをホストしているサーバーにアクセスできるアプリケーションであれば、どのアプリケーションからも使用できるパブリック Web サービス。インフラストラクチャおよびプラットフォームのコンポーネントから使用される Web サービスは、ローカル イントラネット上に置きます。これらの Web サービスは既にイントラネット内で保護されているため、これらに対する探索を制限する必要はありませんが、プライベート LAN の外部に置かれるパブリック Web サービスについては、探索性を制限する必要があります。プライベート .NET Web アプリケーションとパブリック .NET Web アプリケーションについても、同様なことを考慮する必要があります。これらのアプリケーションに関しては、どのアプリケーションを社内ユーザー専用にし、どのアプリケーションを外部ユーザーに提供するのかを検討する必要があります。イントラネット アプリケーションに対しては、Web サービスの代わりに、.NET リモート処理という選択肢もあります。リモート処理と Web サービスの機能比較については、Microsoft Web サイト (http://msdn.microsoft.com/library/en-us/dnadvnet/html/vbnet10232001.asp) を参照してください。異なるプラットフォームで稼動している複数のアプリケーション間での通信には Web サービスが理想的な選択肢となりますが、.NET ベースのアプリケーション間の場合はリモート処理が効率性と信頼性に優れています。いずれの場合も、どの認証方式を各コンポーネントで使用し、どのリソースの使用をどのように承認するのかを決定することが重要です。この決定はプログラムで行うこともできますが、それらの設定を展開フェーズ中に変更することはできません。しかし、このホワイト ペーパーで述べるように、プログラムで使用する設定を構成ファイルに記述しておくと、展開フェーズ中にそれらの設定をカスタマイズできます。.NET テストラボの設計と管理パイロット展開プロジェクトを実施すると、展開計画の実行可能性をテストできます。このパイロット プロジェクトの目的は、潜在的な問題を追跡および解決し、本稼動環境に干渉せずに展開プロセスを細かく調整することにあります。このフェーズは、展開の目標を達成し、プロジェクトを決められたスケジュールと予算の枠の中に収めるうえで重要です。.NET テスト ラボは、ロールアウトに関係するすべてのネットワーク レイヤとシステムを含めて、本稼動環境を論理的に複製したものとします。パイロット プロジェクトは、本稼動環境に近いほど効率性が高くなります。パイロット プロジェクトが安定すると、展開チームでミーティングを開き、最終的なロールアウトの実行可能性を検討できます。このフェーズの主なマイルストーンは、以下のとおりです。•機能仕様の完成と安定化•コンセプトの裏付けの完了•稼動前テストの完了•パイロットの完了•リスク管理計画の更新展開を引き継ぐ運用チームの助けになるように、付加的な展開ドキュメントを作成することも考えられます。たとえば、以下のドキュメントです。•トレーニング計画•サポート計画またはヘルプ デスク計画•運用移管計画•障害復旧計画このフェーズでは、展開計画は、パイロット プログラム中に実施したテストに基づいて継続的に変更されることが多く、動的な計画となります。障害復旧計画は、徹底したテストが必要であり、すべての既知の潜在的問題を予想して解決できるように、特に注意を払う必要があります。フィードバックの取得パイロット プロジェクトから先に進むかどうかを判断しやすくなるように、パイロットに関与したすべてのグループからフィードバックを取得する必要があります。これらのフィードバックを取得するには、以下の方法が考えられます。•Web サイト上に用意したフィードバック フォーム•ビジネス マネージャとの討議•問題レポート•調査•IT プロジェクトとネットワーク運用チームからの意見収集展開しようとしている .NET ソリューションに関して、以下のようなさまざまな角度から、できるだけ多くの情報を収集します。•トレーニング•ロールアウト プロセス•サポート•通信•遭遇した問題•改善の提案本稼動ロールアウト本稼動ロールアウトが展開プロジェクトの最終フェーズとなります。このフェーズに入る時点では、パイロット プログラムに沿ってテスト ラボですべてのタスクが既にテストされており、すべてのリスクと緊急事態対策がすべて定義されています。テスト ラボと実際の本稼動環境には違いがあるため、パイロット プロジェクトで開始したテストおよび調整プロセスを継続する必要があります。本稼動ロールアウト プロセスは、本稼動ロールアウト計画として完全にドキュメント化します。この計画には、各種コンポーネントがどのように展開されているのかに関する詳細な情報を含めることになります。コンポーネント間に依存関係がある場合は、それらの依存関係に特に注意を払い、展開の順序を明確に指定します。障害復旧計画は、テスト ラボで既にテストしましたが、実際の本稼動環境に一致しない部分がある場合は、この時点で再調整します。展開が完了し、上層部およびスポンサーに提示するプロジェクト完了レポートを作成し終えたら、必要に応じて新しいプロジェクト レビューを実施します。プロジェクト レビューでは、プロジェクト全体の長所と短所を客観的に指摘すること、および、実地経験から得た知識を今後のインフラストラクチャ展開にどのように活かすことができるのかを分析することが考えられます。ページのトップへVisual Studio .NET の展開プロジェクトWindows インストーラを使って .NET アプリケーションを展開する場合は、図 4 に示すように、Visual Studio .NET で設定および展開用プロジェクトのいずれかを使用できます。図 4: Visual Studio .NET でセットアッププロジェクトを追加する•セットアッププロジェクト Windows ベースのアプリケーション用の Windows インストーラ プロジェクトを作成します。•Web セットアッププロジェクト 開発プロセス中にファイルを手動で追加できる Windows インストーラ Web プロジェクトを作成します。•結合モジュールプロジェクト 複数のアプリケーションの間で共有される可能性のあるコンポーネントをパッケージ化します。•セットアップウィザード 画面上の指示に従ってセットアップ プロジェクトを作成できます。•Cab プロジェクト レガシ Web ブラウザにダウンロードするためのキャビネット (.cab) ファイルを準備します。VS.NET IDE では、いったん作成した Web セットアップ プロジェクト (Web 展開用のプロジェクト) をセットアップ プロジェクト (Windows インストーラ プロジェクト) に変更することはできません。この逆の変更もできません。この 2 つの機能を同時に使用するには、2 つの異なるセットアップ プロジェクトを作成する必要があります。セットアップ ウィザードを使うと、セットアップ プログラムを簡単に作成できますが、より柔軟な展開プロジェクトを作成できます。セットアップ プロジェクトには、いくつかのエディタがあります。図 5 に示すように、セットアップ プロジェクトのコンテキスト メニューから対応するメニュー項目を選択すると、これらのエディタを表示できます。図 5:セットアッププロジェクトの [表示] メニューからエディタを選択アプリケーション用として選択できるエディタには、以下のものがあります。ファイルシステムエディタ このエディタでは、ユーザーのデスクトップとスタート メニューをカスタマイズすることや、ファイルおよびショートカットをアプリケーション フォルダに追加することができます。図 6:ファイルシステムエディタのオプションレジストリエディタ このエディタでは、レジストリにキーまたは値を追加できます。既定の設定値を保存する場合に使用できます。図 7:レジストリエディタのオプションファイルの種類エディタ このエディタでは、ファイルの種類の追加、および、ファイルの種類に適用するアクションを追加ができます。これらは、拡張子によって定義されます。たとえば、次の図では、ファイルの種類 FGG (拡張子 .fgg) が定義されており、そのアクションとして [開く] が定義されています。図 8:ファイルの種類およびアクションの定義ユーザーインターフェイスエディタ このエディタでは、セットアップ アプリケーションの外観をカスタマイズできます。これらの設定では、セットアップ ウィザードの画面のうち、特定の画面を非表示にしたり、テンプレート スタイルのコレクションから他の画面を追加したりできます。次の図に示すように、ウィザードの特定の部分にどのテキストを表示するのかを定義できます。この図では、テキストが長すぎて全体が表示されていませんが、実際に編集するときには、テキスト全体にアクセスできます。図 9:ユーザーインターフェイスダイアログの定義拡大表示するカスタムアクションエディタ このエディタでは、特定のアクションが選択されたときに、どのプログラムを実行するのかを指定できます。この機能は、さらに別のコンポーネントをインストールする場合や、特定のデータベース オブジェクトを作成する場合に役立ちます。これらのアクションは、以下のような特定のイベントの発生時に実行されます。•アプリケーションのインストール•コミット•インストールのロールバック•アプリケーションのアンインストール図 10:カスタムアクションを定義する起動条件エディタ このエディタでは、どの条件をターゲット コンピュータ上でチェックするのかを指定できます。図 11:起動条件を定義するセットアッププロジェクトの構成セットアップ プロジェクトの構成設定値には、セットアップ プロジェクトのプロパティ ページからアクセスできます。これらのページにアクセスするには、図 12 に示すように、プロジェクトのコンテキスト メニューの [プロパティ] をクリックします。図 12:セットアッププロジェクトのプロジェクトページ拡大表示するこの構成ページを使うと、ビルド構成およびファイルの生成先のフォルダを定義できます。これらのファイルは、図 13 に示すように、数とおりの方法で作成できます。図 13:セットアップファイルのパッケージ方法の定義図 14 に示す [ブートストラッパ] のボックスの一覧を使うと、どの種類の Windows インストーラ ブートストラッパを提供するのかを選択できます。この例では、ブートストラッパを提供することがターゲット コンピュータ側の必要条件になっています。図 14:ブートストラッパを選択する他のどの .NET プロジェクトとも同様に、このセットアップ プロジェクトは、図 15 に示すようにサイズや速度を最適化できます。図 15:圧縮の最適化方法を選択するセットアップファイルセットアップ プロジェクトのビルド プロセスでは、選択したビルドのタイプに応じて Debug フォルダまたは Release フォルダのいずれかに以下のファイルが作成されます。表 1:セットアップ中に作成されるファイルファイル説明YourSetupProgram.msiこのファイルは、Windows インストーラでアプリケーションをセットアップするために必要なインストーラ データベースです。Windows インストーラが既にインストールされている場合、配布が必要になるのはこのファイルだけです。ただし、Windows インストーラがインストールされていなくてもプログラムをインストールできるように、ファイル セット全体を配布することをお勧めします。InstmsiA.exeこのファイルは、Windows 95/98/Me に Windows インストーラをインストールするためのプログラムです。InstmsiW.exeこのファイルは、Windows NT/2000/XP/Server 2003 に Windows インストーラをインストールするためのプログラムです。なお、Windows 2000/XP/Server 2003 には Windows インストーラが標準で付属していますが、この配布ファイルに新しいバージョンを含めることができます。setup.exeこのプログラムは、Windows インストーラを実行し、指定された .msi ファイルを使用してアプリケーションをインストールします。このプログラムは、アプリケーションのインストール前に、システムに Windows インストーラがインストールされているかをチェックし、インストールされていなければ Windows インストーラをインストールします。Setup.iniこのファイルは、setup.exe から .msi ファイルを参照するときに使用される構成ファイルです。ページのトップへ.NET Framework の展開.NET Framework 用に設計されたアプリケーションまたはサービスを特定のコンピュータ上で実行するには、そのコンピュータに .NET Framework がインストールされていることが必要です。.NET Framework は、現行の Microsoft プラットフォームのいずれにも付属していないので、.NET Framework がターゲット コンピュータにインストールされているかどうかを事前に確認する必要があります。Microsoft Windows Server 2003 の各エディションが稼動しているコンピュータでは、標準のオペレーティング システム セットアップ プロセス中に .NET Framework が既にインストールされています。Microsoft Windows XP が稼動しているコンピュータでは、Microsoft Windows Update Web サイトを通じて .NET Framework をインストールできます。.NET Framework を最新のサービス パックおよびリリースにアップデートするには、Microsoft Windows アップデート Web サイトを使用することをお勧めします。その他のプラットフォームが稼動しているコンピュータに対しては、.NET Framework の再配布可能版が Dotnetfx.exe アプリケーションとして用意されています。現時点では、この再配布可能版は、以下の場所および製品に用意されています。•Microsoft ダウンロード サイト : http://msdn.microsoft.com/library/default.asp?url=/downloads/list/netdevframework.asp•.NET Framework SDK の dotNETRedist ディレクトリ。.NET Framework SDK は、MSDN (http://msdn.microsoft.com/library/default.asp?url=/downloads/list/netdevframework.asp) からダウンロードできます。•Microsoft Visual Studio .NET Windows Component Update CD の dotNetFramework ディレクトリ。•Microsoft Visual Studio .NET DVD の ･wcu･dotNetFramework ディレクトリ。ユーザーに .NET Framework の再配布可能版をイントラネットや Web サイトから直接ダウンロードさせるのではなく、Microsoft Windows アップデート Web サイトへのリンクをユーザーに提供してください。これにより、.NET Framework の再配布可能版の最新バージョンをユーザーに使用させることができます。この再配布可能版では、サーバー コンポーネントおよびクライアント コンポーネントに必要なファイルがすべてインストールされます。.NET Framework の再配布可能パッケージでは、以下のプラットフォームがサポートされています。•Windows 98•Windows 98 Second Edition•Windows Millennium Edition (Windows ME)•Windows NT 4.0 (Workstation または Server) Service Pack 6a•Windows 2000 (Professional、Server、または Advanced Server)•Windows XP (Home および Professional)•Windows Server 2003.NET Framework コンポーネントを実行するには、以下のソフトウェアも必要です。•Internet Explorer 5.01 以上。最新バージョンの Internet Explorer は、以下のサイトからダウンロードできます。•Microsoft Windows Update Web サイト : http://v4.windowsupdate.microsoft.com/ja/default.asp•Internet Explorer ダウンロード サイト : http://www.microsoft.com/japan/ie/downloads/default.asp•Windows インストーラ 2.0 以上。最新バージョンの Windows インストーラは、以下のサイトからダウンロードできます。•Microsoft Windows Update Web サイト : http://v4.windowsupdate.microsoft.com/ja/default.asp•Microsoft ダウンロード センター :http://www.microsoft.com/downloads/release.asp?ReleaseID=32831 (Windows 95、98、98 SE、および Me)http://www.microsoft.com/downloads/release.asp?ReleaseID=32832 (Windows NT 4.0 および Windows 2000)Windows XP および Windows Server 2003 には、新しいバージョンが既に付属していますが、Microsoft Windows Update Web サイトでアップデートの有無を確認することをお勧めします。•サーバー上のデータ アクセス コンポーネント (MDAC 2.7 推奨)。これらのコンポーネントの最新バージョンは、http://www.microsoft.com/japan/msdn/data/default.asp からダウンロードできます。•Windows 2000、Windows XP (Professional)、および Windows Server 2003 にインストールされたインターネット インフォメーション サービス (IIS)。このソフトウェアは、ASP.NET アプリケーションの実行に必要です。ページのトップへサーバー側の展開ASP.NET アプリケーションおよび Web サービスは、サーバー コンポーネントとして動作するように設計されており、多くの場合は、ローカル ネットワークまたはリモート ネットワーク上に置かれた専用のコンピュータで集中的に実行されます。これらのアプリケーションとサービスを実行するには、すべての前提条件を確実に満たす必要があります。Windows Server 2003 オペレーティング システムが稼動しているシステムでは、.NET アプリケーションを実行するための前提条件がすべて満たされています。展開するアプリケーションでクライアント側コンポーネントを使用しないのであれば、実施の必要がある展開はサーバー側の展開だけになります。この場合、展開するアプリケーションによって提供される機能は、インターネット ブラウザまたは Windows アプリケーションによって使用されることになり、.NET アプリケーションに関連するどのプロセスにもホスト アプリケーションは関与しません。必要条件の確認.NET サーバー アプリケーションが良好なパフォーマンスで動作するように、表 2 に示す必要条件を確認してください。表 2: .NET アプリケーションを実行するためのサーバー要件種類必要条件サポートされているオペレーティング システムMicrosoftｮ Windowsｮ 2000 Professional Service Pack 2.0。Microsoftｮ Windowsｮ 2000 Server Service Pack 2.0。Microsoftｮ Windowsｮ 2000 Advanced Server Service Pack 2.0。Microsoftｮ Windowsｮ XP Professional。Microsoftｮ Windowsｮ Server 2003, Web Edition。Microsoftｮ Windowsｮ Server 2003, Standard Edition。Microsoftｮ Windowsｮ Server 2003, Enterprise Edition。SQL Server .NET データ プロバイダを使用するための必要条件Microsoft Data Access Components (MDAC) 2.7。このコンポーネントの最新バージョンは、以下のサイトからダウンロードできます。http://www.microsoft.com/japan/msdn/data/default.aspASP.NET アプリケーションを実行するための必要条件Microsoft IIS 5.0 以上 (Windows XP Pro には Version 5.1、Windows .NET には Version 6.0 が付属)。プロセッサインストールされている Windows のバージョンによって違いがありますが、最小限で Intel Pentium 133 MHz (またはこれに相当するプロセッサ) が必要です。作業負荷レベルが高くなることが予想される場合は、マルチプロセッサ コンピュータ上で Pentium III XEON を使用することをお勧めします。.NET サーバー コンポーネントは、複数のユーザーによって繰り返し実行されることになるため、その作業負荷に応じた処理能力が必要になります。プロセッサはますます高速化しつつあり、2 GHz を超える速度も当たり前のことになってきました。RAMインストールされている Windows のバージョンによって違いがありますが、最小限で 128 MB 以上の RAM が必要です。.NET Framework の高度なキャッシュ機能を活用できるように、メモリ容量をできるだけ大きくすることをお勧めします。ストレージ容量インストールされている Windows のバージョンで必要になる容量とアプリケーションを構成するファイルのサイズ以外には、ストレージ容量に関する要求条件は特にありません。ディスク アクセスを最適化し、ストレージ サブシステムにフォールト トレランス機能を持たせるために、高品質な SCSI ディスクと RAID 構成を使用することをお勧めします。Windows 負荷分散サービス (WLBS) を使用して複数のシステムから構築された Web ファームは、SAN デバイスや NAS デバイスなどのネットワーク ストレージ システムを活用できます。ネットワークネットワークの必要条件は、予想される作業負荷と帯域幅の使用率によって異なります。内部クライアントとリモート クライアントとではネットワークの必要条件が異なりますが、これらの必要条件は、純粋なネットワーク管理上の問題です。ページのトップへクライアント側の展開ASP.NET アプリケーションおよび Web サービスは、サーバー コンポーネントとして動作するように設計されています。クライアント デバイスでは、Internet Explorer などのホスト アプリケーションを使用して、これらの .NET アプリケーションを実行するか、または、.NET アプリケーションを実行して、これらのサービスをリモートに使用することになります。Windows Server 2003 オペレーティング システムが稼動しているシステムでは、クライアント デバイスとして .NET アプリケーションを実行するための前提条件がすべて満たされています。.NET アプリケーションの展開時にクライアント側コンポーネントを展開する必要が生じることがありますが、その場合の展開に関する考慮事項は、.NET サーバー アプリケーションを展開する場合とよく似ています。必要条件の確認.NET アプリケーションが適切な機能とパフォーマンスでクライアント デバイス内で動作するように、表 3 に示す必要条件を確認してください。表 3: .NET アプリケーションを実行するためのクライアント要件種類必要条件サポートされているオペレーティング システムMicrosoftｮ Windowsｮ 98。Microsoftｮ Windowsｮ 98 Second Edition。Microsoftｮ Windowsｮ Millennium Edition。Microsoftｮ Windows NTｮ 4.0 Workstation (Service Pack 6.0a 以降)。Microsoftｮ Windows NTｮ 4.0 Server (Service Pack 6.0a 以降)。Microsoftｮ Windowsｮ 2000 Professional。Microsoftｮ Windowsｮ 2000 Server。Microsoftｮ Windowsｮ 2000 Advanced Server。Microsoftｮ Windowsｮ XP Home Edition。Microsoftｮ Windowsｮ XP Professional。Microsoftｮ Windowsｮ Server 2003, Web Edition。Microsoftｮ Windowsｮ Server 2003, Standard Edition。Microsoftｮ Windowsｮ Server 2003, Enterprise Edition。インターネット ブラウザMicrosoftｮ Internet Explorer 5.01 以降。Windows インストーラMicrosoftｮ Windowsｮ Installer 2.0 以上。SQL Server .NET データ プロバイダを使用するための必要条件MDAC 2.7。このコンポーネントの最新バージョンは、以下のサイトからダウンロードできます。http://www.microsoft.com/japan/msdn/data/default.aspシステム管理情報にアクセスするための必要条件WMI (Windows Management Instrumentation)。Windows 2000、Windows Millennium Edition、Windows XP、および Windows Server 2003 の場合にオペレーティング システムと共にインストールされます。COM+ サービスWindows 2000 Service Pack 2.0、Windows XP、Windows Server 2003。ASP.NET アプリケーションを実行するための必要条件Microsoft IIS 5.0 以上 (Windows XP Pro には Version 5.1、Windows .NET には Version 6.0 が付属)。プロセッサインストールされている Windows のバージョンによって違いがありますが、最小限で Intel Pentium 90 MHz (またはこれに相当するプロセッサ) が必要です。クライアント側コンポーネントの実行を伴う .NET アプリケーションを使用する場合は、最小限の必要条件よりも高い速度で動作する Pentium III/IV を使用することをお勧めします。RAMインストールされている Windows のバージョンによって違いがありますが、最小限で 32 MB 以上の RAM が必要です。.NET Framework の高度なキャッシュ機能を活用できるように、メモリ容量をできるだけ大きくすることをお勧めします。ストレージ容量インストールされている Windows のバージョンで必要になる容量とアプリケーションを構成するファイルのサイズ以外には、ストレージ容量に関する要求条件は特にありません。ネットワークネットワークの必要条件は、予想される帯域幅の使用率によって異なります。セキュリティに関する考慮事項Web サービス上の認証および承認には、ASP.NET アプリケーションの認証および承認とまったく同じ規則が適用されます。各種認証方式の概要を表 4 に示します。表 4:認証方式認証方式説明Windows – 基本認証この認証方式では、base64 文字列にエンコードされたユーザー名とパスワードを送信しますが、このデータは暗号化されていません。したがって、このデータがネットワーク監視ツールで傍受されると、アプリケーションまたはサービスのセキュリティが損なわれる可能性があります。SSL で保護された Windows 基本認証Secure Sockets Layer (SSL) 暗号化を使用して、インターネットからユーザー名とパスワードを送信します。SSL は、設定が簡単ですが、パフォーマンスが低下します。Windows ダイジェスト認証ハッシュ テクニックを通じてインターネット クライアントの ID を保護します。プロキシ サーバーも通過できますが、他のプラットフォームではあまりサポートされていません。統合 Windows 認証NTLM または Kerberos を使用します。Microsoft Internet Explorer との通信は、NTLM または Kerberos 暗号化標準を使用して暗号化されます。Windows クライアント証明書イントラネットおよびインターネット上のユーザーに安全な認証を提供します。各クライアントが相互に信頼された証明書を要求します。必要に応じて、Windows アカウントに証明書をマッピングすることもでき、その場合は、Web サービスへのアクセスを IIS に自動的に承認させることができます。フォーム認証HTTP のクライアント側リダイレクトを使用して、HTTP フォームを通じた認証を提供します。Web サービスでは、直接サポートされていません。SOAP ヘッダー (カスタム)SOAP ヘッダー内に格納した資格情報を渡すことで、Web サービスへの認証アクセスと非認証アクセスを提供します。一般に、プラットフォームに依存しません。セキュリティ構成ファイル .NET アプリケーション用のセキュリティ構成ファイルのインストール場所は、表 5 に示すとおりです。表 5:構成ファイルのインストール場所ポリシーの種類構成ファイルエンタープライズポリシー Windows 2000%runtime install path%\Config\Enterprisesec.configWindows NT%runtime install path%\Config\Enterprisesec.configWindows 98 および Windows ME%runtime install path%\Config\Enterprisesec.configコンピュータポリシー構成ファイルWindows 2000%runtime install path%\Config\Security.configWindows NT%runtime install path%\Config\Security.configWindows 98 および Windows ME%runtime install path%\Config\Security.configユーザーポリシー構成ファイルWindows 2000%USERPROFILE%\Application data\Microsoft\CLR security config\vxx.xx\Security.configWindows NT%USERPROFILE%\Application data\Microsoft\CLR security config\vxx.xx\Security.configWindows 98 および Windows ME%WINDIR%\username\CLR security config\vxx.xx\Security.configセキュリティ ファイルの損傷を避けるために、以下のいずれかのツールを使用してください。•.NET Framework Configuration ツール (Mscorcfg.msc)•Code Access Security Policy ツール (Caspol.exe).NET アプリケーションの構成.NET アプリケーションの構成情報は、以降の節で詳細に述べるいくつかのファイルに格納されます。ここでは、これらのファイルがどこにあるかに関する情報を示すと共に、それらのファイルの目的と主なセクションについて説明します。構成ファイルは、標準的な XML ファイルです。構成設定値は、XML タグで定義した要素の事前定義セットとして配置されます。構成ファイルを直接編集するには、XML に関する知識が必要です。XML のタグおよび属性では大文字と小文字が区別されることに注意してください。各構成ファイルには、必ず以下の形式の 要素が 1 つ含まれます。
要素では、アプリケーションを実行する CLR のバージョンを指定します。このセクションの詳細については、次の Web サイトを参照してください。http://www.microsoft.com/japan/msdn/library/ja/cpgenref/html/gngrfstartupsettingsschema.aspこのセクションでは、アプリケーションの実行に必要な特定のランタイムを指定できます。システムに複数のバージョンの CLR がインストールされている場合、この設定を使用すると、互換性のないバージョンの CLR が使用されるのを防ぐことができます。ランタイム
CLR におけるガベージ コレクションの処理方法と構成ファイルで使用するアセンブリのバージョンを指定します。このセクションの詳細については、次の Web サイトを参照してください。http://www.microsoft.com/japan/msdn/library/ja/cpgenref/html/gnconremotingsettingsschema.aspこのセクションを使うと、アプリケーションと互換性のあるアセンブリのバージョン範囲や、一部のアセンブリの代替パスを指定できます。リモート処理
リモート処理アプリケーションの構成ファイルにカスタム設定を追加するためのタグを格納します。このセクションの詳細については、次の Web サイトを参照してください。http://www.microsoft.com/japan/msdn/library/ja/cpgenref/html/gnconremotingsettingsschema.aspこのセクションでは、アプリケーションに必要なリモート オブジェクトとアプリケーションがリモート用に公開する既知のオブジェクトを指定します。ネットワーク
ASP.NET Web アプリケーションの動作を制御します。このセクションの詳細については、次の Web サイトを参照してください。http://www.microsoft.com/japan/msdn/library/ja/cpgenref/html/gngrfaspnetconfigurationsectionschema.aspコンピュータ構成ファイル machine.config ファイルは、%runtime install path%\Config ディレクトリに置かれており、.NET がインストールされているコンピュータ全体に影響する設定を格納します。コンピュータ全体を対象にしないアプリケーション設定値は、後に述べるように別の場所に保存できます。Windows インストーラで .NET アプリケーションを展開する場合は、必要な変更が machine.config ファイルに自動的に適用されますが、XCOPY 展開を使用する場合は自動的に適用されません。アプリケーション構成ファイル CLR は、最初にアプリケーション構成ファイルからアプリケーションの設定値を検索し、その後、コンピュータ構成ファイルを参照します。アプリケーション構成ファイルの名前と場所は、アプリケーションのホストが以下のいずれであるかによって異なります。•実行可能ファイルによってホストされるアプリケーション 実行可能ファイルによってホストされるアプリケーションの構成ファイルは、アプリケーションと同じディレクトリに置かれます。アプリケーション名に .config 拡張子を付加したものが、構成ファイルの名前となります。たとえば、myApp.exe というファイル名のアプリケーションの場合なら、構成ファイル名は myApp.exe.config となります。アプリケーション構成ファイルのサンプル (caspol.exe.config) を以下に示します。
•ASP.NET によってホストされるアプリケーション ASP.NET 構成ファイルの名前は、Web.config です。ASP.NET アプリケーションの構成ファイルには、URL パス内の構成ファイルの設定値が継承されます。たとえば、www.nwtraders.msft/marketing/year2002 の URL の場合なら、www.nwtraders.msft/marketing が Web アプリケーションを指し、このアプリケーションに関連付けられている構成ファイルは www.nwtraders.msft/marketing に置かれます。/year2002 サブディレクトリ内の ASP.NET ページでは、アプリケーション レベルの構成ファイルと /year2002 サブディレクトリ内の構成ファイルの両方の設定値を使用します。ASP.NET 構成ファイルの詳細については、http://www.microsoft.com/japan/msdn/library/ja/cpguide/html/cpconaspnetconfiguration.asp を参照してください。•Internet Explorer でホストされるアプリケーション Internet Explorer でホストされるアプリケーションに構成ファイルがある場合、そのファイルの場所は、<link> タグで指定されます。構文は、次のとおりです。<link rel="Configuration" href="location">.構成ファイルの URL は、このタグの href 属性を通じて Internet Explorer に渡されます。構成ファイルは、アプリケーションと同じ Web サイト上に置く必要があります。ページのトップへWeb サービスの展開これまでに述べた内容は、あらゆる種類の .NET アプリケーションとサービスに該当します。ただし、Web サービスに関しては、注意点がいくつかあります。XML Web サービスの展開時には、XML Web サービスによって使用される Microsoft .NET Framework 外の .asmx ファイルとアセンブリを Web サーバーにコピーする必要があります。たとえば、StockServices という名前の XML Web サービスを展開する場合なら、Web サーバー上に仮想ディレクトリを作成し、XML Web サービスの .asmx ファイルをその仮想ディレクトリに置きます。必須条件ではありませんが、この仮想ディレクトリを IIS Web アプリケーションにもすることをお勧めします。このようなアプリケーションの典型的なツリー構造は、以下のようになります。
\Bin ディレクトリには、XML Web サービスによって使用される Microsoft .NET Framework 外のすべてのアセンブリへの参照を追加できます。Web サービスと共に展開される項目XML Web サービスを公開するときには、表 7 に示す項目が Web サーバーに展開されます。表 7: Web サービスと共に展開される項目項目説明Web アプリケーション ディレクトリXML Web サービスのルート ディレクトリです。他のファイルはすべて、このディレクトリの中に置かれます。このディレクトリには、IIS Web アプリケーションのフラグを付けてください。<MyXMLWebService>.asmx ファイルクライアントが XML Web サービスを呼び出すときに使用されるベース URL です。このファイルには、任意の有効なファイル名を付与できます。<MyXMLWebService>.disco ファイル (省略可能)XML Web サービスの探索メカニズムです。.disco ファイルは、XML Web サービスに対して自動的に作成されるファイルではありません。XML Web サービスで使用する探索ファイルを作成する方法については、次の Web ページの「XML Web サービスに対する探索の有効化」を参照してください。http://www.microsoft.com/japan/msdn/library/ja/cpguide/html/cpconenablingdiscoveryforwebservice.aspこのファイルには、任意の有効なファイル名を付与できます。Web.config ファイル (省略可能)既定の構成設定値を上書きする必要がある場合は、Web.config ファイルを含めることができます。このファイルを XML Web サービスに使用させることにより、システムのカスタマイズと拡張を行うことができます。たとえば、XML Web サービスにだけ認証が必要で、システム上の他の Web アプリケーションに認証が不要な場合であれば、その XML Web サービスに固有の Web.config ファイルを含めることができます。Web サービスの構成オプションの詳細については、次の Web ページを参照してください。http://www.microsoft.com/japan/msdn/library/ja/cpguide/html/cpconconfigurationoptionsforaspnetwebservices.asp\Bin ディレクトリXML Web サービス用のバイナリ ファイルを格納します。XML Web サービスのクラスが .asmx ファイルと同じファイルに含まれていない場合は、そのクラスが格納されているアセンブリを \Bin ディレクトリに置く必要があります。ページのトップへ.NET アプリケーションで使用する SQL Server データベースの展開.NET アプリケーションおよび Web サービスでは、アプリケーション データの保存に SQL Server データベースを使用することがあります。展開プロセスは、すべての必要なストレージ要素を自動的にインストールするように定義します。以下のいずれかの方法を使用できます。•既存の SQL Server を利用します。サーバー上で SQL Server が既に稼動しており、.NET アプリケーションから使用できると、そのサーバー上にデータを保存するようにアプリケーションを構成できます。この場合、以下の設定値を指定するためのオプション (ユーザー インターフェイス上のオプションか、または構成設定値) をセットアップ プログラムに用意します•SQL Server が稼動しているサーバー。必要に応じて、インスタンス名も含めます。通常は、接続先のサーバー インスタンスの名前を (ServerName\InstanceName の形式で) 直接記述、または、IP アドレスとポート番号を (nnn.nnn.nnn.nnn, pppp の形式で) 記述できます。必要に応じて、使用できる SQL Server インスタンスを検索するための検索ボタンをプログラムに用意します。•データベース名。アプリケーションの必要条件に応じて、既存または新しいデータベースの名前を指定します。新しいデータベースが必要な場合は、既存のデータベース ファイルをセットアップ プログラムに添付して、セットアップ中に展開させることができます。•認証方式。通常は、SQL Server 認証 (ユーザー名とパスワードの入力が必要)、統合 Windows 認証のいずれかを選択できます。•新しい SQL Server インスタンスをインストールします。このインストールは、セットアップ中の特定の入力、または構成設定値に基づいて行うことができます。SQL Server のセットアップ手順については、SQL Server 運用・移行 Web サイト (http://www.microsoft.com/japan/sql/techinfo/deployment/2000/default.asp) を参照してください。•新しい SQL Server Desktop Engine をインストールします。展開するアプリケーションだけで使用するデータベースを展開する場合は、SQL Server Desktop Engine をインストールするのが最も簡単な方法となります。このエディションの SQL Server では、ライセンスに定義されている使用ガイドラインを守る必要がありますが、サーバー アクセスまたはクライアント アクセスのためのライセンスは不要です。SQL Server Desktop Engine を使用してアプリケーションを開発するために必要なライセンスを開発者が持っており、Desktop Engine の制限内で .NET アプリケーションのパフォーマンス要件を達成できるのであれば、この方法が最善となります。SQL Server Desktop Engine の詳細については、次の Web サイトを参照してください。http://www.microsoft.com/japan/sql/techinfo/development/2000/MSDE2000.asp.SQL Server Desktop Engine をカスタム アプリケーションに埋め込む方法については、http://msdn.microsoft.com/library/en-us/dnsql2k/html/sql_embeddingmsde.asp (英語) を参照してください。SQL Server データベースのアタッチ.NET アプリケーションの展開に SQL Server データベースが含まれる場合は、SQL Server のデータベース アタッチ機能を使用するのが最も簡単な方法となります。既存または新規にインストールした SQL Server にアタッチされることになる SQL Server データベースを展開するには、以下の手順に従ってください。•アプリケーションの開発フェーズ中に完全な SQL Server データベースを作成します。このデータベースには、アプリケーションの起動に必要な、すべてのオブジェクト、ユーザー、アクセス許可、および既定データを格納しておきます。このデータベースは、既存の SQL Server 2000 インスタンスを使って作成できます。•データベースをデタッチします。sp_detach_db ストアド プロシージャを使用して、SQL Server からデータベースを接続解除します。このシステム ストアド プロシージャの構文については、http://msdn.microsoft.com/library/en-us/tsqlref/ts_sp_da-di_83fm.asp (英語) を参照してください。•展開プロジェクトにデータベース ファイルを含めます。展開が必要となるのは、データ ファイルだけです。これらのファイルの拡張子は、.mdf (プライマリ ファイル) および .ndf (セカンダリ ファイル) です。セカンダリ ファイルは存在しない場合もあります。拡張子 .ldf のログ ファイルは、この展開には不要です。データベースのアタッチ プロセスでは、空のトランザクション ログ ファイルが作成されます。•目的のシステムでデータベースをアタッチするためのセットアップ アプリケーションを作成します。前に述べたガイドラインに従って、データベースをどの SQL Server インスタンスにアタッチするかを選択します。データベースをターゲット サーバーにアタッチするには、sp_attach_db ストアド プロシージャを使用します。このシステム ストアド プロシージャの構文については、http://msdn.microsoft.com/library/en-us/tsqlref/ts_sp_ae-az_52oy.asp (英語) を参照してください。ページのトップへ要約Microsoft .NET Framework は、安全でスケーラブルなソリューションを開発者が構築するための、強力で拡張性に優れたプラットフォームとなります。.NET Framework では、Windows 2000、IIS、および SQL Server で提供されている既存の機能も拡張されていますが、これらの新しいソリューションの展開方法は従来のものとは大きく異なっています。ここでは、展開する .NET アプリケーションを Windows インストーラと XCOPY 展開で準備する方法の詳細を述べていますが、このホワイト ペーパーの最も重要な目標は、最終的な本稼動環境における展開を成功するために、展開プロセスを入念に設計およびテストすることの重要性を示すことにあります。ページのトップへ
[ 9] .NET 展開ガイド
[ѥ] http://www.microsoft.com/japan/technet/archive/itsolutions/net/deploy/netdgv2.mspx
|
