针对到 .NET Framework 4.5.x 迁移的运行时更改

本文列出了 .NET Framework 4.5、4.5.1 和 4.5.2 中引入的应用兼容性问题。

.NET Framework 4.5

ASP.NET

AllowCustomPaging 设为 true 的 GridViews 可能在离开视图最后一页时触发 PageIndexChanging 事件

详细信息

.NET Framework 4.5 中的 bug 导致 System.Web.UI.WebControls.GridView.PageIndexChanging 有时在遇到已启用 System.Web.UI.WebControls.GridView.AllowCustomPaging 的 System.Web.UI.WebControls.GridView 时不会触发。

建议

此问题已在 .NET Framework 4.6 中解决，因此升级到该版本的 .NET Framework 即可解决该问题。 作为解决方法，应用可以对任何满足以下条件的 Page_Load 执行显式 BindGrid（System.Web.UI.WebControls.GridView 在最后一页且 LastSystem.Web.UI.WebControls.GridView.PageSize 不同于 System.Web.UI.WebControls.GridView.PageSize）。 或者，可以将应用修改为允许分页（不是自定义分页），因为该方案不演示此问题。

“属性”	值
范围	次要
Version	4.5
类型	运行时

受影响的 API

• GridView.AllowCustomPaging

HttpRequest.ContentEncoding 属性禁止使用 UTF7

详细信息

从 .NET Framework 4.5 开始，System.Web.HttpRequest 正文禁止使用 UTF-7 编码。 在某些情况下，取决于传入的 UTF-7 数据的应用程序数据将不会正确解码。

建议

理想情况下，应更新应用程序，使其在 System.Web.HttpRequest 中不使用 UTF-7 编码。 或者，可以使用 appSettings 元素的 aspnet:AllowUtf7RequestContentEncoding 属性还原旧行为。

“属性”	值
范围	边缘
Version	4.5
类型	运行时

受影响的 API

• HttpRequest.ContentEncoding

HttpUtility.JavaScriptStringEncode 转义 & 号

详细信息

自 .NET Framework 4.5 起，System.Web.HttpUtility.JavaScriptStringEncode(String) 对和号 (&) 字符进行转义。

建议

如果应用依赖于此方法以前的行为，可将 aspnet:JavaScriptDoNotEncodeAmpersand 设置添加到配置文件中的 ASP.NET appSettings 元素。

“属性”	值
范围	次要
Version	4.5
类型	运行时

受影响的 API

• HttpUtility.JavaScriptStringEncode(String)
• HttpUtility.JavaScriptStringEncode(String, Boolean)

不应在自定义功能文件中使用 IPad，因为它现在是浏览器功能

详细信息

自 .NET Framework 4.5 起，iPad 是默认 ASP.NET 浏览器功能文件中的标识符，所以它不应在自定义功能文件中使用

建议

如果需要特定于 iPad 的功能，则需要修改 iPad 行为，具体方法为设置预定义网关 refID“IPad”上的功能，而不是通过用户代理匹配生成新的“IPad”ID。

名称	值
范围	边缘
Version	4.5
类型	运行时

Page.LoadComplete 事件不再导致 System.Web.UI.WebControls.EntityDataSource 控件调用数据绑定

详细信息

LoadComplete 事件不再导致 System.Web.UI.WebControls.EntityDataSource 控件针对 create/update/delete 参数的更改来调用数据绑定。 此更改消除到数据库的外来行程，防止重置控件的值，并生成与其他数据控件一致的行为，例如 System.Web.UI.WebControls.SqlDataSource 和 System.Web.UI.WebControls.ObjectDataSource。 在应用程序依赖于在 LoadComplete 事件中调用数据绑定的极少数情况下，此更改会产生不同的行为。

建议

如果需要数据绑定，请在回发之前的事件中手动调用数据绑定。

“属性”	值
范围	边缘
Version	4.5
类型	运行时

受影响的 API

无法通过 API 分析检测到。

分析 ASP.NET MVC4 应用可能导致严重的执行引擎错误

详细信息

使用 NGEN /Profile 程序集的探查器可能会在启动时使已配置的 ASP.NET MVC4 应用程序出故障，引发“严重的执行引擎异常”

建议

此问题已在 .NET Framework 4.5.2 中解决。 或者，探查器可通过在其事件掩码中指定 COR_PRF_DISABLE_ALL_NGEN_IMAGES 来避免此问题。

“属性”	值
范围	边缘
Version	4.5
类型	运行时

受影响的 API

无法通过 API 分析检测到。

与 ASP.NET StateServer 共享会话状态需要 Web 场中的所有服务器使用相同版本的 .NET Framework

详细信息

启用 System.Web.SessionState.SessionStateMode.StateServer 会话状态时，给定 Web 场中的所有服务器必须使用相同版本的 .NET Framework 以便正确共享状态。

建议

请务必在同时共享状态的 Web 服务器上升级 .NET Framework 版本。

	值
范围	边缘
版本	4.5
类型	运行时

受影响的 API

• SessionStateMode.StateServer

WebUtility.HtmlDecode 不再对无效的输入序列进行解码

详细信息

默认情况下，解码方法不再将无效的输入序列解码为无效的 UTF-16 字符串。 相反，它们将返回原始的输入。

建议

仅当你存储二进制数据而不是字符串中的 UTF-16 数据时，解码器输出中的更改才会起作用。 要显式控制此行为，请将 appSettings 元素的 aspnet:AllowRelaxedUnicodeDecoding 特性设置为 true 以启用旧行为，或设置为 false 以启用当前行为。

	值
范围	次要
版本	4.5
类型	运行时

受影响的 API

• WebUtility.HtmlDecode(String)
• WebUtility.HtmlDecode(String, TextWriter)
• WebUtility.UrlDecode(String)

核心

使用 Regex.CompileToAssembly 进行编译的程序集在 4.0 和 4.5 之间中断

详细信息

如果已编译的正则表达式的程序集使用 .NET Framework 4.5 生成但却面向 .NET Framework 4，则在安装了 .NET Framework 4 的系统上尝试使用该程序集的正则表达式之一时，将引发异常。

建议

若要解决此问题，可执行下列操作之一：

• 使用 .NET Framework 4 生成包含正则表达式的程序集。
• 使用已解释的正则表达式。

“属性”	值
范围	次要
Version	4.5
类型	运行时

受影响的 API

• Regex.CompileToAssembly(RegexCompilationInfo[], AssemblyName)
• Regex.CompileToAssembly(RegexCompilationInfo[], AssemblyName, CustomAttributeBuilder[])
• Regex.CompileToAssembly(RegexCompilationInfo[], AssemblyName, CustomAttributeBuilder[], String)

BlockingCollection<T>.TryTakeFromAny 不会再引发任何异常

详细信息

如果其中一个输入集合标记为已完成，则 TryTakeFromAny(BlockingCollection<T>[], T) 不会再返回 -1，TakeFromAny(BlockingCollection<T>[], T) 也不会再引发异常。 当其中一个集合为空或已完成，但其他集合仍具有可检索的项时，可通过此更改来使用这些集合。

建议

如果在阻止集合已完成的情况下，在 TryTakeFromAny 返回 -1 或 TakeFromAny 引发异常时用于控制流，此类代码现在应改为使用 .Any(b => b.IsCompleted) 检测该条件。

“属性”	值
范围	次要
Version	4.5
类型	运行时

受影响的 API

• BlockingCollection<T>.TakeFromAny(BlockingCollection<T>[], T)
• BlockingCollection<T>.TakeFromAny(BlockingCollection<T>[], T, CancellationToken)
• BlockingCollection<T>.TryTakeFromAny(BlockingCollection<T>[], T)
• BlockingCollection<T>.TryTakeFromAny(BlockingCollection<T>[], T, Int32)
• BlockingCollection<T>.TryTakeFromAny(BlockingCollection<T>[], T, TimeSpan)
• BlockingCollection<T>.TryTakeFromAny(BlockingCollection<T>[], T, TimeSpan)

带有超时自变量的 Task.WaitAll 方法的行为更改

详细信息

Task.WaitAll 行为在 .NET Framework 4.5 中变得更加一致。在 .NET Framework 4 中，这些方法的行为不一致。 当超时到期时，如果在调用此方法之前已完成或已取消一个或多个任务，则此方法会引发 System.AggregateException 异常。 在超时到期时，如果在调用此方法之前尚未完成或取消任何任务，但在调用此方法之后，一个或多个任务进入了这些状态，则该方法返回 false。

在 .NET Framework 4.5 中，如果在超时时间间隔到期时仍有任务在运行，这些方法重载现在将返回 false；仅当取消某个输入任务（无论是在方法调用之前还是之后取消）且没有任务仍在运行时，它们才将引发 System.AggregateException 异常。

建议

如果 System.AggregateException 已捕获作为检测在调用 WaitAll 之前已取消的任务的方法，该代码应通过 IsCanceled 属性（例如：.Any(t => t.IsCanceled)）执行相同的检测操作，因为 .NET Framework 4.6 仅当所有等待任务在超时前均已完成时才会引发。

	值
范围	次要
版本	4.5
类型	运行时

受影响的 API

• Task.WaitAll(Task[], Int32)
• Task.WaitAll(Task[], Int32, CancellationToken)
• Task.WaitAll(Task[], TimeSpan)

编译器支持多定向 mscorlib 时的类型转发

详细信息

利用新的 CodeDOM 功能，编译器可以针对 mscorlib.dll 的目标版本而不是 mscorlib.dll 的 .NET Framework 4.5 版本进行编译。

“属性”	值
范围	边缘
Version	4.5
类型	运行时

受影响的 API

无法通过 API 分析检测到。

ConcurrentQueue<T>.TryPeek 可通过 out 参数返回错误的 null

详细信息

在某些多线程情况下，System.Collections.Concurrent.ConcurrentQueue<T>.TryPeek(T) 可返回 true，但使用 null 值填充 Out 参数（而非正确的扫视值）。

