移轉至 .NET Framework 4.5.x 時的執行階段變更

  • 發行項

本文列出 .NET Framework 4.5、4.5.1 和 4.5.2 中介紹的應用程式相容性問題。

.NET Framework 4.5

ASP.NET

AllowCustomPaging 設為 true 的 GridView 可能在離開檢視的最後一頁時引發 PageIndexChanging 事件

詳細資料

.NET Framework 4.5 中的 Bug) 導致有時不會針對已啟用 System.Web.UI.WebControls.GridView.AllowCustomPaging 的 System.Web.UI.WebControls.GridView 引發 System.Web.UI.WebControls.GridView.PageIndexChanging。

建議

此此問題在 .NET Framework 4.6 中已修正，因此可藉由升級至該版 .NET Framework 來解決。 應用程式可以對叫用這些條件 (System.Web.UI.WebControls.GridView 位在最後一個頁面上且 LastSystem.Web.UI.WebControls.GridView.PageSize 不同於 System.Web.UI.WebControls.GridView.PageSize) 的 Page_Load 執行明確的 BindGrid，來解決這個問題。 或者，可以修改應用程式以允許分頁 (而不是自訂分頁)，因為該情況不會顯示此問題。

名稱 值
範圍 Minor
版本 4.5
類型 執行階段

受影響的 API

HttpRequest.ContentEncoding 屬性禁止 UTF7

詳細資料

從 .NET Framework 4.5 開始，在 System.Web.HttpRequest 本文中禁止使用 UTF-7 編碼。 在某些情況下，倚賴傳入 UTF-7 資料的應用程式資料將無法正確解碼。

建議

在理想情況下，您應該更新應用程式，不要在 System.Web.HttpRequest 中使用 UTF-7 編碼。 或者，您也可以使用 appSettings 項目的 aspnet:AllowUtf7RequestContentEncoding 屬性還原舊版行為。

名稱 值
範圍 Edge
版本 4.5
類型 執行階段

受影響的 API

HttpUtility.JavaScriptStringEncode 會逸出 & 符號

詳細資料

從 .NET Framework 4.5 開始，System.Web.HttpUtility.JavaScriptStringEncode(String) 會逸出連字號 (&) 字元。

建議

如果您的應用程式相依於此方法的舊版行為，您可以將 aspnet:JavaScriptDoNotEncodeAmpersand 設定新增至組態檔中的 ASP.NET appSettings 項目。

名稱 值
範圍 Minor
版本 4.5
類型 執行階段

受影響的 API

IPad 不應用於自訂功能檔案，因為現在它是一種瀏覽器功能

詳細資料

從 .NET Framework 4.5 開始，iPad 是預設 ASP.NET 瀏覽器功能檔案中的識別碼，所以不應將其用於自訂功能檔案

建議

如果需要 iPad 特定功能，則必須以修改 iPad 行為，方法是在預先定義的閘道 refID "IPad" 上設定功能，而不是透過使用者代理程式比對產生新的 "IPad" 識別碼。

名稱 值
範圍 Edge
版本 4.5
類型 執行階段

Page.LoadComplete 事件不再導致 System.Web.UI.WebControls.EntityDataSource 控制項叫用資料繫結

詳細資料

LoadComplete 事件不再使 System.Web.UI.WebControls.EntityDataSource 控制項叫用資料繫結，讓變更建立/更新/刪除參數。 這項變更可以消除來回存取資料庫的額外作業，防止重設控制項的值，並且產生與其他資料控制項 (例如 System.Web.UI.WebControls.SqlDataSource 和 System.Web.UI.WebControls.ObjectDataSource) 一致的行為。 在像是應用程式倚賴於 LoadComplete 事件中叫用資料繫結這類不常見的情況下，這項變更會產生不同的行為。

建議

如果需要資料繫結，請在回傳初期的事件中手動叫用資料繫結。

名稱 值
範圍 Edge
版本 4.5
類型 執行階段

受影響的 API

無法透過 API 分析偵測。

分析 ASP.NET MVC4 應用程式可能會導致嚴重的執行引擎錯誤

詳細資料

使用 NGEN /Profile 組件的分析工具可能會在啟動時損毀已分析的 ASP.NET MVC4 應用程式，並顯示「嚴重的執行引擎例外狀況」

建議

此問題在 .NET Framework 4.5.2 中已修正。 或者，分析工具時可能會藉由在其事件遮罩中指定 COR_PRF_DISABLE_ALL_NGEN_IMAGES 來避免這個問題。

名稱 值
範圍 Edge
版本 4.5
類型 執行階段

受影響的 API

無法透過 API 分析偵測。

與 ASP.NET StateServer 共用工作階段狀態需要 Web 伺服陣列中的所有伺服器使用相同的 .NET Framework 版本

詳細資料

啟用 System.Web.SessionState.SessionStateMode.StateServer 工作階段狀態時，指定之 Web 伺服陣列中的所有伺服器必須使用相同版本的 .NET Framework，才能正確共用狀態。

建議

請務必將共用狀態之 Web 伺服器上的 .NET Framework 版本同時升級。

值
範圍 Edge
版本 4.5
類型 執行階段

受影響的 API

WebUtility.HtmlDecode 不再將無效的輸入序列解碼

詳細資料

根據預設，解碼方法不再將無效的輸入序列解碼為無效的 UTF-16 字串， 而是改為傳回原始輸入。

建議

解碼器輸出的變更只有在您於字串中儲存二進位資料而不是 UTF-16 資料時才相關。 若要明確控制這個行為，請將 appSettings 項目的 aspnet:AllowRelaxedUnicodeDecoding 屬性設為 true 以啟用舊版行為，或是設為 false 以啟用目前的行為。

值
範圍 Minor
版本 4.5
類型 執行階段

受影響的 API

核心

使用 Regex.CompileToAssembly 編譯的組件在 4.0 與 4.5 之間中斷

詳細資料

如果使用 .NET Framework 4.5 建置編譯之規則運算式的組件，但以 .NET Framework 4 為目標，嘗試在安裝 .NET Framework 4 的系統上使用該組件中的其中一個規則運算式時，會擲回例外狀況。

建議

若要解決這個問題，您可以執行下列任何一項操作：

  • 使用 .NET Framework 4 建置包含規則運算式的組件。
  • 使用解譯的規則運算式。
名稱 值
範圍 Minor
版本 4.5
類型 執行階段

受影響的 API

lBlockingCollection<T>.TryTakeFromAny 不會再擲回例外狀況

詳細資料

