1 人のうち 1 人が役に立つと評価しました - このトピックを評価する

Visual Studio .NET と Visual SourceSafe を使用したチーム開発

ソリューションとプロジェクトの構造化

.NET による分散アプリケーションの構築

Microsoft Corporation

January 2002
日本語版最終更新日 2002 年 12 月 11 日

概要 : この章では、Visual Studio .NET のソリューションとプロジェクトを組織化および構造化する方法を説明し、単一ソリューション開発モデルと複数ソリューション開発モデルの比較検討を示します。また、ローカルまたは VSS (Visual SourceSafe) 内部にプロジェクトを格納するために使用できる推奨フォルダ構造を示します。

これは、「Visual Studio® .NET と Visual SourceSafe? を使用したチーム開発ガイド」の第 3 章です。全容を理解するには、こちらをご覧ください。

開発プロセスとビルドプロセスがチーム開発で効果的に機能するようにするには、すべての開発ワークステーションとビルドサーバーに渡って一貫性のある、正しいプロジェクト構造を使用して開始することが不可欠です。

この章では、以下の点に関するガイドラインについて説明します。

Microsoft® Visual Studio® .NET のソリューションとプロジェクトの分割。
ローカルファイルシステムと Microsoft Visual SourceSafe? (VSS) のフォルダ構造の管理。
プロジェクト、アセンブリおよび名前空間の名前付け規則の適用。

Visual Studio .NET のソリューションとプロジェクト

Visual Studio .NET のソリューションとプロジェクトを組織化する方法について説明する前に、ソリューションとプロジェクトの基本的なメカニズム、およびそれらをソース管理プロバイダ、通常 VSS によって、ローカルに管理する方法を理解することが重要になります。

既に Visual Studio .NET のソリューションとプロジェクトの知識があり、プロジェクト全体を構成するさまざまなファイルの種類を理解している場合は、このセクションを省略して、「ソース管理操作に Visual Studio .NET を常時使用する」に進むことができます。

Visual Studio .NET のプロジェクト

Visual Studio .NET は、 .NET アセンブリを生成するのに必要なすべてのビルド設定と構成設定のコンテナとしてプロジェクトファイルを使用します。プロジェクトファイルには、プロジェクトの言語に応じて、.csproj または .vbproj というファイル拡張子のいずれかが付いています。さまざまなプロジェクトの種類、および関連する迅速なアプリケーション開発 (RAD) 用のテンプレートがありますが、これらは大きく 2 つのカテゴリに分類できます。プロジェクトの種類の 2 つのカテゴリは以下のとおりです。