建议

此问题已在 .NET Framework 4.5.1 中解决。 升级到该 Framework 即可解决该问题。

“属性”	值
范围	主要
Version	4.5
类型	运行时

受影响的 API

• ConcurrentQueue<T>.TryPeek(T)

ETW EventListeners 无法从具有显式关键字的提供程序中（例如 TPL 提供程序）捕获事件

详细信息

具有空白关键字掩码的 ETW EventListeners 无法从具有显式关键字的提供程序中正确捕获事件。 在 .NET Framework 4.5 中，TPL 提供程序开始提供显式关键字，引发了此问题。 在 .NET Framework 4.6 中，EventListeners 已更新，此问题不再存在。

建议

若要解决此问题，请将调用 EnableEvents(EventSource, EventLevel) 替换为调用 EnableEvents 重载，以显式指定要使用的“任意关键字”掩码：EnableEvents(eventSource, level, unchecked((EventKeywords)0xFFFFffffFFFFffff))。

此外，此问题已在 .NET Framework 4.6 中解决，因此升级到该版本的 .NET Framework 即可解决该问题。

“属性”	值
范围	边缘
Version	4.5
类型	运行时

受影响的 API

• EventListener.EnableEvents(EventSource, EventLevel)

System.Threading.Tasks.Task 未观察处理中的异常不再在终接器线程上传播

详细信息

由于 System.Threading.Tasks.Task 类表示异步操作，它捕获在异步处理过程中出现的所有非严重异常。 在 .NET Framework 4.5 中，如果未观察到异常，且代码绝不会等待任务，则异常将不再在终结器线程上传播并在垃圾回收期间不会导致进程崩溃。 此更改增强了使用 Task 类执行未观察到的异步处理的应用程序的可靠性。

建议

如果应用依赖于未观察到的异步异常传播到终接器线程，可通过向 UnobservedTaskException 事件提供相应的处理程序，或通过设置运行时配置元素来还原以前的行为。

“属性”	值
范围	边缘
Version	4.5
类型	运行时

受影响的 API

• Task.Run(Action)
• Task.Run(Action, CancellationToken)
• Task.Run(Func<Task>)
• Task.Run(Func<Task>, CancellationToken)
• Task.Run<TResult>(Func<TResult>)
• Task.Run<TResult>(Func<TResult>, CancellationToken)
• Task.Run<TResult>(Func<Task<TResult>>)
• Task.Run<TResult>(Func<Task<TResult>>, CancellationToken)
• Task.Start()
• Task.Start(TaskScheduler)

List.Sort 算法已更改

详细信息

从 .NET Framework 4.5 开始，System.Collections.Generic.List<T> 的排序算法就已更改（为内省排序而不是快速排序）。 System.Collections.Generic.List<T> 的排序一直都不稳定，但此更改可能会导致各种方案以不稳定的方式进行排序。 这仅仅意味着等效项目可能会在随后的 API 调用中按不同顺序排序。

建议

由于旧的排序算法也不稳定（尽管方式略有不同），因此应该没有代码依赖于始终按特定顺序排序的等效项。 如果有代码实例依赖于此等效项，并且可以幸运地使用旧行为，则此代码应更新为使用按照所需顺序对项进行确定性排序的比较器。

“属性”	值
范围	透明
Version	4.5
类型	运行时

受影响的 API

• List<T>.Sort()
• List<T>.Sort(IComparer<T>)
• List<T>.Sort(Comparison<T>)
• List<T>.Sort(Int32, Int32, IComparer<T>)

在 4.0 行为中缺少了目标框架名字对象结果

详细信息

未在程序集级别应用 System.Runtime.Versioning.TargetFrameworkAttribute 的应用程序将通过使用 .NET Framework 4.0 的语义 (quirks) 自动运行。 为了确保高质量，建议所有二进制文件均通过 System.Runtime.Versioning.TargetFrameworkAttribute 显式属性化，以指示用于生成它们的 .NET Framework 版本。 请注意，在项目文件中使用目标框架名字对象将使 MSBuild 自动应用 System.Runtime.Versioning.TargetFrameworkAttribute。

建议

应通过以下方法提供 System.Runtime.Versioning.TargetFrameworkAttribute：将该属性直接添加到程序集，或者在项目文件中或通过 Visual Studio 的项目属性 GUI 指定目标框架。

“属性”	值
范围	主要
Version	4.5
类型	运行时

受影响的 API

无法通过 API 分析检测到。

一些 .NET API 会导致最可能的（已处理）EntryPointNotFoundExceptions

详细信息

在 .NET Framework 4.5 中，少量 .NET 方法开始引发最可能的 System.EntryPointNotFoundException。 这些异常在 .NET Framework 内进行处理，但可能会中断不希望出现最可能的异常的测试自动化。 启用 HighVersionLie 后，这些相同的 API 会中断一些 ApiVerifier 方案。

建议

升级到 .NET Framework 4.5.1 可避免此 bug 出现。 还可以更新测试自动化以便不中断对最可能的 System.EntryPointNotFoundException 异常的操作。

	值
范围	边缘
版本	4.5
类型	运行时

受影响的 API

• Debug.Assert(Boolean)
• Debug.Assert(Boolean, String)
• Debug.Assert(Boolean, String, String)
• Debug.Assert(Boolean, String, String, Object[])
• XmlSerializer(Type)

释放对象后，System.Threading.Tasks.Task 不再引发 ObjectDisposedException

详细信息

除 IAsyncResult.AsyncWaitHandle 外，System.Threading.Tasks.Task 方法在处置对象后不再引发 System.ObjectDisposedException 异常。此更改支持使用缓存任务。 例如，方法会返回一个缓存任务来表示已完成的操作，而不是分配新任务。 在以前的 .NET Framework 版本中无法执行此操作，因为任务的任何使用者都可以处置它（呈现为不可用）。

建议

请注意，如果释放对象，Task 方法可能不再引发 System.ObjectDisposedException。 如果某个应用依靠此异常了解任务是否已释放，应对其进行更新以使用 Status 显式检查任务状态。

“属性”	值
范围	次要
Version	4.5
类型	运行时

受影响的 API

无法通过 API 分析检测到。

System.Uri 转义现在支持 RFC 3986

详细信息

.NET Framework 4.5 中对 URI 转义做了更改，可支持 RFC 3986。 具体更改包括：

• System.Uri.EscapeDataString(String) 根据 RFC 3986 转义保留字符。
• System.Uri.EscapeUriString(String) 未转义保留字符。
• 如果 System.Uri.UnescapeDataString(String) 遇到无效的转义序列，则它不会引发异常。
• 未保留的转义字符已取消转义。

建议

• 更新应用程序，以便在出现无效转义序列时不依赖于要引发 System.Uri.UnescapeDataString(String)。 此类序列现在必须直接进行检测。
• 同样，预计转义和非转义 URI 和数据字符串在 .NET Framework 4.0 和 .NET Framework 4.5 中可能会有所不同，并且这些字符串不应直接在各种 .NET 版本中进行比较。 而在对这些字符串进行任何比较前，应在单个 .NET 版本中对其进行分析和规范化。

“属性”	值
范围	次要
Version	4.5
类型	运行时

受影响的 API

• Uri.EscapeDataString(String)
• Uri.EscapeUriString(String)
• Uri.UnescapeDataString(String)

数据

Sql_variant 数据使用 sql_variant 排序规则而不是数据库排序规则

详细信息

sql_variant 数据使用 sql_variant 排序规则而不是数据库排序规则。

建议

如果数据库排序规则与 sql_variant 排序规则不同，则此更改将解决可能的数据损坏。 依赖损坏的数据的应用程序可能会失败。

“属性”	值
范围	透明
Version	4.5
类型	运行时

受影响的 API

无法通过 API 分析检测到。

SqlBulkCopy 对字符串使用目标列编码

详细信息

将数据插入列中时，System.Data.SqlClient.SqlBulkCopy 使用目标列的编码而不是 VARCHAR 和 CHAR 类型的默认编码。 在目标列未使用默认编码时，此更改会消除使用此默认编码所引起的数据损坏的可能性。 在极少数情况下，如果对编码进行的更改所生成的数据过大而无法适应目标列，则现有应用程序可能会引发 SqlException 异常。

建议

System.Data.SqlClient.SqlBulkCopy 应不再因为编码差异而损坏数据。 如果复制了接近目标列大小限制的字符串，那么可能需要预编码数据（复制该数据以检查数据是否适合目标列）或者捕获 System.Data.SqlClient.SqlException。

“属性”	值
范围	边缘
Version	4.5
类型	运行时

受影响的 API

• System.Data.SqlClient.SqlBulkCopy
• SqlBulkCopy(SqlConnection)

SqlConnection 可以不再连接到 SQL Server 1997 或使用 VIA 适配器的数据库

详细信息

不再支持使用虚拟接口适配器 (VIA) 协议连接到 SQL Server 数据库。 连接字符串中可以见到用于连接到 SQL Server 数据库的协议。 VIA 连接将包含 via:<servername>。 如果此应用通过协议而不是 VIA（例如 tcp: 或 np:）连接到 SQL，则不会遇到中断的更改。 此外，也不再支持连接到 SQL Server 7 (1997)。

建议

VIA 协议已弃用，因此，应使用备用协议连接到 SQL 数据库。 使用的最常见的协议是 TCP/IP。 若要详细了解如何通过 TCP/IP 进行连接，请参阅对数据库实例启用 TCP/IP 协议。 如果只能从 Intranet 访问数据库，在网络速度慢时，共享的管道协议可能会提供更好的性能。

“属性”	值
范围	边缘
Version	4.5
类型	运行时

受影响的 API

• SqlConnection(String)
• SqlConnection(String, SqlCredential)

SqlConnection.Open 在存在非 IFS Winsock BSP 或 LSP 的 Windows 7 中会失败

详细信息

