從 .NET Framework 4.5.2 移轉至 4.8 的重定目標變更Retargeting Changes for Migration from .NET Framework 4.5.2 to 4.8

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

ASP.NETASP.NET

.NET Framework 4.7.1 中的 ASP.NET 協助工具改進功能ASP.NET Accessibility Improvements in .NET Framework 4.7.1

詳細資料Details

從 .NET Framework 4.7.1 開始,ASP.NET 已經改善 ASP.NET Web 控制項如何搭配 Visual Studio 中的協助工具技術,來更妥善支援 ASP.NET 客戶。Starting with the .NET Framework 4.7.1, ASP.NET has improved how ASP.NET Web Controls work with accessibility technology in Visual Studio to better support ASP.NET customers. 這些包括下列變更:These include the following changes:

  • 在控制項中,實作遺漏 UI 協助工具模式的變更,例如在 [詳細資料檢視精靈] 的 [新增欄位] 對話方塊或 ListView 精靈的 [設定 ListView] 對話方塊。Changes to implement missing UI accessibility patterns in controls, like the Add Field dialog in the Details View wizard, or the Configure ListView dialog of the ListView wizard.
  • 改善高對比模式顯示的變更,例如資料頁面巡覽區欄位編輯器。Changes to improve the display in High Contrast mode, like the Data Pager Fields Editor.
  • 改善控制項鍵盤瀏覽體驗的變更,例如 DataPager 控制項 [編輯頁面巡覽區欄位精靈] 的 [欄位] 對話方塊、[設定 ObjectContext] 對話方塊,或 [設定資料來源精靈] 的 [設定資料選取項目] 對話方塊。Changes to improve the keyboard navigation experiences for controls, like the Fields dialog in the Edit Pager Fields wizard of the DataPager control, the Configure ObjectContext dialog, or the Configure Data Selection dialog of the Configure Data Source wizard.

建議Suggestion

如何選擇加入或退出這些變更:為了讓 Visual Studio 設計工具可受益於這些變更,它必須在 .NET Framework 4.7.1 或更新版本上執行。How to opt in or out of these changes In order for the Visual Studio Designer to benefit from these changes, it must run on the .NET Framework 4.7.1 or later. Web 應用程式可以由下列任一種方式受益於這些變更:The web application can benefit from these changes in either of the following ways:

  • 安裝 Visual Studio 2017 15.3 或更新版本中,依預設它會以下列 AppContext 參數支援新的協助工具功能。Install Visual Studio 2017 15.3 or later, which supports the new accessibility features with the following AppContext Switch by default.
  • 藉由將 Switch.UseLegacyAccessibilityFeatures AppContext 參數新增到 devenv.exe.config 檔案中的 <runtime> 區段,並將它設定為 false,選擇退出舊版協助工具行為,如下列範例所示。Opt out of the legacy accessibility behaviors by adding the Switch.UseLegacyAccessibilityFeatures AppContext switch to the <runtime> section in the devenv.exe.config file and setting it to false, as the following example shows.
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<runtime>
...
<!-- AppContextSwitchOverrides value attribute is in the form of 'key1=true/false;key2=true/false'  -->
<AppContextSwitchOverrides value="Switch.UseLegacyAccessibilityFeatures=false" />
...
</runtime>
</configuration>

以 .NET Framework 4.7.1 或更新版本為目標,並且想要保留舊版協助工具行為的應用程式,可以藉由明確將此 AppContext 參數設為 true,選擇加入舊版的協助工具功能。Applications that target the .NET Framework 4.7.1 or later and want to preserve the legacy accessibility behavior can opt in to the use of legacy accessibility features by explicitly setting this AppContext switch to true.

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

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

每一個工作階段的節流閥並行要求數目Throttle concurrent requests per session

詳細資料Details

在 .NET Framework 4.6.2 和更早版本中,ASP.NET 會使用相同的 Sessionid 循序執行要求,且 ASP.NET 預設一律會透過 Cookie 發出 Sessionid。In the .NET Framework 4.6.2 and earlier, ASP.NET executes requests with the same Sessionid sequentially, and ASP.NET always issues the Sessionid through cookies by default. 如果頁面需要很長的時間來回應,則只要在瀏覽器上按F5 ,就會大幅降低伺服器效能。If a page takes a long time to respond, it will significantly degrade server performance just by pressing F5 on the browser. 在修正程式中,我們新增了一個計數器來追蹤佇列要求,並在超過指定限制時終止要求。In the fix, we added a counter to track the queued requests and terminate the requests when they exceed a specified limit. 預設值是 50。The default value is 50. 如果達到限制,會在事件記錄檔記錄警告並在 IIS 記錄檔中記錄 HTTP 500 回應。If the limit is reached, a warning will be logged in the event log, and an HTTP 500 response may be recorded in the IIS log.

建議Suggestion

若要還原舊行為,您可以將下列設定加入您的 web.config 檔案以選擇退出新行為。To restore the old behavior, you can add the following setting to your web.config file to opt out of the new behavior.

<appSettings>
    <add key="aspnet:RequestQueueLimitPerSession" value="2147483647"/>
</appSettings>
名稱Name Value
影響範圍Scope EdgeEdge
版本Version 4.74.7
類型Type 正在重定目標Retargeting

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

AesCryptoServiceProvider 解密程式提供可重複使用的轉換AesCryptoServiceProvider decryptor provides a reusable transform

詳細資料Details

從以 .NET Framework 4.6.2 為目標的應用程式開始,AesCryptoServiceProvider 解密程式會提供可重複使用的轉換。Starting with apps that target the .NET Framework 4.6.2, the AesCryptoServiceProvider decryptor provides a reusable transform. 呼叫 System.Security.Cryptography.CryptoAPITransform.TransformFinalBlock(Byte[], Int32, Int32) 之後,轉換就會重新初始化並且可重複使用。After a call to System.Security.Cryptography.CryptoAPITransform.TransformFinalBlock(Byte[], Int32, Int32), the transform is reinitialized and can be reused. 若為以舊版 .NET Framework 為目標的應用程式,嘗試透過在呼叫 System.Security.Cryptography.CryptoAPITransform.TransformFinalBlock(Byte[], Int32, Int32) 之後呼叫 System.Security.Cryptography.CryptoAPITransform.TransformBlock(Byte[], Int32, Int32, Byte[], Int32) 來重複使用解密程式,會擲回 CryptographicException 或產生損毀的資料。For apps that target earlier versions of the .NET Framework, attempting to reuse the decryptor by calling System.Security.Cryptography.CryptoAPITransform.TransformBlock(Byte[], Int32, Int32, Byte[], Int32) after a call to System.Security.Cryptography.CryptoAPITransform.TransformFinalBlock(Byte[], Int32, Int32) throws a CryptographicException or produces corrupted data.

建議Suggestion

此變更的影響應該很小,因為這是預期的行為。倚賴舊行為的應用程式可以藉由將下列組態設定新增到應用程式設定檔的 <runtime> 區段,選擇不使用:The impact of this change should be minimal, since this is the expected behavior.Applications that depend on the previous behavior can opt out of it using it by adding the following configuration setting to the <runtime> section of the application's configuration file:

<runtime>
<AppContextSwitchOverrides value="Switch.System.Security.Cryptography.AesCryptoServiceProvider.DontCorrectlyResetDecryptor=true"/>
</runtime>

此外,以舊版 .NET Framework 為目標,但是在從 .NET Framework 4.6.2 開始的 .NET Framework 版本下執行的應用程式,可以藉由將下列組態設定新增到應用程式設定檔的 <runtime> 區段,來選擇使用:In addition, applications that target a previous version of the .NET Framework but are running under a version of the .NET Framework starting with .NET Framework 4.6.2 can opt in to it by adding the following configuration setting to the <runtime> section of the application's configuration file:

<runtime>
<AppContextSwitchOverrides value="Switch.System.Security.Cryptography.AesCryptoServiceProvider.DontCorrectlyResetDecryptor=false"/>
</runtime>
名稱Name Value
影響範圍Scope MinorMinor
版本Version 4.6.24.6.2
類型Type 正在重定目標Retargeting

受影響的 APIAffected APIs

允許在 URI 中使用 Unicode 雙向控制字元Allow Unicode Bidirectional Control Characters in URIs

詳細資料Details

Unicode 會指定數個特殊控制字元,用來指定文字的方向。Unicode specifies several special control characters used to specify the orientation of text. 在舊版的 .NET Framework 中,這些字元會從所有 URI 中不正確地移除,即使它們存在於自己的百分比編碼中。In previous versions of the .NET Framework, these characters were incorrectly stripped from all URIs even if they were present in their percent-encoded form. 為進一步遵循 RFC 3987,我們現在允許在 URI 中使用這些字元。In order to better follow RFC 3987, we now allow these characters in URIs. 在 URI 找到未編碼的內容時,它們是百分比編碼的。When found unencoded in a URI, they are percent-encoded. 找到百分比編碼的內容時,它們會保持現況。When found percent-encoded they are left as-is.

建議Suggestion

以 .NET Framework 4.7.2 版開始為目標的應用程式,預設啟用對 Unicode 雙向字元的支援。For applications that target versions of .NET Framework starting with 4.7.2, support for Unicode bidirectional characters is enabled by default. 如果不需要這項變更,您可以在應用程式組態檔的 <runtime> 區段中新增下列 AppContextSwitchOverrides 參數來停用此變更:If this change is undesirable, you can disable it by adding the following AppContextSwitchOverrides switch to the <runtime> section of the application configuration file:

<runtime>
<AppContextSwitchOverrides value="Switch.System.Uri.DontKeepUnicodeBidiFormattingCharacters=true" />
</runtime>

對於以舊版 .NET Framework 為目標,但執行版本低於 .NET Framework 4.7.2 (含) 的應用程式,預設停用對 Unicode 雙向字元的支援。For applications that target earlier versions of the .NET Framework but are running under versions starting with .NET Framework 4.7.2, support for Unicode bidirectional characters is disabled by default. 您可以在應用程式組態檔的 <runtime> 區段中新增下列 AppContextSwitchOverrides 參數停用它:You can enable it by adding the following AppContextSwitchOverrides switch to the <runtime> section of the application configuration file::

<runtime>
<AppContextSwitchOverrides value="Switch.System.Uri.DontKeepUnicodeBidiFormattingCharacters=false" />
</runtime>
名稱Name Value
影響範圍Scope MinorMinor
版本Version 4.7.24.7.2
類型Type 正在重定目標Retargeting

受影響的 APIAffected APIs

呼叫 ClaimsIdentity 建構函式Calls to ClaimsIdentity constructors

詳細資料Details

從 .NET Framework 4.6.2 開始,具有 System.Security.Principal.IIdentity 參數的 ClaimsIdentity 建構函式如何設定 System.Security.Claims.ClaimsIdentity.Actor 屬性的方法有變更。Starting with the .NET Framework 4.6.2, there is a change in how ClaimsIdentity constructors with an System.Security.Principal.IIdentity parameter set the System.Security.Claims.ClaimsIdentity.Actor property. 如果 System.Security.Principal.IIdentity 引數是 ClaimsIdentity 物件,而且該 ClaimsIdentity 物件的 System.Security.Claims.ClaimsIdentity.Actor 屬性不是 null,則會使用 Clone() 方法來附加 System.Security.Claims.ClaimsIdentity.Actor 屬性。If the System.Security.Principal.IIdentity argument is a ClaimsIdentity object, and the System.Security.Claims.ClaimsIdentity.Actor property of that ClaimsIdentity object is not null, the System.Security.Claims.ClaimsIdentity.Actor property is attached by using the Clone() method. 在 Framework 4.6.1 和更早版本中,System.Security.Claims.ClaimsIdentity.Actor 屬性會附加作為現有的參考。由於此項變更,從 .NET Framework 4.6.2 開始,新 ClaimsIdentity 物件的 System.Security.Claims.ClaimsIdentity.Actor 屬性便不等於建構函式之 System.Security.Principal.IIdentity 引數的 System.Security.Claims.ClaimsIdentity.Actor 屬性。In the Framework 4.6.1 and earlier versions, the System.Security.Claims.ClaimsIdentity.Actor property is attached as an existing reference.Because of this change, starting with the .NET Framework 4.6.2, the System.Security.Claims.ClaimsIdentity.Actor property of the new ClaimsIdentity object is not equal to the System.Security.Claims.ClaimsIdentity.Actor property of the constructor's System.Security.Principal.IIdentity argument. 在 .NET Framework 4.6.1 和更早版本中,它是相等的。In the .NET Framework 4.6.1 and earlier versions, it is equal.

建議Suggestion

如果不想要這種行為,您可以將應用程式組態檔中的 Switch.System.Security.ClaimsIdentity.SetActorAsReferenceWhenCopyingClaimsIdentity 參數設為 true 來還原舊版行為。If this behavior is undesirable, you can restore the previous behavior by setting the Switch.System.Security.ClaimsIdentity.SetActorAsReferenceWhenCopyingClaimsIdentity switch in your application configuration file to true. 您會需要將下列內容新增至 web.config 檔案的 <runtime> 區段︰This requires that you add the following to the <runtime> section of your web.config file:

<configuration>
  <runtime>
    <AppContextSwitchOverrides value="Switch.System.Security.ClaimsIdentity.SetActorAsReferenceWhenCopyingClaimsIdentity=true" />
  </runtime>
</configuration>
名稱Name Value
影響範圍Scope EdgeEdge
版本Version 4.6.24.6.2
類型Type 正在重定目標Retargeting

受影響的 APIAffected APIs

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

路徑正規化的變更Changes in path normalization

詳細資料Details

從以 .NET Framework 4.6.2 為目標的應用程式開始,執行階段正規化路徑的方式已變更。正規化路徑涉及修改識別路徑或檔案的字串,使它符合目標作業系統上的有效路徑。Starting with apps that target the .NET Framework 4.6.2, the way in which the runtime normalizes paths has changed.Normalizing a path involves modifying the string that identifies a path or file so that it conforms to a valid path on the target operating system. 正規化通常牽涉到︰Normalization typically involves:

  • 規範化元件和目錄分隔符號。Canonicalizing component and directory separators.
  • 將目前的目錄套用到相對路徑。Applying the current directory to a relative path.
  • 評估路徑中的相對目錄 (.) 或上層目錄 (..)。Evaluating the relative directory (.) or the parent directory (..) in a path.
  • 修剪指定的字元。Trimming specified characters. 從以 .NET Framework 4.6.2 為目標的應用程式開始,預設會啟用路徑正規化的下列變更:Starting with apps that target the .NET Framework 4.6.2, the following changes in path normalization are enabled by default:
    • 執行階段會延後至作業系統的 GetFullPathName 函式再進行路徑正規化。The runtime defers to the operating system's GetFullPathName function to normalize paths.
  • 正規化不再涉及修剪目錄區段的結尾 (例如目錄名稱結尾的空格)。Normalization no longer involves trimming the end of directory segments (such as a space at the end of a directory name).
  • 支援完全信任的裝置路徑語法,包括 \\.\ 以及適用於 mscorlib.dll 中之檔案 I/O API 的 \\?\Support for device path syntax in full trust, including \\.\ and, for file I/O APIs in mscorlib.dll, \\?\.
  • 執行階段不會驗證裝置語法路徑。The runtime does not validate device syntax paths.
  • 支援使用裝置語法存取替代資料流。The use of device syntax to access alternate data streams is supported. 這些變更可改善效能,同時允許方法存取先前無法存取的路徑。These changes improve performance while allowing methods to access previously inaccessible paths. 此變更不會影響以 .NET Framework 4.6.1 和舊版為目標但執行於 .NET Framework 4.6.2 或更新版本下的應用程式。Apps that target the .NET Framework 4.6.1 and earlier versions but are running under the .NET Framework 4.6.2 or later are unaffected by this change.

建議Suggestion

以 .NET Framework 4.6.2 或更新版本為目標的應用程式可透過在應用程式設定檔的 <runtime> 區段中新增下列內容來選擇退出此變更,並使用舊版行為:Apps that target the .NET Framework 4.6.2 or later can opt out of this change and use legacy normalization by adding the following to the <runtime> section of the application configuration file:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.UseLegacyPathHandling=true" />
</runtime>

以 .NET Framework 4.6.1 或更早版本為目標,但在 .NET Framework 4.6.2 或更新版本上執行的應用程式,可以藉由在應用程式設定檔的 <runtime> 區段新增下行,就能啟用路徑正規化的變更:Apps that target the .NET Framework 4.6.1 or earlier but are running on the .NET Framework 4.6.2 or later can enable the changes to path normalization by adding the following line to the <runtime> section of the application .configuration file:

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

DeflateStream 使用原生 API 解壓縮DeflateStream uses native APIs for decompression

詳細資料Details

從 .NET Framework 4.7.2 開始,T:System.IO.Compression.DeflateStream 類別中的解壓縮實作已變更為預設使用原生 Windows API。Starting with the .NET Framework 4.7.2, the implementation of decompression in the T:System.IO.Compression.DeflateStream class has changed to use native Windows APIs by default. 一般而言,這會導致顯著的效能改善。Typically, this results in a substantial performance improvement. 所有以 .NET Framework 4.7.2 或更高版本為目標的 .NET 應用程式都會使用原生實作。這項變更可能會導致行為的某些差異,包括:All .NET applications targeting the .NET Framework version 4.7.2 or higher use the native implementation.This change might result in some differences in behavior, which include:

  • 例外狀況訊息可能會不同。Exception messages may be different. 不過,擲回的例外狀況類型維持不變。However, the type of exception thrown remains the same.
  • 某些特殊情況下,例如記憶體不足無法完成作業,可能會以不同的方式處理。Some special situations, such as not having enough memory to complete an operation, may be handled differently.
  • 剖析 gzip 標頭的已知差異 (注意:只有針對解壓縮設定的 GZipStream 會受到影響):There are known differences for parsing gzip header (note: only GZipStream set for decompression is affected):
  • 剖析無效標頭時的例外狀況,可能會在不同的時間擲回。Exceptions when parsing invalid headers may be thrown at different times.
  • 原生實作強制執行的 gzip 標頭內某些保留旗標值 (亦即 FLG),會根據規格設定,這可能會造成它擲回略過先前無效值的例外狀況。The native implementation enforces that values for some reserved flags inside the gzip header (i.e. FLG) are set according to the specification, which may cause it to throw an exception where previously invalid values were ignored.

建議Suggestion

如果使用原生 API 解壓縮對您的應用程式行為有不良影響,您可以在 app.config 檔案的 runtime 區段中新增 Switch.System.IO.Compression.DoNotUseNativeZipLibraryForDecompression 參數,並將它設定為 true,選擇不使用這項功能:If decompression with native APIs has adversely affected the behavior of your app, you can opt out of this feature by adding the Switch.System.IO.Compression.DoNotUseNativeZipLibraryForDecompression switch to the runtime section of your app.config file and setting it to true:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <runtime>
    <AppContextSwitchOverrides value="Switch.System.IO.Compression.DoNotUseNativeZipLibraryForDecompression=true" />
  </runtime>
</configuration>
名稱Name Value
影響範圍Scope MinorMinor
版本Version 4.7.24.7.2
類型Type 正在重定目標Retargeting

受影響的 APIAffected APIs

確定 System.Uri 使用一致的保留字集Ensure System.Uri uses a consistent reserved character set

詳細資料Details

System.Uri 中,某些有時已解碼的百分比編碼字元,現在一致保持編碼。In System.Uri, certain percent-encoded characters that were sometimes decoded are now consistently left encoded. 這發生在存取 URI 的路徑、查詢、片段或使用者資訊元件的屬性和方法之間。This occurs across the properties and methods that access the path, query, fragment, or userinfo components of the URI. 行為只有在下列兩項都符合時才會變更:The behavior will change only when both of the following are true:

  • URI 包含下列任一保留字元的編碼格式::'()!*The URI contains the encoded form of any of the following reserved characters: :, ', (, ), ! or *.
  • URI 包含 Unicode 或編碼的非保留字元。The URI contains a Unicode or encoded non-reserved character. 如果符合上述兩項,則編碼的保留字元會保持編碼。If both of the above are true, the encoded reserved characters are left encoded. 在舊版的 .NET Framework 中,它們是解碼的。In previous versions of the .NET Framework, they are decoded.

