使用自己的基于.NET的框架的不同项目

Question

在使用您自己开发的代码库时，我正在寻找有关适当的发行版管理的信息。我们正在与Visual 2010合作，在.NET中开发并使用TFS。让我描述一下情况。

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

例如，“platform”的解决方案有以下项目：

• 日志记录
• Logging.Tests
• 功用
• ChartControl
  • 日志依赖
  • Utils依赖

​

• 本地化
  • 日志依赖

​

• Localization.Tests

在现实中，我们已经有20个项目和更多的项目之间的依赖，但这应该清楚的事情。

假设我们现在有两个项目A和B：

项目A

• 参考测井
• 参考Utils
• 参考ChartControl
• 提及本地化
• DAL
  • 日志依赖

​

• MainApp
  • DAL依赖性
  • 日志依赖
  • Utils依赖
  • ChartControl依赖
  • 本地化依赖

​

项目B

• 参考ChartControl
• 提及本地化
• MainApp
  • ChartControl依赖
  • 本地化依赖

​

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

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

我也试图搜索互联网，并进行了一些内部讨论，但没有提供真正的答案。我在堆栈溢出上发现的是库和框架之间的定义差异，在MSDN上，您可以阅读很多关于DLL和GAC的内容。

任何最佳做法、工具、经验.是受欢迎的。

Answer 1

我将为"platform“创建NuGet包，并在逻辑块中将它们分离出来，并有一个清晰的依赖结构，例如，当您需要"Utils”时，您可以安装这个包，并且“日志”包可以安装。它还包括版本管理。

请参阅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

这可能是一个初步的承诺来设置这一点，但从长远来看，您肯定会收获这种方法的好处。

Answer 2

我将使用包含所有代码的分层目录结构，并发布库all的版本；使用相对路径引用其他all或项目。这将为您提供必要的维护和更新依赖关系的灵活性。

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

检查所有东西到TFS。每个项目可以通过引用DLL或项目文件来决定是否解决其依赖关系。

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

签入DLL，但将它们保存在源代码管理结构中的较低级别的共享资源文件夹中：

/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，这与同样使用LoggingV.1.0.0.0的ChartControl工作得很好。在某一天，我们决定使用一个新版本的ChartControl，该版本也使用一个新版本的Logging V.2.0.0.0。我如何确保项目A不会被迫也开始使用日志记录V.2.0.0.0？

如果需要不同的项目引用同一库的不同版本，那么请签入每个发行版。因此，ChartControl可以引用/Shared/DLL/Logging/V1.0.0.0，而项目A可以引用V2.0.0.0。(不过，我倾向于提醒您不要这样做，因为这可能会变得很麻烦；如果新的日志记录版本使用了不同的文件/数据库格式，该怎么办？)

我们可以决定把这个平台作为一个整体来发布，不管是什么都可以。但是我们如何管理所有这些DLL的构建。手动更新所有项目中的版本号需要大量工作，并从所有不同的bin文件夹中提取它们。

要使构建任务自动化，一定要查看连续集成服务器( Control、QuickBuild、Jenkins等)。

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

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

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

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

如果我们将平台作为一个整体发布，那么小的更改将导致一组完整的新DLL。例如，Utils项目中的更改也将导致新版本的日志记录、本地化、.除非没有任何变化。

不过，这应该可以，对吧？这是一个政策问题；如果每个项目都被迫集成平台的最新版本，或者他们可以使用旧版本。我想你是在暗示后者是真的。项目A、B等是最终产品，因此需要由这些项目的所有者来决定何时集成新的DLL。