閱讀英文

共用方式為


.NET Framework 的新功能

注意

.NET Framework 的服務是獨立於 Windows 更新的,並提供安全性及可靠性漏洞修正。 一般而言,安全性更新會每季發行一次。 .NET Framework 將繼續隨附於 Windows 中,且沒有移除它的計劃。 您不需要移轉 .NET Framework 應用程式,但若要進行新的開發,請使用 .NET 8 或更新版本

本文摘要說明下列 .NET Framework 版本中的重要新功能和改進:

本文不提供每個新功能的完整資訊,而且可能會有所變更。 如需 .NET Framework 的一般資訊,請參閱 用戶入門。 如需支援的平臺,請參閱 系統需求。 如需下載連結和安裝指示,請參閱 安裝指南

注意

.NET Framework 小組也會使用 NuGet 在頻外發行功能,以擴充平臺支援並引進新功能,例如不可變的集合和已啟用 SIMD 的向量類型。 如需詳細資訊,請參閱 其他類別庫和 API.NET Framework 和頻外版本。 請參閱適用於 .NET Framework NuGet 套件的完整清單

.NET Framework 4.8.1 簡介

.NET Framework 4.8.1 是以舊版 .NET Framework 4.x 為基礎,新增許多新的修正程式和數個新功能,同時維持非常穩定的產品。

下載並安裝 .NET Framework 4.8.1

您可以從下列位置下載 .NET Framework 4.8.1:

.NET Framework 4.8 可以安裝在 Windows 11、Windows 10 版本 21H2、Windows 10 版本 21H1、Windows 10 版本 20H2,以及從 Windows Server 2022 開始的對應伺服器平臺。 您可以使用 Web 安裝程式或離線安裝程式來安裝 .NET Framework 4.8.1。 大部分用戶的建議方式是使用 Web 安裝程式。

您可以透過安裝 .NET Framework 4.8.1 Developer Pack,在 Visual Studio 2022 17.3 或更高版本中將開發目標設為 .NET Framework 4.8.1。

.NET Framework 4.8.1 的新功能

.NET Framework 4.8.1 會在下列領域引進新功能:

改善的輔助功能,可讓應用程式為輔助技術的使用者提供適當的體驗,是 .NET Framework 4.8.1 的主要焦點。 如需 .NET Framework 4.8.1 中輔助功能改進的資訊,請參閱 .NET Framework 中的輔助功能新特性

.NET Framework 4.8.1 會將原生 Arm64 支援新增至 .NET Framework 系列。 因此,您對大量 .NET Framework 應用程式和連結庫生態系統的投資現在可以利用在Arm64上原生執行工作負載的優點,也就是相較於在Arm64上仿真的 x64 程式代碼,效能更好。

Microsoft致力於提供可供所有人存取 的產品和平臺。 .NET Framework 4.8.1 提供兩個 Windows UI 開發平臺,兩者都提供開發人員建立無障礙應用程式所需的支援。 在過去數個版本中,Windows Forms 和 WPF 都新增了新功能,並修正了許多與輔助功能相關的可靠性問題。 您可以訪問 .NET Framework 的輔助功能更新,以了解每個版本中已修正或新增項目的詳細資訊

在此版本中,Windows Forms 和 WPF 都已改善工具提示的處理,使其更容易存取。 在這兩種情況下,工具提示現在都符合 WCAG2.1 內容中暫留或聚焦 指引所述的指導方針。 工具提示的需求如下:

  • 工具提示必須透過滑鼠懸停或鍵盤導航至控制項來顯示。
  • 工具提示應該可關閉。 也就是說,像是 Esc 的簡單鍵盤命令應該會關閉工具提示。
  • 工具提示應該能在懸停時顯示。 用戶應該能夠將滑鼠游標放在工具提示上。 這使低視覺使用者能夠使用放大鏡來讀取工具提示。
  • 工具提示應該是持續性的。 工具提示不應在經過一段時間之後自動消失。 相反地,用戶應該將滑鼠移至另一個控件上或透過鍵盤命令來關閉工具提示。

在 Windows Forms 中,這項支援僅適用於 Windows 11 或更新版本的作業系統。 Windows Forms 是一個用來對 Windows API 進行包裝的輕量受控包,而新的工具提示行為僅在 Windows 11 中可用。 WPF 沒有可存取工具提示的作業系統版本相依性。

WPF 已在 .NET Framework 4.8 中實作 WCAG2.1 兼容工具提示的大部分需求。 在此版本中,WPF 改善了使用者體驗,確保目前視窗中的工具提示可以輕鬆地透過使用 Esc 鍵、單獨按下 Ctrl 鍵,或是組合按鍵 Ctrl+Shift+F10來關閉。 此版本中已減少逸出密鑰的範圍,只套用至目前的視窗。 以前它會套用至應用程式中任何開啟的工具提示。

Windows Forms 是針對 .NET Framework 建立的第一個 Windows UI 堆棧。 因此,它最初是為了利用舊版輔助功能技術而建立,但不符合目前的輔助功能需求。 在此版本中,Windows Forms 已解決許多問題。 如需輔助功能變更的完整清單,請瀏覽 .NET Framework 中的輔助功能新功能

.NET Framework 4.8.1 中的 Windows Forms 改善重點如下:

  • 文字模式支援– Windows Forms 新增了 UIA 文字模式的支援。 此模式可讓輔助技術逐字遍歷 TextBox 或類似的文字控制項的內容。 它可讓控件內的文字被選取和更改,並在游標處插入新的文字。 Windows Forms 新增了 TextBox、DataGridView 單元格、ComboBox 控制件等等的支援。

  • 解決對比問題 – 在數個控件中,Windows Forms 已將選取矩形的對比比例變更為較深且更可見。

  • 已修正數個 DataGridView 問題:

    • 滾動條名稱已更新為一致。
    • 朗讀程式現在能夠專注於空白的 DataGridView 單元格。
    • 開發人員可以為自訂的 DataGridView 儲存格設置本地化的控制類型屬性。
    • DataGridViewLink 單元格的連結色彩已更新為與背景有更好的對比。

.NET Framework 4.8 簡介

.NET Framework 4.8 是以舊版 .NET Framework 4.x 為基礎,新增許多新的修正和數項新功能,同時維持非常穩定的產品。

下載並安裝 .NET Framework 4.8

您可以從下列位置下載 .NET Framework 4.8:

.NET Framework 4.8 可以安裝在 Windows 10、Windows 8.1、Windows 7 SP1 和從 Windows Server 2008 R2 SP1 開始的對應伺服器平臺。 您可以使用 Web 安裝程式或離線安裝程式來安裝 .NET Framework 4.8。 大部分用戶的建議方式是使用 Web 安裝程式。

您可以在 Visual Studio 2012 或更新版本中將 .NET Framework 4.8 設為目標,方法是安裝 .NET Framework 4.8 Developer Pack

.NET Framework 4.8 的新功能

.NET Framework 4.8 引進下列領域的新功能:

改善的輔助功能,可讓應用程式為輔助技術的使用者提供適當的體驗,仍然是 .NET Framework 4.8 的主要焦點。 如需瞭解 .NET Framework 4.8 中輔助功能改善的詳情,請參閱 .NET Framework 中的輔助功能最新內容

基類

降低對密碼編譯的 FIPS 影響。 在舊版 .NET Framework 中,當系統加密函式庫設定為「FIPS 模式」時,管理的加密提供者類別(例如 SHA256Managed)會擲回 CryptographicException。 這些例外狀況會被拋出,因為受控版本的加密提供者類別與系統加密庫不同,未經過聯邦資訊處理標準(FIPS 140-2)認證。 由於很少有開發人員將他們的開發機器設定為 FIPS 模式,因此通常會在生產系統中投擲例外狀況。

根據預設,在以 .NET Framework 4.8 為目標的應用程式中,下列管理的加密類別在此情況下不再擲回 CryptographicException

相反地,這些類別會將密碼編譯作業重新導向至系統密碼編譯連結庫。 這項變更可有效地移除開發人員環境與生產環境之間的潛在混淆差異,並讓原生元件和受控元件在相同的密碼編譯原則下運作。 相依於這些例外狀況的應用程式可以藉由將AppContext 參數 Switch.System.Security.Cryptography.UseLegacyFipsThrow 設定為 true來還原先前的行為。 如需詳細資訊,請參閱 在 FIPS 模式中,受控密碼編譯類別不會擲回 CryptographyException

使用更新版本的 ZLib

從 .NET Framework 4.5 開始,clrcompression.dll 元件會使用 ZLib,這是用於數據壓縮的原始的外部函式庫,以提供 deflate 演算法的實作。 .NET Framework 4.8 版的 clrcompression.dll 已更新為採用 ZLib 1.2.11 版本,包含數個主要的改進和修正。

Windows Communication Foundation (WCF)

「ServiceHealthBehavior」簡介

協作工具廣泛使用健康端點,可依健康狀態管理服務。 監視工具也可以使用健康情況檢查來追蹤並提供服務可用性和效能的相關通知。

ServiceHealthBehavior 是擴充 IServiceBehavior的 WCF 服務行為。 新增至 ServiceDescription.Behaviors 集合時,服務行為會執行下列動作:

  • 傳回服務健康狀態及其對應的 HTTP 回應碼。 您可以在查詢字串中指定 HTTP/GET 健康情況探查要求的 HTTP 狀態代碼。

  • 發佈服務健康情況的相關信息。 服務特定的詳細信息,包括服務狀態、頻率限制計數和容量,可以透過 HTTP/GET 請求配合 ?health 查詢字串來顯示。 對 WCF 服務進行疑難解答時,輕鬆存取這類資訊非常重要。

有兩種方式可以公開健康情況端點,併發佈 WCF 服務健康情況資訊:

  • 透過代碼。 例如:

    ServiceHost host = new ServiceHost(typeof(Service1),
                       new Uri("http://contoso:81/Service1"));
    ServiceHealthBehavior healthBehavior =
        host.Description.Behaviors.Find<ServiceHealthBehavior>();
    healthBehavior ??= new ServiceHealthBehavior();
    host.Description.Behaviors.Add(healthBehavior);
    
  • 使用組態檔。 例如:

    <behaviors>
      <serviceBehaviors>
        <behavior name="DefaultBehavior">
          <serviceHealth httpsGetEnabled="true"/>
        </behavior>
      </serviceBehaviors>
    </behaviors>
    

您可以使用查詢參數來查詢服務的健全狀態,例如 OnServiceFailureOnDispatcherFailureOnListenerFailureOnThrottlePercentExceeded),以及每個查詢參數都可以指定 HTTP 回應碼。 如果查詢參數省略 HTTP 回應碼,預設會使用 503 HTTP 回應碼。 例如:

  • OnServiceFailure:https://contoso:81/Service1?health&OnServiceFailure=450

    當 serviceHost.State 大於 時,會傳回 450 HTTP 回應狀態代碼。

查詢參數和範例:

  • OnDispatcherFailure: https://contoso:81/Service1?health&OnDispatcherFailure=455

    當任何通道發送器的狀態大於 CommunicationState.Opened時,會傳回 455 HTTP 回應狀態代碼。

  • OnListenerFailure: https://contoso:81/Service1?health&OnListenerFailure=465

    當任何通道接聽程式的狀態大於 CommunicationState.Opened時,會傳回 465 HTTP 回應狀態代碼。

  • OnThrottlePercentExceeded: https://contoso:81/Service1?health&OnThrottlePercentExceeded= 70:350,95:500

    指定觸發回應及其 HTTP 回應碼 {200 – 599} 的百分比 {1 – 100}。 在這個例子中:

    • 如果百分比大於 95,則會傳回 500 HTTP 回應碼。

    • 如果百分比介於 70 到 95 之間,則會傳回 350。

    • 否則會傳回 200。

藉由指定類似 https://contoso:81/Service1?health 的查詢字串,或在 XML 中指定類似 https://contoso:81/Service1?health&Xml的查詢字串,即可以 HTML 顯示服務健康狀態。 查詢字串,例如 https://contoso:81/Service1?health&NoContent 會傳回空的 HTML 頁面。

Windows Presentation Foundation (WPF)

高 DPI 增強功能

在 .NET Framework 4.8 中,WPF 新增 Per-Monitor V2 DPI 感知和 Mixed-Mode DPI 縮放的支援。 如需高 DPI 開發的詳細資訊,請參閱 windows 上的 高 DPI 桌面應用程式開發。

.NET Framework 4.8 改進了在支援 Mixed-Mode DPI 縮放的平臺上,High-DPI WPF 應用程式中托管的 HWND 和 Windows Forms 互操作性的支持(始於 Windows 10 2018 年 4 月更新)。 當裝載的 HWND 或 Windows Forms 控制項透過呼叫 SetThreadDpiHostingBehaviorSetThreadDpiAwarenessContext建立為 Mixed-Mode DPI 縮放視窗時,它們可以裝載在 Per-Monitor V2 WPF 應用程式中,並適當調整大小及縮放。 這類託管內容不會以原始 DPI 顯示,而是操作系統會將託管內容調整為適當的大小。 Per-Monitor v2 DPI 感知模式的支援也允許在高 DPI 應用程式的原生視窗中嵌入(即作為父系)WPF 控制項。

若要啟用 Mixed-Mode 高 DPI 縮放比例的支援,您可以設定下列 AppContext 切換應用程式組態檔:

<runtime>
   <AppContextSwitchOverrides value = "Switch.System.Windows.DoNotScaleForDpiChanges=false; Switch.System.Windows.DoNotUsePresentationDpiCapabilityTier2OrGreater=false"/>
</runtime>

通用語言執行平台

.NET Framework 4.8 中的運行時間包含下列變更和改進:

JIT 編譯程式的改善。 .NET Framework 4.8 中的 Just-In-Time (JIT) 編譯程式是以 .NET Core 2.1 中的 JIT 編譯程式為基礎。 許多對 .NET Core 2.1 JIT 編譯程式所做的優化和所有 Bug 修正都包含在 .NET Framework 4.8 JIT 編譯程式中。

NGEN 改善。 運行時間已改善對 (NGEN)原生映像生成器映像的記憶體管理,從而使映像對應的數據不再駐留在記憶體中。 這樣可減少攻擊面,降低透過修改將要執行的記憶體來執行任意代碼的攻擊風險。