建議Suggestion

對於以 .NET Framework 4.7.2 版開始為目標的應用程式,預設會啟用新的解碼行為。For applications that target versions of .NET Framework starting with 4.7.2, the new decoding behavior is enabled by default. 如果不需要這項變更,您可以在應用程式組態檔的 <runtime> 區段中新增下列 AppContextSwitchOverrides 參數來停用此變更:If this change is undesirable, you can disable it by adding the following AppContextSwitchOverrides switch to the <runtime> section of the application configuration file:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.Uri.DontEnableStrictRFC3986ReservedCharacterSets=true" />
</runtime>

對於以舊版 .NET Framework 為目標,但執行版本低於 .NET Framework 4.7.2 (含) 的應用程式,預設會停用新的解碼行為。For applications that target earlier versions of the .NET Framework but are running under versions starting with .NET Framework 4.7.2, the new decoding behavior is disabled by default. 您可以藉由在AppContextSwitchOverrides <runtime> 應用程式佈建檔的區段中新增下列 AppCoNtextSwitchOverrides 參數來啟用它:You can enable it by adding the following AppContextSwitchOverrides switch to the <runtime> section of the application configuration file:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.Uri.DontEnableStrictRFC3986ReservedCharacterSets=false" />
</runtime>
名稱Name Value
影響範圍Scope MinorMinor
版本Version 4.7.24.7.2
類型Type 正在重定目標Retargeting

受影響的 APIAffected APIs

長路徑支援Long path support

詳細資料Details

從以 .NET Framework 4.6.2 為目標的應用程式開始,支援長路徑 (最多 32K 個字元),且已移除對於路徑長度的 260 個字元 (或 MAX_PATH) 限制。若為重新編譯以 .NET Framework 4.6.2 為目標的應用程式,先前因為路徑超過 260 個字元而擲回 System.IO.PathTooLongException 的程式碼路徑,現在將只有在下列情況下擲回 System.IO.PathTooLongExceptionStarting with apps that target the .NET Framework 4.6.2, long paths (of up to 32K characters) are supported, and the 260-character (or MAX_PATH) limitation on path lengths has been removed.For apps that are recompiled to target the .NET Framework 4.6.2, code paths that previously threw a System.IO.PathTooLongException because a path exceeded 260 characters will now throw a System.IO.PathTooLongException only under the following conditions:

  • 路徑的長度大於 MaxValue (32,767) 個字元。The length of the path is greater than MaxValue (32,767) characters.
  • 作業系統傳回 COR_E_PATHTOOLONG 或其對應項。The operating system returns COR_E_PATHTOOLONG or its equivalent. 若為以 .NET Framework 4.6.1 和更早版本為目標的應用程式,每當路徑超過 260 個字元時,執行階段就會自動擲回 System.IO.PathTooLongExceptionFor apps that target the .NET Framework 4.6.1 and earlier versions, the runtime automatically throws a System.IO.PathTooLongException whenever a path exceeds 260 characters.

建議Suggestion

若為以 .NET Framework 4.6.2 為目標的應用程式,如果不需要長路徑支援,您可以透過將下列內容新增至 app.config 檔案的 <runtime> 區段以選擇退出長路徑支援︰For apps that target the .NET Framework 4.6.2, you can opt out of long path support if it is not desirable by adding the following to the <runtime> section of your app.config file:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.BlockLongPaths=true" />
</runtime>

若為以舊版 .NET Framework 為目標但卻在 .NET Framework 4.6.2 或更新版本上執行的應用程式,則可將下列內容新增至 app.config 檔案的 <runtime> 區段,以選擇加入長路徑支援:For apps that target earlier versions of the .NET Framework but run on the .NET Framework 4.6.2 or later, you can opt in to long path support by adding the following to the <runtime> section of your app.config file:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.BlockLongPaths=false" />
</runtime>
名稱Name Value
影響範圍Scope MinorMinor
版本Version 4.6.24.6.2
類型Type 正在重定目標Retargeting

受控加密類別在 FIPS 模式中不會擲回 CryptographyExceptionManaged cryptography classes do not throw a CryptographyException in FIPS mode

詳細資料Details

在舊版 .NET Framework 4.7.2 及更早版本中,受控加密提供者類別 (例如 SHA256Managed) 會在系統密碼編譯程式庫以 FIPS 模式設定時擲回 CryptographicExceptionIn .NET Framework 4.7.2 and earlier versions, managed cryptographic provider classes such as SHA256Managed throw a CryptographicException when the system cryptographic libraries are configured in FIPS mode. 因為受控版本未經過 FIPS (聯邦資訊處理標準) 140-2 認證,並封鎖可能不受 FIPS 規則核准的加密演算法,因此會擲回這些例外狀況。These exceptions are thrown because the managed versions have not undergone FIPS (Federal Information Processing Standards) 140-2 certification, as well as to block cryptographic algorithms that were not considered to be approved based on the FIPS rules. 因為只有極少數開發人員以 FIP 模式使用開發電腦,因此這些例外狀況通常僅在生產系統上擲回。以 .NET Framework 4.8 及更新版本為目標的應用程式,會自動切換至較新且寬鬆的原則,以便不再於此情況下根據預設擲回 CryptographicExceptionBecause few developers have their development machines in FIPS mode, these exceptions are frequently thrown only on production systems.Applications that target .NET Framework 4.8 and later versions automatically switch to the newer, relaxed policy, so that a CryptographicException is no longer thrown by default in such cases. 相反地,這些受控加密類別會將加密作業重新導向到系統加密程式庫。Instead, the managed cryptography classes redirect cryptographic operations to a system cryptography library. 此原則變更有效地去除了開發人員環境與生產環境之間的潛在混淆,而且讓原生元件與受控元件在相同的密碼編譯原則下執行。This policy change effectively removes a potentially confusing difference between developer environments and the production environments and makes native components and managed components operate under the same cryptographic policy.

建議Suggestion

如果不需要此行為,您可以選擇退出並還原先前行為,以便藉由將下列 AppContextSwitchOverrides 組態設定新增至應用程式組態檔的 <runtime> 區段,在 FIPS 模式中擲回 CryptographicExceptionIf this behavior is undesirable, you can opt out of it and restore the previous behavior so that a CryptographicException is thrown in FIPS mode by adding the following AppContextSwitchOverrides configuration setting to the <runtime> section of your application configuration file:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.Security.Cryptography.UseLegacyFipsThrow=true" />
</runtime>

如果您的應用程式以 .NET Framework 4.7.2 或更早版本為目標,您也可以藉由將下列 AppContextSwitchOverrides 組態設定新增至應用程式組態檔的 <runtime> 區段,選擇使用這項變更:If your application targets .NET Framework 4.7.2 or earlier, you can also opt in to this change by adding the following AppContextSwitchOverrides configuration setting to the <runtime> section of your application configuration file:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.Security.Cryptography.UseLegacyFipsThrow=false" />
</runtime>
名稱Name Value
影響範圍Scope EdgeEdge
版本Version 4.84.8
類型Type 正在重定目標Retargeting

受影響的 APIAffected APIs

路徑冒號檢查更嚴格Path colon checks are stricter

詳細資料Details

在 .NET Framework 4.6.2 中,為了支援先前所不支援的路徑 (就長度和格式兩方面) 而有數項變更。In .NET Framework 4.6.2, a number of changes were made to support previously unsupported paths (both in length and format). 檢查是否有適當的磁片磁碟機分隔符號 (冒號) 語法是否更正確,它的副作用是在一些先前容許的特定路徑 Api 中封鎖某些 URI 路徑。Checks for proper drive separator (colon) syntax were made more correct, which had the side effect of blocking some URI paths in a few select Path APIs where they were previously tolerated.

建議Suggestion

如果傳遞 URI 給受影響的 API,請先將字串修改為合法的路徑。If passing a URI to affected APIs, modify the string to be a legal path first.

  • 以手動方式從 Url 移除配置 (例如, file:// 從 url 移除) 。Remove the scheme from URLs manually (for example, remove file:// from URLs).

  • 將 URI 傳遞給 Uri 類別,並使用 LocalPathPass the URI to the Uri class and use LocalPath.

或者,您可以藉由將 AppCoNtext 參數設定為,退出宣告新的路徑正規化 Switch.System.IO.UseLegacyPathHandling trueAlternatively, you can opt out of the new path normalization by setting the Switch.System.IO.UseLegacyPathHandling AppContext switch to true.

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

受影響的 APIAffected APIs

Resgen 拒絕從 web 載入內容Resgen refuses to load content from the web

詳細資料Details

.resx 檔案可能包含二進位格式的輸入。.resx files may contain binary formatted input. 如果您嘗試使用 resgen 來載入從不受信任位置下載的檔案,預設將無法載入輸入。If you attempt to use resgen to load a file that was downloaded from an untrusted location, it will fail to load the input by default.

建議Suggestion

需要從不受信任的位置載入二進位格式輸入的 Resgen 使用者,可以從輸入檔移除 web 標記,或套用退出怪癖。新增下列登錄設定,以套用全電腦的退出怪癖: [HKEY_LOCAL_MACHINE \software\microsoft.netframework\sdk] " AllowProcessOfUntrustedResourceFiles " = " true"Resgen users who require loading binary formatted input from untrusted locations can either remove the mark of the web from the input file or apply the opt-out quirk.Add the following registry setting to apply the machine wide opt-out quirk: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.NETFramework\SDK] "AllowProcessOfUntrustedResourceFiles"="true"

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

SerialPort 背景執行緒例外狀況SerialPort background thread exceptions

詳細資料Details

使用 SerialPort 資料流建立的背景執行緒與不會再於擲回 OS 的例外狀況時終止處理序。Background threads created with SerialPort streams no longer terminate the process when OS exceptions are thrown.
在以 .NET Framework 4.7 和舊版為目標的應用程式中,當使用 SerialPort 資料流建立的背景執行緒上擲回作業系統例外狀況時,處理程序會終止。In applications that target the .NET Framework 4.7 and earlier versions, a process is terminated when an operating system exception is thrown on a background thread created with a SerialPort stream.
在目標為 .NET Framework 4.7.1 或更新版本的應用程式中,背景執行緒會等候與作用中的序列連接埠相關且在某些情況下可能會損毀的 OS 事件,例如突然移除序列連接埠。In applications that target the .NET Framework 4.7.1 or a later version, background threads wait for OS events related to the active serial port and could crash in some cases, such as sudden removal of the serial port.

建議Suggestion

若為以 .NET Framework 4.7.1 為目標的應用程式,如果不需要例外狀況處理,您可以透過將下列內容新增至 app.config 檔案的 <runtime> 區段以選擇退出例外狀況處理︰For apps that target the .NET Framework 4.7.1, you can opt out of the exception handling if it is not desirable by adding the following to the <runtime> section of your app.config file:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.Ports.DoNotCatchSerialStreamThreadExceptions=true" />
</runtime>

若為以舊版 .NET Framework 為目標但卻在 .NET Framework 4.7.1 或更新版本上執行的應用程式,則可將下列內容新增至 app.config 檔案的 <runtime> 區段,以選擇加入例外狀況處理:For apps that target earlier versions of the .NET Framework but run on the .NET Framework 4.7.1 or later, you can opt in to the exception handling by adding the following to the <runtime> section of your app.config file:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.Ports.DoNotCatchSerialStreamThreadExceptions=false" />
</runtime>
名稱Name Value
影響範圍Scope MinorMinor
版本Version 4.7.14.7.1
類型Type 正在重定目標Retargeting

受影響的 APIAffected APIs

ServiceBase 不會傳播 OnStart 例外狀況ServiceBase doesn't propagate OnStart exceptions

詳細資料Details

在 .NET Framework 4.7 和更早版本中,在服務啟動時擲回的例外狀況不會傳播至 ServiceBase.Run 的呼叫端。In the .NET Framework 4.7 and earlier versions, exceptions thrown on service startup are not propagated to the caller of ServiceBase.Run.
從 .NET Framework 4.7.1 為目標的應用程式開始,執行階段會為無法啟動的服務將例外狀況傳播到 ServiceBase.RunStarting with applications that target the .NET Framework 4.7.1, the runtime propagates exceptions to ServiceBase.Run for services that fail to start.

建議Suggestion

在服務啟動時,如果有例外狀況,將會傳播該例外狀況。On service start, if there is an exception, that exception will be propagated. 這應該有利於診斷服務無法啟動的情況。This should help diagnose cases where services fail to start.
如果不需要此行為,您可以在應用程式組態檔的 <runtime> 區段中新增以下 <AppContextSwitchOverrides> 元素,以選擇退出:If this behavior is undesirable, you can opt out of it by adding the following <AppContextSwitchOverrides> element to the <runtime> section of your application configuration file:

<AppContextSwitchOverrides value="Switch.System.ServiceProcess.DontThrowExceptionsOnStart=true" />

如果您的應用程式以比 4.7.1 舊的版本為目標,但您想要有這種行為,請在應用程式設定檔的 <runtime> 區段中新增以下 <AppContextSwitchOverrides> 元素:If your application targets an earlier version than 4.7.1 but you want to have this behavior, add the following <AppContextSwitchOverrides> element to the <runtime> section of your application configuration file:

<AppContextSwitchOverrides value="Switch.System.ServiceProcess.DontThrowExceptionsOnStart=false" />
名稱Name Value
影響範圍Scope MinorMinor
版本Version 4.7.14.7.1
類型Type 正在重定目標Retargeting

受影響的 APIAffected APIs

使用可攜式 PDB 時取得的堆疊追蹤,現已包含來源檔案與程式碼資訊 (若要求)Stack traces obtained when using portable PDBs now include source file and line information if requested

詳細資料Details

從 .NET Framework 4.7.2 開始,如果要求,使用可攜式 PDB 時取得的堆疊追蹤會包含來源檔案與程式碼資訊。Starting with .NET Framework 4.7.2, stack traces obtained when using portable PDBs include source file and line information when requested. 在 .NET Framework 4.7.2 之前的版本中,即使明確要求,使用可攜式 PDB 時也無法取得來源檔案和程式碼資訊。In versions prior to .NET Framework 4.7.2, source file and line information would be unavailable when using portable PDBs even if explicitly requested.

建議Suggestion

若為以 .NET Framework 4.7.2 為目標的應用程式,如果不需要,您可以透過將下列內容新增至 app.config 檔案的 <runtime> 區段,選擇使用可攜式 PDB 時不包含來源檔案和程式碼資訊︰For applications that target the .NET Framework 4.7.2, you can opt out of the source file and line information when using portable PDBs if it is not desirable by adding the following to the <runtime> section of your app.config file:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.Diagnostics.IgnorePortablePDBsInStackTraces=true" />
</runtime>

若為以舊版 .NET Framework 為目標但卻在 .NET Framework 4.7.2 或更新版本上執行的應用程式,則可將下列內容新增至 app.config 檔案的 <runtime> 區段,選擇使用可攜式 PDB 時包含來源檔案和程式碼資訊︰For applications that target earlier versions of the .NET Framework but run on the .NET Framework 4.7.2 or later, you can opt in to the source file and line information when using portable PDBs by adding the following to the <runtime> section of your app.config file:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.Diagnostics.IgnorePortablePDBsInStackTraces=false" />
</runtime>
名稱Name Value
影響範圍Scope EdgeEdge
版本Version 4.7.24.7.2
類型Type 正在重定目標Retargeting

受影響的 APIAffected APIs

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

ServicePointManager.SecurityProtocol 的預設值是 SecurityProtocolType.System.DefaultDefault value of ServicePointManager.SecurityProtocol is SecurityProtocolType.System.Default

詳細資料Details

從以 .NET Framework 4.7 為目標的應用程式開始,ServicePointManager.SecurityProtocol 屬性是 SecurityProtocolType.SystemDefaultStarting with apps that target the .NET Framework 4.7, the default value of the ServicePointManager.SecurityProtocol property is SecurityProtocolType.SystemDefault. 這項變更可以讓以 SslStream 為基礎的 .NET Framework 網路 API (例如 FTP、HTTPS 及 SMTP) 繼承作業系統的預設安全性通訊協定,而不要使用由 .NET Framework 定義的硬式編碼值。This change allows .NET Framework networking APIs based on SslStream (such as FTP, HTTPS, and SMTP) to inherit the default security protocols from the operating system instead of using hard-coded values defined by the .NET Framework. 預設值會依作業系統和系統管理員執行的任何自訂設定而異。The default varies by operating system and any custom configuration performed by the system administrator. 如需每個 Windows 作業系統版本中預設 SChannel 通訊協定的資訊,請參閱 Protocols in TLS/SSL (Schannel SSP) (TLS/SSL 中的通訊協定 (Schannel SSP))。For information on the default SChannel protocol in each version of the Windows operating system, see Protocols in TLS/SSL (Schannel SSP).

目標是舊版 .NET Framework 的應用程式,ServicePointManager.SecurityProtocol 屬性的預設值視目標的 .NET framework 版本而定。For applications that target an earlier version of the .NET Framework, the default value of the ServicePointManager.SecurityProtocol property depends on the version of the .NET Framework targeted. 如需詳細資訊,請參閱從 .NET Framework 4.5.2 移轉到 4.6 的重定目標變更的網路區段See the Networking section of Retargeting Changes for Migration from .NET Framework 4.5.2 to 4.6 for more information.

建議Suggestion

這項變更會影響目標為 .NET Framework 4.7 或更新版本的應用程式。This change affects applications that target the .NET Framework 4.7 or later versions. 如果您偏好使用定義的通訊協定,而不是依賴系統預設,您可以明確設定 ServicePointManager.SecurityProtocol 屬性的值。If you prefer to use a defined protocol rather than relying on the system default, you can explicitly set the value of the ServicePointManager.SecurityProtocol property. 如果不需要這項變更,您可以將設定設定新增至 <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.Net.DontEnableSystemDefaultTlsVersions 選擇退出參數:The following example shows both the <runtime> section and the Switch.System.Net.DontEnableSystemDefaultTlsVersions opt-out switch:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.Net.DontEnableSystemDefaultTlsVersions=true" />
</runtime>
名稱Name Value
範圍Scope MinorMinor
版本Version 4.74.7
類型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

SslStream 支援 TLS 警示SslStream supports TLS Alerts

詳細資料Details

失敗的 TLS 信號交換之後,第一個 I/O 讀取/寫入作業將會擲回 System.IO.IOException 與內部 System.ComponentModel.Win32Exception 例外狀況。After a failed TLS handshake, an System.IO.IOException with an inner System.ComponentModel.Win32Exception exception will be thrown by the first I/O Read/Write operation. System.ComponentModel.Win32Exception.NativeErrorCode System.ComponentModel.Win32Exception 可以使用 tls 和 SSL 警示的安全通道錯誤碼,將的程式碼對應至遠端方的 tls 警示。如需詳細資訊,請參閱 RFC 2246:區段7.2.2 錯誤警示The System.ComponentModel.Win32Exception.NativeErrorCode code for the System.ComponentModel.Win32Exception can be mapped to the TLS Alert from the remote party using the Schannel error codes for TLS and SSL alerts.For more information, see RFC 2246: Section 7.2.2 Error alerts.
.NET Framework 4.6.2 和更早版本的行為是如果另一方交握失敗,傳輸通道 (通常是 TCP 連線) 會在寫入或讀取期間逾時,並在之後立即拒絕連線。The behavior in .NET Framework 4.6.2 and earlier is that the transport channel (usually TCP connection) will timeout during either Write or Read if the other party failed the handshake and immediately afterwards rejected the connection.

建議Suggestion

