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

如果您想從 .NET Framework 4.6.2 移轉至 4.7.1,請檢閱下列主題中可能會影響應用程式的應用程式相容性問題:If you are migrating from the .NET Framework 4.6.2 to 4.7.1, 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

HttpRuntime.AppDomainAppPath 擲回 NullReferenceExceptionHttpRuntime.AppDomainAppPath Throws a NullReferenceException

詳細資料Details

在 .NET Framework 4.6.2 中,執行階段在擷取包含 null 字元的 P:System.Web.HttpRuntime.AppDomainAppPath 值時,會擲回 T:System.NullReferenceException。在 .NET Framework 4.6.1 和更早版本中,執行階段會擲回 T:System.ArgumentNullExceptionIn the .NET Framework 4.6.2, the runtime throws a T:System.NullReferenceException when retrieving a P:System.Web.HttpRuntime.AppDomainAppPath value that includes null characters.In the .NET Framework 4.6.1 and earlier versions, the runtime throws an T:System.ArgumentNullException.

建議Suggestion

您可以執行下列其中一個動作以回應這項變更︰You can do either of the follow to respond to this change:

  • 如果您的應用程式是在 .NET Framework 4.6.2 上執行,請處理 T:System.NullReferenceExceptionHandle the T:System.NullReferenceException if you application is running on the .NET Framework 4.6.2.
  • 升級至 .NET Framework 4.7,這可以還原舊版行為並擲回 T:System.ArgumentNullExceptionUpgrade to the .NET Framework 4.7, which restores the previous behavior and throws an T:System.ArgumentNullException.
名稱Name Value
影響範圍Scope EdgeEdge
版本Version 4.6.24.6.2
類型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

核心Core

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

網路Networking

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

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

安全性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

SignedXml.GetPublicKey RSACng 會在 net462 (或 lightup) 上傳回 RSACng,而無重定目標變更SignedXml.GetPublicKey returns RSACng on net462 (or lightup) without retargeting change

詳細資料Details

從 .NET Framework 4.6.2 開始,SignedXml.GetPublicKey 方法所傳回的物件具象類型 (毫不奇怪地) 從 CryptoServiceProvider 實作變更為 Cng 實作。Starting with the .NET Framework 4.6.2, the concrete type of the object returned by the SignedXml.GetPublicKey method changed (without a quirk) from a CryptoServiceProvider implementation to a Cng implementation. 這是因為實作從使用 certificate.PublicKey.Key 變更為使用內部 certificate.GetAnyPublicKey,它會轉送給 RSACertificateExtensions.GetRSAPublicKeyThis is because the implementation changed from using certificate.PublicKey.Key to using the internal certificate.GetAnyPublicKey which forwards to RSACertificateExtensions.GetRSAPublicKey.

建議Suggestion

從在 .NET Framework 4.7.1 上執行的應用程式開始,您可以使用 .NET Framework 4.6.1 和更早版本中預設使用的 CryptoServiceProvider 實作,方法是將下列設定參數新增至您應用程式設定檔的 runtime 區段:Starting with apps running on the .NET Framework 4.7.1, you can use the CryptoServiceProvider implementation used by default in the .NET Framework 4.6.1 and earlier versions by adding the following configuration switch to the runtime section of your app config file:

<AppContextSwitchOverrides value="Switch.System.Security.Cryptography.Xml.SignedXmlUseLegacyCertificatePrivateKey=true" />
名稱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)

某些 .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

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

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

Windows FormsWindows Forms

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

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

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

詳細資料Details

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

建議Suggestion

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

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

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

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

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

工作流程總和檢查碼從 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