如果在存在非 IFS Winsock BSP 或 LSP 的 Windows 7 计算机上运行，Open() 和 OpenAsync(CancellationToken) 在 .NET Framework 4.5 中将会失败。若要确定是否安装了非 IFS BSP 或 LSP，请使用 netsh WinSock Show Catalog 命令，并查看每个返回的 Winsock Catalog Provider Entry 项。 如果服务标志值设置了 0x20000 位，提供程序将使用 IFS 句柄，并将正确运行。 如果 0x20000 位已清除（未设置），则它将是非 IFS BSP 或 LSP。

建议

此 bug 已在 .NET Framework 4.5.2 中得到修复，因此升级 .NET Framework 可避免出现此问题。 或者，可通过删除任何已安装的非 IFS Winsock LSP 来避免出现此问题。

“属性”	值
范围	次要
Version	4.5
类型	运行时

受影响的 API

• SqlConnection.Open()
• SqlConnection.OpenAsync(CancellationToken)

调试器

在执行后一个步骤时才能在调试器中看到空联合器值

详细信息

在 64 位版本的 Framework 上运行时，.NET Framework 4.5 中的 bug 导致在执行分配操作后无法立即在调试器中看到通过空联合操作设置的值。

建议

在调试器中多单步执行一次将正确更新本地/字段的值。 另外，此问题已在 .NET Framework 4.6 中解决；因此升级到该版本的 Framework 即可解决该问题。

“属性”	值
范围	边缘
Version	4.5
类型	运行时

受影响的 API

无法通过 API 分析检测到。

Entity Framework

数据定义语言 (DDL) API 行为的更改

详细信息

指定 AttachDBFilename 时，DDL API 的行为已更改，具体如下：

• 连接字符串不需要指定 Initial Catalog 值。 以前，需要 AttachDBFilename 和 Initial Catalog。
• 如果指定了 AttachDBFilename 和 Initial Catalog，并且存在给定的 MDF 文件，DatabaseExists 方法将返回 true。 以前，它会返回 false。
• 如果指定了 AttachDBFilename 和 Initial Catalog，并且存在给定的 MDF 文件，则调用 DeleteDatabase 方法会删除这些文件。
• 如果在连接字符串指定一个 AttachDBFilename 值，且不存在 MDF 和 Initial Catalog 时调用 DeleteDatabase，则该方法将引发 InvalidOperationException 异常。 以前，它会引发 SqlException 异常。

建议

利用这些更改，可以更轻松地生成使用 DDL API 的工具和应用程序。 这些更改会影响以下方案中的应用程序兼容性：

• 如果 DROP DATABASE 返回 DeleteDatabase，则用户会编写直接执行 DatabaseExists 命令而不是调用 true 的代码。 如果未附加数据库但存在 MDF 文件，则会中断现有代码。
• 用户编写的代码预期 DeleteDatabase 方法在 Initial Catalog 和 MDF 文件不存在时引发 SqlException 而非 InvalidOperationException。

“属性”	值
范围	次要
Version	4.5
类型	运行时

受影响的 API

无法通过 API 分析检测到。

ObjectContext.CreateDatabase 和 DbProviderServices.CreateDatabase 方法处理异常的方式不同

详细信息

从 .NET Framework 4.5 开始，如果数据库创建失败，CreateDatabase 方法将尝试删除空数据库。 如果该操作成功，将传播原始 System.Data.SqlClient.SqlException（而非始终在 .NET Framework 4.0 中引发的 System.InvalidOperationException）

建议

在执行 CreateDatabase() 或 CreateDatabase(DbConnection, Nullable<Int32>, StoreItemCollection) 时如果捕获到 System.InvalidOperationException，现在也应会捕获到 SQLExceptions。

“属性”	值
范围	次要
Version	4.5
类型	运行时

受影响的 API

• ObjectContext.CreateDatabase()
• DbProviderServices.CreateDatabase(DbConnection, Nullable<Int32>, StoreItemCollection)

EntityFramework 6.0 在从 Visual Studio 启动的应用中会非常缓慢地加载

详细信息

从 Visual Studio 2013 启动使用 EntityFramework 6.0 的应用可能会非常缓慢。

建议

此问题已在 EntityFramework 6.0.2 中解决。 更新 EntityFramework，避免出现此性能问题。

“属性”	值
范围	边缘
Version	4.5
类型	运行时

受影响的 API

无法通过 API 分析检测到。

ObjectContext.CreateDatabase 方法创建的日志文件名已更改，以匹配 SQL Server 规范

详细信息

当直接调用 System.Data.Objects.ObjectContext.CreateDatabase() 方法或通过使用 Code First 与 SqlClient 提供程序以及连接字符串中的 AttachDBFilename 值来调用此方法时，它将创建一个名为 filename_log.ldf 而非 filename.ldf 的日志文件（其中 filename 是 AttachDBFilename 值指定的文件的名称）。 此更改通过提供根据 SQL Server 规范命名的日志文件来改进调试。

建议

如果日志文件名对应用而言很重要，应更新该应用，以使用标准的 _log.ldf 文件名格式。

	值
范围	边缘
版本	4.5
类型	运行时

受影响的 API

• ObjectContext.CreateDatabase()

ObjectContext.Translate 和 ObjectContext.ExecuteStoreQuery 现在支持枚举类型

详细信息

在 .NET Framework 4.0 中，ObjectContext.Translate 和 ObjectContext.ExecuteStoreQuery 方法的泛型参数 T 不能是枚举类型。 现在支持这种情况。

建议

如果在 .NET Framework 4.0 的枚举类型上调用了 Translate 或 ExecuteStoreQuery，则返回“0”。 如果需要该行为，调用应替换为常数 0（或其枚举等效项）。

“属性”	值
范围	边缘
Version	4.5
类型	运行时

受影响的 API

• ObjectContext.Translate<TElement>(DbDataReader)
• ObjectContext.Translate<TEntity>(DbDataReader, String, MergeOption)
• ObjectContext.ExecuteStoreQuery<TElement>(String, Object[])
• ObjectContext.ExecuteStoreQuery<TEntity>(String, String, MergeOption, Object[])

LINQ

Enumerable.Empty<TResult> 始终返回缓存的实例

详细信息

从 .NET Framework 4.5 开始，Empty<TResult>() 始终返回缓存的内部实例 IEnumerable<T>。以前，在调用 API 时，Empty<TResult>() 将缓存空 IEnumerable<T>，这意味着在同时快速调用 Empty<TResult>() 的某些情况下，针对 API 的不同调用将返回不同的类型实例。

建议

因为以前的行为不确定，所以代码不太可能依赖它。 但是，如果出现需要比较空枚举并希望它们有时不相等这一罕见情形，应创建显式空数组 (new T[0])，而非使用 Empty<TResult>()。

“属性”	值
范围	边缘
Version	4.5
类型	运行时

受影响的 API

• Enumerable.Empty<TResult>()

Managed Extensibility Framework (MEF)

MEF 目录实现 IEnumerable，因此不能再用于创建序列化程序

详细信息

从 .NET Framework 4.5 开始，MEF 目录实现 IEnumerable，因此不能再用于创建序列化程序（System.Xml.Serialization.XmlSerializer 对象）。 尝试对 MEF 目录进行序列化会引发异常。

建议

不能再使用 MEF 创建序列化程序

“属性”	值
范围	主要
Version	4.5
类型	运行时

受影响的 API

无法通过 API 分析检测到。

网络

在 .NET Framework 4.5 下序列化的 MailMessage 对象进行反序列化可能会失败

详细信息

从 .NET Framework 4.5 开始，MailMessage 对象可以包含非 ASCII 字符。 在 .NET Framework 4 中，仅支持 ASCII 字符。 包含非 ASCII 字符并在 .NET Framework 4.5 或更高版本下序列化的 MailMessage 对象不能在 .NET Framework 4 下进行反序列化。

建议

请确保在反序列化 MailMessage 对象时，代码会提供异常处理。

“属性”	值
范围	次要
Version	4.5
类型	运行时

受影响的 API

• System.Web.Mail.MailMessage

System.Net.PeerToPeer.Collaboration 在 Windows 8 上不可用

详细信息

System.Net.PeerToPeer.Collaboration 命名空间在 Windows 8 或更高版本上不可用。

建议

支持 Windows 8 或更高版本的应用必须进行更新，才能不依赖于此命名空间或其成员。

“属性”	值
范围	主要
Version	4.5
类型	运行时

受影响的 API

• System.Net.PeerToPeer.Collaboration

打印

写入到 PrintSystemJobInfo.JobStream 的数据必须采用 XPS 格式

详细信息

JobStream 属性公开打印作业的流。 通过写入到此流，用户可以将原始数据发送到基础操作系统打印组件。从 Windows 操作系统的 Windows 8 和更高版本上的 .NET Framework 4.5 起，写入到此流的数据必须采用作为包流的 XPS 格式。

建议

若要输出打印内容，可以执行下列任一操作：

• 使用 XpsDocumentWriter 类输出打印内容。 这是建议的替代项。
• 确保发送给 JobStream 属性返回的流的数据作为包流采用 XPS 格式。

“属性”	值
范围	次要
Version	4.5
类型	运行时

受影响的 API

• PrintSystemJobInfo.JobStream

序列化

BinaryFormatter 可能无法从 LoadFrom 上下文找到类型

详细信息

自 .NET Framework 4.5 起，大量 System.Xml.Serialization.XmlSerializer 更改可能在使用 System.Runtime.Serialization.Formatters.Binary.BinaryFormatter 反序列化 LoadFrom 上下文中负载的类型时导致反序列化出现差异。 这些更改由新的方式引起，System.Xml.Serialization.XmlSerializer 现在加载了一种类型，可以在 System.Runtime.Serialization.Formatters.Binary.BinaryFormatter 稍后尝试反序列化为该类型时，导致其他行为。 默认序列化活页夹虽然在某些情况下可以基于 XmlSerializer 旧行为工作，但它不会自动搜索 LoadFrom 上下文。 由于这些更改，当从其他上下文加载的程序集加载类型时，可能引发 System.IO.FileNotFoundException。