Web プロジェクト。 Web プロジェクトは、HTTP (Hypertext Transfer Protocol) の場所 (たとえば、http://localhost/MyWebProject) に作成されるプロジェクトです。 Web プロジェクトには、Web ブラウザにコンテンツを配信するために使用する ASP.NET Web アプリケーション、および主にインターネット経由でのデータの統合に使用する ASP.NET Web サービスがあります。
Web 以外のプロジェクトまたはローカルプロジェクト。 Web 以外のプロジェクトまたはローカルプロジェクトは、ファイルシステムの場所 (たとえば、C:\Projects\MySystem\MySolution\ MyWinProject) に作成されます。
最も一般的なローカルプロジェクトの種類は Windows アプリケーションとクラスライブラリですが、サービス、コンソールアプリケーション、データベースプロジェクトなど、多くのプロジェクトがあります。

Visual Studio .NET のソリューション

(.sln というファイル拡張子の付いた) ソリューションファイルは、互いに関連するプロジェクトをグループ化するためにも使用できますが、主にビルドプロセスを制御するために使用します。ソリューションを使用して、ビルドの依存関係の問題を制御でき、含まれているプロジェクトをビルドする正確な順番を制御できます。

重要プロジェクトは 1 つ以上のソリューションの一部になることがありますが、ソリューションを別のソリューションに含めることはできません。

図 3.1 では、ソリューションとプロジェクトの関係を示し、ソリューションとプロジェクトのレベルの設定を管理するために VSS が使用するファイルの種類を示しています。

ms998208.tdlg03(ja-jp,MSDN.10).gif

図 3.1.Visual Studio .NET のプロジェクトとソリューション

ソリューションとビルドの依存関係

ソリューションファイルには、ビルドプロセスが使用するプロジェクトの依存情報も含まれています。たとえば、上図において、依存情報はプロジェクト A がプロジェクト B に依存し、プロジェクト B がプロジェクト C に依存していることを示しています。結果として、プロジェクト C、プロジェクト B、プロジェクト A の順にビルドされる必要があります。単一のソリューション内部でプロジェクト参照を使用すると、 Visual Studio .NET が正しいビルドの順序を保証します。

重要基本的な参照の種類には、プロジェクト参照とファイル参照という 2 種類の参照があります。 Visual Studio .NET で [参照の追加] ダイアログボックスを使用して、両方の種類の参照を設定します。プロジェクト参照は、ビルド順序の依存関係も確立するので、できる限りこの参照を使用する必要があります。詳細については、第 4 章「依存関係の管理」の「アセンブリの参照」を参照してください。

ソース管理の対象となるファイル

以下の一覧では、Visual Studio .NET 統合開発環境 (IDE) を使用してソリューションをソース管理に追加するときに、 VSS に自動的に追加される主要なファイルの種類を示しています。

ソリューションファイル (*.sln)。このファイル内に保持される主要な項目には、構成プロジェクトの一覧、依存情報、ビルド構成の詳細およびソース管理プロバイダの詳細があります。
プロジェクトファイル (*.csproj または *.vbproj)。このファイル内に保持される主要な項目には、アセンブリのビルド設定、(名前とパスによって) 参照されるアセンブリ、およびファイル一覧があります。
アプリケーション構成ファイル。これは、プロジェクトの実行時の動作のさまざまな側面を制御するために使用する XML (Extensible Markup Language) に基づいた構成ファイルです。

注意 Web アプリケーションの場合は、ソース管理される構成ファイルは Web.config と呼ばれます。 Web アプリケーション以外のアプリケーションの場合は、ソース管理されるファイルは app.config と呼ばれ、プロジェクトフォルダに含まれます。 Visual Studio .NET のビルドシステムは、実行時に App.config を Bin フォルダにコピーし、その名前を Yourappname.exe.config に変更します。

Web アプリケーション以外のアプリケーションの場合は、構成ファイルは新しいプロジェクトに自動的に追加されません。構成ファイルが必要な場合は手動で追加します。そのファイルが App.config という名前で、プロジェクトフォルダ内に存在するようにします。

ソースファイル (*.cs、*.vb、*.aspx、*.asax、*.resx、*.vsdisco、*.css など)。すべてのプロジェクトソースファイルはソース管理の対象になります。

ソース管理の対象とならないファイル

以下のファイルは、開発者固有のファイルなので、ソース管理には追加されません。

ソリューションユーザーオプションファイル (*.suo)。このファイルには、各開発者が IDE に行ったカスタマイズが含まれています。
プロジェクトユーザーオプションファイル (*.csproj.user または *.vbproj.user)。このファイルには、開発者固有のプロジェクトオプション、および参照されるアセンブリを設定するために IDE が使用する任意の参照パスが含まれています。第 4 章「依存関係の管理」の「アセンブリの参照」セクションでは、チーム環境でアセンブリ参照を管理する方法について説明しています。
WebInfo ファイル (*.csproj.webinfo または *.vbproj.webinfo)。このファイルは、プロジェクトの仮想ルートの場所を記録しています。このファイルはソース管理に追加されないので、各開発者は作業用にコピーした独自のプロジェクトにさまざまな仮想ルートを指定できるようになります。ただしこの機能があっても、Web アプリケーションを開発する場合は、一貫性がある (ローカルな) 仮想ルートの場所を使用することをすべてのチームメンバにお勧めします。 Web アプリケーションおよびそれ以外のアプリケーションの推奨する構造については、「ソリューションとプロジェクトに一貫性のあるフォルダ構造を使用する」で説明します。
アセンブリ DLL (ダイナミックリンクライブラリ)、相互運用アセンブリ DLL、および実行可能ファイルなどのビルド出力。ただし、システムのビルドプロセスの一環としてビルドされない外部システムのアセンブリ (サードパーティのコントロールやライブラリ) を参照するプロジェクトの内部の VSS にそのアセンブリを追加することを推奨していることに注意してください。詳細については、第 4 章「依存関係の管理」の「外部システムのアセンブリをプロジェクトに含める」を参照してください。

ソース管理操作に Visual Studio .NET を常時使用する

VSS 内でのすべてのプロジェクトの作成と操作は、 Visual Studio .NET 内に統合された VSS のサポートメニューを使用することによって実行する必要があります。ここでは、VSS エクスプローラを使用しません。 Visual Studio .NET の機能は、以下のことを保証します。

適切なファイルのみをソース管理に追加します。
適切な VSS の詳細情報を使用して、 Visual Studio .NET のプロジェクトファイルとソリューションファイルを更新します。たとえば、Visual Studio .NET 内の VSS 機能は、 (数ある項目の中でも) 以下の情報を使用して、ソリューションファイル (.sln) を更新します。
- ソース管理下にある、ソリューション内のプロジェクトの数 (この数にはソリューション自体も含まれます)
- 各プロジェクトの VSS サーバー
- 各プロジェクトのサーバー上の場所
- 各プロジェクトのソース管理プロバイダの名前
- ソリューションファイルに関連する各プロジェクトの場所

ソリューションユーザーファイル (.suo) とプロジェクトファイル (.csproj or .vbproj) などその他のファイルも更新されます。

重要 VSS エクスプローラではなく、常に Visual Studio .NET のインターフェイスを使って VSS と対話します。製品の緊密な統合によって、ファイルがチーム環境で正しく管理されるようになります。

ソリューションとプロジェクトの分割

ソリューションとプロジェクトを分割する方法は、チーム環境での開発作業とビルドプロセスに大きく影響します。

ソリューションとプロジェクトを分割するために検討する 3 つの主要なモデルがあります。以下にこのモデルをよく使用される順に示します。

単一ソリューションモデル
パーティション分割した単一ソリューションモデル
複数ソリューションモデル

重要正当な理由がある場合を除いて、複数ソリューションモデルの使用を避け、単一ソリューションモデル、または大規模システムでのパーティション分割した単一ソリューションモデルを導入する必要があります。単一ソリューションモデルとパーティション分割した単一ソリューションモデルは、使用が簡単であり、複数ソリューションモデルよりも多くの重要な利点を提供します。これについては、以下のセクションで説明します。

できる限り、単一ソリューションモデルを使用する

単一ソリューションモデルでは、 Visual Studio .NET のソリューションを 1 つだけ作成し、アプリケーションが定義するすべてのプロジェクトのコンテナとして使用します。単一ソリューションモデルを使用する場合、以下のことに注意してください。

あるプロジェクトが別のプロジェクトによって生成されたアセンブリを参照する必要がある場合、プロジェクト参照を使用します。
ファイル参照を使用して、残りのシステムでビルドされない外部システムのアセンブリ (.NET Framework アセンブリやサードパーティのアセンブリなど) だけを参照する必要があります。

ms998208.tdlg04(ja-jp,MSDN.10).gif

図 3.2.単一ソリューションモデル

単一ソリューションモデルには多くの重要な利点があるので、できる限りこのモデルを使用します。

利点

単一ソリューションモデルには、以下の利点があります。

個別のプロジェクトが生成した別のアセンブリを参照する必要がある場合、プロジェクト参照を使用できます。プロジェクト参照は、別のアセンブリへの参照を確立するのに好ましい方法で、チーム環境のすべての開発ワークステーションで機能することが保証されています。プロジェクト参照の多くの利点、およびファイル参照使用時の指示については、第 4 章「依存関係の管理」の「アセンブリの参照」で説明します。
参照されるアセンブリのクライアントをいつリビルドする必要があるかを Visual Studio .NET が検出するので、アセンブリのバージョン管理の問題は回避されます。
プロジェクト参照は、参照されるプロジェクトの構成の変更に反応します。これは、参照の再設定を必要とせずに、デバッグおよびリリースのビルドからプロジェクトにまたがって自動的に切り替えられることを意味しています。
システムのビルドプロセスとビルドスクリプトが大幅に単純になります。

問題点

できる限り、単一ソリューションモデルを導入することをお勧めします。ただし、以下の問題点があります。

このモデルは規模が大きくなります。ソリューション内で単一プロジェクトを使って作業する場合、ソリューション内にすべてのプロジェクト用のすべてのソースコードを取得する必要があります。
プロジェクトの依存関係により、 1 つのプロジェクト内の 1 つのソースファイルに対するあまり重要ではない変更でも、結果としてソリューション内の多くのプロジェクトをリビルドすることになります。参照するプロジェクト内でアセンブリのインターフェイスが変更された場合、クライアントプロジェクトをリビルドしようとします。ただし、特に多くのプロジェクトを含むソリューションでは、不要なリビルドにかなりの時間を費すことがあります。

大規模システム向けにパーティション分割した単一ソリューションモデルを検討する

各開発ワークステーションで必要なプロジェクトとソースファイルの数を少なくしたい大規模システムでは、個別のサブソリューションファイル内に関連するプロジェクトをまとめてグループ化することを検討します。

この結果、開発者は内部システム境界内の独立した小規模サブシステムで作業できるようになります。

注意単一プロジェクトファイルを、 1 つ以上のソリューションファイルに含めることができます。ソリューションを別のソリューションに含めることはできません。

図 3.3 では、パーティション分割した単一ソリューションモデルを示しています。独立したソリューションファイルを使用して、内部システム境界内に含まれる小規模サブシステムで作業できるようにする方法に注意してください。また、この結果として 1 つ以上のソリューションファイルに含まれるプロジェクトになる方法にも注意してください。たとえば、プロジェクト D とプロジェクト H は、マスタソリューションを含む合計 3 つのソリューションファイルに存在します。

ms998208.tdlg05(ja-jp,MSDN.10).gif

図 3.3.パーティション分割した単一ソリューションモデル

パーティション分割した単一ソリューションモデルでは、以下のことが行われます。

すべてのプロジェクトがマスタソリューションファイルに含まれます。システムのビルドプロセスがこのマスタソリューションファイルを使用し、システム全体をリビルドします。プロジェクトファイルの最上位レベルで作業する必要がある場合、マスタソリューションを使用して作業します。
各プロジェクト間でプロジェクト参照を使用します。
選択されたプロジェクトファイル用に独立したソリューションファイルが導入されます。これを希望する場合、システム内のプロジェクトごとにソリューションファイルを導入できます。各ソリューションファイルはメインプロジェクトファイルと、互いに依存関係にある下位プロジェクト、さらにのその下位プロジェクトというように、下位方向に向かう依存チェーンを保持します。
独立したソリューションファイルによって、全体的なシステム内の小規模サブシステムで作業できるようになり、その上プロジェクト参照の主要な利点を保持できます。各サブソリューションファイル内では、構成するプロジェクト間でプロジェクト参照を使用します。

注意互いに参照しあう 2 つのプロジェクトを独立したソリューションに分割すべきではありません。これは、不要なファイル参照を使用することになります。不要なファイル参照はできる限り避ける必要があります。詳細については、第 4 章「依存関係の管理」の「アセンブリの参照」を参照してください。

利点

パーティション分割した単一ソリューションモデルには、以下の利点があります。

小規模サブシステムで作業できます。すべての開発ワークステーション上にシステム全体のソースコードとプロジェクトファイルを必要としません。結果として、Visual Studio .NET のソリューションエクスプローラが雑然とすることがなくなり、容易に使用できるようになります。
各ソリューション内でプロジェクト参照を使用できます。
マスタソリューションによって、システム全体を簡単にリビルドできるようになります。マスタソリューションファイルは、ビルドサーバー上のビルドプロセスが使用します。

問題点

パーティション分割した単一ソリューションモデルには、以下の問題点があります。

新しいプロジェクトを追加すると、潜在的にそのプロジェクトを追加することになり、マスタソリューションファイルや 1 つ以上の別のソリューションファイルなど、複数のソリューションファイル内のすべてのプロジェクト参照を更新する必要があります。
システムを分割する方法が制限されます。これは、プロジェクトの依存関係に起因するものです。結果として、たとえば、プレゼンテーション層内の ASP.NET Web アプリケーションなどの最上位レベルのプロジェクトで作業する場合、依存するすべてのプロジェクトを開発ワークステーションにコピーする必要があります。これには、ビジネス層やデータ層のプロジェクトも含まれることがあります。これに対して、依存性がほとんどないクラスライブラリやデータアクセスコンポーネントの開発作業を行う場合は、個別のプロジェクトだけを必要とします。

確実に必要な場合のみ、複数ソリューションモデルを使用する

複数ソリューションモデルは、以下の点を除いて、パーティション分割した単一ソリューションモデルと同じです。

マスタソリューションファイルがありません。
独立したソリューション内のプロジェクト間でファイル参照を使用します (ただし、依然として各ソリューション内のプロジェクト間でプロジェクト参照も使用されます。)
ビルドサーバー上で実行するシステムのビルドスクリプトは、既知の依存関係に基づいて、各ソリューションを順番にビルドします。ビルドスクリプトは、出力アセンブリをビルドサーバー上の固定的な場所に格納します。

図 3.4 は、複数ソリューションモデルを示しています。

ms998208.tdlg06(ja-jp,MSDN.10).gif

図 3.4.複数ソリューションモデル

利点

複数ソリューションモデルは、パーティション分割した単一ソリューションモデルよりも以下の点で優れています。

各プロジェクトは単一のソリューションだけに含まれます。これは、プロジェクトをシステムに追加したり、システムから削除することが簡単であることを意味します。
論理的な境界に基づいてシステムを複数のソリューションに再分割できるので、プロジェクトの依存関係による影響を受けません。たとえば、ビジネス機能の分野に基づいた分割を選択する場合があります。

問題点

複数ソリューションモデルには、以下の問題点があります。

独立したソリューション内のプロジェクトが生成したアセンブリを参照する必要があるとき、ファイル参照を使用する必要があります。 (プロジェクト参照とは異なる) この参照は、自動的にビルドの依存関係をセットアップしません。これは、システムのビルドスクリプト内のソリューションのビルド順序の問題を解決する必要があることを意味します。これを管理することはできますが、ビルドプロセスに特別な複雑性が加わります。
DLL の特定の構成ビルド (たとえば、製品版やデバッグ版) を参照することに注目する必要もあります。 Visual Studio .NET では、プロジェクト参照が自動的にこの参照を管理し、現在アクティブな構成を参照します。
単一ソリューションを使って作業するとき、別のチームメンバが開発した (おそらく、別のプロジェクトにある) 最新のコードを入手して、ローカルな統合テストを実行することがあります。次のシステムのビルドに備えて VSS にコードをチェックインする前に、何も問題がないことを確認できます。以前のシステムのビルド結果を使用してのみ、他のソリューションに対して独自のソリューションをテストできるので、複数ソリューションシステムでは、この作業がはるかに困難になります。

10、20、または 30 ものプロジェクトを含む単一ソリューションを使用して簡単に作業できるべきです。 1 つのソリューション内で実行できるプロジェクトの最大数は、ビルドサーバーと開発ワークステーションの仕様、および個別のプロジェクトに関連付けられたソースファイルのサイズと数によって決まるので、正確に定義するのは困難です。

プロジェクトをソリューションにグループ化する際に考慮する点

プロジェクトをソリューションにグループ化するときの問題を解決する最善の方法は、アプリケーションの全体的なアーキテクチャを考慮することです。たとえば、以下のことを考慮します。

システム内で構成するアセンブリ (またはコンポーネント) の識別から始めます。これは、システムに必要な各プロジェクトを定義することです。各アセンブリは、Visual Studio .NET の独立したプロジェクトによって生成されることを覚えておいてください。
単一ソリューションモデルを目標にします。プロジェクトを分割し、さらに上位レベルの分離や制御を提供する場合は、パーティション分割した単一ソリューションモデルを使用できます。中間層ビジネスコンポーネントなど、分離して作業するプロジェクトのグループを考慮し、それに応じて個別のソリューションを作成します。

プロジェクトを複数のソリューションに分割し、パーティション分割した単一ソリューションモデルを使用して、この操作を実行できない場合、ソリューション間の依存関係、および 2 つの依存するアセンブリを分割するインターフェイスの性質を慎重に検討します。プロジェクトを別のソリューションに組織化する場合、以下の項目に従う必要があります。

システムの構成部分を分割する外部インターフェイスを識別します。変更する可能性が最も低い外部インターフェイスを識別するように努めます。あるプロジェクトが公開するインターフェイスが頻繁に変更される場合、原則的に依存するすべてのプロジェクトを同じソリューションに配置する必要があります。
XML Web サービスを使用して、システムの一部のコンポーネントを互いに接続している場合、 XML Web サービスのインターフェイスは優れた分割位置を提供します。たとえば、XML Web サービスインターフェイスのクライアント側のプロジェクトとサーバー側のプロジェクトは、独立したソリューションにする優れた候補です。

ソリューションとプロジェクトに一貫性のあるフォルダ構造を使用する

Visual Studio .NET のソリューションとプロジェクトを格納するために共通の構造を使用すると、チーム開発環境での作業は大幅に容易になります。これを均整が取れたものにする (結果として、より単純にする) には、ローカルファイルシステムの構造と一致するフォルダ構造を VSS 内にセットアップします。

共通のルートフォルダを定義する

共通のルートフォルダ、たとえばファイルシステムに C:\Projects を、 VSS 内に $/Projects を定義します。これが、すべての開発システムのコンテナとして機能します。

共通のルートフォルダの下にシステムごとのシステムルートフォルダ、たとえば C:\Projects\MyCompanysInsuranceApp と $/Projects/MyCompanysInsuranceApp をそれぞれ作成します。

ソリューションとプロジェクト用に親子構造のフォルダを採用する

ソリューションとプロジェクト用に親子構造のフォルダを採用すべきです。このため、以下のことを行います。

Visual Studio .NET のソリューションのシステムルートフォルダの下にサブフォルダを作成します。
ソリューションフォルダの下に構成プロジェクトごとに新たな子サブフォルダを作成します。
Web アプリケーションとそれ以外のアプリケーションにこの共通構造を採用します。
Bin フォルダとそのコンテンツは VSS に追加しません。

注意パーティション分割した単一ソリューションモデルを使用する場合、メインソリューションファイルを含むフォルダの下にプロジェクトフォルダをセットアップします。作成するすべてのサブソリューションの場合は、この場所から直接プロジェクトファイルを含めます。

図 3.5 は、推奨構造を例示しています。

ms998208.tdlg07(ja-jp,MSDN.10).gif

図 3.5.Visual Studio .NET と VSS のフォルダ構造

以下のサブセクションでは、 Visual Studio .NET IDE を使用して、 Web アプリケーションおよびそれ以外のアプリケーションに適切な構造を作成する方法について説明します。

新しい ASP.NET Web プロジェクトの作成方法

新しい ASP.NET Web アプリケーションを作成すると、特に指定しない限りプロジェクトファイルが既定の Web サイト (通常、\inetpub\wwwroot) の下の指定された仮想ルートに配置され、関連するソリューションファイルが \My Documents\Visual Studio Projects の下に配置されます。この既定の配置は、VSS プロジェクトとローカルファイルの間の均整が取れた構造を壊すので、チーム開発環境では理想的ではありません。

以下の手順では、推奨するソリューションとプロジェクトのフォルダ構造に従った、新しい ASP.NET Web アプリケーションの作成について説明します。手順では、MyWebAppSolution という名前のソリューションと MyWebApp という名前のプロジェクトを使用します。

ソリューション名に Solution (または Soln) という単語を含めると、その名前がプロジェクト名ではないことを明確にするのに役立ちます。

望ましい構造を、図 3.6 に示します。プロジェクトフォルダと Microsoft Internet Information Server (IIS) 仮想ルートがまったく同じであることに注意してください。

ms998208.tdlg08(ja-jp,MSDN.10).gif

図 3.6.推奨する Web アプリケーション構造

この構造を使用して新しい Web アプリケーションを作成するには、以下の手順に従います。

Visual Studio .NET を起動して、 [ファイル] メニューの [新規作成] をポイントし、 [空のソリューション] をクリックします。
ソリューション名として「MyWebAppSolution」と入力して、その場所を「\Projects\MySystem」に設定します。
[OK] をクリックします。 Visual Studio .NET が指定したルートフォルダの下に MyWebAppSolution フォルダを作成します。
Windows エクスプローラを使用して、 \Projects\MySystem\MyWebAppSolution フォルダの下に MyWebApp という新しいサブフォルダを作成します。
Windows エクスプローラまたはインターネットサービスマネージャのいずれかを使用して、 MyWebApp フォルダを IIS 仮想ルートとして確立します。
注意 Visual Studio .NET では、仮想ルート名がプロジェクトフォルダ名と一致している必要があります。
Visual Studio .NET に戻り、 [ファイル] メニューの [プロジェクトの追加] をポイントして、 [新しいプロジェクト] をクリックします。
ASP.Net Web アプリケーションプロジェクトを追加します。
[場所] ボックスに「http://localhost/MyWebApp」と入力して、[OK] をクリックします。プロジェクトと Web ソースファイルが指定した仮想ルートに作成されます。

Web アプリケーションを複数のプロジェクトに分割する方法

場合によっては、同じソリューション内で Web アプリケーションを複数のプロジェクトに分割し、チーム開発を円滑に行いたいことがあります。たとえば、同じ Web アプリケーションのさまざまな側面をそれぞれ個別のチームが担当する場合、アプリケーションを複数のプロジェクトに分割できると便利です。この機能は、本来 Visual Studio .NET ではサポートされていませんが、手動による仮想ルートの操作によって実現できます。

重要単一プロジェクトアプローチの方が単純なので、やむ得ない場合のみ Web アプリケーションを複数のプロジェクトに分割します。一般的には、非常に大規模の Web アプリケーションの場合に分割を行います。

ASP.NET コードビハインドファイルを使用して作業する

Web フォーム (aspx) ファイルまたはコードビハインドファイル (aspx.cs または aspx.vb) のいずれかをチェックアウトすると、Visual Studio .NET が自動的に両方のファイルをチェックアウトすることに気がつきます。一般的に、ユーザーインターフェイスの変更はコードビハインドファイルのコーディングに関係しますので、このことは仕様です。

たとえば、新しいコントロールを Web フォームに追加する場合、 Visual Studio .NET は、コードビハインドファイルにコントロールのメンバ変数を自動的に作成します。

Web プロジェクト以外の新しいプロジェクトを作成する方法

以下の手順では、 Windows ベースのアプリケーションやコンソールアプリケーション、クラスライブラリやサービスなど Web プロジェクト以外の新しいプロジェクトの作成について説明します。手順では、MyWinAppSolution という名前のソリューションと MyWinApp という名前のプロジェクトを使用します。望ましい構造を図 3.7 に示します。

ms998208.tdlg09(ja-jp,MSDN.10).gif

図 3.7.Web プロジェクト以外の推奨プロジェクト構造

この構造を使用して Web アプリケーション以外の新しいアプリケーションを作成するには、以下の手順に従います。

Visual Studio .NET を起動して、 [ファイル] メニューの [新規作成] をポイントし、 [プロジェクト] をクリックします。
適切なプロジェクトの種類とテンプレートを選択します。
[名前] ボックスにプロジェクト名 (ここでは、MyWinApp) を入力します。
[場所] ボックスに「\Projects\MySystem」と入力します。
[詳細] をクリックします。
[ソリューションのディレクトリを作成] チェックボックスをオンにします。この結果、プロジェクトファイルはソリューションフォルダの下のプロジェクトサブフォルダに作成されます。
[新しいソリューション名] ボックスに「MyWinAppSolution」と入力します。
[OK] をクリックして、プロジェクトとソリューションの作成プロセスを完了します。

新しく作成されたプロジェクトとソリューションを Visual SourceSafe に追加する方法の詳細については、第 6 章「Visual SourceSafe? を使用した作業」の「新しいソリューションを VSS にチェックインする方法」を参照してください。

名前付け規則を慎重に検討する

プロジェクト、アセンブリ、フォルダおよび名前空間に名前を付ける方法を慎重に、かつ早い段階に検討します。開発サイクルでこれらの項目の名前を後から変更できますが、できるだけこれは避けるべきです。プロジェクト名の変更方法の詳細については、第 6 章「Visual SourceSafe を使用した作業」の「プロジェクト名の変更」を参照してください。

一貫性のある名前のセットはプロジェクトの組織を単純化できるので、一貫性のある名前のセットを目標とすべきです。

プロジェクトとアセンブリに共通の名前を使用する

出力アセンブリの名前は、このアセンブリを生成するプロジェクトの名前と常に一致させます。たとえば、MyCompany.Utilities.Data.dll という名前のアセンブリは、 MyCompany.Utilities.Data という名前のプロジェクトが生成すると想定できるようにします。

出力アセンブリの名前を変更する場合、プロジェクト名も変更して名前を一致させることを検討します。逆も同様です。

共通のルート名前空間名を使用する

型 (構造体、クラス、インターフェイスなど) を配置するルート名前空間は、プロジェクトとアセンブリの名前と一致させるべきです。

たとえば、MyCompany.Utilities.Data.dll アセンブリ内のルート名前空間として MyCompany.Utilities.Data を使用します。

.NET ではこの調整は必須ではありませんが、どの型がどのアセンブリに存在するか説明することが容易になるので、名前を一致させることには意味があります。

注意 Microsoft Visual Basic® .NET のプロジェクトは、プロジェクトのプロパティを使ってルート名前空間を公開します。既定では、Visual Basic プロジェクト内で作成されるすべての型がこの名前空間の内に配置されます。 Visual Basic .NET プロジェクトで明示的に namespace ステートメントを使用すると、ルート名前空間のエントリを削除します。それ以外の場合は、明示的な名前空間名をルート名前空間名に追加します。

C# プロジェクトは、プロジェクトのプロパティを使って既定の名前空間のプロパティを公開します。このプロパティを再度使用して、プロジェクトに追加された新しい型が配置される名前空間を決定します。ただし、Visual Basic .NET のプロジェクトとは異なり、ルート名前空間は、ソースファイル内で namespace ステートメントを使って明示的に宣言されます。

VSS フォルダとローカルフォルダに共通の名前を使用する

上記のように、対応する VSS フォルダ名とローカルのソリューションフォルダ名やプロジェクトフォルダ名を同期させます。

これは、「Visual Studio .NET と Visual SourceSafe を使用したチーム開発ガイド」の第 3 章です。続いて、第 4 章「依存関係の管理」を参照してください。

ページのトップへ

この情報は役に立ちましたか。はいいいえ

不正確

内容が浅い

もっとコード例が必要

翻訳品質の向上が必要

(残り 1500 文字)