.NET Framework 的服務是獨立於 Windows 更新的,並提供安全性及可靠性漏洞修正。 一般而言,安全性更新會每季發行一次。 .NET Framework 將繼續包含在 Windows 中,沒有計劃將其刪除。 您不需要移轉 .NET Framework 應用程式,但針對新的開發,請使用 .NET 而不是 .NET Framework

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

.NET Framework 4.8.1 .NET Framework 4.8 .NET Framework 4.7.2 .NET Framework 4.7.1 .NET Framework 4.7 .NET Framework 4.6.2 .NET Framework 4.6.1 .NET 2015 和 .NET Framework 4.6 .NET Framework 4.5.2 .NET Framework 4.5.1 .NET 框架 4.5

本文不提供有關每個新功能的全面信息,並且可能會發生變化。 如需 .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.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 在下列區域引進新功能:

  • Arm64 的原生支援
  • 符合 WCAG2.1 的無障礙工具提示 Windows Forms – 輔助功能改善

    改善協助工具可讓應用程式為輔助技術使用者提供適當的體驗,是 .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 網頁安裝程式

    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 安裝程式。

    您可以安裝 .NET Framework 4.8 開發人員套件 ,以 Visual Studio 2012 或更新版本中的 .NET Framework 4.8 為目標。

    .NET Framework 4.8 的新功能

    .NET Framework 4.8 在下列區域引進新功能:

    Windows 通訊基礎 (WCF) Windows Presentation Foundation (WPF) 通用語言執行環境

    改善的協助工具可讓應用程式為輔助技術使用者提供適當的體驗,這仍然是 .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

  • MD5Cng
  • MD5CryptoServiceProvider
  • RC2CryptoServiceProvider
  • RijndaelManaged
  • RIPEMD160Managed
  • SHA256Managed
  • 相反地,這些類別會將密碼編譯作業重新導向至系統密碼編譯程式庫。 此變更有效地消除了開發人員環境和生產環境之間可能令人困惑的差異,並使原生元件和受管理元件在相同的加密策略下運行。 相依於這些例外狀況的應用程式可以將 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);
    
    Dim host As New ServiceHost(GetType(Service1),
                New Uri("http://contoso:81/Service1"))
    Dim healthBehavior As ServiceHealthBehavior =
       host.Description.Behaviors.Find(Of ServiceHealthBehavior)()
    If healthBehavior Is Nothing Then
       healthBehavior = New ServiceHealthBehavior()
    End If
    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 大於 CommunicationState.Opened時,會傳回 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

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

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

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

  • 否則會傳回 200。

    服務健康情況狀態可以透過指定查詢字串(例如 )以 HTML 顯示,也可以透過指定查詢字串(例如 https://contoso:81/Service1?healthhttps://contoso:81/Service1?health&Xml)以 XML 顯示。 類似的 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 編譯器所做的所有錯誤修正都包含在 .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 包含下列區域的新功能:

    ASP.NET
  • ClickOnce
  • .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.
    
    ' Before .NET Framework 4.7.2
    Using rsa = RSA.Create()
       rsa.ImportParameters(rsaParameters)
       ' Other code to execute using the rsa instance.
    End Using
    

    類似以下代碼:

    // Starting with .NET Framework 4.7.2
    using (RSA rsa = RSA.Create(rsaParameters))
       // Other code to execute using the rsa instance.
    
    ' Starting with .NET Framework 4.7.2
    Using rsa = RSA.Create(rsaParameters)
       ' Other code to execute using the rsa instance.
    End Using
                  DSA.Create(Int32)RSA.Create(Int32) 方法可讓您產生具有特定金鑰大小的新 DSARSA 金鑰。 例如:

    using (DSA dsa = DSA.Create(2048))
       // Other code to execute using the dsa instance.
    
    Using dsa = DSA.Create(2048)
       ' Other code to execute using the dsa instance.
    End Using
                  Rfc2898DeriveBytes 建構函式接受哈希演算法名稱

    Rfc2898DeriveBytes 類別具有三個新的建構函式,其參數 HashAlgorithmName 可識別派生索引鍵時要使用的 HMAC 演算法。 開發人員不應使用 SHA-1,而是使用 SHA-2 型 HMAC,例如 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);
    
    Private Shared Function DeriveKey(password As String, ByRef iterations As Integer,
                                      ByRef salt AS Byte(), ByRef algorithm As HashAlgorithmName) As Byte()
       iterations = 100000
       algorithm = HashAlgorithmName.SHA256
       Const SaltSize As Integer = 32
       Const  DerivedValueSize As Integer = 32
       Using pbkdf2 = New Rfc2898DeriveBytes(password, SaltSize, iterations, algorithm)
          salt = pbkdf2.Salt
          Return pbkdf2.GetBytes(DerivedValueSize)
       End Using
    End Function
                  暫時金鑰的支援

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

  • 由於金鑰不會保存到磁碟,因此使用此旗標載入的憑證不適合新增至 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);
    
    Dim 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> 類型。 這些包括:

    TryGetValue 方法,可將其他集合類型中使用的 try 模式延伸至這兩種類型。 方法是:

    公用 bool HashSet<T>。TryGetValue(T equalValue,out T actualValue)

  • public bool 排序集<T>。TryGetValue(T equalValue, out T actualValue)
  • Enumerable.To* 擴充方法,用來將集合轉換成 HashSet<T>

    公用靜態 HashSet<TSource> ToHashSet<TSource>(這個 IEnumerable<TSource> 來源) 公用靜態 HashSet<TSource> ToHashSet<TSource>(此 IEnumerable<TSource> source, IEqualityComparer<TSource> 比較子)
  • 新的 HashSet<T> 建構函式可讓您設定集合的容量,當您預先知道 HashSet<T> 的大小時,可以提高效能。

    公共 HashSet(int capacity)
  • 公共 HashSet(int capacity, IEqualityComparer<T> 比較子) ConcurrentDictionary<TKey,TValue> 類別包含新多載的 AddOrUpdate GetOrAdd 方法,以便從字典中擷取值或在找不到時新增,並將值新增至字典或在已存在時更新。

    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)
    
    Public AddOrUpdate(Of TArg)(key As TKey, addValueFactory As Func(Of TKey, TArg, TValue), updateValueFactory As Func(Of TKey, TValue, TArg, TValue), factoryArgument As TArg) As TValue
    Public GetOrAdd(Of TArg)(key As TKey, valueFactory As Func(Of TKey, TArg, TValue), factoryArgument As TArg) As TValue
    

    ASP.NET

    支援 Web Forms 中的相依性插入

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

  • 在 ASP.NET Web 應用程式專案的 處理程式和模組中,使用設置器注入、介面注入和建構子注入,Page 實例,以及 使用者控制項

  • 處理程式和模組中使用 setter 型和介面型插入,Page 實例,以及 使用者控件 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;
    
    Dim c As New HttpCookie("secureCookie", "same origin")
    c.SameSite = SameSiteMode.Lax
    

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

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

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

    <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 現在提供這些屬性的實作。 屬性包括:

  • CheckCertificateRevocationList
  • SslProtocols
  • SQLClient

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

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

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

    如需詳細資訊和範例,請參閱 .NET 部落格中的「SQL -- Azure AD 通用和多重要素驗證支援」。

    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 命名空間:

    SqlConnectionStringBuilder.EnclaveAttestationUrl,指定記憶體保護區型 Always Encrypted 的 URI。

    SqlColumnEncryptionEnclaveProvider,這是一個所有安全區提供者衍生自的抽象類。

    SqlEnclaveSession,它會封裝指定區域會話的狀態。

    SqlEnclaveAttestationParameters,提供 SQL Server 用來取得執行特定證明通訊協定所需的信息證明參數。

    然後,應用程式組態檔會指定抽象類別 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 的基本流程如下:

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

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

  • 在 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"));
    
    Dim dictionaries As IEnumerable(Of ResourceDictionary) = 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 屬性的基底類型各一個,支援此步驟:

  • public static IEnumerable<FrameworkElement> GetFrameworkElementOwners(ResourceDictionary dictionary);

  • public static IEnumerable<FrameworkContentElement> GetFrameworkContentElementOwners(ResourceDictionary dictionary);

  • public static IEnumerable<Application> GetApplicationOwners(ResourceDictionary dictionary);

    除非已啟用 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;
    
    Public Shared Event StaticResourceResolved As EventHandler(Of StaticResourceResolvedEventArgs)
    

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

    public class StaticResourceResolvedEventArgs : EventArgs
       public Object TargetObject { get; }
       public Object TargetProperty { get; }
       public ResourceDictionary ResourceDictionary { get; }
       public object ResourceKey { get; }
    
    Public Class StaticResourceResolvedEventArgs : Inherits EventArgs
       Public ReadOnly Property TargetObject As Object
       Public ReadOnly Property TargetProperty As Object
       Public ReadOnly Property ResourceDictionary As ResourceDictionary
       Public ReadOnly Property ResourceKey As Object
    End Class
    

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

    ClickOnce

    Windows Forms、Windows Presentation Foundation (WPF) 和 Visual Studio Tools for Office (VSTO) 的 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 包含下列區域的新功能:

    共通語言執行階段(Common Language Runtime,CLR)
  • ASP.NET
  • 此外,.NET Framework 4.7.1 的主要重點是改善協助工具,這可讓應用程式為輔助技術使用者提供適當的體驗。 如需 .NET Framework 4.7.1 中輔助功能改善的資訊,請參閱 .NET Framework 中輔助功能的最新變更

    .NET Standard 2.0 支援

    .NET Standard 會定義一組 API,這些 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 執行階段和編譯器功能 部落格文章中的「BCL - .NET Standard 2.0 支援」。

    支援組態建置器

    配置建置器可讓開發人員在執行階段動態插入及建置應用程式的配置設定。 自訂組態產生器可用來修改組態區段中的現有資料,或完全從頭開始建置組態區段。 如果沒有配置建置器,.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 其相關聯的泛型類型會標示為 Serializable,這允許二進位序列化。 這應該會使像 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.ShaHashAlgorithm.Md5值。 從 .NET Framework 4.7.1 開始, HashAlgorithm.Sha256也支援 、 HashAlgorithm.Sha384HashAlgorithm.Sha512 。 是否實際使用此值取決於 MSMQ,因為 Message 實例本身不會進行雜湊,而只是將值傳遞至 MSMQ。 如需詳細資訊,請參閱 .NET Framework 4.7.1 ASP.NET 和組態功能 部落格文章中的「Message.HashAlgorithm 的 SHA-2 支援」一節。

    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 包含下列領域的新功能:

    ASP.NET
  • Windows 通訊基礎 (WCF) Windows Forms Windows Presentation Foundation (WPF)

    如需新增至 .NET Framework 4.7 的新 API 清單,請參閱 GitHub 上的 .NET Framework 4.7 API 變更 。 如需 .NET Framework 4.7 中的功能改善和錯誤修正清單,請參閱 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 曲線套件) 的支援,並新增了預先定義的定義,以便透過新 Create 方法和 Create 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 通訊協定的預設作業系統支援*

    TLS 堆疊由 HTTP、FTP 和 SMTP 等上層元件使用 System.Net.Security.SslStream ,可讓開發人員使用作業系統支援的預設 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 開始,除了 SSL 3.0 和 TLS 1.0 之外,WCF 還允許您將 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 包含下列區域的新功能:

    ASP.NET

    SqlClient

    Windows Communication Foundation(視窗通訊基礎)

    Windows Presentation Foundation (WPF)

    Windows Workflow Foundation (WF)

    ClickOnce

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

    如需新增至 .NET Framework 4.6.2 的新 API 清單,請參閱 GitHub 上的 .NET Framework 4.6.2 API 變更 。 如需 .NET Framework 4.6.2 中的功能改善和錯誤修正清單,請參閱 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 可讓您輕鬆地當地語系化錯誤訊息。 如果出現以下情況,錯誤訊息將被當地語系化:

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

  • 資源檔案儲存在App_LocalResources資料夾中。

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

  • 資源的索引鍵名稱是指派給屬性的 ValidationAttribute.ErrorMessage 字串,其值是當地語系化的錯誤訊息。

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

    public class RatingInfo
       [Required(ErrorMessage = "The rating must be between 1 and 10.")]
       [Display(Name = "Your Rating")]
       public int Rating { get; set; }
    
    Public Class RatingInfo
       <Required(ErrorMessage = "The rating must be between 1 and 10.")>
       <Display(Name = "Your Rating")>
       Public Property Rating As Integer = 1
    End Class
    

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

    此外,資料註解本地化是可延伸的。 開發人員可以藉由實作 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);
    
    Public Interface ISessionStateModule : Inherits IHttpModule
       Sub ReleaseSessionState(context As HttpContext)
       Function ReleaseSessionStateAsync(context As HttpContext) As Task
    End Interface
    

    此外,該 SessionStateUtility 類別還包含兩個新方法, IsSessionStateReadOnly 以及 IsSessionStateRequired可用來支援非同步作業的方法。

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

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

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

    System.Web.Caching.OutputCacheProviderAsync 類別繼承自 System.Web.Caching.OutputCacheProvider,允許開發人員實作異步輸出快取提供者。

    OutputCacheUtility類別,提供用於設定輸出快取的協助程式方法。

  • 班級 System.Web.HttpCachePolicy 中的 18 個新方法。 這些包括 GetCacheabilityGetCacheExtensionsGetETagGetETagFromFileDependenciesGetMaxAgeGetMaxAgeGetNoStoreGetNoTransformsGetOmitVaryStarGetProxyMaxAgeGetRevalidationGetUtcLastModifiedGetVaryByCustomHasSlidingExpirationIsValidUntilExpires

  • 類別中的 System.Web.HttpCacheVaryByContentEncodings 2 個新方法: GetContentEncodingsSetContentEncodings

  • 類別中的 System.Web.HttpCacheVaryByHeaders 2 個新方法: GetHeadersSetHeaders

  • 類別中的 System.Web.HttpCacheVaryByParams 2 個新方法: GetParamsSetParams

  • System.Web.Caching.AggregateCacheDependency 類別中,GetFileDependencies 方法。

  • CacheDependency中,GetFileDependencies 方法。

    .NET Framework 4.6.2 中的字元是根據 Unicode 標準 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 新增了對金鑰超過 FIPS 186-2 1024 位限制的 DSA (數位簽章演算法) X509 憑證的支援。

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

    為了符合 .NET Framework 4.6 中類別 RSAECDsa .NET Framework 4.6.1 中類別的最新變更, DSA .NET Framework 4.6.2 中的抽象基類具有其他方法,可讓呼叫端使用這項功能,而不需要轉換。 您可以呼叫 DSACertificateExtensions.GetDSAPrivateKey 擴充功能方法來簽署資料,如下列範例所示。

    public static byte[] SignDataDsaSha384(byte[] data, X509Certificate2 cert)
        using (DSA dsa = cert.GetDSAPrivateKey())
            return dsa.SignData(data, HashAlgorithmName.SHA384);
    
    Public Shared Function SignDataDsaSha384(data As Byte(), cert As X509Certificate2) As Byte()
        Using DSA As DSA = cert.GetDSAPrivateKey()
            Return DSA.SignData(data, HashAlgorithmName.SHA384)
        End Using
    End Function
    

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

    public static bool VerifyDataDsaSha384(byte[] data, byte[] signature, X509Certificate2 cert)
        using (DSA dsa = cert.GetDSAPublicKey())
            return dsa.VerifyData(data, signature, HashAlgorithmName.SHA384);
    
     Public Shared Function VerifyDataDsaSha384(data As Byte(), signature As Byte(), cert As X509Certificate2) As Boolean
        Using dsa As DSA = cert.GetDSAPublicKey()
            Return dsa.VerifyData(data, signature, HashAlgorithmName.SHA384)
        End Using
    End Function
                  增加 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);
    
    Public Shared Function EncryptDataWithPersistedKey(data As Byte(), iv As Byte()) As Byte()
        Using Aes As Aes = New AesCng("AesDemoKey", CngProvider.MicrosoftSoftwareKeyStorageProvider)
            Aes.IV = iv
            ' Using the zero-argument overload Is required to make use of the persisted key
            Using encryptor As ICryptoTransform = Aes.CreateEncryptor()
                If Not encryptor.CanTransformMultipleBlocks Then
                    Throw New InvalidOperationException("This is a sample, this case wasn't handled...")
                End If
                Return encryptor.TransformFinalBlock(data, 0, data.Length)
            End Using
        End Using
    End Function
                  SignedXml 支援 SHA-2 哈希

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

    URI 常數都公開在 SignedXml

    SignedXml 欄位

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

    Sql客戶端

    .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 關鍵字可讓您選取最適合應用程式的封鎖期間。 值包括:

    連線到 Azure SQL 資料庫之應用程式的連線集區封鎖期間會停用,而連線到任何其他 SQL Server 執行個體之應用程式的連線集區封鎖期間會啟用。 這是預設值。 如果伺服器端點名稱以下列任何一項結尾,則會將其視為 Azure SQL 資料庫:

  • .database.windows.net

  • .database.chinacloudapi.cn

  • .database.usgovcloudapi.net

  • .database.cloudapi.de

    AlwaysBlock

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

    NeverBlock

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

    Always Encrypted 的 增強功能

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

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

  • 密鑰快取中的欄位加密金鑰紀錄現在會在設定的時間間隔後被清除,並可使用 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 檔案的執行階段> 區段,以啟用此功能。

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

    這也可以使用如下程式碼以程式設計方式完成:

    private const string DisableCngCertificates = @"Switch.System.IdentityModel.DisableCngCertificates";
    AppContext.SetSwitch(disableCngCertificates, false);
    
    Const DisableCngCertificates As String = "Switch.System.IdentityModel.DisableCngCertificates"
    AppContext.SetSwitch(disableCngCertificates, False)
                  DataContractJsonSerializer 類別對於多個日光節約時間調整規則的更好支援

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

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

    啟用此功能時,物件會DataContractJsonSerializer使用類型而非TimeZone類型來TimeZoneInfo還原序列化日期和時間資料。 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 不再是用來交涉安全連線的預設通訊協定。 在大部分情況下,應該不會對現有應用程式造成影響,因為 TLS 1.0 包含在 NetTcp 的通訊協定清單中。 所有現有的用戶端都應該能夠至少使用 TLS 1.0 交涉連線。 如果需要 Ssl3,請使用下列其中一個組態機制,將它新增至交涉通訊協定清單。

    SslStreamSecurityBindingElement.SslProtocols 屬性

    TcpTransportSecurity.SslProtocols 屬性

    <傳輸> 區段在 <netTcpBinding> 區段中

    <customBinding> 區段的 <sslStreamSecurity> 區段

    Windows Presentation Foundation (WPF)

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

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

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

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

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

    <GroupDescriptions>
         <PropertyGroupDescription
             PropertyName="Age"
             CustomSort=
                  "{x:Static PropertyGroupDescription.CompareNamesAscending}"/>
         </PropertyGroupDescription>
    </GroupDescriptions>
    <SortDescriptions>
         <SortDescription PropertyName="LastName"/>
    </SortDescriptions>
                  觸控式鍵盤支援

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

    在舊版 .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 設計工具和程式碼工作流程中都支援 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 工作流程設計工具中的動態更新時的工作流程改進

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

  • 工作流程設計工具無法正確載入 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 裝置使用。

    偵錯功能改進

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

    ICorDebugCode4ICorDebugVariableHomeICorDebugVariableHomeEnum 介面,這些介面公開了託管變數的原生位置。 這可讓偵錯工具在發生 NullReferenceException 時執行一些程式流程分析,並逆向操作,以判斷對應至 null原生位置的受控變數。

    ICorDebugType2::GetTypeID 方法提供 ICorDebugType 與 COR_TYPEID 的對應,可讓偵錯工具取得沒有 ICorDebugType 實例的COR_TYPEID。 然後,可以使用 COR_TYPEID 上的現有 API 來判斷類型的類別配置。

    .NET Framework 4.6.1 的新功能

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

    ADO.NET

    Windows Presentation Foundation (WPF)

    Windows 工作流程基礎

    程式代碼剖析

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

    .NET Framework 4.6.1 變更清單

    4.6.1 中的應用程式相容性

    .NET Framework API 差異 (在 GitHub 上)

    密碼學:支援包含 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);
    
    Imports System.Security.Cryptography
    Imports System.Security.Cryptography.X509Certificates
    Public Class Net461Code
        Public Shared Function SignECDsaSha512(data As Byte(), cert As X509Certificate2) As Byte()
            Using privateKey As ECDsa = cert.GetECDsaPrivateKey()
                Return privateKey.SignData(data, HashAlgorithmName.SHA512)
            End Using
        End Function
        Public Shared Function SignECDsaSha512(data As Byte, privateKey As ECDsa) As Byte()
            Return privateKey.SignData(data, HashAlgorithmName.SHA512)
        End Function
    End Class
    

    這與在 .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);
    
    Imports System.Security.Cryptography
    Imports System.Security.Cryptography.X509Certificates
    Public Class Net46Code
        Public Shared Function SignECDsaSha512(data As Byte(), cert As X509Certificate2) As Byte()
            ' 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...")
        End Function
        Public Shared Function SignECDsaSha512(data As Byte(), privateKey As ECDsa) As Byte()
            ' This way works, but SignData probably better matches what you want.
            Using hasher As SHA512 = SHA512.Create()
                Dim signature1 As Byte() = privateKey.SignHash(hasher.ComputeHash(data))
            End Using
            ' This might not be the ECDsa you got!
            Dim ecDsaCng As ECDsaCng = CType(privateKey, ECDsaCng)
            ecDsaCng.HashAlgorithm = CngAlgorithm.Sha512
            Return ecDsaCng.SignData(data)
        End Function
    End Class
    

    ADO.NET

    以下內容已新增至 ADO.NET:

    Always Encrypted 支援硬體保護的密鑰

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

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

    MultiSubnetFailover 連線行為

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

  • 檔案應該是以位元組順序標記 (BOM) 開頭的 UTF-16 LE 純文字。

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

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

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

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

    DirectX 延伸模組

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

    Windows Workflow Foundation:交易處理

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

  • Transaction.EnlistDurable

  • TransactionInterop.GetDtcTransaction

  • TransactionInterop.GetExportCookie

  • TransactionInterop.GetTransmitterPropagationToken

    一旦登記了非 MSDTC 的交易促進者,未來的持久性登記必須使用它所定義的通訊協定。 您可以使用 Guid 屬性來取得交易推動者 PromoterType。 當交易推廣時,交易推廣者會提供代表已推廣令牌的 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 核心

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

    ASP.NET 更新

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

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

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

    在 .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 上執行,才能將 HTTP/2 與 ASP.NET 搭配使用。

    HTTP/2 也受支援,而且預設會開啟,適用於使用 System.Net.Http.HttpClient API 的 Windows 10 通用 Windows 平台 (UWP) 應用程式。

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

    雖然 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 (資料庫引擎)Always Encrypted (用戶端開發)。

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

    .NET Framework 4.6 具有新版本的 64 位 JIT 編譯器 (最初代號為 RyuJIT)。 新的 64 位編譯器比舊的 64 位 JIT 編譯器提供了顯著的性能改進。 新的 64 位編譯器已針對在 .NET Framework 4.6 上執行的 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 的類型,例如 Matrix3x2Vector2Vector4Matrix4x4PlaneQuaternionVector3和 。

    因為新的 64 位 JIT 編譯器也包含硬體 SIMD 加速功能,所以搭配新的 64 位 JIT 編譯器使用啟用 SIMD 的類型時,效能會特別顯著改善。

    密碼學更新

    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);
    
    Dim rsa As RSACryptoServiceProvider = CType(cert.PrivateKey, RSACryptoServiceProvider)
    Dim oaepEncrypted() As Byte = rsa.Encrypt(data, True)
    Dim pkcs1Encrypted() As Byte = 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);
    
    Dim rsa As RSA = cert.GetRSAPrivateKey()
    If rsa Is Nothing Then
        Throw New InvalidOperationException("An RSA certificate was expected")
    End If
    Dim oaepEncrypted() As Byte = rsa.Encrypt(data, RSAEncryptionPadding.OaepSHA1)
    Dim pkcs1Encrypted() As Byte = rsa.Encrypt(data, RSAEncryptionPadding.Pkcs1)
                  兼容性開關

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

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

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

    AppContext.SetSwitch("Switch.AmazingLib.ThrowOnException", true);
    
    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
        // new code
    
    If Not AppContext.TryGetSwitch("Switch.AmazingLib.ThrowOnException", shouldThrow) Then
        ' 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.
    End If
    ' The library can use the value of shouldThrow to throw exceptions or not.
    If shouldThrow Then
        ' old code
        ' new code
    End If
    

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

    開關命名空間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 類別。

    高密度像素顯示的改善

    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.UsesPerPixelTransparencytrue來啟用此功能。

    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 活動的工作流程服務,您很可能會有非協議書籤。 您可以將如下所示的行新增至 appSettings app.config 檔案的區段來指定間隔:

    <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 例外狀況之交易的分散式交易識別碼。 您可以透過將下列索引鍵 appSettings 新增至 app.config 檔案的區段來執行此操作:

    <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 限制:

    System.Net.Sockets.SocketOptionName 列舉值。

    ServicePointManager.ReusePort 屬性。

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

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

    支持國際域名和 PunyCode

    類別中Uri新增了新屬性IdnHost,以更好地支援國際網域名稱和 PunyCode。

    Windows Forms 控制件的大小調整。

    此功能已在 .NET Framework 4.6 中展開,以包含 DomainUpDown、 、 NumericUpDownDataGridViewComboBoxColumnDataGridViewColumnToolStripSplitButton類型,以及繪製 UITypeEditor時所使用的屬性所Bounds指定的矩形。

    這是一個選擇性功能。 若要啟用它,請在應用程式組態 (app.config) 檔案中將 EnableWindowsFormsHighDpiAutoResizing 元素設定為 true

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

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

    .NET 原生

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

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

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

    開放原始碼 .NET Framework 套件

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

    .NET Framework 4.5.2 的新功能

  • 適用於 ASP.NET 應用程式的新 API。 新的 HttpResponse.AddOnSendingHeadersHttpResponseBase.AddOnSendingHeaders 方法可讓您在將回應傳送至用戶端應用程式的過程中,檢查和修改回應標頭和狀態代碼。 請考慮使用這些方法,而不是 and PreSendRequestHeadersPreSendRequestContent 事件;它們更有效率且可靠。

    HostingEnvironment.QueueBackgroundWorkItem 方法可讓您排程小型背景工作任務。 ASP.NET 會追蹤這些專案,並防止 IIS 突然終止背景工作程式,直到所有背景工作專案完成為止。 這個方法無法在 ASP.NET 受控應用程式網域外部呼叫。

    new HttpResponse.HeadersWrittenHttpResponseBase.HeadersWritten 屬性會傳回布林值,指出是否已寫入回應標頭。 您可以使用這些屬性來確保例如 HttpResponse.StatusCode 這樣的 API 呼叫會成功,如果標頭已被寫入,則會引發例外狀況。

  • 在 Windows Forms 控制件中重設大小。 此功能已擴展。 您現在可以使用系統 DPI 設定來調整其他以下控制項的元件大小(例如下拉式選單中的下拉箭頭):

  • ComboBox
  • ToolStripComboBox
  • ToolStripMenuItem
  • Cursor
  • DataGridView
  • DataGridViewComboBoxColumn
  • 這是一個選擇性功能。 若要啟用它,請在應用程式組態 (app.config) 檔案中將 EnableWindowsFormsHighDpiAutoResizing 元素設定為 true

    <appSettings>
        <add key="EnableWindowsFormsHighDpiAutoResizing" value="true" />
    </appSettings>
    
  • 新的工作流程功能。 使用 EnlistPromotableSinglePhase 方法的資源管理員(因此實作 IPromotableSinglePhaseNotification 介面)可以使用新的 Transaction.PromoteAndEnlistDurable 方法來請求下列事項:

  • 將交易升級為 Microsoft 分散式交易協調器 (MSDTC) 的交易。

  • IPromotableSinglePhaseNotification 替換為 ISinglePhaseNotification,它是能夠支援單一階段提交的持久性註冊。

    這可以在相同的應用程式網域內完成,而且不需要任何額外的 Unmanaged 代碼與 MSDTC 互動以執行升級操作。 只有在有從 System.Transactions 到由可促銷登記實作的 IPromotableSinglePhaseNotificationPromote 方法的突出呼叫時,才能呼叫新的方法。

  • 分析改善。 下列新的非受控效能剖析 API 提供更健全的剖析功能:

    COR_PRF_ASSEMBLY_REFERENCE_INFO 結構
  • COR_PRF_HIGH_MONITOR 列舉
  • GetAssemblyReferences 方法
  • GetEventMask2 方法
  • SetEventMask2 方法
  • AddAssemblyReference 方法
  • 先前 ICorProfiler 實作版本支援延遲載入相依元件。 新的分析 API 需要分析器插入的相依元件可立即載入,而不是在應用程式完全初始化之後載入。 此變更不會影響現有 ICorProfiler API 的使用者。

  • 偵錯改善。 下列新的非受控偵錯 API 可提供與分析工具更好的整合。 您現在可以存取分析工具所插入的元數據,以及編譯程式 ReJIT 要求在傾印偵錯時所產生的局部變數和程式代碼。

    SetWriteableMetadataUpdateMode 方法
  • EnumerateLocalVariablesEx 方法
  • GetLocalVariableEx 方法 GetCodeEx 方法 GetActiveReJitRequestILCode 方法 GetInstrumentedILMap 方法
  • 事件追蹤變更。 .NET Framework 4.5.2 可針對更廣泛的範圍啟用非內部、Windows 事件追蹤(ETW)型活動追蹤。 這使高級電源管理 (APM) 供應商能夠提供輕量級工具,以準確跟踪跨線程的單個請求和活動的成本。 只有當 ETW 控制器啟用這些事件時,才會引發這些事件,因此,這些變更不會影響先前撰寫的 ETW 代碼或 ETW 停用狀態下運行的代碼。

    促進交易並將其轉換為持久性參與

    Transaction.PromoteAndEnlistDurable 是新增至 .NET Framework 4.5.2 和 4.6 的新 API:

    [System.Security.Permissions.PermissionSetAttribute(System.Security.Permissions.SecurityAction.LinkDemand, Name = "FullTrust")]
    public Enlistment PromoteAndEnlistDurable(Guid resourceManagerIdentifier,
                                              IPromotableSinglePhaseNotification promotableNotification,
                                              ISinglePhaseNotification enlistmentNotification,
                                              EnlistmentOptions enlistmentOptions)
    
    <System.Security.Permissions.PermissionSetAttribute(System.Security.Permissions.SecurityAction.LinkDemand, Name:="FullTrust")>
    public Function PromoteAndEnlistDurable(resourceManagerIdentifier As Guid,
                                            promotableNotification As IPromotableSinglePhaseNotification,
                                            enlistmentNotification As ISinglePhaseNotification,
                                            enlistmentOptions As EnlistmentOptions) As Enlistment
    

    方法可由先前由 Transaction.EnlistPromotableSinglePhase 建立的登記來使用,以回應 ITransactionPromoter.Promote 方法。 它會要求 System.Transactions 將交易升階為 MSDTC 交易,並將可促銷登記「轉換為永久性登記」。 此方法成功完成後, IPromotableSinglePhaseNotification 介面將不再被 System.Transactions引用,並且任何未來的通知都會到達提供的 ISinglePhaseNotification 介面。 有問題的登記必須作為永久性登記,支援事務歷史記錄和復原。 如需詳細資訊,請參閱 Transaction.EnlistDurable。 此外,召募必須支援 ISinglePhaseNotification。 這個方法 ITransactionPromoter.Promote 呼叫。 如果情況並非如此,則會拋出 TransactionException 例外狀況。

    .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 基底類別中的新功能和增強功能包括:

  • 元件的自動系結重新導向。 從 Visual Studio 2013 開始,當您編譯以 .NET Framework 4.5.1 為目標的應用程式時,如果您的應用程式或其元件參考相同元件的多個版本,則可能會將繫結重新導向新增至應用程式組態檔。 您也可以針對以舊版 .NET Framework 為目標的專案啟用此功能。 如需詳細資訊,請參閱 如何啟用和停用自動繫結重新導向

  • 能夠收集診斷資訊,幫助開發人員提高伺服器和雲端應用程式的效能。 如需詳細資訊,請參閱類別中的 EventSourceWriteEventWithRelatedActivityIdWriteEventWithRelatedActivityIdCore 方法。

  • 能夠在垃圾收集期間顯式壓縮大型物件堆(LOH)。 如需詳細資訊,請參閱屬性 GCSettings.LargeObjectHeapCompactionMode

  • 其他效能改善,例如 ASP.NET 應用程式暫停、多核心 JIT 改善,以及 .NET Framework 更新後更快的應用程式啟動。 如需詳細資訊,請參閱 .NET Framework 4.5.1 公告ASP.NET 應用程式暫停 部落格文章。

    Windows Forms 的改進包括:

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

  • PropertyGrid
  • TreeView
  • DataGridView 的某些方面(有關支援的其他控件,請參閱 4.5.2 中的 新功能
  • 若要啟用此功能,請將新的 <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 開始,您可以使用 受控配置檔引導式最佳化工具 (Mpgo.exe) 來優化 Windows 8.x 市集應用程式和傳統型應用程式。

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

    .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 中,受控擴充性架構 (MEF) 提供下列新功能:

  • 支援泛型型別。

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

  • 多個範圍。

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

    如需詳細資訊,請參閱 受控擴充性架構 (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 表單的模型繫結、WebSocket 支援、非同步處理常式、效能增強功能以及許多其他功能。 如需詳細資訊,請參閱下列資源:

    ASP.NET 4.5 和 Visual Studio 2012

    ASP.NET 和 Web Tools for Visual Studio 2013 發行說明

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

    此功能也包含支援使用現有的 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 文件中產生中繼資料。

  • WebSocket 支援透過連接埠 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 平台上運作的受控元件。 使用可攜式類別程式庫專案,您可以選擇要鎖定的平臺 (例如 Windows Phone 和 Windows 8.x 市集應用程式的 .NET)。 在您的專案中,可用的類型和成員會自動限制為這些平台上共同使用的類型和成員。 如需詳細資訊,請參閱 可攜式類別庫

    .NET Framework 和頻外版本
  • .NET Framework 輔助功能的最新功能 Visual Studio 2019 的新功能 ASP.NET Visual Studio 中C++的新功能 下載 .NET SDK