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

标签 c# .net .net-3.5 .net-2.0

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

我正在寻找有关在这种情况下最佳做法是什么的指导。

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

如果我想保持组件的大部分代码与 1.1 一起工作,但还要为更高版本的 .NET 添加功能,最好的方法是什么?

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

此外,如有任何关于如何处理程序集签名的建议,我们将不胜感激。

提前致谢

最佳答案

在我看来,停止支持 .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 用户梦寐以求的所有酷炫功能。

关于c# - 如何在 .NET 版本上发展 .NET 代码库,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/1051613/

相关文章:

.net - 编写使用 .NET 的语言的优点、缺点和困难

.net - Node.js 和 .net 之间的命名管道通信

sockets - 使用桌面 WPF 应用程序的套接字推送通知(无 Win8 应用程序)

c# - Winforms - 当任何表单加载到设计器中时执行函数

C# 泛型和反射

c# - 具有相同名称的类和方法变量的行为

c# - 在 .Net 3.5 中使用 GetDirectories() 识别错误的 ReparsePoints?

c# - 使用反射获取继承接口(interface)的类的属性

.net - fsharp BinaryReader 如何读取文件末尾?

.net - .NET 3.5 SP1 客户端框架的 HttpUtility 的替代方案?