7

背景：我的团队由 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 中是否可行？如果没有，有什么好的方法可以解决这个问题？

编辑感谢大家在下面的好建议。这是我最终做的总结。

简而言之，问题的答案是：“是”和“有点，但大多是”。我实现如下：为了了解依赖关系，我按照下面的建议进行操作，并绘制了二进制产品的映射，箭头从 dll 或 exe 的名称指向其所有依赖项。

对于每个项目，我打开了其对应的解决方案（因为一开始有一个解决方案 pr 项目）。然后，我在图中显示的树结构中添加了每个依赖项的项目文件（通过右键单击解决方案资源管理器中的解决方案），因此还包括依赖项的依赖项等。然后我删除了旧的引用（直接指向 .dll）并添加了对项目的引用。

重要的结果是：

  • 当一个项目的解决方案被构建时，它的所有依赖项都是用它构建的，所以在部署时，你知道所有的构建产品都是自动的最新版本。
4

4 回答 4

7

我将创建一个新的解决方案并将所有相互关联的项目添加到它。您可以通过将每个原始解决方案中的项目放在新解决方案中的不同解决方案文件夹中来对它们进行分组。这样，当您构建一个项目时，它所依赖的所有项目也将被构建。这也意味着您的所有项目都将使用相同的配置（即发布或调试）构建。这意味着您的所有项目都可以在 Debug 中构建，而不仅仅是依赖关系树中的顶部项目，而它下面的所有项目都是发布程序集。使调试更容易。

于 2013-01-30T15:01:06.533 回答
4

我有 Visual C# Express 2010，当我创建一个新项目时，它会自动创建一个默认解决方案。如果它是可见的，那么您可以右键单击解决方案并选择添加>现有项目。

如果解决方案不可见，（我似乎记得 C# Express 2005/8 中的这个问题），那么您可以通过 File>Add>Existing Project 添加现有项目。现在应该可以看到解决方案。

在操作方面，我通常做的是：

必须一起构建的所有东西都应该在一个解决方案中，并且这些应该是项目而不是 DLL。我尝试按照 Joel List生活，您应该能够在其中一步构建您的项目。如果它是一个可部署的单元，那么应该有一个解决方案。我的所有项目都在部署之前构建在构建服务器上，因此所有项目都应该在需要构建的解决方案中。

有时为了调试方便，有些人会把 WCF 服务项目和客户端放在同一个项目中，但这取决于你是否要独立部署客户端和服务器。通常对于较大的项目，我将它们分开。

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

于 2013-01-30T16:36:47.283 回答
2

您需要将解决方案视为“项目分组”——这些项目是实际“构建”的，而不是“解决方案”（嗯，这并不完全正确，解决方案变成了引用包含的“元项目”项目，但它足够接近真相）

如果解决方案之间存在相互依赖关系，我建议在大白板上绘制所有项目，然后绘制表示项目之间依赖关系的箭头。完成此操作后，您将一眼就能看出适当的“项目分组”是什么意思。这些成为您的解决方案文件。

例如，如果您有项目 A、B、...、F，其中：

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

一种可能的拆分方式是项目 A、B、C、D 的解决方案 1 和项目 E、F 的解决方案 2。

于 2013-01-30T15:29:09.850 回答
-4

我会想出一个公共区域来推送所有 dll。我的公司使用“R”驱动器，它只是一个本地（不是网络，所以没有人可以触摸另一个人的文件夹）映射文件夹，每个人都有。每个解决方案都将以此为基础。右键单击一个项目，属性->构建并更改输出。或者您可以添加一个构建后命令以将 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
)
于 2013-01-30T15:03:36.593 回答