警告

使用 BinaryFormatter 的二进制序列化可能很危险。 有关详细信息，请参阅 BinaryFormatter 安全指南。

建议

如果显示此异常，则 System.Runtime.Serialization.Formatters.Binary.BinaryFormatter 的 Binder 属性可以设为将查找正确类型的自定义活页夹。

var formatter = new BinaryFormatter { Binder = new TypeFinderBinder() }

然后自定义活页夹：

public class TypeFinderBinder : SerializationBinder
{
    private static readonly string s_assemblyName = Assembly.GetExecutingAssembly().FullName;

    public override Type BindToType(string assemblyName, string typeName)
    {
        return Type.GetType(String.Format(CultureInfo.InvariantCulture, "{0}, {1}", typeName, s_assemblyName));
    }
}

“属性”	值
范围	边缘
Version	4.5
类型	运行时

受影响的 API

• System.Runtime.Serialization.Formatters.Binary.BinaryFormatter
• BinaryFormatter.Deserialize(Stream)
• BinaryFormatter.Deserialize(Stream, HeaderHandler)

SoapFormatter 无法反序列化哈希表和类似有序的集合对象

详细信息

System.Runtime.Serialization.Formatters.Soap.SoapFormatter 不保证在一个 .NET Framework 版本下进行序列化的对象能够在其他版本下成功反序列化。 具体而言，某些有序集合（例如 System.Collections.Hashtable）已在 4.0 和 4.5 中添加了成员，如果这些类型的对象在 .NET Framework 4.5 中进行了序列化，它们在 .NET Framework 4.0 中将无法反序列化。 请注意，如果序列化的数据在同一 .NET Framework 版本中进行序列化和反序列化，将不会发生任何问题。

建议

应使用 System.Runtime.Serialization.Formatters.Binary.BinaryFormatter 序列化或 System.Runtime.Serialization.NetDataContractSerializer 替换 System.Runtime.Serialization.Formatters.Soap.SoapFormatter 序列化以适应 .NET Framework 的更改。

警告

使用 BinaryFormatter 的二进制序列化可能很危险。 有关详细信息，请参阅 BinaryFormatter 安全指南。

名称	值
范围	次要
Version	4.5
类型	运行时

受影响的 API

• SoapFormatter.Serialize(Stream, Object)
• SoapFormatter.Serialize(Stream, Object, Header[])
• SoapFormatter.Deserialize(Stream)
• SoapFormatter.Deserialize(Stream, HeaderHandler)

当所序列化的类型使用不可访问成员来隐藏可访问的成员时，XmlSerializer 失败

详细信息

在序列化派生类型时，如果该类型包含不可访问的字段或属性，即（通过“new”关键字）隐藏之前基类型上可访问的同名字段或属性（例如，public），则 System.Xml.Serialization.XmlSerializer 可能会失败。

建议

可以通过使新的隐藏成员可供 System.Xml.Serialization.XmlSerializer 访问（例如，将其标记为公开）来解决此问题。 或者，以下配置设置将还原为 4.0 System.Xml.Serialization.XmlSerializer 行为，这将解决该问题：

<system.xml.serialization>
<xmlSerializer useLegacySerializerGeneration="true" />
</system.xml.serialization>

名称	值
范围	次要
Version	4.5
类型	运行时

受影响的 API

• XmlSerializer.Serialize(Stream, Object)
• XmlSerializer.Serialize(TextWriter, Object)
• XmlSerializer.Serialize(Object, XmlSerializationWriter)
• XmlSerializer.Serialize(XmlWriter, Object)
• XmlSerializer.Serialize(Stream, Object, XmlSerializerNamespaces)
• XmlSerializer.Serialize(TextWriter, Object, XmlSerializerNamespaces)
• XmlSerializer.Serialize(XmlWriter, Object, XmlSerializerNamespaces)
• XmlSerializer.Serialize(XmlWriter, Object, XmlSerializerNamespaces, String)
• XmlSerializer.Serialize(XmlWriter, Object, XmlSerializerNamespaces, String, String)

Web 应用程序

锁定承载来自 .NET Framework 1.1 和 2.0 的控件的托管浏览器

详细信息

Internet Explorer 中阻止对这些控件的承载。

建议

Internet Explorer 将无法启动使用用于承载控件的托管浏览器的应用程序。 通过将注册表子项 HKLM/SOFTWARE/MICROSOFT/.NETFramework 的 EnableIEHosting 值设置为 1（对于 x86 系统和 x64 系统上的 32 位处理器），并将注册表子项 HKLM/SOFTWARE/Wow6432Node/Microsoft/.NETFramework 的 EnableIEHosting 值设置为 1（对于 x64 系统上的 64 位处理器），可以还原之前的行为。

“属性”	值
范围	次要
Version	4.5
类型	运行时

受影响的 API

无法通过 API 分析检测到。

Windows Communication Foundation (WCF)

maxRequestLength 或 maxReceivedMessageSize 的错误代码是不同的

详细信息

Internet Information Services (IIS) 或 ASP.NET 开发服务器承载的 WCF Web 服务中的消息如果超过 maxRequestLength（在 ASP.NET 中）或 maxReceivedMessageSize（在 WCF 中），则有不同的错误代码。HTTP 状态代码已从 400（错误请求）更改为 413（请求实体太大），并且超过 maxRequestLength 或 maxReceivedMessageSize 设置的消息引发了 System.ServiceModel.ProtocolException 异常。 这包括转换模式为“流式处理”的情况。

建议

在消息长度超过 ASP.NET 或 WCF 所允许的限制的情况下，此更改有利于调试。必须基于 HTTP 400 状态代码修改执行处理的任何代码。

“属性”	值
范围	边缘
Version	4.5
类型	运行时

受影响的 API

无法通过 API 分析检测到。

System.ServiceModel.Web.WebServiceHost 对象不再添加默认终结点

详细信息

如果显式终结点已由应用程序代码添加，则 WebServiceHost 对象不再添加默认终结点。

建议

如果用户希望能够连接到默认终结点，并且其他显式终结点已添加到 System.ServiceModel.Web.WebServiceHost，则还应显式添加默认终结点（使用 System.ServiceModel.ServiceHostBase.AddDefaultEndpoints()）。

“属性”	值
范围	次要
Version	4.5
类型	运行时

受影响的 API

• ServiceHost.AddServiceEndpoint(Type, Binding, String)
• ServiceHost.AddServiceEndpoint(Type, Binding, Uri)
• ServiceHost.AddServiceEndpoint(Type, Binding, String, Uri)
• ServiceHost.AddServiceEndpoint(Type, Binding, Uri, Uri)
• ServiceHost.AddServiceEndpoint(Type, Binding, Uri, Uri)
• ServiceHostBase.AddServiceEndpoint(ServiceEndpoint)
• ServiceHostBase.AddServiceEndpoint(String, Binding, String)
• ServiceHostBase.AddServiceEndpoint(String, Binding, Uri)
• ServiceHostBase.AddServiceEndpoint(String, Binding, String, Uri)
• ServiceHostBase.AddServiceEndpoint(String, Binding, Uri, Uri)

默认情况下，禁用 OData URL 中的 Replace 方法

详细信息

从 .NET Framework 4.5 开始，默认会禁用 OData URL 中的 Replace 方法。 在禁用 OData Replace 时（现在是默认设置），任何包含 replace 函数的用户请求（这并不常见）都将失败。

建议

如果需要 replace 方法（这并不常见），可通过配置设置 (System.Data.Services.Configuration.DataServicesFeaturesSection.ReplaceFunction) 重新启用。 但是，启用的 replace 方法可能会带来安全漏洞，应仅在仔细检查后使用。

“属性”	值
范围	边缘
Version	4.5
类型	运行时

受影响的 API

• System.Data.Services.DataService<T>

Windows 窗体

如果 PreviewLostKeyboardFocus 的处理程序显示 Windows 窗体消息框，将重复调用它

详细信息

从 .NET Framework 4.5 开始，在消息框关闭时，从 PreviewLostKeyboardFocus 处理程序中调用 MessageBox.Show 将重新触发该处理程序，从而可能会导致消息框无限循环出现。

建议

有两种选项可以解决此问题：

• 调用 MessageBox.Show（而非 MessageBox.Show）可避免此问题出现。
• 在 LostKeyboardFocus 事件处理程序中显示消息框可避免此问题出现（这与 System.Windows.UIElement.PreviewLostKeyboardFocus 事件处理程序的情况不同）。

“属性”	值
范围	边缘
Version	4.5
类型	运行时

受影响的 API

• ContentElement.PreviewLostKeyboardFocus
• IInputElement.PreviewLostKeyboardFocus
• UIElement.PreviewLostKeyboardFocus
• UIElement3D.PreviewLostKeyboardFocus

对于 System.Drawing，WinForm 的 CheckForOverflowUnderflow 属性现在为 true

详细信息

System.Drawing.dll 程序集的 CheckForOverflowUnderflow 设置为 true。

建议

之前在发生溢出时，结果会在不提示的情况下被截断。 现在引发了 System.OverflowException 异常。

“属性”	值
范围	边缘
Version	4.5
类型	运行时

受影响的 API

无法通过 API 分析检测到。

Windows Presentation Foundation (WPF)

从 DataGrid 的 UnloadingRow 事件的处理程序访问 WPF DataGrid 的选定项可能会导致 NullReferenceException

详细信息

由于 .NET Framework 4.5 中的 bug，涉及删除行的 DataGrid 事件的事件处理程序如果访问 DataGrid 的 System.Windows.Controls.Primitives.Selector.SelectedItem 或 System.Windows.Controls.Primitives.MultiSelector.SelectedItems 属性，可能会导致引发 System.NullReferenceException。

建议

此问题已在 .NET Framework 4.6 中解决，因此升级到该版本的 .NET Framework 即可解决该问题。

