经过一些研究,该选项基本上归结为两个选项:
- 从共享位置引用代码
- 分支共享代码
共享位置:
使用这种方法,您可以将共享位置(例如另一个团队项目)中的源映射到开发计算机上的工作区。这将创建一个配置,将来自共享位置的共享源与开发计算机上的项目代码统一起来。
这种方法的优点是每次您将最新版本的源检索到您的工作区时,都会获取对共享源的任何更改。例如,考虑一个名为 Common 的团队项目,其中包含共享源。要从此位置引用代码,请将两个团队项目映射到开发计算机上的公共路径位置。
分枝
使用这种方法,您可以将公共团队项目中的共享代码分支到您的团队项目中。这还创建了一个配置,该配置将来自共享位置和您的项目的源统一起来。
这种方法的不同之处在于共享源更改是作为分支之间合并过程的一部分而被拾取的。这使得在共享源中获取更改的决定更加明确。您决定何时执行合并以获取最新更改。
Winforms 的更多信息。
ASP.NET 的更多信息。
使用共享位置,您不能不使用项目引用,这意味着您失去了此类引用相对于文件引用的优势。我还没有尝试过,理论上可以分支到的子文件夹位置$\BranchName\Project1Name\Project1.sln
并能够安全地创建项目引用。
第三种选择,在 MSDN 上有些掩饰,是将所有sln
文件放入分支的根文件夹中。然后将项目存储在所述根目录下的文件夹中。
显示此错误消息是为了让人们知道解决方案文件使用可能导致问题的相对路径。
例如
<ProjectReference Include="..\..\Applications\DL\MyDL.csproj">
例如,如果另一个开发人员要将解决方案映射到其硬盘驱动器上的不同物理位置:
"..\..\..\Applications\DL\MyDL.csproj"
...然后构建将在他们的机器上被破坏。就个人而言,我认为实现每个开发人员映射到相同物理位置的最佳实践更容易:
C:\TFS
这些东西都不应该引起关注。