我的应用程序使用2.0。在将来的某个时候，我可能想开始使用在更高的框架版本中添加的较新功能。我应该等到那时吗？还是现在更新到最新的.NET 3.5有优势？

我想我准备为明年春天的4.0版发布的时间就到了。也许我应该在秋季发布时坚持使用2.0，并为客户节省其他框架版本的高清空间和安装时间？

解决方案

回答

我认为，我们应该随应用程序的需求一起交付。否则，我们将无缘无故地延长安装时间，并且正如我们指出的，本质上无缘无故地再次使用客户的HD空间。

回答

我很欣赏.NET 3.5中的新语言功能，但是除非我们使用它们，否则我将避免升级到最新的运行时，因为它是用户可能需要处理的较大文件/安装。

回答

Linq to SQL功能，实际上，实际上，Linq Extensions扩展非常值得升级。

至于我们对高清空间和安装时间的担心，IMO在大多数现代系统上都与较新的框架无关。框架的较新版本(3.0和3.5)实际上只是2.0框架的"刷新"。除非客户/市场是较旧的PC，否则我认为我们将为开发团队在功能和生产力上取得不错的折衷，而失去客户的风险则可以忽略不计，因为他们无法冒险在硬盘上再增加20Mb(我弥补了20mb的号码，有人可以拨打BS。

回答

3.5框架是第一个Service Pack版本，因此它比发布后更加稳定，但是请记住，无论出于何种原因，将代码从2.0升级到3.5比将其升级回3.5都容易得多显示塞子。

Wiki文章很好地展示了新功能。

回答

我们应该使用测试最广泛的版本.Net发行应用程序。如果我们一直在.Net 2.0中进行所有开发和测试，请附带2.0。

但是，由于自2.0版本发布以来，该框架中已修复的所有错误，我们可能应该欠客户针对3.5进行测试并随其一起提供。该框架已经非常庞大，即使发布WCF，WPF等之前的版本，发布早期版本可能也没有任何好处，除非我们为发布它付出了带宽成本，或者目标设备的存储空间有限空间。

回答

我始终使用最新版本的Framework。这可能会给用户带来很小的前期负担，但该应用在两次升级之间的寿命更长。这对我们可能不重要，但请考虑：

如果我们在2005年使用.NET 1.1交付了一个应用程序，则该应用程序所运行的框架现在不在主流支持范围内，并且可能具有未修补的安全漏洞或者Microsoft可能无法解决的其他严重问题，我们无法补偿用你自己的代码。在2008年，我们唯一的选择是让用户立即升级其框架版本。而且，众所周知，让用户及时更新事物可能会成问题。

同样，请考虑我们在2011年的情况。如果现在为.NET 3.5编程，那么出厂时的应用程序将可以使用更长的时间。如果现在为.NET 2.0发货，那么几年后，我们将可以说服用户升级其框架(记住对他们没有好处的代码)，以便正确支持此应用程序。

另外，如果我们计划实现3.5级功能(例如，明年将使用LINQ to SQL)，则现在要以3.5(而不是2.0)的价格发货，这将使我们以后的部署工作不再那么麻烦。

回答

我同意EBGreen和Chris的观点，但我想补充一点，我们可能要考虑针对较新版本的框架测试应用程序，并允许应用程序在我们认为可以很好使用的那些版本上运行(可以使用一些配置技巧，但很遗憾，我找不到对此的引用)。这样，应用程序可以在客户端可能已经安装的版本上运行。

我建议这样做是因为：

• 新的框架版本可能会提高性能。
• 客户端可能已经在其计算机上安装了另一个版本，如我们所说，浪费硬盘驱动器空间实在是可耻的。
• 我们可能希望在将来的某个时间针对较新的框架版本运行应用程序，并且如果客户端已经具有该版本并且正在运行该应用程序的当前版本，则他们的计算机上将没有旧的框架。

不过，我仍然缺少一些信息，例如分发方式，客户计算机的配置文件等。

回答

我发现2.0版是最容易定位和部署的版本，因为已经有很多人安装了2.0版。如果相当一部分客户使用Vista，则可以考虑升级到3.0版。
高于该版本的版本几乎总是需要安装，这对于某些用户而言可能是一件痛苦的事情。

编辑："框架版本不再支持"参数不成立，因为3.0是2.0的扩展，而3.5是其扩展。根据定义，只要支持3.5，就将支持2.0。版本1.1是唯一一个完全独立的运行时版本，不再受支持。

回答

如果打算升级到3.5 SP1，则应考虑使用"新.NET Framework客户端配置文件安装程序包"。

.NET 3.5 SP1为开发人员构建名为.NET Framework Client Profile的.NET客户端应用程序引入了新的安装程序包选项。这提供了一个新的安装程序安装程序，可以为尚未安装.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一起使用。

回答

我想问的一个问题是，我们想使用.NET 3.5的哪些功能？许多被炒作的功能实际上是C3.0功能，而不是特定于.NET 3.0 / 3.5的功能，并且由于C3.0使用与.NET Framework 2.0相同的CLR，因此我们也可以在自己的2.0应用程序中自由使用它们。这只需要VS 2008.

例如：

• Lambda表达式
• 对象初始化器
• 匿名类型
• 局部变量类型推断
• 扩展方式

我在自己的.NET 2.0项目中使用了许多这些文件，而没有出现问题。

如果我们要使用特定于框架的功能(如Linq，WPF等)，则必须进行升级。

回答

我同意我们应该满足应用程序的需求，但也应该为将来的应用程序做准备。

如果我们有几个备用周期，则可以在运行3.5运行时的SCM中迁移应用程序的一个单独分支，并且在实际需要升级时，我们可以使用一个分支(假设我们将其保持最新状态)。与每两周合并一次的日期)。

回答

不要忘记.Net 4.0与该框架的先前版本会有一点不同。 .Net 4.0将并排(SxS).Net 3.5并重新安装。如果我们将应用程序升级为使用.Net 4.0，则长期用户(即以前的版本)最终将不得不安装框架的全新版本。

如果我们考虑要在客户端计算机上使用应用程序和框架使用多少磁盘空间，那么不要忘记这种"隐藏"的额外空间使用。如果我们现在将应用程序从2.0升级到3.5，则应用程序可能可以完整功能存在更长的时间，而不会强迫用户安装第二个框架，该框架占用了另外20+ MB的空间。

回答

请记住，给用户带来的"小负担"可能意味着我们接受和拒绝应用程序之间的区别。

我为一家公司经营IT。我们公司的标准不是3.5. 我们必须拥有一个非常精巧的应用程序，才能让我将每个人都升级到.NET 3.5，以便应用程序可以运行。换句话说，可能不会发生。我会找到另一个不会给我们已经超负荷的IS部门增加额外"小负担"的应用程序。

有人对我们真正要使用的功能发表了评论。如果1.1或者2.0具有真实功能集，则需要坚持使用。

回答

.net 3.5sp1引导程序太慢，特别是如果我们使用的是asp.net应用程序(与Windows窗体相比)，则在仅具有.net 2.0的计算机中，它会加载整个框架，这意味着我们需要20-30适度的互联网连接和机器速度下的分钟下载时间+安装时间。