操作系统Windows98，WindowsNT4.0，WindowsServer2003，WindowsXP，WindowsVista，WindowsServer2008，Windows7，Windows8，WindowsServer2012
类型系统平台
许可协议许可协议Proprietarysoftware
版本完整版本号发行日期VisualStudioWindows默认安装
1.01.0.3705.02002-02-13VisualStudio.NET2002WindowsXPMediaCenterEditionWindowsXPTabletPCEdition
1.11.1.4322.5732003-04-24VisualStudio.NET2003WindowsServer2003
2.02.0.50727.422005-11-07VisualStudio2005
3.03.0.4506.302006-11-06WindowsVistaWindowsServer2008
3.53.5.21022.82007-11-19VisualStudio2008Windows7WindowsServer2008R2
4.04.0.30319.12010-04-12VisualStudio2010
4.54.5.507092012-08-16VisualStudio2012RTMWindows8WindowsServer2012
完整版本号-1.0.3705。这是最初的.NET构架，发行于2002年。它可以以一个独立且可重新分发的包的形式或在一个软件发展工具包集中被获得。它也是第一个微软VisualStudio.NET的发行版的一部分（也被称作VisualStudio.NET2002）。
完整版本号-1.1.4322。这是首个主要的.NetFramework升级版本，发行于2003年。它可以以一个独立的可重新分发的包的形式或在一个软件发展工具包集中被获得。它也是第二个微软VisualStudio.NET版本的一部分（也被称作VisualStudio.NET2003）。它也是首个被Windows操作系统-WindowsServer2003所内置的.NetFramework版本。
自1.0版本以来的改进：
自带了对mobileasp.net控件的支持。这在1.0版本是以附加功能方式实现的，现在已经集成到框架的内部。安全方面的变更-使得Windows窗体代码以可靠的行为运行，从而可以在Internet环境内安全运行，并且加入了ASP.NET应用程序的代码安全访问功能。自带了对ODBC和Oracle数据库的支持。这在1.0版本是以附加功能方式实现的，现在已经集成到框架的内部。.NETCompactFramework-这是一个用于智能设备（例如PocketPC或者SmartPhone）的.NetFramework的子集。对IPv6的支持。大量的API变更。
完整版本号-2.0.50727.42，发行于2005年10月27日。
.NetFramework2.0的组件都包含在VisualStudio2005和SQLServer2005里面。通过MSDNUniverse版可以免费下载RTM版本。自1.1版本以来的改进：大量的API变更。新的API让需要管理.NET运行库实例的非.NET的应用程序可以做到这点。这个新的API对.NET运行库的各种功能，包括：多线程、存储器分配、代码加载等，提供了很好的控制。它最初是为MicrosoftSQLServer能够有效率的使用.NET运行库而设计的，因为MicrosoftSQLServer拥有它自己的日程管理器和存储器管理器。
.NETFramework3.0
此版本不支持Windows2000。
同时，.NETFramework3.5自动包含.NETFramework2.0SP1以及.NetFramework3.0SP1，用于为这两个版本提供安全性修复，以及少量新增的类库（如System.DateTimeOffest）。此版本提供的新功能有：
该版本新增的ASP.NET功能，随VisualStudio2008SP1发布，此版本提供了下列的新功能：
.NETFramework4.0主要增加了并行支持，于2010年4月12日推出。
企业基础.NET提供开发软件的独立平台，自带高度安全的网络系统，相当倚重软件组件以及组件导向程序。在这方面它完全取代前者（COM1）。
此版本不支持Windows2000、WindowsXP。
.NETFramework4.5发行于2012年8月16日，是支持生成和运行下一代应用程序和Web服务的内部Windows组件。.NETFramework的关键组件为公共语言运行时(CLR)和.NETFramework类库（包括ADO.NET、ASP.NET、Windows窗体和WindowsPresentationFoundation(WPF)和WindowsWorkflowFoundation(WF)）。.NETFramework提供了托管执行环境、简化的开发和部署以及与各种编程语言的集成。
.NETforWindowsStoreapps：WindowsMetro风格应用程序为特定窗体因素并利用Windows操作系统的功能。通过使用C#或VisualBasic，.NETFramework4.5的子集可用于生成Windows的Metro风格应用程序。这个子集称为.NETforWindowsStoreapps
更新内容：
在部署期间，能够通过检测和关闭.NETFramework4应用程序来减少系统重启。为大于20GB在64位平台上(GB)的数组支持。此功能可在应用程序配置文件中启用。
通过服务器的背景垃圾回收改进性能。当您使用服务器垃圾回收在.NETFramework4.5中时，后台垃圾回收自动启用。
背景实时(JIT)生成，可以选择可用在多核处理器改进应用程序性能。
能够定义应用程序域的默认区域性。
Unicode(UTF-16)编码的控制台支持。
为版本控制区域性字符串排序和比较数据支持。
通过CustomReflectionContext类，能够自定义反射上下文来重写默认反射行为。
对于国际化域名的2008版在应用程序(IDNA)标准的支持，当System.Globalization.IdnMapping选件类在Windows8使用时。
当.NETFramework在Windows8使用时，到操作系统的字符串比较的委托实现Unicode6.0。在其他平台上运行时，.NETFramework包括其自己的实现Unicode5.x的字符串比较数据。每个应用程序域的基础上能够计算字符串的哈希代码。
ASP.NET动态数据，它提供了丰富的框架，从而使用户可以快速进行数据驱动的开发，而无需编写代码；ASP.NETAJAX的一项新增功能，对管理浏览器历史记录提供了支持（支持后退按钮）。
ClickOnce应用程序发行者可以决定在适当情况下不进行签名和加密，开发人员可以编程方式安装ClickOnce应用程序以显示自定义署名，并且ClickOnce错误对话框支持链接到Web上应用程序特定的支持网站。
实体框架是从现有的一套ADO.NET数据访问技术发展而来的。利用实体框架，开发人员可以按照应用程序特定的域模型（而不是基础数据库模型）来针对关系数据库进行编程。有关更多信息，请参见实体框架入门。实体框架还引入了一些其他功能，包括支持SQLServer2008的新类型、默认实体图形序列化和实体数据源。在此版本中，实体框架支持SQLServer2008中的新日期和文件流功能。图形序列化工作可帮助开发人员生成将全部图形建模为数据协定的WindowsCommunicationFoundation(WCF)服务。实体数据源为希望使用实体框架的ASP.NET应用程序构建者提供了传统的数据源体验。
LINQtoSQL新增了对SQLServer2008中的新日期和文件流功能的支持。
ADO.NETDataServicesFramework由满足以下条件的模式和库组合而成：支持将数据公开为一项基于REST（具象状态传输）的灵活数据服务，企业网络内部或整个互联网上的Web客户端都可以使用该服务。ADO.NETDataServicesFramework支持基于任何数据源创建数据服务。通过与ADO.NETEntityFramework的充分集成，可以轻松公开基础存储架构的概念视图模型。可以轻松地从任一平台访问使用ADO.NETDataServicesFramework创建的服务以及兼容的WindowsLive(dev.live.com)服务。针对运行在微软平台上的客户端应用程序提供了一组客户端库，以简化与数据服务的交互。例如，基于.NETFramework的客户端可以使用LINQ查询数据服务，也可以使用简单的.NETFramework对象层更新此服务中的数据。
现在，WindowsCommunicationFoundation改进了对互操作性的支持，增强了部分受信任情况下的调试体验，并且扩展了整合协议支持以便在Web2.0应用程序中可以进行更广泛的应用，从而使DataContract序列化程序变得更易于使用。
用于SQLServer(SqlClient)的.NETFramework数据提供程序新增了对SQLServer2008中的文件流和稀疏列功能的支持。
安全结构提供了基于用户账号的隔离和访问控制--在这些限制内给予代码完全访问权，并假定由特定用户可运行的代码具有相同的信任度。不幸的是，如果所有程序都代表某用户运行，根据用户对代码的隔离对于保护一个程序不被其它用户使用是不够的。另一种情况，不能被完全信任的代码经常被转移到沙箱模型中执行，在此代码运行于隔离环境，而不会访问大部分的服务。
应用程序的成功的安全解决方案必须能强化两个安全模型间的平衡。它必须提供对资源的访问，以便以完成有用的工作，它需要对应用程序的安全性作细致的控制以确保代码被识别，检测，并给予合适的安全级别。.NETFramework就提供了一个这样的安全模型。
验证将阻止不是类型安全的代码执行，在它们引起破坏前捕获很多常见的编程错误。通常的弱点--如缓存溢出，对任意内存或没有初始化的内存的读取，对控件的随意传送--都不再可能出现。这将使最终用户受益，因为在他们执行代码前对其进行检查。这也有益于开发人员，他们会发现很多常见错误（过去一直在困绕前开发）现在可以查明，并能阻止它们引起破坏。
认证可通过系统或企业逻辑来完成，通过某个API它是或获得的。认证API是完全可扩展的，因此开发人员根据需要使用自己的企业逻辑。开发人员可以对他们的认证需求进行编码，也可以修改底层的认证方法而无需对他们的代码作太大变化。除了微软Windows操作系统身份认证外，还有的认证方法包括基本HTTP，摘要和Kerberos，以及微软Passport和基于窗体的认证。这些认证方法已经完全集成到ASP.NET中了。
.NETFramework提供了一个特殊的功能，隔离存储，用于存储数据，甚至是当不允许对文件进行访问时--例如，当从Internet下载了一个管理控件，并运行它，为它提供了有限的许可权但没有权力读写文件。
隔离存储是一组新的用于.NET支持的用于本地存储的类型和方法。在本质上，每个组合可以访问磁盘上一断被隔离的存储空间。它不允许访问其它数据，隔离存储只对为它创建的组合有效。
隔离存储也可被应用程序用于保存活动记录，保存设置，或者将状态数据保存到磁盘上以备将来之用。因为隔离存储的位置是预先决定好的，所以隔离存储为指定唯一存储空间提供了一种方便的方式，而不需要决定文件路径。
从本地企业局域网获得的代码具有相似的限制，但更少，它可以访问大限额的隔离存储。最后，从受限站点区域（不信任站点）来的代码没有对隔离存储的访问权。
.NETFramework引入了基于证据的安全的概念。在本质上，它是对安全策略暴露出来问题的解答：
组合从哪个站点获得？
组合是.NETFramework应用程序的构件。它们组成了部署，版本控制，重用，激活作用域，安全认证的基本单元。应用程序的组合是从网站上下载到客户端的。
组合是从哪个URL获得的？
安全策略需要明确的地址，而组合是从这个地址下载的。
组合是从哪个区获得的？
区是基于代码的位置，对安全标准，如Internet，intranet和本机等等，的描述。
组合的强名(strongname）是什么？
策略驱动的信任模型使用代码证据
当组合被调入内存进，CLR策略系统通过收集组合的证据并在策略环境中对证据进行计算，从而决定赋予组合什么样的许可权。CLR策略系统然后根据评估过的证据和组合作出的许可请求给予组合一组许可。只有在组合被给予了一组最少的许可后，或组合根本不需要许可权，组合的创建者才能知道组合正确运行。通过一个或多个对特定许可的请求，这样的附加需求可以被传送室策略系统。
根据许可请求的类型，策略系统可以进一步限制给予组合的许可（删除不必要的许可）或甚至拒绝将组合装入内存（如果运行组合所需的最小许可没有被策略给予）。在不存在任何许可请求的情况下，组合永远不会被给予多于策略系统将会给予的许可权限，请求只是进一步限制得到的许可。
创建许可的的过程涉及到对证据的评估，以确定代码组适用于哪个等级：企业，机器，和用户。策略按上面顺序对这三个等级进行评估，然后创建交插了三个等级的许可设置。管理员可以将任何一个策略等级标记为终结（final），这样做应付阻止在其它等级上对策略做进一步评估。例如，管理员可以在机器级别上对组合终止策略，这样就会阻止用户级策略对该组合的应用。
一旦策略完成，许可的最初设置也就创建了。组合通过从三个方面做出特定的请求可以优化这些许可：
第一方面是指定为了使组合运行它必须拥有的最小许可设置。如果这些许可没有给予，那么组合将不同调入到内存，并抛出例外。
第二，可以指定一组可选的许可。尽管组合希望存在这些许可，但如果无法获得这些许可，它仍可以调入到内存。
代码访问安全堆栈遍历可以保护代码不受攻击。在精通的攻击中，恶意代码欺骗受信任代码执行它独自不能运行的操作--有效地利用代码的许可权限实现恶意的目的。对这类攻击，开发人员很难进行防备--但堆栈遍历确保了如果涉及到了低级信任等级的代码，有效许可将被减少到信任等级最低的代码具有的许可。
结果，代码将从源处获得不同的信任等级，并在适合于特定的代码执行环境的限制下运行。
一些活动，如读写文件，显示对话框，读写环境变量，可以通过包含在框架安全构架中的.NETFramework方法实现。这就使.NETFramework能根据安全策略允许或不允许一个操作，而不需要程序员做额外的工作。尽管暴露了保护资源的管理类的创建者在他们的库中做了明确的安全需求，使用.NETFramework类库访问受保护资源的开发人员可以自由地利用代码访问安全系统；他们不必作出明确的安全调用。
管理员可以通过决定给予哪些许可来优化安全策略，然后，依靠.NETFramework处理所有的安全操作。代码访问安全能阻止大部分的恶意攻击，对代码的验证减少了缓存溢出和其它会导致安全攻击的不期望的行为。因此，应用程序和组件生来就受到了保护，它们免于大多数安全问题的冲击，而这些安全问题一直困绕着本地代码的实现。
强迫式安全直接在代码中实现。程序员通过程序采取安全活动，并且根据安全堆栈的状态决定是给予还是拒绝许可。例如，当一个方法请求访问一个特定的文件时，如果调用者（或方法的任何一个调用者）没有被给予必需的许可权限，那么请求失败。因为强迫式安全是通过程序实现的，所以满足了动态需求。如果需要对一个特定文件的访问许可，但该许可还要根据其它信息发生变化，那么，强迫式安全就是可选的解决方案。