呼叫網路 I/O API (例如 Read(Byte[], Int32, Int32)/Write(Byte[], Int32, Int32)) 的應用程式,應該處理 IOExceptionSystem.TimeoutExceptionApplications calling network I/O APIs such as Read(Byte[], Int32, Int32)/Write(Byte[], Int32, Int32) should handle IOException or System.TimeoutException.
從 .NET Framework 4.7 開始,預設會啟用 TLS 警示功能。The TLS Alerts feature is enabled by default starting with .NET Framework 4.7. 以 .NET Framework 4.0 到 4.6.2 版為目標且在 .NET Framework 4.7 或更高版本的系統上執行的應用程式,會停用此功能以保留相容性。Applications targeting versions of the .NET Framework from 4.0 through 4.6.2 running on a .NET Framework 4.7 or higher system will have the feature disabled to preserve compatibility.
若為在 .NET Framework 4.7 或更新版本上執行之 .NET Framework 4.6 和更新版本的應用程式,您可以使用下列組態 API 來啟用或停用此功能。The following configuration API is available to enable or disable the feature for .NET Framework 4.6 and later applications running on .NET Framework 4.7 or later.

  • 以程式設計方式:必須是應用程式執行的第一件事,因為 ServicePointManager 只會初始化一次:Programmatically: Must be the very first thing the application does since ServicePointManager will initialize only once:

    AppContext.SetSwitch("TestSwitch.LocalAppContext.DisableCaching", true);
    
    // Set to 'false' to enable the feature in .NET Framework 4.6 - 4.6.2.
    AppContext.SetSwitch("Switch.System.Net.DontEnableTlsAlerts", true);
    
  • AppConfig:AppConfig:

    <runtime>
      <AppContextSwitchOverrides value="Switch.System.Net.DontEnableTlsAlerts=true"/>
      <!-- Set to 'false' to enable the feature in .NET Framework 4.6 - 4.6.2. -->
    </runtime>
    
  • 登錄機碼 (電腦全域) :將值設定為,以 false 啟用 .NET Framework 4.6-4.6.2 中的功能。Registry key (machine global): Set the Value to false to enable the feature in .NET Framework 4.6 - 4.6.2.

    Key: HKLM\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\AppContext\Switch.System.Net.DontEnableTlsAlerts
    - Type: String
    - Value: "true"
    
名稱Name Value
範圍Scope EdgeEdge
版本Version 4.74.7
類型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

安全性Security

CspParameters.ParentWindowHandle 現在預期有 HWND 值CspParameters.ParentWindowHandle now expects HWND value

詳細資料Details

.NET Framework 2.0 中引進的 ParentWindowHandle 值,可讓應用程式註冊父視窗控制代碼值,因而存取金鑰所需的任何 UI (如 PIN 提示或同意對話方塊) 在指定的視窗會開啟為強制回應子項。從以 .NET Framework 4.7 為目標的應用程式開始,Windows Forms 應用程式可以使用如下的程式碼設定 ParentWindowHandle 屬性:The ParentWindowHandle value, introduced in .NET Framework 2.0, allows an application to register a parent window handle value such that any UI required to access the key (such as a PIN prompt or consent dialog) opens as a modal child to the specified window.Starting with apps that target the .NET Framework 4.7, a Windows Forms application can set the ParentWindowHandle property with code like the following:

cspParameters.ParentWindowHandle = form.Handle;

在舊版 .NET Framework 中,值必須為 System.IntPtr,代表存放 HWND 值之記憶體中的位置。In previous versions of the .NET Framework, the value was expected to be an System.IntPtr representing a location in memory where the HWND value resided. 在 Windows 7 和舊版中,將屬性設為 form.Handle 不會有任何作用,但在 Windows 8 和更新的版本中,則會導致 "System.Security.Cryptography.CryptographicException:參數不正確。"Setting the property to form.Handle on Windows 7 and earlier versions had no effect, but on Windows 8 and later versions, it results in a "System.Security.Cryptography.CryptographicException: The parameter is incorrect."

建議Suggestion

以 .NET Framework 4.7 或更新版本為目標的應用程式若要註冊父視窗關聯性,建議使用以下的簡化格式︰Applications targeting .NET Framework 4.7 or higher wishing to register a parent window relationship are encouraged to use the simplified form:

cspParameters.ParentWindowHandle = form.Handle;

使用者如已發現要傳遞的正確值,是 form.Handle 值所在之記憶體位置的位址,則可以藉由將 AppContext 參數 Switch.System.Security.Cryptography.DoNotAddrOfCspParentWindowHandle 設為 true 以選擇退出行為變更:Users who had identified that the correct value to pass was the address of a memory location which held the value form.Handle can opt out of the behavior change by setting the AppContext switch Switch.System.Security.Cryptography.DoNotAddrOfCspParentWindowHandle to true:

  • 以程式設計方式設定 AppContext 的相容性參數,如這裡所述。By programmatically setting compat switches on the AppContext, as explained here.
  • 將下列程式行加入至 app.config 檔案的 <runtime> 區段:By adding the following line to the <runtime> section of the app.config file:
<runtime>
 <AppContextSwitchOverrides value="Switch.System.Security.Cryptography.DoNotAddrOfCspParentWindowHandle=true"/>
</runtime>

相反地,若使用者想在應用程式在舊版 .NET Framework 下載入時,選擇加入 .NET Framework 4.7 執行階段上的新行為,可以將 AppContext 參數設為 falseConversely, users who wish to opt in to the new behavior on the .NET Framework 4.7 runtime when the application loads under older .NET Framework versions can set the AppContext switch to false.

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

受影響的 APIAffected APIs

預設 SignedXML 和 SignedXMS 演算法變更為 SHA256Default SignedXML and SignedXMS algorithms changed to SHA256

詳細資料Details

在 .NET Framework 4.7 和更早版本中,某些作業的 SignedXML 和 SignedCMS 預設為 SHA1。從 .NET Framework 4.7.1 開始,針對這些作業預設會啟用 SHA256。In the .NET Framework 4.7 and earlier, SignedXML and SignedCMS default to SHA1 for some operations.Starting with the .NET Framework 4.7.1, SHA256 is enabled by default for these operations. 這項變更是必要的,因為 SHA1 不再被視為是安全的方法。This change is necessary because SHA1 is no longer considered to be secure.

建議Suggestion

有兩個新內容參數值可以控制預設使用 SHA1 (不安全) 還是 SHA256:There are two new context switch values to control whether SHA1 (insecure) or SHA256 is used by default:

  • Switch.System.Security.Cryptography.Xml.UseInsecureHashAlgorithmsSwitch.System.Security.Cryptography.Xml.UseInsecureHashAlgorithms
  • Switch.System。UseInsecureHashAlgorithms 適用于以 .NET Framework 4.7.1 和更新版本為目標的應用程式,如果不想使用 SHA256,您可以將下列設定參數新增至您應用程式佈建檔的runtime區段,將預設值還原為 SHA1:Switch.System.Security.Cryptography.Pkcs.UseInsecureHashAlgorithms For applications that target the .NET Framework 4.7.1 and later versions, if the use of SHA256 is undesirable, you can restore the default to SHA1 by adding the following configuration switch to the runtime section of your app config file:
<AppContextSwitchOverrides value="Switch.System.Security.Cryptography.Xml.UseInsecureHashAlgorithms=true;Switch.System.Security.Cryptography.Pkcs.UseInsecureHashAlgorithms=true" />

若為以 .NET Framework 4.7.1 和更早版本為目標的應用程式,您可以新增下列設定參數到應用程式設定檔的 runtime 區段,選擇加入此變更:For applications that target the .NET Framework 4.7 and earlier versions, you can opt into this change by adding the following configuration switch to the runtime section of your app config file:

<AppContextSwitchOverrides value="Switch.System.Security.Cryptography.Xml.UseInsecureHashAlgorithms=false;Switch.System.Security.Cryptography.Pkcs.UseInsecureHashAlgorithms=false" />
名稱Name Value
影響範圍Scope MinorMinor
版本Version 4.7.14.7.1
類型Type 正在重定目標Retargeting

受影響的 APIAffected APIs

RSACng 現在會正確地載入非標準金鑰大小的 RSA 金鑰RSACng now correctly loads RSA keys of non-standard key size

詳細資料Details

在 .NET Framework 4.6.2 之前,使用非標準的 RSA 憑證金鑰大小客戶,無法透過 System.Security.Cryptography.X509Certificates.RSACertificateExtensions.GetRSAPublicKey(X509Certificate2)System.Security.Cryptography.X509Certificates.RSACertificateExtensions.GetRSAPrivateKey(X509Certificate2) 擴充方法存取這些金鑰。In .NET Framework versions prior to 4.6.2, customers with non-standard key sizes for RSA certificates are unable to access those keys via the System.Security.Cryptography.X509Certificates.RSACertificateExtensions.GetRSAPublicKey(X509Certificate2) and System.Security.Cryptography.X509Certificates.RSACertificateExtensions.GetRSAPrivateKey(X509Certificate2) extension methods. 會擲回 System.Security.Cryptography.CryptographicException 以及「不支援要求的金鑰大小」訊息。A System.Security.Cryptography.CryptographicException with the message "The requested key size is not supported" is thrown. 在 .NET Framework 4.6.2 中,已修正此問題。In .NET Framework 4.6.2 this issue has been fixed. 同樣地,ImportParameters(RSAParameters)ImportParameters(RSAParameters) 現在可以使用非標準的金鑰大小,而不會擲回 System.Security.Cryptography.CryptographicExceptionSimilarly, ImportParameters(RSAParameters) and ImportParameters(RSAParameters) now work with non-standard key sizes without throwing a System.Security.Cryptography.CryptographicException.

建議Suggestion

如果有任何例外狀況處理邏輯會依賴先前的行為,也就是使用非標準的金鑰大小時會擲回 System.Security.Cryptography.CryptographicException,請考慮移除該邏輯。If there is any exception handling logic that relies on the previous behavior where a System.Security.Cryptography.CryptographicException is thrown when non-standard key sizes are used, consider removing the logic.

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

受影響的 APIAffected APIs

SslStream 支援 TLS 警示SslStream supports TLS Alerts

詳細資料Details

失敗的 TLS 信號交換之後,第一個 I/O 讀取/寫入作業將會擲回 System.IO.IOException 與內部 System.ComponentModel.Win32Exception 例外狀況。After a failed TLS handshake, an System.IO.IOException with an inner System.ComponentModel.Win32Exception exception will be thrown by the first I/O Read/Write operation. System.ComponentModel.Win32Exception.NativeErrorCode System.ComponentModel.Win32Exception 可以使用 tls 和 SSL 警示的安全通道錯誤碼,將的程式碼對應至遠端方的 tls 警示。如需詳細資訊,請參閱 RFC 2246:區段7.2.2 錯誤警示The System.ComponentModel.Win32Exception.NativeErrorCode code for the System.ComponentModel.Win32Exception can be mapped to the TLS Alert from the remote party using the Schannel error codes for TLS and SSL alerts.For more information, see RFC 2246: Section 7.2.2 Error alerts.
.NET Framework 4.6.2 和更早版本的行為是如果另一方交握失敗,傳輸通道 (通常是 TCP 連線) 會在寫入或讀取期間逾時,並在之後立即拒絕連線。The behavior in .NET Framework 4.6.2 and earlier is that the transport channel (usually TCP connection) will timeout during either Write or Read if the other party failed the handshake and immediately afterwards rejected the connection.

建議Suggestion

呼叫網路 I/O API (例如 Read(Byte[], Int32, Int32)/Write(Byte[], Int32, Int32)) 的應用程式,應該處理 IOExceptionSystem.TimeoutExceptionApplications calling network I/O APIs such as Read(Byte[], Int32, Int32)/Write(Byte[], Int32, Int32) should handle IOException or System.TimeoutException.
從 .NET Framework 4.7 開始,預設會啟用 TLS 警示功能。The TLS Alerts feature is enabled by default starting with .NET Framework 4.7. 以 .NET Framework 4.0 到 4.6.2 版為目標且在 .NET Framework 4.7 或更高版本的系統上執行的應用程式,會停用此功能以保留相容性。Applications targeting versions of the .NET Framework from 4.0 through 4.6.2 running on a .NET Framework 4.7 or higher system will have the feature disabled to preserve compatibility.
若為在 .NET Framework 4.7 或更新版本上執行之 .NET Framework 4.6 和更新版本的應用程式,您可以使用下列組態 API 來啟用或停用此功能。The following configuration API is available to enable or disable the feature for .NET Framework 4.6 and later applications running on .NET Framework 4.7 or later.

  • 以程式設計方式:必須是應用程式執行的第一件事,因為 ServicePointManager 只會初始化一次:Programmatically: Must be the very first thing the application does since ServicePointManager will initialize only once:

    AppContext.SetSwitch("TestSwitch.LocalAppContext.DisableCaching", true);
    
    // Set to 'false' to enable the feature in .NET Framework 4.6 - 4.6.2.
    AppContext.SetSwitch("Switch.System.Net.DontEnableTlsAlerts", true);
    
  • AppConfig:AppConfig:

    <runtime>
      <AppContextSwitchOverrides value="Switch.System.Net.DontEnableTlsAlerts=true"/>
      <!-- Set to 'false' to enable the feature in .NET Framework 4.6 - 4.6.2. -->
    </runtime>
    
  • 登錄機碼 (電腦全域) :將值設定為,以 false 啟用 .NET Framework 4.6-4.6.2 中的功能。Registry key (machine global): Set the Value to false to enable the feature in .NET Framework 4.6 - 4.6.2.

    Key: HKLM\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\AppContext\Switch.System.Net.DontEnableTlsAlerts
    - Type: String
    - Value: "true"
    
名稱Name Value
範圍Scope EdgeEdge
版本Version 4.74.7
類型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

使用可重新進入服務時,可能會造成死結Deadlock may result when using Reentrant services

詳細資料Details

可重新進入服務可能會造成死結,將服務的執行個體限制為一次執行一個執行緒。A deadlock may result in a Reentrant service, which restricts instances of the service to one thread of execution at a time. 容易發生此問題的服務在其程式碼中會有下列 ServiceBehaviorAttributeServices prone to encounter this problem will have the following ServiceBehaviorAttribute in their code:

[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Reentrant)]

建議Suggestion

若要解決此問題,您可執行以下動作:To address this issue, you can do the following:

[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Reentrant)]
  • 安裝 .NET Framework 4.6.2 的最新更新,或升級至更新版本的 .NET Framework。Install the latest update to the .NET Framework 4.6.2, or upgrade to a later version of the .NET Framework. 這會停用 OperationContext.Current 中的 ExecutionContext 流程。This disables the flow of the ExecutionContext in OperationContext.Current. 這是可設定的行為;相當於在您的組態檔中新增下列應用程式設定:This behavior is configurable; it is equivalent to adding the following app setting to your configuration file:
<appSettings>
  <add key="Switch.System.ServiceModel.DisableOperationContextAsyncFlow" value="true" />
</appSettings>

Reentrant 服務的值 Switch.System.ServiceModel.DisableOperationContextAsyncFlow 絕對不可設定為 falseThe value of Switch.System.ServiceModel.DisableOperationContextAsyncFlow should never be set to false for Reentrant services.

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

受影響的 APIAffected APIs

某些 .NET SDK 工具之改善的協助工具Improved accessibility for some .NET SDK tools

詳細資料Details

在 .NET Framework SDK 4.7.1 中,SvcConfigEditor.exe 和 SvcTraceViewer.exe 工具已透過修正不同的協助工具問題而得到改善。In the .NET Framework SDK 4.7.1, the SvcConfigEditor.exe and SvcTraceViewer.exe tools have been improved by fixing varied accessibility issues. 其中大部分是小問題,例如未定義名稱,或未正確實作某些 UI 自動化模式。Most of these were small issues like a name not being defined or certain UI automation patterns not being implemented correctly. 雖然許多使用者不會察覺到這些不正確的值,但使用螢幕讀取器等輔助技術的客戶會發現這些 SDK 工具更容易存取。While many users wouldn't be aware of these incorrect values, customers who use assistive technologies like screen readers will find these SDK tools more accessible. 當然,這些修正程式會變更一些先前的行為,例如鍵盤焦點順序。為了取得這些工具的所有協助工具修正程式,您可以將下列程式碼新增至 app.config 檔案:Certainly, these fixes change some previous behaviors, like keyboard focus order.In order to get all the accessibility fixes in these tools, you can the following to your app.config file:

<runtime>
  <AppContextSwitchOverrides value="Switch.UseLegacyAccessibilityFeatures=false"/>
</runtime>
名稱Name Value
影響範圍Scope EdgeEdge
版本Version 4.7.14.7.1
類型Type 正在重定目標Retargeting

OperationContext.Current 在 using 子句中進行呼叫時,可能會傳回 NullOperationContext.Current may return null when called in a using clause

詳細資料Details

如果符合下列所有條件,則 OperationContext.Current 可能會傳回 null,而且可能會導致 NullReferenceExceptionOperationContext.Current may return null and a NullReferenceException may result if all of the following conditions are true:

using (new OperationContextScope(OperationContext.Current))
{
    // OperationContext.Current is null.
    OperationContext context = OperationContext.Current;

    // ...
}

建議Suggestion

若要解決此問題,您可執行以下動作:To address this issue, you can do the following:

  • 如下所示修改您的程式碼,以具現化新的非 null Current 物件:Modify your code as follows to instantiate a new non- null Current object:

    OperationContext ocx = OperationContext.Current;
    using (new OperationContextScope(OperationContext.Current))
    {
        OperationContext.Current = new OperationContext(ocx.Channel);
    
        // ...
    }
    
  • 安裝 .NET Framework 4.6.2 的最新更新,或升級至更新版本的 .NET Framework。Install the latest update to the .NET Framework 4.6.2, or upgrade to a later version of the .NET Framework. 這會停用 OperationContext.Current 中的 ExecutionContext 流程,並還原 WCF 應用程式在 .NET Framework 4.6.1 和舊版中的行為。This disables the flow of the ExecutionContext in OperationContext.Current and restores the behavior of WCF applications in the .NET Framework 4.6.1 and earlier versions. 這是可設定的行為;相當於在您的組態檔中新增下列應用程式設定:This behavior is configurable; it is equivalent to adding the following app setting to your configuration file:

    <appSettings>
      <add key="Switch.System.ServiceModel.DisableOperationContextAsyncFlow" value="true" />
    </appSettings>
    

    如果這項變更並不適當,且您的應用程式相依於作業內容之間流動的執行內容,您可以啟用其流程,如下所示:If this change is undesirable and your application depends on execution context flowing between operation contexts, you can enable its flow as follows:

    <appSettings>
      <add key="Switch.System.ServiceModel.DisableOperationContextAsyncFlow" value="false" />
    </appSettings>
    
名稱Name Value
影響範圍Scope EdgeEdge
版本Version 4.6.24.6.2
類型Type 正在重定目標Retargeting

受影響的 APIAffected APIs

DataContractJsonSerializer 的控制字元序列化現在與 ECMAScript V6 和 V8 相容Serialization of control characters with DataContractJsonSerializer is now compatible with ECMAScript V6 and V8

詳細資料Details

在 .NET Framework 4.6.2 和舊版中,並未 System.Runtime.Serialization.Json.DataContractJsonSerializer 以與 ECMAScript V6 和 V8 標準相容的方式序列化某些特殊控制字元,例如 \b、\f 和 \t。In .NET Framework 4.6.2 and earlier versions, the System.Runtime.Serialization.Json.DataContractJsonSerializer did not serialize some special control characters, such as \b, \f, and \t, in a way that was compatible with the ECMAScript V6 and V8 standards. 從 .NET Framework 4.7 開始,這些控制字元的序列化會與 ECMAScript V6 和 V8 相容。Starting with .NET Framework 4.7, serialization of these control characters is compatible with ECMAScript V6 and V8.

建議Suggestion