“属性”	值
范围	次要
Version	4.5
类型	运行时

受影响的 API

• DataGrid.UnloadingRow
• DataGrid.UnloadingRowDetails

从 CellEditEnding 处理程序调用 DataGrid.CommitEdit 将丢失焦点

详细信息

从 System.Windows.Controls.DataGrid 的一个 System.Windows.Controls.DataGrid.CellEditEnding 事件处理程序中调用 CommitEdit() 导致 System.Windows.Controls.DataGrid 失去焦点。

建议

此 bug 已在 .NET Framework 4.5.2 中得到修复，因此升级 .NET Framework 可避免出现此问题。 或者，可通过在调用 System.Windows.Controls.DataGrid.CommitEdit() 后显式重新选择 System.Windows.Controls.DataGrid 避免出现此问题。

“属性”	值
范围	边缘
Version	4.5
类型	运行时

受影响的 API

• DataGrid.CommitEdit()
• DataGrid.CommitEdit(DataGridEditingUnit, Boolean)

在选定项目的 WPF ListBox、ListView 或 DataGrid 上调用 Items.Refresh 可能会导致元素中出现重复项目

详细信息

在 .NET Framework 4.5 中，在项目已在 System.Windows.Controls.ListBox 中选定的同时从代码中调用 ListBox.Items.Refresh 可能会导致选定项目在列表中重复。 System.Windows.Controls.ListView 和 System.Windows.Controls.DataGrid 会出现类似问题。 此问题已在 .NET Framework 4.6 中解决。

建议

在调用 System.Windows.Data.CollectionView.Refresh() 前以编程方式取消选择项，然后在调用完成后重新选择它们，可以解决此问题。 此外，此问题已在 .NET Framework 4.6 中解决，因此升级到该版本的 .NET Framework 即可解决该问题。

	值
范围	次要
版本	4.5
类型	运行时

受影响的 API

• CollectionView.Refresh()

FlowDocument 可能显示额外的文本行

详细信息

在某些情况下，当 FlowDocument 元素在 .NET Framework 4.5 上运行时，可能显示额外的文本行，这是与它在 .NET Framework 4.0 上运行时显示的不同之处。 暂未出现已知的案例显示此更改导致任意文本难以阅读或显示不明，但是它可能导致出现之前 FlowDocument 视图中忽略的文本。

建议

在某些情况下，减少一个显示元素的 PageHeight 属性可能还原之前显示的行数。

“属性”	值
范围	边缘
Version	4.5
类型	运行时

受影响的 API

• FlowDocument()
• FlowDocument(Block)
• FlowDocumentReader()
• FlowDocumentPageViewer()
• DocumentPageView()

从 .NET Framework 4.5 开始，GlyphRun.ComputeInkBoundingBox() 和 FormattedText.Extent 返回不同的值

详细信息

.NET Framework 4.5 改进了 ComputeInkBoundingBox() 和 Extent，以解决在 .NET Framework 4.0 中，框在某些情况下因过小而无法包含字形的问题。 因此，从 .NET Framework 4.5 开始，某些范围框将更大，从而使 UI 布局产生细微差异。

建议

请注意，某些字形范围框大小已增加。 这些更改通常会改进展示和点击框测试，但如果需要使用旧（.NET 4.5 之前的）行为，可通过以下条目添加到 app.config 文件进行选择：

<appsettings>
<add key="IncludeAllInkInBoundingBox" value="false">
</appsettings>

“属性”	值
范围	边缘
Version	4.5
类型	运行时

受影响的 API

• GlyphRun.ComputeInkBoundingBox()
• FormattedText.Extent

使用自定义 DataTemplates 时，在 ItemsControls（例如 ListBox 和 DataGrid）内间歇性无法滚动到底部项目

详细信息

在某些情况下，使用自定义 DataTemplates 时，.NET Framework 4.5 中的 bug 引起 ItemsControls（例如 System.Windows.Controls.ListBox、System.Windows.Controls.ComboBox、System.Windows.Controls.DataGrid 等）无法滚动到底部项。 如果再次尝试滚动（在可重新滚动后），将可以滚动。

建议

此问题已在 .NET Framework 4.5.2 中解决，升级到该版本（或更高版本）的 .NET Framework 即可解决该问题。 或者，用户仍可将滚动条拖动至这些集合中的最后几个项目，但可能需要尝试两次才能成功。

“属性”	值
范围	次要
Version	4.5
类型	运行时

受影响的 API

无法通过 API 分析检测到。

Items.Clear 不会从 SelectedItems 删除重复项

详细信息

假设选择器（已启用多个选择）在其 System.Windows.Controls.Primitives.MultiSelector.SelectedItems 集合中有多个重复项（出现不止一次的相同项）。 从数据源删除这些项（例如通过调用 Items.Clear）不会从 System.Windows.Controls.Primitives.MultiSelector.SelectedItems 删除它们；仅删除第一个实例。 此外，随后使用 System.Windows.Controls.Primitives.MultiSelector.SelectedItems（例如 SelectedItems.Clear()）可能会遇到 System.ArgumentException 等问题，这是因为 System.Windows.Controls.Primitives.MultiSelector.SelectedItems 包含不再出现在数据源中的项。

建议

如果可能请升级到 .NET Framework 4.6.2。

“属性”	值
范围	次要
Version	4.5
类型	运行时

受影响的 API

• MultiSelector.SelectedItems

ObservableCollection<T>.Move 的 ListBoxItem IsSelected 绑定问题

详细信息

在绑定到有选中项的 System.Windows.Controls.ListBox 的集合上调用 Move(Int32, Int32) 或 MoveItem(Int32, Int32) 可能导致未来选择或不选 System.Windows.Controls.ListBox 项的不稳定行为。

建议

调用 System.Collections.ObjectModel.Collection<T>.Remove(T) 和 System.Collections.ObjectModel.Collection<T>.Insert(Int32, T)（而不是 Move(Int32, Int32)）将解决此问题。 此外，此问题已在 .NET Framework 4.6 中解决，因此升级到该版本的 .NET Framework 即可解决该问题。

“属性”	值
范围	次要
Version	4.5
类型	运行时

受影响的 API

• ObservableCollection<T>.Move(Int32, Int32)
• ObservableCollection<T>.MoveItem(Int32, Int32)

WPF PageRangeSelection 中的新枚举值

详细信息

两个新成员（System.Windows.Controls.PageRangeSelection.CurrentPage 和 System.Windows.Controls.PageRangeSelection.SelectedPages）已添加到 System.Windows.Controls.PageRangeSelection 枚举。

建议

大多数情况下，这些更改不会影响用户代码。 但是，应该修改依赖于对 System.Windows.Controls.PageRangeSelection 类型的 GetNames(Type) 或 GetValues(Type) 调用中所存在特定数量元素的代码。

“属性”	值
范围	边缘
Version	4.5
类型	运行时

受影响的 API

• System.Windows.Controls.PageRangeSelection

如果 PreviewLostKeyboardFocus 的处理程序显示 Windows 窗体消息框，将重复调用它

详细信息

从 .NET Framework 4.5 开始，在消息框关闭时，从 PreviewLostKeyboardFocus 处理程序中调用 MessageBox.Show 将重新触发该处理程序，从而可能会导致消息框无限循环出现。

建议

有两种选项可以解决此问题：

• 调用 MessageBox.Show（而非 MessageBox.Show）可避免此问题出现。
• 在 LostKeyboardFocus 事件处理程序中显示消息框可避免此问题出现（这与 System.Windows.UIElement.PreviewLostKeyboardFocus 事件处理程序的情况不同）。

“属性”	值
范围	边缘
Version	4.5
类型	运行时

受影响的 API

• ContentElement.PreviewLostKeyboardFocus
• IInputElement.PreviewLostKeyboardFocus
• UIElement.PreviewLostKeyboardFocus
• UIElement3D.PreviewLostKeyboardFocus

右键单击 WPF DataGrid 行标题更改 DataGrid 选择

详细信息

在选中多行时，右键单击所选的 System.Windows.Controls.DataGrid 行标题会导致 System.Windows.Controls.DataGrid 更改为仅选择该行。

建议

此问题已在 .NET Framework 4.6 中解决，因此升级到该版本的 .NET Framework 即可解决该问题。

“属性”	值
范围	边缘
Version	4.5
类型	运行时

受影响的 API

• DataGrid()

在 VirtualizingStackPanel 中滚动 WPF TreeView 或分组 ListBox 可能会导致应用程序停止响应

详细信息

在 .NET Framework v4.5 中，如果在视区中有边距（例如，在 System.Windows.Controls.TreeView 中的项之间，或在 ItemsPresenter 元素上），则在一个虚拟化的堆叠面板中滚动WPF System.Windows.Controls.TreeView 会导致应用程序停止响应。 此外，在某些情况下，即使没有边距，视图中不同大小的项目也可能会导致不稳定性。

建议

升级到 .NET Framework 4.5.1 可避免此 bug 出现。 或者，如果包含的所有项目大小相同，可从虚拟化堆叠面板的视图集合（例如 System.Windows.Controls.TreeView）中删除边距。

“属性”	值
范围	主要
Version	4.5
类型	运行时

受影响的 API

• VirtualizingStackPanel.SetIsVirtualizing(DependencyObject, Boolean)

WPF DataTemplate 元素现在对 UIA 可见

详细信息

以前 System.Windows.DataTemplate 元素对 UI 自动化不可见。 从 4.5 开始，UI 自动化将能检测到这些元素。 这在许多情况下很有用，但可能会中断依赖于不包含 System.Windows.DataTemplate 元素的 UIA 树的测试。

建议

此应用的 UI 自动化测试需要更新，以便考虑到 UIA 树现在所包含的以前不可见的 System.Windows.DataTemplate 元素。 例如，对于预计某些元素彼此相邻的测试，现在需要考虑到其间之前不可见的 UIA 元素。 否则，依赖 UIA 元素的特定计数或索引的测试可能需要使用新值进行更新。

