我终于开始抽出时间来完成持续的整合过程。我已经开始在家里组建一个构建服务器，并试图了解如何处理构建中的不同情况。
如果我有应用程序“B”使用的组件“A” - 告诉构建服务器编译“A”然后使用新编译编译“B”的“最佳实践”是什么“A”
显然，我希望看到我如何集成工作组件，我看到了很多数据库示例，但没有使用DLL等等。
非常感谢！
答案 0 :(得分：1)
几乎所有.net构建服务器都在解决方案之外，以获取项目引用/依赖项。要考虑的主要事情是构建路径必须镜像您的开发路径。
现在，要明确的是，如果您使用的是GAC程序集，那么这些程序集也必须在构建服务器上进行GAC。否则你会遇到问题。
以您的示例为例，您的解决方案文件中应包含项目A和B.此外，对于A应该有一个项目依赖于B.您可以通过右键单击项目B中的References文件夹，选择Projects选项卡，然后选择Project A来实现此目的。
该信息与项目B一起存储。解决方案维护B的参考和项目A之间的联系。我希望这是有道理的。
答案 1 :(得分：1)
有两种方法可以解决这个问题：
1 - 您的相关组件是否独立并在任何地方重复使用
或
2 - 这是一个大型系统的一部分，它是相互依赖的，但很好地模块化为不同的项目。
我不是百分之百确定在第一种情况下最佳做法是什么，但我可以解释我在第二种情况下做了什么。
假设您有以下结构
/中继线
/trunk/Rob.Core
/trunk/Rob.MyCoolApplication.Server
/trunk/Ron.MyCoolApplication.Client
每个应用程序都是“顶级”应用程序，每个应用程序都有自己的解决方案和目标，它们可以独立编译，但它们属于同一系统。
为了以最小的麻烦获得“流畅”的构建集成，我总是建议尝试在开发和构建服务器上重现相同的环境。因此，当您签出编辑这些应用程序时，您应该将/ trunk签出到/ MyTrunkFolder。
现在，我倾向于做的是对任何可重用的.dll或组件进行post构建操作，设置一个post构建操作，将xcopys的构建输出（在发布模式下）设置为：
/中继/ CompiledOutputs / AppOrLibName /
永远不要签入此文件夹，这一点很重要，应该通过构建必备的解决方案来生成。
现在，在将Rob.MyCoolApplication.Server中的引用添加到Rob.Core时，实际上是添加了对/trunk/CompiledOutputs/Rob.Core/some.dll的引用。
这样您的开发环境看起来就像构建服务器一样。 一旦正确连接了依赖关系，就需要在CI系统中添加触发器。在CCNET中，对于上面的例子，我对Rob.Core的成功构建进行了触发，以触发Rob.MyCoolApplication.Server的构建。
当您对系统进行全新检查时，建议使用批处理脚本以依赖顺序触发msbuild以构建您的环境。
以上内容仅在您始终希望根据组件的最新版本构建应用程序时才有效。如果不是这种情况，您可能希望将引用的程序集的已签入文件夹作为使用它们的应用程序的一部分，然后手动更新到已编译组件的新版本，以及它何时有效。如此。
关于这个主题的文章很少，所以大部分内容都是在3-4个项目中被感知和推断，但在我最近的两个大项目中它肯定是可重复和可靠的。很明显，你的里程可能会有所不同。
答案 2 :(得分：0)
Ant和nAnt是Java和.Net的一些构建工具，它们是可能有用的脚本示例。如果您想要更多想法，Msbuild或Cruise Control也可能是有用的工具。
我可能会使用一些脚本，在构建B时说必须首先构建A，这是大多数现代构建工具支持的依赖。