若為以 .NET Framework 4.7 為目標的應用程式,會預設啟用此功能。For apps that target the .NET Framework 4.7, this feature is enabled by default. 如果不需要此行為,您可將下列程式行加入至 app.config 或 web.config 檔案的 <runtime> 區段,以選擇退出此功能:If this behavior is not desirable, you can opt out of this feature by adding the following line to the <runtime> section of the app.config or web.config file:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.Runtime.Serialization.DoNotUseECMAScriptV6EscapeControlCharacter=false" />
</runtime>
名稱Name Value
影響範圍Scope EdgeEdge
版本Version 4.74.7
類型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

WCF 訊息安全性現在能夠使用 TLS1.1 和 TLS1.2WCF message security now is able to use TLS1.1 and TLS1.2

詳細資料Details

從 .NET Framework 4.7 開始,除了 SSL3.0 和 TLS1.0 之外,客戶還可以透過應用程式組態設定,在 WCF 訊息安全性設定 TLS1.1 或 TLS1.2。Starting in the .NET Framework 4.7, customers can configure either TLS1.1 or TLS1.2 in WCF message security in addition to SSL3.0 and TLS1.0 through application configuration settings.

建議Suggestion

在 .NET Framework 4.7 中,預設會停用 WCF 訊息安全性中的 TLS1.1 和 TLS1.2 支援。In the .NET Framework 4.7, support for TLS1.1 and TLS1.2 in WCF message security is disabled by default. 您可以將下行新增到 app.config 或 web.config 檔案的 <runtime> 區段來啟用它:You can enable it by adding the following line to the <runtime> section of the app.config or web.config file:

<runtime>
<AppContextSwitchOverrides value="Switch.System.ServiceModel.DisableUsingServicePointManagerSecurityProtocols=false;Switch.System.Net.DontEnableSchUseStrongCrypto=false" />
</runtime>
名稱Name Value
影響範圍Scope EdgeEdge
版本Version 4.74.7
類型Type 正在重定目標Retargeting

WCF 傳輸安全性支援使用 CNG 儲存的憑證WCF transport security supports certificates stored using CNG

詳細資料Details

從以 .NET Framework 4.6.2 為目標的應用程式開始,WCF 傳輸安全性支援使用 Windows 密碼編譯程式庫 (CNG) 儲存的憑證。Starting with apps that target the .NET Framework 4.6.2, WCF transport security supports certificates stored using the Windows Cryptography Library (CNG). 這項支援僅限於具有公開金鑰的憑證,且指數長度不能超過 32 位元。This support is limited to certificates with a public key that has an exponent no more than 32 bits in length. 當應用程式以 .NET Framework 4.6.2 為目標時,此功能預設為開啟。在舊版 .NET Framework 中,嘗試搭配 CSG 金鑰儲存提供者使用 X509 憑證會擲回例外狀況。When an application targets the .NET Framework 4.6.2, this feature is on by default.In earlier versions of the .NET Framework, the attempt to use X509 certificates with a CSG key storage provider throws an exception.

建議Suggestion

應用程式是以 .NET Framework 4.6.1 和更早版本為目標,但卻執行於 .NET Framework 4.6.2 當中,則可將下列這一行新增至 app.config 或 web.config 檔的 <runtime> 區段,來啟用支援 CNG 憑證:Apps that target the .NET Framework 4.6.1 and earlier but are running on the .NET Framework 4.6.2 can enable support for CNG certificates by adding the following line to the <runtime> section of the app.config or web.config file:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.ServiceModel.DisableCngCertificates=false" />
</runtime>

這也可以用程式設計方式,以下列程式碼完成︰This can also be done programmatically with the following code:

private const string DisableCngCertificates = @"Switch.System.ServiceModel.DisableCngCertificate";

AppContext.SetSwitch(disableCngCertificates, false);
Const DisableCngCertificates As String = "Switch.System.ServiceModel.DisableCngCertificates"
AppContext.SetSwitch(disableCngCertificates, False)

請注意,由於這項變更,將不再執行任何倚賴使用 CNG 憑證嘗試起始安全通訊失敗的任何例外住況處理程式碼。Note that, because of this change, any exception handling code that depends on the attempt to initiate secure communication with a CNG certificate to fail will no longer execute.

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

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

已改進 .NET 4.7.2 之 Windows Forms 控制項的協助工具Accessibility improvements in Windows Forms controls for .NET 4.7.2

詳細資料Details

Windows Forms Framework 利用了協助工具技術改善其運作方式,可為 Windows Forms 客戶提供更良好的支援。Windows Forms Framework is improving how it works with accessibility technologies to better support Windows Forms customers. 這些包括下列變更:These include the following changes:

  • 改善高對比模式期間之顯示方式的變更。Changes to improve display during High Contrast mode.
  • 在 DataGridView 與 MenuStrip 控制項中進行了改進鍵盤瀏覽的變更。Changes to improve the keyboard navigation in the DataGridView and MenuStrip controls.
  • 對朗讀程式的互動進行了變更。Changes to interaction with Narrator.

建議Suggestion

如何加入宣告或退出這些變更 為了讓應用程式受益于這些變更,它必須在 .NET Framework 4.7.2 或更新版本上執行。How to opt in or out of these changes In order for the application to benefit from these changes, it must run on the .NET Framework 4.7.2 or later. 應用程式可以用下列任一種方式受益於這些變更:The application can benefit from these changes in either of the following ways:

  • 將其重新編譯為以 .NET Framework 4.7.2 為目標。It is recompiled to target the .NET Framework 4.7.2. 在以 .NET Framework 4.7.2 或更新版本為目標的 Windows Forms 應用程式上,預設會啟用這些協助工具的變更。These accessibility changes are enabled by default on Windows Forms applications that target the .NET Framework 4.7.2 or later.
  • 其以 .NET Framework 4.7.1 或更新版本為目標,且藉由在應用程式組態檔的 <runtime> 區段中新增下列 AppContext 參數,並將其設定為 false,選擇不使用舊版協助工具行為,如下範例所示。It targets the .NET Framework 4.7.1 or earlier version and opts out of the legacy accessibility behaviors by adding the following AppContext Switch to the <runtime> section of the app config file and setting it to false, as the following example shows.
<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <startup>
    <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.7"/>
  </startup>
  <runtime>
    <!-- AppContextSwitchOverrides value attribute is in the form of 'key1=true/false;key2=true/false  -->
    <AppContextSwitchOverrides value="Switch.UseLegacyAccessibilityFeatures=false;Switch.UseLegacyAccessibilityFeatures.2=false" />
  </runtime>
</configuration>

請注意,選擇使用 .NET Framework 4.7.2 中新增的協助工具功能時,也必須選擇使用 .NET Framework 4.7.1 的協助工具功能。Note that to opt in to the accessibility features added in .NET Framework 4.7.2, you must also opt in to accessibility features of .NET Framework 4.7.1 as well. 以 .NET Framework 4.7.2 或更新版本為目標,而且想要保留舊版協助工具行為的應用程式,可以藉由明確地將此 AppCoNtext 參數設定為,選擇使用舊版的協助工具功能 trueApplications that target the .NET Framework 4.7.2 or later and want to preserve the legacy accessibility behavior can opt in to the use of legacy accessibility features by explicitly setting this AppContext switch to true.

使用高對比佈景主題中作業系統定義的色彩Use of OS-defined colors in High Contrast themes

  • ToolStripDropDownButton 的下拉式箭號現在會於高對比佈景主題中使用 OS 所定義的色彩。The drop down arrow of the ToolStripDropDownButton now uses OS-defined colors in High Contrast theme.
  • 若有選取時,其 FlatStyle 設定為 FlatStyle.FlatFlatStyle.PopupButtonRadioButtonCheckBox 控制項,現已會於高對比佈景主題中使用 OS 所定義的色彩。Button, RadioButton and CheckBox controls with FlatStyle set to FlatStyle.Flat or FlatStyle.Popup now use OS-defined colors in High Contrast theme when selected. 以往,文字和背景色彩不會呈現對比,因此難以閱讀。Previously, text and background colors were not contrasting and were hard to read.
  • GroupBox 中其 Enabled 屬性設定為 false 的控制項,現已會於高對比佈景主題中使用 OS 所定義的色彩。Controls contained within a GroupBox that has its Enabled property set to false will now use OS-defined colors in High Contrast theme.
  • 控制項 ToolStripButtonToolStripComboBoxToolStripDropDownButton 在高對比模式下有更高的亮度對比率。The ToolStripButton, ToolStripComboBox, and ToolStripDropDownButton controls have an increased luminosity contrast ratio in High Contrast Mode.
  • DataGridViewLinkCell 預設會為 DataGridViewLinkCell.LinkColor 屬性在高對比模式下使用 OS 所定義的色彩。DataGridViewLinkCell will by default use OS-defined colors in High Contrast mode for the DataGridViewLinkCell.LinkColor property. 注意:Windows 10 已變更某些高對比系統色彩的值。NOTE: Windows 10 has changed values for some high contrast system colors. Windows Forms 架構是以 Win32 架構為基礎。Windows Forms Framework is based on the Win32 framework. 為了獲得最佳體驗,請在最新版本的 Windows 上執行,並藉由在測試應用程式中新增 app.config 檔案並取消批註下列程式碼,加入宣告最新的 OS 變更:For the best experience, run on the latest version of Windows and opt in to the latest OS changes by adding an app.manifest file in a test application and un-commenting the following code:
<!-- Windows 10 -->
<supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}" />

已改進朗讀程式支援Improved Narrator support

已改進 DataGridView 協助工具支援Improved DataGridView Accessibility support

已改進視覺提示Improved Visual cues

  • Text 屬性為空白的控制項 RadioButtonCheckBox,現已會於接收到焦點時顯示焦點指標。The RadioButton and CheckBox controls with an empty Text property will now display a focus indicator when they receive focus.

已改進屬性方格支援Improved Property Grid Support

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

已改進 .NET 4.8 之 Windows Forms 控制項的協助工具Accessibility improvements in Windows Forms controls for .NET 4.8

詳細資料Details

Windows Forms Framework 利用協助工具技術,持續改善運作方式,可為 Windows Forms 客戶提供更良好的支援。The Windows Forms Framework is continuing to improve how it works with accessibility technologies to better support Windows Forms customers. 這些包括下列變更:These include the following changes:

  • 改善高對比模式期間之顯示方式的變更。Changes to improve display during High Contrast mode.
  • 對朗讀程式的互動進行了變更。Changes to interaction with Narrator.
  • 對可存取階層進行了變更 (改善 UI 自動化樹狀的瀏覽)。Changes in the Accessible hierarchy (improving navigation through the UI Automation tree).

建議Suggestion

如何加入宣告或退出這些變更 為了讓應用程式受益于這些變更,它必須在 .NET Framework 4.8 上執行。How to opt in or out of these changes In order for the application to benefit from these changes, it must run on the .NET Framework 4.8. 應用程式可以用下列任一種方式選擇使用這些變更:The application can opt in into these changes in either of the following ways:

  • 將其重新編譯為以 .NET Framework 4.8 為目標。It is recompiled to target the .NET Framework 4.8. 在以 .NET Framework 4.8 為目標的 Windows Forms 應用程式上,預設會啟用這些協助工具的變更。These accessibility changes are enabled by default on Windows Forms applications that target the .NET Framework 4.8.
  • 其以 .NET Framework 4.7.2 或更早版本為目標,且藉由在應用程式組態檔的 <runtime> 區段中新增下列 AppContext 參數,並設定為 false,選擇不使用舊版協助工具行為,如下範例所示。It targets the .NET Framework 4.7.2 or earlier version and opts out of the legacy accessibility behaviors by adding the following AppContext switch to the <runtime> section of the app config file and setting it to false, as the following example shows.
<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <startup>
    <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.7"/>
  </startup>
  <runtime>
    <!-- AppContextSwitchOverrides value attribute is in the form of 'key1=true/false;key2=true/false  -->
    <AppContextSwitchOverrides value="Switch.UseLegacyAccessibilityFeatures=false;Switch.UseLegacyAccessibilityFeatures.2=false;Switch.UseLegacyAccessibilityFeatures.3=false" />
  </runtime>
</configuration>

請注意,選擇使用 .NET Framework 4.8 中新增的協助工具功能時,也必須選擇使用 .NET Framework 4.7.1 和 4.7.2 的協助工具功能。Note that to opt in to the accessibility features added in .NET Framework 4.8, you must also opt in to accessibility features of .NET Framework 4.7.1 and 4.7.2 as well. 以 .NET Framework 4.8 為目標,並且想要保留舊版協助工具行為的應用程式,可以藉由明確將此 AppContext 參數設為 true,選擇使用舊版的協助工具功能。如需啟用鍵盤工具提示引動過程支援,需要將 Switch.System.Windows.Forms.UseLegacyToolTipDisplay=false 行新增至 AppContextSwitchOverrides 值:Applications that target the .NET Framework 4.8 and want to preserve the legacy accessibility behavior can opt in to the use of legacy accessibility features by explicitly setting this AppContext switch to true.Enabling the keyboard ToolTip invocation support requires adding the Switch.System.Windows.Forms.UseLegacyToolTipDisplay=false line to the AppContextSwitchOverrides value:

<AppContextSwitchOverrides value="Switch.UseLegacyAccessibilityFeatures=false;Switch.UseLegacyAccessibilityFeatures.2=false;Switch.UseLegacyAccessibilityFeatures.3=false;Switch.System.Windows.Forms.UseLegacyToolTipDisplay=false" />

請注意,啟用這項功能需要選擇使用上述 .NET Framework 4.7.1 - 4.8 的協助工具功能。Note that enabling this feature requires opting in to the aforementioned accessibility features of .NET Framework 4.7.1 - 4.8. 此外,如果未選擇使用任何協助工具,但選擇使用了工具提示顯示功能,則在第一次存取這些功能時將擲回執行階段 NotSupportedExceptionAlso, if any of the accessibility features are not opted in but the tooltip display feature is opted in, a runtime NotSupportedException will be thrown on the first access to these features. 例外狀況訊息指出鍵盤工具提示需要啟用層級3的協助工具改進。The exception message indicates that keyboard ToolTips require accessibility improvements of level 3 to be enabled.

使用高對比佈景主題中作業系統定義的色彩Use of OS-defined colors in High Contrast themes

  • 改善的高對比佈景主題。Improved high-contrast themes.

已改進朗讀程式支援Improved Narrator support

改善的 CheckedListBox 協助工具支援Improved CheckedListBox Accessibility support

  • 已改善 CheckedListBox 控制項的朗讀程式支援。Improved Narrator support for the CheckedListBox control. 使用鍵盤瀏覽至 CheckedListBox 控制項時,朗讀程式會專注於 CheckedListBox 項目並宣布該項目。When navigating to the CheckedListBox control using the keyboard, Narrator focuses the CheckedListBox item and announces it.
  • 當控制項變成焦點時,空白 CheckedListBox 控制項現在具有為虛擬第一個項目繪製的焦點矩形。An empty CheckedListBox control now has a focus rectangle drawn for a virtual first item when the control becomes focused.

改善的 ComboBox 協助工具支援Improved ComboBox Accessibility support

  • 已啟用 ComboBox 控制項的 UI 自動化支援,並可使用 UI 自動化通知和其他 UI 自動化功能。Enabled UI Automation support for the ComboBox control, with the ability to use UI Automation notifications and other UI Automation features. 已改進 DataGridView 協助工具支援Improved DataGridView Accessibility support

  • 已啟用 DataGridView 控制項的 UI 自動化支援,並可使用 UI 自動化通知和其他 UI 自動化功能。Enabled UI Automation support for DataGridView control with ability to use UI Automation notifications and other UI Automation features.

  • 對應至 DataGridViewComboBoxEditingControlDataGridViewTextBoxEditingControl 的 UI 自動化項目,現為對應編輯儲存格的子項目。The UI Automation element which corresponds to the DataGridViewComboBoxEditingControl or DataGridViewTextBoxEditingControl is now a child of corresponding editing cell.

改善的 LinkLabel 協助工具支援Improved LinkLabel Accessibility support

  • 改良 LinkLabel 的控制項協助工具:當對應的 LinkLabel 控制項已停用時,朗讀程式會宣佈連結的停用狀態。Improved LinkLabel control accessibility: Narrator announces the disabled state for the link if the corresponding LinkLabel control is disabled.

改善的進度列協助工具支援Improved ProgressBar Accessibility support

  • 已啟用 ProgressBar 控制項的 UI 自動化支援,並可使用 UI 自動化通知和其他 UI 自動化功能。Enabled UI Automation support for the ProgressBar control with the ability to use UI Automation notifications and other UI Automation features. 開發人員現在可以使用 UI 自動化通知,朗讀程式可以透過這些通知顯示進度。Developers are now able to use UI Automation notifications which Narrator can announce to indicate progress. 如需使用者介面自動化事件總覽(包括 UI 自動化通知事件)的總覽,請參閱 消費者介面自動化事件總覽For an overview of UI automation events overview, including UI automation notification events, see the UI Automation Events Overview.

改善的 PropertyGrid 協助工具支援Improved PropertyGrid Accessibility support

  • 已啟用 PropertyGrid 控制項的 UI 自動化支援,並可使用 UI 自動化通知和其他 UI 自動化功能。Enabled UI Automation support for the PropertyGrid control, with the ability to use UI Automation notifications and other UI Automation features.
  • 與當前已編輯屬性對應的 UI 自動化項目,現為對應屬性項目 UI 自動化項目的子項目。The UI Automation element which corresponds to the currently edited property is now a child of the corresponding property item UI Automation element.
  • 如果父 PropertyGrid 控制項設為類別檢視,則 UI 自動化屬性項目項目現為對應類別項目的子項目。The UI Automation property item element is now a child of the corresponding category element if the parent PropertyGrid control is set to category view.

改善的 ToolStrip 支援Improved ToolStrip support

  • 已啟用 ToolStrip 控制項的 UI 自動化支援,並可使用 UI 自動化通知和其他 UI 自動化功能。Enabled UI Automation support for the ToolStrip control, with the ability to use UI Automation notifications and other UI Automation features.
  • 已改善 ToolStrip 項目的瀏覽。Improved navigation through ToolStrip items.
  • 在項目模式中,朗讀程式的焦點未消失,且不會前往隱藏的項目。In items mode, Narrator focus does not disappear and does not go to hidden items.

已改進視覺提示Improved Visual cues

  • 空白 CheckedListBox 控制項現會在收到焦點時顯示焦點指標。An empty CheckedListBox control now displays a focus indicator when it receives focus. 注意:在執行時間中,控制項的 UI 自動化支援已啟用,但不會在設計階段中使用。Note: UI automation support is enabled for controls in runtime but is not used in design time. 如需 UI 自動化的概觀,請參閱 UI 自動化概觀For an overview of UI automation, see the UI Automation Overview.

使用鍵盤叫用控制項的工具提示Invoking controls' ToolTips with a keyboard

  • 現在可以把焦點放在使用鍵盤控制,叫用控制項工具提示。Control tooltip can now be invoked by focusing the control with keyboard. 您必須為應用程式明確啟用這項功能 (請參閱一節** " 如何加入宣告或退出這些變更 " **) This feature needs to be enabled explicitly for the application (see section "How to opt in or out of these changes")
名稱Name Value
範圍Scope 主要Major
版本Version 4.84.8
類型Type 正在重定目標Retargeting

Windows Forms 控制項的協助工具改善Accessibility improvements in Windows Forms controls

詳細資料Details

Windows Forms 正在使用協助工具技術改善其運作方式,以便為 Windows Forms 客戶提供更好的支援。Windows Forms is improving how it works with accessibility technologies to better support Windows Forms customers. 包括自 .NET Framework 4.7.1 開始的下列變更:These include the following changes starting with the .NET Framework 4.7.1:

  • 改善高對比模式期間之顯示方式的變更。Changes to improve display during High Contrast mode.
  • 改善屬性瀏覽器體驗的變更。Changes to improve the property browser experience. 屬性瀏覽器改善包括:Property browser improvements include:
  • 透過各種下拉式選取視窗進行更佳的鍵盤導覽。Better keyboard navigation through the various drop-down selection windows.
  • 減少不必要的定位停駐點。Reduced unnecessary tab stops.
  • 更適當地報告控制項類型。Better reporting of control types.
  • 改善的朗讀程式行為。Improved narrator behavior.
  • 在控制項中實作遺漏的 UI 協助工具模式的變更。Changes to implement missing UI accessibility patterns in controls.