“属性”	值
范围	边缘
Version	4.5
类型	运行时

受影响的 API

• DataTemplate()
• DataTemplate(Object)

WPF DispatcherSynchronizationContext.CreateCopy 现在返回新副本，而非当前实例

详细信息

在 .NET Framework 4 中，CreateCopy() 返回当前实例的引用，这主要作为一项性能优化。 在 .NET Framework 4.5 中，它返回新实例，这可以首次得出结论：相同的引用指示执行线程位于正确的同步上下文中。 检查这些引用标识的代码可能不受影响，但由于此更改，作为迁移到 .NET Framework 4.5 或更高版本的一部分，应测试调用 CreateCopy() 的代码。

建议

请注意，CreateCopy() 现在将返回新的 System.Threading.SynchronizationContext 对象。 以前，使用按此方法所生成引用的等效项的代码实际上不会检查它是否在正确的上下文中，但针对 .NET Framework 4.5 或更高版本生成时则会检查。 虽然不太可能产生问题，但执行受影响的代码路径应足以确定这是否会带来任何问题。

“属性”	值
范围	次要
Version	4.5
类型	运行时

受影响的 API

• DispatcherSynchronizationContext.CreateCopy()

WPF 文本框默认撤消限制是 100

详细信息

在 .NET Framework 4.5 中，WPF 文本框的默认撤消限制是 100（.NET Framework 4.0 则没有限制）

建议

如果 100 的撤消限制过低，可使用 UndoLimit 显式设置该限制

“属性”	值
范围	边缘
Version	4.5
类型	运行时

受影响的 API

• System.Windows.Controls.TextBox

WPF 文本框选定文本在文本框处于非活动状态时，将显示其他颜色

详细信息

在 .NET Framework 4.5 中，当 WPF 文本框控件处于非活动状态（该控件没有焦点）时，文本框中选定文本所显示的颜色与该控件处于活动状态时所显示的颜色不同。

建议

可通过将 AreInactiveSelectionHighlightBrushKeysSupported 属性设置为 false 来还原以前的 (.NET Framework 4.0) 行为。

“属性”	值
范围	边缘
Version	4.5
类型	运行时

受影响的 API

• System.Windows.Controls.TextBox

WPF TreeViewItem 必须在 TreeView 内使用

详细信息

4\.5 中引入了一项更改，即限制在 System.Windows.Controls.TreeView 外使用 System.Windows.Controls.TreeViewItem 元素。 在下列条件下，可能会出现这种情况：

• System.Windows.Controls.TreeViewItem 的视觉父级不是面板。 （为 System.Windows.Controls.TreeView 生成的 System.Windows.Controls.TreeViewItem 将有一个面板作为其父级）
• System.Windows.Controls.TreeViewItem 是充当列表控件（ListBox、DataGrid、ListView 等）“项目主机”的 System.Windows.Controls.VirtualizingStackPanel 的后代。 无需启用虚拟化。
• System.Windows.Controls.VirtualizingStackPanel 进行项滚动 (ScrollUnit="Item")。
• 有些用户调用 VirtualizingStackPanel.MakeVisible(v) 以将元素 v 滚动至视图。 这可通过许多方法显式或隐式实现；或许最常见的方法是，只需单击 v 即可为其提供键盘焦点。
• 视觉父链贯穿整个 System.Windows.Controls.TreeViewItem，范围从 v 到 System.Windows.Controls.VirtualizingStackPanel。

换言之，在 System.Windows.Controls.TreeView 之外使用 System.Windows.Controls.TreeViewItem，并且用户单击 System.Windows.Controls.TreeViewItem 的某个后代以显示它后，便可显示。 如果 System.Windows.Controls.TreeViewItem 的后代都没有焦点，将永远不会遇到此问题。 例如，如果 System.Windows.Controls.TreeViewItem 是 DataTemplate 的根，则会出现此问题。 发生此问题时，WPF 框架中将引发 InvalidCastException。

建议

将向此问题提供修补程序。

“属性”	值
范围	次要
Version	4.5
类型	运行时

受影响的 API

无法通过 API 分析检测到。

Windows Workflow Foundation (WF)

System.Activities 现在是 APTCA

详细信息

该程序集用 System.Security.AllowPartiallyTrustedCallersAttribute 特性标记。

建议

无法使用 System.Security.SecurityCriticalAttribute 标记派生类。 以前，派生类型必须使用 System.Security.SecurityCriticalAttribute 进行标记。 但是，此更改不应有实际影响。

“属性”	值
范围	边缘
Version	4.5
类型	运行时

受影响的 API

无法通过 API 分析检测到。

WF 现在采用不同方式序列化 Expressions.Literal<T> DateTimes（中断自定义 XAML 分析器）

详细信息

关联的 ValueSerializer 对象将一个 System.DateTime 或 System.DateTimeOffset 对象（其 Second 和 System.DateTime.Millisecond 组件非零且（针对 System.DateTime 值）且其 Kind 属性不是 Unspecified）转换为属性元素语法而不是字符串。 此更改允许 System.DateTime 和 System.DateTimeOffset 值往返。 假定输入 XAML 是采用特性语法的自定义 XAML 分析器将无法正常运行。

建议

此更改允许 System.DateTime 和 System.DateTimeOffset 值往返。 假定输入 XAML 是采用特性语法的自定义 XAML 分析器将无法正常运行。

“属性”	值
范围	边缘
Version	4.5
类型	运行时

受影响的 API

无法通过 API 分析检测到。

XML、XSLT

XmlSchemaException 现在正确设置行位置

详细信息

如果将 SetLineInfo 值传递给 Load 方法并发生验证错误，则 LineNumber 和 LinePosition 属性现在包含行信息。

建议

应该更新假设不设置 LineNumber 和 LinePosition 的异常处理代码，因为这些属性将会在加载 XML 且使用 SetLineInfo 的时候正确设置。

“属性”	值
范围	边缘
Version	4.5
类型	运行时

受影响的 API

• LoadOptions.SetLineInfo

XmlTextReader DTD 实体扩展限制为 10,000,000 个字符

详细信息

DTD 实体扩展现在限制为 10,000,000 个字符。 加载不带 DTD 实体扩展或带有限的 DTD 实体扩展的 XML 文件不受影响。 包含了扩展到 10,000,000 个字符以上的 DTD 实体的文件将无法加载，且会立即引发异常。

建议

如果 DTD 实体扩展的限制低于 10,000,000，该值可使用 MaxCharactersFromEntities 属性重写。 可以将具有适当 System.Xml.XmlReaderSettings.MaxCharactersFromEntities 值的 System.Xml.XmlReaderSettings 传递给采用 System.Xml.XmlReaderSettings 的 XmlReader.Create（即 Create(String, XmlReaderSettings))

名称	值
范围	边缘
Version	4.5
类型	运行时

受影响的 API

• System.Xml.XmlTextReader
• XmlTextReader()
• XmlTextReader(Stream)
• XmlTextReader(Stream, XmlNameTable)
• XmlTextReader(Stream, XmlNodeType, XmlParserContext)
• XmlTextReader(TextReader)
• XmlTextReader(TextReader, XmlNameTable)
• XmlTextReader(String)
• XmlTextReader(String, Stream)
• XmlTextReader(String, Stream, XmlNameTable)
• XmlTextReader(String, TextReader)
• XmlTextReader(String, TextReader, XmlNameTable)
• XmlTextReader(String, XmlNameTable)
• XmlTextReader(String, XmlNodeType, XmlParserContext)
• XmlTextReader(XmlNameTable)

XSLT 向前兼容现在有效

详细信息

在 .NET Framework 4 中，XSLT 1.0 向前兼容性具有以下问题：

• 如果其版本设置为 2.0，并且分析器遇到无法识别的 XSLT 1.0 构造，则无法加载样式表。
• 如果样式表版本设置为 1.1，则 xsl:sort 构造无法对数据排序。在 .NET Framework 4.5 中，这些问题已修复，XSLT 1.0 向前兼容模式正常运行。

建议

大多数应用应该不受影响，但由于遵循 xsl:sort，某些情况下数据排序将会不同。 如果在 1.1 样式表中使用 xsl:sort，请确定应用不依赖于未排序数据。 如果应用依赖于 4.0 排序行为，请从样式表删除 xsl:sort。

“属性”	值
范围	边缘
Version	4.5
类型	运行时

受影响的 API

• System.Xml.Xsl.XslCompiledTransform

XSLT 样式表异常消息已更改

详细信息

在 .NET Framework 4.5 中，XSLT 文件过于复杂时显示的错误消息文本为“样式表太复杂”。在先前版本中，错误消息为“XSLT 编译错误”。取决于错误消息文本的应用程序代码将不再有效。 但是，异常类型保持不变，因此，此更改应该不会造成实际影响。

建议

根据此错误条件发出的异常消息更新任何应用代码，以收到新消息，或者（最好是）更新代码以仅依赖于未更改的异常类型 (System.Xml.Xsl.XsltException)。

“属性”	值
范围	边缘
Version	4.5
类型	运行时

受影响的 API

• XslCompiledTransform.Load(String)
• XslCompiledTransform.Load(Type)
• XslCompiledTransform.Load(XmlReader)
• XslCompiledTransform.Load(IXPathNavigable)
• XslCompiledTransform.Load(MethodInfo, Byte[], Type[])
• XslCompiledTransform.Load(String, XsltSettings, XmlResolver)
• XslCompiledTransform.Load(XmlReader, XsltSettings, XmlResolver)
• XslCompiledTransform.Load(IXPathNavigable, XsltSettings, XmlResolver)

.NET Framework 4.5.1

ADO.NET

ADO.NET 现在尝试自动重连已中断的 SQL 连接

详细信息

从 .NET Framework 4.5.1 开始，.NET Framework 将尝试自动重新连接已中断的 SQL 连接。 虽然这通常会使应用更可靠，但在少数情况下，应用需要知道连接已断开，以便重新连接时可采取一些操作。

