3

この投稿をよく読みました: Visual Studio のソース管理統合は Perforce とどのように連携しますか? 非常に有益であることがわかりました。ただし、VS での Perforce の使用を妨げている特定の問題があります。

ほとんどの場合、プラグインについて不満はありません (新しいプラグインはチーム全体で変換する必要があるため、現時点では不可能なため、私はまだ P4VSCC プラグインを使用しています)。特異性を理解すると、プラグインの操作で 1 つだけ問題が発生しました。

当社のソリューションには、単一の展開パッケージに組み込まれた多くのプロジェクトが含まれています。そのため、各アセンブリは同じようにバージョン管理されます。これと他の一般的な側面に対応するために、AssemblyInfo.cs ファイルで通常見られる AssemblyVersion および AssemblyFileVersion 属性を含む共通の "SharedVersionInfo.cs" ファイルを定義しました。このファイルは、ソリューション フォルダーの下の Assets フォルダーに保存され、リンクされたファイルとして各プロジェクトの Properties フォルダーに追加されます。これは、バージョンを 1 か所で変更するだけですべてのアセンブリが更新されるため、バージョン管理の観点からはうまく機能します。ただし、Perforce には、新しい開発者が最初にソリューションを開いたとき、または新しいプロジェクトが追加されたときに、これに関する問題があります。

新しいプロジェクトを追加する場合、これはそれほど大きな問題ではありませんが、ソリューションには 80 個のプロジェクトが含まれているため (現在も増え続けています)、これは新しい開発者にとって実行可能な救済策ではありません!

私の理解では、この問題は、VS が各プロジェクトのバインディング ルートをどこにあると考えるかに関係しているということです。いくつかの調査の後、プロジェクトの MSSCCPRJ.SCC ファイルがどこにあるかを見つけました。ソリューション構造全体に多数の SCC ファイルが散在していることがわかりました。そう...

最初の質問: ソリューション構造に複数の MSSCCPRJ.SCC ファイルがあるのはなぜですか?

また、ソリューションで使用する共有/共通プロジェクトもいくつかあります。これにより、次のフォルダー構造になります。

/Source
    /CommonTools
        /ProjectA
            ProjectA.csproj
        /ProjectB
            ProjectB.csproj
    /MySolution
        /Assets
            SharedVersionInfo.cs
        /Project1
            Project1.csproj
        /Project2
            Project2.csproj
        :
        /ProjectZ
            ProjectZ.csproj
        MySolution.sln

ProjectA と ProjectB の両方が MySolution.sln の一部である場合

2 番目の質問: /Source フォルダーがルートと見なされるようにバインディングをセットアップするにはどうすればよいですか? これにより、ソリューションに含まれるすべてのプロジェクトが同じバインディング ルートの下にあることが保証されます。Perforce はこのフォルダをルートと見なしますが、VS とプラグインで同じことを行うにはどうすればよいですか?

4

1 に答える 1

0

他の誰も解決策を提案していないので、スレッドに出くわした他の人のために自分の調査結果をフォローアップしたいと思いました。

まず、Visual Studioが複数のMSSCCPRJ.SCCファイルを作成する理由はまだわかりませんが、これらはソリューションの「バインディングルート」を確立するための鍵です。ソリューション内のすべてのプロジェクトがこのファイルの場所に対してサブフォルダーに含まれるように、このファイルが必要な最高レベルに存在することが重要です。上記の例では、MSSCCPRJ.SCCを/Sourceフォルダーに配置する必要がありました。/ MySolutionフォルダーにあると、/CommonToolsからソリューションにプロジェクトを追加するときに元の問題が発生しました。

とはいえ、問題の解決は簡単な作業ではありませんでした。メモ帳の.slnファイルとすべての.csprojファイルを手動で編集する必要がありました。私が見つけたのは、いくつかの.csprojファイルには、ソース管理設定を識別する次の要素が含まれていることでした。

<SccProjectName>SAK</SccProjectName>
<SccLocalPath>SAK</SccLocalPath>
<SccAuxPath>SAK</SccAuxPath>
<SccProvider>SAK</SccProvider>

SAKが何の略かはわかりませんが、これはVisualStudioに.slnファイルに含まれているバインディング情報を使用するように指示していることを理解しています。

これらを次のように変更する必要がありました。

<SccProjectName>Perforce Project</SccProjectName>
<SccLocalPath>..\..</SccLocalPath>
<SccAuxPath />
<SccProvider>MSSCCI:Perforce SCM</SccProvider>

ここで、SccLocalPath値は、.csprojファイルからMSSCCPRJ.SCCファイルへの相対パスです。

また、.slnファイル内の各プロジェクトのSccLocalPathXステートメントとSccProjectFilePathRelativizedFromConnectionXステートメントを変更する必要がありました。SccLocalPathX値は、.slnファイルからMSSCCPRJ.SCCファイルへの相対パス（同じフォルダー内の場合はドット（。））である必要があります。SccProjectFilePathRelativizedFromConnectionXは、バインディングルートから.csprojファイルへの相対パスである必要があります。

それが整っていれば、これらの手順を繰り返す必要はなかったと言えます。残念ながら、ソリューションに新しいプロジェクトを追加するたびに、修正を加える必要があります。Visual Studioは、.csprojファイルの要素にSAKを使用したいので、.slnファイルの値が正しくない場合があります。

しかし、少なくとも私は自分の目標を達成するために何を探すべきか、そして何をする必要があるかを知っています。これらの設定が事前に正しく作成されるように、VSやPERFORCEを構成するためのより良いソリューションや方法を他の誰かが持っている場合は、喜んでクレジットを提供します。

お役に立てば幸いです...

于 2012-09-27T11:52:52.027 に答える