我有一组很久以前开发的.NET组件（1.1）。我想继续为需要该版本的任何客户端提供1.1版本，但也提供版本 - 在某些情况下为.NET 2和.NET 3（.5）提供相同的代码，在某些情况下还有增强功能。在以后的每种情况下，我可能希望利用平台的新功能来处理某些组件。
我正在寻找有关这种情况下最佳做法的指导。
如果我不打算对组件进行任何更改，那么我想我仍然可以将其作为1.1提供，以后库/应用程序可以按原样使用1.1程序集。我怀疑可能仍然有充分的理由提供使用更高版本的.NET构建的程序集 - 例如性能 - 但我的理解是我可以只提供1.1。这是对的吗？
如果我希望保持组件代码的大部分代码与1.1一起使用，而且还为更高版本的.NET添加功能，那么最好的方法是什么？
此外，我们将非常感谢任何有关如何处理装配签名的建议。
提前致谢
答案 0 :(得分：11)
在我相当苛刻的意见中，停止支持.NET 1.1已经过时了。我仍然可以考虑仍然使用.NET 1.1的唯一理由是，如果你仍然需要支持.NET 2.0不支持的硬件 - 而且在这个较晚的日期，我不确定我们可以称之为一个很好的理由。 / p>
事实上，除了硬件支持之外，我认为我没有听说过任何有效的原因导致机器无法升级到.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人员梦寐以求的所有很酷的功能。
答案 1 :(得分：3)
我维护一个.NET 2.0，.NET 3.0，.NET 3.5 CF 2.0，CF 3.5，Mono 2.x和Silverlight 2.0的项目 - 我使用项目（构建）文件和#if的组合来完成大部分工作指令，以最小化/本地化重复代码的数量。
我主要输出相同的dll - 尽管我已经创建了一些3.5特定的dll来覆盖扩展方法等内容。
一项重要的工作是确保你设置它以便你可以快速构建/测试它们 - 例如，我有一个“build.bat”，它将检查它是否在所有这些中编译（它是真的很容易引入非法语法）。
对于1.1，我想你可以使用MSBee，但是你可能需要一个“csc” - 但是有一些非常基本的变化（例如没有泛型），所以它可能会更难一个数量级......
答案 2 :(得分：2)
答案 3 :(得分：1)
这似乎很快就会变得混乱。您要么最终要维护针对不同框架的相同代码库的多个流（在这种情况下，您肯定要考虑SCM中的分支），或者您将功能分解为为不同框架执行离散任务的类
我认为这主要取决于您对未来代码库增长的期望。如果您期望对已取代的版本进行有限的更改，我将继续使用大部分新功能进入最新一代.NET，以利用新的语言功能。大多数新功能都是在3.0和3.5中得出的，所以我倾向于尽可能地让客户转向他们;他们获得了新的语言，你可以将注意力集中在构建主要是一个框架上。