在Visual C#Express中使用多个解决方案的良好实践

时间:2013-01-30 14:49:54

标签: c# build-automation visual-c#-express-2010

背景:我的团队由3位相当缺乏经验的开发人员组成。我们正在为我们公司开发内部软件。目前,我们有许多较小且独立的解决方案。其中许多是相互依存的。目前,这些依赖关系是通过引用相应版本文件夹中的输出dll来实现的。通过手动重建依赖解决方案来推动更新。

示例: 解决方案A使用解决方案B的功能。连接是通过解决方案A引用... \ Release \ B.dll。对B的更改通过构建解决方案B传播,然后构建解决方案A等等。

之前这个工作没问题,但是现在我们正在从手动(精神麻木)“版本控制系统”(folder1,folder2,folder2New ...)转到使用正确的(git)。

似乎不建议对.dll进行版本控制。这意味着每当有人想要构建新版本的A时,他还需要构建B(以及可能的其他5个解决方案)以获得最新版本的B。

我认为必须有更好的方法来做到这一点。 我一直在考虑将相关的解决方案合并到一个主解决方案中,但我无法弄清楚如何在Visual C#Express中实现这一点(我们正在使用)。

所以最后问题是:

  1. 是否有一个主要的解决方案可以构建所有方法? - 从MSDN看起来似乎如此,但我无法弄清楚如何在Visual C#Express 2008中做到这一点,它让我去了

  2. 这在Visual C#Express中是否可行?如果不是,那是什么 管理问题的好方法是什么?

  3. 修改感谢所有人提供以下优秀建议。以下是我最终做的总结。

    简而言之,问题的答案是:“是”和“排序,但大部分都是”。我实现如下:为了了解依赖关系,我按照下面的建议做了,并绘制了二进制产品的映射,箭头指向dll或exe的名称到其所有依赖项。

    对于每个项目,我打开了相应的解决方案(因为起初有一个解决方案项目)。然后,我在图中显示的树结构中添加了每个依赖项的项目文件(通过右键单击解决方案资源管理器中的解决方案),以便还包括依赖项依赖项等。然后我删除了旧的引用(直接指向.dlls)并添加了对项目的引用。

    重要的结果是:

    • 当构建项目的解决方案时,所有它的依赖项都是用它构建的,因此在部署时,您知道所有构建产品都是自动的最新版本。

4 个答案:

答案 0 :(得分:7)

我会创建一个新的解决方案,并将所有相互关联的项目添加到其中。您可以将每个原始解决方案中的项目分组到新解决方案中的不同解决方案文件夹中。这样,当您构建项目时,它所依赖的所有项目也将构建。它还意味着您将使用相同的配置(即Release或Debug)构建所有项目。这意味着项目的所有可以在Debug中构建,而不仅仅是依赖树中的顶层项目,而它下面的所有项目都是Release程序集。使调试更容易。

答案 1 :(得分:4)

我有Visual C#Express 2010,当我创建一个新项目时,它会自动创建一个默认解决方案。如果可见,则可以右键单击解决方案,然后选择添加>现有项目。

如果解决方案不可见,(我似乎记得C#Express 2005/8中存在此问题),那么您可以通过文件>添加>现有项目添加现有项目。解决方案现在应该可见。

就练习而言,我通常做的是:

必须一起构建的所有内容都应该在一个解决方案中,这些应该是项目,而不是DLL。我试着靠The Joel List生活,你应该能够在一步中建立你的项目。如果它是一个可部署的单元,那么应该有一个解决方案。我的所有项目都是在构建服务器上构建的,然后才能部署它们,所以一切都应该在需要构建的解决方案中。

Guys有时会将WCF服务项目和客户端放在同一个项目中以便于调试,但这取决于您是否要独立部署客户端和服务器。通常对于较大的项目,我将它们分开。

最后有一个例外。我们有一个由不同团队使用的中央公共库。如果它包含在不同的解决方案中,并且一个团队改变了某些东西,我们最终会破坏其他团队的构建。在这种情况下,我们创建一个包含所有库项目的解决方案。这些内置于我们存储版本的DLL。我们将这些视为其他解决方案可以使用的框架。例如。 A队使用CommonLibrary 1.1,B队使用CommonLibrary 1.2。

答案 2 :(得分:3)

您需要将解决方案视为"项目分组" - 项目实际上是"内置"而不是"解决方案" (好吧,那不是完全是真的,解决方案变成了一个"元项目"引用所包含的项目,但它足够接近真相)

如果解决方案之间存在相互依赖关系,我建议在大白板上绘制所有项目,然后绘制表示项目之间依赖关系的箭头。一旦你完成了这项工作,你就能够一目了然地看到适当的项目组合和#34;合理。那些成为您的解决方案文件。

例如,如果您有项目A,B,...,F,其中:

  • A取决于B
  • B取决于C
  • D取决于C
  • E取决于F

这里可能的一个分裂是项目A,B,C,D的解决方案1和项目E,F的解决方案2.

答案 3 :(得分:-3)

我想出一个共同的区域来推动所有的dll。我的公司使用“R”驱动器,它只是一个LOCAL(不是网络所以没有人可以触摸另一个人文件夹)每个人都有的映射文件夹。每个解决方案都将构建到此。右键单击项目,属性 - >构建并更改输出。或者你可以添加一个post build命令来推送dll。之后,让所有项目都引用此位置。

一旦完成并且所有内容都指向同一个地方,您甚至可以将不同的项目组合添加到不同的解决方案中。如果开发人员只想要ui项目,他们可以打开一个特殊的“ui”解决方案,这是整体的一个子集。

以下是我在项目属性中使用的帖子构建事件 - >构建事件

rem when building on local workstation copy dll to local R:\
if '$(BuildingInsideVisualStudio)' (
    xcopy $(TargetDir)$(TargetName).* R:\Extranet\$(TargetName)\1.0\  /Y
)
rem if "Enterprise" build then copy dll to Corp R:\ drive and to Build Machine R:\
if '$(Reason)' == 'Manual' (
    xcopy $(TargetDir)$(TargetName).* \\folder\$(TargetName)\1.0\ /Y
    xcopy $(TargetDir)$(TargetName).* R:\Extranet\$(TargetName)\1.0\ /Y
)