2

在使用您自己开发的代码库时，我正在寻找有关正确发布管理的信息。我们正在使用 Visual Studio 2010，在 .NET 中开发并使用 TFS。让我勾勒一下情况。

我们正在与一个团队合作开展不同的项目，这些项目都产生了自己的程序/产品。所以我们开始考虑重用代码并将它们放入某种框架或库中。为此，我们创建了一个单独的解决方案，其中包含不同的项目和它们之间的依赖关系。我们称之为“平台”。

“平台”的解决方案例如有以下项目：

  • 日志记录
  • 记录.测试
  • 实用程序
  • 图表控件
    • 日志依赖
    • 实用程序依赖
  • 本土化
    • 日志依赖
  • 本地化.测试

实际上，我们已经有 20 个项目，并且项目之间的依赖关系更多，但这应该让事情变得清晰。

假设我们现在有两个项目A和B。它们如下所示：

项目A

  • 参考记录
  • 参考 Utils
  • 对 ChartControl 的引用
  • 本地化参考
  • 达尔
    • 日志依赖
  • 主应用
    • DAL 依赖
    • 日志依赖
    • 实用程序依赖
    • ChartControl 依赖项
    • 本地化依赖

项目 B

  • 对 ChartControl 的引用
  • 本地化参考
  • 主应用
    • ChartControl 依赖项
    • 本地化依赖

我们如何管理这种结构？我看到了几个问题，但没有真正的答案。

  • 我们是否在平台的项目 A 和 B 中包含 DLL 或代码？
  • 我们是否签入 DLL 并复制到不同的项目？分支可以有益吗？
  • 版本呢？假设项目 A 使用 Logging V.1.0.0.0，并且与同样使用 Logging V.1.0.0.0 的 ChartControl 一起工作得很好。在某一天，我们决定使用新版本的 ChartControl，它也使用新版本的 Logging V.2.0.0.0。如何确保项目 A 不会被迫也开始使用 Logging V.2.0.0.0？
  • 我们可以决定将平台作为一部分、全部或全部发布。但是我们如何管理所有这些 DLL 的构建。手动更新所有项目中的版本号需要大量工作，并且从所有不同的 bin 文件夹中提取它们甚至更多。
  • 我们如何将“平台”集成到我们的项目中。我们是否创建了一个引用文件夹并将所有 DLL 放在其中，以便在解决方案中引用它们？
  • 我们如何跟踪依赖关系？如果为整个平台发布一个版本，我们如何丢弃不需要的 DLL。例如，项目 B 对 Utils 不感兴趣，但间接对 Logging 感兴趣。
  • 如果我们将平台作为一个平台发布，那么小的改动就会产生一组全新的 DLL。例如，Utils 项目中的更改也将导致 Logging、Localization 等新版本......除非没有更改。

我还尝试搜索互联网并进行了一些内部讨论，但没有提供真正的答案。我在 Stack Overflow 上发现的是关于库和框架之间的定义差异，在 MSDN 上你可以阅读很多关于 DLL 和 GAC 的信息。

欢迎任何最佳实践、工具、经验……。

4

2 回答 2

1

我会为“平台”创建 NuGet 包，并将它们分隔在具有清晰依赖结构的逻辑块中，这样当您需要例如“Utils”时，您可以安装此包，并且会立即安装“Logging”包。它还涵盖了版本管理。

请参阅http://docs.nuget.org/docs/creating-packages/creating-and-publishing-a-package

然后，因为它是一个内部框架，你想看看设置你自己的 NuGet 提要：http ://docs.nuget.org/docs/creating-packages/hosting-your-own-nuget-feeds

设置它可能是最初的承诺，但从长远来看，您肯定会从这种方法中获益。

于 2012-08-23T11:04:58.747 回答
0

我会使用包含所有代码的分层目录结构，以及库 DLL 的发布版本；使用相对路径来引用其他 DLL 或项目。这应该使您可以根据需要灵活地维护和更新依赖项。

我们是否在平台的项目 A 和 B 中包含 DLL 或代码？

将所有内容都签入 TFS。每个项目都可以决定是否通过引用 DLL 或项目文件来解决其依赖关系。

我们是否签入 DLL 并复制到不同的项目？分支可以有益吗？

签入 DLL，但将它们保存在源代码控制结构中较低级别的Shared Resources文件夹中：

/Shared
    /DLLs
        /Platform
            /Logging
                /V1.0.0.0
                    /Debug
                    /Release
                /V2.0.0.0
            /ChartControl
/Source
    /Platform
        /Logging
        /ChartControl
    /Projects
        /ProjectA
        /ProjectB

版本呢？假设项目 A 使用 Logging V.1.0.0.0，并且与同样使用 Logging V.1.0.0.0 的 ChartControl 一起工作得很好。在某一天，我们决定使用新版本的 ChartControl，它也使用新版本的 Logging V.2.0.0.0。如何确保项目 A 不会被迫也开始使用 Logging V.2.0.0.0？

如果您需要让不同的项目引用同一库的不同版本，请签入每个发布版本。所以ChartControl可以引用/Shared/DLLs/Logging/V1.0.0.0，而Project A可以引用V2.0.0.0。（不过，我倾向于注意这一点，因为它可能会变得混乱；如果新的日志记录版本使用不同的文件/数据库格式怎么办？）

我们可以决定将平台作为一部分、全部或全部发布。但是我们如何管理所有这些 DLL 的构建。手动更新所有项目中的版本号需要大量工作，并且从所有不同的 bin 文件夹中提取它们甚至更多。

要自动化构建任务，一定要考虑持续集成服务器（Cruise Control、QuickBuild、Jenkins 等）。

我们如何将“平台”整合到我们的项目中。我们是否创建了一个引用文件夹并将所有 DLL 放在其中，以便在解决方案中引用它们？

我认为这是正确的做法。引用 DLL 使您能够遵守平台的单独开发/测试/发布过程。

我们如何跟踪依赖关系？如果为整个平台发布一个版本，我们如何丢弃不需要的 DLL。例如，项目 B 对 Utils 不感兴趣，但间接对 Logging 感兴趣。

每个项目所有者都必须跟踪自己的依赖关系；只有项目 B 的所有者知道是否引用 Utils。

如果我们将平台作为一个平台发布，那么小的改动就会产生一组全新的 DLL。例如，Utils 项目中的更改也将导致 Logging、Localization 等新版本......除非没有更改。

不过这应该没问题吧？这是一个政策问题；是否应该强制每个项目集成平台的最新版本，或者他们可以针对旧版本工作。我认为你是在暗示后者是正确的。项目 A、B 等是最终产品，因此由这些项目的所有者决定何时集成新的 DLL。

于 2012-08-21T16:47:32.823 回答