建議Suggestion

如何加入宣告或退出這些變更 為了讓應用程式受益于這些變更,它必須在 .NET Framework 4.7.1 或更新版本上執行。How to opt in or out of these changes In order for the application to benefit from these changes, it must run on the .NET Framework 4.7.1 or later. 應用程式可以用下列任一種方式受益於這些變更:The application can benefit from these changes in either of the following ways:

  • 它已重新編譯為以 .NET Framework 4.7.1 為目標。It is recompiled to target the .NET Framework 4.7.1. 在以 .NET Framework 4.7.1 或更新版本為目標的 Windows Forms 應用程式上,預設會啟用這些協助工具變更。These accessibility changes are enabled by default on Windows Forms applications that target the .NET Framework 4.7.1 or later.
  • 藉由在 app config 檔案的 <runtime> 區段中新增下列 AppContext 參數,並將它設定為 false,選擇退出舊版協助工具行為,如下列範例所示。It opts out of the legacy accessibility behaviors by adding the following AppContext switch to the <runtime> section of the app.config file and setting it to false, as the following example shows.
<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <startup>
    <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.7"/>
  </startup>
  <runtime>
    <!-- AppContextSwitchOverrides value attribute is in the form of 'key1=true/false;key2=true/false  -->
    <AppContextSwitchOverrides value="Switch.UseLegacyAccessibilityFeatures=false" />
  </runtime>
</configuration>

以 .NET Framework 4.7.1 或更新版本為目標,並且想要保留舊版協助工具行為的應用程式,可以藉由明確將此 AppContext 參數設為 true,選擇加入舊版的協助工具功能。Applications that target the .NET Framework 4.7.1 or later and want to preserve the legacy accessibility behavior can opt in to the use of legacy accessibility features by explicitly setting this AppContext switch to true.

如需 UI 自動化的概觀,請參閱 UI 自動化概觀For an overview of UI automation, see the UI Automation Overview.

為 UI 自動化模式和屬性新增的支援Added support for UI Automation patterns and properties
協助工具用戶端可以使用通用的公開描述叫用模式,利用新的 WinForms 協助工具功能。Accessibility clients can take advantage of new WinForms accessibility functionality by using common, publicly described invocation patterns. 這些不是 WinForms 特有模式。These patterns are not WinForms-specific. 例如,協助工具用戶端可以在 IAccessible 介面 (MAAS) 上呼叫 QueryInterface 方法,以取得 IServiceProvider 介面。For instance, accessibility clients can call the QueryInterface method on the IAccessible interface (MAAS) to obtain an IServiceProvider interface. 如果此介面可供使用,用戶端可以使用其 QueryService 方法來要求 IAccessibleEx 介面。If this interface is available, clients can use its QueryService method to request an IAccessibleEx interface. 如需詳細資訊,請參閱從用戶端使用 IAccessibleExFor more information, see Using IAccessibleEx from a Client. 從 .NET Framework 4.7.1 開始,IServiceProvider 和 IAccessibleEx (若適用) 可供 WinForms 協助工具物件使用。Starting with the .NET Framework 4.7.1, IServiceProvider and IAccessibleEx (where applicable) are available for WinForms accessibility objects.

.NET Framework 4.7.1 為下列 UI 自動化模式和屬性新增支援:The .NET Framework 4.7.1 adds support for the following UI automation patterns and properties:

使用高對比佈景主題中作業系統定義的色彩Use of OS-defined colors in High Contrast themes

  • FlatStyle 屬性設定為 FlatStyle.System (這是預設樣式) 的 ButtonCheckBox 控制項,現在使用選取的高對比佈景主題中作業系統定義的色彩。The Button and CheckBox controls with their FlatStyle property set to FlatStyle.System, which is the default style, now use OS-defined colors in High Contrast theme when selected. 以往,文字和背景色彩不會呈現對比,因此難以閱讀。Previously, text and background colors were not contrasting and were hard to read.
  • Enabled 屬性設定為 falseButtonCheckBoxRadioButtonLabelLinkLabelGroupBox 控制項,使用陰影色彩呈現高對比佈景主題中的文字,導致與背景的對比過低。The Button, CheckBox, RadioButton, Label, LinkLabel, and GroupBox controls with their Enabled property set to false used a shaded color to render text in High Contrast themes, resulting in low contrast against the background. 現在,這些控制項使用作業系統所定義的「已停用文字」色彩。Now these controls use the "Disabled Text" color defined by the OS. 此修正套用至 FlatStyle 屬性設定為非 FlatStyle.System 值的控制項。This fix applies to controls with the FlatStyle property set to a value other than FlatStyle.System. 後者的控制項是由作業系統呈現。The latter controls are rendered by the OS.
  • DataGridView 現在會於目前焦點所在的儲存格內容周圍呈現可見的矩形。DataGridView now renders a visible rectangle around the content of the cell which has the current focus. 之前,這不會顯示在特定的高對比佈景主題中。Previously, this was not visible in certain High Contrast themes.
  • ToolStripMenuItemEnabled屬性設為false的控制項現在會使用 " 作業系統所定義的停用文字 " 色彩。ToolStripMenuItem controls with their Enabled property set to false now use the "Disabled Text" color defined by the OS.
  • Checked 屬性設定為 trueToolStripMenuItem 控制項,現在以對比的系統色彩呈現相關聯的核取記號。ToolStripMenuItem controls with their Checked property set to true now render the associated check mark in a contrasting system color. 先前的核取記號色彩對比不足,無法在高對比佈景主題中顯示。Previously the check mark color was not contrasting enough and not visible in High Contrast themes. 注意:Windows 10 已變更某些高對比系統色彩的值。NOTE: Windows 10 has changed values for some high contrast system colors. Windows Forms 架構是以 Win32 架構為基礎。Windows Forms Framework is based on the Win32 framework. 為了獲得最佳體驗,請在最新版本的 Windows 上執行,並藉由在測試應用程式中新增 app.config 檔案並取消批註下列程式碼,加入宣告最新的 OS 變更:For the best experience, run on the latest version of Windows and opt in to the latest OS changes by adding an app.manifest file in a test application and un-commenting the following code:
<!-- Windows 10 -->
<supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}" />

改善的鍵盤導覽Improved keyboard navigation

  • ComboBox 控制項將其 DropDownStyle 屬性設定為 ComboBoxStyle.DropDownList,且它是表單中定位順序的第一個控制項時,如果使用鍵盤來開啟父表單,它現在會顯示焦點矩形。When a ComboBox control has its DropDownStyle property set to ComboBoxStyle.DropDownList and is the first control in the tab order on the form, it now displays a focus rectangle when the parent form is opened using the keyboard. 在這項變更之前,鍵盤焦點是在這個控制項上,但不會呈現焦點指標。Before this change, keyboard focus was on this control, but a focus indicator was not rendered.

已改進朗讀程式支援Improved Narrator support

  • MonthCalendar 控制項已針對輔助技術新增存取控制項的支援,包括讓朗讀程式可以讀取先前無法讀取的控制項值。The MonthCalendar control has added support for assistive technologies to access the control, including the ability for Narrator to read the value of the control when previously it could not.

  • CheckedListBox 控制項現在會於 CheckBox.CheckState 屬性已變更時通知朗讀程式。The CheckedListBox control now notifies Narrator when a CheckBox.CheckState property has been changed. 之前,朗讀程式不會收到通知,因此使用者不會被告知 CheckState 屬性已更新。Previously, Narrator did not receive notification and as a result users would not be informed that the CheckState property had been updated.

  • LinkLabel 控制項已變更其告知朗讀程式有關控制項文字的方式。The LinkLabel control has changed the way it notifies Narrator of the text of in the control. 之前,朗讀程式會宣告這段文字兩次,並將 "&" 符號讀取為實際文字,即使使用者看不到這些文字也一樣。Previously, Narrator announced this text twice and read "&" symbols as real text even though they are not visible to a user. 已從朗讀程式宣告中移除重複的文字,以及不必要的 "&" 符號。The duplicated text was removed from the Narrator announcements, as well as unnecessary "&" symbols.

  • DataGridViewCell 控制項類型現在會正確地向朗讀程式和其他輔助技術報告唯讀狀態。The DataGridViewCell control types now correctly report the read-only status to Narrator and other assistive technologies.

  • 朗讀程式現在可以讀取 [Multiple-Document Interface]~/docs/framework/winforms/advanced/multiple-document-interface-mdi-applications.md) 應用程式中的子視窗系統功能表。Narrator is now able to read the System Menu of child windows in [Multiple-Document Interface]~/docs/framework/winforms/advanced/multiple-document-interface-mdi-applications.md) applications.

  • 朗讀程式現在可以讀取 ToolStripItem.Enabled 屬性設定為 falseToolStripMenuItem 控制項。Narrator is now able to read ToolStripMenuItem controls with a ToolStripItem.Enabled property set to false. 之前,朗讀程式無法將焦點放在已停用的功能表項目來讀取內容。Previously, Narrator was unable to focus on disabled menu items to read the content.

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

受影響的 APIAffected APIs

針對 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

在巢狀 ToolStripMenuItems 的情況下,ContextMenuStrip.SourceControl 屬性包含有效的控制項ContextMenuStrip.SourceControl property contains a valid control in the case of nested ToolStripMenuItems

詳細資料Details

在 .NET Framework 4.7.1 和舊版本中,當使用者從巢狀 ToolStripMenuItem 控制項開啟功能表時,ContextMenuStrip.SourceControl 屬性會誤傳回 null。In the .NET Framework 4.7.1 and previous versions, the ContextMenuStrip.SourceControl property incorrectly returns null when the user opens the menu from nested ToolStripMenuItem controls. 在 .NET Framework 4.7.2 和更新版本中,一律會將 SourceControl 屬性設定為實際的來源控制項。In the .NET Framework 4.7.2 and later, SourceControl property is always set to the actual source control.

建議Suggestion

如何加入宣告或退出這些變更 為了讓應用程式受益于這些變更,它必須在 .NET Framework 4.7.2 或更新版本上執行。How to opt in or out of these changes In order for an application to benefit from these changes, it must run on the .NET Framework 4.7.2 or later. 應用程式可以用下列任一種方式受益於這些變更:The application can benefit from these changes in either of the following ways:

  • 以 .NET Framework 4.7.2 為目標。It targets the .NET Framework 4.7.2. 在以 .NET Framework 4.7.2 或更新版本為目標的 Windows Forms 應用程式上,預設會啟用這項變更。This change is enabled by default on Windows Forms applications that target the .NET Framework 4.7.2 or later.
  • 以 .NET Framework 4.7.1 或舊版為目標,並選擇不使用舊版協助工具行為;方法為在 app.config 檔的 <runtime> 區段中新增下列 AppContext 參數,並將其設定為 false,如下範例所示。It targets the .NET Framework 4.7.1 or an earlier version and opts out of the legacy accessibility behaviors by adding the following AppContext Switch to the <runtime> section of the app.config file and setting it to false, as the following example shows.
<runtime>
  <AppContextSwitchOverrides value="Switch.System.Windows.Forms.UseLegacyContextMenuStripSourceControlValue=false"/>
</runtime>

如果應用程式是以 .NET Framework 4.7.2 或更新版本為目標,而您想要保留舊版的行為,則可以明確將此 AppContext 參數設為 true,選擇使用舊版的來源控制項。Applications that target the .NET Framework 4.7.2 or later, and want to preserve the legacy behavior can opt in to the use of the legacy source control value by explicitly setting this AppContext switch to true.

名稱Name Value
範圍Scope EdgeEdge
版本Version 4.7.24.7.2
類型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

MemberDescriptor.Equals 的實作不正確Incorrect implementation of MemberDescriptor.Equals

詳細資料Details

MemberDescriptor.Equals 方法的原始實作會比較正在比較之物件的兩個不同字串屬性:分類名稱與描述字串。The original implementation of the MemberDescriptor.Equals method compares two different string properties from the objects being compared: the category name and the description string. 修正方法是比較第一個物件的 Category 和第二個物件的 Category,比較第一個物件的 Description 和第二個物件的 DescriptionThe fix is to compare the Category of the first object to the Category of the second one, and the Description of the first to the Description of the second.

建議Suggestion

如果您的應用程式相依於當描述項相等時有時會傳回 falseMemberDescriptor.Equals,而且您的目標是 .NET Framework 4.6.2 版或更新版本,則有數個選項:If your application depends on MemberDescriptor.Equals sometimes returning false when descriptors are equivalent, and you are targeting the .NET Framework 4.6.2 or later, you have several options:

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

如果您的應用程式目標設為 .NET Framework 4.6.1 或較舊版本,但在 .NET Framework 4.6.2 或更新版本上執行,而您想要啟用這項變更,您可以在 app.config 檔案中新增下列值,將相容性參數設為 falseIf your application targets .NET Framework 4.6.1 or earlier and is running on the .NET Framework 4.6.2 or later and you want this change enabled, you can set the compatibility switch to false by adding the following value to the app.config file:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.MemberDescriptorEqualsReturnsFalseIfEquivalent=false" />
</runtime>
名稱Name Value
影響範圍Scope EdgeEdge
版本Version 4.6.24.6.2
類型Type 正在重定目標Retargeting

受影響的 APIAffected APIs

PrivateFontCollection.AddFontFile 方法會釋放字型資源PrivateFontCollection.AddFontFile method releases Font resources

詳細資料Details

在 .NET Framework 4.7.1 和舊版本中,如果 Font 物件是使用 AddFontFile(String) 方法新增至這個集合,則 System.Drawing.Text.PrivateFontCollection 類別不會在處置物件的 PrivateFontCollection 之後釋放 GDI+ 字型資源。In the .NET Framework 4.7.1 and previous versions, the System.Drawing.Text.PrivateFontCollection class does not release the GDI+ font resources after the PrivateFontCollection is disposed for Font objects that are added to this collection using the AddFontFile(String) method. 在 .NET Framework 4.7.2 和更新版本中,Dispose 會釋放已藉由檔案形式新增至集合中的 GDI+ 字型。In the .NET Framework 4.7.2 and later Dispose releases the GDI+ fonts that were added to the collection as files.

建議Suggestion

如何加入宣告或退出這些變更 為了讓應用程式受益于這些變更,它必須在 .NET Framework 4.7.2 或更新版本上執行。How to opt in or out of these changes In order for an application to benefit from these changes, it must run on the .NET Framework 4.7.2 or later. 應用程式可以用下列任一種方式受益於這些變更:The application can benefit from these changes in either of the following ways:

  • 將其重新編譯為以 .NET Framework 4.7.2 為目標。It is recompiled to target the .NET Framework 4.7.2. 在以 .NET Framework 4.7.2 或更新版本為目標的 Windows Forms 應用程式上,預設會啟用這項變更。This change is enabled by default on Windows Forms applications that target the .NET Framework 4.7.2 or later.
  • 以 .NET Framework 4.7.1 或舊版為目標,並選擇不使用舊版協助工具行為;方法為在 app.config 檔的 <runtime> 區段中新增下列 AppContext 參數,並將其設定為 false,如下範例所示。It targets the .NET Framework 4.7.1 or an earlier version and opts out of the legacy accessibility behaviors by adding the following AppContext Switch to the <runtime> section of the app.config file and setting it to false, as the following example shows.
<runtime>
<AppContextSwitchOverrides value="Switch.System.Drawing.Text.DoNotRemoveGdiFontsResourcesFromFontCollection=false"/>
</runtime>

如果應用程式是以 .NET Framework 4.7.2 或更新版本為目標,而您想要保留舊版本的行為,則可以明確將此 AppContext 參數設為 true,選擇不要釋放字型資源。Applications that target the .NET Framework 4.7.2 or later, and want to preserve the legacy behavior can opt in to not release font resources by explicitly setting this AppContext switch to true.

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

受影響的 APIAffected APIs

WinForm 的網域 upbutton 和 downbutton 動作現在會同步WinForm's Domain upbutton and downbutton actions are in sync now

詳細資料Details

在 .NET Framework 4.7.1 和先前版本中,DomainUpDown 控制項的 DomainUpDown.UpButton() 動作會在控制項文字存在時予以忽略,因此開發人員必須在控制項上使用 DomainUpDown.DownButton() 動作,才能使用 DomainUpDown.UpButton() 動作。In the .NET Framework 4.7.1 and previous versions the DomainUpDown control's DomainUpDown.UpButton() action is ignored when control text is present, and the developer is required to use DomainUpDown.DownButton() action on the control before using DomainUpDown.UpButton() action. 從 .NET Framework 4.7.2 開始,DomainUpDown.UpButton()DomainUpDown.DownButton() 這兩個動作在此案例中會獨立工作,並保持同步。Starting with the .NET Framework 4.7.2 both the DomainUpDown.UpButton() and DomainUpDown.DownButton() actions work independently in this scenario and remain in sync.

建議Suggestion

為了讓應用程式可受益於這些變更,它必須在 .NET Framework 4.7.2 或更新版本上執行。In order for an application to benefit from these changes, it must run on the .NET Framework 4.7.2 or later. 應用程式可以用下列任一種方式受益於這些變更:The application can benefit from these changes in either of the following ways:

  • 將其重新編譯為以 .NET Framework 4.7.2 為目標。It is recompiled to target the .NET Framework 4.7.2. 在以 .NET Framework 4.7.2 或更新版本為目標的 Windows Forms 應用程式上,預設會啟用這項變更。This change is enabled by default on Windows Forms applications that target the .NET Framework 4.7.2 or later.
  • 藉由在應用程式組態檔的 <runtime> 區段中新增下列 AppContext 參數,並將它設定為 false,選擇退出舊版捲動行為,如下列範例所示。It opts out of the legacy scrolling behavior by adding the following AppContext Switch to the <runtime> section of the app config file and setting it to false, as the following example shows.
<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Forms.DomainUpDown.UseLegacyScrolling=false"/>
</runtime>
名稱Name Value
範圍Scope EdgeEdge
版本Version 4.7.24.7.2
類型Type 正在重定目標Retargeting

受影響的 APIAffected APIs

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

WPF 的協助工具改善Accessibility improvements in WPF

詳細資料Details

高對比改善High Contrast improvements

  • 現在會顯示 Expander 控制項的焦點。The focus for the Expander control is now visible. 在舊版 .NET Framework 中,則不是。In previous versions of .NET Framework, it was not.
  • CheckBoxRadioButton 控制項在選取時,其中的文字現在比起舊版 .NET Framework 更容易查看。The text in CheckBox and RadioButton controls when they are selected is now easier to see than in previous .NET Framework versions.
  • 已停用 ComboBox 的框線現在與已停用文字的色彩相同。The border of a disabled ComboBox is now the same color as the disabled text. 在舊版 .NET Framework 中,則不是。In previous versions of .NET Framework, it was not.
  • 已停用和聚焦按鈕現在會使用正確的佈景主題色彩。Disabled and focused buttons now use the correct theme color. 在舊版 .NET Framework 中,它們沒有。In previous versions of .NET Framework, they did not.
  • ComboBox 控制項的樣式設定為時,現在會顯示下拉式按鈕 ToolBar.ComboBoxStyleKeyThe dropdown button is now visible when a ComboBox control's style is set to ToolBar.ComboBoxStyleKey. 在舊版 .NET Framework 中,則不是。In previous versions of .NET Framework, it was not.
  • DataGrid 控制項中的排序指標箭號現在會使用佈景主題色彩。The sort indicator arrow in a DataGrid control now uses theme colors. 在舊版的 .NET Framework 中,它不是。In previous versions of .NET Framework, it did not.
  • 預設的超連結樣式現在會在滑鼠移至上方時變更為正確的佈景主題色彩。The default hyperlink style now changes to the correct theme color on mouse over. 在舊版的 .NET Framework 中,它不是。In previous versions of .NET Framework, it did not.
  • 現在會顯示選項按鈕上的鍵盤焦點。The Keyboard focus on radio buttons is now visible. 在舊版 .NET Framework 中,則不是。In previous versions of .NET Framework, it was not.
  • DataGrid 控制項的核取方塊資料行現在會使用鍵盤焦點回饋的預期色彩。The DataGrid control's checkbox column now uses the expected colors for keyboard focus feedback. 在舊版的 .NET Framework 中,它不是。In previous versions of .NET Framework, it did not.
  • 鍵盤焦點視覺效果現在會顯示在 ComboBoxListBox 控制項上。the Keyboard focus visuals are now visible on ComboBox and ListBox controls. 在舊版 .NET Framework 中,則不是。In previous versions of .NET Framework, it was not.

