Visual Studio 中的版本控制和解决方案结构

Question

我的系统包含三个应用程序（一个 Windows 应用程序和两个 Web 应用程序）。这些应用程序都共享两个共同的程序集。因此，我总共有 5 个项目。过去，我对每个项目都有单独的解决方案。这允许我在源代码控制中单独对每个程序集进行版本控制。但是，这会产生很大的开销，因为我必须单独打开每个解决方案，以查看我对其中一个常见程序集所做的更改是否破坏了任何应用程序。

我考虑过迁移到一个解决方案包含所有项目的结构。这让我可以立即看到我所做的任何更改的影响，但这会导致版本控制问题。如果我只更改通用程序集，或者仅更改其中一个应用程序，每个项目/程序集很快就会处于不同的版本级别。在源代码管理中，由于整个解决方案是在一起的，因此我的项目存储库中没有可使用的单一版本号。

我阅读的每个讨论似乎都解决了一个问题或另一个问题。可以使用多个解决方案来简化版本控制，也可以使用单个解决方案来简化依赖关系控制。

人们对构建解决方案/项目有什么建议，同时能够适当地对程序集进行版本控制？

Answer 1

我会坚持多种解决方案。您的 Windows 应用确实不需要（也不应该）知道您的 Web 应用程序中发生了什么。

我使用类似的设置，我们有多个 Web 应用程序，它们之间共享公共程序集。每天（或者如果您的构建时间足够快，则持续）构建有很大帮助。我们使用 NAnt 和 CruiseControl，但可用的选项与意见一样丰富。

如果您使用持续构建设置，您可以在共享库构建并通过其单元测试后触发其他解决方案构建（Web 应用程序等）。您仍然需要打开其他解决方案，但构建服务器会告诉您是否需要。

Answer 2

就个人而言，我喜欢有利于更轻松的依赖控制的解决方案。我更担心破坏性更改而不是拥有相同版本的项目#。

我（个人）唯一会担心版本 # 是我必须排除故障或修复错误时。如果我必须进行错误修复，那么我最终将重新编译代码，并且将拥有最新版本。老实说，如果有人在运行使用我开发的某个共享类库的旧版本的代码，那又如何呢？如果它有效，我在乎它是否是旧版本。有较新版本的唯一原因可能是后来编写的某些 OTHER 应用程序需要额外的功能。

当然，这假设您遵循“您不得更改共享程序集的方式会破坏现有代码”的诫命。添加新功能就OK了。修改一个函数，使其在内部以不同的方式工作，但返回相同的结果是可以的。更改功能以使其适用于新软件但破坏现有软件是不行的。那么担心版本控制就不是问题了。

当然，这可能是因为我从未在有理由担心版本的商店工作过，所以我预计会因为这个答案而被打败，但即使我是，我'我相信我会从 cmets 那里了解到为什么这是一个糟糕的答案，这就是我喜欢这个网站的原因。