反惡意代碼掃描所有元件。 在舊版 .NET Framework 中,執行環境會使用 Windows Defender 或第三方防毒或反惡意軟體對從磁碟載入的所有組件進行掃描。 不過,像是透過 Assembly.Load(Byte[]) 方法從其他來源載入的元件,不會被掃描,可能含有未被偵測的惡意軟體。 從 Windows 10 上運行的 .NET Framework 4.8 開始,執行階段會觸發反惡意軟體解決方案進行掃描,這些解決方案會實作 反惡意軟體掃描介面(AMSI)

.NET Framework 4.7.2 的新功能

.NET Framework 4.7.2 包含下列領域的新功能:

.NET Framework 4.7.2 中不斷的重點是改善可及性,以便應用程式能為輔助技術的使用者提供適當的體驗。 如需了解 .NET Framework 4.7.2 中輔助功能的改進,請參閱 .NET Framework 輔助功能的新亮點

基類

.NET Framework 4.7.2 具有大量的密碼編譯增強功能、更好的 ZIP 封存解壓縮支援,以及其他收集 API。

RSA.Create 和 DSA.Create 的新重載方法

DSA.Create(DSAParameters)RSA.Create(RSAParameters) 方法可讓您在建立新的 DSARSA 索引鍵時提供關鍵參數。 它們可讓您取代程式代碼,如下所示:

// Before .NET Framework 4.7.2
using (RSA rsa = RSA.Create())
{
   rsa.ImportParameters(rsaParameters);
   // Other code to execute using the RSA instance.
}

類似以下代碼:

// Starting with .NET Framework 4.7.2
using (RSA rsa = RSA.Create(rsaParameters))
{
   // Other code to execute using the rsa instance.
}

DSA.Create(Int32)RSA.Create(Int32) 方法可讓您產生具有特定金鑰大小的新 DSARSA 金鑰。 例如:

using (DSA dsa = DSA.Create(2048))
{
   // Other code to execute using the dsa instance.
}

Rfc2898DeriveBytes 建構函式接受哈希演算法名稱

Rfc2898DeriveBytes 類別有三個新的建構函式,具有 HashAlgorithmName 參數,可識別衍生密鑰時要使用的 HMAC 演算法。 開發人員應該使用SHA-2型HMAC,而不是使用SHA-1,如SHA-256,如下列範例所示:

private static byte[] DeriveKey(string password, out int iterations, out byte[] salt,
                                out HashAlgorithmName algorithm)
{
   iterations = 100000;
   algorithm = HashAlgorithmName.SHA256;

   const int SaltSize = 32;
   const int DerivedValueSize = 32;

   using (Rfc2898DeriveBytes pbkdf2 = new Rfc2898DeriveBytes(password, SaltSize,
                                                             iterations, algorithm))
   {
      salt = pbkdf2.Salt;
      return pbkdf2.GetBytes(DerivedValueSize);
   }
}

暫時金鑰的支援

PFX 匯入可以選擇性地直接從記憶體載入私鑰,略過硬碟。 如果在 X509Certificate2 建構函式或 X509Certificate2.Import 方法的多載版本中指定新的 X509KeyStorageFlags.EphemeralKeySet 旗標,則私鑰將會載入為暫時密鑰。 這可防止在磁碟上看見密鑰。 然而:

  • 由於密鑰不會保存到磁碟,因此使用此旗標載入的憑證不是要新增至 X509Store 的好候選專案。

  • 以這種方式載入的密鑰幾乎一律會透過 Windows CNG 載入。 因此,呼叫端必須藉由呼叫擴充方法來存取私鑰,例如 憑證.GetRSAPrivateKey()X509Certificate2.PrivateKey 屬性無法運作。

  • 由於舊版 X509Certificate2.PrivateKey 屬性不適用於憑證,因此開發人員應該先執行嚴格的測試,再切換至暫時密鑰。

以程式自動化方式建立 PKCS#10 憑證簽署要求和 X.509 公鑰憑證

從 .NET Framework 4.7.2 開始,工作負載可以產生憑證簽署請求 (CSR),使得憑證請求的生成可以在現有工具中進行整合。 這在測試案例中經常很有用。

如需詳細資訊和程式代碼範例,請參閱 .NET 部落格中的<以程序設計方式建立 PKCS#10 憑證簽署要求和 X.509 公鑰憑證>。

新的 SignerInfo 成員

從 .NET Framework 4.7.2 開始,SignerInfo 類別會公開簽章的詳細資訊。 您可以擷取 System.Security.Cryptography.Pkcs.SignerInfo.SignatureAlgorithm 屬性的值,以判斷簽署者所使用的簽章演算法。 您可以呼叫 SignerInfo.GetSignature,以取得此簽署者的密碼編譯簽章複本。

在處置 CryptoStream 之後將封裝數據流保持開啟狀態

從 .NET Framework 4.7.2 開始,CryptoStream 類別有一個額外的建構函式,可讓 Dispose 不要關閉包裝的數據流。 若要在處置 CryptoStream 實例之後讓包裝數據流保持開啟,請呼叫新的 CryptoStream 建構函式,如下所示:

var cStream = new CryptoStream(stream, transform, mode, leaveOpen: true);

DeflateStream 中的 解壓縮變更

從 .NET Framework 4.7.2 開始,DeflateStream 類別中的解壓縮作業實作預設已變更為使用原生 Windows API。 一般而言,這會導致大幅提升效能。

針對以 .NET Framework 4.7.2 為目標的應用程式,預設會啟用使用 Windows API 進行解壓縮的支援。 以舊版 .NET Framework 為目標,但在 .NET Framework 4.7.2 下執行的應用程式,可以在應用程式組態檔中加入下列 AppContext 開關,以選擇使用此行為:

<AppContextSwitchOverrides value="Switch.System.IO.Compression.DoNotUseNativeZipLibraryForDecompression=false" />

其他集合 API

.NET Framework 4.7.2 會將一些新的 API 新增至 SortedSet<T>HashSet<T> 類型。 這些包括:

ConcurrentDictionary<TKey,TValue> 類別包含新多載的 AddOrUpdateGetOrAdd 方法,以便從字典中擷取值或在找不到時新增,並將值新增至字典或在已存在時更新。

public TValue AddOrUpdate<TArg>(TKey key, Func<TKey, TArg, TValue> addValueFactory, Func<TKey, TValue, TArg, TValue> updateValueFactory, TArg factoryArgument)

public TValue GetOrAdd<TArg>(TKey key, Func<TKey, TArg, TValue> valueFactory, TArg factoryArgument)

ASP.NET

支援 Web Forms 中的相依性插入

相依性注入(DI) 將物件與其相依性解耦,這樣一來,物件的程式碼就不必因為相依性的改變而需要修改。 開發以 .NET Framework 4.7.2 為目標 ASP.NET 應用程式時,您可以:

支援同一網站 Cookie

SameSite 防止瀏覽器在跨網站請求時傳送 Cookie。 .NET Framework 4.7.2 會新增 HttpCookie.SameSite 屬性,其值為 System.Web.SameSiteMode 列舉成員。 如果其值為 SameSiteMode.StrictSameSiteMode.Lax,ASP.NET 會將 SameSite 屬性新增至 set-cookie 標頭。 SameSite 支援適用於 HttpCookie 物件,以及 FormsAuthenticationSystem.Web.SessionState Cookie。

您可以為 HttpCookie 物件設定 SameSite,如下所示:

var c = new HttpCookie("secureCookie", "same origin");
c.SameSite = SameSiteMode.Lax;

您也可以修改 web.config 檔案,在應用程式層級設定 SameSite Cookie:

<system.web>
   <httpCookies sameSite="Strict" />
</system.web>

您可以修改 Web 組態檔,為 FormsAuthenticationSystem.Web.SessionState Cookie 新增 SameSite:

<system.web>
   <authentication mode="Forms">
      <forms cookieSameSite="Lax">
         <!-- ...   -->
      </forms>
   </authentication>
   <sessionState cookieSameSite="Lax"></sessionState>
</system.web>

聯網

HttpClientHandler 屬性的實作

.NET Framework 4.7.1 已將八個屬性新增至 System.Net.Http.HttpClientHandler 類別。 不過有兩個人投擲了PlatformNotSupportedException。 .NET Framework 4.7.2 現在提供這些屬性的實作。 屬性為:

SQLClient

對於 Azure Active Directory 的通用驗證和多重要素驗證之支援

越來越多的合規性和安全性需求需要許多客戶使用多重要素驗證 (MFA)。 此外,目前的最佳做法不鼓勵直接在連接字串中包含用戶密碼。 為了支援這些變更,.NET Framework 4.7.2 會藉由新增新的值 “Active Directory Interactive” 來擴充 SQLClient 連接字符串,讓現有的 “Authentication” 關鍵詞支援 MFA,並 Azure AD 驗證。 新的互動式方法支援原生和同盟的 Azure AD 使用者,以及 Azure AD 來賓使用者。 使用此方法時,SQL 資料庫支援 Azure AD 所強加的 MFA 驗證。 此外,驗證程式會要求用戶密碼,以遵守安全性最佳做法。

在舊版 .NET Framework 中,SQL 連線僅支援 SqlAuthenticationMethod.ActiveDirectoryPasswordSqlAuthenticationMethod.ActiveDirectoryIntegrated 選項。 這兩者都是非互動式 ADAL 通訊協定的一部分,不支援 MFA。 使用新的 SqlAuthenticationMethod.ActiveDirectoryInteractive 選項,SQL 連線能力支援 MFA 以及現有的驗證方法(密碼和整合式驗證),讓使用者以互動方式輸入用戶密碼,而不需要將密碼保存在連接字元串中。

如需詳細資訊和範例,請參閱 .NET 部落格中的

Always Encrypted 第 2 版 的支援

NET Framework 4.7.2 新增支援以安全區域為基礎的 Always Encrypted。 Always Encrypted 的原始版本是用戶端加密技術,其中加密密鑰永遠不會離開用戶端。 在記憶體保護區型 Always Encrypted 中,用戶端可以選擇性地將加密密鑰傳送至安全記憶體保護區,這是可視為 SQL Server 一部分的安全計算實體,但 SQL Server 程式代碼無法竄改。 為了支援使用保護區的 Always Encrypted,.NET Framework 4.7.2 將下列類型和成員新增至 System.Data.SqlClient 命名空間:

然後,應用程式組態檔會指定抽象類別 System.Data.SqlClient.SqlColumnEncryptionEnclaveProvider 的具體實作,以提供安全區提供者的功能。 例如:

<configuration>
  <configSections>
    <section name="SqlColumnEncryptionEnclaveProviders" type="System.Data.SqlClient.SqlColumnEncryptionEnclaveProviderConfigurationSection,System.Data,Version=4.0.0.0,Culture=neutral,PublicKeyToken=b77a5c561934e089"/>
  </configSections>
  <SqlColumnEncryptionEnclaveProviders>
    <providers>
      <add name="Azure" type="Microsoft.SqlServer.Management.AlwaysEncrypted.AzureEnclaveProvider,MyApp"/>
      <add name="HGS" type="Microsoft.SqlServer.Management.AlwaysEncrypted.HGSEnclaveProvider,MyApp" />
    </providers>
  </SqlColumnEncryptionEnclaveProviders >
</configuration>

記憶體保護區型 Always Encrypted 的基本流程如下:

  1. 使用者會建立與支援記憶體保護區型 Always Encrypted 之 SQL Server 的 AlwaysEncrypted 連線。 驅動程式會連絡證明服務,以確保它連線到正確的安全區域。

  2. 一旦記憶體保護區被驗證,驅動程式就會與託管在 SQL Server 上的安全記憶體保護區建立安全通道。

  3. 在 SQL 連線期間,驅動程式與安全區域共用由用戶端授權的加密密鑰。

Windows Presentation Foundation

尋找 ResourceDictionaries 依來源