螢幕助讀程式互動改善Screen reader interaction improvements

  • 螢幕助讀程式現在會將 Expander 控制項正確宣告為群組 (展開/摺疊)。Expander controls are now correctly announced as groups (expand/collapse) by screen readers.
  • 螢幕助讀程式現在會將 DataGridCell 控制項正確宣告為資料儲存格 (展開/摺疊)。DataGridCell controls are now correctly announced as data grid cell (localized) by screen readers.
  • 螢幕助讀程式現在會宣告可編輯 ComboBox 的名稱。Screen readers will now announce the name of an editable ComboBox.
  • PasswordBox 螢幕讀取器不再將控制項宣告為「沒有專案在視野中」。PasswordBox controls are no longer announced as "no item in view" by screen readers.

LiveRegion 支援LiveRegion support

螢幕閱讀程式(例如朗讀程式)可協助人員瞭解應用程式的使用者介面 (UI) ,通常是透過描述目前擁有焦點的 UI 元素。Screen readers, such as Narrator, help people understand the user interface (UI) of an application, usually by describing the UI element that currently has focus. 不過,如果螢幕某處的 UI 項目變更,而且沒有焦點,則使用者可能不會收到通知,並且可能會遺失重要資訊。However, if a UI element changes somewhere in the screen and it does not have the focus, the user may not be informed and miss important information. LiveRegions 旨在用來解決這個問題。LiveRegions are meant to solve this problem. 開發人員可以使用它們來通知螢幕助讀程式或任何其他 UI 自動化用戶端,已對 UI 項目進行重要變更。A developer can use them to inform the screen reader or any other UI Automation client that an important change has been made to a UI element. 螢幕助讀程式接著可以決定如何和何時通知使用者已進行這項變更。The screen reader can then decide how and when to inform the user of this change. LiveSetting 屬性還可讓螢幕助讀程式知道通知使用者 UI 所做變更的重要性。The LiveSetting property also lets the screen reader know how important it is to inform the user of the change made to the UI.

建議Suggestion

如何選擇加入或退出這些變更How to opt in or out of these changes

為了讓應用程式受益于這些變更,它必須在 .NET Framework 4.7.1 或更新版本上執行。In order for the application to benefit from these changes, it must run on .NET Framework 4.7.1 or later. 應用程式可以用下列任一種方式受益於這些變更:The application can benefit from these changes in either of the following ways:

  • 目標 .NET Framework 4.7.1。Target .NET Framework 4.7.1. 這是建議的方法。This is the recommended approach. 在以 .NET Framework 4.7.1 或更新版本為目標的 WPF 應用程式上,預設會啟用這些協助工具變更。These accessibility changes are enabled by default on WPF applications that target .NET Framework 4.7.1 or later.

  • 藉由在 app config 檔案的 <runtime> 區段中新增下列 AppContext 參數,並將它設定為 false,選擇退出舊版協助工具行為,如下列範例所示。It opts out of the legacy accessibility behaviors by adding the following AppContext Switch in the <runtime> section of the app config file and setting it to false, as the following example shows.

    <?xml version="1.0" encoding="utf-8"?>
    <configuration>
      <startup>
        <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.7"/>
      </startup>
      <runtime>
        <!-- AppContextSwitchOverrides value attribute is in the form of 'key1=true/false;key2=true/false'  -->
        <AppContextSwitchOverrides value="Switch.UseLegacyAccessibilityFeatures=false" />
      </runtime>
    </configuration>
    

以 .NET Framework 4.7.1 或更新版本為目標,而且想要保留舊版協助工具行為的應用程式,可以藉由明確地將此 AppCoNtext 參數設定為,選擇使用舊版的協助工具功能 trueApplications that target .NET Framework 4.7.1 or later and want to preserve the legacy accessibility behavior can opt in to the use of legacy accessibility features by explicitly setting this AppContext switch to true. 如需 UI 自動化的總覽,請參閱 消費者介面自動化總覽For an overview of UI automation, see UI Automation Overview.

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

受影響的 APIAffected APIs

將 SelectionTextBrush 公用屬性新增至 TextBox/PasswordBox 非提示選取項目Add SelectionTextBrush public property to TextBox/PasswordBox non-adorner selection

詳細資料Details

在針對 TextBoxPasswordBox 使用非提示型文字選取項目的 WPF 應用程式中,開發人員現在可以設定新增的 SelectionTextBrush 屬性,以變更所選文字的轉譯。In WPF applications using non-adorner based text selection for TextBox and PasswordBox, developers may now set the newly added SelectionTextBrush property in order to alter the rendering of the selected text. 根據預設,此色彩會隨著 HighlightTextBrushKey 而變更。By default, this color changes with HighlightTextBrushKey. 如果未啟用非提示型文字選取範圍,則會忽略這個屬性。If non-adorner based text selection is not enabled, this property does nothing.

建議Suggestion

啟用非提示型文字選取範圍後,您可以使用 PasswordBox.SelectionTextBrushSelectionTextBrush 屬性變更所選文字的外觀。Once non-adorner based text selection is enabled, you can use the PasswordBox.SelectionTextBrush and SelectionTextBrush property to change the appearance of the selected text. 此操作可以使用 XAML 完成:This can be achieved using XAML:

<TextBox SelectionBrush="Red" SelectionTextBrush="White"  SelectionOpacity="0.5"
Foreground="Blue" CaretBrush="Blue">
This is some text.
</TextBox>
名稱Name Value
影響範圍Scope 主要Major
版本Version 4.84.8
類型Type 正在重定目標Retargeting

受影響的 APIAffected APIs

HwndHost 現在會在 DPI 變更期間正確調整子 HWND 的大小HwndHost now correctly resizes child-HWND during DPI changes

詳細資料Details

在 .NET Framework 4.7.2 和更早版本中,當 WPF 在個別監視器感知模式中執行時,裝載於 HwndHost 內的控制項未在 DPI 變更後正確調整大小,例如將應用程式從某個監視器移至另一個監視器時。In .NET Framework 4.7.2 and earlier versions, when WPF was run in Per-Monitor Aware mode, controls hosted within HwndHost were not sized correctly after DPI changes, such as when moving applications from one monitor to another. 此修正可確保裝載的控制項適當調整大小。This fix ensures that hosted controls are sized appropriately.

建議Suggestion

為了讓應用程式受益於這些變更,應用程式必須於 .NET Framework 4.7.2 或更新版本執行,並且必須藉由將應用程式組態檔中 <runtime> 區段的 AppContext 參數設為 false 來選擇使用此行為,如下列範例所示。In order for the application to benefit from these changes, it must run on the .NET Framework 4.7.2 or later, and it must opt-in to this behavior by setting the following AppContext Switch in the <runtime> section of the app config file to false, as the following example shows.

<?xml version="1.0" encoding="utf-8"?>
<configuration>
<startup>
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.7"/>
</startup>
<runtime>
<!-- AppContextSwitchOverrides value attribute is in the form of 'key1=true/false;key2=true/false  -->
<AppContextSwitchOverrides value="Switch.System.Windows.DoNotUsePresentationDpiCapabilityTier2OrGreater=false" />
</runtime>
</configuration>
名稱Name Value
範圍Scope 主要Major
版本Version 4.84.8
類型Type 正在重定目標Retargeting

鍵盤焦點現在可在 WinForms/WPF 裝載的多個圖層中正確移動Keyboard focus now moves correctly across multiple layers of WinForms/WPF hosting

詳細資料Details

請考慮裝載 WinForms 控制項的 WPF 應用程式,此控制項因此會裝載 WPF 控制項。Consider a WPF application hosting a WinForms control which in turn hosts WPF controls. 如果該圖層中的第一個或最後一個控制項是 WPF System.Windows.Forms.Integration.ElementHost,使用者可能無法使用 Tab 離開 WinForms 圖層。Users may not be able to tab out of the WinForms layer if the first or last control in that layer is the WPF System.Windows.Forms.Integration.ElementHost. 這項變更會修正此問題,而且使用者現在可以使用 Tab 離開 WinForms 圖層。依賴焦點的自動化應用程式絕不會逸出可能不再如預期運作的 WinForms 圖層。This change fixes this issue, and users are now able to tab out of the WinForms layer.Automated applications that rely on focus never escaping the WinForms layer may no longer work as expected.

建議Suggestion

至於以低於 .NET Framework 4.7.2 版本為目標,又想要利用這項變更的開發人員,可以將下列 AppContext 旗標集合設為 false,以啟用變更。A developer who wants to utilize this change while targeting a framework version below .NET 4.7.2 can set the following set of AppContext flags to false for the change to be enabled.

<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.UseLegacyAccessibilityFeatures=false;Switch.UseLegacyAccessibilityFeatures.2=false"/>
</runtime>
</configuration>

WPF 應用程式必須選擇所有早期的協助工具改善,才能取得更新版本的增強功能。WPF applications must opt in to all early accessibility improvements to get the later improvements. 換句話說,Switch.UseLegacyAccessibilityFeaturesSwitch.UseLegacyAccessibilityFeatures.2 參數都必須是以 .NET 4.7.2 或更新版本為目標且需要先前功能的 setA 開發人員,其可將下列的 AppContext 旗標設為 true,才能停用變更。In other words, both the Switch.UseLegacyAccessibilityFeatures and the Switch.UseLegacyAccessibilityFeatures.2 switches must be setA developer who requires the previous functionality while targeting .NET 4.7.2 or greater can set the following AppContext flag to true for the change to be disabled.

<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.UseLegacyAccessibilityFeatures.2=true"/>
</runtime>
</configuration>
名稱Name Value
影響範圍Scope EdgeEdge
版本Version 4.7.24.7.2
類型Type 正在重定目標Retargeting

ImageSourceConverter.ConvertFrom 之例外狀況處理程式碼中的 NullReferenceExceptionNullReferenceException in exception handling code from ImageSourceConverter.ConvertFrom

詳細資料Details

ConvertFrom(ITypeDescriptorContext, CultureInfo, Object) 的例外狀況處理程式碼錯誤已導致擲回不正確的 System.NullReferenceException,而不是預期的例外狀況 (System.IO.DirectoryNotFoundExceptionSystem.IO.FileNotFoundException)。An error in the exception handling code for ConvertFrom(ITypeDescriptorContext, CultureInfo, Object) caused an incorrect System.NullReferenceException to be thrown instead of the intended exception ( System.IO.DirectoryNotFoundException or System.IO.FileNotFoundException). 這項變更會修正該錯誤,讓該方法現在擲回正確的例外狀況。This change corrects that error so that the method now throws the right exception.

根據預設,所有以 .NET Framework 4.6.2 和更早版本為目標的應用程式會繼續擲回 System.NullReferenceException 以提供相容性。By default all applications targeting .NET Framework 4.6.2 and earlier continue to throw System.NullReferenceException for compatibility. 以 .NET Framework 4.7 和以上版本為目標的開發人員應該會看到正確的例外狀況。Developers targeting .NET Framework 4.7 and above should see the right exceptions.

建議Suggestion

開發人員若想要在以 .NET Framework 4.7 或更新版本為目標時還原成取得 System.NullReferenceException,可以在其應用程式的 App.config 檔案中新增/合併下列程式碼:Developers who wish to revert to getting System.NullReferenceException when targeting .NET Framework 4.7 or later can add/merge the following to their application's App.config file:

<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Media.ImageSourceConverter.OverrideExceptionWithNullReferenceException=true"/>
</runtime>
</configuration>
名稱Name Value
影響範圍Scope EdgeEdge
版本Version 4.74.7
類型Type 正在重定目標Retargeting

受影響的 APIAffected APIs

Selector 的 SelectionChanged 事件和 SelectedValue 屬性Selector SelectionChanged event and SelectedValue property

詳細資料Details

從 .NET Framework 4.7.1 開始,Selector 在其選取項目變更時,一律會先更新其 SelectedValue 屬性的值,再引發 SelectionChanged 事件。Starting with the .NET Framework 4.7.1, a Selector always updates the value of its SelectedValue property before raising the SelectionChanged event, when its selection changes. 這會讓 SelectedValue 屬性與其他的選取項目屬性一致 (SelectedItemSelectedIndex),它們會在引發事件前予以更新。This makes the SelectedValue property consistent with the other selection properties (SelectedItem and SelectedIndex), which are updated before raising the event.

在 .NET Framework 4.7 和舊版中,在大部分情況下,更新 SelectedValue 會發生在事件之前,但如果選取項目變更是由於變更 SelectedValue 屬性所造成,則會發生在事件之後。In the .NET Framework 4.7 and earlier versions, the update to SelectedValue happened before the event in most cases, but it happened after the event if the selection change was caused by changing the SelectedValue property.

建議Suggestion

以 .NET Framework 4.7.1 或更新版本為目標的應用程式可透過在應用程式組態檔的 <runtime> 區段中新增下列內容來選擇退出此變更,並使用舊版行為:Apps that target the .NET Framework 4.7.1 or later can opt out of this change and use legacy behavior by adding the following to the <runtime> section of the application configuration file:

<runtime>
<AppContextSwitchOverrides
value="Switch.System.Windows.Controls.TabControl.SelectionPropertiesCanLagBehindSelectionChangedEvent=true" />
</runtime>

以 .NET Framework 4.7 或舊版為目標但在 .NET Framework 4.7.1 或更新版本上執行的應用程式,只要在應用程式組態檔的 <runtime> 區段新增下列程式行,就能啟用新行為:Apps that target the .NET Framework 4.7 or earlier but are running on the .NET Framework 4.7.1 or later can enable the new behavior by adding the following line to the <runtime> section of the application .configuration file:

<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Controls.TabControl.SelectionPropertiesCanLagBehindSelectionChangedEvent=false" />
</runtime>
名稱Name Value
影響範圍Scope MinorMinor
版本Version 4.7.14.7.1
類型Type 正在重定目標Retargeting

受影響的 APIAffected APIs

TabControl SelectionChanged 事件和 SelectedContent 屬性TabControl SelectionChanged event and SelectedContent property

詳細資料Details

從 .NET Framework 4.7.1 開始,TabControl 會在其選取項目變更時先更新其 SelectedContent 屬性的值,再引發 SelectionChanged 事件。在 .NET Framework 4.7 和舊版中,更新 SelectedContent 發生在事件之後。Starting with the .NET Framework 4.7.1, a TabControl updates the value of its SelectedContent property before raising the SelectionChanged event, when its selection changes.In the .NET Framework 4.7 and earlier versions, the update to SelectedContent happened after the event.

建議Suggestion

以 .NET Framework 4.7.1 或更新版本為目標的應用程式可透過在應用程式組態檔的 <runtime> 區段中新增下列內容來選擇退出此變更,並使用舊版行為:Apps that target the .NET Framework 4.7.1 or later can opt out of this change and use legacy behavior by adding the following to the <runtime> section of the application configuration file:

<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Controls.TabControl.SelectionPropertiesCanLagBehindSelectionChangedEvent=true" />
</runtime>

以 .NET Framework 4.7 或舊版為目標但在 .NET Framework 4.7.1 或更新版本上執行的應用程式,只要在應用程式組態檔的 <runtime> 區段新增下列程式行,就能啟用新行為:Apps that target the .NET Framework 4.7 or earlier but are running on the .NET Framework 4.7.1 or later can enable the new behavior by adding the following line to the <runtime> section of the application .configuration file:

<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Controls.TabControl.SelectionPropertiesCanLagBehindSelectionChangedEvent=false" />
</runtime>
名稱Name Value
影響範圍Scope MinorMinor
版本Version 4.7.14.7.1
類型Type 正在重定目標Retargeting

受影響的 APIAffected APIs

WPF PackageDigitalSignatureManager 的預設雜湊演算法現在是 SHA256The default hash algorithm for WPF PackageDigitalSignatureManager is now SHA256

詳細資料Details

System.IO.Packaging.PackageDigitalSignatureManager 提供與 WPF 套件相關的數位簽章功能。The System.IO.Packaging.PackageDigitalSignatureManager provides functionality for digital signatures in relation to WPF packages. 在 .NET Framework 4.7 和舊版中,用來簽署套件各部分的預設演算法 (PackageDigitalSignatureManager.DefaultHashAlgorithm) 是 SHA1。In the .NET Framework 4.7 and earlier versions, the default algorithm (PackageDigitalSignatureManager.DefaultHashAlgorithm) used for signing parts of a package was SHA1. 由於最新的 SHA1 安全性考量之故,這個預設值從 .NET Framework 4.7.1 開始已變更為 SHA256。Due to recent security concerns with SHA1, this default has been changed to SHA256 starting with the .NET Framework 4.7.1. 這項變更會影響所有套件簽署,包括 XPS 文件。This change affects all package signing, including XPS documents.

建議Suggestion

開發人員若想要在目標設為低於 .NET Framework 4.7.1 的 Framework 版本時利用這項變更,或在目標設為 .NET Framework 4.7.1 或更高版本時使用先前的功能,可以適當地設定下列 AppContext 旗標。A developer who wants to utilize this change while targeting a framework version below .NET Framework 4.7.1 or a developer who requires the previous functionality while targeting .NET Framework 4.7.1 or greater can set the following AppContext flag appropriately. true 值會導致使用 SHA1 作為預設演算法;false 值則導致使用 SHA256。A value of true will result in SHA1 being used as the default algorithm; false results in SHA256.

<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.MS.Internal.UseSha1AsDefaultHashAlgorithmForDigitalSignatures=true"/>
</runtime>
</configuration>

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

受影響的 APIAffected APIs

現在,WPF 標記編譯器的預設雜湊演算法是 SHA256The default hash algorithm for WPF's Markup Compiler is now SHA256

詳細資料Details

WPF 標記編譯器提供 XAML 標記檔案的編譯服務。The WPF MarkupCompiler provides compilation services for XAML markup files. 在 .NET Framework 4.7.1 和舊版本中,用於總和檢查碼的預設演算法是 SHA1。In the .NET Framework 4.7.1 and earlier versions, the default hash algorithm used for checksums was SHA1. 但由於最近對 SHA1 產生的安全性顧慮,因此從 .NET Framework 4.7.2 開始,這個預設已變更為 SHA256。Due to recent security concerns with SHA1, this default has been changed to SHA256 starting with the .NET Framework 4.7.2. 這項變更會影響標記檔案在編譯期間產生的所有總和檢查碼。This change affects all checksum generation for markup files during compilation.

建議Suggestion

如果開發人員是以 .NET Framework 4.7.2 或更新版本為目標,並想還原到 SHA1 雜湊行為,則必須設定下列 AppContext 旗標。A developer who targets .NET Framework 4.7.2 or greater and wants to revert to SHA1 hashing behavior must set the following AppContext flag.

<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Markup.DoNotUseSha256ForMarkupCompilerChecksumAlgorithm=true"/>
</runtime>
</configuration>

如果開發人員想要利用 SHA256 雜湊,同時以 .NET 4.7.2 以下的 Framework 版本為目標,則必須設定下列 AppContext 旗標。A developer who wants to utilize SHA256 hashing while targeting a framework version below .NET 4.7.2 must set the below AppContext flag. 請注意,安裝的 .NET Framework 版本必須為 4.7.2 或更新版本。Note that the installed version of the .NET Framework must be 4.7.2 or greater.

