What .NET Framework version should I ship with; 2, 3, 3.5?我的应用程序使用2.0。 在将来的某个时候，我可能想开始使用在更高的框架版本中添加的较新功能。 我应该等到那时吗？ 还是现在更新到最新的.NET 3.5有优势？ 我想我准备为明年Spring的4.0版发布的时间就到了。 也许我应该在秋季发布时坚持使用2.0，并为客户节省其他框架版本的高清空间和安装时间？ 我认为，您应该随应用程序的需求一起交付。否则，您会无缘无故地延长安装时间，并且正如您所指出的，本质上无缘无故再次使用客户的HD空间。 如果计划升级到3.5 SP1，则应考虑使用"新.NET Framework客户端配置文件安装程序包"。 .NET 3.5 SP1为开发人员构建.NET客户端应用程序引入了一个新的安装程序包选项，称为" .NET Framework客户端配置文件"。这提供了新的安装程序安装程序，可为尚未安装.NET Framework的计算机上的.NET客户端应用程序提供更小，更快和更简单的安装体验。 .NET Framework客户端配置文件设置仅包含.NET Framework中通常用于客户端应用程序方案的那些程序集和文件。例如：它包括Windows窗体，WPF和WCF。它不包括ASP.NET以及主要用于服务器方案的那些库和组件。我们希望此安装程序包的大小约为26MB，并且可以比完整的.NET Framework安装程序包更快地下载和安装。 .NET Framework客户端安装程序包中的程序集和API与完整的.NET Framework安装程序包中的程序集和API 100％相同(它们实际上是相同的二进制文件)。这意味着应用程序可以同时针对.NET 3.5 SP1的客户端配置文件和完整配置文件(无需重新编译)。使用.NET客户端配置文件安装程序运行的所有.NET应用程序都会自动与完整的.NET Framework一起使用。 我总是使用框架的最新版本。这可能会给用户带来很小的前期负担，但应用程序之间的升级寿命更长。这对您可能不重要，但请考虑： 如果您在2005年使用.NET 1.1交付了一个应用程序，则该应用程序所运行的框架现在不在主流支持范围内，并且可能具有未修补的安全漏洞或Microsoft可能无法解决的其他严重问题，您无法补偿用你自己的代码。在2008年，您唯一的选择是让您的用户立即升级其框架版本。而且，众所周知，让用户及时更新事物可能会成问题。 同样，请考虑您在2011年的情况。如果现在为.NET 3.5编程，那么出厂时的应用程序将可以使用更长的时间。如果现在为.NET 2.0发货，那么几年后，您将可以说服用户升级其框架(请记住对他们没有好处的代码)，以便您可以正确支持此应用程序。 另外，如果您计划实现3.5级功能(例如，明年将使用LINQ to SQL)，那么现在就希望以3.5而不是2.0的形式交付，因为这将使以后的部署不再是您的问题。 请记住，给用户带来的"小负担"可能意味着您接受和拒绝您的应用程序之间的区别。 我为一家公司经营IT。我们公司的标准不是3.5。您必须拥有一个非常精巧的应用程序，才能让我将每个人都升级到.NET 3.5，以便您的应用程序可以运行。换句话说，可能不会发生。我将找到另一个不会给我们已经超负荷的IS部门增加额外"小负担"的应用程序。 有人对您真正要使用的功能发表了评论。如果1.1或2.0具有真实功能集，则需要坚持使用。 您应该使用测试最广泛的.Net版本分发应用程序。如果您一直在.Net 2.0中进行所有开发和测试，请附带2.0。 但是，由于自2.0版本发布以来，该框架中已修复的所有错误，您可能应该欠您的客户针对3.5进行测试并随其一起提供。该框架已经很大，以至于发布早期版本可能没有任何好处，即使它早于WCF，WPF等，除非您付出了分发带宽的代价，或者目标设备的存储空间有限空间。 .net 3.5sp1引导程序太慢，特别是如果您使用的是asp.net应用程序(与Windows窗体相比)，在一台仅包含.net 2.0的计算机中，它会加载整个框架，这意味着您需要20-30适度的互联网连接和机器速度下的分钟下载时间+安装时间。 不要忘记.Net 4.0与该框架的先前版本会有一点不同。 .Net 4.0将并排(SxS).Net 3.5并重新安装。如果您将应用程序升级为使用.Net 4.0，则长期用户(即以前的版本)最终将不得不安装框架的全新版本。 如果您考虑要在客户端计算机上使用应用程序和框架使用多少磁盘空间，请不要忘记这种"隐藏"的额外空间使用。如果您现在将应用程序从2.0升级到3.5，则您的应用程序可能可以使用完整的功能存在更长的时间，而不会强迫用户安装第二个框架，该框架占用了另外20+ MB的空间。 我同意您应该满足应用程序的需求，但也应该为将来的应用程序做准备。 如果您有几个备用周期，则可以在运行3.5 Runtime的SCM中迁移应用程序的单独分支，并且在您实际需要升级时，您可以使用一个分支(假设您将其保持最新状态)。日期，每两周合并一次)。 我想问的一个问题是，您想使用.NET 3.5的哪些功能？许多被炒作的功能实际上是C＃3.0功能，而不是特定于.NET 3.0 / 3.5的功能，并且由于C＃3.0使用与.NET Framework 2.0相同的CLR，因此您也可以在2.0应用程序中自由使用它们。这只需要VS 2008。 例如：
我在自己的.NET 2.0项目中使用了许多此类文件，而没有出现问题。 如果要使用特定于框架的功能(如Linq，WPF等)，则必须进行升级。
我发现2.0版是最容易定位和部署的版本，因为已经有很多人安装了2.0版。如果相当一部分客户使用Vista，则可以考虑升级到3.0版。 编辑："框架版本不再支持"参数不成立，因为3.0是2.0的扩展，而3.5是其扩展。根据定义，只要支持3.5，就支持2.0。版本1.1是唯一一个完全独立的运行时版本，不再受支持。 我同意EBGreen和Chris的观点，但我想补充一点，您可能要考虑针对较新版本的框架测试您的应用程序，并允许您的应用程序在您认为可以很好地使用的那些版本上运行(可以使用某些方法配置技巧，但很遗憾，我找不到对此的引用)。这样，您的应用程序可以针对客户端可能已经安装的版本运行。 我建议这样做是因为： 不过，我仍然缺少一些信息，例如分发方式，客户计算机的配置文件等。 3.5框架是第一个Service Pack版本，因此它比发布后更加稳定，但是请记住，无论出于何种原因，将代码从2.0升级到3.5比将其升级回3.5都容易得多。显示塞子。 Wiki文章很好地展示了新功能。 Linq to SQL功能，实际上，实际上，Linq Extensions非常值得升级。 至于您对高清空间和安装时间的担心，IMO在大多数现代系统上都与较新的框架无关。框架的较新版本(3.0和3.5)实际上只是2.0框架的"刷新"。除非您的客户/市场是较旧的PC，否则我认为您将为开发团队在功能和生产力上取得不错的折衷，而失去客户的风险则可以忽略不计，因为他们无法冒险在硬盘上再增加20Mb( 20mb的号码，有人可以拨打BS。 我很欣赏.NET 3.5中的新语言功能，但是除非您使用它们，否则我将避免升级到最新的运行时，因为它是用户可能必须处理的较大文件/安装。 |