如果其中一個輸入集合標記為已完成，則 TryTakeFromAny(BlockingCollection<T>[], T) 不會再傳回 -1，而且 TakeFromAny(BlockingCollection<T>[], T) 不會再擲回例外狀況。 這項變更能夠讓您在其中一個集合為空集合或已完成，而另一個集合仍有可擷取的項目時處理集合。

建議

如果在防止集合完成時，使用了傳回 -1 的 TryTakeFromAny 或擲回的 TakeFromAny 來控制流程，現在應該將這類程式碼變更為使用 .Any(b =&gt; b.IsCompleted) 來偵測該情況。

名稱 值
範圍 Minor
版本 4.5
類型 執行階段

受影響的 API

含逾時引數之 Task.WaitAll 方法的行為變更

詳細資料

在 .NET Framework 4.5 中，Task.WaitAll 行為變得更一致。在 .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 只會在所有等候的工作在逾時前都已完成時，才會擲回此例外狀況。

值
範圍 Minor
版本 4.5
類型 執行階段

受影響的 API

編譯器支援多目標 mscorlib 時的類型轉送

詳細資料

新的 CodeDOM 功能可讓編譯器針對設為目標的 mscorlib.dll 版本 (而非 .NET Framework 4.5 版的 mscorlib.dll) 進行編譯。

名稱 值
範圍 Edge
版本 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 將會解決問題。

名稱 值
範圍 主修
版本 4.5
類型 執行階段

受影響的 API

ETW EventListeners 無法使用 Explicit 關鍵字從提供者擷取事件 (例如 TPL 提供者)

詳細資料

具有空白關鍵字遮罩的 ETW EventListeners 無法使用 Explicit 關鍵字從提供者正確地擷取事件。 在 .NET Framework 4.5 中，TPL 提供者已開始提供 Explicit 關鍵字並觸發此問題。 在 .NET Framework 4.6 中，已更新 EventListeners，因此不會再發生此問題。

建議

若要解決此問題，請將 EnableEvents(EventSource, EventLevel) 的呼叫取代為 EnableEvents 多載的呼叫，其明確指定「任何關鍵字」遮罩以使用：EnableEvents(eventSource, level, unchecked((EventKeywords)0xFFFFffffFFFFffff))。

此外，此問題在 .NET Framework 4.6 中已修正，因此可藉由升級至該版 .NET Framework 來解決。

名稱 值
範圍 Edge
版本 4.5
類型 執行階段

受影響的 API

在 System.Threading.Tasks.Task 中未觀察到的處理期間發生的例外狀況，將不再於完成項執行緒上傳播

詳細資料

由於 System.Threading.Tasks.Task 類別代表非同步作業，因此它會攔截非同步處理期間發生的所有非嚴重的例外狀況。 在 .NET Framework 4.5 中，如果未觀察到某個例外狀況，而您的程式碼絕不會等候這項工作，則該例外狀況將不再於完成項執行緒上傳播，並且會在記憶體回收期間損毀處理序。 這項變更可以增強使用 Task 類別執行未觀察到的非同步處理之應用程式的可靠性。

建議

如果應用程式必須將未觀察到的非同步例外狀況傳播至完成項執行緒，可以藉由提供適當的處理常式給 UnobservedTaskException 事件，或藉由設定執行階段組態項目，來還原舊版行為。

名稱 值
範圍 Edge
版本 4.5
類型 執行階段

受影響的 API

List.Sort 演算法已變更

詳細資料

從 .NET Framework 4.5 開始，System.Collections.Generic.List<T> 的排序演算法已變更 (變更為內省式排序，而不是快速排序)。 System.Collections.Generic.List<T> 的排序從未穩定，但這項變更可能會導致不同的案例以不穩定的方式排序。 這只是表示對等項目可能會在 API 的後續呼叫中以不同的順序排序。

建議

因為舊的排序演算法也不穩定 (儘管方式略有不同)，應該沒有任何程式碼相依於一律以特定順序排序的對等項目。 如果有程式碼的執行個體相依於該項目，且湊巧使用舊行為，該程式碼應該更新為使用將明確地以所需順序排序項目的比較子。

名稱 值
範圍 透明
版本 4.5
類型 執行階段

受影響的 API

在 4.0 行為中遺漏目標 Framework Moniker 結果

詳細資料

未在組件層級套用 System.Runtime.Versioning.TargetFrameworkAttribute 的應用程式將會使用 .NET Framework 4.0 的語意 (Quirks) 來自動執行。 為了確保有高品質，建議明確設定所有二進位檔的 System.Runtime.Versioning.TargetFrameworkAttribute 屬性，以指出用來建置的 .NET Framework 版本。 請注意，在專案檔中使用目標 Framework Moniker 會使 MSBuild 自動套用 System.Runtime.Versioning.TargetFrameworkAttribute。

建議

您應該透過直接將屬性新增至組件，或藉由在專案檔中或透過 Visual Studio 的專案屬性 GUI 來指定目標 Framework，以提供 System.Runtime.Versioning.TargetFrameworkAttribute。

名稱 值
範圍 主修
版本 4.5
類型 執行階段

受影響的 API

無法透過 API 分析偵測。

某些 .NET API 會造成第一個可能發生 (已處理) 的 EntryPointNotFoundException

詳細資料

在 .NET Framework 4.5 中，少數 .NET 方法已開始擲回第一個可能發生的 System.EntryPointNotFoundException。 這些例外狀況在 .NET Framework 中已處理，但可能會中斷未預期第一個可能發生例外狀況的測試自動化。 這些相同的 API 會在啟用 HighVersionLie 時中斷一些 ApiVerifier 案例。

建議

您可以升級至 .NET Framework 4.5.1 來避免此錯誤 (bug)。 或者，您也可以更新測試自動化，使其不會在首次發生 System.EntryPointNotFoundException 例外狀況時發生中斷。

值
範圍 Edge
版本 4.5
類型 執行階段

受影響的 API

System.Threading.Tasks.Task 不會再於處置物件之後擲回 ObjectDisposedException

詳細資料

除了 IAsyncResult.AsyncWaitHandle 以外，System.Threading.Tasks.Task 方法將不再於處置物件之後擲回 System.ObjectDisposedException 例外狀況。這項變更支援使用快取的工作。 例如，方法可能傳回快取的工作來表示已完成的作業，而不配置新的工作。 舊版的 .NET Framework 並未提供這項功能，因為工作的任何消費者都可能會處置它，使它變得無法使用。

建議

請注意，Task 方法可能不會再於處置物件之後擲回 System.ObjectDisposedException。 如果應用程式根據此例外狀況得知某個工作已處置，則應該將它更新，以使用 Status 明確檢查工作的狀態。