<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Markup.DoNotUseSha256ForMarkupCompilerChecksumAlgorithm=false
</runtime>
</configuration>
名稱Name Value
影響範圍Scope 透明Transparent
版本Version 4.7.24.7.2
類型Type 正在重定目標Retargeting

WPF AppDomain 關閉處理現在可能呼叫發送器。清除弱式事件時叫用WPF AppDomain Shutdown Handling May Now Call Dispatcher.Invoke in Cleanup of Weak Events

詳細資料Details

在 .NET Framework 4.7.1 和較早的版本中,WPF 可能會在 System.Windows.Threading.Dispatcher AppDomain 關閉期間,于 .net 完成項執行緒上建立。In .NET Framework 4.7.1 and earlier versions, WPF potentially creates a System.Windows.Threading.Dispatcher on the .NET finalizer thread during AppDomain shutdown. 這是在 .NET Framework 4.7.2 和更新版本中修正,方法是讓清除弱式事件的執行緒感知。This was fixed in .NET Framework 4.7.2 and later versions by making the cleanup of weak events thread-aware. 因此,WPF 可能會呼叫 Dispatcher.Invoke 來完成清除程式。在某些應用程式中,完成項時間的變更可能會在 AppDomain 或處理常式關閉期間造成例外狀況。Due to this, WPF may call Dispatcher.Invoke to complete the cleanup process.In certain applications, this change in finalizer timing can potentially cause exceptions during AppDomain or process shutdown. 在進程或 AppDomain 關閉之前,未正確關閉工作者執行緒上執行之發送器的應用程式中,通常會出現這種情況。This is generally seen in applications that do not correctly shut down dispatchers running on worker threads prior to process or AppDomain shutdown. 這類應用程式應該負責妥善管理發送器的存留期。Such applications should take care to properly manage the lifetime of dispatchers.

建議Suggestion

在 .NET Framework 4.7.2 和更新版本中,開發人員可以停用此修正程式,以協助減少(但不能消除)因清除變更而可能發生的時間問題。若要停用清除中的變更,請使用下列 AppCoNtext 旗標。In .NET Framework 4.7.2 and later versions, developers can disable this fix in order to help alleviate (but not eliminate) timing issues that may occur due to the cleanup change.To disable the change in cleanup, use the following AppContext flag.

<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.MS.Internal.DoNotInvokeInWeakEventTableShutdownListener=true"/>
</runtime>
</configuration>

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

WPF 在主要/詳細資料案例中顯示 ADO 資料時會變更主索引鍵WPF Changing a primary key when displaying ADO data in a Master/Detail scenario

詳細資料Details

假設您有 Order 類型的 ADO 項目集合,並具有名為 "OrderDetails" 的關係,透過主索引鍵 "OrderID" 將它與 Detail 類型的項目集合相關聯。Suppose you have an ADO collection of items of type Order, with a relation named "OrderDetails" relating it to a collection of items of type Detail via the primary key "OrderID". 在 WPF 應用程式中,您可以將清單控制項繫結到指定訂單的詳細資料:In your WPF app, you can bind a list control to the details for a given order:

<ListBox ItemsSource="{Binding Path=OrderDetails}" >

其中 DataContext 是 Orderwhere the DataContext is an Order. WPF 會取得屬性的值 OrderDetails -所有專案的集合 D, DetailOrderID 符合 OrderID 主要專案的。WPF gets the value of the OrderDetails property - a collection D of all the Detail items whose OrderID matches the OrderID of the master item. 當您變更主要專案的主鍵時,就會發生行為變更 OrderIDThe behavior change arises when you change the primary key OrderID of the master item. ADO 會自動變更 Details 集合中每個受影響記錄的 OrderID (也就是複製到集合 D 的項目)。ADO automatically changes the OrderID of each of the affected records in the Details collection (namely the ones copied into collection D). 但 D 會發生什麼情況?But what happens to D?

  • 舊的行為:集合 D 已清除。Old behavior: Collection D is cleared. 主要項目不會針對屬性 OrderDetails 引發變更通知。The master item does not raise a change notification for property OrderDetails. ListBox 會繼續使用集合 D (它現在是空的)。The ListBox continues to use collection D, which is now empty.
  • 新的行為:系統不會變更集合 D。New behavior: Collection D is unchanged. 其每個項目都會針對 OrderID 屬性引發變更通知。Each of its items raises a change notification for the OrderID property. ListBox 會繼續使用集合 D,並以新的 OrderID 來顯示詳細資料。The ListBox continues to use collection D, and displays the details with the new OrderID. WPF 會透過以不同的方式建立集合 D 來實作新的行為,也就是搭配將 followParent 引數設定為 true 來呼叫 ADO 方法 DataRowView.CreateChildView(DataRelation, Boolean)WPF implements the new behavior by creating collection D in a different way: by calling the ADO method DataRowView.CreateChildView(DataRelation, Boolean) with the followParent argument set to true.

建議Suggestion

應用程式能透過使用下列 AppContext 參數來取得新的行為。An app gets the new behavior by using the following AppContext switch.

<configuration>
  <runtime>
    <AppContextSwitchOverrides value="Switch.System.Windows.Data.DoNotUseFollowParentWhenBindingToADODataRelation=false"/>
  </runtime>
</configuration>

針對以 .NET 4.7.1 或更舊版本為目標的應用程式,此參數的預設值為 true (舊行為),而針對以 .NET 4.7.2 或更新版本為目標的應用程式,預設值則為 false (新行為)。The switch defaults to true (old behavior) for apps that target .NET 4.7.1 or below, and to false (new behavior) for apps that target .NET 4.7.2 or above.

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

現在,當控制項沒有內容時,RadioButton 和 CheckBox 的 WPF 焦點視覺效果會正確顯示WPF FocusVisual for RadioButton and CheckBox Now Displays Correctly When The Controls Have No Content

詳細資料Details

在 .NET Framework 4.7.1 和舊版的傳統和高對比佈景主題中,WPF System.Windows.Controls.CheckBoxSystem.Windows.Controls.RadioButton 的焦點視覺效果不一致且不正確。In the .NET Framework 4.7.1 and earlier versions, WPF System.Windows.Controls.CheckBox and System.Windows.Controls.RadioButton have inconsistent and, in Classic and High Contrast themes, incorrect focus visuals. 當控制項沒有任何內容集時,會發生上述問題。These issues occur in cases where the controls do not have any content set. 這可能會讓人混淆佈景主題之間的轉換,也看不清楚焦點視覺效果。This can make the transition between themes confusing and the focus visual hard to see. 現在,.NET Framework 4.7.2 的這些視覺效果在各佈景主題之間會更一致;在傳統和高對比佈景主題中也可以看得更清楚。In the .NET Framework 4.7.2, these visuals are now more consistent across themes and more easily visible in Classic and High Contrast themes.

建議Suggestion

如果開發人員是以 .NET Framework 4.7.2 為目標,並想要還原為 .NET 4.7.1 的行為,則必須設定下列 AppContext 旗標。A developer targeting .NET Framework 4.7.2 that wants to revert to the behavior in .NET 4.7.1 will need to set the following AppContext flag.

<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.UseLegacyAccessibilityFeatures.2=true;"/>
</runtime>
</configuration>

如果開發人員想要利用這項變更,同時以 .NET 4.7.2 以下的 Framework 版本為目標,則必須設定下列 AppContext 旗標。請注意,所有旗標都必須正確設定,而且安裝的 .NET Framework 版本必須為 4.7.2 或更新版本。您必須具備 WPF 應用程式,才能選擇使用所有舊版的協助工具改進功能,並取得最新的改進功能。A developer who wants to utilize this change while targeting a framework version below .NET 4.7.2 must set the following AppContext flags.Note that all the flags must be set appropriately and the installed version of the .NET Framework must be 4.7.2 or greater.WPF applications are required to opt in to all earlier accessibility improvements to get the latest improvements. 若要這樣做,請確認 'Switch.UseLegacyAccessibilityFeatures' 和 'Switch.UseLegacyAccessibilityFeatures.2' 這兩個 AppContext 參數均設為 false。To do this, ensure that both the AppContext switches 'Switch.UseLegacyAccessibilityFeatures' and 'Switch.UseLegacyAccessibilityFeatures.2' are set to false.

<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.UseLegacyAccessibilityFeatures=false;Switch.UseLegacyAccessibilityFeatures.2=false;"/>
</runtime>
</configuration>
名稱Name Value
影響範圍Scope EdgeEdge
版本Version 4.7.24.7.2
類型Type 正在重定目標Retargeting

star-column 空間的 WPF 方格配置WPF Grid allocation of space to star-columns

詳細資料Details

