Visual Studio は、ソリューションのサブフォルダーではないディレクトリにプロジェクトを保存することについて警告します。
ソース管理に追加しようとしているプロジェクトが原因で、他のソース管理ユーザーがこのソリューションを開いたり、新しいバージョンを取得したりすることが困難になる場合があります。この問題を回避するには、ソリューション内の他のソース管理プロジェクトのバインディング ルートの下の場所からプロジェクトを追加します。
共有プロジェクトはこの制約にどのように適合しますか? EGギブン
$\BranchName\Project1Name\Project1.sln
$\BranchName\Project2Name\Project2.sln
どこに置けますか
MyCompany.DataLayer.proj?
いくつかの調査の後、オプションは基本的に 2 つのオプションに要約されます。
- 共有の場所からコードを参照する
- 共有コードを分岐する
共有場所:
このアプローチでは、別のチーム プロジェクトなどの共有の場所から開発用コンピューターのワークスペースにソースをマップします。これにより、共有の場所からの共有ソースを開発用コンピューター上のプロジェクト コードと統合する構成が作成されます。
このアプローチの利点は、ワークスペースにソースの最新バージョンを取得するたびに、共有ソースへの変更が取得されることです。たとえば、共有ソースを含む Common という名前のチーム プロジェクトについて考えてみます。この場所からコードを参照するには、両方のチーム プロジェクトを開発用コンピューターの共通パスの場所にマップします。
分岐
このアプローチでは、共有コードを共通のチーム プロジェクトから自分のチーム プロジェクトに分岐します。これにより、共有の場所とプロジェクトからのソースを統合する構成も作成されます。
このアプローチとの違いは、共有ソースの変更がブランチ間のマージ プロセスの一部として取得されることです。これにより、共有ソースの変更を取得するという決定がより明確になります。いつマージを実行して最新の変更を取得するかを決定します。
Winforms の詳細情報。
ASP.NET の詳細情報。
共有の場所では、プロジェクト参照を使用するべきではありません。つまり、ファイル参照に対するそのような参照の利点を失うことになります。まだ試していませんが、理論的には、サブフォルダーの場所に分岐して、$\BranchName\Project1Name\Project1.slnプロジェクト参照を安全に作成することができます。
3 番目のオプションは、MSDN では多少省略されていますが、すべてのslnファイルをブランチのルート フォルダーに配置することです。次に、プロジェクトを上記のルートの下のフォルダーに保存します。
このエラー メッセージは、ソリューション ファイルが問題を引き起こす可能性のある相対パスを使用していることを知らせるために表示されます。
例えば
<ProjectReference Include="..\..\Applications\DL\MyDL.csproj">
たとえば、別の開発者がソリューションをハード ドライブ上の別の物理的な場所にマップするとします。
"..\..\..\Applications\DL\MyDL.csproj"
...その後、ビルドはマシン上で壊れます。個人的には、すべての開発者が同じ物理的な場所にマップするベスト プラクティスを実装する方が簡単だと思います。
C:\TFSこのようなものはどれも懸念を示すべきではありません。