【问题标题】:How to manage class library evolution in Visual Studio 2013/TFS?如何在 Visual Studio 2013/TFS 中管理类库演变?
【发布时间】:2015-02-10 12:44:45
【问题描述】:

我们正在开发一个类库来帮助我们的开发过程。该库包含一个包含 3 个不同项目/程序集的解决方案:

CustomLibrarySolution
|
|--CustomLibrary.Mvc
|--CustomLibrary.Persistence
|--CustomLibrary.Persistence.NHibernate

每个项目都有 NuGet 依赖项,在最初的 CustomLibrary 开发时,包版本更新到最后一个,看起来像这样(一些库,为简单起见):

CustomLibrarySolution
|
|--CustomLibrary.Mvc [NuGet: log4net 1.2]
|--CustomLibrary.Persistence
|--CustomLibrary.Persistence.NHibernate [NuGet: NHibernate 3.0]

所以,我们使用这个库创建了我们的第一个项目,解决方案如下所示:

MyFirstProject
|--Libs
   |--CustomLibrary.Mvc.dll [NuGet: log4net 1.2]
   |--CustomLibrary.Persistence.dll
   |--CustomLibrary.Persistence.NHibernate.dll [NuGet: NHibernate 3.0]
|--MyFirstProject.Web [CustomLibrary.Mvc.dll AND NuGet: log4net 1.2]
|--MyFirstProject.Core [CustomLibrary.Persistence.dll]
|--MyFirstProject.Core.NHibernate [CustomLibrary.Persistence.NHibernate.dll 
                                   AND NuGet: NHibernate 3.0]

一切正常。

现在,在我们的第二个项目中,出现了我为什么要写这个的问题:

My2ndProject
|--Libs
   |--CustomLibrary.Mvc.dll [NuGet: log4net 1.2]
   |--CustomLibrary.Persistence.dll
   |--CustomLibrary.Persistence.NHibernate.dll [NuGet: NHibernate 3.0]
|--My2ndProject.Web [CustomLibrary.Mvc.dll AND NuGet: log4net 1.3] <-- newer version
|--My2ndProject.Core [CustomLibrary.Persistence.dll]
|--My2ndProject.Core.NHibernate [CustomLibrary.Persistence.NHibernate.dll 
                                 AND NuGet: NHibernate 4.0] <-- newer version

项目构建正常,运行良好;但我怀疑这是不可以的,基于:

  • My2ndProjectpackages 文件夹包含 2 个版本文件夹
NHibernate 3.0
NHibernate 4.0
log4net 1.2
log4net 1.3
  • 当我使用 Reflector.NET 之类的工具检查其中一个 My2ndProject 程序集时,它显示了两个依赖项(NHibernate 3.0 和 NHibernate 4.0)。例如,这让我在尝试使用 InstallUtil 安装 Windows 服务时感到头疼,因为它会引发 AssemblyLoadException 搜索 NHibernate 3.0。

我正在考虑这种情况,而我想到的一种可能的解决方案是,每次在新项目中使用类库项目时都复制它们,而不是只复制 dll。这将允许将类库 NuGet 依赖项更新到与新项目中引用的完全相同的版本。 这种方法的问题是我们将丢失类库的 TFS 版本控制。相反,该库将存在于 N 个存储库中。

我可以做些什么来改进这种方法吗?

【问题讨论】:

  • 为什么不使用单一的依赖集?这种混乱通常很快就会失控。
  • 你的意思是在 2ndProject 中使用 NHibernate 3.0 而不是 NHibernate 4.0 对吧?
  • 哪个更可取。我认为使用较新的版本会更好,所以我会升级库。将多个版本的依赖项加载到同一个进程中并不是一个好主意。
  • 归根结底,您真的只想将每个外部库的一个版本加载到进程中,以避免各种版本不匹配问题。处理一组依赖项要简单得多。
  • 好的,但这就是问题所在。如果我升级类库,那么我必须升级第一个项目的依赖项,如果我想提供类库错误修复或改进。

标签: .net visual-studio-2012 tfs nuget


【解决方案1】:

您的项目 2 直接依赖于 NHibernate 4.0,并且“传递”依赖于 NHibernate 3.0(通过库)。至少这是我在与人们谈论这个问题时使用的术语。

我写了一篇关于这个问题的博客文章,以及解决它的策略:http://geekswithblogs.net/Optikal/archive/2013/01/27/151951.aspx

其要点是您需要为各种组件制定版本控制策略,并使用程序集绑定重定向来解决无法将多个版本加载到同一进程中的问题。

幸运的是,NuGet 基本上为您完成了所有艰苦的工作(根据策略找出可接受的版本,并创建绑定重定向),您只需在各种 nuspec 文件中指定版本控制策略。

这里是有关如何指定版本控制策略的 nuget 文档:http://docs.nuget.org/docs/reference/versioning

这里有一篇很棒的博客文章,介绍了如何让 NuGet 为您生成绑定重定向:http://blog.davidebbo.com/2011/01/nuget-versioning-part-3-unification-via.html

【讨论】:

  • 那种 NuGet 版本配置正是我想要的。非常感谢
猜你喜欢
  • 2015-03-17
  • 1970-01-01
  • 2016-09-07
  • 2014-08-04
  • 2013-12-23
  • 1970-01-01
  • 2019-02-05
  • 2014-08-08
  • 1970-01-01
相关资源
最近更新 更多