從 .NET Framework 4.7.2 開始,診斷助手可以找到從指定來源 URI 建立的 ResourceDictionaries。 (此功能供診斷助理使用,而不是生產應用程式使用。Visual Studio 的「編輯與繼續」功能等診斷助理可讓用戶編輯 ResourceDictionary,其意圖是將變更套用至執行中的應用程式。 達成此目標的其中一個步驟是找到執行中的應用程式所建立的所有資源字典,這些字典是從正在編輯的字典中創建的。 例如,應用程式可以宣告 ResourceDictionary,其內容是從指定的來源 URI 複製:

<ResourceDictionary Source="MyRD.xaml" />

MyRD.xaml 中編輯原始標記語法的診斷助手,可以使用新功能來定位字典。 此功能是由新的靜態方法實作,ResourceDictionaryDiagnostics.GetResourceDictionariesForSource。 診斷助理會使用識別原始標記的絕對 URI 來呼叫新方法,如下列程式代碼所示:

IEnumerable<ResourceDictionary> dictionaries = ResourceDictionaryDiagnostics.GetResourceDictionariesForSource(new Uri("pack://application:,,,/MyApp;component/MyRD.xaml"));

除非已啟用 VisualDiagnostics 且已設定 ENABLE_XAML_DIAGNOSTICS_SOURCE_INFO 環境變數,否則方法會傳回空集合。

尋找 ResourceDictionary 擁有者

從 .NET Framework 4.7.2 開始,診斷助理可以找到指定 ResourceDictionary的擁有者。 (此功能供診斷助理使用,而不是由生產應用程式使用。每當對 ResourceDictionary進行變更時,WPF 會自動尋找所有 DynamicResource 可能受到變更影響的參考。

Visual Studio 的「編輯與繼續」等診斷小幫手可能會想要擴充這項功能,以處理 靜態資源 參考。 在此過程中的第一個步驟是找到字典的擁有者,也就是說,尋找所有 Resources 屬性直接或間接透過 ResourceDictionary.MergedDictionaries 屬性參考字典的物件。 在 System.Windows.Diagnostics.ResourceDictionaryDiagnostics 類別上實作的三個新的靜態方法,每個具有 Resources 屬性的基底類型各有一個,支援此步驟:

除非已啟用 VisualDiagnostics 且已設定 ENABLE_XAML_DIAGNOSTICS_SOURCE_INFO 環境變數,否則這些方法會傳回空的可列舉。

尋找 StaticResource 參考

診斷助手每當解析 StaticResource 參考時,將會收到通知。 此功能是供診斷助理使用,而不是供生產應用程式使用。例如 Visual Studio 的「編輯與繼續」這類的診斷工具,在 ResourceDictionary 的值發生變更時,可能會希望更新資源的所有用量。 WPF 會自動針對 DynamicResource 參考執行這項操作,但故意不針對 StaticResource 參考這麼做。 從 .NET Framework 4.7.2 開始,診斷小幫手可以使用這些通知來找出靜態資源的使用方式。

新的 ResourceDictionaryDiagnostics.StaticResourceResolved 事件會實作通知:

public static event EventHandler<StaticResourceResolvedEventArgs> StaticResourceResolved;

每當執行階段解析 StaticResource 參考時,就會引發此事件。  StaticResourceResolvedEventArgs 自變數會描述解析,並指出裝載 StaticResource 參考的物件和屬性,以及用於解析的 ResourceDictionary 和索引鍵:

public class StaticResourceResolvedEventArgs : EventArgs
{
   public Object TargetObject { get; }

   public Object TargetProperty { get; }

   public ResourceDictionary ResourceDictionary { get; }

   public object ResourceKey { get; }
}

除非已啟用 VisualDiagnostics 且已設定 ENABLE_XAML_DIAGNOSTICS_SOURCE_INFO 環境變數,否則不會引發事件(且會忽略其 add 存取子)。

ClickOnce

Windows Forms、Windows Presentation Foundation (WPF) 和 Visual Studio Tools for Office 的 HDPI 感知應用程式都可以使用 ClickOnce 來部署。 如果在應用程式清單中找到下列項目,在 .NET Framework 4.7.2 下的部署將會成功:

<windowsSettings>
   <dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true</dpiAware>
</windowsSettings>

針對 Windows Forms 應用程式,過去需要在應用程式組態檔中設定 DPI 感知作為因應措施,以取代應用程式指令清單,但現在在 ClickOnce 部署中已不再需要此操作才能成功。

.NET Framework 4.7.1 的新功能

.NET Framework 4.7.1 包含下列領域的新功能:

此外,.NET Framework 4.7.1 的主要焦點是改善輔助功能,這可讓應用程式為輔助技術的使用者提供適當的體驗。 如需 .NET Framework 4.7.1 中輔助功能改善的資訊,請參閱 .NET Framework 中輔助功能的最新變更

基類

.NET Standard 2.0 支援

.NET Standard 定義一組 API,每個支援該標準版本的 .NET 實作都必須提供。 .NET Framework 4.7.1 完全支援 .NET Standard 2.0,並在 .NET Standard 2.0、4.6.2 和 4.7 中定義約 200 個 API 新增 。 (請注意,只有在目標系統上也部署其他 .NET Standard 支援檔案時,這些版本的 .NET Framework 才支援 .NET Standard 2.0。如需詳細資訊,請參閱 .NET Framework 4.7.1 運行時間和編譯程式功能 部落格文章中的

組態產生器的支援

組態產生器可讓開發人員在運行時間動態插入和建置應用程式的組態設定。 自定義組態產生器可用來修改組態區段中的現有數據,或完全從頭開始建置組態區段。 如果沒有組態產生器,.config 檔案是靜態的,而且會在啟動應用程式之前定義其設定。

若要建立自訂組態產生器,您可以從抽象 ConfigurationBuilder 類別衍生您的產生器,並覆寫其 ConfigurationBuilder.ProcessConfigurationSectionConfigurationBuilder.ProcessRawXml。 您也可以在 .config 檔案中定義您的建置者。 如需更多資訊,請參閱 .NET Framework 4.7.1 ASP.NET 和組態功能 部落格文章中的「組態建構器」部分。

執行時間功能偵測

System.Runtime.CompilerServices.RuntimeFeature 類別提供一種機制,以判斷在編譯時間或運行時間指定的 .NET 實作上是否支援預先定義的功能。 在編譯時期,編譯程式可以檢查指定的欄位是否存在,以判斷是否支援此功能;如果是,它可以發出利用該功能的程序代碼。 在運行時間,應用程式可以在運行時間發出程式碼之前呼叫 RuntimeFeature.IsSupported 方法。 如需詳細資訊,請參閱 新增輔助方法來描述運行時間支援的功能

值元組類型可串行化

從 .NET Framework 4.7.1 開始,System.ValueTuple 及其相關聯的泛型型別會標示為可串行化的 ,允許二進位串行化。 這應該會使像 Tuple<T1,T2,T3>Tuple<T1,T2,T3,T4>這些 Tuple 類型更容易移轉為值元組類型。 如需詳細資訊,請參閱 .NET Framework 4.7.1 運行時間和編譯程式功能 部落格文章中的<編譯程式 -- ValueTuple 可串行化>。

唯讀參考的支援

.NET Framework 4.7.1 會新增 System.Runtime.CompilerServices.IsReadOnlyAttribute。 語言編譯程式會使用這個屬性來標記具有只讀 ref 傳回型別或參數的成員。 如需詳細資訊,請參閱 .NET Framework 4.7.1 運行時間和編譯程式功能 部落格文章中的<編譯程式 -- ReadOnlyReferences 的支援>。 如需 ref 傳回值的詳細資訊,請參閱 Ref 傳回值ref 局部變數Ref 傳回值 (Visual Basic)

Common Language Runtime (CLR)

垃圾收集效能改善

.NET Framework 4.7.1 中垃圾收集(GC)的變更可改善整體效能,特別是針對大型物件堆(LOH)配置分配。 在 .NET Framework 4.7.1 中,個別的鎖定會用於小型物件堆積 (SOH) 和 LOH 配置,這可讓 LOH 配置在背景 GC 掃掠 SOH 時發生。 因此,大量進行 LOH 配置的應用程式應該會減少配置鎖定衝突,從而提升效能。 如需詳細資訊,請參閱 .NET Framework 4.7.1 運行時間和編譯程式功能 部落格文章中的<運行時間 -- GC 效能改善>一節。

聯網

SHA-2 支援用於 Message.HashAlgorithm

在 .NET Framework 4.7 和舊版中,Message.HashAlgorithm 屬性僅支援 HashAlgorithm.Md5HashAlgorithm.Sha 的值。 從 .NET Framework 4.7.1 開始,也支援 HashAlgorithm.Sha256HashAlgorithm.Sha384HashAlgorithm.Sha512。 此值是否實際使用取決於 MSMQ,因為 Message 實例本身不會進行哈希處理,而只會將值傳遞至 MSMQ。 如需詳細資訊,請參閱 .NET Framework 4.7.1 ASP.NET 和組態功能 部落格文章中的一節。

ASP.NET

ASP.NET 應用程式中 執行步驟

ASP.NET 在包含23個事件的預先定義管線中處理要求。 ASP.NET 執行每個事件處理程式作為執行步驟。 在 .NET Framework 4.7 及之前版本的 ASP.NET 中,ASP.NET 由於在原生與受管控緒之間切換,無法傳遞執行上下文。 相反地,ASP.NET 選擇性地只傳遞 HttpContext。 從 .NET Framework 4.7.1 開始,HttpApplication.OnExecuteRequestStep(Action<HttpContextBase,Action>) 方法也允許模組還原環境數據。 這項功能針對對追蹤、分析、診斷或交易等應用程式執行流程感興趣的程式庫設計。 如需詳細資訊,請參閱 .NET Framework 4.7.1 ASP.NET 和組態功能 部落格文章中的「ASP.NET 執行步驟功能」。

ASP.NET HttpCookie 剖析

.NET Framework 4.7.1 包含新的方法,HttpCookie.TryParse,提供標準化的方式,從字串建立 HttpCookie 物件,並準確地指派 Cookie 值,例如到期日和路徑。 如需詳細資訊,請參閱 .NET Framework 4.7.1 ASP.NET 和組態功能 部落格文章中的「ASP.NET HttpCookie 剖析」。

ASP.NET 表單驗證憑證的SHA-2哈希選項

在 .NET Framework 4.7 和舊版中,ASP.NET 可讓開發人員使用 MD5 或 SHA1,將具有哈希密碼的使用者認證儲存在組態檔中。 從 .NET Framework 4.7.1 開始,ASP.NET 也支援新的安全 SHA-2 哈希選項,例如 SHA256、SHA384 和 SHA512。 SHA1 會維持預設值,而且可以在 Web 組態檔中定義非預設哈希演算法。

重要

Microsoft建議您使用最安全的驗證流程。 如果您要連線到 Azure SQL,Azure 資源的託管識別 是建議的驗證方法。

.NET Framework 4.7 的新功能

.NET Framework 4.7 包含下列領域的新功能:

如需新增至 .NET Framework 4.7 的新 API 清單,請參閱 GitHub 上的 .NET Framework 4.7 API 變更。 如需 .NET Framework 4.7 中的功能改進和 Bug 修正清單,請參閱 GitHub 上的 .NET Framework 4.7 變更清單。 如需詳細資訊,請參閱 .NET 部落格中的 宣告 .NET Framework 4.7

基類

.NET Framework 4.7 改善了 DataContractJsonSerializer的序列化:

增強功能使用橢圓曲線密碼編譯(ECC)*

在 .NET Framework 4.7 中,已將 ImportParameters(ECParameters) 方法新增至 ECDsaECDiffieHellman 類別,以允許物件代表已建立的索引鍵。 新增了一種 ExportParameters(Boolean) 方法,以使用明確的曲線參數匯出金鑰。

.NET Framework 4.7 也會新增對其他曲線的支援(包括 Brainpool 曲線套件),並已新增預先定義的定義,以便透過新的 CreateCreate Factory 方法輕鬆建立。

您可以在 GitHub 上看到 .NET Framework 4.7 密碼編譯改進 的 範例。

DataContractJsonSerializer 對控制字元的支援更好

在 .NET Framework 4.7 中,DataContractJsonSerializer 類別會依照ECMAScript 6標準串行化控制字元。 此行為預設會針對以 .NET Framework 4.7 為目標的應用程式啟用,而針對在 .NET Framework 4.7 下執行但目標為舊版 .NET Framework 的應用程式,此功能是需要選擇性啟用的。 如需詳細資訊,請參閱 應用程式相容性 一節。

聯網

.NET Framework 4.7 新增下列網路相關功能:

TLS 通訊協定的預設作業系統支援*

System.Net.Security.SslStream 和上層堆疊元件所使用的 TLS 堆疊,例如 HTTP、FTP 和 SMTP,可讓開發人員使用操作系統所支援的預設 TLS 通訊協定。 開發人員不再需要將 TLS 版本硬式編碼。

ASP.NET

在 .NET Framework 4.7 中,ASP.NET 包含下列新功能:

物件快取擴充性

從 .NET Framework 4.7 開始,ASP.NET 新增了一組新的 API,可讓開發人員取代記憶體內部物件快取和記憶體監視的預設 ASP.NET 實作。 如果 ASP.NET 實作不夠,開發人員現在可以取代下列三個元件中的任何一個:

  • 物件快取存放區。 藉由使用新的快取提供者組態區段,開發人員可以使用新的 ICacheStoreProvider 介面,插入 ASP.NET 應用程式之物件快取的新實作。

  • 記憶體監視。 ASP.NET 中的預設記憶體監視器會在應用程式執行接近進程設定的私人位元組限制時,或計算機在可用實體 RAM 總計不足時通知應用程式。 當這些限制範圍達到時,會引發通知。 對於某些應用程式,通知是在接近設定的限制時觸發的,這樣的設置不利於用戶進行有效反應。 開發人員現在可以撰寫自己的記憶體監視器,以使用 ApplicationMonitors.MemoryMonitor 屬性來取代預設值。

  • 記憶體限制反應。 根據預設,ASP.NET 嘗試修剪物件快取,並在私人位元組進程限制接近時定期呼叫 GC.Collect。 對於某些應用程式,呼叫 GC.Collect 的頻率或修剪的快取數量沒有效率。 開發人員現在可以將 IObserver 實作訂閱至應用程式的記憶體監視器,來取代或補充預設行為。

Windows Communication Foundation (WCF)

Windows Communication Foundation (WCF) 會新增下列功能和變更:

能夠將預設訊息安全性設定為 TLS 1.1 或 TLS 1.2

從 .NET Framework 4.7 開始,WCF 除了 SSL 3.0 和 TLS 1.0 之外,您還可以將 TLS 1.1 或 TLS 1.2 設定為預設訊息安全性通訊協定。 這是選擇性設定;若要啟用,您必須將下列專案新增至您的應用程式設定檔:

<runtime>
   <AppContextSwitchOverrides value="Switch.System.ServiceModel.DisableUsingServicePointManagerSecurityProtocols=false;Switch.System.Net.DontEnableSchUseStrongCrypto=false" />
</runtime>

提升 WCF 應用程式的可靠性及 WCF 串行化的可靠性

WCF 包含一些程式碼變更,可消除競爭狀況,進而改善串行化選項的效能和可靠性。 這些包括:

  • 更好地在呼叫SocketConnection.BeginReadSocketConnection.Read時,支援混合非同步和同步程式碼。
  • 改善在中止與 SharedConnectionListenerDuplexChannelBinder連線時的可靠性。
  • 已改善呼叫 FormatterServices.GetSerializableMembers(Type) 方法時串行化作業的可靠性。
  • 藉由呼叫 ChannelSynchronizer.RemoveWaiter 方法,改善移除等候者時的可靠性。

Windows Forms

在 .NET Framework 4.7 中,Windows Forms 可改善高 DPI 監視器的支援。

高解析度支援

從以 .NET Framework 4.7 為目標的應用程式開始,.NET Framework 針對 Windows Forms 應用程式提供高 DPI 和動態 DPI 支援。 高 DPI 支援可改善高 DPI 監視器上表單和控件的配置和外觀。 當使用者變更執行中應用程式的 DPI 或顯示縮放比例時,動態 DPI 會變更表單和控件的配置和外觀。

您可以在應用程式組態檔中定義 <System.Windows.Forms.ConfigurationSection> 區段,以配置啟用高 DPI 支援的選擇性功能。 如需將高 DPI 支援和動態 DPI 支援新增至 Windows Forms 應用程式的詳細資訊,請參閱在 Windows Forms中 高 DPI 支援。

Windows Presentation Foundation (WPF)

在 .NET Framework 4.7 中,WPF 包含下列增強功能:

支援以 Windows WM_POINTER 訊息為基礎的觸控/手寫筆支援架構

您現在可以根據 WM_POINTER 訊息來選擇使用觸控/手寫筆堆棧, 而不是 Windows Ink Services Platform (WISP)。 這是 .NET Framework 中的可選功能。 如需詳細資訊,請參閱 應用程式相容性 一節。

WPF 列印 API 的新改進

System.Printing.PrintQueue 類別中的 WPF 列印 API 會呼叫 Windows 列印文件封裝 API,而不是已取代的 XPS 列印 API。 如需這項變更對應用程式相容性的影響,請參閱 應用程式相容性 一節。

.NET Framework 4.6.2 的新功能

.NET Framework 4.6.2 包含下列領域的新功能:

如需新增至 .NET Framework 4.6.2 的新 API 清單,請參閱 GitHub 上的 .NET Framework 4.6.2 API 變更。 如需 .NET Framework 4.6.2 中的功能改進和 Bug 修正清單,請參閱 GitHub 上的 .NET Framework 4.6.2 變更清單。 如需詳細資訊,請參閱 .NET 部落格中的 宣告 .NET Framework 4.6.2

ASP.NET

在 .NET Framework 4.6.2 中,ASP.NET 包含下列增強功能:

改善資料標註驗證器中本地化錯誤訊息的支援

數據批註驗證程式可讓您將一或多個屬性新增至類別屬性,以執行驗證。 如果驗證失敗,屬性的 ValidationAttribute.ErrorMessage 元素會定義錯誤訊息的文字。 從 .NET Framework 4.6.2 開始,ASP.NET 可讓您輕鬆地將錯誤訊息當地語系化。 如果下列狀況,錯誤訊息將會當地語系化:

  1. 驗證屬性中提供了 ValidationAttribute.ErrorMessage

  2. 資源檔會儲存在 App_LocalResources資料夾中。

  3. 本地化資源檔的名稱具有格式 DataAnnotation.Localization.{名稱}.resx,其中 名稱 是語言特性名稱,格式為 語言代碼-國家/地區代碼languageCode格式。

  4. 資源的索引鍵名稱是指派給 ValidationAttribute.ErrorMessage 屬性的字串,而其值為本地化的錯誤訊息。

例如,下列資料註釋屬性定義了無效評分時預設文化的錯誤訊息。

public class RatingInfo
{
   [Required(ErrorMessage = "The rating must be between 1 and 10.")]
   [Display(Name = "Your Rating")]
   public int Rating { get; set; }
}

然後,您可以建立資源檔 DataAnnotation.Localiz.fr.resx,其索引鍵是錯誤訊息字串,而其值為本地化的錯誤訊息。 檔案必須在 App.LocalResources 資料夾中找到。 例如,下列是本地化法文(fr)語言錯誤訊息中的鍵及其值:

名字 價值
評等必須介於 1 到 10 之間。 La note doit être comprise entre 1 et 10.

此外,數據批注本地化是可延伸的。 開發人員可以藉由實作 IStringLocalizerProvider 介面來插入自己的字串本地化工具提供者,以將當地語系化字串儲存在資源檔以外的某個位置。

工作階段狀態存放區提供者的 Async 支援

ASP.NET 現在允許工作傳回方法與會話狀態存放區提供者搭配使用,從而允許 ASP.NET 應用程式取得異步的延展性優勢。 為了支援工作階段狀態存放區提供者的異步操作,ASP.NET 包含了一個新的介面 System.Web.SessionState.ISessionStateModule,該介面繼承自 IHttpModule,並允許開發人員實作自己的工作階段狀態模組和異步會話存放區提供者。 介面的定義如下:

public interface ISessionStateModule : IHttpModule {
    void ReleaseSessionState(HttpContext context);
    Task ReleaseSessionStateAsync(HttpContext context);
}

此外,SessionStateUtility 類別包含兩個新的方法,IsSessionStateReadOnlyIsSessionStateRequired,可用來支援異步操作。

輸出快取提供者的異步支援

從 .NET Framework 4.6.2 開始,可以將傳回工作的方法與輸出快取提供者結合使用,以展現非同步運作的可擴展性優勢。 實作這些方法的提供者可減少網頁伺服器上的線程封鎖,並改善 ASP.NET 服務的延展性。

已新增下列 API 以支援異步輸出快取提供者:

字元類別

.NET Framework 4.6.2 中的字元會根據 Unicode Standard 版本 8.0.0分類。 在 .NET Framework 4.6 和 .NET Framework 4.6.1 中,字元是根據 Unicode 6.3 字元類別分類。

Unicode 8.0 的支援僅限於 CharUnicodeInfo 類別的字元分類,以及依賴它的類型和方法。 包含的內容有 StringInfo 類別、超載的 Char.GetUnicodeCategory 方法,以及由 .NET Framework 正則表達式引擎所識別的 字元類別。 此變更不會影響字元和字串比較和排序,而且會繼續依賴基礎操作系統,或在 Windows 7 系統上,依賴 .NET Framework 所提供的字元數據。

如需從 Unicode 6.0 到 Unicode 7.0 的字元類別變更,請參閱 Unicode 聯盟網站上的 Unicode Standard, Version 7.0.0。 如需了解從 Unicode 7.0 更新至 Unicode 8.0 的變更,請參閱 Unicode 聯盟網站上的 Unicode 標準,版本 8.0.0

密碼學

X509 憑證的支援,其中包含 FIPS 186-3 DSA

.NET Framework 4.6.2 新增 DSA (數位簽名演算法) X509 憑證的支援,其密鑰超過 FIPS 186-2 1024 位限制。

除了支援 FIPS 186-3 的較大金鑰大小外,.NET Framework 4.6.2 還允許使用 SHA-2 系列哈希演算法(SHA256、SHA384 和 SHA512) 計算簽章。 新的 System.Security.Cryptography.DSACng 類別提供 FIPS 186-3 支援。

為了配合 .NET Framework 4.6 中 RSA 類別和 .NET Framework 4.6.1 中 ECDsa 類別的最新變更,.NET Framework 4.6.2 中的 DSA 抽象基類有額外的方法,可讓呼叫者在不轉型的情況下使用這項功能。 您可以呼叫 DSACertificateExtensions.GetDSAPrivateKey 擴充方法來簽署數據,如下列範例所示。

public static byte[] SignDataDsaSha384(byte[] data, X509Certificate2 cert)
{
    using (DSA dsa = cert.GetDSAPrivateKey())
    {
        return dsa.SignData(data, HashAlgorithmName.SHA384);
    }
}

您可以呼叫 DSACertificateExtensions.GetDSAPublicKey 擴充方法來驗證已簽署的數據,如下列範例所示。

public static bool VerifyDataDsaSha384(byte[] data, byte[] signature, X509Certificate2 cert)
{
    using (DSA dsa = cert.GetDSAPublicKey())
    {
        return dsa.VerifyData(data, signature, HashAlgorithmName.SHA384);
    }
}

增加 ECDiffieHellman 金鑰衍生例程的輸入

.NET Framework 3.5 新增了橢圓曲線 Diffie-Hellman 密鑰合約的支援,其中包含三個不同的密鑰衍生函式 (KDF) 例程。 例程和例程本身的輸入是透過 ECDiffieHellmanCng 物件上的屬性來設定。 但是,由於並非每個例行程式都會讀取每個輸入屬性,因此開發人員可能會感到困惑。

若要在 .NET Framework 4.6.2 中解決此問題,下列三種方法已新增至 ECDiffieHellman 基類,以更清楚地表示這些 KDF 例程及其輸入:

ECDiffieHellman 方法 描述
DeriveKeyFromHash(ECDiffieHellmanPublicKey, HashAlgorithmName, Byte[], Byte[]) 使用公式生成金鑰材料

HASH(secretPrepend || x || secretAppend)

HASH(secretPrepend OrElse x OrElse secretAppend)

其中 x 是 EC Diffie-Hellman 演算法的計算結果。
DeriveKeyFromHmac(ECDiffieHellmanPublicKey, HashAlgorithmName, Byte[], Byte[], Byte[]) 使用公式衍生金鑰材料

HMAC(hmacKey, secretPrepend || x || secretAppend)

HMAC(hmacKey, secretPrepend OrElse x OrElse secretAppend)

其中 x 是 EC Diffie-Hellman 演算法的計算結果。
DeriveKeyTls(ECDiffieHellmanPublicKey, Byte[], Byte[]) 使用 TLS 虛擬隨機函式 (PRF) 衍生演算法衍生金鑰數據。

支援保存金鑰對稱式加密

Windows 密碼編譯連結庫 (CNG) 新增了儲存保存對稱密鑰和使用硬體儲存對稱密鑰的支援,而 .NET Framework 4.6.2 可讓開發人員使用這項功能。 由於金鑰名稱和金鑰提供者的概念是實作特定的,因此使用這項功能需要利用具體實作類型的建構函式,而不是較常用的工廠方法(例如呼叫 Aes.Create)。

AES(AesCng)和 3DES(TripleDESCng)演算法提供保存密钥對稱加密支援。 例如:

public static byte[] EncryptDataWithPersistedKey(byte[] data, byte[] iv)
{
    using (Aes aes = new AesCng("AesDemoKey", CngProvider.MicrosoftSoftwareKeyStorageProvider))
    {
        aes.IV = iv;

        // Using the zero-argument overload is required to make use of the persisted key
        using (ICryptoTransform encryptor = aes.CreateEncryptor())
        {
            if (!encryptor.CanTransformMultipleBlocks)
            {
                throw new InvalidOperationException("This is a sample, this case wasn't handled...");
            }

            return encryptor.TransformFinalBlock(data, 0, data.Length);
        }
    }
}

SignedXml 支援 SHA-2 哈希

.NET Framework 4.6.2 新增 RSA-SHA256、RSA-SHA384 和 RSA-SHA512 PKCS#1 簽章方法及 SHA256、SHA384 和 SHA512 參考摘要演算法 SignedXml 類別的支援。

URI 常數全都會在 SignedXml上公開:

SignedXml 欄位 恆定
XmlDsigSHA256Url "http://www.w3.org/2001/04/xmlenc#sha256"
XmlDsigRSASHA256Url "http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"
XmlDsigSHA384Url "http://www.w3.org/2001/04/xmldsig-more#sha384"
XmlDsigRSASHA384Url "http://www.w3.org/2001/04/xmldsig-more#rsa-sha384"
XmlDsigSHA512Url "http://www.w3.org/2001/04/xmlenc#sha512"
XmlDsigRSASHA512Url "http://www.w3.org/2001/04/xmldsig-more#rsa-sha512"

任何已將自定義 SignatureDescription 處理程式註冊到 CryptoConfig 的程式,以新增這些演算法的支援將會繼續像過去一樣運作,但由於現在有平台預設值,因此不再需要 CryptoConfig 註冊。

SqlClient

.NET Framework Data Provider for SQL Server (System.Data.SqlClient) 包含 .NET Framework 4.6.2 中的下列新功能:

使用 Azure SQL 資料庫 連線共用和逾時

啟用連線池時若發生逾時或其他登入錯誤,會快取例外狀況,並在隨後的 5 秒到 1 分鐘內的連線嘗試中擲回該快取的例外狀況。 如需詳細資訊,請參閱 SQL Server 連線共用 (ADO.NET)

在連線到 Azure SQL 資料庫時,這種行為是不理想的,因為連線嘗試可能會因暫時性錯誤而失敗,但通常能夠迅速復原。 為了更妥善地優化連線重試體驗,聯機集區封鎖期間行為會在連線到 Azure SQL Database 失敗時移除。

新增新的 PoolBlockingPeriod 關鍵詞可讓您選取最適合您應用程式的封鎖期間。 值包括:

Auto

已停用連線至 Azure SQL Database 之應用程式的連線集區封鎖期間,並啟用連線至任何其他 SQL Server 實例之應用程式的連線集區封鎖期間。 這是預設值。 如果伺服器端點名稱以下列任一項結尾,則會將其視為 Azure SQL Database:

  • .database.windows.net

  • .database.chinacloudapi.cn

  • .database.usgovcloudapi.net

  • .database.cloudapi.de

AlwaysBlock

連接池阻塞期間始終啟用。

NeverBlock

連接集區封鎖期間一律停用。

Always Encrypted 的 增強功能

SQLClient 引進了兩項 Always Encrypted 增強功能:

  • 為了提升針對加密資料庫欄位的參數化查詢效能,現在會快取查詢參數的加密元數據。 當 SqlConnection.ColumnEncryptionQueryMetadataCacheEnabled 屬性設定為 true (也就是預設值),如果呼叫相同的查詢多次,用戶端只會從伺服器擷取參數元數據一次。

  • 密鑰快取中的欄位加密金鑰紀錄現在會在設定的時間間隔後被清除,並可使用 SqlConnection.ColumnEncryptionKeyCacheTtl 屬性進行設定。

Windows Communication Foundation

在 .NET Framework 4.6.2 中,Windows Communication Foundation 已在下列領域增強:

使用 CNG 儲存之憑證的 WCF 傳輸安全性支援

WCF 傳輸安全性支援使用 Windows 密碼編譯連結庫 (CNG) 儲存的憑證。 在 .NET Framework 4.6.2 中,這項支援僅限於使用具有長度不超過 32 位之公鑰的憑證。 當應用程式以 .NET Framework 4.6.2 為目標時,此功能預設為開啟。

針對以 .NET Framework 4.6.1 和更早版本為目標但是在 .NET Framework 4.6.2 上執行的應用程式,您可以將下列這一行新增至 app.config 或 web.config 檔案的 <runtime> 區段來啟用此功能。

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

這也可以透過程式代碼以程序設計方式完成,如下所示:

private const string DisableCngCertificates = @"Switch.System.IdentityModel.DisableCngCertificates";
AppContext.SetSwitch(disableCngCertificates, false);

DataContractJsonSerializer 類別對於多個日光節約時間調整規則的更好支援

客戶可以使用應用程式組態設定來判斷 DataContractJsonSerializer 類別是否支援單一時區的多個調整規則。 這是一個選擇性功能。 若要啟用它,請將下列設定新增至您的 app.config 檔案:

<runtime>
     <AppContextSwitchOverrides value="Switch.System.Runtime.Serialization.DoNotUseTimeZoneInfo=false" />
</runtime>

啟用此功能時,DataContractJsonSerializer 物件會使用 TimeZoneInfo 類型,而不是 TimeZone 類型來還原串行化日期和時間數據。 TimeZoneInfo 支援多個調整規則,可讓您使用歷史時區數據;TimeZone 沒有。

如需 TimeZoneInfo 結構和時區調整的詳細資訊,請參閱 時區概觀

NetNamedPipeBinding 最符合

WCF 提供了一個新設定功能,允許用戶端應用程式確保它們始終連接到所要求的 URI 中最符合的接聽服務。 將此應用程式設定設為 false (預設值),用戶端可以使用 NetNamedPipeBinding 嘗試連線到接聽所要求 URI 子字串的服務。

例如,客戶端嘗試連線至 net.pipe://localhost/Service1的服務,但該電腦上一個具有管理員權限的不同服務正在監聽 net.pipe://localhost。 將此應用程式設定設為 false,用戶端會嘗試連線到錯誤的服務。 將應用程式設定設為 true之後,用戶端一律會連線到最佳的比對服務。

注意

使用 NetNamedPipeBinding 的用戶端會根據服務的基地址來尋找服務(如果有的話),而不是完整的端點位址。 為了確保此設定一律能夠運作,服務應該使用唯一的基位址。

若要啟用這項變更,請將下列應用程式設定新增至用戶端應用程式的 App.config 或 Web.config 檔案:

<configuration>
    <appSettings>
        <add key="wcf:useBestMatchNamedPipeUri" value="true" />
    </appSettings>
</configuration>

SSL 3.0 不是預設通訊協定

搭配傳輸安全性和憑證的認證類型使用 NetTcp 時,SSL 3.0 不再是用來交涉安全連線的預設通訊協定。 在大部分情況下,應該不會影響現有的應用程式,因為 NetTcp 的通訊協定清單中會包含 TLS 1.0。 所有現有的用戶端都應該能夠至少使用 TLS 1.0 交涉連線。 如果需要 Ssl3,請使用下列其中一個組態機制將它新增至交涉通訊協定清單。

Windows Presentation Foundation (WPF)

在 .NET Framework 4.6.2 中,Windows Presentation Foundation 已在下列領域增強:

群組排序

使用 CollectionView 物件來分組數據的應用程式現在可以明確地宣告如何排序群組。 明確排序可解決應用程式動態新增或移除群組時,或變更與群組相關的專案屬性值時所發生的非直覺式排序問題。 它也可以透過將群組屬性的比較從整個集合的排序移至群組的排序,來提升群組建立過程的效能。

為了支援群組排序,新的 GroupDescription.SortDescriptionsGroupDescription.CustomSort 屬性描述如何排序 GroupDescription 物件所產生的群組集合。 這類似於相同名稱 ListCollectionView 屬性描述如何排序數據項的方式。

PropertyGroupDescription 類別的兩個新的靜態屬性,CompareNameAscendingCompareNameDescending,可用於最常見的案例。

例如,下列 XAML 會依年齡分組數據、以遞增順序排序年齡群組,以及依姓氏將每個年齡組中的專案分組。

<GroupDescriptions>
     <PropertyGroupDescription
         PropertyName="Age"
         CustomSort=
              "{x:Static PropertyGroupDescription.CompareNamesAscending}"/>
     </PropertyGroupDescription>
</GroupDescriptions>

<SortDescriptions>
     <SortDescription PropertyName="LastName"/>
</SortDescriptions>

觸控式鍵盤支援

觸控式鍵盤支援可在 WPF 應用程式中自動叫用和關閉 Windows 10 中的觸控式鍵盤,以在可接受文字輸入的控制項收到觸控輸入時啟用焦點追蹤。

在舊版 .NET Framework 中,WPF 應用程式若要加入焦點追蹤,必須停用 WPF 手寫筆/觸控手勢支援。 因此,WPF 應用程式必須選擇完整的 WPF 觸控支援,或依賴 Windows 滑鼠升級。

每監視器 DPI

為了支援 WPF 應用程式中最新的高 DPI 和混合 DPI 環境激增,.NET Framework 4.6.2 中的 WPF 允許每個監視器對 DPI 的感知。 如需有關如何讓您的 WPF 應用程式在每個監視器上啟用 DPI 感知的更多資訊,請查看 GitHub 上的 範例和開發人員指南

在舊版 .NET Framework 中,WPF 應用程式是系統 DPI 認知的。 換句話說,應用程式的 UI 會根據顯示該應用程式的監視器的 DPI,由作業系統適當地縮放調整。

針對在 .NET Framework 4.6.2 下執行的應用程式,您可以將組態語句新增至應用程式組態檔 <運行時間> 區段,以停用 WPF 應用程式中的個別監視器 DPI 變更,如下所示:

<runtime>
   <AppContextSwitchOverrides value="Switch.System.Windows.DoNotScaleForDpiChanges=false"/>
</runtime>

Windows Workflow Foundation (WF)

在 .NET Framework 4.6.2 中,Windows Workflow Foundation 已在下列區域中增強:

重新裝載 WF 設計工具中的 C# 運算式和 IntelliSense 支援

從 .NET Framework 4.5 開始,WF 支援 Visual Studio Designer 和程式碼工作流程中的 C# 表達式。 重新裝載的工作流程設計工具是 WF 的主要功能,可讓工作流程設計工具位於 Visual Studio 外部的應用程式(例如,在 WPF 中)。 Windows Workflow Foundation 提供在重新裝載工作流程設計工具中支援 C# 表達式和 IntelliSense 的功能。 如需詳細資訊,請參閱 Windows Workflow Foundation 部落格

Availability of IntelliSense when a customer rebuilds a workflow project from Visual Studio 在 4.6.2 之前的 .NET Framework 版本中,當客戶從 Visual Studio 重建工作流程專案時,WF 設計工具 IntelliSense 會中斷。 當專案建置成功時,設計工具上找不到工作流程類型,遺漏工作流程類型的IntelliSense警告會出現在 [錯誤清單] 視窗中。 .NET Framework 4.6.2 可解決此問題,並讓 IntelliSense 可供使用。

現在帶有工作流程追蹤的工作流程 V1 應用程式會在 FIPS 模式下運行

已啟用 FIPS 合規性模式的機器現在可以成功執行工作流程第 1 版應用程式,並開啟工作流程追蹤。 若要啟用此案例,您必須對 app.config 檔案進行下列變更:

<add key="microsoft:WorkflowRuntime:FIPSRequired" value="true" />

如果未啟用此案例,執行應用程式會繼續產生例外狀況訊息:「此實作不是Windows 平臺 FIPS 驗證的密碼編譯演算法的一部分」訊息。

使用 Visual Studio 工作流程設計工具中的動態更新時的工作流程改進

工作流程設計工具、FlowChart 活動設計工具和其他工作流程活動設計工具現在已成功載入並顯示呼叫 DynamicUpdateServices.PrepareForUpdate 方法之後已儲存的工作流程。 在 .NET Framework 4.6.2 之前的 .NET Framework 版本中,針對呼叫 DynamicUpdateServices.PrepareForUpdate 之後已儲存的工作流程,在 Visual Studio 中載入 XAML 檔案可能會導致下列問題:

  • 工作流程設計工具無法正確載入 XAML 檔案(當 ViewStateData.Id 位於行尾時)。

  • 流程圖活動設計工具或其他工作流程活動設計工具可能會顯示其預設位置中的所有物件,而不是附加屬性值。

ClickOnce

除了已經支援的 1.0 通訊協定之外,ClickOnce 也已更新為支援 TLS 1.1 和 TLS 1.2。 ClickOnce 會自動偵測所需的通訊協定;不需要 ClickOnce 應用程式內的額外步驟,才能啟用 TLS 1.1 和 1.2 支援。

將 Windows Forms 和 WPF 應用程式轉換為 UWP 應用程式

Windows 現在提供將現有的 Windows 傳統型應用程式,包括 WPF 和 Windows Forms 應用程式帶入通用 Windows 平臺 (UWP) 的功能。 這項技術充當橋樑,使您能逐漸將現有的程式代碼基底移轉至 UWP,從而使您的應用程式能在所有 Windows 10 裝置上運行。

已轉換的傳統型應用程式會取得與 UWP 應用程式的應用程式身分識別類似的應用程式身分識別,讓 UWP API 可供存取,以啟用動態磚和通知等功能。 應用程式會繼續像之前一樣運作,並以完全信任應用程式的形式執行。 一旦轉換應用程式,就可以將應用程式容器進程新增至現有的完全信任程式,以新增調適型使用者介面。 當所有功能都移至應用程式容器進程時,可以移除完整的信任程式,並將新的UWP應用程式提供給所有Windows 10裝置使用。

偵錯功能改進

非受控偵錯 API 已在 .NET Framework 4.6.2 中增強,以便在擲回 NullReferenceException 時進行額外分析,從而可以判斷單行原始程式碼中的哪一個變數是 null。 為了支援此案例,下列 API 已新增至 Unmanaged 偵錯 API。

.NET Framework 4.6.1 的新功能

.NET Framework 4.6.1 包含下列領域的新功能:

如需 .NET Framework 4.6.1 的詳細資訊,請參閱下列主題:

密碼編譯:支援包含ECDSA的 X509 憑證

.NET Framework 4.6 新增 X509 憑證的 RSACng 支援。 .NET Framework 4.6.1 新增對 ECDSA (橢圓曲線數位簽名演算法) X509 憑證的支援。

ECDSA 提供更佳的效能,而且比 RSA 更安全的密碼編譯演算法,提供傳輸層安全性(TLS) 效能和延展性問題的絕佳選擇。 .NET Framework 實作會將呼叫包裝成現有的 Windows 功能。

下列範例程式代碼示範如何使用 .NET Framework 4.6.1 中包含的 ECDSA X509 憑證新支援,為位元組數據流產生簽章是多麼容易。

using System;
using System.Security.Cryptography;
using System.Security.Cryptography.X509Certificates;

public class Net461Code
{
    public static byte[] SignECDsaSha512(byte[] data, X509Certificate2 cert)
    {
        using (ECDsa privateKey = cert.GetECDsaPrivateKey())
        {
            return privateKey.SignData(data, HashAlgorithmName.SHA512);
        }
    }

    public static byte[] SignECDsaSha512(byte[] data, ECDsa privateKey)
    {
        return privateKey.SignData(data, HashAlgorithmName.SHA512);
    }
}

這與在 .NET Framework 4.6 中產生簽章所需的程序代碼形成鮮明對比。

using System;
using System.Security.Cryptography;
using System.Security.Cryptography.X509Certificates;

public class Net46Code
{
    public static byte[] SignECDsaSha512(byte[] data, X509Certificate2 cert)
    {
        // This would require using cert.Handle and a series of p/invokes to get at the
        // underlying key, then passing that to a CngKey object, and passing that to
        // new ECDsa(CngKey).  It's a lot of work.
        throw new Exception("That's a lot of work...");
    }

    public static byte[] SignECDsaSha512(byte[] data, ECDsa privateKey)
    {
        // This way works, but SignData probably better matches what you want.
        using (SHA512 hasher = SHA512.Create())
        {
            byte[] signature1 = privateKey.SignHash(hasher.ComputeHash(data));
        }

        // This might not be the ECDsa you got!
        ECDsaCng ecDsaCng = (ECDsaCng)privateKey;
        ecDsaCng.HashAlgorithm = CngAlgorithm.Sha512;
        return ecDsaCng.SignData(data);
    }
}

ADO.NET

下列專案已新增至 ADO.NET:

Always Encrypted 支援硬體保護的密鑰

ADO.NET 現在支援在硬體安全性模組 (HSM) 中原生儲存 Always Encrypted 資料行主要密鑰。 透過此支援,客戶可以利用儲存在 HSM 中的非對稱金鑰,而不需要撰寫自定義數據行主要密鑰存放區提供者,並在應用程式中註冊它們。

客戶必須在應用程式伺服器或用戶端計算機上安裝 HSM 廠商提供的 CSP 提供者或 CNG 金鑰存放區提供者,才能存取以 HSM 中儲存的數據行主要密鑰保護的 Always Encrypted 資料。

改善 AlwaysOnMultiSubnetFailover 連線行為

SqlClient 現在會自動提供對 AlwaysOn 可用性群組 (AG) 的更快速連線。 它會以透明方式偵測您的應用程式是否連線到不同子網上的 AlwaysOn 可用性群組 (AG),並快速探索目前的使用中伺服器,並提供與伺服器的連線。 在此版本之前,應用程式必須設定連接字串以包含 "MultisubnetFailover=true",以指出它已連線到 AlwaysOn 可用性群組。 若未將 connection 關鍵詞設定為 true,應用程式在連線至 AlwaysOn 可用性群組時可能會遇到逾時。 在此版本中,應用程式不需要再 將 設定為 。 如需 AlwaysOn 可用性群組之 SqlClient 支援的詳細資訊,請參閱 SqlClient 高可用性支援、災害復原

Windows Presentation Foundation (WPF)

Windows Presentation Foundation 包含多項改進和變更。

效能提升

.NET Framework 4.6.1 中已修正引發觸控事件的延遲。 此外,快速輸入時,輸入 RichTextBox 控制碼不再占用渲染線程。

拼字檢查改善

WPF 中的拼字檢查程式已在 Windows 8.1 和更新版本上更新,以利用操作系統支援進行拼字檢查其他語言。 Windows 8.1 之前的 Windows 版本功能沒有變更。

如同舊版 .NET Framework,會依下列順序尋找資訊來偵測 TextBox 控件或 RichTextBox 區塊的語言:

  • xml:lang,如果它存在的話。

  • 目前的輸入語言。

  • 目前的文化。

如需 WPF 中語言支援的詳細資訊,請參閱 .NET Framework 4.6.1 功能上的 WPF 部落格文章。

針對每位使用者的自訂字典提供額外支援

在 .NET Framework 4.6.1 中,WPF 會辨識全域註冊的自定義字典。 除了能夠為每個控件註冊這些功能之外,還提供這項功能。

在舊版 WPF 中,自定義字典無法辨識排除的文字和自動更正清單。 Windows 8.1 和 Windows 10 可透過使用可放置在 %AppData%\Microsoft\Spelling\<language tag> 目錄下的檔案來支持它們。 下列規則適用於這些檔案:

  • 這些檔案的擴展名應為 .dic(針對新增字)、.exc(針對排除的單字),或 .acl(適用於自動更正)。

  • 這些檔案應該是開頭為 Byte Order Mark (BOM) 的 UTF-16 LE 純文本。

  • 每一行都應該包含在新增和排除的字詞清單中的一個單字,或在自動更正字清單中的以垂直線("|")分隔的自動更正配對。

  • 這些檔案會視為唯讀,系統不會修改。

注意

WPF 拼字檢查 API 不支援這些新的檔案格式,而且應用程式中提供給 WPF 的自定義字典應該繼續使用 .lex 檔案。

範例

GitHub 存放庫中 Microsoft/WPF 範例 有許多 WPF 範例。 藉由傳送合併請求或開啟 GitHub 問題,協助我們改善範例

DirectX 擴充功能

WPF 包含 NuGet 套件,提供新的 D3DImage 實作,讓您輕鬆地與 DX10 和 Dx11 內容互操作。 此套件的程式代碼已開放原始碼,且可在 GitHub上取得。

Windows Workflow Foundation:交易處理

Transaction.EnlistPromotableSinglePhase 方法現在可以使用 MSDTC 以外的分散式交易管理員來提升交易。 您可以透過將 GUID 交易促進器識別碼指定給新的 Transaction.EnlistPromotableSinglePhase(IPromotableSinglePhaseNotification, Guid) 多載來完成此動作。 如果這項作業成功,交易的功能會受到限制。 一旦登記非 MSDTC 交易升級程式之後,下列方法會擲回 TransactionPromotionException,因為這些方法需要升級至 MSDTC:

一旦登記了非 MSDTC 的交易促進者,未來的持久性登記必須使用它所定義的通訊協定。 您可以使用 PromoterType 屬性來取得交易推動者 Guid。 當交易推廣時,交易推廣者會提供代表已推廣令牌的 Byte 陣列。 應用程式可以使用 GetPromotedToken 方法來取得非 MSDTC 升級交易的升級令牌。

Transaction.EnlistPromotableSinglePhase(IPromotableSinglePhaseNotification, Guid) 重載的使用者必須遵循特定的呼叫順序,以完成晉升操作。 這些規則記載於方法的說明文件。

剖析

Unmanaged 分析 API 已增強,如下所示:

  • ICorProfilerInfo7 介面中,有更佳的支援來存取 PDB。

    在 ASP.NET Core 中,透過 Roslyn 即時編譯記憶體中的元件變得越來越常見。 對於製作分析工具的開發人員而言,這表示過去在磁碟上串行化的 PDB 可能不再存在。 分析工具通常會使用 PDB 將程式代碼對應回原始程式碼行,以進行程式碼涵蓋範圍或逐行效能分析等工作。 ICorProfilerInfo7 介面現在包含兩個新方法:ICorProfilerInfo7::GetInMemorySymbolsLengthICorProfilerInfo7::ReadInMemorySymbols,以提供這些分析工具工具記憶體內部 PDB 數據的存取權, 藉由使用新的 API,分析工具可以取得記憶體內部 PDB 的內容做為位元組陣列,然後將它串行化為磁碟。

  • 使用 ICorProfiler 介面進行更好的檢測。

    使用 ICorProfiler 應用程式介面中的 ReJit 功能進行動態監控的剖析器現在可以修改某些元數據。 先前這類工具可以隨時檢測 IL,但元數據只能在模組載入時修改。 因為 IL 是指元數據,所以這限制了可進行的工具化類型。 我們藉由新增 ICorProfilerInfo7::ApplyMetaData 方法,支援模組載入之後的部分元數據編輯,特別是透過新增 AssemblyRefTypeRefTypeSpecMemberRefMemberSpecUserString 記錄來解除其中一些限制。 這項變更使得可以進行更廣泛的實時檢測。

原生映像生成器 (NGEN) PDB 檔案

跨機器事件追蹤可讓客戶在機器 A 上分析程式,並使用機器 B 上的源行對應來查看分析數據。使用舊版的 .NET Framework,使用者會將所有模組和原生映射從已分析的計算機複製到包含 IL PDB 的分析機器,以建立來源對原生對應。 雖然此過程在檔案相對較小時效果良好,例如在手機應用程式中,但桌面系統上的檔案可能非常大,而且需要大量時間才能複製。

使用 NGen PDB 時,NGen 可以建立一個 PDB,包含從 IL 映射到原生代碼的對應關係,無需依賴 IL PDB。 在我們的跨機器事件追蹤案例中,只需要將機器 A 產生的原生映射 PDB 複製到機器 B,並使用 偵錯介面存取 API 來讀取 IL PDB 的來源to-IL 對應和原生映射 PDB 的 IL 對原生對應。 將這兩個對應結合可提供來源到本地化的對應。 由於原生映像 PDB 比所有模組和原生映像小得多,因此從機器 A 到機器 B 的複製過程會快很多。

.NET 2015 的新功能

.NET 2015 引進 .NET Framework 4.6 和 .NET Core。 某些新功能同時適用於 ,而其他功能則專屬於 .NET Framework 4.6 或 .NET Core。

  • ASP.NET Core

    .NET 2015 包含 ASP.NET Core,這是建置現代化雲端式應用程式的精簡 .NET 實作。 ASP.NET Core 是模組化的,因此您只能包含應用程式中所需的功能。 它可以裝載在 IIS 上,或在自訂進程中自我裝載,而且您可以在相同伺服器上以不同版本的 .NET Framework 執行應用程式。 它包含專為雲端部署而設計的新環境組態系統。

    MVC、Web API 和網頁會整合成稱為MVC 6的單一架構。 您可以透過 Visual Studio 2015 或更新版本中的工具建置 ASP.NET Core 應用程式。 您現有的應用程式將在新的 .NET Framework 上運作;不過,若要建置使用MVC 6或 SignalR 3 的應用程式,您必須在Visual Studio 2015 或更新版本中使用項目系統。

    如需詳細資訊,請參閱 ASP.NET Core

  • ASP.NET 更新

    • 任務導向 API for 異步回應排清

      ASP.NET 現在提供一種簡單的任務導向的 API,能夠藉由使用語言的 async/await 支援,以異步方式排清回應 HttpResponse.FlushAsync

    • 模型繫結支援回傳任務的函式

      在 .NET Framework 4.5 中,ASP.NET 新增了模型繫結功能,以啟用 Web Forms 頁面和使用者控制項中基於 CRUD 的數據操作的可延展、以程式碼為重點的方法。 模型繫結系統現在支援返回 Task的模型繫結方法。 這項功能可讓 Web Forms 開發人員在使用較新版本的 ORM,包括 Entity Framework 時,可隨著資料繫結系統的便利性,輕鬆取得異步操作的可擴展性優勢。

      異步模型系結是由 aspnet:EnableAsyncModelBinding 組態設定所控制。

      <appSettings>
          <add key=" aspnet:EnableAsyncModelBinding" value="true|false" />
      </appSettings>
      

      在目標 .NET Framework 4.6 的應用程式上,預設為 true。 在 .NET Framework 4.6 執行的應用程式中,如果以較早版本的 .NET Framework 為目標,則預設為 false。 您可以將組態設定設定設為 true來啟用。

    • HTTP/2 支援 (Windows 10)

      HTTP/2 是新版的 HTTP 通訊協定,可提供更好的連線使用率(客戶端與伺服器之間的往返次數較少),因而讓使用者載入延遲較低的網頁。 網頁(相比於服務)最能從 HTTP/2 獲益,因為該協議優化了在單次操作中請求的多個資源。 已將 HTTP/2 支援新增至 .NET Framework 4.6 中的 ASP.NET。 由於網路功能存在於多層,因此 Windows、IIS 和 ASP.NET 中需要新功能,才能啟用 HTTP/2。 您必須在 Windows 10 上執行,才能搭配 ASP.NET 使用 HTTP/2。

      根據預設,使用 System.Net.Http.HttpClient API 的 Windows 10 通用 Windows 平臺 (UWP) app 也支援和開啟 HTTP/2。

      為了在 ASP.NET 應用程式中提供使用 PUSH_PROMISE 功能的方法,已在 HttpResponse 類別中新增一個帶有兩個多載的 PushPromise(String)PushPromise(String, String, NameValueCollection)新方法。

      注意

      雖然 ASP.NET Core 支援 HTTP/2,但尚未新增 PUSH PROMISE 功能的支援。

      瀏覽器和網頁伺服器 (Windows 上的 IIS) 會執行所有工作。 您不需要為使用者執行任何繁重的工作。

      大部分 主要瀏覽器都支援 HTTP/2,因此如果您的伺服器支援 HTTP/2,您的使用者可能會受益於 HTTP/2 支援。

    • 支援令牌系結通訊協定

      Microsoft 和 Google 一直在合作開發一種新的驗證方法,稱為 令牌綁定通訊協定。 前提是驗證令牌(在您的瀏覽器快取中)可以遭竊,並供罪犯用來存取其他安全資源(例如,您的銀行帳戶),而不需要您的密碼或任何其他特殊許可權知識。 新的通訊協定旨在減輕此問題。

      令牌系結通訊協定將會在 Windows 10 中實作為瀏覽器功能。 ASP.NET 應用程式將參與通訊協定,以便驗證令牌是合法的。 用戶端和伺服器實作會建立通訊協定所指定的端對端保護。

    • 隨機字串哈希演算法

      .NET Framework 4.5 引進了 隨機字串哈希演算法。 不過,ASP.NET 不支援,因為某些 ASP.NET 功能相依於穩定的哈希程序代碼。 在 .NET Framework 4.6 中,現在支援隨機字串哈希演算法。 若要啟用此功能,請使用 aspnet:UseRandomizedStringHashAlgorithm 組態設定。

      <appSettings>
          <add key="aspnet:UseRandomizedStringHashAlgorithm" value="true|false" />
      </appSettings>
      
  • ADO.NET

    ADO .NET 現在支援 SQL Server 2016 中提供的 Always Encrypted 功能。 透過 Always Encrypted,SQL Server 可以在加密數據上執行作業,而且最佳的是,加密密鑰是與客戶信任環境內的應用程式一起保存,而不是在伺服器上。 Always Encrypted 可保護客戶數據,讓 DBA 無法存取純文本數據。 數據加密和解密會在驅動程式層級以透明方式進行,將對現有應用程式所做的變更降至最低。 如需詳細資訊,請參閱 Always Encrypted (Database Engine)Always Encrypted (客戶端開發)

  • 適用於管理的代碼的 64 位 JIT 編譯程式

    .NET Framework 4.6 具有新版的 64 位 JIT 編譯程式(最初稱為 RyuJIT 的程式代碼)。 新的64位編譯程式提供較舊64位 JIT 編譯程式的重大效能改善。 針對在 .NET Framework 4.6 上執行的64位進程,啟用新的64位編譯程式。 如果您的應用程式會編譯為64位或AnyCPU,並在64位操作系統上執行,則您的應用程式會在64位進程中執行。 雖然在新的編譯程式的轉換過程中已盡量做到透明,但行為可能會發生變更。

    新的 64 位 JIT 編譯程式也包含硬體 SIMD 加速功能,同時搭配 System.Numerics 命名空間中已啟用 SIMD 的類型,這可產生良好的效能改善。

  • 元件載入器改善

    元件載入器現在會在載入對應的 NGEN 影像後,卸載 IL 元件,以更有效率地使用記憶體。 這項變更減少了虛擬記憶體,這對大型 32 位應用程式(例如 Visual Studio)特別有幫助,並且節省物理記憶體。

  • 基類庫變更

    許多新的 API 已新增至 .NET Framework 4.6,以啟用主要情境。 其中包括下列變更和新增:

    • IReadOnlyCollection<T> 實作

      其他集合會實作 IReadOnlyCollection<T>,例如 Queue<T>Stack<T>

    • CultureInfo.CurrentCulture 和 CultureInfo.CurrentUICulture

      CultureInfo.CurrentCultureCultureInfo.CurrentUICulture 屬性現在是讀寫,而不是唯讀的。 如果您將新的 CultureInfo 物件指派給這些屬性,Thread.CurrentThread.CurrentCulture 屬性所定義的目前線程文化特性,以及 Thread.CurrentThread.CurrentUICulture 屬性所定義的目前 UI 線程文化特性也會變更。

    • 垃圾回收功能增強(GC)

      GC 類別現在包含 TryStartNoGCRegionEndNoGCRegion 方法,可讓您在重要路徑執行期間不允許垃圾收集。

      GC.Collect(Int32, GCCollectionMode, Boolean, Boolean) 方法的新多載版本可讓您控制是小型物件堆積和大型物件堆積同時進行橫掃和壓縮,還是僅進行橫掃。

    • 已啟用 SIMD 的 類型

      System.Numerics 命名空間現在包含一些已啟用 SIMD 的類型,例如 Matrix3x2Matrix4x4PlaneQuaternionVector2Vector3Vector4

      由於新的 64 位 JIT 編譯程式也包含硬體 SIMD 加速功能,因此使用已啟用 SIMD 的型別搭配新的 64 位 JIT 編譯程式時,效能特別顯著。

    • 密碼編譯更新

      System.Security.Cryptography API 正在更新,以支援 Windows CNG 密碼編譯 API。 舊版 .NET Framework 完全依賴 舊版的 Windows 密碼編譯 API,做為 System.Security.Cryptography 實作的基礎。 我們已要求支援 CNG API,因為它支援 新式密碼編譯演算法,這對特定類別的應用程式很重要。

      .NET Framework 4.6 包含下列支援 Windows CNG 密碼編譯 API 的新增強功能:

      • X509 證書、System.Security.Cryptography.X509Certificates.RSACertificateExtensions.GetRSAPublicKey(System.Security.Cryptography.X509Certificates.X509Certificate2)System.Security.Cryptography.X509Certificates.RSACertificateExtensions.GetRSAPrivateKey(System.Security.Cryptography.X509Certificates.X509Certificate2)的一組擴充方法,當有可能時會返回以 CNG 為基礎的實作,而非以 CAPI 為基礎的實作。 (有些智慧卡等設備仍然需要 CAPI,而 APIs 會處理後援機制)。

      • System.Security.Cryptography.RSACng 類別,提供 RSA 演算法的 CNG 實作。

      • RSA API 的功能增強,使常見操作不再需要類型轉換。 例如,使用 X509Certificate2 物件加密數據需要舊版 .NET Framework 中的程序代碼,如下所示。

        RSACryptoServiceProvider rsa = (RSACryptoServiceProvider)cert.PrivateKey;
        byte[] oaepEncrypted = rsa.Encrypt(data, true);
        byte[] pkcs1Encrypted = rsa.Encrypt(data, false);
        

        使用 .NET Framework 4.6 中新密碼編譯 API 的程式代碼可以改寫如下,以避免轉換。

        RSA rsa = cert.GetRSAPrivateKey();
        if (rsa == null)
           throw new InvalidOperationException("An RSA certificate was expected");
        
        byte[] oaepEncrypted = rsa.Encrypt(data, RSAEncryptionPadding.OaepSHA1);
        byte[] pkcs1Encrypted = rsa.Encrypt(data, RSAEncryptionPadding.Pkcs1);
        
    • 支援將日期和時間轉換成 Unix 時間

      下列新方法已被添加到 DateTimeOffset 結構中,以支援日期和時間值與 Unix 時間之間的轉換:

    • 兼容性開關

      AppContext 類別新增了新的相容性功能,使程式庫開發者能為使用者提供統一的選擇不參加機制。 它會建立元件之間的鬆散結合合約,以傳達退出要求。 當對現有功能進行變更時,這項功能通常很重要。 相反地,對於新功能來說,已經有隱含的默認同意。

      使用 AppContext時,連結庫會定義並公開相容性參數,而相依的程式代碼可以設定這些參數來影響連結庫行為。 根據預設,程式庫會提供新功能,只有在設定開關時,它們才會改變功能(也就是說,它們會提供先前的功能)。

      應用程式(或程式庫)可以宣告相依程式庫所定義的開關數值(一律為 Boolean 值)。 這個開關總是隱含 false。 將開關設定為 true 以啟用它。 明確將開關設定為 false 會實現新的行為。

      AppContext.SetSwitch("Switch.AmazingLib.ThrowOnException", true);
      

      函式庫必須檢查使用者是否已宣告開關的值,然後對其採取適當的行動。

      if (!AppContext.TryGetSwitch("Switch.AmazingLib.ThrowOnException", out shouldThrow))
      {
          // This is the case where the switch value was not set by the application.
          // The library can choose to get the value of shouldThrow by other means.
          // If no overrides nor default values are specified, the value should be 'false'.
          // A false value implies the latest behavior.
      }
      
      // The library can use the value of shouldThrow to throw exceptions or not.
      if (shouldThrow)
      {
          // old code
      }
      else
      {
          // new code
      }
      

      使用一致的格式來處理開關是很有幫助的,因為它們是由函式庫公開的正式合約。 以下是兩種明顯的格式。

      • 開關命名空間switchname

      • 開關函式庫switchname

    • 以任務為基礎的非同步模式的變更 (TAP)

      針對以 .NET Framework 4.6 為目標的應用程式,TaskTask<TResult> 對象會繼承呼叫線程的文化特性和UI文化特性。 以舊版 .NET Framework 為目標或未以特定 .NET Framework 版本為目標的應用程式行為不會受到影響。 如需詳細資訊,請參閱 CultureInfo 類別主題中「文化與基於任務的非同步操作」這一節。

      System.Threading.AsyncLocal<T> 類別可讓您表示本地於指定異步控制流程的環境數據,例如 async 方法。 它可用來跨線程保存數據。 您也可以定義一個 callback 方法,每當環境數據因 AsyncLocal<T>.Value 屬性明確變更或線程遇到上下文轉換而變更時,就會收到通知。

      三種便利方法,Task.CompletedTaskTask.FromCanceledTask.FromException,已新增至以任務為基礎的非同步模式(TAP),以傳回處於特定狀態的已完成的任務。

      NamedPipeClientStream 類別現在支援與其新 ConnectAsync進行異步通訊。 方法。

    • EventSource 現在支援寫入事件記錄檔

      您現在可以使用 EventSource 類別,將系統管理或操作訊息記錄到事件記錄檔,以及計算機上建立的任何現有 ETW 工作階段。 過去,您必須針對這項功能使用 Microsoft.Diagnostics.Tracing.EventSource NuGet 套件。 這項功能現在內建 .NET Framework 4.6。

      NuGet 套件和 .NET Framework 4.6 都已更新下列功能:

      • 動態事件

        允許「即時」定義的事件,而不需建立事件方法。

      • 豐富承載

        允許傳遞具有特殊屬性的類別和陣列,以及基本類型作為承載。

      • 活動追蹤

        促使啟動和停止活動以用一個表示所有當前活躍活動的標識碼來標記其間的事件。

      為了支持這些功能,多載 Write 方法已新增至 EventSource 類別。

  • Windows Presentation Foundation (WPF)

    • 高密度像素顯示的改善

      WPF 中的 HDPI 支援現在在 .NET Framework 4.6 中更好。 已針對佈局的圓角化處理進行變更,以減少具有邊框的控制項中出現裁切的情況。 根據預設,只有在您的 TargetFrameworkAttribute 設定為 .NET Framework 4.6 時,才會啟用此功能。 以早期版本架構為目標,但在 .NET Framework 4.6 中執行的應用程式,可以在 app.config 檔案的 <runtime> 區段新增以下這一行,以啟用新行為:

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

      WPF 視窗現在可以完全跨越多個具有不同 DPI 設定的監視器(多 DPI 設定)而不會出現黑屏區域。 您可以將下列這一行新增至 app.config 檔案的 <appSettings> 區段,以停用此新行為,從而選擇退出該行為:

      <add key="EnableMultiMonitorDisplayClipping" value="true"/>
      

      支援根據 DPI 設定自動載入正確的游標,已新增至 System.Windows.Input.Cursor

    • 觸控更好

      已針對 Connect 中客戶反映的觸控功能引發無法預測行為的問題,在 .NET Framework 4.6 中進行了解決。 Windows 市集應用程式和 WPF 應用程式的按兩下閾值現在與 Windows 8.1 和更新版本相同。

    • 透明子窗口的支援功能

      .NET Framework 4.6 中的 WPF 支援 Windows 8.1 和更新版本的透明子視窗。 這可讓您在最上層視窗中建立非矩形和透明的子視窗。 您可以將 HwndSourceParameters.UsesPerPixelTransparency 屬性設定為 true來啟用此功能。

  • Windows Communication Foundation (WCF)

    • SSL 支援

      WCF 現在支援 TLS 版本 1.1 和 1.2,以及 SSL 3.0 和 TLS 1.0,當使用 NetTcp 搭配傳輸安全性和用戶端驗證時。 現在可以選取要使用的通訊協定,或停用較舊較不安全的通訊協定。 您可以藉由設定 SslProtocols 屬性或將下列內容新增至組態檔來完成。

      <netTcpBinding>
          <binding>
            <security mode= "None|Transport|Message|TransportWithMessageCredential" >
                <transport clientCredentialType="None|Windows|Certificate"
                          protectionLevel="None|Sign|EncryptAndSign"
                          sslProtocols="Ssl3|Tls1|Tls11|Tls12">
                  </transport>
            </security>
          </binding>
      </netTcpBinding>
      
    • 使用不同的 HTTP 連線傳送訊息

      WCF 現在可讓用戶確保特定訊息會使用不同的基礎 HTTP 連線來傳送。 有兩種方式可以執行這項操作:

      • 使用聯機組名字首

        用戶可以指定一個字串,作為 WCF 連接組名前置詞。 兩個具有不同前置詞的訊息會使用不同的基礎 HTTP 連線來傳送。 您可以將索引鍵/值組新增至訊息的 Message.Properties 屬性,以設定前綴。 鑰匙為 "HttpTransportConnectionGroupNamePrefix";值是所需的前綴。

      • 使用不同的通道處理站

        使用者也可以啟用功能,以確保使用不同通道處理站所建立的通道所傳送的訊息會使用不同的基礎 HTTP 連線。 若要啟用此功能,用戶必須將下列 appSetting 設定為 true

        <appSettings>
            <add key="wcf:httpTransportBinding:useUniqueConnectionPoolPerFactory" value="true" />
        </appSettings>
        
  • Windows Workflow Foundation (WWF)

    您現在可以指定工作流程服務在遇到 "非通訊協定" 書籤未完成的情況下,對於順序錯亂的作業請求保持的秒數,這樣在逾時請求之前即可管理等候時間。 「非協議」書籤是與尚未完成接收操作無關的書籤。 某些活動會在其實作中建立非通訊協定書籤,因此非通訊協定書籤可能並不明顯。 其中包括 [狀態] 和 [挑選]。 因此,如果您有使用狀態機或包含 Pick 活動的工作流程服務,您很可能會有非協議書籤。 您可以將如下行新增至 app.config 檔案的 [appSettings] 區段,以指定間隔:

    <add key="microsoft:WorkflowServices:FilterResumeTimeoutInSeconds" value="60"/>
    

    預設值為 60 秒。 如果 value 設定為 0,則會立即拒絕順序錯亂的要求,並顯示類似以下文字的錯誤:

    Operation 'Request3|{http://tempuri.org/}IService' on service instance with identifier '2b0667b6-09c8-4093-9d02-f6c67d534292' cannot be performed at this time. Please ensure that the operations are performed in the correct order and that the binding in use provides ordered delivery guarantees.
    

    如果您收到順序錯誤作業訊息且沒有非通訊協定書籤,則會收到相同的訊息。

    如果 FilterResumeTimeoutInSeconds 元素的值不是零,則有非通訊協定書籤,且逾時間隔到期,作業就會失敗並出現逾時訊息。

  • 交易

    您現在可以包含造成衍生自 TransactionException 例外狀況之交易的分散式交易識別碼。 將下列金鑰新增至 app.config 檔案的 [appSettings] 區段,即可執行此動作:

    <add key="Transactions:IncludeDistributedTransactionIdInExceptionMessage" value="true"/>
    

    預設值為 false

  • 網路

    • 套接字重複使用

      Windows 10 包含新的高延展性網路演算法,可藉由重複使用本機埠進行輸出 TCP 連線,讓機器資源得到更好的使用。 .NET Framework 4.6 支援新的演算法,讓 .NET 應用程式能夠利用新的行為。 在舊版 Windows 中,有人為的並行連線限制(通常是 16,384,動態埠範圍的預設大小),這可能會在負載下造成埠耗盡而限制服務的延展性。

      在 .NET Framework 4.6 中,已新增兩個 API 來啟用埠重複使用,這有效地移除了並行連線的 64 KB 限制:

      根據預設,ServicePointManager.ReusePort 屬性會是 false,除非 HKLM\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 登錄機碼的 HWRPortReuseOnSocketBind 值設定為 0x1。 若要在 HTTP 連線上啟用本機埠重複使用,請將 ServicePointManager.ReusePort 屬性設定為 true。 這會導致來自 HttpClientHttpWebRequest 的所有傳出 TCP 套接字連線使用 Windows 10 的新套接字選項 SO_REUSE_UNICASTPORT,從而啟用本機埠重複使用。

      撰寫僅使用套接字的應用程式的開發人員可以在呼叫 Socket.SetSocketOption 之類的方法時指定 System.Net.Sockets.SocketOptionName 選項,讓外部套接字在綁定時重複使用本機埠。

    • 支持國際域名和 PunyCode

      IdnHost的新屬性已新增至 Uri 類別,以更好地支援國際域名和 PunyCode。

  • Windows Forms 控制件的大小調整。

    這項功能已在 .NET Framework 4.6 中展開,以包含繪製 UITypeEditor時所使用的 Bounds 屬性所指定的 DomainUpDownNumericUpDownDataGridViewComboBoxColumnDataGridViewColumnToolStripSplitButton 型別和矩形。

    這是一個需要用戶選擇加入的功能。 若要啟用它,請將 EnableWindowsFormsHighDpiAutoResizing 項目設定為應用程式組態 (app.config) 檔案中的 true

    <appSettings>
        <add key="EnableWindowsFormsHighDpiAutoResizing" value="true" />
    </appSettings>
    
  • 支援代碼頁編碼

    .NET Core 主要支援 Unicode 編碼,根據預設,提供代碼頁編碼的有限支援。 您可以透過在 Encoding.RegisterProvider 方法中註冊代碼頁編碼,來新增在 .NET Framework 中可用但在 .NET Core 中不支援的代碼頁編碼支援。 如需詳細資訊,請參閱 System.Text.CodePagesEncodingProvider

  • .NET Native

以 C# 或 Visual Basic 撰寫的通用 Windows 平臺 (UWP) 應用程式可以利用將應用程式編譯成機器碼而非 IL 的新技術。 這項技術會產生更快啟動和運行時間的應用程式。 如需詳細資訊,請參閱使用 .NET Native編譯應用程式 。 如需瞭解 .NET Native 的概述,其中探討其與 JIT 編譯和 NGEN 的差異及其對您的程式碼的影響,請參閱 .NET Native and Compilation

當您使用 Visual Studio 2015 或更新版本編譯應用程式時,預設會編譯成原生碼。 如需詳細資訊,請參閱 .NET Native用戶入門。

為了支援偵錯 .NET Native 應用程式,已將許多新的介面和列舉新增至非受控偵錯 API。 如需詳細資訊,請參閱 偵錯(Unmanaged API 參考) 主題。

  • 開放原始碼 .NET Framework 套件

    .NET Core 套件,例如不可變的集合、SIMD API,以及 命名空間中找到的 API 等網路 API,現在可在 GitHub上以開放原始碼套件的形式使用。 若要存取程式代碼,請參閱 GitHub 上的 .NET。 如需更多資訊以及如何貢獻於這些封裝,請參閱 .NET簡介、GitHub .NET 首頁

.NET Framework 4.5.2 的新功能

.NET Framework 4.5.1 的新功能

2014 年 4 月更新

  • Visual Studio 2013 Update 2 包含可攜式類別庫範本的更新,以支持這些案例:

    • 您可以在以 Windows 8.1、Windows Phone 8.1 和 Windows Phone Silverlight 8.1 為目標的可攜式連結庫中使用 Windows 運行時間 API。

    • 當您以 Windows 8.1 或 Windows Phone 8.1 為目標時,您可以將 XAML (Windows.UI.XAML 類型)包含在可攜式連結庫中。 支援下列 XAML 範本:空白頁面、資源字典、範本化控件和使用者控制件。

    • 您可以建立可攜式 Windows 運行時間元件 (.winmd 檔案),以用於以 Windows 8.1 和 Windows Phone 8.1 為目標的市集應用程式。

    • 您可以將 Windows 市集或 Windows Phone 市集類別庫重新設定為目標,例如可攜式類別庫。

    如需這些變更的詳細資訊,請參閱 可攜式類別庫

  • .NET Framework 內容集合現在包含 .NET Native 的文件,這是一種用於建置和部署 Windows 應用程式的先行編譯技術。 .NET Native 會將您的應用程式直接編譯成機器碼,而不是中繼語言 (IL),以提升效能。 如需詳細資訊,請參閱使用 .NET Native編譯應用程式

  • .NET Framework 參考來源 提供新的瀏覽體驗和增強功能。 您現在可以在線流覽 .NET Framework 原始程式碼,下載參考 以進行脫機檢視,並在偵錯期間逐步執行來源(包括修補程式和更新)。 如需詳細資訊,請參閱部落格文章 .NET 參考來源的新外觀

.NET Framework 4.5.1 基類的新功能和增強功能包括:

Windows Forms 的改善包括:

  • 在 Windows Forms 控制件中重設大小。 您可以使用系統 DPI 設定來調整控制元件的大小(例如,在屬性網格中顯示的圖示),方法是加入應用程式組態檔(app.config)中的條目。 目前下列 Windows Forms 控制項支援這項功能:

    若要啟用此功能,請將新的 <appSettings> 元素新增至組態檔 (app.config),並將 EnableWindowsFormsHighDpiAutoResizing 元素設定為 true

    <appSettings>
        <add key="EnableWindowsFormsHighDpiAutoResizing" value="true" />
    </appSettings>
    

在 Visual Studio 2013 中偵錯 .NET Framework 應用程式時的改善包括:

  • 傳回 Visual Studio 調試程式中的值。 當您在 Visual Studio 2013 中偵錯管理程式應用程式時,[自動變數] 視窗會顯示方法的傳回類型和值。 此資訊適用於桌面、Windows 市集和 Windows Phone 應用程式。 如需詳細資訊,請參閱 檢查方法呼叫的傳回值

  • 64 位應用程式的編輯及繼續功能。 Visual Studio 2013 支援桌面、Windows 市集和 Windows Phone 64 位受控應用程式的 [編輯後繼續] 功能。 32 位和 64 位應用程式的現有限制仍然有效(請參閱 支援的程式代碼變更(C#) 一文的最後一節)。

  • 異步感知偵錯。 為了更輕鬆地偵錯 Visual Studio 2013 中的異步應用程式,呼叫堆疊會隱藏編譯程式所提供的基礎結構程式代碼以支援異步程序設計,並鏈結在邏輯父框架中,以便更清楚地遵循邏輯程序執行。 [工作] 視窗會取代 [平行工作] 視窗,並顯示與特定斷點相關的工作,也會顯示應用程式中目前作用中或已排程的任何其他工作。 您可以在 .NET Framework 4.5.1 公告的「異步感知偵錯」一節中閱讀這項功能。

  • Windows 運行時間元件更佳的例外狀況支援。 在 Windows 8.1 中,來自 Windows 市集應用程式的例外狀況會保留造成例外狀況之錯誤的相關信息,甚至跨越語言界限。 您可以在 .NET Framework 4.5.1 公告的「Windows 市集應用程式開發」一節中閱讀關於這項功能的資訊,

從 Visual Studio 2013 開始,您可以使用 Managed Profile Guided Optimization Tool (Mpgo.exe),將 Windows 8.x 市集應用程式和桌面應用程式優化。

如需 ASP.NET 4.5.1 中的新功能,請參閱 ASP.NET 和 Web Tools for Visual Studio 2013 版本資訊

.NET Framework 4.5 的新功能

基類

  • 在部署期間偵測和關閉 .NET Framework 4 應用程式,以減少系統重新啟動的能力。 請參閱 在 .NET Framework 4.5 安裝期間減少系統重新啟動

  • 在64位平台上支援大於2 GB的陣列。 這項功能可以在應用程式組態檔中啟用。 請參閱 <gcAllowVeryLargeObjects> 元素,其中也列出物件大小和陣列大小的其他限制。

  • 透過伺服器背景垃圾回收提升效能。 當您在 .NET Framework 4.5 中使用伺服器垃圾收集時,會自動啟用背景垃圾收集。 請參閱垃圾收集 基本概念一節的背景伺服器垃圾收集一節。

  • 背景執行的即時編譯(Just-In-Time, JIT),可以選擇地在多核心處理器上使用,以改善應用程式效能。 請參閱 ProfileOptimization

  • 限制正則表達式引擎在逾時之前嘗試解析正則表達式的時間長度。請參閱 Regex.MatchTimeout 屬性。

  • 能夠定義應用程式域的預設文化特性。 請參閱 CultureInfo 類別。

  • Unicode (UTF-16) 編碼的控制台支援。 請參閱 Console 類別。

  • 支援文化字串排序和比較數據的版本化。 請參閱 SortVersion 類別。

  • 在擷取資源時,效能更佳。 請參閱 套件和部署資源

  • Zip 壓縮的改進,以減少壓縮檔案的大小。 請參閱 System.IO.Compression 命名空間。

  • 可以自訂反射上下文,以透過 CustomReflectionContext 類別覆蓋預設的反射行為。

  • 在 Windows 8 上使用 System.Globalization.IdnMapping 類別時,支援 Internationalized Domain Names in Applications (IDNA) 2008 版標準。

  • 當在 Windows 8 上使用 .NET Framework 時,字串比較會委派給實作 Unicode 6.0 的作業系統。 在其他平台上執行時,.NET Framework 會包含自己的字元串比較數據,其會實作 Unicode 5.x。 請參閱 String 類別和 SortVersion 類別的備註部分。

  • 能夠針對每個應用程式域計算字串的哈希碼。 請參閱 <UseRandomizedStringHashAlgorithm> Element

  • 類型反射支援分割在 TypeTypeInfo 類別之間。 請參閱適用於 Windows 市集應用程式的 .NET Framework 反射。

受控擴充性架構 (MEF)

在 .NET Framework 4.5 中,Managed Extensibility Framework (MEF) 提供下列新功能:

  • 支援泛型型別。

  • 以慣例為基礎的程序設計模型,可讓您根據命名慣例而不是屬性來建立元件。

  • 多個範圍。

  • 您可以在建立 Windows 8.x 市集應用程式時使用的 MEF 子集。 此子集可從 NuGet 資源庫 以 可下載的套件的形式提供。 若要安裝套件,請在 Visual Studio 中開啟您的專案,從 [專案] 選單中選擇 [管理 NuGet 套件],然後在線搜尋 Microsoft.Composition 套件。

如需詳細資訊,請參閱 Managed Extensibility Framework (MEF)

異步檔案作業

在 .NET Framework 4.5 中,新的異步功能已新增至 C# 和 Visual Basic 語言。 這些功能會新增工作型模型來執行異步操作。 若要使用此新模型,請使用 I/O 類別中的異步方法。 請參閱 非同步檔案 I/O

工具

在 .NET Framework 4.5 中,資源文件產生器 (Resgen.exe) 可讓您從內嵌在 .NET Framework 元件中的 .resources 檔案,建立 .resw 檔案以用於 Windows 8.x 市集應用程式。 如需詳細資訊,請參閱 Resgen.exe (資源檔案產生器)

管理的配置檔引導優化(Mpgo.exe)可讓您藉由優化原生映像元件來改善應用程式啟動時間、記憶體使用率(工作集大小)和吞吐量。 命令行工具會產生原生映像應用程式元件的配置檔數據。 請參閱 Mpgo.exe(管理的配置文件引導最佳化工具)。 從 Visual Studio 2013 開始,您可以使用 Mpgo.exe 來優化 Windows 8.x 市集應用程式和傳統型應用程式。

平行運算

.NET Framework 4.5 提供數個新功能和平行運算的改善。 其中包括改善的效能、增加的控制、改善異步程式設計的支援、新的數據流連結庫,以及改善平行偵錯和效能分析的支援。 請參閱 .NET 平行程式設計部落格中的文章 ,了解 .NET Framework 4.5 的平行運算新功能

ASP.NET 4.5 和 4.5.1 新增 Web Forms 的模型系結、WebSocket 支援、異步處理程式、效能增強功能,以及其他許多功能。 如需詳細資訊,請參閱下列資源:

網路

.NET Framework 4.5 提供 HTTP 應用程式的新程序設計介面。 如需詳細資訊,請參閱新的 System.Net.HttpSystem.Net.Http.Headers 命名空間。

此功能也包含支援使用現有的 HttpListener 和相關類別接收及與 WebSocket 連線進行互動的新程式設計介面。 如需詳細資訊,請參閱新的 System.Net.WebSockets 命名空間和 HttpListener 類別。

此外,.NET Framework 4.5 包含下列網路功能改善:

  • 符合 RFC 規範的 URI 支援。 如需詳細資訊,請參閱 Uri 和相關類別。

  • 支援國際化網域名稱(IDN)解析。 如需詳細資訊,請參閱 Uri 和相關類別。

  • 支援電子郵件地址國際化(EAI)。 如需詳細資訊,請參閱 System.Net.Mail 命名空間。

  • 改善的 IPv6 支援。 如需詳細資訊,請參閱 System.Net.NetworkInformation 命名空間。

  • 雙模式套接字支援。 如需詳細資訊,請參閱 SocketTcpListener 類別。

Windows Presentation Foundation (WPF)

在 .NET Framework 4.5 中,Windows Presentation Foundation (WPF) 包含下列領域的變更和改進:

  • 新的 Ribbon 控制件可讓您實現一個包含快速存取工具列、應用程式選單和索引標籤的功能區使用者介面。

  • 新的 INotifyDataErrorInfo 介面,可支援同步和異步數據驗證。

  • VirtualizingPanelDispatcher 類別的新功能。

  • 改善在顯示大型群組數據集,以及在非UI線程上存取集合時的效能。

  • 數據系結至靜態屬性、數據系結至實作 ICustomTypeProvider 介面的自定義型別,以及從系結表達式擷取數據系結資訊。

  • 隨著值變更而重新定位數據(即時成形)。

  • 檢查項目容器的資料內容是否斷線的功能。

  • 能夠設定屬性變更與數據源更新之間應該經過的時間量。

  • 改善對於實作弱事件模式的支援。 此外,事件現在可以接受標籤擴展。

Windows Communication Foundation (WCF)

在 .NET Framework 4.5 中,已新增下列功能,讓撰寫和維護 Windows Communication Foundation (WCF) 應用程式更簡單:

  • 簡化產生的組態檔。

  • 支援契約優先開發。

  • 能夠更輕鬆地設定 ASP.NET 相容性模式。

  • 預設傳輸屬性值的變更,旨在減少您需要自行設定它們的可能性。

  • 更新 XmlDictionaryReaderQuotas 類別,以減少您必須手動設定 XML 字典讀取器配額的可能性。

  • Visual Studio 在建置過程中驗證 WCF 組態檔,因此您可以在執行應用程式之前偵測組態錯誤。

  • 新的異步串流支援。

  • 新的 HTTPS 協議對應設計,使您可以更輕鬆地使用 Internet Information Services (IIS)透過 HTTPS 來公開端點。

  • 能夠藉由將 ?singleWSDL 附加至服務 URL,在單一 WSDL 檔中產生元數據。

  • Websockets 支援透過埠 80 和 443 啟用真正的雙向通訊,其效能特性類似於 TCP 傳輸。

  • 支援在程式代碼中設定服務。

  • XML 編輯器工具提示。

  • ChannelFactory 快取支援。

  • 二進位編碼器壓縮支援。

  • 支援UDP傳輸,讓開發人員能撰寫使用「發射後即忘」傳訊的服務。 用戶端會將訊息傳送至服務,並預期不會收到來自服務的回應。

  • 使用 HTTP 傳輸和傳輸安全性時,能夠在單一 WCF 端點上支援多個驗證模式。

  • 支援使用國際化網域名稱(IDN)的 WCF 服務。

如需詳細資訊,請參閱 Windows Communication Foundation 的新功能

Windows Workflow Foundation (WF)

在 .NET Framework 4.5 中,已將數個新功能新增至 Windows Workflow Foundation (WF),包括:

  • 狀態機器工作流程最初是在 .NET Framework 4.0.1 中引進的(.NET Framework 4 平臺更新 1)。 此更新包含數個新的類別和活動,可讓開發人員建立狀態機器工作流程。 .NET Framework 4.5 已更新這些類別和活動,包括:

    • 在狀態上設定斷點的能力。

    • 在工作流程設計工具中複製和貼上轉換的能力。

    • 設計工具支援共用觸發轉換的建立。

    • 建立狀態機器工作流程的活動,包括:StateMachineStateTransition

  • 增強的工作流程設計工具功能,例如:

    • Visual Studio 中的增強工作流程搜尋功能,包括 [快速尋找][在檔案中尋找]

    • 當第二個子活動新增至容器活動時,能夠自動建立一個序列活動,並將兩個活動都包含在此序列活動中。

    • 平移支援,可讓工作流程中可見的部分在不使用滾動條的情況下進行變更。

    • 新的 檔大綱 檢視,顯示樹狀結構樣式大綱檢視中工作流程的元件,並可讓您在 檔大綱 檢視中選取元件。

    • 能夠將批註新增至活動。

    • 能夠使用工作流程設計工具來定義及取用活動委派。

    • 自動連接和自動插入功能,用於狀態機器和流程圖工作流程中的活動和轉換。

  • 儲存 XAML 檔案中單一元素之工作流程的檢視狀態資訊,讓您可以輕鬆地找出和編輯檢視狀態資訊。

  • NoPersistScope 容器活動,用於防止子活動持久化。

  • 支援 C# 運算式:

    • 使用 Visual Basic 的工作流程專案會使用 Visual Basic 運算式,而 C# 工作流程專案將會使用 C# 運算式。

    • 在 Visual Studio 2010 中建立且具有 Visual Basic 表達式的 C# 工作流程專案與使用 C# 表達式的 C# 工作流程專案相容。

  • 版本控制增強功能:

    • 新的 WorkflowIdentity 類別,提供持續性工作流程實例與其工作流程定義之間的對應。

    • 在相同主機中同時執行多個工作流版本,包括 WorkflowServiceHost

    • 在動態更新中,能夠修改保存工作流程實例的定義。

  • 合約優先工作流程服務開發,可支援自動產生活動以符合現有的服務合約。

如需詳細資訊,請參閱 Windows Workflow Foundation 的新功能

適用於 Windows 8.x 市集應用程式的 .NET

Windows 8.x 市集應用程式專為特定尺寸而設計,並利用 Windows 作業系統的強大功能。 .NET Framework 4.5 或 4.5.1 的子集可用於使用 C# 或 Visual Basic 建置適用於 Windows 的 Windows 8.x 市集應用程式。 此子集稱為 .NET,適用於 Windows 8.x 市集應用程式,並在 概覽中進行討論

可攜式類別庫

Visual Studio 2012(及更新版本)中的可攜式類別庫專案可讓您撰寫及建置在多個 .NET Framework 平臺上運作的 Managed 元件。 使用可攜式類別庫專案,您可以選擇目標平臺(例如 Windows Phone 和適用於 Windows 8.x 市集應用程式的 .NET)。 在您的專案中,可用的類型和成員會自動限制為這些平台上共同使用的類型和成員。 如需詳細資訊,請參閱 可攜式類別庫

另請參閱