P.B*_*key 5 .net tfs visual-studio visual-studio-2012
Visual Studio 警告将项目存储在不是解决方案子文件夹的目录中:

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