如何在.NET版本上发展.NET代码库

Dan*_*nyT 8 .net c# .net-3.5 .net-2.0

我有一组很久以前开发的.NET组件(1.1).我想继续为需要该版本的任何客户端提供1.1版本,但也提供版本 - 在某些情况下为.NET 2和.NET 3(.5)提供相同的代码,在某些情况下还有增强功能.在后面的每种情况下,我可能希望利用平台的新功能来处理某些组件.

我正在寻找有关这种情况下最佳做法的指导.

在我不打算对组件进行任何更改的情况下,我想我仍然可以将其作为1.1提供,以后的库/应用程序可以按原样使用1.1程序集.我怀疑可能仍然有充分的理由提供使用更高版本的.NET构建的程序集 - 例如性能 - 但我的理解是我可以提供1.1.它是否正确?

在我希望保持组件代码的大部分代码与1.1一起使用的情况下,还要为更高版本的.NET添加功能,最好的方法是什么?

  • 单独的代码分支
  • C#预处理器
  • 在.NET 2+版本的单独(新)类中提供功能,并使用原始的via,例如,组合
  • 我还不知道的一些其他高级.NET技巧

此外,任何关于如何处理组装签署的建议将不胜感激.

提前致谢

Joh*_*ers 11

在我相当苛刻的意见中,停止支持.NET 1.1已经过去了.我仍然可以考虑仍然使用.NET 1.1的唯一理由是,如果你仍然需要支持.NET 2.0不支持的硬件 - 而且在这个较晚的日期,我不确定我们可以称之为一个很好的理由.

事实上,除了硬件支持之外,我认为我没有听说过任何有效的原因导致机器无法升级到.NET 3.5 SP1.就.NET 2.0应用程序而言,.NET 3.5 SP1只是.NET 2.0 SP2.你不得不想知道为什么有人不想实现近一年来一直存在的服务包.

.NET 3.0和.NET 3.5的所有其余部分只是附加程序集,不会影响不使用它们的代码.

所以我平衡了为所有客户服务的愿望与支持.NET 1.1的持续成本.也许您继续支持它,但收取额外的支持,和很多更多的任何新功能.使用.NET 2.0在较小程度上也是如此.

另一个更狂野的想法是:我们是不是通过继续支持它们来启用.NET 1.1公司,好像这样做没有额外费用?我们真的通过帮助他们把头埋在沙子中来帮助他们吗?即使他们太忙而无法看到它,也不久之后,一些创业公司开始与他们竞争并赢得他们的大部分业务,不是因为他们是一个更好的公司,而是因为他们正在使用WCF和ASP.NET MVC和AJAX以及.NET 1.1人员梦寐以求的所有酷炫功能.