名稱 值
範圍 Minor
版本 4.5
類型 執行階段

受影響的 API

無法透過 API 分析偵測。

System.URI 逸出現在支援 RFC 3986

詳細資料

URI 逸出在 .NET Framework 4.5 中已變更，可支援 RFC 3986。 特定變更包括：

建議

  • 請更新應用程式，以便在逸出序列無效時，不依賴 System.Uri.UnescapeDataString(String) 擲回例外狀況。 現在必須直接偵測這類序列。
  • 同樣地，逸出和未逸出 URI 以及資料字串可能會因 .NET Framework 4.0 和 .NET Framework 4.5 而有所不同，因此不應該在不同的 .NET 版本之間直接進行比較。 相反地，應該將這些字串剖析和正規化為單一 .NET 版本，再進行任何比較。
名稱 值
範圍 Minor
版本 4.5
類型 執行階段

受影響的 API

資料

Sql_variant 資料使用的是 sql_variant 定序，而不是資料庫定序

詳細資料

sql_variant 資料使用的是 sql_variant 定序，而不是資料庫定序。

建議

這項變更可以解決資料庫定序與 sql_variant 定序不同時，可能發生的資料毀損。 依賴損毀資料的應用程式可能會失敗。

名稱 值
範圍 透明
版本 4.5
類型 執行階段

受影響的 API

無法透過 API 分析偵測。

SqlBulkCopy 針對字串使用目的地資料行編碼方式

詳細資料

將資料插入資料行時，System.Data.SqlClient.SqlBulkCopy 會使用目的地資料行的編碼方式，而不是 VARCHAR 和 CHAR 類型的預設編碼方式。 這項變更可排除當目的地資料行未使用預設編碼方式時，使用預設編碼方式可能造成的資料損毀。 在某些鮮少發生的情況下，如果變更編碼方式後產生的資料太大而不適用於目的地資料行，現有的應用程式可能會擲回 SqlException 例外狀況。

建議

由於編碼方式的差異，預期 System.Data.SqlClient.SqlBulkCopy 不會再損毀資料。 如果所複製的字串接近目的地資料行的大小限制，可能必須預先編碼資料 (要複製以確認資料可納入目的地資料行) 或攔截 System.Data.SqlClient.SqlException。

名稱 值
範圍 Edge
版本 4.5
類型 執行階段

受影響的 API

SqlConnection 無法再使用 VIA 配接器連線至 SQL Server 1997 或資料庫

詳細資料

不再支援使用虛擬介面配接器 (VIA) 通訊協定至 SQL Server 資料庫。 用來連線至 SQL Server 資料庫的通訊協定會顯示在接字串中。 VIA 連線將包含 via:<伺服器名稱>。 如果此應用程式透過 VIA 以外的通訊協定 (例如 tcp: 或 np:) 連線至 SQL，則不會發生任何重大變更。 此外，不再支援連線至 SQL Server 7 (1997)。

建議

VIA 通訊協定已淘汰，因此應該使用替代的通訊協定來連線至 SQL 資料庫。 最常用的通訊協定是 TCP/IP。 如需透過 TCP/IP 進行連線的詳細資訊，請參閱啟用資料庫執行個體的 TCP/IP 通訊協定。 如果只能從內部網路中存取資料庫，若網路太慢，則共用管道通訊協定可以提供更好的效能。

名稱 值
範圍 Edge
版本 4.5
類型 執行階段

受影響的 API

SqlConnection.Open 在有非 IFS Winsock BSP 或 LSP 的 Windows 7 上會失敗

詳細資料

在 .NET Framework 4.5 中，如果 Open() 和 OpenAsync(CancellationToken) 在 Windows 7 電腦上執行，而且該電腦上有非 IFS Winsock BSP 或 LSP，則會失敗。若要判斷是否已安裝非 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 來避免此錯誤 (bug)。

名稱 值
範圍 Minor
版本 4.5
類型 執行階段

受影響的 API

偵錯工具

在稍後的步驟中，偵錯工具才會顯示 Null 聯合器值

詳細資料

.NET Framework 4.5 中的 Bug) 會導致在 64 位元版本的 Framework 上執行時，透過 Null 聯合運算設定的值不會立即於執行指派作業之後顯示在偵錯工具中。

建議

在偵錯工具中逐步執行一段額外時間，將使本機/欄位的值正確更新。 此外，此問題已在 .NET Framework 4.6 中修正；升級至該版 .NET Framework 應可解決此問題。

名稱 值
範圍 Edge
版本 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 不存在且初始目錄也不存在時呼叫 DeleteDatabase，則方法會擲回 InvalidOperationException 例外狀況。 以往它會擲回 SqlException 例外狀況。

建議

這些變更可讓您更容易建置使用 DDL 應用程式開發介面的工具和應用程式。 在下列情節中，這些變更可能會影響應用程式相容性：

名稱 值
範圍 Minor
版本 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，現在也應該要攔截 SQLException。

名稱 值
範圍 Minor
版本 4.5
類型 執行階段

受影響的 API

EntityFramework 6.0 在從 Visual Studio 啟動的應用程式中的載入速度很慢

詳細資料

從 Visual Studio 2013 啟動使用 EntityFramework 6.0 的應用程式可能會很慢。

建議

此問題在 EntityFramework 6.0.2 中已修正。 更新 EntityFramework 可避免發生效能問題。

名稱 值
範圍 Edge
版本 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 檔案名稱格式。

值
範圍 Edge
版本 4.5
類型 執行階段

受影響的 API

ObjectContext.Translate 和 ObjectContext.ExecuteStoreQuery 現在支援列舉類型

詳細資料

在 .NET Framework 4.0 中，ObjectContext.Translate 和 ObjectContext.ExecuteStoreQuery 方法的泛型參數 T 不可為列舉。 現在支援這種情況。

建議

如果在 .NET Framework 4.0 中對列舉類型呼叫 Translate 或 ExecuteStoreQuery，則會傳回 '0'。 如果這不是您要的行為，請以常數 0 (或相當於此值的列舉) 取代呼叫。

名稱 值
範圍 Edge
版本 4.5
類型 執行階段

受影響的 API

LINQ

Enumerable.Empty<TResult> 一律會傳回快取的執行個體

詳細資料

從 .NET Framework 4.5 開始，Empty<TResult>() 一律會傳回快取的內部執行個體 IEnumerable<T>。之前，Empty<TResult>() 會在呼叫 API 時快取空的 IEnumerable<T>，也就是說，在快速且同時呼叫 Empty<TResult>() 的某些情況下，可能會針對不同的 API 呼叫傳回不同的類型執行個體。

建議

由於舊版行為不具決定性，因此程式碼不太可能取決於此行為。 不過，在罕見的情況下，如果空的可列舉值經比較有時必須不相等，則應該建立明確的空陣列 (new T[0])，而不是使用 Empty<TResult>()。

名稱 值
範圍 Edge
版本 4.5
類型 執行階段

受影響的 API

Managed Extensibility Framework (MEF)

MEF 目錄會實作 IEnumerable，因此不能再用來建立序列化程式

詳細資料

從 .NET Framework 4.5 開始，MEF 目錄會實作 IEnumerable，因此不能再用來建立序列化程式 (System.Xml.Serialization.XmlSerializer 物件)。 嘗試序列化 MEF 目錄會擲回例外狀況。

建議

無法再使用 MEF 建立序列化程式

名稱 值
範圍 主修
版本 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 物件還原序列化時，會提供例外狀況處理。

名稱 值
範圍 Minor
版本 4.5
類型 執行階段

受影響的 API

Windows 8 上無法使用 System.Net.PeerToPeer.Collaboration

詳細資料

在 Windows 8 (含) 以上版本上無法使用 System.Net.PeerToPeer.Collaboration 命名空間。

建議

您必須更新支援 Windows 8 (含) 以上版本的應用程式，使其不相依於此命名空間或其成員。

名稱 值
範圍 主修
版本 4.5
類型 執行階段

受影響的 API

列印

寫入 PrintSystemJobInfo.JobStream 的資料必須是 XPS 格式

詳細資料

JobStream 屬性會公開列印工作的資料流。 使用者可藉由寫入此資料流，將原始資料傳送至基礎作業系統列印元件。從 Windows 8 和更新版本的 Windows 作業系統上的 .NET Framework 4.5 開始，寫入此資料流的資料必須是作為套件資料流的 XPS 格式。

建議

若要輸出列印的內容，您可以執行下列任何一項操作：

  • 使用 XpsDocumentWriter 類別來輸出列印的內容。 這是建議的替代方案。
  • 請確定傳送至 JobStream 屬性所傳回之資料流的資料是作為套件資料流的 XPS 格式。
名稱 值
範圍 Minor
版本 4.5
類型 執行階段

受影響的 API

序列化

BinaryFormatter 可能無法從 LoadFrom 內容尋找類型

詳細資料

從 .NET Framework 4.5 開始，使用 System.Runtime.Serialization.Formatters.Binary.BinaryFormatter 將已在 LoadFrom 內容中載入的類型還原序列化時，System.Xml.Serialization.XmlSerializer 變更可能會造成還原序列化的差異。 這些變更是由於新方法 System.Xml.Serialization.XmlSerializer 現在會載入類型，因此這會在 System.Runtime.Serialization.Formatters.Binary.BinaryFormatter 稍後嘗試為該類型還原序列化時，導致不同的行為。 預設序列化繫結器不會自動搜尋 LoadFrom 內容，雖然在某些狀況下，其根據 XmlSerializer 舊有行為可正常運作。 由於這些變更之故，從在不同內容載入的組件中載入類型時，可能會擲回 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));
    }
}
名稱 值
範圍 Edge
版本 4.5
類型 執行階段

受影響的 API

SoapFormatter 無法將 Hashtable 和類似的已排序集合物件還原序列化

詳細資料

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.Soap.SoapFormatter 應該取代為 System.Runtime.Serialization.Formatters.Binary.BinaryFormatter 序列化或 System.Runtime.Serialization.NetDataContractSerializer 應該彈性處理 .NET Framework 變更。

警告

使用 BinaryFormatter 進行二進位序列化可能很危險。 如需詳細資訊，請參閱 BinaryFormatter 安全性指南。

名稱 值
範圍 Minor
版本 4.5
類型 執行階段

受影響的 API

在序列化以無法存取的成員隱藏可存取成員的類型時，XmlSerializer 會失敗

詳細資料

序列化衍生的類型時，如果類型包含無法存取的欄位或屬性，而此欄位或屬性隱藏 (透過 'new' 關鍵字) 先前在基底類型上可存取 (例如，公用) 之相同名稱的欄位或屬性，System.Xml.Serialization.XmlSerializer 可能會失敗。

建議

這個問題可以透過讓 System.Xml.Serialization.XmlSerializer 能夠存取新的隱藏成員 (例如，將其設為公用) 來解決。 或者，下列組態設定會還原為 4.0 System.Xml.Serialization.XmlSerializer 行為，從而解決該問題：

<system.xml.serialization>
<xmlSerializer useLegacySerializerGeneration="true" />
</system.xml.serialization>
名稱 值
範圍 Minor
版本 4.5
類型 執行階段

受影響的 API

Web 應用程式

.NET Framework 1.1 和 2.0 的受控瀏覽器裝載控制項已封鎖

詳細資料

Internet Explorer 中已封鎖裝載這些控制項。

建議

Internet Explorer 將無法啟動使用 Managed 瀏覽器裝載控制項的應用程式。 可還原先前行為的方式包括：在 x86 系統和 x64 系統的 32 位元處理序上，將登錄子機碼 HKLM/SOFTWARE/MICROSOFT/.NETFramework 的 EnableIEHosting 值設為 1，在 x64 系統的 64 位元處理序上，將登錄子機碼 HKLM/SOFTWARE/Wow6432Node/Microsoft/.NETFramework 的 EnableIEHosting 值設為 1。

名稱 值
範圍 Minor
版本 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 例外狀況。 傳輸模式為 Streamed 的案例也包括在內。

建議

這項變更有助於在訊息長度超過 ASP.NET 或 WCF 所允許之限制的情況下進行偵錯。您必須修改任何依據 HTTP 400 狀態碼執行處理的程式碼。

名稱 值
範圍 Edge
版本 4.5
類型 執行階段

受影響的 API

無法透過 API 分析偵測。

System.ServiceModel.Web.WebServiceHost 物件不會再新增預設端點

詳細資料

如果應用程式程式碼加入明確的端點，WebServiceHost 物件將不再加入預設端點。

建議

如果使用者希望能夠連線到預設端點，而且 System.ServiceModel.Web.WebServiceHost 已新增其他明確的端點，也應該明確新增預設端點 (使用 System.ServiceModel.ServiceHostBase.AddDefaultEndpoints())。

名稱 值
範圍 Minor
版本 4.5
類型 執行階段

受影響的 API

OData URL 中的 Replace 方法預設為停用

詳細資料

從 .NET Framework 4.5 開始，OData URL 中的 Replace 方法預設為停用。 當 OData Replace 停用 (現在為預設) 時，任何包含取代功能的使用者要求 (不常見) 將會失敗。

建議

如果需要 Replace 方法 (不常見)，可以透過組態設定 (System.Data.Services.Configuration.DataServicesFeaturesSection.ReplaceFunction) 將它重新啟用。 不過，已啟用的 Replace 方法可能會有資訊安全漏洞，因此只有在仔細檢閱之後才能使用。

名稱 值
範圍 Edge
版本 4.5
類型 執行階段

受影響的 API

Windows Forms

如果其處理常式顯示 Windows Forms 訊息方塊，則會重複呼叫 PreviewLostKeyboardFocus

詳細資料

從 .NET Framework 4.5 開始，從 PreviewLostKeyboardFocus 處理常式呼叫 MessageBox.Show 會使處理常式在關閉訊息方塊時重新引發，而可能產生無限的訊息方塊迴圈。

建議

此問題有兩個解決方法：

名稱 值
範圍 Edge
版本 4.5
類型 執行階段

受影響的 API

WinForm 的 CheckForOverflowUnderflow 屬性對於 System.Drawing 現在是 true

詳細資料

System.Drawing.dll 組件的 CheckForOverflowUnderflow 屬性設定為 true。

建議

以往發生溢位時，結果會以無訊息模式截斷。 現在則會擲回 System.OverflowException 例外狀況。

名稱 值
範圍 Edge
版本 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 來解決。

名稱 值
範圍 Minor
版本 4.5
類型 執行階段

受影響的 API

從 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，來避免此 Bug。

名稱 值
範圍 Edge
版本 4.5
類型 執行階段

受影響的 API

在已選取項目的 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 來解決。

值
範圍 Minor
版本 4.5
類型 執行階段

受影響的 API

FlowDocument 可能會顯示額外的文字行

詳細資料

在某些情況下，相較於 FlowDocument 項目在 .NET Framework 4.0 上執行時的顯示方式，其在 .NET Framework 4.5 上執行時，會顯示額外的文字行。 沒有任何已知的變更情況會導致文字顯示不良或無法辨識，但它可能會導致顯示之前已從 FlowDocument 檢視表中省略的文字。

建議

在某些情況下，將顯示項目的 PageHeight 屬性減 1 可以還原先前顯示的行數。

名稱 值
範圍 Edge
版本 4.5
類型 執行階段

受影響的 API

從 .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>
名稱 值
範圍 Edge
版本 4.5
類型 執行階段

受影響的 API

使用自訂 DataTemplates 時，會斷斷續續無法捲動至 ItemsControls (例如 ListBox 和 DataGrid) 中的底部項目

詳細資料

在某些情況下，.NET Framework 4.5 中的 Bug 會導致在使用自訂 DataTemplates 時，ItemsControls (例如 System.Windows.Controls.ListBox、System.Windows.Controls.ComboBox、System.Windows.Controls.DataGrid 等) 無法捲動至其底部項目。 如果嘗試捲動第二次 (在向上捲動之後)，則會再次運作。

建議

此問題在 .NET Framework 4.5.2 中已修正，因此可藉由升級至該版 .NET Framework (或更新版本) 來解決。 此外，使用者仍可將捲軸拖曳至這些集合中的最後一個項目，但可能需要嘗試兩次才能成功。

名稱 值
範圍 Minor
版本 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。

名稱 值
範圍 Minor
版本 4.5
類型 執行階段

受影響的 API

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 來解決。

名稱 值
範圍 Minor
版本 4.5
類型 執行階段

受影響的 API

WPF PageRangeSelection 中的新列舉值

詳細資料

兩個新成員 (System.Windows.Controls.PageRangeSelection.CurrentPage 和 System.Windows.Controls.PageRangeSelection.SelectedPages) 已新增至 System.Windows.Controls.PageRangeSelection 列舉。

建議

在大多數情況下，這些變更不會影響使用者程式碼。 不過，您應該修改與 System.Windows.Controls.PageRangeSelection 型別的 GetNames(Type) 或 GetValues(Type) 呼叫中現有的特定項目數目相依的程式碼。

名稱 值
範圍 Edge
版本 4.5
類型 執行階段

受影響的 API

如果其處理常式顯示 Windows Forms 訊息方塊，則會重複呼叫 PreviewLostKeyboardFocus

詳細資料

從 .NET Framework 4.5 開始，從 PreviewLostKeyboardFocus 處理常式呼叫 MessageBox.Show 會使處理常式在關閉訊息方塊時重新引發，而可能產生無限的訊息方塊迴圈。

建議

此問題有兩個解決方法：

名稱 值
範圍 Edge
版本 4.5
類型 執行階段

受影響的 API

以滑鼠右鍵按一下 WPF DataGrid 資料列標頭會變更 DataGrid 選取項目

詳細資料

選取多個資料列時，若以滑鼠右鍵按一下選取的 System.Windows.Controls.DataGrid 資料列標頭，會導致 System.Windows.Controls.DataGrid 的選取項目變更為只有該資料列。

建議

此此問題在 .NET Framework 4.6 中已修正，因此可藉由升級至該版 .NET Framework 來解決。

名稱 值
範圍 Edge
版本 4.5
類型 執行階段

受影響的 API

在 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) 移除邊界。

名稱 值
範圍 主修
版本 4.5
類型 執行階段

受影響的 API

UIA 現在看得到 WPF DataTemplate 項目

詳細資料

之前，UI 自動化看不到 System.Windows.DataTemplate 項目。 從 4.5 開始，使用者介面自動化將會偵測這些項目。 這在許多情況下很有用，但可能會中斷相依於不含 System.Windows.DataTemplate 項目之 UIA 樹狀目錄的測試。

建議

您可能需要更新此應用程式的 UI 自動化測試，UIA 樹狀目錄現在才能包含先前不可見的 System.Windows.DataTemplate 項目。 例如，預期某些項目彼此相鄰的測試，現在可能需要預期這些項目之間會出現先前不可見的 UIA 項目。 或者，依賴幾個 UIA 項目或其索引的測試，可能需要以新值更新。

名稱 值
範圍 Edge
版本 4.5
類型 執行階段

受影響的 API

WPF DispatcherSynchronizationContext.CreateCopy 現在會傳回新的複本，而不是目前的執行個體

詳細資料

在 .NET Framework 4 中，CreateCopy() 會傳回目前執行個體的參考，主要是當作效能最佳化。 在 .NET Framework 4.5 中，則會傳回新的執行個體，這是第一次能夠認定同等參考，表示執行中執行緒是在正確的同步處理內容中。 程式碼不太可能檢查這些參考的識別是否會受到影響，但由於這項變更，您應該在移轉至 .NET Framework 4.5 或更新版本的過程中，測試呼叫 CreateCopy() 的程式碼。

建議

請注意，CreateCopy() 現在會傳回新的 System.Threading.SynchronizationContext 物件。 之前，使用以此方式產生之對等參考的程式碼不會實際檢查它是否在適當的內容中，但針對 .NET Framework 4.5 或更新版本建置時則會進行檢查。 雖然不太可能會造成問題，但執行受影響的程式碼路徑應該足以判斷是否會造成任何問題。

名稱 值
範圍 Minor
版本 4.5
類型 執行階段

受影響的 API

WPF TextBox 的預設復原限制為 100

詳細資料

在 .NET Framework 4.5 中，WPF TextBox 的預設復原限制為 100 (在 .NET Framework 4.0 中則沒有限制)

建議

如果 100 的復原限制太低，可以使用 UndoLimit 明確設定此限制

名稱 值
範圍 Edge
版本 4.5
類型 執行階段

受影響的 API

WPF TextBox 選取文字在文字方塊非作用中時，會以不同的色彩來顯示

詳細資料

在 .NET Framework 4.5 中，當 WPF 文字方塊控制項非作用中時 (沒有焦點)，方塊內的選取文字會以不同於控制項作用中的色彩來顯示。

建議

將 AreInactiveSelectionHighlightBrushKeysSupported 屬性設為 false 可以還原舊有 (.NET Framework 4.0) 行為。

名稱 值
範圍 Edge
版本 4.5
類型 執行階段

受影響的 API

WPF TreeViewItem 必須在 TreeView 內使用

詳細資料

4.5 中引進一項變更，限制在 System.Windows.Controls.TreeView 外使用 System.Windows.Controls.TreeViewItem 項目。 在下列狀況下可能會發生這種情形：

換句話說，在 System.Windows.Controls.TreeView 外使用 System.Windows.Controls.TreeViewItem，然後使用者點選 System.Windows.Controls.TreeViewItem 的子系將其帶入檢視時，就會看到此問題。 如果 System.Windows.Controls.TreeViewItem 沒有可設定焦點的子系，則絕不會看到此問題。 例如，當 System.Windows.Controls.TreeViewItem 是 DataTemplate 的根項目時，就會遇到此問題。 遇到此問題時，WPF 架構內會出現 InvalidCastException。

建議

未來將針對此問題提供 Hotfix。

名稱 值
範圍 Minor
版本 4.5
類型 執行階段

受影響的 API

無法透過 API 分析偵測。

Windows Workflow Foundation (WF)

System.Activities 現在是 APTCA

詳細資料

組件會以 System.Security.AllowPartiallyTrustedCallersAttribute 屬性標記。

建議

衍生類別無法以 System.Security.SecurityCriticalAttribute 標記。 以往衍生類型必須以 System.Security.SecurityCriticalAttribute 標記。 不過，這項變更應該不會產生實際影響。

名稱 值
範圍 Edge
版本 4.5
類型 執行階段

受影響的 API

無法透過 API 分析偵測。

WF 現在會以不同的方式來序列化 Expressions.Literal<T> DateTimes (中斷自訂 XAML 剖析器)

詳細資料

相關聯的 ValueSerializer 物件會將 Second 和 System.DateTime.Millisecond 元件為非零且 (針對 System.DateTime 值) Kind 屬性不是 Unspecified 的 System.DateTime 或 System.DateTimeOffset 物件轉換為屬性項目語法，而非字串。 這項變更會允許往返 System.DateTime 和 System.DateTimeOffset 值。 假設輸入 XAML 是使用屬性語法的自訂 XAML 剖析器將無法正常運作。

建議

這項變更會允許往返 System.DateTime 和 System.DateTimeOffset 值。 假設輸入 XAML 是使用屬性語法的自訂 XAML 剖析器將無法正常運作。

名稱 值
範圍 Edge
版本 4.5
類型 執行階段

受影響的 API

無法透過 API 分析偵測。

XML、XSLT

XmlSchemaException 現在會正確設定行位置

詳細資料

如果將 SetLineInfo 值傳遞至 Load 方法且發生驗證錯誤，則 LineNumber 和 LinePosition 屬性現在會包含行資訊。

建議

您應該更新假設不會設定 LineNumber 和 LinePosition 的例外狀況處理程式碼，因為當使用 SetLineInfo 載入 XML 時，現在會正確設定這些屬性。

名稱 值
範圍 Edge
版本 4.5
類型 執行階段

受影響的 API

XmlTextReader DTD 實體展開限制為 10,000,000 個字元

詳細資料

DTD 實體展開現在限制為 10,000,000 個字元。 載入無 DTD 實體展開或 DTD 實體展開受限的 XML 檔案並不會受到影響。 若檔案具有展開至超過 10,000,000 個字元的 DTD 實體，則會載入失敗，而且現在會擲回例外狀況。

建議

如果 DTD 實體展開的限制太低，可以使用 MaxCharactersFromEntities 屬性覆寫值 10,000,000。 具有適當 System.Xml.XmlReaderSettings.MaxCharactersFromEntities 值的 System.Xml.XmlReaderSettings 可以傳遞至採用 System.Xml.XmlReaderSettings 的 XmlReader.Create。 Create(String, XmlReaderSettings))

名稱 值
範圍 Edge
版本 4.5
類型 執行階段

受影響的 API

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。

名稱 值
範圍 Edge
版本 4.5
類型 執行階段

受影響的 API

XSLT 樣式表例外狀況訊息已變更

詳細資料

在 .NET Framework 4.5 中，當 XSLT 檔太複雜時，錯誤訊息的文字會是「樣式表太複雜」。在舊版中，錯誤訊息是「XSLT 編譯錯誤」。倚賴錯誤訊息文字的應用程式程式碼將無法運作。 不過，例外狀況類型會保持不變，因此這項變更應該不會產生實際影響。

建議

請將依據此錯誤狀況之例外狀況訊息的任何應用程式程式碼更新為預期會有新訊息，或是 (甚至更佳的做法) 將程式碼更新為只依據尚未變更的例外狀況類型 (System.Xml.Xsl.XsltException)。

名稱 值
範圍 Edge
版本 4.5
類型 執行階段

受影響的 API

.NET Framework 4.5.1

ADO.NET

ADO.NET 現在會嘗試自動重新連接中斷的 SQL 連線

詳細資料

從 .NET Framework 4.5.1 中開始，.NET Framework 將嘗試自動重新連接中斷的 SQL 連線。 雖然這通常會讓應用程式更可靠，但是會有邊緣案例，應用程式必須知道連線已中斷，讓它可以在重新連接時採取某些動作。

建議

如果基於相容性考量，您不想要這項功能，可以將連接字串的 System.Data.SqlClient.SqlConnectionStringBuilder.ConnectRetryCount 屬性 (或 System.Data.SqlClient.SqlConnectionStringBuilder) 設為 0 來加以停用。

名稱 值
範圍 Edge
版本 4.5.1
類型 執行階段

受影響的 API

核心

在 .NET Framework 4.5 中利用 NetDataContractSerializer 序列化過的 ConcurrentDictionary，無法由 .NET Framework 4.5.1 或 4.5.2 還原序列化

詳細資料

由於此類型的內部變更，使用 System.Runtime.Serialization.NetDataContractSerializer 以 .NET Framework 4.5 序列化的 ConcurrentDictionary<TKey,TValue> 物件，無法在 .NET Framework 4.5.1 或 .NET Framework 4.5.2 中還原序列化。請注意，反向移動 (以 .NET Framework 4.5.x 序列化並以 .NET Framework 4.5 還原序列化) 則運作正常。 同樣地，所有 4.x 跨版本序列化在 .NET Framework 4.6 中都會正常運作。以單一 .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 來解決。

名稱 值
範圍 Minor
版本 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 將會解決問題。

名稱 值
範圍 主修
版本 4.5
類型 執行階段

受影響的 API

分析工具不會列舉 COR_PRF_GC_ROOT_HANDLE

詳細資料

在 .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 來解決。

名稱 值
範圍 Minor
版本 4.5.1
類型 執行階段

受影響的 API

無法透過 API 分析偵測。

還原序列化跨應用程式網域的物件會失敗

詳細資料

在某些情況下，當應用程式使用具有不同應用程式基底的兩個或多個應用程式網域時，嘗試在邏輯呼叫內容中還原序列化跨應用程式網域的物件會擲回例外狀況。

建議

請參閱緩和：在應用程式定義域之間還原序列化物件

名稱 值
範圍 Edge
版本 4.5.1
類型 執行階段

受影響的 API

無法透過 API 分析偵測。

EventListener 會截斷內嵌 Null 的字串

詳細資料

System.Diagnostics.Tracing.EventListener 會截斷內嵌 Null 的字串。 System.Diagnostics.Tracing.EventSource 類別不支援 Null 字元。 這項變更只會影響使用 System.Diagnostics.Tracing.EventListener 讀取處理中 System.Diagnostics.Tracing.EventSource 資料並使用 Ｎull 字元做為分隔符號的應用程式。

建議

如果可能的話，您應該更新 System.Diagnostics.Tracing.EventSource 資料，不要使用內嵌 Null 字元。

名稱 值
範圍 Edge
版本 4.5.1
類型 執行階段

受影響的 API

EventSource.WriteEvent impl 必須將收到的相同參數傳遞給 WriteEvent (再加上識別碼)

詳細資料

執行階段現在會強制執行指定下列作業的合約：定義 ETW 事件方法之衍生自 System.Diagnostics.Tracing.EventSource 的類別在呼叫基底類別 EventSource.WriteEvent 方法時，必須在事件識別碼後面接著傳遞 ETW 事件方法的相同目的地引數。

建議

如果 System.IndexOutOfRangeException 讀取來自於違反此合約之事件來源的處理中 System.Diagnostics.Tracing.EventListener 資料，則會擲回 System.Diagnostics.Tracing.EventSource 例外狀況。

名稱 值
範圍 Minor
版本 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# 動態關鍵字) 可能會造成 MethodInvocationExceptions，因為新增了可能對指令碼引擎模稜兩可的方法多載。

建議

請更新指令碼，以清楚指出應使用哪個多載。 一般而言，將方法的型別參數明確轉換成 Type，即可完成此作業。 如需如何解決問題的詳細資訊和範例，請參閱這個連結。

名稱 值
範圍 Minor
版本 4.5.1
類型 執行階段

受影響的 API

無法透過 API 分析偵測。

某些 .NET API 會造成第一個可能發生 (已處理) 的 EntryPointNotFoundException

詳細資料

在 .NET Framework 4.5 中，少數 .NET 方法已開始擲回第一個可能發生的 System.EntryPointNotFoundException。 這些例外狀況在 .NET Framework 中已處理，但可能會中斷未預期第一個可能發生例外狀況的測試自動化。 這些相同的 API 會在啟用 HighVersionLie 時中斷一些 ApiVerifier 案例。

建議

您可以升級至 .NET Framework 4.5.1 來避免此錯誤 (bug)。 或者，您也可以更新測試自動化，使其不會在首次發生 System.EntryPointNotFoundException 例外狀況時發生中斷。

值
範圍 Edge
版本 4.5
類型 執行階段

受影響的 API

WinRT 資料流配接器不會再於關閉時自動呼叫 FlushAsync

詳細資料

在 Windows 市集應用程式中，Windows 執行階段資料流配接器不會再從 Dispose 方法呼叫 FlushAsync 方法。

建議

這項變更應該是透明的。 開發人員可以撰寫下列程式碼來還原舊有行為：

using (var stream = GetWindowsRuntimeStream() as Stream)
{
// do something
await stream.FlushAsync();
}
名稱 值
範圍 透明
版本 4.5.1
類型 執行階段

受影響的 API

無法透過 API 分析偵測。

資料

ADO.NET 現在會嘗試自動重新連接中斷的 SQL 連線

詳細資料

從 .NET Framework 4.5.1 中開始，.NET Framework 將嘗試自動重新連接中斷的 SQL 連線。 雖然這通常會讓應用程式更可靠，但是會有邊緣案例，應用程式必須知道連線已中斷，讓它可以在重新連接時採取某些動作。

建議

如果基於相容性考量，您不想要這項功能，可以將連接字串的 System.Data.SqlClient.SqlConnectionStringBuilder.ConnectRetryCount 屬性 (或 System.Data.SqlClient.SqlConnectionStringBuilder) 設為 0 來加以停用。

名稱 值
範圍 Edge
版本 4.5.1
類型 執行階段

受影響的 API

序列化

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 或更新版本還原序列化時，無法正確還原序列化的已知類型。

建議

此問題有許多可能的因應措施：

名稱 值
範圍 Minor
版本 4.5.1
類型 執行階段

受影響的 API

Windows Communication Foundation (WCF)

現在會遵守 MinFreeMemoryPercentageToActiveService

詳細資料

此設定建立伺服器上必須提供才能啟動 WCF 服務的最小記憶體。 其設計目的是為了防止發生 System.OutOfMemoryException 例外狀況。 在 .NET Framework 4.5 中，此設定不會造成影響。 在 .NET Framework 4.5.1 中，會遵守此設定。

建議

如果 Ｗeb 伺服器上可用的記憶體小於此組態設定所定義的百分比，則會發生例外狀況。 某些成功啟動並在有限記憶體環境下執行的 WCF 服務現在可能會失敗。

名稱 值
範圍 Minor
版本 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) 移除邊界。

名稱 值
範圍 主修
版本 4.5
類型 執行階段

受影響的 API

.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 來存取。

名稱 值
範圍 Minor
版本 4.5.2
類型 執行階段

受影響的 API

無法再將 EnableViewStateMac 設定為 false

詳細資料

ASP.NET 不再允許開發人員指定 <pages enableViewStateMac=&quot;false&quot;/> 或 <@Page EnableViewStateMac=&quot;false&quot; %>。 檢視狀態訊息驗證碼 (MAC) 現在會強制所有要求內嵌檢視狀態。 只會影響將 EnableViewStateMac 屬性明確設定為 false 的應用程式。

建議

EnableViewStateMac 必須假設為 true，而且必須解決任何產生的 MAC 錯誤 (如這個指引中所述，其中包含多個解決方法，視造成 MAC 錯誤的特定原因而定)。

名稱 值
範圍 主修
版本 4.5.2
類型 執行階段

受影響的 API

無法透過 API 分析偵測。

分析 ASP.NET MVC4 應用程式可能會導致嚴重的執行引擎錯誤

詳細資料

使用 NGEN /Profile 組件的分析工具可能會在啟動時損毀已分析的 ASP.NET MVC4 應用程式，並顯示「嚴重的執行引擎例外狀況」

建議

此問題在 .NET Framework 4.5.2 中已修正。 或者，分析工具時可能會藉由在其事件遮罩中指定 COR_PRF_DISABLE_ALL_NGEN_IMAGES 來避免這個問題。

名稱 值
範圍 Edge
版本 4.5
類型 執行階段

受影響的 API

無法透過 API 分析偵測。

資料

SqlConnection.Open 在有非 IFS Winsock BSP 或 LSP 的 Windows 7 上會失敗

詳細資料

在 .NET Framework 4.5 中，如果 Open() 和 OpenAsync(CancellationToken) 在 Windows 7 電腦上執行，而且該電腦上有非 IFS Winsock BSP 或 LSP，則會失敗。若要判斷是否已安裝非 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 來避免此錯誤 (bug)。

名稱 值
範圍 Minor
版本 4.5
類型 執行階段

受影響的 API

Entity Framework

針對具有特定字元的 QueryView，不再擲回 EF

詳細資料

當應用程式執行與 QueryView (導覽屬性為 0..1) 相關的查詢，嘗試在查詢中包含相關的項目時，Entity Framework 不再擲回 System.StackOverflowException 例外狀況。 例如，藉由呼叫 .Include(e =&gt; e.RelatedNavProp)。

建議

這項變更只會影響在執行呼叫 .Include 的查詢時，使用 QueryView (關聯性為 1-0..1) 的程式碼。 這項功能可提高可靠性，對於幾乎所有應用程式應該都是透明的。 不過，如果這項功能造成未預期的行為，您可以在應用程式組態檔的 <appSettings> 區段中加入下列項目，來停用這項功能：

<add key="EntityFramework_SimplifyUserSpecifiedViews" value="false" />
名稱 值
範圍 Edge
版本 4.5.2
類型 執行階段

受影響的 API

無法透過 API 分析偵測。

選擇中斷以從不同的 4.5 SQL 產生還原為更簡單的 4.0 SQL 產生

詳細資料

產生 JOIN 陳述式並包含限制作業呼叫 (不先使用 OrderBy) 的查詢，現在能產生更簡單的 SQL。 升級至 .NET Framework 4.5 之後，這些查詢會產生比舊版更複雜的 SQL。

建議

此功能預設為停用。 如果 Entity Framework 產生額外的 JOIN 陳述式而造成效能降低，您可以啟用這項功能，方法是在應用程式組態檔 (app.config) 的 <appSettings> 區段中新增下列項目：

<add key="EntityFramework_SimplifyLimitOperations" value="true" />
名稱 值
範圍 透明
版本 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，來避免此 Bug。

名稱 值
範圍 Edge
版本 4.5
類型 執行階段

受影響的 API

使用自訂 DataTemplates 時，會斷斷續續無法捲動至 ItemsControls (例如 ListBox 和 DataGrid) 中的底部項目

詳細資料

在某些情況下，.NET Framework 4.5 中的 Bug 會導致在使用自訂 DataTemplates 時，ItemsControls (例如 System.Windows.Controls.ListBox、System.Windows.Controls.ComboBox、System.Windows.Controls.DataGrid 等) 無法捲動至其底部項目。 如果嘗試捲動第二次 (在向上捲動之後)，則會再次運作。

建議

此問題在 .NET Framework 4.5.2 中已修正，因此可藉由升級至該版 .NET Framework (或更新版本) 來解決。 此外，使用者仍可將捲軸拖曳至這些集合中的最後一個項目，但可能需要嘗試兩次才能成功。

名稱 值
範圍 Minor
版本 4.5
類型 執行階段

受影響的 API

無法透過 API 分析偵測。

WPF 會繁衍可以凍結滑鼠的 wisptis.exe 處理序

詳細資料

在 4.5.2 中產生了一個問題，導致繁衍可凍結滑鼠輸入的 wisptis.exe。

建議

解決此問題的修正程式可在 .NET Framework 4.5.2 的服務版本 (Hotfix 彙總套件 3026376) 中取得，或藉由升級至 .NET Framework 4.6 取得

名稱 值
範圍 主修
版本 4.5.2
類型 執行階段

受影響的 API

無法透過 API 分析偵測。

XML

XML 剖析變更

名稱 值
範圍 Minor
版本 4.5.2
類型 執行階段

詳細資料

基於安全性原因，已將下列變更引進 XML 剖析 APIS：

注意

XmlReaderSettings 是由所有 XML 剖析器使用，因此雖然這項變更有助於 XmlReader 案例，但其也會影響其他案例。

建議

若要還原為先前的行為，您可以在登錄中設定一值。 將名為 EnableLegacyXmlSettings 的 DWORD 值新增至 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\XML 登錄機碼，並將其值設定為 1。 您也可以改為在 HKEY_CURRENT_USER Hive 中新增登錄值。

受影響的 API

此外，直接或間接相依於 XmlResolver 的任何 XML API 都會受到影響。