英文原文: Announcing .NET Framework 4.6.2
原文发表时间: August 2, 2016
今天，我们很高兴地宣布.NET Framework 4.6.2 发布了！许多更改都是基于您的反馈意见，其中包括一些在用户反馈和反馈联系中心提交的意见和建议。非常感谢您的不断的帮助和参与 ！
这次的发布在以下几个方面有着巨大的改进和提升：
在 .NET Framework 4.6.2 的更改列表和 应用程序接口变化集中，你可以查看到所有更改的东西。
立即下载
现在，你可以通过以下途径来下载 .NET Framework 4.6.2:
- .NET Framework 4.6.2 Web 安装程序–最快捷的安装方式，需要连接互联网。
- .NET Framework 4.6.2 脱机安装程序—包括所有的安装程序（包括所有的语言包），不需要连接互联网。
- .NET Framework 4.6.2 开发包—针对于开发和建立环境（包括脱机安装程序和 4.6.2 定向包），不需要连接互联网。
基础库类（BCL）
在 BCL 上进行了以下改进：
支持长路径（MAXPATH）
在 System.IO 的应用程序接口中，我们修复了最长（MAXPATH）文件名称长度为 260 个字符的限制。在用户反馈的问题上，超过 4500 用户提到了该问题。
通常情况下，这种限制不会影响使用者的应用程序 （例如，从”我的文档”中加载文件），但比较常见的是，在开发人员的机器上生成嵌套很深的源码树或着使用专门的工具，还运行在 Unix（经常会用到长路径）。
在 .NET Framework 4.6.2 以及之后的版本上，这个新功能已经启用。您可以通过在 app.config 或者 web.config 等配置文件中进行如下设置，来设置你的应用程序 以定向到 .Net4.6.2：
你可以通过下面的方式来设置 AppContext 开关配置文件，从而将此功能应用到早期版本的 .NET 框架应用程序上面。此开关只支持在 .NET4.6.2 框架上运行的应用程序 （或更高版本）。
在现有的禁止使用路径比 MAXPATH 长的行为中，缺乏定向到 .NET4.6.2 框架或者是设置 AppContext 开关。这是为了维护现有应用程序的向后兼容性。
通过以下改进，使得长路径可以应用︰
- 允许大于 260 字符 (MAX_PATH)的路径。 BCL 组允许路径长度超过 MAX_PATH 最大允许范围。BCL 应用程序接口依赖底层 Win32 文件来进行限制检查。
- 启用扩展路径语法和文件命名空间(
\\?\,\\.\). Windows 公开了多个启用备用路径计划的文件命名空间。例如扩展路径语法，允许超过 32k 的路径字符。BCL 现在支持一些路径，例如︰ \\?\长路径。.NET 框架现在主要依赖于 Windows 路径来进行规范化，以避免无意中阻止合法路径。扩展路径语法是一个很好的解决 Windows 版本不支持使用常规形式的长路径（例如，C:\长路经）的方法。 - 性能改进。通过在 BCL 中采取 Windows 路径规范化以及减少类似的逻辑，使得关于文件路径的逻辑整体性能得到改进。
更多详细的信息，您可以在 Jeremy Kuhne 的博客中找到。
X509 证书现在支持 FIPS 186-3 数字签名算法
.NET 框架 4.6.2 添加了 FIPS 186-3 数字签名算法 (DSA) 的支持。支持密钥长度超过 1024 位的 X509 证书。它还支持计算签名哈希算法系列（SHA256、 SHA384 和 SHA512）。
.NET 框架 4.6.1 支持 FIPS 186-2，但是限制了密钥长度不能超过 1024 位。
通过使用新的 DSACng 类，你可以利用 FIPS 186-3 支持，这可以从下面的示例中看到。
DSA 基类也已经更新，所以您可以使用 FIPS 186-3 的支持而不需要转换到新的 DSACng 类。这与之前两个版本 .NET 框架用于更新 RSA 和 ECDsa 算法实现中的方法相同。
改进的椭圆曲线加密算法派生例程
ECDiffieHellmanCng 类的可用性已得到改进。在 .NET 框架的椭圆曲线加密算法(ECDH) 的密钥协议执行包括三个不同的密钥派生功能(KDF) 例程。这些 KDF 例程现在代表和也被三种不同的方法所支持，你可以从下面的示例中看到。
在 .NET Framework 的早期版本中，对于三个不同的例程，你必须知道每个例程在 ECDiffieHellmanCng 类中需要设置的属性子集。
保存密钥的对称加密支持
Windows 加密库 (CNG) 支持在软件和硬件上保留对称密钥。.NET 框架现在公开了这种 CNG 能力，正如下面的示例中展示的那样。
您需要使用具体的实现类，如 AesCng 类来使用此新功能，而不是更常见的工厂方式，如 Aes.Create ()。这项要求是由于特定于实现的密钥名称和密钥提供者。
在 AesCng TripleDESCng 类中，分别为 AES 和 3DES 算法添加了保存密钥的对称加密。
SignedXml 支持哈希 SHA-2
.NET 框架 SignedXml 实现支持以下 SHA-2 哈希算法
- RSA-SHA256
- RSA-SHA384
- RSA-SHA512 PKCS#1 签名方法
- SHA256
- SHA384
- SHA512 引用摘要算法
你可以在下面的实例中看到使用 SHA-256 对 XML 进行签名。
新的 SignedXml 字段中添加了新的 SignedXML URI 常数。下面显示了新字段。
为了支持这些算法，那些已经注册了自定义的 SignatureDescription 处理程序到 CryptoConfig 的应用程序将会和往常一样继续运作，但是因为现在有平台默认，所以注册 CryptoConfig 已经不再是必须的了。
公共语言运行库（CLR）
在 CLR 做了以下改进。
空引用异常的改进
大家可能都经历过并且调查过空 NullReferenceException 的原因。为了在以后的 Visual Studio 版本中，在空引用方面提供更好的调试体验，我们启用了部分与 Visual Studio 团队合作的方式。
在 Visual Studio 中的调试体验，依赖于与你的代码低水平交互的公共语言运行库调试应用程序接口。现在，在 Visual Studio 中的NullReferenceException 体验看起来是这样︰
在这个版本中，我们扩展了 CLR 调试应用程序接口，当空引用异常弹出时，就可以使得调试器能够请求更多的信息，并且进行额外的分析。利用此信息，调试器就能够确定哪些引用为空，并将这些信息提供给你，使你的工作更加容易。
部署方案
ClickOnce 进行了以下方面的改进。
支持传输层安全(TLS)协议 1.1 和 1.2
在部署方案方面，我们为 .NET Framework 4.5.2，4.6，4.6.1 以及 4.6.2 版本增加了 TLS 1.1 和 1.2 的协议支持。我们要感谢，在用户反馈上面投票的你们！你不需要做任何额外的步骤来启用 TLS 1.1 或 1.2 的支持，因为部署方案会在运行时自动检测哪个 TLS 协议是必需的。
安全套接字层 (SSL) 和 TLS 1.0 不再被一些组织推荐或支持。例如，为了满足他们在线事务的规范，支付卡行业安全标准委员会在为要求 TLS 1.1 或更高版本而努力。
为了兼容那些不会或者不能升级的应用程序，部署方案继续支持 TLS 1.0。我们建议分析您所有使用的 SSL 和 TLS 1.0。请参阅 KB 库，并使用里面的链接来下载修复程序 .NET 框架4. 6，4.6.1和4. 5.2
客户端证书支持
现在可以将部署方案的应用程序托管在虚拟目录中，而这个虚拟目录要求启用了 SSL 并且有客户端证书。在该配置下，当用户访问某个应用程序的时候，将会被提示要选择他们的证书。如果客户端证书被设置为”忽略”，那么部署方案应用程序将不会提示选择证书。
在以前的版本中，虽然应用程序以同样的方式托管，但是应用程序的 ClickOnce 部署最终会被终止，并且弹出拒绝访问错误。
ASP.NET
ASP.NET 中提出了以下改进。请参阅 ASP.NET 核心 1.0 公告，以了解 ASP.NET 核心的具体改进。
本地化数据注释
使用了模型绑定和数据注释验证，使得本地化更加容易。ASP.NET 采用了一个简单的公约，这个公约是针对其中包含数据注释验证消息的 resx 资源文件：
- 位于 App_LocalResources 文件夹
- 按照 DataAnnotation.Localization.{locale}.resx 命名约定。
使用 .NET Framework 4.6.2，你可以在你的模型文件中指定数据注解，就像你在未本地化的应用程序中那样。对于错误提示信息，您可以在使用的资源文件中指定名称，如下所示︰
根据新的约定，你可以看到本地化的资源文件已经被放置在’App_LocalResources’文件夹中，如下图所示︰
您也可以插入自己的 stringlocalizer 提供程序，将本地化字符存储在另外的路径或者另外的文件类型。
在之前版本的 .NET 框架中，你需要指定 ErrorMessageResourceType 和 ErrorMessageResourceNamevalues，如下面所示。
异步的改进
SessionStateModule 和输出缓存模块已得到改进，启用了异步场景。这个团队正在通过 NuGet 来发布两个模块的异步版本，这个需要导入现有项目来使用。这两个 NuGet 程序包预计将在未来几周发布。当发生这种情况，我们将更新这篇文章。
SessionStateModule 接口
当用户导航到 ASP.NET 网站时，会话状态可以存储和检索用户会话数据。现在， 你可以使用新的 SessionStateModule 接口来创建自己的异步会话状态模块，这样你就可以用你自己的方式来存储会话数据， 并且使用异步方法。
输出缓存模块
输出缓存通过从控制器行为中缓存返回结果，可以显著地提高 ASP.NET 应用程序的性能，并且这种缓存方式可以避免对于每个请求，不必要地生成相同的内容。
现在，通过执行一个叫做 OutputCacheProviderAsync 的新接口，你就可以在输出缓存中使用异步应用程序接口。这样做可以减少 Web 服务器上线程阻塞，并提高 ASP.NET 服务的可扩展性。
SQL
SQL 客户端取得了以下方面的改进。
加密功能增强
始终加密功能旨在保护敏感数据，例如存储在数据库中的信用卡号码或身份证号码。它允许客户在对其应用程序内的敏感数据进行加密，永远不会将加密密钥透露给数据库引擎。因此，始终加密将数据拥有着（可以查看这些数据）和数据管理者（没有权限去访问这些数据）进行了分离。
.NET Framework 中的 SQL Server (System.Data.SqlClient) 数据访问程序对于始终加密功能，在性能和安全性方面也进行了改善。
性能
为了提高对加密数据库列的参数化查询性能，查询参数的元数据现在被缓存下来。当 theSqlConnection::ColumnEncryptionQueryMetadataCacheEnabled 属性设置为 true（默认值），即使相同的查询被多次调用， 客户端数据库也都只会从服务器里检索一次元数据参数。
安全
在可配置的时间间隔之外，在密钥缓存中的列加密密钥记录将会被释放。你可以通过设置
SqlConnection::ColumnEncryptionKeyCacheTtl 属性来设置时间间隔。
Windows 通信基础 (WCF)
WCF 做了以下改进。
NetNamedPipeBinding 最佳匹配
在 .NET4.6.2 中，关于支持新管道查找来说，NetNamedPipeBinding 已得到增强，就是我们所熟知“最佳匹配”。在使用 “最佳匹配”时，该 NetNamedPipeBinding 服务将强制客户端，在最佳匹配的 URI 和请求断点之间搜索服务侦听，而不是找到第一个匹配服务。
如果 WCF 客户端应用程序使用默认的”首先匹配”行为，尝试连接到错误的 URI 时，”最佳匹配”是特别有用的。在某些情况下，当多个 WCF 服务在指定的管道上侦听时，WCF 客户端使用”首先匹配”将会连接到错误的服务。如果一些服务是以管理员帐户托管的，这种情况也可能会发生。
若要启用此功能，你可以将以下 AppSetting 添加到客户端应用程序的 App.config 或 Web.config 文件︰
DataContractJsonSerializer 改进
DataContractJsonSerializer 已得到改进，以更好地支持多个夏令时制调整规则。当启用时，DataContractJsonSerializer 将使用 TimeZoneInfo 类，来替代时区类。TimeZoneInfo 类支持多个调整规则，这使得它能够处理历史时区数据。当一个时区有不同的夏令时制调整规则时（例如，（UTC 2）伊斯坦布尔），这是非常有用的。
你可以通过向 app.config 文件中添加以下 AppSetting 启用此功能︰
TransportDefaults 不再支持 SSL 3
在使用包含运输安全和证书信任类型的 NetTcp 设置安全链接时，SSL 3 不再是默认协议。在大多数情况下，不会影响到现有的应用程序，因为对于 NetTcp，自 TLS 1.0 以来一直包括在默认协议列表中。所有现有的客户端至少能够通过 TLS 1.0 进行连接。
SSL3 作为默认协议被移除，因为它不再被认为是安全的。虽然不建议这样做，但如果这是部署所必需的话，你可以通过下面的配置机制将 SSL 3 协定重新添加到协商链接的列表当中：
- SslStreamSecurityBindingElement.SslProtocols 属性
- TcpTransportSecurity.SslProtocols 属性
- <netTcpBinding> 部分的 <transport>
- <customBinding>部分的 <sslStreamSceurity>
Windows 密码库 (CNG) 的传输安全
传输安全现在支持使用 Windows 密码库 (CNG) 存储的证书。目前，该支持仅限于使用一个长度不超过 32 位指数的公钥证书。
这个新功能在 .NET 框架 4.6.2 （或更高版本）的应用程序中可以启用。您可以通过配置以下 app.config 文件或 web.config 配置文件，来配置应用程序定向到 .NET Framework 4.6.2，︰
你可以使用下面的方式设置 AppContext，来使得你选择的之前版本 .NET 的应用程序可以使用此项功能，需要提醒的是，此开关只能够使用到在 .NET4.6.2（或更高版本）上运行的应用程序。
你也可以以编程方式启用此功能︰
OperationContext.Current 的异步改进
WCF 现在有能力使 OperationContext.Current 成为 ExecutionContext 的一部分。通过这一改进，WCF 允许 CurrentContext 从一个线程传播到另一个线程。这意味着，即使在调用到 OperationContext.Current 之间存在情景切换，在执行的整个方法中，它的值也会正确传递。
下面的示例演示 OperationContext.Current 正确流经线程过渡︰
之前，OperationContext.Current 的内部执行是使用 ThreadStatic 变量存储 CurrentContext，使用线程的本地存储区来存储与 CurrentContext 相关的数据。如果执行方法调用的场景发生改变（即，由等待其他操作的线程更改），任何之后的调用将运行在不同的线程，而对原始值没有引用。经过这样的修复之后，第二次调用的 OperationContext.Current 会获取预期的值，尽管 threadId1 和 threadId2 可能会有所不同。
Windows Presentation Foundation (WPF)
WPF 做了如下改进：
分组排序
现在，使用 CollectionView 对数据排序的应用程序可以明确地声明如何进行组排序。这克服了当应用程序动态地添加或删除组，或者是应用程序更改参与分组的项目属性值时一些可能会出现的不直观的排序。通过比较分组中的数据来排序，而不是整个集合的数据，这也提高了创建组的性能。
该功能包括 GroupDescription 类的两个新属性︰ SortDescriptions 和 CustomSort。这些属性描述了如何对使用 GroupDescription 产生的组集合进行排序，在 ListCollectionView 中，也有与之同名的属性描述如何对数据项目进行排序。在 PropertyGroupDescription 类里面有两个新的静态属性，使用最为常见的两个新的静态属性︰ CompareNameAscending 和 CompareNameDescending。
例如，假设应用程序想要按年龄分组，进行升序排列，每个组按照姓氏排序。
应用程序现在可以使用此新功能的声明︰
这个新功能之前，应用程序会如下声明︰
支持同时在不同分辨率的显示器上显示
WPF 应用程序现在启用每个显示器分辨率认知。这个改进对于不同分辨率级别的多个屏幕连接在一台机器上的显示至关重要。在场景不同 DPI 级别的多台显示器相连为一台机器。由于 WPF 应用程序的全部或部分内容会在多个显示器上显示，我们期望 WPF 能够自动将应用程序的分辨率和屏幕进行匹配，现在它真的做到了。
您可以在 WPF 实例和在 GitHub 上的开发人员指南中了解更多有关如何启用您的 WPF 应用程序对每个屏幕分辨率适应功能 。
在以前的版本，你必须编写额外的代码，来启用 WPF 应用程序中每个显示器分辨率的认知。
支持软键盘
软键盘支持能够自动调用和解除 WPF 应用程序中的触摸键盘，而不会在 Win10 操作系统中禁用 WPF 手写/触控支持。
以前的版本里，在不禁用 WPF 手写/触控支持的情况下，WPF 应用程序将不会支持调用或解除触摸键盘。这是由于从 Win8 操作系统开始，应用程序中追踪触摸键盘焦点的方式发生了改变。
您的反馈
最后，我想再次感谢下那些为 4.6.2 预览版本提供反馈的人！它有助于 4.6.2 的发布。请您继续通过以下方式提出反馈意见︰