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

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

ASP.NETASP.NET

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

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

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

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

詳細資料Details

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

建議Suggestion

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

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

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

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

受影響的 APIAffected APIs

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

詳細資料Details

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

建議Suggestion

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

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

長路徑支援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

路徑冒號檢查更嚴格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

安全性Security

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

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

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

使用可重新進入服務時,可能會造成死結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

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

使用 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 傳輸安全性支援使用 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

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

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

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

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

詳細資料Details

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

建議Suggestion

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

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

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

詳細資料Details

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

建議Suggestion

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

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

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

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