Visual Studio .NETによるチーム開発事始め 効率のよいソース管理を実現しようデジタルアドバンテージ2004/03/10 |
|
|
2. VS.NET 2003の新機能「ソリューション・ルート」
これまでのソース管理の例では、すべてVS.NET 2002+VSS 6.0cを使ってきた。そのため、最新のVS.NET 2003+VSS 6.0dでの機能と若干違う部分があることに気付いた賢明な読者もいらっしゃるだろう。その違いはVS.NET 2003で追加された新機能にある。ここでは、その機能について明らかにする。なお、ここで紹介する機能以外のVSS 6.0cから6.0dへの変更点については、マイクロソフトのサポート技術情報「[INFO] Visual SourceSafe 6.0d で修正された問題の一覧」で明記されているので、詳しく知りたい場合はこちらを参考にしていただきたい。
VS.NET 2003によるソース管理がVS.NET 2002のそれと異なる点は、VSSデータベースにソリューションを追加したときに「<ソリューション名>.root」というフォルダがVSSデータベース上に自動的に作成されることである。これは「ソリューション・ルート(Solution Root)」と呼ばれるフォルダで、VS.NET 2003で新たに導入された機能の1つである。このソリューション・ルート機能に対応しているソース管理プロバイダは「VSS 6.0d」以降なので、使用に際しては必ずVS.NET 2003+VSS 6.0dという組み合わせが必要である。
ソリューション・ルート機能は簡単にいうと、「ソリューション・ルート」と呼ばれる1つのフォルダの下に、ソリューションに含まれるすべてのプロジェクトを集める機能である。しかも、プロジェクトを集めるときにファイル・システムのフォルダ構造を維持する。よって、ソリューション内のすべてのプロジェクトを、ソリューション単位でまとめて管理できるようになるだけでなく、VSSデータベースとファイル・システムのフォルダ構造を並列・対等の関係で管理できるようになる。
このソリューション・ルート機能について、実際の例を挙げて説明していく。例に使用するのは、これまで本連載で使用してきた「BlogX」というVS.NETソリューションである。まず次の図は「VS.NETのソリューション・エクスプローラ上のフォルダ構造」と「ファイル・システム上のフォルダ構造」を横に並べたものだ。
ソリューション・エクスプローラとファイル・システムのフォルダ構成 |
「BlogX」というソリューションに7個のプロジェクトが追加されている。この中で「WeblogX」はWebプロジェクトであり、実際のファイル・システム上では「BlogX」ソリューション・フォルダの中ではなく別の場所(IISのwwwrootフォルダの中)にある。 |
なお、この図のファイル・システムのように、ソリューションの下にプロジェクトを追加するには、必ず「空のソリューション」を作成して、そのソリューションにプロジェクトを追加する必要がある。例えば上図の例では、まず「BlogX」で空のソリューションを作成して、その後で「BlogCmd」「BlogXRuntime」など個別のプロジェクトをそのソリューションに追加している。
もし空のソリューションを作成せずに、プロジェクトの作成時にソリューションまで作成してしまうと、プロジェクトとソリューションが同じフォルダになってしまう。例えば、BlogXでプロジェクトを作れば、ソリューション「BlogX」のフォルダも、プロジェクト「BlogX」のフォルダも同一フォルダになってしまう。これでは適切にソリューションとプロジェクトを分けて管理することができない。
上の図では、「BlogX」というソリューションがあって、そこに7個のプロジェクトが含まれている。そして、実際のファイル・システム上でもそのソリューションの下にプロジェクトがある。しかし、Webアプリケーションの「WeblogX」プロジェクトだけは違う場所(IISのwwwrootフォルダの下)にある。
このファイル・システムの構成のソリューションを、VSSデータベースに追加したのが以下の図である。この図では、VS.NET 2002+VSS 6.0dとVS.NET 2003+VSS 6.0dの場合の「VSSデータベース上のフォルダ構造」を比較している。ちなみに、この「VSSデータベース」のような「ソース管理用のデータベース」は、一般的に「リポジトリ(Repository)」と呼ばれる。ソース管理関連の文献で必ず出てくる単語なので、覚えておくとよいだろう。
VS.NET 2002と2003におけるVSSデータベース上のフォルダ構成の比較 |
VS.NET 2002では、任意の位置にソリューションやWebプロジェクト「WeblogX」が追加されている。なお、「WeblogX」が「BlogX」の下にあるのは追加する位置を手動で指定したためである(これについては以前の記事で解説した)。一方、VS.NET 2003のVSSデータベースでは、ソリューション・ルートが先頭に追加され、その下にソリューションやWebプロジェクトが追加されている。 |
VS.NET 2002のVSSデータベースの場合、Webプロジェクト(この例では「WeblogX」)はソリューションの下にはないため、そのまま追加するとソリューション(この例では「BlogX」)と同じレベルの位置に追加されてしまう。そのため、本稿では手動でソリューションの下にプロジェクトを追加するようにしていた(以前の記事を参照)。
一方、VS.NET 2003のVSSデータベースの場合、先頭にソリューション・ルートが追加されているので、「WeblogX」もそのソリューション・ルートの下に追加される。よって、ソリューション・ルートでソリューション全体を管理でき、しかもファイル・システムのフォルダ構造と同じになる。
このようにソリューション・ルートが導入されたことで、自動的にソリューション全体を管理できるようになり、しかも自動的にファイル・システムと同じフォルダ構造にすることが可能になった。このため、 VSSデータベース上のソリューションのフォルダ構造が分かりやすくなり、ソースの管理もしやすくなるだろう。
またVS.NET 2003+VSS 6.0dでプロジェクトを新たに追加する場合もプロジェクトはソリューション・ルートの下に自動的に追加されるので、VS.NET 2002のときのように手動でVSSデータベースのフォルダ位置を指定する必要がなくなった。よって、VS.NET 2003+VSS 6.0dでは[Visual SourceSafeに追加]ダイアログがまったく表示されないようになっており、ソース管理作業が軽減できる。
しかし、このようにソリューション・ルートによる自動処理でソース管理が便利になった反面、任意の位置にプロジェクトを追加できなくなり、自由度がなくなったという見方もできる。実際に、このソリューション・ルートの概念やファイル・システムとVSSデータベースのフォルダ構造を合わせるという考え方は素晴らしいものの、MSDNの「Visual Studio .NETとVisual SourceSafeを使用したチーム開発:ソリューションとプロジェクトの構造化」で推奨されているフォルダ構成とは合致していない。また、プロジェクト管理者が独自の考えに基づきフォルダ階層を設計する場合にも不向きである。
VS.NET 2003+VSS 6.0dの環境で任意のフォルダ構成を実現したい場合には、ソリューション・ルート機能を解除するしかない。これには、レジストリ・キー[HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\7.1\SourceControl]の値[DoNotCreateSolutionRootFolderInSourceControl]をデフォルト値の「0」から「1」に変更すればよい。この値が「1」の場合は、VSS6.0cと同様のモードで動作し、ソリューション・ルートを作成しないようになる。一方、「0」の場合はVSS6.0dの標準機能としてソリューション・ルートを作成する。この場合、ソリューション・ルート以下のプロジェクトのフォルダは自動作成されるので、フォルダの作成を手動でカスタマイズすることはできない。
このレジストリ項目を変更して、ソリューション・ルート機能を解除すると、Visual SourceSafe 6.0cと同じ動作に戻るため、プロジェクトをVSSデータベースに追加すると[Visual SourceSafeに追加]ダイアログが表示されるようになる。VS.NET 2003+VSS 6.0d環境で、本稿のこれまでのサンプルと同じよううなフォルダ構造を作成したい場合には、ソリューションをVSSデータベースへ追加する前に、このレジストリを変更していただきたい。なお、レジストリを変更する場合は、レジストリのバックアップも忘れずに実行しておくこと。
INDEX | ||
Visual Studio .NETによるチーム開発事始め | ||
効率のよいソース管理を実現しよう | ||
1.バッチ処理ファイルによる自動処理 | ||
2.VS.NET 2003の新機能「ソリューション・ルート」 | ||
3.ピン設定および共有/分岐について | ||
4.次期VS.NET“Whidbey”と同時リリースされる次期VSSの新機能 | ||
「Visual Studio .NETによるチーム開発事始め」 |
- 第2回 簡潔なコーディングのために (2017/7/26)
ラムダ式で記述できるメンバの増加、throw式、out変数、タプルなど、C# 7には以前よりもコードを簡潔に記述できるような機能が導入されている - 第1回 Visual Studio Codeデバッグの基礎知識 (2017/7/21)
Node.jsプログラムをデバッグしながら、Visual Studio Codeに統合されているデバッグ機能の基本の「キ」をマスターしよう - 第1回 明瞭なコーディングのために (2017/7/19)
C# 7で追加された新機能の中から、「数値リテラル構文の改善」と「ローカル関数」を紹介する。これらは分かりやすいコードを記述するのに使える - Presentation Translator (2017/7/18)
Presentation TranslatorはPowerPoint用のアドイン。プレゼンテーション時の字幕の付加や、多言語での質疑応答、スライドの翻訳を行える
|
|