c# - 在 TFS 中的解决方案之间共享代码

Question

关闭。这个问题需要debugging details .它目前不接受答案。












想改进这个问题？将问题更新为 on-topic对于堆栈溢出。

2年前关闭。




Improve this question




我有几个不同的应用程序需要在它们之间共享代码以减少维护。我试图阅读很多关于 stackoverflow 和一般网络的内容，这是一个相当普遍的问题；我还没有找到我喜欢的答案。

我们的 TFS 分支结构是这样的。我们有三个分支开发，主要和生产。在 Development 分支上，所有事件的开发都完成了，当我们完成新功能的开发时，我们将它与 Main 合并，然后再到生产中。生产分支始终是在服务器上运行的代码。如果我们检测到必须在下一次迭代之前修复的错误。更改主要完成，并在我们部署时与生产合并。需要共享代码的应用程序不共享公共(public)分支层次结构或公共(public)迭代计划。事实上，其中一个应用程序每年只进行一次 1 个月的迭代。 (我知道这与传统的做法略有不同。

在我的研究中，我发现了一些不同的解决方案，但我都遇到了问题。

二进制共享:
我发现的一种常见方法是将编译后的二进制文件分支到开发分支下的 a 文件夹中。我的问题是，如果我们在哪里检测必须快速修复的共享代码中的错误，那么相关代码就会被编译。如果我们在哪里修复错误，我们将对共享代码库进行所有更改。

项目分享:
我的主要问题是如何以可接受的方式完成。我最初的想法是当新的迭代开始时，将主分支的更改与共享代码合并以更新它。将主分支与开发分支合并，以使用错误修复导致的更改来更新开发分支。并将共享代码的新更新版本分支到开发分支中。但据我了解，这不受 TFS 支持，因为我会创建嵌套分支。

我的问题是:
我如何在解决方案之间共享一些常见项目，同时保持它们隔离，并能够修复主分支上的错误，而不用担心常见项目已更改并因此引入新错误。但仍然能够修复公共(public)项目中的错误并将这些修复合并回共享的公共(public)项目中。

Answer 1

我所做的是您所谓的“二进制共享”的一个版本。如果您可以将共享代码视为第 3 方项目，那么您可以应用与运行良好的第 3 方项目相同的开发规则。这意味着您应该专门对共享代码进行版本控制(使用 semVer 或类似的东西)并尽可能保持向后兼容性。

是的，你是对的，这意味着如果你在共享代码中发现了一个错误，你需要发布另一个版本，然后重新编译依赖这个代码的项目。

但是，这也意味着如果依赖共享代码的两个项目中只有一个需要修复错误，则只有该项目需要采用新版本。

另一个好处是，何时进行更新取决于项目。因此，您可以更有信心地管理错误修复过程。

所以，要明确一点，我的建议是为共享代码创建一个新的 TFS 项目，把你对第 3 方项目(它自己的构建、NuGet 等)表现出的所有爱都给它，然后进行构建程序集放入想要使用它的项目的库文件夹中。

希望这可以帮助。