跨颠覆维护解决方案的引用答案

【问题标题】：Maintaining references for solutions across subversion跨颠覆维护解决方案的引用
【发布时间】：2011-12-12 11:26:09
【问题描述】：

我有一个解决方案，其中包含三个项目。如果需要，这些项目都可以独立使用。为了给出一个清晰的画面，我的项目如下：

“General”类库项目，其中包含许多基本抽象类，如“Person”和一些 Helper 类。
“EmployeeManagement”类库项目，其中包含 Employee : Person、EmployeeAddressList 等类以及与管理员工相关的其他内容。
引用上述两个项目的 Web 应用程序项目充当表示层/Web 表单。即“editemployees.aspx.cs”用于编辑现有员工信息等。

这一切都很好，但是当我进行大量更改然后将所有三个项目推送到它们各自的三个存储库时，我的同事将从三个存储库中提取我的所有更改，然后打开整体解决方案.一切都在那里并且完好无损，但是 Web 应用程序项目不再识别对 General 和 EmployeeManagement 的引用。它们列在 References 文件夹中，但代码本身无法编译，尖叫着各种带下划线的红色疯狂。简单的解决方案是将它们从 References 文件夹中删除，然后再次添加它们，就像魔术一样，一切都恢复正常了。

我的问题是：

为什么会这样？
我做错了什么？（也许我推送到存储库的顺序或他的拉取顺序是关闭的？）
我能做些什么来防止这种情况发生？

谢谢:)

【问题讨论】：

如何添加参考文献？您是在添加对项目的引用还是对已编译的 DLL 的引用？
添加对项目的引用，方法是在 VS2010 中右键单击项目，转到“添加引用”，然后从“项目”选项卡中选择项目。

标签： .net visual-studio-2010 svn reference projects-and-solutions

【解决方案1】：

您的目录布局很可能与您同事的不同。

您的项目看起来很小，以证明分布在三个存储库中是合理的。您最好专注于软件的架构，而不是过度设计的项目基础架构使生活变得复杂。

顺便说一句。在 svn 中，我们提交和更新 :-)

【讨论】：

我不同意大小是决定存储库布局的一个因素。如果类库确实在多个项目或解决方案之间共享，那么将它们存储在单独的存储库中是非常有意义的。
一般来说，你是对的，但如果 OP 很难解决一些看起来非常琐碎的问题，我不建议他使用高级场景，如单一解决方案的多存储库设置发展。
我选择使用三个存储库的原因是为了让这些项目保持独立，如果它们需要独立的话。例如，有一天，有人说，“我希望我们有一个通用抽象类的类库，比如 Person 和 EmailAddress，这样我就不必从头开始创建所有这些了。”然后我可以说，“哦，当然，去检查通用存储库”，这完全独立于这个 Web 应用程序项目。
@CptSupermrkt：这很可能永远不会发生，因为这些通用类并不像您想象的那么通用。当然，它们是abstract，但它们仍然是根据您当前项目的需求量身定制的。当它真正被不同的项目使用时，你最好将该类库移动到不同的存储库。
谢谢丹尼尔。考虑到你说的话，我认为你可能是对的。我的目标可能太大了，无法创建可以涵盖所有未来项目的东西。但是，如果未来的项目需要它，将其复制并重新调整到该项目并不是世界末日。我一想到，嗯，你是对的，无论如何我都会重新剪裁它：）谢谢！

【解决方案2】：

在不了解更多信息的情况下，我会查看你们各自的 .sln 和 .csproj 或 .vbproj 文件，并确保每次提交更改时都不会覆盖所包含项目的相对路径。

以下是您的解决方案/项目文件中包含的项目引用示例：

.sln

Project("{6f8415d8-82c0-4e47-8ddd-f3962bb3b518}") = "QuickJoe.Awesome", "QuickJoe.Awesome\QuickJoe.Awesome.csproj", "{e623a940-79ba-4762-af02-84993a2b37b7}"
EndProject
Project("{6f8415d8-82c0-4e47-8ddd-f3962bb3b518}") = "QuickJoe", "..\qjs\QuickJoe\QuickJoe.csproj", "{6754372e-b253-41be-9b83-23cf8bea786f}"
EndProject

.csproj/.vbproj

<ItemGroup>
  <ProjectReference Include="..\..\qjs\QuickJoe\QuickJoe.csproj">
    <Project>{6754372e-b253-41be-9b83-23cf8bea786f}</Project>
    <Name>QuickJoe</Name>
  </ProjectReference>
</ItemGroup>

另一个好的提示（如果您还没有这样做的话）是专门排除 .user 和 .suo 文件。在某些情况下，它们在加载到不同的工作站时会产生积极的危害。

【讨论】：

哇，这是我不知道的事情 :) 每天学习新东西。肯定会玩这个。

【解决方案3】：

如果您使用的是 Visual Studio，请考虑将您的解决方案放在文件夹树的顶部，并将项目放在其下方。然后，Visual Studio 应通过其内部变量之一 $(SolutionDir) 引用项目。如果做不到这一点，请手动编辑解决方案并使文件夹/项目位置相对于$(SolutionDir)，然后无论在何处签出，所有内容都应该是可移植的。

【讨论】：