建议

如果由于兼容性问题而不希望使用此功能，则可通过将连接字符串（或 System.Data.SqlClient.SqlConnectionStringBuilder）的 System.Data.SqlClient.SqlConnectionStringBuilder.ConnectRetryCount 属性设置为 0 来禁用此功能。

“属性”	值
范围	边缘
Version	4.5.1
类型	运行时

受影响的 API

• IDbConnection.ConnectionString
• SqlConnection.ConnectionString
• ConnectionStringSettings.ConnectionString
• DbConnection.ConnectionString
• DbConnectionStringBuilder.ConnectionString
• SqlConnectionStringBuilder()
• SqlConnectionStringBuilder(String)
• DbConnectionStringBuilder()
• DbConnectionStringBuilder(Boolean)

核心

在 .NET Framework 4.5 中使用 NetDataContractSerializer 序列化的 ConcurrentDictionary 无法通过 .NET Framework 4.5.1 或 4.5.2 反序列化

详细信息

由于对类型作了内部更改，因此在 .NET Framework 4.5 中使用 System.Runtime.Serialization.NetDataContractSerializer 序列化的 ConcurrentDictionary<TKey,TValue> 对象无法在 .NET Framework 4.5.1 或 .NET Framework 4.5.2 中反序列化。注意，反之则可行（可以通过 .NET Framework 4.5.x 序列化，然后通过 .NET Framework 4.5 反序列化）。 同样，使用 .NET Framework 4.6 可以实现所有 4.x 的跨版本序列化，单个版本的 .NET Framework 的序列化和反序列化不受影响。

建议

如果需要在 .NET Framework 4.5 和 .NET Framework 4.5.1/4.5.2 之间序列化和反序列化 System.Collections.Concurrent.ConcurrentDictionary<TKey,TValue>，应使用 System.Runtime.Serialization.DataContractSerializer 之类的不同序列化程序，而非使用 System.Runtime.Serialization.NetDataContractSerializer。 或者，由于此问题已在 .NET Framework 4.6 中解决，因此升级件到该版本的 .NET Framework 即可解决该问题。

名称	值
范围	次要
Version	4.5.1
类型	运行时

受影响的 API

无法通过 API 分析检测到。

ConcurrentQueue<T>.TryPeek 可通过 out 参数返回错误的 null

详细信息

在某些多线程情况下，System.Collections.Concurrent.ConcurrentQueue<T>.TryPeek(T) 可返回 true，但使用 null 值填充 Out 参数（而非正确的扫视值）。

建议

此问题已在 .NET Framework 4.5.1 中解决。 升级到该 Framework 即可解决该问题。

“属性”	值
范围	主要
Version	4.5
类型	运行时

受影响的 API

• ConcurrentQueue<T>.TryPeek(T)

探查器未枚举 COR_PRF_GC_ROOT_HANDLEs

详细信息

在 .NET Framework v4.5.1 中，分析 API RootReferences2() 错误地不会返回 COR_PRF_GC_ROOT_HANDLE（而是返回 COR_PRF_GC_ROOT_OTHER）。 此问题已从 .NET Framework 4.6 开始修复。

建议

此问题已在 .NET Framework 4.6 中解决，因此升级到该版本的 .NET Framework 即可解决该问题。

“属性”	值
范围	次要
Version	4.5.1
类型	运行时

受影响的 API

无法通过 API 分析检测到。

跨应用域的对象的反序列化可能失败

详细信息

在某些情况下，当应用使用两个或更多带有不同应用程序基的应用域时，尝试跨应用域在逻辑调用上下文中为对象反序列化将引发异常。

建议

请参阅缓解措施：跨应用域的对象反序列化

“属性”	值
范围	边缘
Version	4.5.1
类型	运行时

受影响的 API

无法通过 API 分析检测到。

EventListener 将截断带有嵌入 NULL 的字符串

详细信息

System.Diagnostics.Tracing.EventListener 将截断带有嵌入的 null 的字符串。 Null 字符不受 System.Diagnostics.Tracing.EventSource 类支持。 此更改仅影响使用 System.Diagnostics.Tracing.EventListener 读取进程中 System.Diagnostics.Tracing.EventSource 数据的应用以及使用 null 字符串作为分隔符的应用。

建议

应可能更新 System.Diagnostics.Tracing.EventSource 数据，以便不使用嵌入的空字符。

“属性”	值
范围	边缘
Version	4.5.1
类型	运行时

受影响的 API

• EventListener()
• EventListener.EnableEvents(EventSource, EventLevel)
• EventListener.EnableEvents(EventSource, EventLevel, EventKeywords)
• EventListener.EnableEvents(EventSource, EventLevel, EventKeywords, IDictionary<String,String>)

EventSource.WriteEvent impls 必须传递它接收的相同参数 WriteEvent（以及 ID）

详细信息

运行时现在强制执行指定以下内容的合同：如果类派生自 System.Diagnostics.Tracing.EventSource 且用于定义 ETW 事件方法，它必须使用事件 ID（后跟已传递给 ETW 事件方法的相同参数）调用基类 EventSource.WriteEvent 方法。

建议

如果 System.IndexOutOfRangeException 读取违反此协定的事件源进程中的 System.Diagnostics.Tracing.EventListener 数据，则将引发 System.Diagnostics.Tracing.EventSource 异常。

“属性”	值
范围	次要
Version	4.5.1
类型	运行时

受影响的 API

无法通过 API 分析检测到。

Marshal.SizeOf 和 Marshal.PtrToStructure 重载中断动态代码

详细信息

从 .NET Framework 4.5.1 开始，动态绑定到方法 SizeOf<T>()、SizeOf<T>(T)、PtrToStructure(IntPtr, Object)、PtrToStructure(IntPtr, Type)、PtrToStructure<T>(IntPtr) 或 PtrToStructure<T>(IntPtr, T)（例如通过 Windows PowerShell、IronPython 或 C# dynamic 关键字）将引发 MethodInvocationExceptions，因为这些方法的新重载已添加，使得对于脚本引擎而言可能不明确。

建议

更新脚本以清楚指示应使用哪个重载。 通常，这可通过将方法的类型参数显式转换为 Type 来实现。 有关如何解决此问题的详细信息和示例，请参阅此链接。

“属性”	值
范围	次要
Version	4.5.1
类型	运行时

受影响的 API

无法通过 API 分析检测到。

一些 .NET API 会导致最可能的（已处理）EntryPointNotFoundExceptions

详细信息

在 .NET Framework 4.5 中，少量 .NET 方法开始引发最可能的 System.EntryPointNotFoundException。 这些异常在 .NET Framework 内进行处理，但可能会中断不希望出现最可能的异常的测试自动化。 启用 HighVersionLie 后，这些相同的 API 会中断一些 ApiVerifier 方案。

建议

升级到 .NET Framework 4.5.1 可避免此 bug 出现。 还可以更新测试自动化以便不中断对最可能的 System.EntryPointNotFoundException 异常的操作。

	值
范围	边缘
版本	4.5
类型	运行时

受影响的 API

• Debug.Assert(Boolean)
• Debug.Assert(Boolean, String)
• Debug.Assert(Boolean, String, String)
• Debug.Assert(Boolean, String, String, Object[])
• XmlSerializer(Type)

WinRT 流适配器不再在关闭时自动调用 FlushAsync

详细信息

在 Windows 应用商店的应用中，Windows 运行时流适配器不再从 Dispose 方法调用 FlushAsync 方法。

建议

此更改应该为透明。 开发人员可以通过编写如下代码还原之前的行为：

using (var stream = GetWindowsRuntimeStream() as Stream)
{
// do something
await stream.FlushAsync();
}

“属性”	值
范围	透明
Version	4.5.1
类型	运行时

受影响的 API

无法通过 API 分析检测到。

数据

ADO.NET 现在尝试自动重连已中断的 SQL 连接

详细信息

从 .NET Framework 4.5.1 开始，.NET Framework 将尝试自动重新连接已中断的 SQL 连接。 虽然这通常会使应用更可靠，但在少数情况下，应用需要知道连接已断开，以便重新连接时可采取一些操作。

建议

如果由于兼容性问题而不希望使用此功能，则可通过将连接字符串（或 System.Data.SqlClient.SqlConnectionStringBuilder）的 System.Data.SqlClient.SqlConnectionStringBuilder.ConnectRetryCount 属性设置为 0 来禁用此功能。

“属性”	值
范围	边缘
Version	4.5.1
类型	运行时

受影响的 API

• IDbConnection.ConnectionString
• SqlConnection.ConnectionString
• ConnectionStringSettings.ConnectionString
• DbConnection.ConnectionString
• DbConnectionStringBuilder.ConnectionString
• SqlConnectionStringBuilder()
• SqlConnectionStringBuilder(String)
• DbConnectionStringBuilder()
• DbConnectionStringBuilder(Boolean)

序列化

NetDataContractSerializer 无法反序列化使用其他 .NET 版本序列化的 ConcurrentDictionary

详细信息

根据设计，只有在序列化和反序列化端共享相同的 CLR 类型时，才能使用 System.Runtime.Serialization.NetDataContractSerializer。 因此，不能保证使用 .NET Framework 的一个版本序列化的对象可以被其他版本反序列化。System.Collections.Concurrent.ConcurrentDictionary<TKey,TValue> 是一种已知在使用 .NET Framework 4.5 或更早版本进行序列化并使用 .NET Framework 4.5.1 或更高版本进行反序列化无法正确反序列化的类型。

建议

针对这个问题有很多可行的解决方法：

• 升级序列化计算机以使用 .NET Framework 4.5.1。
• 使用 System.Runtime.Serialization.DataContractSerializer 而不是 System.Runtime.Serialization.NetDataContractSerializer，因为这并不指望在序列化端和反序列化端具有完全相同的 CLR 类型。
• 使用 System.Collections.Generic.Dictionary<TKey,TValue> 而不是 System.Collections.Concurrent.ConcurrentDictionary<TKey,TValue>，因为它不会显示出特定的 4.5->4.5.1 中断。

