Cod*_*ray 11
没有理由不使用最新版本的框架.您不仅可以获得加速开发时间的所有最新功能和口哨,而且还可以利用Microsoft在引擎盖下完成的所有错误修复和改进.
定位早期版本的框架的唯一优势是徒劳地希望用户不必下载和安装任何东西以便使用您的应用程序.但这远非万无一失,而且大部分都是徒劳的.请记住,Windows不是.NET Framework交付渠道,您无法可靠地假设用户将安装任何版本的.NET Framework.即使你坚持指望它与Windows捆绑(你不应该),许多用户仍然没有从Windows XP升级.即使您指望它被推送到Windows Update,也有大量用户不使用Windows Update,不经常使用Windows Update,或者居住在互联网访问速度较慢/较慢的偏远地区并且无法下载所有这些更新.
故事的寓意是,无论如何,您将不得不在您的应用程序中提供适当版本的.NET Framework.并且.NET 4.0运行时实际上比以前的版本小得多,因此没有理由将它们作为目标.团队在这方面做得非常努力,他们的努力确实得到了回报.更好的是,作为atornblad笔记,大多数应用程序可以针对框架的客户端配置文件版本,该版本修剪掉一些不经常使用的部分,并将内容减少到另外约16%.
此外,我强烈建议使用一个安装应用程序来自动和无缝地为用户处理所需的框架.Visual Studio内置支持创建安装应用程序,或者您可以使用Inno Setup等第三方安装程序实用程序.这使得使用最新版本变得简单.
其他人似乎都建议您使用最新版本，因此如果您实际上不需要更高版本的任何功能，那么我会建议您使用2.0，如果这确实是一个客户端库并且您无法控制和关于谁将使用它的一点想法。
实际上，这确实取决于您的用户可能是谁，而这又取决于REST服务是什么。如果是某种社交媒体，那么我想说的是，您的客户更有可能位于他们可以使用.NET 4的环境中。如果它很可能被金融机构或其他大型企业使用，不能选择使用.NET 4，因此您应该考虑使用早期版本。这是我们在Noda Time所采用的方法，我们认为该库将在多种情况下有用，并且我们无法预测客户的需求。
当然，如果您认识所有客户并且知道他们都将能够使用.NET 4，那么就去吧。
坚持使用.NET 2.0的最大缺点是您将无法在内部使用LINQ（除非您使用LINQBridge或类似的东西，这将为您的库添加另一个依赖项），并且您将无法（干净地）提供扩展方法。如果在使用更高版本的情况下可以向客户端公开更多功能，则可能需要提供该库的多个版本-但这显然是维护上的麻烦。
另一个要考虑的因素是您是否应该提供Silverlight版本-再次取决于您提供的服务类型和期望的用户类型。
如果您正在制作 REST 服务，您可能应该使用 4.0。
您唯一需要考虑使用旧版本的情况是另一个项目是否应该引用您编译的 dll。REST 服务通过 Internet 使用 HTTP 公开，客户端不会直接使用 .dll。还是我对问题的理解有误？