`
cdragon
  • 浏览: 76241 次
  • 性别: Icon_minigender_1
  • 来自: 北京
最近访客 更多访客>>
社区版块
存档分类
最新评论

.Net Framework各版本(1)

阅读更多

微软,作为全球最有效率的企业之一。自2000年6月22日微软向全球宣布自己的.NET战略,到现在已经十余年了。作为.NET战略的基础,Microsoft .NET Framework 也已经发行了多个版本。下面,我们就来看看这些年来微软到底发布了哪些 .NET Framework 版本,

大量细节见这里

 

 .net 1.0 2002年2月
 .net 2.0 2006年1月
 .net 3.0 2006年11月 
 .net 3.5 2007年11月
 .net 3.5 sp1 2008年8 
 .net 4.0 beta1 2009年5月

 .net 4.0 beta2 2009年10月

 .net 4.0 正式版 2010年4月

 

我们从中可以看出,第一次版本升级中间历时近四年,第二次用时近一年,第三次升级到3.5sp1历时整一年,也就是.net framework的发布周期并非呈现越来越快的趋势,而是恒定在12个月左右。而从3开始,开始出现戏剧性地转变。微软开始真正较为清晰地定义并呈现自已的矩阵计算,到3.5的sp1中发布EF,对ado进行最后修正时,这一过程的初步阶段完成。

 

以上内容,可简单归纳为,

.Net 2.0 = CLR + WinForms + ASP.Net + WebServices
.Net 3.0 = .NET 2.0 + (WPF, WCF, WF, CardSpace)
.Net 3.5 = .Net 3.0 + LINQ + AJAX + REST 

.Net 3.5SP1 = .NET 3.5 + MVC + Dynamic Data + Entity Framework + Data Service

 

这种演进过程,我们可以看这张图 (截止到3.5sp1之前):

 

 

 

下面我们来回顾一篇文章,复习一下.net framework的历程。
 
.NET Framework升级带来的挑战

 

.NET Framework新版本的不断推出,新特性不断增加,需要支持的开发工具也不断升级,对于企业内部的平台构架师来说,也面临着各种抉择:如何规划开发技术策略,如何进行开发技术选型,如何既保持技术的持续性又能充分应用新技术来提高生产力。

 

从2002年微软发布.NET Framework 1.0以来,到现在微软一共发布了5个版本的.NET Framework:.NET FX 1.0、 .NET FX 1.1、.NET FX 2.0、.NET FX 3.0和.NET FX 3.5(Beta 2)。同时还发布了针对移动设备开发的:.NET Compact Framework 1.0和.NET Compact Framework 2.0。

.NET Framework新版本的不断推出,新特性不断增加,需要支持的开发工具也不断升级,对于企业内部的平台构架师来说,也面临着各种抉择:如何规划开发技术策略,如何进行开发技术选型,如何既保持技术的持续性又能充分应用新技术来提高生产力。

 

(一).NET FX 1.0-2.0——初生

2002年,微软发布.NET Framework 1.0,这给软件开发界带来了很多激动人心的特性:

◆统一的类型系统,基础类库,垃圾回收,多语言支持。
◆ADO.NET 1.0开启了微软全新的数据访问技术。
◆ASP.NET 1.0对古老的ASP的变革,提供一种全新的方式来开发Web应用程序。
◆Windows Forms 1.0 把微软开发Windows桌面系统的界面统一在一起。

在.NET 1.0发布之后,很多企业开始转向.NET 1.0的开发。从此软件开发界开始被带上了.NET的道路,同时也不得不面对.NET Framework升级所带来的挑战。

微软在经过3年的研发后,于2005年底发布了.NET 2.0,这次的变化是革命性的。而架构师们也不得不再次进行抉择和调整:

1、ADO.NET 2.0加强了很多功能,提升了性能,能够更好的胜任数据层的开发。尤其Visual Studio的DataSet设计器中TableAdapter的功能可以支持可视化设计数据层,让开发数据层更加容易。对于以数据为中心的软件系统,再也无需使用ORM等辅助工具来开发数据层了。

2、Web Service性能得到提升,并且辅以WSE 3.0,安全性等各方面都得以保证。Web Service作为首选的分布式技术成为可能。

3、泛型和内置泛型集合的支持,和其他基础类库的扩展,可以让内部的公共类库开发更加简化。

4、全新事务机制(System.Transactions)的引入,让整个系统的事务处理更加方便。

 

(二).NET FX 3.0——四大基础

2006年底,微软发布了一个稍显另类的版本——.NET 3.0。这个版本的特殊之处在于,它需要.NET 2.0安装后才能运行。这是因为.NET 3.0是基于.NET 2.0基础上而开发的一套扩展包,它增加了如下组件:

◆ Windows Communication Foundation (WCF)
◆ Windows Workflow Foundation (WF)
◆ Windows Presentation Foundation(WPF)
◆ Windows CardSpace(WCS)

.NET 3.0提供的这些新组件为开发企业应用程序提供了一致的基础框架,这样业务开发人员就只需要专注于业务问题的解决,按照.NET 3.0的规范来编写业务代码。平台构架师面对.NET 3.0,需要考虑的就是如何把.NET 3.0提供的这四个组件,融合到企业现有的开发框架中,以及如何和第三方类似的产品进行协作。



  

(1/WF:支持基于工作流的应用程序

工作流引擎不是什么新技术,但WF的初衷是在Windows环境中提供一个通用的工作流技术,为所有基于工作流的应用程序提供统一的创建基础。

WF支持人员(Human)工作流和系统(System)工作流,也支持连续(Sequential)工作流和状态机(State-Machine)工作流。WF提出了一个重要的概念:活动(Activity),并同时内置了一个基础活动库(Base Activity Library),另外开发人员也可以通过API来自定义自己的活动。

WF利用和Visual Studio集成的可视化设计器来设计工作流过程模型。开发好的工作流过程模型可以运行于WF提供的运行时引擎(Runtime Engine)中。在工作流执行过程中,WF也提供了一系列运行时服务来完成额外的工作,如持久性功能支持工作流的长期运行,跟踪功能获取工作流执行过程的信息。

在WF推出后,平台构架师面临的问题是:WF不是工作流管理平台,仅仅是一个工作流的开发基础和执行引擎,并没有提供组织架构图、窗体与流程设计等套件。所以,平台构架师需要做出如下的抉择:基于WF构建自己的工作流管理平台,还是继续使用第三方的工作流平台?是否需要选用基于WF开发的第三方的工作流平台?如何把WF和现存的工作流平台集成?如何由现存工作流平台移植到WF?

 

(2/WCF:支持面向服务的应用程序

WCF是微软为了统一目前.NET下多个分布式计算技术而提出的,它提供一致的编程模型,通过稳定的结构、极大改进的功能性和互操作性以及可扩展性,全面改善了分布式软件系统的。WCF不仅仅是对以前技术的整合,更多是提供面向服务开发的基础。

WCF的核心思想是服务(Service),一个服务可以暴露一个或多个端点(Endpoint),端点即客户端可以使用的接口。而端点由著名的ABC构成:地址(Address)指定发送消息的目标位置、绑定(Binding)描述如何发送消息、合同(Contract)描述消息所包含的内容。客户端只有获知ABC的信息,才能正确访问服务。

使用WCF,有如下优势:

◆ 统一的模型。
◆ 互操作性,WCF的基本通讯机制是SOAP。
◆ 安全性、可靠性和事务,完善支持WS各类规范。
◆ 兼容性,WCF可以和旧技术实现的系统进行交互。

 

 (3/WPF:适用于不同用户界面的统一方法

用户界面对于应用程序是极其重要的一个部分,随着IT业的发展,用户对界面的要求越来越高。但是在.NET下一直存在着多种界面开发方式:使用Windows Forms开发Windows桌面软件界面,使用ASP.NET开发Web应用程序界面。另外,很多应用程序还需要嵌入文档、视频、实现2D和3D动画。这样,开发人员为了实现不同界面,需要学习不同的技术。是否有一种统一的技术来同时满足不同的需求?

WPF(最初发布的代号为“Avalon”)就是为解决这一问题而设计。WPF为所有的这些用户界面提供一致的技术基础,从而大幅简化了开发人员的工作。WPF 采用更为现代的方法,支持视频、动画、二维或三维图形以及各种类型的文档,从而可以让用户以全新的方式处理信息。此外,WPF 还为桌面客户端和浏览器客户端提供了通用基础,大大简化了二者的应用程序开发工作。

在开发用户界面的过程,人们还遇到一个重要的问题就是:界面逻辑的开发人员,并不擅长定义界面的外观和交互设计。而界面设计人员并不熟悉IDE等工具。因而,界面设计人员和开发人员很难协同工作。为了解决这个问题,WPF引入名为XAML(可扩展标记语言,一种基于XML的语言,允许以声明方式指定用户界面,而非代码)的技术来分离界面定义代码和界面逻辑代码。

WPF给应用程序的界面开发带来的变化是巨大的,可以说WPF代表了未来界面技术的方向。然而在目前的情况下,WPF并没有大规模运用,也没有成为主流,因而平台构架师面临的问题就有点尴尬:既无法把WPF作为唯一选择,也无法很好解决当前界面开发的一些疑难杂症。也许,最好的选择就是:尽量把界面层独立出来,让开发团队开始学习WPF,并逐步尝试使用WPF。

 

(4/WCS:一致的数字标识用户控件

Windows CardSpace,最初的代号叫InfoCard,是微软取代用户ID和密码成为验证网络使用者身份的新方法。实际上就是一项以用户为中心的身份识别技术。用户可以通过它控制登录网站时提交的信息,这将会使管理个人信息更加简便安全。同时这项技术也将包含在Windows Vista之中。微软推广它的目的就是取代传统的用户名和密码,因为它可以提供更好的反钓鱼功能,并且预防其他类型的网络欺骗。

WCS实际上是一个标识元系统,可以支持任何数字标识系统,而发行、获取和使用数字标识的过程可以视作是获取三个不同角色的过程:

◆用户:有时称为主体,用户是具有数字标识的实体。
◆标识提供者:标识提供者可以为用户提供数字标识。
◆依赖方:依赖方是一个应用程序,以某种方式依赖于数字标识。

WCS为这三种实体在标识元系统中进行交互提供了一致的环境。

 

(三).NET FX 3.5——语言的变革(当时3.5正式版本还未发布)

微软将于今年年底发布.NET Framework 3.5,目前大家已经可以获取8月份发布的Beta 2版本。值得说明的是,Beta2已经附带了Go-Live的许可协议,这说明整个.NET 3.5的接口已经冻结。对于一个超前的团队,完全可以把.NET 3.5运用于实际的项目开发了。

 

.NET 3.5有如下3个方面的重要新特性:

◆ASP.NET AJAX,.NET 3.5把之前发布的Ajax扩展包内置到.NET 3.5里面。
◆语言改进和LINQ,具体改进有:自动属性、对象初始化器、集合初始化器、扩展方法、Lambda表达式、查询句法、匿名类型。
◆LINQ to SQL实现的数据访问改进。

 

ASP.NET AJAX几乎不会刁难平台构架师,因为Ajax已经流行很长一段时间,ASP.NET Ajax扩展包已经在大量使用了,.NET 3.5带来的唯一好处就是无需单独部署以前的Ajax扩展包了。

 

语言方面的改进,引入了函数式编程(Functional Programming)的思想,但不会对整个系统构架和企业内部的开发框架产生多大的影响,只会让开发人员编写代码更加灵活和敏捷。

 

LINQ(Language Integrated Query),通过编译器来实现在语言中类似SQL的查询语法,是一个跨时代的底层技术,它的出现让语言能力变得无比的强大。

 

而LINQ to SQL却给平台构架师出了难题:在ADO.NET和LINQ to SQL中如何选择?在第三方ORM和LINQ to SQL如何选择?在LINQ to SQL和未来的ADO.NET EF(Entity Framework)中如何选择?

 

对于第一个问题,由于LINQ to SQL和ADO.NET一样是对数据库结构的映射,那么基于LINQ to SQL来开发数据访问层和ADO.NET的基本做法也大同小异,唯一不同的是LINQ to SQL面对的实体和实体集合,对数据处理无需编写SQL语句。

对于第二个问题,当前版本的LINQ to SQL还仅支持SQL Server,还不足以成为真正意义上的ORM。如果你只使用SQL Server,并且对ORM的要求不高的话,使用LINQ to SQL来代替现有的ORM是可行的。

第三个问题提到的ADO.NET EF是一个实体或概念设计的服务框架,是将现实的实体和实体间的关系映射到对象层,目的是能够更好地支持流行的Domain Model Driven的开发。而LINQ to SQL是和数据库紧密绑定的,无法进行抽象也无法支持多级的继承,更偏重语言层面对数据库的操作。所以说,是选择未来的ADO.NET EF还是LINQ to SQL完全取决于应用系统的规模和设计模式。




                                   wf工作原理                                                           wcf原理

  

 wcs在三种实体中的交互

参见, http://www.net-security.org/secworld.php?id=6424

 

(四).NET FX 3.5sp1——"修理数据"(对原文补充)

  1、ASP.NET动态数据,它提供了丰富的框架,从而使用户可以快速进行数据驱动的开发,而无需编写代码;ASP.NET AJA 的一项新增功能,对管理浏览器历史记录提供了支持(支持后退按钮)。有关更多信息,请参见ASP.NET和Web开发中的新增功能。

  2、对公共语言运行时的核心改进包括:改进了.NET Framework本机映像的布局、选择不再对完全受信任的程序集进行强名称验证、提高了应用程序启动性能、改进了生成的代码以缩短端对端应用程序执行时 间、选择在ASLR(地址空间布局随机化)模式下运行托管代码(如果操作系统支持)。此外,从网络共享打开的托管应用程序在完全受信任环境下运行时与本机 应用程序具有相同的行为。

  3、提高了Windows Presentation Foundation的性能,包括缩短了启动时间,提高了与位图效果有关的性能。WPF的其他新增功能包括:改善了对业务线应用程序、本机初始屏幕、 DirectX 像素着色器的支持,并且新增了WebBrowser控件。

  4、ClickOnce应用程序发行者可以决定在适当情况下不进行签名和加密,开发人员可以编程方式安装ClickOnce应用程序以显示自定义署名,并且ClickOnce错误对话框支持链接到Web上应用程序特定的支持网站。

  5、实体框架是从现有的一套ADO.NET数据访问技术发展而来的。利用实体框架,开发人员可以按照应用程序特定的域模型(而不是基础数据库模型)来针对关系数据库进行编程。有关更多信息,请参见实体框架入门。 实体框架还引入了一些其他功能,包括支持SQL Server 2008的新类型、默认实体图形序列化和实体数据源。在此版本中,实体框架支持SQL Server 2008中的新日期和文件流功能。图形序列化工作可帮助开发人员生成将全部图形建模为数据协定的Windows Communication Foundation (WCF)服务。实体数据源为希望使用实体框架的ASP.NET应用程序构建者提供了传统的数据源体验。

  6、LINQ to SQL新增了对SQL Server 2008中的新日期和文件流功能的支持。

  7、ADO.NET Data Services Framework由满足以下条件的模式和库组合而成:支持将数据公开为一项基于REST(具象状态传输)的灵活数据服务,企业网络内部或整个互联网上的 Web客户端都可以使用该服务。ADO.NET Data Services Framework支持基于任何数据源创建数据服务。通过与 ADO.NET Entity Framework 的充分集成,可以轻松公开基础存储架构的概念视图模型。可以轻松地从任一平台访问使用ADO.NET Data Services Framework创建的服务以及兼容的Windows Live (dev.live.com)服务。针对运行在微软平台上的客户端应用程序提供了一组客户端库,以简化与数据服务的交互。例如,基于.NET Framework的客户端可以使用LINQ查询数据服务,也可以使用简单的.NET Framework对象层更新此服务中的数据。

  8、现在,Windows Communication Foundation改进了对互操作性的支持,增强了部分受信任情况下的调试体验,并且扩展了整合协议支持以便在Web 2.0应用程序中可以进行更广泛的应用,从而使DataContract序列化程序变得更易于使用。

  9、用于SQL Server(SqlClient) 的.NET Framework数据提供程序新增了对SQL Server 2008中的文件流和稀疏列功能的支持。

 

(五).NET FX 4.0——继续前进(补充)

新特征一览:链接一(中文),链接二(英文),链接三(英文)

发布包:链接一

 

附,版本查验
Version Release Date
1.0.3705.0 1.0 RTM 2002-??-??
1.0.3705.209 1.0 SP1 2002-??-??
1.0.3705.288 1.0 SP2 2002-08-07
1.0.3705.6018 1.0 SP3 2004-08-25
1.0.3705.6060 1.0 SP3 (KB928367) 2007-07-10
1.1.4322.573 1.1 RTM 2003-04-03
1.1.4322.2032 1.1 SP1 (MSI-based) 2004-08-30
1.1.4322.2300 1.1 SP1 (OCM-based On Windows Server 2003) 2004-??-??
1.1.4322.2407 1.1 SP1 (KB928366) 2007-07-10

2.0.40607.16 2.0 Beta 1 2004-06-07 ?
2.0.50215.44 2.0 Beta 2 2005-02-15 ?
2.0.50727.42 2.0 RTM 2005-07-27 ?
2.0.50727.832 2.0 RTM (KB928365) 2007-07-10
2.0.50727.1378 2.0 ???  200?-??-??

3.0.04506.26 3.0 RTM (OCM-based On Windows Vista ?) 2006-??-??
3.0.04506.30 3.0 RTM (MSI-based)          (KB932471) 2006-11-21
3.0.04506.590 3.0 ??? 200?-??-??

3.5.20404.??? 3.5 Beta 1 2007-04-24 ?
3.5.20706.1 3.5 Beta 2 2007-07-24
3.5正式版 2007-11
3.5 sp1     2008-08

  使用 Version 对象可以存储和比较程序集的版本号。版本号由二至四个部分组成:主版本号、次版本号、内部版本号和修订号。主版本号和次

版本号是必选的;内部版本号和修订号是可选的,但是如果定义了修订号部分,则内部版本号就是必选的。所有定义的部分都必须是大于等于 0 的整

数。版本号的格式如下所示。可选组件显示在方括号(“[”和“]”)中:

  主版本.次版本[.内部版本[.修订号]]

  Major.Minor[.Build[.Revision]]

  应根据下面的约定使用这些部分:

  主版本:名称相同但主版本号不同的程序集不可互换。例如,这适用于对产品的大量重写,这些重写使得无法实现向后兼容性。
  次版本:如果两个程序集的名称和主版本号相同,而次版本号不同,这指示显著增强,但照顾到了向后兼容性。例如,这适用于产品的修正版

或完全向后兼容的新版本。
  内部版本:内部版本号的不同表示对相同源所作的重新编译。这适合于更改处理器、平台或编译器的情况。
  修订号:名称、主版本号和次版本号都相同但修订号不同的程序集应是完全可互换的。这适用于修复以前发布的程序集中的安全漏洞。
  程序集的只有内部版本号或修订号不同的后续版本被认为是先前版本的修补程序 (Hotfix) 更新。

  上表是我根据网络上相关资料整理的(请参阅文末的“参考资料”),但是这方面的资料比较少,所以还有不少缺漏之处。特别是很多版本的发布日

期无从查找。各位朋友如有知道的,恳请在本文的评论中告诉我(并请给出资料来源),以便将该表补充完整。上表中如有错误的地方,恳请各位朋友指正。谢谢!

  在 IE 浏览器的地址栏输入: “javascript:alert(navigator.userAgent)” (注意:大小写要完全一致)可以查看本机安装了 .NET Framework 的哪些版本。 “User Agent.CN”网站可以查看并分析 User Agent。

 


 

  • 大小: 12.6 KB
  • 大小: 92.9 KB
  • 大小: 16.6 KB
  • 大小: 11.3 KB
  • 大小: 12.3 KB
  • 大小: 25.2 KB
  • 大小: 117.4 KB
分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics