將移轉變更從 .NET Framework 4.5.2 重定為 4.6.1Retargeting Changes for Migration from .NET Framework 4.5.2 to 4.6.1

如果您想從 .NET Framework 4.5.2 移轉至 4.6.1,請檢閱下列主題中可能會影響應用程式的應用程式相容性問題:If you are migrating from the .NET Framework 4.5.2 to 4.6.1, review the following topics for application compatibility issues that may affect your app:

ASP.NETASP.NET

HtmlTextWriter 無法正確轉譯 <br/> 項目HtmlTextWriter does not render <br/> element correctly

詳細資料Details

從 .NET Framework 4.6 開始,使用 <BR /> 項目呼叫 RenderBeginTag(String)RenderEndTag() 將會正確地只插入一個 <BR /> (而不是兩個)Beginning in the .NET Framework 4.6, calling RenderBeginTag(String) and RenderEndTag() with a <BR /> element will correctly insert only one <BR /> (instead of two)

建議Suggestion

如果應用程式需要額外的 <BR /> 標籤,則應該再次呼叫 RenderBeginTag(String)If an app depended on the extra <BR /> tag, RenderBeginTag(String) should be called a second time. 請注意,這項行為變更只會影響以 .NET Framework 4.6 或更新版本為目標的應用程式,因此另一個做法是以舊版 .NET Framework 為目標,以取得舊版行為。Note that this behavior change only affects apps that target the .NET Framework 4.6 or later, so another option is to target a previous version of the .NET Framework in order to get the old behavior.

名稱Name Value
影響範圍Scope EdgeEdge
版本Version 4.64.6
類型Type 正在重定目標Retargeting

受影響的 APIAffected APIs

ClickOnceClickOnce

透過 ClickOnce 發行的應用程式,這些應用程式使用可能會在 Windows 2003 上失敗的 SHA-256 程式碼簽署憑證Apps published with ClickOnce that use a SHA-256 code-signing certificate may fail on Windows 2003

詳細資料Details

這個可執行檔使用 SHA256 簽署。The executable is signed with SHA256. 之前,不論程式碼簽署憑證為 SHA-1 或 SHA-256,都會使用 SHA1 簽署。Previously, it was signed with SHA1 regardless of whether the code-signing certificate was SHA-1 or SHA-256. 這適用於:This applies to:

  • 使用 Visual Studio 2012 (含) 以後版本建置的所有應用程式。All applications built with Visual Studio 2012 or later.
  • 使用 Visual Studio 2010 (含) 以前版本,在具有 .NET Framework 4.5 的系統上建置應用程式。Applications built with Visual Studio 2010 or earlier on systems with the .NET Framework 4.5 present. 此外,如果有 .NET Framework 4.5 (含) 以後版本,也會針對 SHA-256 憑證使用 SHA-256 來簽署 ClickOnce 資訊清單,而不論編譯的 .NET Framework 版本為何。In addition, if the .NET Framework 4.5 or later is present, the ClickOnce manifest is also signed with SHA-256 for SHA-256 certificates regardless of the .NET Framework version against which it was compiled.

建議Suggestion

對簽署 ClickOnce 可執行檔所做的變更只會影響 Windows Server 2003 系統;這些變更需要安裝 KB 938397。The change in signing the ClickOnce executable affects only Windows Server 2003 systems; they require that KB 938397 be installed. 對使用 SHA-256 簽署資訊清單所做的變更還會引進 .NET Framework 4.5 (含) 以後版本的執行階段相依性,即使應用程式是以 .NET Framework 4.0 (含) 以前版本為目標亦然。The change in signing the manifest with SHA-256 even when an app targets the .NET Framework 4.0 or earlier versions introduces a runtime dependency on the .NET Framework 4.5 or a later version.

名稱Name Value
影響範圍Scope EdgeEdge
版本Version 4.54.5
類型Type 正在重定目標Retargeting

ClickOnce 在 4.0 為目標的應用程式上支援 SHA-256ClickOnce supports SHA-256 on 4.0-targeted apps

詳細資料Details

先前,具有使用 SHA-256 簽署之憑證的 ClickOnce 應用程式,需要有 .NET Framework 4.5 或更新版本存在,即使應用程式是以 4.0 為目標。Previously, a ClickOnce app with a certificate signed with SHA-256 would require .NET Framework 4.5 or later to be present, even if the app targeted 4.0. 現在,即使使用 SHA-256 簽署,以 .NET Framework 4.0 為目標的 ClickOnce 應用程式也可以在 .NET Framework 4.0 上執行。Now, .NET Framework 4.0-targeted ClickOnce apps can run on .NET Framework 4.0, even if signed with SHA-256.

建議Suggestion

這項變更移除了該相依性,並允許使用 SHA-256 憑證來簽署以 .NET Framework 4 和更早版本為目標的 ClickOnce 應用程式。This change removes that dependency and allows SHA-256 certificates to be used to sign ClickOnce apps that target .NET Framework 4 and earlier versions.

名稱Name Value
影響範圍Scope MinorMinor
版本Version 4.64.6
類型Type 正在重定目標Retargeting

核心Core

ZipArchiveEntry 物件的 FullName 屬性中路徑分隔符號字元變更Change in path separator character in FullName property of ZipArchiveEntry objects

詳細資料Details

針對以 .NET Framework 4.6.1 和更新版本為目標的應用程式,在方法的多載所建立之物件的屬性中,路徑分隔符號已從反斜線 ( " \ " ) 變更為正斜線 ( "/" ) FullName ZipArchiveEntry CreateFromDirectoryFor apps that target the .NET Framework 4.6.1 and later versions, the path separator character has changed from a backslash ("\") to a forward slash ("/") in the FullName property of ZipArchiveEntry objects created by overloads of the CreateFromDirectory method. 這項變更使得 .NET 實作遵守 .ZIP File Format Specification (.ZIP 檔案格式規格) 的 4.4.17.1 小節,並允許在非 Windows 系統上解壓縮 ZIP 封存。The change brings the .NET implementation into conformity with section 4.4.17.1 of the .ZIP File Format Specification and allows .ZIP archives to be decompressed on non-Windows systems.
在非 Windows 作業系統 (例如 Macintosh) 上解壓縮以舊版 .NET Framework 為目標的應用程式所建立的 ZIP 檔案,會無法保留目錄結構。Decompressing a zip file created by an app that targets a previous version of the .NET Framework on non-Windows operating systems such as the Macintosh fails to preserve the directory structure. 例如,在 Macintosh 上,它會建立一組檔案,其檔案名稱會串連目錄路徑,以及任何反斜線 (\) 字元和檔案名稱。For example, on the Macintosh, it creates a set of files whose filename concatenates the directory path, along with any backslash ("\") characters, and the filename. 因此,解壓縮檔案的目錄結構會無法保留。As a result, the directory structure of decompressed files is not preserved.

建議Suggestion

這項變更對的影響。在 Windows 作業系統上,由 .NET Framework 命名空間中的 Api 解壓縮的 ZIP 檔案 System.IO 應該是最小的,因為這些 api 可以順暢地處理正斜線 ( "/" ) 或反斜線 ( " \ " ) 做為路徑分隔字元。The impact of this change on .ZIP files that are decompressed on the Windows operating system by APIs in the .NET Framework System.IO namespace should be minimal, since these APIs can seamlessly handle either a forward slash ("/") or a backslash ("\") as the path separator character.
如果不需要這項變更,您可以新增設定至 <runtime> 應用程式佈建檔的區段,以退出宣告。If this change is undesirable, you can opt out of it by adding a configuration setting to the <runtime> section of your application configuration file. 下列範例顯示 <runtime> 區段及 Switch.System.IO.Compression.ZipFile.UseBackslash 選擇退出參數:The following example shows both the <runtime> section and the Switch.System.IO.Compression.ZipFile.UseBackslash opt-out switch:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.Compression.ZipFile.UseBackslash=true" />
</runtime>

此外,以舊版 .NET Framework 為目標但在 .NET Framework 4.6.1 和更新版本上執行的應用程式,可以藉由新增設定至 <runtime> 應用程式佈建檔的區段,來加入宣告此行為。In addition, apps that target previous versions of the .NET Framework but are running on the .NET Framework 4.6.1 and later versions can opt in to this behavior by adding a configuration setting to the <runtime> section of the application configuration file. 下圖顯示 <runtime> 區段及 Switch.System.IO.Compression.ZipFile.UseBackslash 選擇加入參數。The following shows both the <runtime> section and the Switch.System.IO.Compression.ZipFile.UseBackslash opt-in switch.

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.Compression.ZipFile.UseBackslash=false" />
</runtime>
名稱Name Value
範圍Scope EdgeEdge
版本Version 4.6.14.6.1
類型Type 正在重定目標Retargeting

受影響的 APIAffected APIs

工作之間的 CurrentCulture 和 CurrentUICulture 流程CurrentCulture and CurrentUICulture flow across tasks

詳細資料Details

從 .NET Framework 4.6 開始,System.Globalization.CultureInfo.CurrentCultureSystem.Globalization.CultureInfo.CurrentUICulture 會儲存在執行緒的 System.Threading.ExecutionContext,它會在非同步作業之間流動。這表示變更 System.Globalization.CultureInfo.CurrentCultureSystem.Globalization.CultureInfo.CurrentUICulture 會反映在稍後以非同步方式執行的工作。Beginning in the .NET Framework 4.6, System.Globalization.CultureInfo.CurrentCulture and System.Globalization.CultureInfo.CurrentUICulture are stored in the thread's System.Threading.ExecutionContext, which flows across asynchronous operations.This means that changes to System.Globalization.CultureInfo.CurrentCulture or System.Globalization.CultureInfo.CurrentUICulture will be reflected in tasks which are later run asynchronously. 這與舊版 .NET Framework 的行為不同,而舊版本會重設所有非同步工作中的 System.Globalization.CultureInfo.CurrentCultureSystem.Globalization.CultureInfo.CurrentUICultureThis is different from the behavior of previous .NET Framework versions (which would reset System.Globalization.CultureInfo.CurrentCulture and System.Globalization.CultureInfo.CurrentUICulture in all asynchronous tasks).

建議Suggestion

受到此變更影響的應用程式,可以藉由明確地設定所需的 System.Globalization.CultureInfo.CurrentCultureSystem.Globalization.CultureInfo.CurrentUICulture 作為非同步工作中的第一個作業來因應。Apps affected by this change may work around it by explicitly setting the desired System.Globalization.CultureInfo.CurrentCulture or System.Globalization.CultureInfo.CurrentUICulture as the first operation in an async Task. 或者,可以藉由設定下列相容性參數,以選擇加入舊的行為 (不流動 System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture):Alternatively, the old behavior (of not flowing System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture) may be opted into by setting the following compatibility switch:

AppContext.SetSwitch("Switch.System.Globalization.NoAsyncCurrentCulture", true);

.NET Framework 4.6.2 中的 WPF 已修正此問題。This issue has been fixed by WPF in .NET Framework 4.6.2. .NET Frameworks 4.6、4.6.1 也已透過 KB 3139549 進行修正。It has also been fixed in .NET Frameworks 4.6, 4.6.1 through KB 3139549. 以 .NET Framework 4.6 或更新版本為目標的應用程式將在 WPF 應用程式中自動取得正確的行為 - System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture 會跨發送器作業保留。Applications targeting .NET Framework 4.6 or later will automatically get the right behavior in WPF applications - System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture) would be preserved across Dispatcher operations.

名稱Name Value
影響範圍Scope MinorMinor
版本Version 4.64.6
類型Type 正在重定目標Retargeting

受影響的 APIAffected APIs

ETW 事件名稱不能只有 "Start" 或 "Stop" 尾碼不同ETW event names cannot differ only by a "Start" or "Stop" suffix

詳細資料Details

在 .NET Framework 4.6 和4.6.1 中,執行時間會在 ArgumentException 兩個 Windows 事件追蹤(ETW)事件名稱不同于 "Start" 或 "Stop" 後置詞時擲回(當一個事件名為 LogUser 且另一個名為時 LogUserStart )。In the .NET Framework 4.6 and 4.6.1, the runtime throws an ArgumentException when two Event Tracing for Windows (ETW) event names differ only by a "Start" or "Stop" suffix (as when one event is named LogUser and another is named LogUserStart). 在此情況下,執行階段無法建構事件來源,因此無法發出任何記錄。In this case, the runtime cannot construct the event source, which cannot emit any logging.

建議Suggestion

若要避免這個例外狀況,請確定沒有任何兩個事件名稱的差異只在於 "Start" 或 "Stop" 後置詞。從 .NET Framework 4.6.2 開始,會移除這項需求;執行時間可以區分只有 "Start" 和 "Stop" 尾碼不同的事件名稱。To prevent the exception, ensure that no two event names differ only by a "Start" or "Stop" suffix.This requirement is removed starting with the .NET Framework 4.6.2; the runtime can disambiguate event names that differ only by the "Start" and "Stop" suffix.

名稱Name Value
影響範圍Scope EdgeEdge
版本Version 4.64.6
類型Type 正在重定目標Retargeting

Entity FrameworkEntity Framework

如果使用 EntityDeploySplit 或 EntityClean 工作,以 Visual Studio 2013 建置 Entity Framework edmx 可能會失敗,並出現錯誤 MSB4062Building an Entity Framework edmx with Visual Studio 2013 can fail with error MSB4062 if using the EntityDeploySplit or EntityClean tasks

詳細資料Details

MSBuild 12.0 工具 (隨附於 Visual Studio 2013) 已變更 MSBuild 檔案位置,導致舊版 Entity Framework 的目標檔案無效。MSBuild 12.0 tools (included in Visual Studio 2013) changed MSBuild file locations, causing older Entity Framework targets files to be invalid. 結果是 EntityDeploySplitEntityClean 工作會失敗,因為找不到 Microsoft.Data.Entity.Build.Tasks.dllThe result is that EntityDeploySplit and EntityClean tasks fail because they are unable to find Microsoft.Data.Entity.Build.Tasks.dll. 請注意,造成此中斷的原因是工具組 (MSBuild/VS) 變更,而不是 .NET Framework 變更。Note that this break is because of a toolset (MSBuild/VS) change, not because of a .NET Framework change. 只有在升級開發人員工具時才會發生此情況,若只是升級 .NET Framework 則不會發生。It will only occur when upgrading developer tools, not when merely upgrading the .NET Framework.

建議Suggestion

Entity Framework 的目標檔案已修正,從 .NET Framework 4.6 開始,可搭配新的 MSBuild 配置使用。Entity Framework targets files are fixed to work with the new MSBuild layout beginning in the .NET Framework 4.6. 升級至該版 Framework 將會修正此問題。Upgrading to that version of the Framework will fix this issue. 或者,您也可以使用此因應措施來直接修補目標檔案。Alternatively, this workaround can be used to patch the targets files directly.

名稱Name Value
影響範圍Scope 主要Major
版本Version 4.5.14.5.1
類型Type 正在重定目標Retargeting

JITJIT

try 區域中不允許 IL retIL ret not allowed in a try region

詳細資料Details

不同於 JIT64 Just-In-Time 編譯器,RyuJIT (用於 .NET Framework 4.6) 不允許在 try 區域中使用 IL ret 指令。Unlike the JIT64 just-in-time compiler, RyuJIT (used in .NET Framework 4.6) does not allow an IL ret instruction in a try region. ECMA-335 規格不允許從 try 區域傳回,而且不會有已知的受控編譯器產生這類 IL。Returning from a try region is disallowed by the ECMA-335 specification, and no known managed compiler generates such IL. 不過,如果這類 IL 是由反映發出所產生,則 JIT64 編譯器將會執行這類 IL。However, the JIT64 compiler will execute such IL if it is generated using reflection emit.

建議Suggestion

如果應用程式產生在 try 區域中包含 ret opcode 的 IL,應用程式可以 .NET Framework 4.5 為目標,即可使用舊的 JIT,以避免這項中斷。If an app is generating IL that includes a ret opcode in a try region, the app may target .NET Framework 4.5 to use the old JIT and avoid this break. 或者,可以將產生的 IL 更新為在 try 區域之後傳回。Alternatively, the generated IL may be updated to return after the try region.

名稱Name Value
影響範圍Scope EdgeEdge
版本Version 4.64.6
類型Type 正在重定目標Retargeting

.NET Framework 4.6 中的新 64 位元 JIT 編譯器New 64-bit JIT compiler in the .NET Framework 4.6

詳細資料Details

從 .NET Framework 4.6 開始,使用新的 64 位元 JIT 編譯器來進行 Just-In-Time 編譯。Starting with the .NET Framework 4.6, a new 64-bit JIT compiler is used for just-in-time compilation. 在某些情況下,如果使用 32 位元編譯器或舊版 64 位元 JIT 編譯器來執行應用程式,則會擲回非預期的例外狀況或遵守不同的行為。In some cases, an unexpected exception is thrown or a different behavior is observed than if an app is run using the 32-bit compiler or the older 64-bit JIT compiler. 這種變更不會影響32位 JIT 編譯程式。This change does not affect the 32-bit JIT compiler. 下列是已知的差異︰The known differences include the following:

  • 在某些情況下,已開啟最佳化的發行組建中的 Unboxing 作業可能會擲回 NullReferenceExceptionUnder certain conditions, an unboxing operation may throw a NullReferenceException in Release builds with optimization turned on.
  • 在某些情況下,執行大型方法主體中的實際執行程式碼可能會擲回 StackOverflowExceptionIn some cases, execution of production code in a large method body may throw a StackOverflowException.
  • 某些狀況下,發行組建中傳遞至方法的結構會被視為參考型別而非實值型別。Under certain conditions, structures passed to a method are treated as reference types rather than as value types in Release builds. 這個問題的其中一種表現,就是集合中的個別項目會以非預期的順序出現。One of the manifestations of this issue is that the individual items in a collection appear in an unexpected order.
  • 在某些情況下,如果啟用最佳化,UInt16 的值在設定高位元時的比較會不正確。Under certain conditions, the comparison of UInt16 values with their high bit set is incorrect if optimization is enabled.
  • 在某些情況下,尤其是初始化陣列值時,使用 OpCodes.Initblk IL 指令初始化記憶體,可能會以不正確的值初始化記憶體。Under certain conditions, particularly when initializing array values, memory initialization by the OpCodes.Initblk IL instruction may initialize memory with an incorrect value. 這會造成未處理的例外狀況或不正確的輸出。This can result either in an unhandled exception or incorrect output.
  • 在少數情況下,如果啟用編譯器最佳化,條件式位元測試可能會傳回不正確的 Boolean 值或擲回例外狀況。Under certain rare conditions, a conditional bit test can return the incorrect Boolean value or throw an exception if compiler optimizations are enabled.
  • 某些狀況下,如果使用 if 陳述式在進入 try 區塊之前和自 try 區塊退出時測試某項條件,而且也在 catchfinally 區塊中評估該條件時,新版 64 位元 JIT 編譯器在最佳化程式碼時會將 if 條件自 catchfinally 區塊中移除。Under certain conditions, if an if statement is used to test for a condition before entering a try block and in the exit from the try block, and the same condition is evaluated in the catch or finally block, the new 64-bit JIT compiler removes the if condition from the catch or finally block when it optimizes code. 因此,catchfinally 區塊的 if 陳述式中的程式碼會無條件執行。As a result, code inside the if statement in the catch or finally block is executed unconditionally.

建議Suggestion

降低已知問題的風險Mitigation of known issues
如果您遇到上述問題,可以採取以下任一種方式來解決︰If you encounter the issues listed above, you can address them by doing any of the following:

  • 升級至 .NET Framework 4.6.2。Upgrade to the .NET Framework 4.6.2. 隨附於 .NET Framework 4.6.2 中的新版 64 位元編譯器可以解決這些已知問題。The new 64-bit compiler included with the .NET Framework 4.6.2 addresses each of these known issues.

  • 執行 Windows Update,確定您的 Windows 已更新至最新版本。Ensure that your version of Windows is up to date by running Windows Update. .NET Framework 4.6 和 4.6.1 的服務更新可解決上述問題中除了 Unboxing 作業之 NullReferenceException 以外的所有問題。Service updates to the .NET Framework 4.6 and 4.6.1 address each of these issues except the NullReferenceException in an unboxing operation.

  • 使用舊版 64 位元 JIT 編譯器編譯。Compile with the older 64-bit JIT compiler. 如需如何進行的詳細資訊,請參閱降低其他問題的風險一節。See the Mitigation of other issues section for more information on how to do this. 降低其他問題的風險Mitigation of other issues
    如果舊版和新版 64 位元 JIT 編譯器編譯的程式碼之間有任何差異,或是使用新版 64 位元 JIT 編譯器編譯的應用程式偵錯版本和發行版本之間有任何差異,您可以使用舊版 64 位元 JIT 編譯器搭配下列方式來編譯應用程式:If you encounter any other difference in behavior between code compiled with the older 64-bit compiler and the new 64-bit JIT compiler, or between the debug and release versions of your app that are both compiled with the new 64-bit JIT compiler, you can do the following to compile your app with the older 64-bit JIT compiler:

  • 以每個應用程式為基礎,您可以將 < 元素新增至應用程式的設定檔。On a per-application basis, you can add the < element to your application's configuration file. 下列程式碼會停止以新版 64 位元 JIT 編譯器進行編譯,改用舊版 64 位元 JIT 編譯器。The following disables compilation with the new 64-bit JIT compiler and instead uses the legacy 64-bit JIT compiler.

    <?xml version ="1.0"?>
    <configuration>
      <runtime>
       <useLegacyJit enabled="1" />
      </runtime>
    </configuration>
    
  • 若以每一使用者為基礎,您可以將名為 useLegacyJitREG_DWORD 值加入至登錄的 HKEY_CURRENT_USER\SOFTWARE\Microsoft\.NETFramework 索引鍵。On a per-user basis, you can add a REG_DWORD value named useLegacyJit to the HKEY_CURRENT_USER\SOFTWARE\Microsoft\.NETFramework key of the registry. 值為 1 會啟用舊版 64 位元 JIT 編譯器;值為 0 會停用它,並啟用新版 64 位元 JIT 編譯器。A value of 1 enables the legacy 64-bit JIT compiler; a value of 0 disables it and enables the new 64-bit JIT compiler.

  • 若以每一電腦為基礎,您可以將名為 useLegacyJitREG_DWORD 值加入至登錄的 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework 索引鍵。On a per-machine basis, you can add a REG_DWORD value named useLegacyJit to the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework key of the registry. 值為 1 會啟用舊版 64 位元 JIT 編譯器;值為 0 會停用它,並啟用新版 64 位元 JIT 編譯器。A value of 1 enables the legacy 64-bit JIT compiler; a value of 0 disables it and enables the new 64-bit JIT compiler. 您也可以前往 Microsoft Connect 回報錯誤,讓我們知道問題所在。You can also let us know about the problem by reporting a bug on Microsoft Connect.

名稱Name Value
影響範圍Scope EdgeEdge
版本Version 4.64.6
類型Type 正在重定目標Retargeting

網路Networking

憑證 EKU OID 驗證Certificate EKU OID validation

詳細資料Details

從 .NET Framework 4.6 開始,SslStreamServicePointManager 類別會執行增強金鑰使用方法 (EKU) 物件識別碼 (OID) 驗證。Starting with .NET Framework 4.6, the SslStream or ServicePointManager classes perform enhanced key use (EKU) object identifier (OID) validation. 增強金鑰使用方法 (EKU) 延伸模組是表示使用金鑰之應用程式的物件識別碼 (OID) 集合。An enhanced key usage (EKU) extension is a collection of object identifiers (OIDs) that indicate the applications that use the key. EKU OID 驗證會使用遠端憑證回呼,以確保遠端憑證有用於預定目的的正確 OID。EKU OID validation uses remote certificate callbacks to ensure that the remote certificate has the correct OIDs for the intended purpose.

建議Suggestion

如果不需要這項變更,您可以將下列參數新增至 <AppContextSwitchOverrides> ` 應用程式佈建檔的中的,以停用憑證 EKU OID 驗證:If this change is undesirable, you can disable certificate EKU OID validation by adding the following switch to the <AppContextSwitchOverrides> in the ` of your app configuration file:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.Net.DontCheckCertificateEKUs=true" />
</runtime>

重要

提供此設定的目的,只是為了回溯相容性。This setting is provided for backward compatibility only. 不建議用於其他用途。Its use is otherwise not recommended.

名稱Name Value
影響範圍Scope MinorMinor
版本Version 4.64.6
類型Type 正在重定目標Retargeting

受影響的 APIAffected APIs

在 System.Net.ServicePointManager 和 System.Net.Security.SslStream 只支援 Tls 1.0、1.1 及 1.2 通訊協定Only Tls 1.0, 1.1 and 1.2 protocols supported in System.Net.ServicePointManager and System.Net.Security.SslStream

詳細資料Details

從 .NET Framework 4.6 開始,只有 ServicePointManagerSslStream 類別可以使用 Tls1.0、Tls1.1 或 Tls 1.2 這三種通訊協定之一。Starting with the .NET Framework 4.6, the ServicePointManager and SslStream classes are only allowed to use one of the following three protocols: Tls1.0, Tls1.1, or Tls1.2. 不支援 SSL3.0 通訊協定與 RC4 編碼器。The SSL3.0 protocol and RC4 cipher are not supported.

建議Suggestion

建議的緩和措施是將伺服器端應用程式升級至 Tls1.0、Tls1.1 或 Tls1.2。The recommended mitigation is to upgrade the sever-side app to Tls1.0, Tls1.1, or Tls1.2. 如果這並不可行,或是用戶端應用程式已中斷,則可使用 System.AppContext 類別搭配下列兩種方式之一,停用這項功能:If this is not feasible, or if client apps are broken, the System.AppContext class can be used to opt out of this feature in either of two ways:

  • 以程式設計方式設定上的相容性參數 System.AppContext ,如這裡所述。By programmatically setting compat switches on the System.AppContext, as explained here.
  • 將下列程式行加入至 app.config 檔案的 <runtime> 區段:By adding the following line to the <runtime> section of the app.config file:
<AppContextSwitchOverrides value="Switch.System.Net.DontEnableSchUseStrongCrypto=true"/>
名稱Name Value
影響範圍Scope MinorMinor
版本Version 4.64.6
類型Type 正在重定目標Retargeting

受影響的 APIAffected APIs

TLS 1.x 依預設會將 SCH_SEND_AUX_RECORD 旗標傳遞至基礎的 SCHANNEL APITLS 1.x by default passes the SCH_SEND_AUX_RECORD flag to the underlying SCHANNEL API

詳細資料Details

使用 TLS 1.x 時,.NET Framework 依賴基礎的 Windows SCHANNEL API。When using TLS 1.x, the .NET Framework relies on the underlying Windows SCHANNEL API. 從 .NET Framework 4.6 開始,預設會傳遞 SCH_SEND_AUX_RECORD 旗標給 SCHANNL。Starting with .NET Framework 4.6, the SCH_SEND_AUX_RECORD flag is passed by default to SCHANNEL. 這會導致 SCHANNEL 分割資料,以便加密成兩個不同的記錄,第一個是單一位元組,第二個則是 n-1 個位元組。在罕見的情況下,這會中斷用戶端與假設資料位於單一記錄中的現有伺服器之間的通訊。This causes SCHANNEL to split data to be encrypted into two separate records, the first as a single byte and the second as n-1 bytes.In rare cases, this breaks communication between clients and existing servers that make the assumption that the data resides in a single record.

建議Suggestion

如果這項變更會中斷與現有伺服器的通訊,您可以停用傳送 SCH_SEND_AUX_RECORD 旗標,並還原先前的行為,不將資料分割成個別的記錄,其方法是新增下列參數到應用程式組態檔 <runtime> 區段中的 <AppContextSwitchOverrides> 項目:If this change breaks communication with an existing server, you can disable sending the SCH_SEND_AUX_RECORD flag and restore the previous behavior of not splitting data into separate records by adding the following switch to the <AppContextSwitchOverrides> element in the <runtime> section of your app configuration file:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.Net.DontEnableSchSendAuxRecord=true" />
</runtime>

重要

提供此設定的目的,只是為了回溯相容性。This setting is provided for backward compatibility only. 不建議用於其他用途。Its use is otherwise not recommended.

名稱Name Value
範圍Scope EdgeEdge
版本Version 4.64.6
類型Type 正在重定目標Retargeting

受影響的 APIAffected APIs

Windows Communication Foundation (WCF)Windows Communication Foundation (WCF)

使用 Null 引數呼叫 CreateDefaultAuthorizationContext 已變更Calling CreateDefaultAuthorizationContext with a null argument has changed

詳細資料Details

使用 Null authorizationPolicies 引數呼叫 System.IdentityModel.Policy.AuthorizationContext.CreateDefaultAuthorizationContext(IList<IAuthorizationPolicy>) 所傳回的 System.IdentityModel.Policy.AuthorizationContext 實作,已變更其在 .NET Framework 4.6 中的實作。The implementation of the System.IdentityModel.Policy.AuthorizationContext returned by a call to the System.IdentityModel.Policy.AuthorizationContext.CreateDefaultAuthorizationContext(IList<IAuthorizationPolicy>) with a null authorizationPolicies argument has changed its implementation in the .NET Framework 4.6.

建議Suggestion

在少數情況下,使用自訂驗證的 WCF 應用程式,在行為上可能會有些許差異。In rare cases, WCF apps that use custom authentication may see behavioral differences. 在此情況下,您可使用下列兩種方式之一還原舊版行為:In such cases, the previous behavior can be restored in either of two ways:

  • 以 .NET Framework 4.6 之前的舊版為目標,重新編譯您的應用程式。Recompile your app to target an earlier version of the .NET Framework than 4.6. 對於裝載在 IIS 上的服務,請使用 <httpRuntime targetFramework="x.x"> 項目,將目標設為舊版 .NET Framework。For IIS-hosted services, use the <httpRuntime targetFramework="x.x"> element to target an earlier version of the .NET Framework.

  • 將下列行加入 app.config 檔案中的 <appSettings> 區段:Add the following line to the <appSettings> section of your app.config file:

    <add key="appContext.SetSwitch:Switch.System.IdentityModel.EnableCachedEmptyDefaultAuthorizationContext" value="true" />
    
名稱Name Value
影響範圍Scope MinorMinor
版本Version 4.64.6
類型Type 正在重定目標Retargeting

受影響的 APIAffected APIs

使用 TransportWithMessageCredential 安全性模式的 WCF 繫結WCF binding with the TransportWithMessageCredential security mode

詳細資料Details

從 .NET Framework 4.6.1 開始,使用 TransportWithMessageCredential 安全性模式的 WCF 繫結可以設定以接收具有不帶正負號 "to" 標頭的非對稱安全性金鑰訊息。根據預設,不帶正負號的 "to" 標頭會繼續在 .NET Framework 4.6.1 中遭到拒絕。Beginning in the .NET Framework 4.6.1, WCF binding that uses the TransportWithMessageCredential security mode can be set up to receive messages with unsigned "to" headers for asymmetric security keys.By default, unsigned "to" headers will continue to be rejected in .NET Framework 4.6.1. 其只有在應用程式使用 Switch.System.ServiceModel.AllowUnsignedToHeader 組態參數來接受此新的作業模式時才會接受。They will only be accepted if an application opts into this new mode of operation using the Switch.System.ServiceModel.AllowUnsignedToHeader configuration switch.

建議Suggestion

由於這是可選擇加入的功能,因此不會影響現有應用程式的行為。Because this is an opt-in feature, it should not affect the behavior of existing apps.
若要控制是否使用新的行為,請使用下列組態設定:To control whether the new behavior is used or not, use the following configuration setting:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.ServiceModel.AllowUnsignedToHeader=true" />
</runtime>
名稱Name Value
影響範圍Scope 透明Transparent
版本Version 4.6.14.6.1
類型Type 正在重定目標Retargeting

受影響的 APIAffected APIs

X509CertificateClaimSet.FindClaims 會考慮所有 claimTypesX509CertificateClaimSet.FindClaims Considers All claimTypes

詳細資料Details

在目標為 .NET Framework 4.6.1 的應用程式中,如果 X509 宣告集是初始化自 SAN 欄位中含有多個 DNS 項目的憑證,System.IdentityModel.Claims.X509CertificateClaimSet.FindClaims(String, String) 方法會嘗試使用所有 DNS 項目來比對 claimType 引數。若是以舊版 .NET Framework 為目標的應用程式,則 System.IdentityModel.Claims.X509CertificateClaimSet.FindClaims(String, String) 方法僅會嘗試使 claimType 引數符合最後一個 DNS 項目。In apps that target the .NET Framework 4.6.1, if an X509 claim set is initialized from a certificate that has multiple DNS entries in its SAN field, the System.IdentityModel.Claims.X509CertificateClaimSet.FindClaims(String, String) method attempts to match the claimType argument with all the DNS entries.For apps that target previous versions of the .NET Framework, the System.IdentityModel.Claims.X509CertificateClaimSet.FindClaims(String, String) method attempts to match the claimType argument only with the last DNS entry.

建議Suggestion

這項變更只會影響以 .NET Framework 4.6.1 為目標的應用程式。This change only affects applications targeting the .NET Framework 4.6.1. 您可以使用 DisableMultipleDNSEntries 相容性參數來停用這項變更 (如果以 4.6.1 以前版本為目標則可啟用)。This change may be disabled (or enabled if targeting pre-4.6.1) with the DisableMultipleDNSEntries compatibility switch.

名稱Name Value
影響範圍Scope MinorMinor
版本Version 4.6.14.6.1
類型Type 正在重定目標Retargeting

受影響的 APIAffected APIs

Windows FormsWindows Forms

針對 IMessageFilter.PreFilterMessage 的可重新進入實作,Application.FilterMessage 不會再擲回例外狀況Application.FilterMessage no longer throws for re-entrant implementations of IMessageFilter.PreFilterMessage

詳細資料Details

在 .NET Framework 4.6.1 之前,使用呼叫 System.Windows.Forms.Application.AddMessageFilter(IMessageFilter)System.Windows.Forms.Application.RemoveMessageFilter(IMessageFilter)PreFilterMessage(Message) 呼叫 FilterMessage(Message) (同時也呼叫DoEvents()) 會造成 System.IndexOutOfRangeExceptionPrior to the .NET Framework 4.6.1, calling FilterMessage(Message) with an PreFilterMessage(Message) which called System.Windows.Forms.Application.AddMessageFilter(IMessageFilter) or System.Windows.Forms.Application.RemoveMessageFilter(IMessageFilter) (while also calling DoEvents()) would cause an System.IndexOutOfRangeException.

從目標為 .NET Framework 4.6.1 的應用程式開始,不會再擲回此例外狀況,而且可能會使用如上所述的可重新進入篩選。Beginning with applications targeting the .NET Framework 4.6.1, this exception is no longer thrown, and re-entrant filters as described above may be used.

建議Suggestion

請注意,FilterMessage(Message) 將不再針對上述的可重新進入 PreFilterMessage(Message) 行為進行擲回。Be aware that FilterMessage(Message) will no longer throw for the re-entrant PreFilterMessage(Message) behavior described above. 這只會影響以 .NET Framework 4.6.1 為目標的應用程式。藉由使用 DontSupportReentrantFilterMessage 相容性參數,以 .NET Framework 4.6.1 為目標的應用程式可退出這項變更 (或以舊版 Framework 為目標的應用程式可加入這項變更)。This only affects applications targeting the .NET Framework 4.6.1.Apps targeting the .NET Framework 4.6.1 can opt out of this change (or apps targeting older Frameworks may opt in) by using the DontSupportReentrantFilterMessage compatibility switch.

名稱Name Value
影響範圍Scope EdgeEdge
版本Version 4.6.14.6.1
類型Type 正在重定目標Retargeting

受影響的 APIAffected APIs

Icon.ToBitmap 成功將具有 PNG 畫面格的圖示轉換成點陣圖物件Icon.ToBitmap successfully converts icons with PNG frames into Bitmap objects

詳細資料Details

從以 .NET Framework 4.6 為目標的應用程式開始,Icon.ToBitmap 方法可將具有 PNG 框架的圖示成功轉換成點陣圖物件。Starting with the apps that target the .NET Framework 4.6, the Icon.ToBitmap method successfully converts icons with PNG frames into Bitmap objects.

在以 .NET Framework 4.5.2 (含) 之前版本為目標的應用程式中,如果圖示物件具有 PNG 框架,則 Icon.ToBitmap 方法會擲回 ArgumentOutOfRangeException 例外狀況。In apps that target the .NET Framework 4.5.2 and earlier versions, the Icon.ToBitmap method throws an ArgumentOutOfRangeException exception if the Icon object has PNG frames.

這項變更會影響重新撰寫之以 .NET Framework 4.6 為目標的應用程式,以及針對圖示物件具有 PNG 框架時所擲回的 ArgumentOutOfRangeException 實作特殊處理的應用程式。This change affects apps that are recompiled to target the .NET Framework 4.6 and that implement special handling for the ArgumentOutOfRangeException that is thrown when an Icon object has PNG frames. 以 .NET Framework 4.6 執行時,轉換會成功,且不再擲回 ArgumentOutOfRangeException ,因此不會再叫用例外狀況處理常式。When running under the .NET Framework 4.6, the conversion is successful, an ArgumentOutOfRangeException is no longer thrown, and therefore the exception handler is no longer invoked.

建議Suggestion

如果不需要這項行為,您可以在 app.config 檔案的 <runtime> 區段中新增下列項目,以保留舊版行為:If this behavior is undesirable, you can retain the previous behavior by adding the following element to the <runtime> section of your app.config file:

<AppContextSwitchOverrides
value="Switch.System.Drawing.DontSupportPngFramesInIcons=true" />

如果 app.config 檔案已經包含 AppContextSwitchOverrides 項目,則應以下列程式碼將新值與值屬性合併:If the app.config file already contains the AppContextSwitchOverrides element, the new value should be merged with the value attribute like this:

<AppContextSwitchOverrides
value="Switch.System.Drawing.DontSupportPngFramesInIcons=true;<previous key>=<previous value>" />
名稱Name Value
影響範圍Scope MinorMinor
版本Version 4.64.6
類型Type 正在重定目標Retargeting

受影響的 APIAffected APIs

Windows Presentation Foundation (WPF)Windows Presentation Foundation (WPF)

在具有觸控功能的系統上呼叫 System.Windows.Input.PenContext.Disable 可能會擲回 ArgumentExceptionCalls to System.Windows.Input.PenContext.Disable on touch-enabled systems may throw an ArgumentException

詳細資料Details

在某些情況下,在具有觸控功能的系統上呼叫內部 System.Windows.Intput.PenContext.Disable 方法,可能會擲回由於重新進入而未處理的 T:System.ArgumentExceptionUnder some circumstances, calls to the internal System.Windows.Intput.PenContext.Disable method on touch-enabled systems may throw an unhandled T:System.ArgumentException because of reentrancy.

建議Suggestion

.NET Framework 4.7 中已解決這個問題。This issue has been addressed in the .NET Framework 4.7. 若要避免這個例外狀況,請升級至從 .NET Framework 4.7 開始的 .NET Framework 版本。To prevent the exception, upgrade to a version of the .NET Framework starting with the .NET Framework 4.7.

名稱Name Value
影響範圍Scope EdgeEdge
版本Version 4.6.14.6.1
類型Type 正在重定目標Retargeting

CurrentCulture 無法跨 WPF 發送器作業保留CurrentCulture is not preserved across WPF Dispatcher operations

詳細資料Details

從 .NET Framework 4.6 開始,在 System.Windows.Threading.Dispatcher 內對 System.Globalization.CultureInfo.CurrentCultureSystem.Globalization.CultureInfo.CurrentUICulture 所做的變更,將會在發送器作業結束時遺失。Beginning in the .NET Framework 4.6, changes to System.Globalization.CultureInfo.CurrentCulture or System.Globalization.CultureInfo.CurrentUICulture made within a System.Windows.Threading.Dispatcher will be lost at the end of that dispatcher operation. 同樣地,在發送器作業外部對 System.Globalization.CultureInfo.CurrentCultureSystem.Globalization.CultureInfo.CurrentUICulture 所做的變更,不會在執行該作業時反映出來。實際上,這表示 System.Globalization.CultureInfo.CurrentCultureSystem.Globalization.CultureInfo.CurrentUICulture 變更可能不會在 WPF UI 回呼與 WPF 應用程式的其他程式碼之間流動。這是因為從以 .NET Framework 4.6 為目標的應用程式開始,System.Threading.ExecutionContext 的變更會導致 System.Globalization.CultureInfo.CurrentCultureSystem.Globalization.CultureInfo.CurrentUICulture 儲存在執行內容中。Similarly, changes to System.Globalization.CultureInfo.CurrentCulture or System.Globalization.CultureInfo.CurrentUICulture made outside of a Dispatcher operation may not be reflected when that operation executes.Practically speaking, this means that System.Globalization.CultureInfo.CurrentCulture and System.Globalization.CultureInfo.CurrentUICulture changes may not flow between WPF UI callbacks and other code in a WPF application.This is due to a change in System.Threading.ExecutionContext that causes System.Globalization.CultureInfo.CurrentCulture and System.Globalization.CultureInfo.CurrentUICulture to be stored in the execution context beginning with apps targeting the .NET Framework 4.6. WPF 發送器作業會儲存用來開始作業的執行內容,並在作業完成時還原先前的內容。WPF dispatcher operations store the execution context used to begin the operation and restore the previous context when the operation is completed. 因為 System.Globalization.CultureInfo.CurrentCultureSystem.Globalization.CultureInfo.CurrentUICulture 現在是該內容的一部分,所以在發送器作業內對其進行的變更不會保留到作業外。Because System.Globalization.CultureInfo.CurrentCulture and System.Globalization.CultureInfo.CurrentUICulture are now part of that context, changes to them within a dispatcher operation are not persisted outside of the operation.

建議Suggestion

您可以將所需的 System.Globalization.CultureInfo.CurrentCultureSystem.Globalization.CultureInfo.CurrentUICulture 儲存在欄位中,然後簽入設定正確 System.Globalization.CultureInfo.CurrentCultureSystem.Globalization.CultureInfo.CurrentUICulture 的所有發送器作業主體 (包括 UI 事件回呼處理常式),來解決受此變更影響的應用程式。Apps affected by this change may work around it by storing the desired System.Globalization.CultureInfo.CurrentCulture or System.Globalization.CultureInfo.CurrentUICulture in a field and checking in all Dispatcher operation bodies (including UI event callback handlers) that the correct System.Globalization.CultureInfo.CurrentCulture and System.Globalization.CultureInfo.CurrentUICulture are set. 此外,由於此 WPF 變更的基本 ExecutionContext 變更只會影響以 .NET Framework 4.6 或更新版本為目標的應用程式,因此您可以將目標設為 .NET Framework 4.5.2 來避免此中斷情況。以 .NET Framework 4.6 或更新版本為目標的應用程式,也可以設定下列相容性參數來解決此問題:Alternatively, because the ExecutionContext change underlying this WPF change only affects apps targeting the .NET Framework 4.6 or newer, this break can be avoided by targeting the .NET Framework 4.5.2.Apps that target .NET Framework 4.6 or later can also work around this by setting the following compatibility switch:

AppContext.SetSwitch("Switch.System.Globalization.NoAsyncCurrentCulture", true);

.NET Framework 4.6.2 中的 WPF 已修正此問題。This issue has been fixed by WPF in .NET Framework 4.6.2. .NET Frameworks 4.6、4.6.1 也已透過 KB 3139549 進行修正。It has also been fixed in .NET Frameworks 4.6, 4.6.1 through KB 3139549. 以 .NET Framework 4.6 或更新版本為目標的應用程式將在 WPF 應用程式中自動取得正確的行為 - System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture 會跨發送器作業保留。Applications targeting .NET Framework 4.6 or later will automatically get the right behavior in WPF applications - System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture) would be preserved across Dispatcher operations.

名稱Name Value
影響範圍Scope MinorMinor
版本Version 4.64.6
類型Type 正在重定目標Retargeting

邊界的 WPF 版面配置進位已變更WPF layout rounding of margins has changed

詳細資料Details

邊界的進位方式以及邊界內部的框線和背景皆有所變更。The way in which margins are rounded and borders and the background inside of them has changed. 此變更的結果:As a result of this change:

  • 項目寬度或高度的增減最多不超過一個像素。The width or height of elements may grow or shrink by at most one pixel.
  • 物件的位置的位最多不超過一個像素。The placement of an object can move by at most one pixel.
  • 置中項目的垂直或水平位移最多不超過一個像素。Centered elements can be vertically or horizontally off center by at most one pixel. 預設只有以 .NET Framework 4.6 為目標的應用程式才會啟用此新版面配置。By default, this new layout is enabled only for apps that target the .NET Framework 4.6.

建議Suggestion

由於此修改會停用高 DPI 之 WPF 控制項右側或底端的裁剪功能,因此,應用程式若是以舊版 .NET Framework 為目標,但要在 .NET Framework 4.6 上執行,可將下行加入 app.config 檔案中的 <runtime> 區段來選擇使用此新行為:Since this modification tends to eliminate clipping of the right or bottom of WPF controls at high DPIs, apps that target earlier versions of the .NET Framework but are running on the .NET Framework 4.6 can opt into this new behavior by adding the following line to the <runtime> section of the app.config file:

<AppContextSwitchOverrides value="Switch.MS.Internal.DoNotApplyLayoutRoundingToMarginsAndBorderThickness=false" />'

應用程式若是以 .NET Framework 4.6 為目標,但想使用先前的配置演算法來呈現 WPF 控制項,可將下行新增至 app.config 檔案中的 <runtime> 區段,以執行此作業:Apps that target the .NET Framework 4.6 but want WPF controls to render using the previous layout algorithm can do so by adding the following line to the <runtime> section of the app.config file:

<AppContextSwitchOverrides value="Switch.MS.Internal.DoNotApplyLayoutRoundingToMarginsAndBorderThickness=true" />'.
名稱Name Value
影響範圍Scope MinorMinor
版本Version 4.64.6
類型Type 正在重定目標Retargeting

XML、XSLTXML, XSLT

無效的代理字組會擲回 XmlWriterXmlWriter throws on invalid surrogate pairs

詳細資料Details

針對以 .NET Framework 4.5.2 或之前版本為目標的應用程式,使用例外狀況後援處理寫入無效的 Surrogate 字組時不一定每次都會擲回例外狀況。For apps that target the .NET Framework 4.5.2 or previous versions, writing an invalid surrogate pair using exception fallback handling does not always throw an exception. 針對以 .NET Framework 4.6 為目標的應用程式,嘗試寫入無效的代理字組會擲回 System.ArgumentException 例外狀況。For apps that target the .NET Framework 4.6, attempting to write an invalid surrogate pair throws an System.ArgumentException.

建議Suggestion

如有必要,可以將目標設為 .NET Framework 4.5.2 或更早版本以避免這項中斷。If necessary, this break can be avoided by targeting the .NET Framework 4.5.2 or earlier. 或者,可以將無效的代理字組字組預先處理成有效的 XML,再寫入它們。Alternatively, invalid surrogate pairs can be pre-processed into valid xml prior to writing them.

名稱Name Value
影響範圍Scope EdgeEdge
版本Version 4.64.6
類型Type 正在重定目標Retargeting

受影響的 APIAffected APIs

如果使用複合索引鍵,而且一個索引鍵為空白,XSD 結構描述驗證現在會正確地偵測唯一條件約束的違規XSD Schema validation now correctly detects violations of unique constraints if compound keys are used and one key is empty

詳細資料Details

.NET Framework 4.6 之前的版本有錯誤 (bug),會導致 XSD 驗證在其中一個索引鍵為空白時,無法偵測複合索引鍵上的唯一條件約束。Versions of the .NET Framework prior to 4.6 had a bug that caused XSD validation to not detect unique constraints on compound keys if one of the keys was empty. 在 .NET Framework 4.6 中,已修正此問題。In the .NET Framework 4.6, this issue is corrected. 這會導致更正確的驗證,但也可能會導致之前可驗證的某些 XML 無法驗證。This will result in more correct validation, but it may also result in some XML not validating which previously would have.

建議Suggestion

如果需要較鬆散的 .NET Framework 4.0 驗證,正在驗證的應用程式可以將目標設為 .NET Framework 4.5 版 (或舊版)。If looser .NET Framework 4.0 validation is needed, the validating application can target version 4.5 (or earlier) of the .NET Framework. 不過,重定目標為 .NET Framework 4.6 時,應完成程式碼檢閱,以確保重複的複合索引鍵 (如本問題說明中所述) 不會導致無效。When retargeting to .NET Framework 4.6, however, code review should be done to be sure that duplicate compound keys (as described in this issue's description) are not expected to validate.

名稱Name Value
影響範圍Scope EdgeEdge
版本Version 4.64.6
類型Type 正在重定目標Retargeting