從 .NET Framework 4.7 開始,WPF 取代了 Grid 用來配置 *-column 空間的演算法。Starting with the .NET Framework 4.7, WPF replaces the algorithm that Grid uses to allocate space to *-columns. 在以下幾種情況下,這會使指派給 *-column 的實際寬度產生變化:This will change the actual width assigned to *-columns in a number of cases:

  • 當一或多個資料 * 行的寬度下限或上限覆寫該上的比例配置時。When one or more *-columns also have a minimum or maximum width that overrides the proportional allocation for that colum. (寬度下限可能衍生自明確的 MinWidth 宣告,或衍生自從資料行的內容取得的隱含下限。(The minimum width can derive from an explicit MinWidth declaration, or from an implicit minimum obtained from the column's content. 寬度上限僅能明確地從 MaxWidth 宣告定義)。The maximum width can only be defined explicitly, from a MaxWidth declaration.)

  • 當一或多個 *-columns 宣告極大的 *-weight 時 (大於 10^298)。When one or more *-columns declare an extremely large *-weight, greater than 10^298.

  • 當 *-weights 的差異足以發生浮點不穩定 (溢位、反向溢位、精確度失準) 時。When the *-weights are sufficiently different to encounter floating-point instability (overflow, underflow, loss of precision).

  • 當版面配置進位已啟用,且有效顯示 DPI 夠高時。When layout rounding is enabled, and the effective display DPI is sufficiently high. 在前兩個狀況中,新演算法產生的寬度可能明顯不同於舊演算法產生的寬度;在最後一個狀況中,差異最多會是一或兩個像素。In the first two cases, the widths produced by the new algorithm can be significantly different from those produced by the old algorithm; in the last case, the difference will be at most one or two pixels.

    新的演算法修正了舊演算法中的數個錯誤:The new algorithm fixes several bugs present in the old algorithm:

  • 資料行的總配置可能會超過方格的寬度。Total allocation to columns can exceed the Grid's width. 資料行的按比例共用若低於其大小下限,配置空間時就可能發生這個狀況。This can occur when allocating space to a column whose proportional share is less than its minimum size. 此演算法會配置大小下限,因此,其他資料行的可用空間會減少。The algorithm allocates the minimum size, which decreases the space available to other columns. 如果沒有要配置的 *-columns,總配置將會過大。If there are no *-columns left to allocate, the total allocation will be too large.

  • 總配置的方格寬度可能會不足。Total allocation can fall short of the Grid's width. 這是第 1 點的雙重問題,在為資料行配置空間時,若其按比例共用超過大小上限,但缺少可使用剩餘空間的 *-columns 時,就會發生這個狀況。This is the dual problem to #1, arising when allocating to a column whose proportional share is greater than its maximum size, with no *-columns left to take up the slack.

  • 兩個 *-column 的配置可能不是依其 *-weight 按比例分配。Two *-columns can receive allocations not proportional to their *-weights. 相較於第 1 點/第 2 點,這是程度較輕的錯誤,在為 *-columns A、B 和 C (依此順序) 配置空間時,若 B 的按比例共用違反其下限 (或上限) 條件約束,就會發生這個狀況。This is a milder version of #1/#2, arising when allocating to *-columns A, B, and C (in that order), where B's proportional share violates its min (or max) constraint. 如上所述,這會使資料行 C 的可用的空間產生變化,可能會獲得較 A 更少 (或更多) 的比例配置,As above, this changes the space available to column C, who gets less (or more) proportional allocation than A did,

  • 權數極大 (> 10^298) 的資料行一律會視為擁有 10 ^298 的權數。Columns with extremely large weights (> 10^298) are all treated as if they had weight 10^298. 它們之間 (及權數較小的資料行之間) 的比例差異則可忽略。Proportional differences between them (and between columns with slightly smaller weights) are not honored.

  • 無法正確處理擁有無限權數的資料行。Columns with infinite weights are not handled correctly. [事實上,您無法將權數設為無限大,但這是人為限制。[Actually you can't set a weight to Infinity, but this is an artificial restriction. 配置程式碼會嘗試處理它,但成效不彰。]The allocation code was trying to handle it, but doing a bad job.]

  • 避免溢位、反向溢位時的幾個小問題、精確度失準及類似的浮點數問題。Several minor problems while avoiding overflow, underflow, loss of precision and similar floating-point issues.

  • 版面配置進位的調整在 DPI 足夠高的情況下不正確。Adjustments for layout rounding are incorrect at sufficiently high DPI. 新的演算法會產生符合下列準則的結果︰The new algorithm produces results that meet the following criteria:

    A.A. 指派給 *-column 的實際寬度永遠不會低於其寬度下限或高於其寬度上限。The actual width assigned to a *-column is never less than its minimum width nor greater than its maximum width.
    B.B. 未指派其最小值或最大寬度的每個資料行都會被指派寬度與其粗細的比例。若要精確地說,如果兩個資料行分別以寬度 x 和 y宣告,而且兩個數據行都沒有收到其最小或最大寬度,則指派給資料行的實際寬度 v 和 w 的比例相同: v/w = = x/y。Each -column that is not assigned its minimum or maximum width is assigned a width proportional to its -weight. To be precise, if two columns are declared with width x and y respectively, and if neither column receives its minimum or maximum width, the actual widths v and w assigned to the columns are in the same proportion: v / w == x / y.
    C.C. 配置給多層式資料行的總寬度, " " * 等於配置給條件約束資料行之後可用的空間 (固定、自動和資料行,這些資料行會配置給它們的 * 最小或最大寬度) 。The total width allocated to "proportional" *-columns is equal to the space available after allocating to the constrained columns (fixed, auto, and *-columns that are allocated their min or max width). 這可能是零,例如,若寬度下限的總和超過方格可用的寬度。This might be zero, for instance if the sum of the minimum widths exceeds the Grid's available width.
    D.D. 以上所述是就「理想」的版面配置而言。All these statements are to be interpreted with respect to the "ideal" layout. 當版面配置進位作用中時,實際寬度與理想寬度最多會相差一個像素。When layout rounding is in effect, the actual widths can differ from the ideal widths by as much as one pixel.
    舊的演算法能實現 (A) 準則,卻無法實現上述狀況中的其他準則。The old algorithm honored (A) but failed to honor the other criteria in the cases outlined above.

    本文中有關資料行和寬度的所有內容也適用於資料列和高度。Everything said about columns and widths in this article applies as well to rows and heights.

建議Suggestion

根據預設,以 .NET Framework 4.7 開始的 .NET Framework 版本為目標的應用程式會看見新的演算法,而以 .NET Framework 4.6.2 或更舊版本為目標的應用程式會看見舊的演算法。By default, apps that target versions of the .NET Framework starting with the .NET Framework 4.7 will see the new algorithm, while apps that target the .NET Framework 4.6.2 or earlier versions will see the old algorithm.

若要覆寫預設值,請使用下列組態設定︰To override the default, use the following configuration setting:

<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Controls.Grid.StarDefinitionsCanExceedAvailableSpace=true" />
</runtime>

true 會選取舊的演算法,false 會選取新的演算法。The value true selects the old algorithm, false selects the new algorithm.

名稱Name Value
範圍Scope MinorMinor
版本Version 4.74.7
類型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

WPF 指標式觸控堆疊WPF Pointer-Based Touch Stack

詳細資料Details

這項變更將能夠啟用選用的 WM_POINTER 式 WPF 觸控/手寫筆堆疊。This change adds the ability to enable an optional WM_POINTER based WPF touch/stylus stack. 開發人員若未明確地啟用此項目,應該不會看到任何 WPF 觸控/手寫筆行為的變更。以下是選用之 WM_POINTER 式觸控/手寫筆堆疊的目前已知問題:Developers that do not explicitly enable this should see no change in WPF touch/stylus behavior.Current Known Issues With optional WM_POINTER based touch/stylus stack:

  • 不支援即時筆跡。No support for real-time inking.
  • 雖然筆跡和手寫筆外掛程式還能運作,但它們是在 UI 執行緒上處理,可能會導致效能不佳。While inking and StylusPlugins will still work, they will be processed on the UI Thread which can lead to poor performance.
  • 從觸控/手寫筆事件提升為滑鼠事件的變更,因而產生行為變更Behavioral changes due to changes in promotion from touch/stylus events to mouse events
  • 操作可能有不同的行為Manipulation may behave differently
  • 拖放動作無法對觸控輸入顯示適當的回應Drag/Drop will not show appropriate feedback for touch input
  • 這不影響手寫筆輸入This does not affect stylus input
  • 無法再針對觸控/手寫筆事件起始拖放動作Drag/Drop can no longer be initiated on touch/stylus events
  • 這可能會使應用程式停止回應到偵測到滑鼠輸入為止。This can potentially hang the application until mouse input is detected.
  • 開發人員應改為從滑鼠事件起始拖放動作。Instead, developers should initiate drag and drop from mouse events.

建議Suggestion

想要啟用此堆疊的開發人員可以將以下內容新增/合併至其應用程式的 App.config 檔案:Developers who wish to enable this stack can add/merge the following to their application's App.config file:

<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Input.Stylus.EnablePointerSupport=true"/>
</runtime>
</configuration>

移除此項目或將其值設為 false 可關閉這個選用堆疊。請注意,此堆疊僅適用於 Windows 10 Creators Update 和更新版本。Removing this or setting the value to false will turn this optional stack off.Note that this stack is available only on Windows 10 Creators Update and above.

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

WPF 文字方塊/PasswordBox 文字選取範圍不遵循系統色彩WPF TextBox/PasswordBox Text Selection Does Not Follow System Colors

詳細資料Details

在 .NET Framework 4.7.1 和舊版中,WPF System.Windows.Controls.TextBoxSystem.Windows.Controls.PasswordBox 只能在 Adorner 圖層轉譯文字選取項目。In .NET Framework 4.7.1 and earlier versions, WPF System.Windows.Controls.TextBox and System.Windows.Controls.PasswordBox could only render a text selection in the Adorner layer. 在某些系統佈景主題中,這會遮擋文字,讓它變得更難讀取。In some system themes this would occlude text, making it hard to read. 在 .NET Framework 4.7.2 和更新版本中,開發人員可以選擇非 Adorner 型的選取項目轉譯配置來減輕這個問題。In .NET Framework 4.7.2 and later, developers have an option of enabling a non-Adorner-based selection rendering scheme that alleviates this issue.

建議Suggestion

想要利用這項變更的開發人員必須適當設定下列 AppContext 旗標。A developer who wants to utilize this change must set the following AppContext flag appropriately. 若要利用這項功能,已安裝的 .NET Framework 版本必須是 4.7.2 或更高。若要啟用非 Adorner 型的選取項目,請使用下列 AppContext 旗標。To utilize this feature, the installed .NET Framework version must be 4.7.2 or greater.To enabled the non-adorner-based selection, use the following AppContext flag.

<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Controls.Text.UseAdornerForTextboxSelectionRendering=false"/>
</runtime>
</configuration>

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

Windows Workflow Foundation (WF)Windows Workflow Foundation (WF)

Windows Workflow Foundation (WF) 工作流程設計工具中的協助工具改善Accessibility improvements in Windows Workflow Foundation (WF) workflow designer

詳細資料Details

Windows Workflow Foundation (WF) 工作流程設計工具正在使用協助工具技術改善其運作方式。The Windows Workflow Foundation (WF) workflow designer is improving how it works with accessibility technologies. 這些改善包括下列變更:These improvements include the following changes:

  • 在某些控制項中,定位順序變更為由左至右及由上至下:The tab order is changed to left to right and top to bottom in some controls:
  • 設定 InitializeCorrelation 活動之關聯性資料的初始化關聯性視窗The initialize correlation window for setting correlation data for the InitializeCorrelation activity
  • ReceiveSendSendReplyReceiveReply 活動的內容定義視窗The content definition window for the Receive, Send, SendReply, and ReceiveReply activities
  • 可透過鍵盤使用多個功能:More functions are available via the keyboard:
  • 編輯活動的屬性時,如果第一次將焦點放在屬性群組,可以透過鍵盤將其摺疊。When editing the properties of an activity, property groups can be collapsed by keyboard the first time they are focused.
  • 現在可透過鍵盤存取警告圖示。Warning icons are now accessible by keyboard.
  • 現在可透過鍵盤存取 [屬性] 視窗中的 [其他屬性] 按鈕。The More Properties button in the Properties window is now accessible by keyboard.
  • 鍵盤使用者現在可以存取工作流程設計工具之 [引數] 和 [變數] 窗格中的標頭項目。Keyboard users now can access the header items in the Arguments and Variables panes of the Workflow Designer.
  • 在以下這類情況發生時,已改善具有焦點之項目的可見性:Improved visibility of items with focus, such as when:
  • 在工作流程設計工具與活動設計工具所使用的資料格中新增資料列。Adding rows to data grids used by the Workflow Designer and activity designers.
  • 使用 Tab 鍵循環顯示 ReceiveReplySendReply 活動的欄位。Tabbing through fields in the ReceiveReply and SendReply activities.
  • 設定變數或引數的預設值Setting default values for variables or arguments
  • 螢幕助讀程式現在可以正確辨識:Screen readers can now correctly recognize:
  • 工作流程設計工具中設定的中斷點。Breakpoints set in the workflow designer.
  • FlowSwitch<T>FlowDecisionCorrelationScope 活動。The FlowSwitch<T>, FlowDecision, and CorrelationScope activities.
  • Receive 活動的內容。The contents of the Receive activity.
  • InvokeMethod 活動的目標類型。The Target Type for the InvokeMethod activity.
  • TryCatch 活動中的例外狀況下拉式方塊和 Finally 區段。The Exception combobox and the Finally section in the TryCatch activity.
  • 傳訊活動 (ReceiveSendSendReplyReceiveReply) 中的 [訊息類型] 下拉式方塊、[新增關聯性初始設定式] 視窗、[內容定義] 視窗和 [CorrelatesOn 定義] 視窗。The Message Type combobox, the splitter in the Add Correlation Initializers window, the Content Definition window, and the CorrelatesOn Defintion window in the messaging activities (Receive, Send, SendReply, and ReceiveReply).
  • 狀態機器轉換和轉換目的地。State machine transitions and transitions destinations.
  • FlowDecision 活動的註釋和連接器。Annotations and connectors on FlowDecision activities.
  • 活動的操作 (右鍵) 功能表。The context (right-click) menus for activities.
  • 屬性方格中的屬性值編輯器、[清除搜尋] 按鈕、[依分類] 及 [字母順序] 排序按鈕和 [運算式編輯器] 對話方塊。The property value editors, the Clear Search button, the By Category and Alphabetical sort buttons, and the Expression Editor dialog in the properties grid.
  • 工作流程設計工具中的顯示比例百分比。The zoom percentage in the Workflow Designer.
  • ParallelPick 活動中的分隔符號。The separator in Parallel and Pick activities.
  • InvokeDelegate 活動。The InvokeDelegate activity.
  • 字典活動 (Microsoft.Activities.AddToDictionary&lt;TKey,TValue>Microsoft.Activities.RemoveFromDictionary&lt;TKey,TValue> 等) 的 [選取類型] 視窗。The Select Types window for dictionary activities (Microsoft.Activities.AddToDictionary&lt;TKey,TValue>, Microsoft.Activities.RemoveFromDictionary&lt;TKey,TValue>, etc.).
  • [瀏覽並選取 .NET 類型] 視窗。The Browse and Select .NET Type window.
  • 工作流程設計工具中的階層連結。Breadcrumbs in the Workflow Designer.
  • 選擇高對比佈景主題的使用者會看到工作流程設計工具和其控制項在可見性方面的許多改善,例如項目之間的更佳對比比例以及用於焦點項目的更明顯選取方塊。Users who choose High Contrast themes will see many improvements in the visibility of the Workflow Designer and its controls like better contrast ratios between elements and more noticeable selection boxes used for focus elements.

建議Suggestion

如果您使用已重新裝載工作流程設計工具的應用程式,藉由執行上述其中一個動作,您的應用程式可以受益於這些變更:If you have an application with a re-hosted workflow designer, your application can benefit from these changes by performing either of these actions:

  • 重新編譯應用程式,使其以 .NET Framework 4.7.1 為目標。Recompile your application to target the .NET Framework 4.7.1. 預設會啟用這些協助工具變更。These accessibility changes are enabled by default.
  • 應用程式若以 .NET Framework 4.7 或舊版為目標,但卻在 .NET Framework 4.7.1 上執行,您可以在 app.config 檔案的 <runtime> 區段中新增下列 AppContext 參數,並將它設定為 false,選擇退出這些舊版協助工具行為,如下列範例所示。If your application targets the .NET Framework 4.7 or earlier but is running on the .NET Framework 4.7.1, you can opt out of these legacy accessibility behaviors by adding the following AppContext switch to the <runtime> section of the app.config file and set it to false, as the following example shows.
<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <startup>
    <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.7"/>
  </startup>
  <runtime>
    <!-- AppContextSwitchOverrides value attribute is in the form of 'key1=true/false;key2=true/false  -->
    <AppContextSwitchOverrides value="Switch.UseLegacyAccessibilityFeatures=false" />
  </runtime>
</configuration>

以 .NET Framework 4.7.1 或更新版本為目標,並且想要保留舊版協助工具行為的應用程式,可以藉由明確將此 AppContext 參數設為 true,選擇加入舊版的協助工具功能。Applications that target the .NET Framework 4.7.1 or later and want to preserve the legacy accessibility behavior can opt in to the use of legacy accessibility features by explicitly setting this AppContext switch to true.

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

避免 IWorkflowInstanceManagement.TransactedCancel 與 IWorkflowInstanceManagement.TransactedTerminate 的無止盡遞迴Avoiding endless recursion for IWorkflowInstanceManagement.TransactedCancel and IWorkflowInstanceManagement.TransactedTerminate

詳細資料Details

在某些情況下,若使用 IWorkflowInstanceManagement.TransactedCancelIWorkflowInstanceManagement.TransactedTerminate API 取消或終止工作流程服務執行個體,當 Workflow 執行階段因為處理要求的過程,而嘗試保有該服務執行個體時,工作流程執行個體可能會出現因為無止盡遞迴而發生堆疊溢位。Under some circumstances when using IWorkflowInstanceManagement.TransactedCancel or IWorkflowInstanceManagement.TransactedTerminate APIs to cancel or terminate a workflow service instance, the workflow instance may encounter a stack overflow due to endless recursion when the Workflow runtime attempts to persist the service instance as part of processing the request. 如果工作流程實例的狀態是正在等候其他服務的其他未完成 WCF 要求完成,就會發生此問題。The problem occurs if the workflow instance is in a state where it is waiting for some other outstanding WCF request to another service to complete. TransactedCancelTransactedTerminate 作業會建立針對工作流程服務實例排入佇列的工作專案。The TransactedCancel and TransactedTerminate operations create work items that are queued for the workflow service instance. 處理 TransactedCancel/TransactedTerminate 要求的過程中,不會執行這些工作項目。These work items are not executed as part of the processing of the TransactedCancel/TransactedTerminate request. 因為工作流程服務執行個體正忙於等候其他未完成的 WCF 要求完成,所以建立的工作項目會維持在佇列中。Because the workflow service instance is busy waiting for the other outstanding WCF request to complete, the work item created remains queued. TransactedCancel/TransactedTerminate 作業已完成,且控制權已回到用戶端。The TransactedCancel/TransactedTerminate operation completes and control is returned back to the client. 當交易與嘗試認可的 TransactedCancel/TransactedTerminate 作業相關聯時,它需要保有該工作流程服務執行個體的狀態。When the transaction associated with the TransactedCancel/TransactedTerminate operation attempts to commit, it needs to persist the workflow service instance state. 但因為執行個體仍有未完成的 WCF要求,所以工作流程執行階段無法保有該工作流程服務執行個體,因而發生無止盡的遞迴迴圈而導致堆疊溢位。因為 TransactedCancelTransactedTerminate 只會在記憶體中建立工作項目,所以交易存在的事實並沒有任何影響。But because there is an outstanding WCF request for the instance, the Workflow runtime cannot persist the workflow service instance, and an endless recursion loop leads to the stack overflow.Because TransactedCancel and TransactedTerminate only create a work item in memory, the fact that a transaction exists doesn't have any effect. 復原交易並不會捨棄該工作項目。為解決此問題,從 .NET Framework 4.7.2 起已引進了 AppSetting,其可新增至工作流程服務的 web.config/app.config,告知它可忽略 TransactedCancelTransactedTerminate 的交易。A rollback of the transaction does not discard the work item.To address this issue, starting in .NET Framework 4.7.2, we have introduced an AppSetting that can be added to the web.config/app.config of the workflow service that tells it to ignore transactions for TransactedCancel and TransactedTerminate. 這可讓交易認可,而不需要等待工作流程實例保存。This allows the transaction to commit without waiting for the workflow instance to persist. 這項功能的 AppSetting 名為 microsoft:WorkflowServices:IgnoreTransactionsForTransactedCancelAndTransactedTerminateThe AppSetting for this feature is named microsoft:WorkflowServices:IgnoreTransactionsForTransactedCancelAndTransactedTerminate. true 表示應忽略該交易,以避免堆疊溢位。A value of true indicates that the transaction should be ignored, thus avoiding the stack overflow. 此 AppSetting 的預設值為 false,因此不會影響現有的工作流程服務執行個體。The default value of this AppSetting is false, so existing workflow service instances are not affected.

建議Suggestion

若目前使用 AppFabric 或另一個 IWorkflowInstanceManagement 用戶端,且在嘗試取消或終止工作流程執行個體時,在工作流程服務執行個體中發生了堆疊溢位,您可以將下列內容加入工作流程服務的 web.config/app.config 檔案之 <appSettings> 區段中:If you are using AppFabric or another IWorkflowInstanceManagement client and are encountering a stack overflow in the workflow service instance when trying to cancel or terminate a workflow instance, you can add the following to the <appSettings> section of the web.config/app.config file for the workflow service:

<add key="microsoft:WorkflowServices:IgnoreTransactionsForTransactedCancelAndTransactedTerminate" value="true"/>

若未遇到問題,則不需要執行這項動作。If you are not encountering the problem, you do not need to do this.

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

工作流程總和檢查碼從 MD5 變更為 SHA1Workflow checksums changed from MD5 to SHA1

詳細資料Details

為了支援使用 Visual Studio 進行偵錯,工作流程執行階段會使用雜湊演算法為工作流程執行個體產生總和檢查碼。To support debugging with Visual Studio, the Workflow runtime generates a checksum for a workflow instance using a hashing algorithm. 在 .NET Framework 4.6.2 和更早版本中,工作流程總和檢查碼雜湊使用 MD5 演算法,它會在啟用 FIPS 的系統上造成問題。In the .NET Framework 4.6.2 and earlier versions, workflow checksum hashing used the MD5 algorithm, which caused issues on FIPS-enabled systems. 從 .NET Framework 4.7 開始,演算法是 SHA1。Starting with the .NET Framework 4.7, the algorithm is SHA1. 如果您的程式碼已保存這些總和檢查碼,就會不相容。If your code has persisted these checksums, they will be incompatible.

建議Suggestion

如果您的程式碼因為總和檢查碼失敗而無法載入工作流程執行個體,請嘗試將 AppContext 參數 "Switch.System.Activities.UseMD5ForWFDebugger" 設為 true。在程式碼中:If your code is unable to load workflow instances due to a checksum failure, try setting the AppContext switch "Switch.System.Activities.UseMD5ForWFDebugger" to true.In code:

System.AppContext.SetSwitch("Switch.System.Activities.UseMD5ForWFDebugger", true);

或者,在組態中:Or in configuration:

<configuration>
  <runtime>
    <AppContextSwitchOverrides value="Switch.System.Activities.UseMD5ForWFDebugger=true" />
  </runtime>
</configuration>
名稱Name Value
影響範圍Scope MinorMinor
版本Version 4.74.7
類型Type 正在重定目標Retargeting

符號的工作流程 XAML 總和檢查碼從 SHA1 變更為 SHA256Workflow XAML checksums for symbols changed from SHA1 to SHA256

詳細資料Details

為了支援 Visual Studio 偵錯,工作流程執行階段會使用雜湊演算法為工作流程 XAML 檔案產生總和檢查碼。To support debugging with Visual Studio, the Workflow runtime generates a checksum for a workflow XAML file using a hashing algorithm. 在 .NET Framework 4.6.2 和更早版本中,工作流程總和檢查碼雜湊使用 MD5 演算法,它會在啟用 FIPS 的系統上造成問題。In the .NET Framework 4.6.2 and earlier versions, workflow checksum hashing used the MD5 algorithm, which caused issues on FIPS-enabled systems. 從 .NET Framework 4.7 開始,預設的演算法已變更為 SHA1。Starting with the .NET Framework 4.7, the default algorithm was changed to SHA1. 從 .NET Framework 4.8 開始,預設的演算法已變更為 SHA256。Starting with the .NET Framework 4.8, the default algorithm was changed to SHA256.

建議Suggestion

如果您的程式碼因為總和檢查碼失敗而無法載入工作流程實例或尋找適當的符號,請嘗試將參數設定為「 AppContext Switch.System。UseSHA1HashForDebuggerSymbols "to trueIf your code is unable to load workflow instances or to find appropriate symbols due to a checksum failure, try setting the AppContext switch "Switch.System.Activities.UseSHA1HashForDebuggerSymbols" to true. 在程式碼中:In code:

System.AppContext.SetSwitch("Switch.System.Activities.UseSHA1HashForDebuggerSymbols", true);

或者,在組態中:Or in configuration:

<configuration>
  <runtime>
    <AppContextSwitchOverrides value="Switch.System.Activities.UseSHA1HashForDebuggerSymbols=true" />
  </runtime>
</configuration>
名稱Name Value
影響範圍Scope MinorMinor
版本Version 4.84.8
類型Type 正在重定目標Retargeting

工作流程 XOML 定義和 SqlTrackingService 快取索引鍵已從 MD5 變更為 SHA256Workflow XOML definition and SqlTrackingService cache keys changed from MD5 to SHA256

詳細資料Details

工作流程執行階段會保留 XOML 中定義之工作流程定義的快取。The Workflow Runtime in keeps a cache of workflow definitions defined in XOML. SqlTrackingService 也會保留以字串作為索引鍵的快取。The SqlTrackingService also keeps a cache that is keyed by strings. 這些快取會依包含總和檢查碼雜湊值的值作為索引鍵。These caches are keyed by values that include checksum hash value. 在 .NET Framework 4.7.2 及更早版本中,這個總和檢查碼雜湊會使用 MD5 演算法,它會在啟用 FIPS 的系統上造成問題。In the .NET Framework 4.7.2 and earlier versions, this checksum hashing used the MD5 algorithm, which caused issues on FIPS-enabled systems. 從 .NET Framework 4.8 開始,使用的演算法是 SHA256。這項變更應該不會有相容性問題,因為每次工作流程執行時間和 SqlTrackingService 啟動時,都會重新計算這些值。Starting with the .NET Framework 4.8, the algorithm used is SHA256.There shouldn't be a compatibility issue with this change because the values are recalculated each time the Workflow Runtime and SqlTrackingService is started. 不過,如有需要,我們也提供可讓客戶還原回使用舊版雜湊演算法的方式。However, we have provided quirks to allow customers to revert back to usage of the legacy hashing algorithm, if necessary.

建議Suggestion

如果這項變更在執行工作流程時會造成問題,請嘗試設定其中一個 AppContext 參數 (或兩者):If this change presents a problem when executing workflows, try setting one or both of the AppContext switches:

  • "Switch.System.Workflow.Runtime.UseLegacyHashForWorkflowDefinitionDispenserCacheKey" 設為 True。"Switch.System.Workflow.Runtime.UseLegacyHashForWorkflowDefinitionDispenserCacheKey" to true.
  • "Switch.System.Workflow.Runtime.UseLegacyHashForSqlTrackingCacheKey" 設為 True."Switch.System.Workflow.Runtime.UseLegacyHashForSqlTrackingCacheKey" to true. 在程式碼中:In code:
System.AppContext.SetSwitch("Switch.System.Workflow.Runtime.UseLegacyHashForWorkflowDefinitionDispenserCacheKey", true);
System.AppContext.SetSwitch("Switch.System.Workflow.Runtime.UseLegacyHashForSqlTrackingCacheKey", true);

或在組態檔中 (必須位於建立 WorkflowRuntime 物件之應用程式的組態檔中):Or in the configuration file (this needs to be in the config file for the application that is creating the WorkflowRuntime object):

<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.System.Workflow.Runtime.UseLegacyHashForWorkflowDefinitionDispenserCacheKey=true" />
<AppContextSwitchOverrides value="Switch.System.Workflow.Runtime.UseLegacyHashForSqlTrackingCacheKeytrue" />
</runtime>
</configuration>
名稱Name Value
影響範圍Scope MinorMinor
版本Version 4.84.8
類型Type 正在重定目標Retargeting

工作流程 XOML 檔案總和檢查碼已從 MD5 變更為 SHA256Workflow XOML file checksums changed from MD5 to SHA256

詳細資料Details

為了支援搭配 Visual Studio 偵錯 XOML 式的工作流程,建置包含 XOML 檔案的工作流程專案時,XOML 檔案內容的總和檢查碼會作為 WorkflowMarkupSourceAttribute.MD5Digest 值包含在所產生程式碼中。To support debugging XOML-based workflows with Visual Studio, when workflow projects containing XOML files build, a checksum of the contents of the XOML file is included in the code generated as a WorkflowMarkupSourceAttribute.MD5Digest value. 在 .NET Framework 4.7.2 及更早版本中,這個總和檢查碼雜湊會使用 MD5 演算法,它會在啟用 FIPS 的系統上造成問題。In the .NET Framework 4.7.2 and earlier versions, this checksum hashing used the MD5 algorithm, which caused issues on FIPS-enabled systems. 從 .NET Framework 4.8 開始,所使用的演算法是 SHA256。Starting with the .NET Framework 4.8, the algorithm used is SHA256. 為了與 WorkflowMarkupSourceAttribute.MD5Digest 相容,只會使用所產生總和檢查碼的前 16 個位元組。這可能會在偵錯時造成問題。To be compatible with the WorkflowMarkupSourceAttribute.MD5Digest, only the first 16 bytes of the generated checksum are used.This may cause problems during debugging. 您可能需要重新建置您的專案。You may need to re-build your project.

建議Suggestion

若重新建置您的專案沒有解決問題,請嘗試將 AppContext 切換 "Switch.System.Workflow.ComponentModel.UseLegacyHashForXomlFileChecksum" 設為 True。在程式碼中:If re-building your project does not solve the problem, try setting the AppContext switch "Switch.System.Workflow.ComponentModel.UseLegacyHashForXomlFileChecksum" to true.In code:

System.AppContext.SetSwitch("Switch.System.Workflow.ComponentModel.UseLegacyHashForXomlFileChecksum", true);

或是在組態檔內 (這需要在您所使用 MSBuild.exe 的 MSBuild.exe.config 中):Or in a configuration file (this needs to be in MSBuild.exe.config for the MSBuild.exe that you are using):

<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.System.Workflow.ComponentModel.UseLegacyHashForXomlFileChecksum=true" />
</runtime>
</configuration>
名稱Name Value
範圍Scope MinorMinor
版本Version 4.84.8
類型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