“属性”	值
范围	次要
Version	4.5.1
类型	运行时

受影响的 API

• NetDataContractSerializer.Deserialize(Stream)

Windows Communication Foundation (WCF)

MinFreeMemoryPercentageToActiveService 现在受到遵从

详细信息

此设置可确立激活 WCF 服务之前必须在服务器上可用的最小内存。 它旨在阻止 System.OutOfMemoryException 异常。 在 .NET Framework 4.5 中，此设置没有效果。 在 .NET Framework 4.5.1 中，观察到该设置。

建议

如果 Web 服务器上的可用内存少于由配置设置定义的百分比，将引发异常。 某些成功启动并且在受约束的内存环境中运行的 WCF 服务现在可能失败。

“属性”	值
范围	次要
Version	4.5.1
类型	运行时

受影响的 API

无法通过 API 分析检测到。

Windows Presentation Foundation (WPF)

在 VirtualizingStackPanel 中滚动 WPF TreeView 或分组的 ListBox 可能会导致应用程序停止响应

详细信息

在 .NET Framework v4.5 中，如果在视区中有边距（例如，在 System.Windows.Controls.TreeView 中的项之间，或在 ItemsPresenter 元素上），则在一个虚拟化的堆叠面板中滚动WPF System.Windows.Controls.TreeView 会导致应用程序停止响应。 此外，在某些情况下，即使没有边距，视图中不同大小的项目也可能会导致不稳定性。

建议

升级到 .NET Framework 4.5.1 可避免此 bug 出现。 或者，如果包含的所有项目大小相同，可从虚拟化堆叠面板的视图集合（例如 System.Windows.Controls.TreeView）中删除边距。

“属性”	值
范围	主要
Version	4.5
类型	运行时

受影响的 API

• VirtualizingStackPanel.SetIsVirtualizing(DependencyObject, Boolean)

.NET Framework 4.5.2

ASP.NET

ASP.NET MVC 现在将转义通过路由参数传递的字符串中的空格

详细信息

为了遵守 RFC 2396，从路由中填充操作参数时，现在将转义路由路径中的空格。 因此，尽管 /controller/action/some data 之前会匹配路由 /controller/action/{data} 并提供 some data 作为数据参数，但它现在将改为提供 some%20data。

建议

应更新代码，以取消转义路由中的字符串参数。 如果需要原始 URI，可通过 RequestUri.OriginalString API 进行访问。

“属性”	值
范围	次要
Version	4.5.2
类型	运行时

受影响的 API

• RouteAttribute(String)

无法再将 EnableViewStateMac 设为 false

详细信息

ASP.NET 不再允许开发者指定 <pages enableViewStateMac=&quot;false&quot;/> 或 <@Page EnableViewStateMac=&quot;false&quot; %>。 现在，针对所有带嵌入视图状态的请求强制执行视图状态消息身份验证代码 (MAC)。 仅影响将 EnableViewStateMac 属性显式设置为 false 的应用。

建议

EnableViewStateMac 必须假设为 true，并且必须解决任何生成的 MAC 错误（如本指南所述，该指南包含多种解决方法，具体视引发 MAC 错误的具体原因而定）。

“属性”	值
范围	主要
Version	4.5.2
类型	运行时

受影响的 API

无法通过 API 分析检测到。

分析 ASP.NET MVC4 应用可能导致严重的执行引擎错误

详细信息

使用 NGEN /Profile 程序集的探查器可能会在启动时使已配置的 ASP.NET MVC4 应用程序出故障，引发“严重的执行引擎异常”

建议

此问题已在 .NET Framework 4.5.2 中解决。 或者，探查器可通过在其事件掩码中指定 COR_PRF_DISABLE_ALL_NGEN_IMAGES 来避免此问题。

“属性”	值
范围	边缘
Version	4.5
类型	运行时

受影响的 API

无法通过 API 分析检测到。

数据

SqlConnection.Open 在存在非 IFS Winsock BSP 或 LSP 的 Windows 7 中会失败

详细信息

如果在存在非 IFS Winsock BSP 或 LSP 的 Windows 7 计算机上运行，Open() 和 OpenAsync(CancellationToken) 在 .NET Framework 4.5 中将会失败。若要确定是否安装了非 IFS BSP 或 LSP，请使用 netsh WinSock Show Catalog 命令，并查看每个返回的 Winsock Catalog Provider Entry 项。 如果服务标志值设置了 0x20000 位，提供程序将使用 IFS 句柄，并将正确运行。 如果 0x20000 位已清除（未设置），则它将是非 IFS BSP 或 LSP。

建议

此 bug 已在 .NET Framework 4.5.2 中得到修复，因此升级 .NET Framework 可避免出现此问题。 或者，可通过删除任何已安装的非 IFS Winsock LSP 来避免出现此问题。

“属性”	值
范围	次要
Version	4.5
类型	运行时

受影响的 API

• SqlConnection.Open()
• SqlConnection.OpenAsync(CancellationToken)

Entity Framework

EF 将不再引发有特定特征的 QueryViews

详细信息

当应用执行涉及到带有 0..1 导航属性（此属性尝试将相关实体包含为查询的一部分）的查询时，Entity Framework 将不再引发 System.StackOverflowException 异常。 例如，通过调用 .Include(e => e.RelatedNavProp)。

建议

在运行调用 .Include 的查询时，此更改仅影响使用带有 1-0..1 关系的 QueryViews 的代码。 它可以改善可靠性，并且应该几乎对所有应用透明。 但是，如果它导致意外的行为，你可以通过将以下项添加到应用配置文件的 <appSettings> 部分来禁用它：

<add key="EntityFramework_SimplifyUserSpecifiedViews" value="false" />

“属性”	值
范围	边缘
Version	4.5.2
类型	运行时

受影响的 API

无法通过 API 分析检测到。

选择中断以从不同的 4.5 SQL 生成还原到更简单的 4.0 SQL 生成

详细信息

生成 JOIN 语句并包含对限制操作的调用（无需先使用 OrderBy）的查询现在可以生成更简单的 SQL。 升级到 .NET Framework 4.5 后，这些查询生成了比以前版本更复杂的 SQL。

建议

在默认情况下，禁用此功能。 如果实体框架生成可导致性能降低的额外 JOIN 语句，则可以通过将以下项添加到应用程序配置 (app.config) 文件的 <appSettings> 部分来启用此功能：

<add key="EntityFramework_SimplifyLimitOperations" value="true" />

“属性”	值
范围	透明
Version	4.5.2
类型	运行时

受影响的 API

无法通过 API 分析检测到。

Windows Presentation Foundation (WPF)

从 CellEditEnding 处理程序调用 DataGrid.CommitEdit 将丢失焦点

详细信息

从 System.Windows.Controls.DataGrid 的一个 System.Windows.Controls.DataGrid.CellEditEnding 事件处理程序中调用 CommitEdit() 导致 System.Windows.Controls.DataGrid 失去焦点。

建议

此 bug 已在 .NET Framework 4.5.2 中得到修复，因此升级 .NET Framework 可避免出现此问题。 或者，可通过在调用 System.Windows.Controls.DataGrid.CommitEdit() 后显式重新选择 System.Windows.Controls.DataGrid 避免出现此问题。

“属性”	值
范围	边缘
Version	4.5
类型	运行时

受影响的 API

• DataGrid.CommitEdit()
• DataGrid.CommitEdit(DataGridEditingUnit, Boolean)

使用自定义 DataTemplates 时，在 ItemsControls（例如 ListBox 和 DataGrid）内间歇性无法滚动到底部项目

详细信息

在某些情况下，使用自定义 DataTemplates 时，.NET Framework 4.5 中的 bug 引起 ItemsControls（例如 System.Windows.Controls.ListBox、System.Windows.Controls.ComboBox、System.Windows.Controls.DataGrid 等）无法滚动到底部项。 如果再次尝试滚动（在可重新滚动后），将可以滚动。

建议

此问题已在 .NET Framework 4.5.2 中解决，升级到该版本（或更高版本）的 .NET Framework 即可解决该问题。 或者，用户仍可将滚动条拖动至这些集合中的最后几个项目，但可能需要尝试两次才能成功。

“属性”	值
范围	次要
Version	4.5
类型	运行时

受影响的 API

无法通过 API 分析检测到。

WPF 生成可冻结鼠标的 wisptis.exe 进程

详细信息

4\.5.2 中引入了一个问题，导致生成可冻结鼠标输入的 wisptis.exe。

建议

.NET Framework 4.5.2 的服务版本（修补程序汇总 3026376）中提供了此问题的修补程序，也可通过升级到 .NET Framework 4.6 解决此问题

“属性”	值
范围	主要
Version	4.5.2
类型	运行时

受影响的 API

无法通过 API 分析检测到。

XML

XML 分析更改

名称	值
范围	次要
Version	4.5.2
类型	运行时

详细信息

出于安全原因，XML 分析 API 中引入了以下更改：

• 初始化 XmlReaderSettings 时，XmlReaderSettings.MaxCharactersFromEntities 设置为 1 千万。
• 默认情况下，XmlReaderSettings.XmlResolver 设置为 null。

备注

所有 XML 分析器都使用 XmlReaderSettings，因此尽管此更改有助于 XmlReader 的情况，但它也会影响其他情况。

建议

若要恢复到以前的行为，可以在注册表中设置一个值。 将名为 EnableLegacyXmlSettings 的 DWORD 值添加到 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\XML 注册表项，并将其值设置为 1。 还可以改为在 HKEY_CURRENT_USER 配置单元中添加注册表值。

受影响的 API

• System.Xml.XmlReaderSettings.MaxCharactersFromEntities
• System.Xml.XmlReaderSettings.XmlResolver

此外，任何直接或间接依赖于 XmlResolver 的 XML API 都会受到影响。