Nyheter i .NET Framework

  • Artikel

Anteckning

.NET Framework 4.8 är den sista versionen av .NET Framework. .NET Framework hanteras varje månad med felkorrigeringar för säkerhet och tillförlitlighet. .NET Framework kommer att fortsätta att ingå i Windows, utan några planer på att ta bort den. Du behöver inte migrera dina .NET Framework-appar, men för ny utveckling använder du .NET 5 eller senare.

Den här artikeln sammanfattar viktiga nya funktioner och förbättringar i följande versioner av .NET Framework:

Den här artikeln innehåller inte omfattande information om varje ny funktion och kan komma att ändras. Allmän information om .NET Framework finns i Komma igång. Information om plattformar som stöds finns i Systemkrav. Nedladdningslänkar och installationsinstruktioner finns i Installationsguide.

Anteckning

.NET Framework-teamet släpper även funktioner utan band, med Hjälp av NuGet, för att utöka plattformsstödet och introducera nya funktioner, till exempel oföränderliga samlingar och SIMD-aktiverade vektortyper. Mer information finns i Ytterligare klassbibliotek och API:er samt .NET Framework och out-of-band-versioner. Se en fullständig lista över NuGet-paket för .NET Framework.

Introduktion till .NET Framework 4.8

.NET Framework 4.8 bygger på tidigare versioner av .NET Framework 4.x genom att lägga till många nya korrigeringar och flera nya funktioner samtidigt som en mycket stabil produkt förblir.

Ladda ned och installera .NET Framework 4.8

Du kan ladda ned .NET Framework 4.8 från följande platser:

.NET Framework 4.8 kan installeras på Windows 10, Windows 8.1, Windows 7 SP1 och motsvarande serverplattformar från och med Windows Server 2008 R2 SP1. Du kan installera .NET Framework 4.8 med hjälp av antingen webbinstallationsprogrammet eller installationsprogrammet offline. Det rekommenderade sättet för de flesta användare är att använda webbinstallationsprogrammet.

Du kan rikta .NET Framework 4.8 i Visual Studio 2012 eller senare genom att installera .NET Framework 4.8 Developer Pack.

Nyheter i .NET Framework 4.8

.NET Framework 4.8 introducerar nya funktioner inom följande områden:

Förbättrad tillgänglighet, vilket gör att ett program kan ge en lämplig upplevelse för användare av hjälpmedelsteknik, fortsätter att vara ett stort fokus i .NET Framework 4.8. Information om hjälpmedelsförbättringar i .NET Framework 4.8 finns i Nyheter i tillgänglighet i .NET Framework.

Basklasser

Minskad FIPS-påverkan på kryptografi. I tidigare versioner av .NET Framework konfigureras hanterade kryptografiska providerklasser, till exempel SHA256Managed när CryptographicException systemets kryptografiska bibliotek konfigureras i "FIPS-läge". Dessa undantag genereras eftersom de hanterade versionerna av kryptografiska providerklasser, till skillnad från systemets kryptografiska bibliotek, inte har genomgått FIPS-certifiering (Federal Information Processing Standards) 140–2. Eftersom få utvecklare har sina utvecklingsdatorer i FIPS-läge genereras undantagen ofta i produktionssystem.

I program som är inriktade på .NET Framework 4.8 utlöser följande hanterade kryptografiklasser som standard inte längre en CryptographicException i det här fallet:

I stället omdirigerar dessa klasser kryptografiska åtgärder till ett systemkryptografibibliotek. Den här ändringen tar effektivt bort en potentiellt förvirrande skillnad mellan utvecklarmiljöer och produktionsmiljöer och gör att inbyggda komponenter och hanterade komponenter fungerar enligt samma kryptografiska princip. Program som är beroende av dessa undantag kan återställa det tidigare beteendet genom att ange AppContext-växeln Switch.System.Security.Cryptography.UseLegacyFipsThrow till true. Mer information finns i Hanterade kryptografiklasser genererar inte kryptografiException i FIPS-läge.

Användning av uppdaterad version av ZLib

Från och med .NET Framework 4.5 använder clrcompression.dll-sammansättningen ZLib, ett internt externt bibliotek för datakomprimering, för att tillhandahålla en implementering för deflate-algoritmen. .NET Framework 4.8-versionen av clrcompression.dll uppdateras för att använda ZLib version 1.2.11, som innehåller flera viktiga förbättringar och korrigeringar.

Windows Communication Foundation (WCF)

Introduktion till ServiceHealthBehavior

Hälsoslutpunkter används ofta av orkestreringsverktyg för att hantera tjänster baserat på deras hälsostatus. Hälsokontroller kan också användas av övervakningsverktyg för att spåra och ge meddelanden om tillgänglighet och prestanda för en tjänst.

ServiceHealthBehavior är ett WCF-tjänstbeteende som utökar IServiceBehavior. När en tjänst läggs till i ServiceDescription.Behaviors samlingen gör den följande:

  • Returnerar tjänstens hälsostatus med HTTP-svarskoder. Du kan ange HTTP-statuskoden för en HTTP/GET-hälsoavsökningsbegäran i en frågesträng.

  • Publicerar information om tjänstens hälsa. Tjänstspecifik information, inklusive tjänsttillstånd, begränsningsantal och kapacitet kan visas med hjälp av en HTTP/GET-begäran med frågesträngen ?health . Enkel åtkomst till sådan information är viktigt när du felsöker en WCF-tjänst som inte fungerar.

Det finns två sätt att exponera hälsoslutpunkten och publicera hälsoinformation för WCF-tjänsten:

  • Via kod. Ett exempel:

    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)

  • Genom att använda en konfigurationsfil. Ett exempel:

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

En tjänsts hälsostatus kan efterfrågas med hjälp av frågeparametrar som OnServiceFailure, OnDispatcherFailure, OnListenerFailure, OnThrottlePercentExceeded), och en HTTP-svarskod kan anges för varje frågeparameter. Om HTTP-svarskoden utelämnas för en frågeparameter används en 503 HTTP-svarskod som standard. Ett exempel:

Frågeparametrar och exempel:

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

    En 455 HTTP-svarsstatuskod returneras när tillståndet för någon av kanalutskickarna är större än CommunicationState.Opened.

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

    En 465 HTTP-svarsstatuskod returneras när tillståndet för någon av kanallyssnare är större än CommunicationState.Opened.

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

    Anger procentandelen {1 – 100} som utlöser svaret och dess HTTP-svarskod {200 – 599}. I det här exemplet:

    • Om procentandelen är större än 95 returneras en HTTP-svarskod på 500.

    • Om procentandelen är mellan 70 och 95 returneras 350.

    • Annars returneras 200.

Tjänstens hälsostatus kan visas antingen i HTML genom att ange en frågesträng som https://contoso:81/Service1?health eller i XML genom att ange en frågesträng som https://contoso:81/Service1?health&Xml. En frågesträng som https://contoso:81/Service1?health&NoContent returnerar en tom HTML-sida.

Windows Presentation Foundation (WPF)

Förbättringar av hög DPI

I .NET Framework 4.8 lägger WPF till stöd för Per-Monitor V2 DPI Awareness och Mixed-Mode DPI-skalning. Mer information om hög DPI-utveckling för skrivbordsprogram finns i Windows om hög DPI-utveckling.

.NET Framework 4.8 förbättrar stödet för värdbaserade HWND:ar och Windows Forms interoperation i WPF-program med hög DPI på plattformar som stöder Mixed-Mode DPI-skalning (från och med Windows 10 uppdatering i april 2018). När värdbaserade HWND:er eller Windows Forms kontroller skapas som Mixed-Mode DPI-skalade fönster genom att anropa SetThreadDpiHostingBehavior och SetThreadDpiAwarenessContext, kan de finnas i ett Per-Monitor V2 WPF-program och har lämplig storlek och skalning. Sådant värdbaserat innehåll återges inte i det interna DPI:et. I stället skalar operativsystemet värdbaserat innehåll till rätt storlek. Stödet för Per-Monitor v2 DPI-medvetenhetsläge gör också att WPF-kontroller kan finnas (dvs. överordnad) i ett internt fönster i ett hög-DPI-program.

Om du vill aktivera stöd för Mixed-Mode hög DPI-skalning kan du ange följande AppContext-växlar programkonfigurationsfilen:

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

Common Language Runtime

Körningen i .NET Framework 4.8 innehåller följande ändringar och förbättringar:

Förbättringar av JIT-kompilatorn. JIT-kompilatorn (Just-in-time) i .NET Framework 4.8 baseras på JIT-kompilatorn i .NET Core 2.1. Många av optimeringarna och alla felkorrigeringar som görs i JIT-kompilatorn för .NET Core 2.1 ingår i JIT-kompilatorn .NET Framework 4.8.

NGEN-förbättringar. Körningen har förbättrat minneshanteringen för NGEN-avbildningar ( Native Image Generator ) så att data som mappas från NGEN-avbildningar inte är minnesbaserade. Detta minskar den yta som är tillgänglig för attacker som försöker köra godtycklig kod genom att ändra minne som ska köras.

Genomsökning av program mot skadlig kod efter alla sammansättningar. I tidigare versioner av .NET Framework genomsöker körningen alla sammansättningar som lästs in från disken med antingen Windows Defender eller programvara mot skadlig kod från tredje part. Sammansättningar som läses in från andra källor, till exempel med Assembly.Load(Byte[]) metoden, genomsöks dock inte och kan potentiellt innehålla oupptäckt skadlig kod. Från och med .NET Framework 4.8 som körs på Windows 10 utlöser körningen en genomsökning av program mot skadlig kod som implementerar AMSI (Antimalware Scan Interface).

Nyheter i .NET Framework 4.7.2

.NET Framework 4.7.2 innehåller nya funktioner inom följande områden:

Ett fortsatt fokus i .NET Framework 4.7.2 är förbättrad tillgänglighet, vilket gör att ett program kan ge en lämplig upplevelse för användare av assistiv teknik. Information om hjälpmedelsförbättringar i .NET Framework 4.7.2 finns i Nyheter om hjälpmedel i .NET Framework.

Basklasser

.NET Framework 4.7.2 har ett stort antal kryptografiska förbättringar, bättre dekomprimeringsstöd för ZIP-arkiv och ytterligare samlings-API:er.

Nya överlagringar av RSA. Skapa och DSA. Skapa

Med DSA.Create(DSAParameters) metoderna och RSA.Create(RSAParameters) kan du ange nyckelparametrar när du instansierar en ny DSA eller RSA nyckel. De gör att du kan ersätta kod som följande:

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

med kod som den här:

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

Med DSA.Create(Int32) metoderna och RSA.Create(Int32) kan du generera nya DSA nycklar eller RSA nycklar med en specifik nyckelstorlek. Ett exempel:

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-konstruktorer accepterar ett hash-algoritmnamn

Klassen Rfc2898DeriveBytes har tre nya konstruktorer med en HashAlgorithmName parameter som identifierar HMAC-algoritmen som ska användas vid härledning av nycklar. I stället för att använda SHA-1 bör utvecklare använda en SHA-2-baserad HMAC som SHA-256, som du ser i följande exempel:

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

Stöd för tillfälliga nycklar

PFX-import kan också läsa in privata nycklar direkt från minnet och kringgå hårddisken. När den nya X509KeyStorageFlags.EphemeralKeySet flaggan anges i en X509Certificate2 konstruktor eller någon av överlagringarna av X509Certificate2.Import metoden läses de privata nycklarna in som tillfälliga nycklar. Detta förhindrar att nycklarna visas på disken. Observera följande:

  • Eftersom nycklarna inte sparas på disken är certifikat som läses in med den här flaggan inte lämpliga kandidater att lägga till i en X509Store.

  • Nycklar som läses in på detta sätt läses nästan alltid in via Windows CNG. Anropare måste därför komma åt den privata nyckeln genom att anropa tilläggsmetoder, till exempel certifikat. GetRSAPrivateKey(). Egenskapen X509Certificate2.PrivateKey fungerar inte.

  • Eftersom den äldre X509Certificate2.PrivateKey egenskapen inte fungerar med certifikat bör utvecklare utföra rigorös testning innan de växlar till tillfälliga nycklar.

Programmatiskt skapande av PKCS#10-certifieringssigneringsbegäranden och X.509-certifikat för offentlig nyckel

Från och med .NET Framework 4.7.2 kan arbetsbelastningar generera certifikatsigneringsbegäranden (CSR), vilket gör att generering av certifikatbegäranden mellanlagras till befintliga verktyg. Detta är ofta användbart i testscenarier.

Mer information och kodexempel finns i "Programmatiskt skapande av PKCS#10-certifieringssigneringsbegäranden och X.509-certifikat för offentlig nyckel" i .NET-bloggen.

Nya SignerInfo-medlemmar

Från och med .NET Framework 4.7.2 SignerInfo visar klassen mer information om signaturen. Du kan hämta värdet för System.Security.Cryptography.Pkcs.SignerInfo.SignatureAlgorithm egenskapen för att fastställa signaturalgoritmen som används av undertecknaren. SignerInfo.GetSignature kan anropas för att hämta en kopia av den kryptografiska signaturen för den här undertecknaren.

Lämna en omsluten ström öppen efter att CryptoStream har kasserats

Från och med .NET Framework 4.7.2 CryptoStream har klassen ytterligare en konstruktor som gör det möjligt Dispose att inte stänga den omslutna dataströmmen. Om du vill lämna den omslutna dataströmmen öppen efter att instansen CryptoStream har kasserats anropar du den nya CryptoStream konstruktorn på följande sätt:

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

Dim cStream = New CryptoStream(stream, transform, mode, leaveOpen:=true)

Dekomprimeringsändringar i DeflateStream

Från och med .NET Framework 4.7.2 har implementeringen av dekomprimeringsåtgärder i DeflateStream klassen ändrats till att använda interna Windows-API:er som standard. Detta resulterar vanligtvis i en betydande prestandaförbättring.

Stöd för dekomprimering med hjälp av Windows-API:er är aktiverat som standard för program som har .NET Framework 4.7.2 som mål. Program som riktar sig mot tidigare versioner av .NET Framework men som körs under .NET Framework 4.7.2 kan välja det här beteendet genom att lägga till följande AppContext-växel i programkonfigurationsfilen:

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

Ytterligare samlings-API:er

.NET Framework 4.7.2 lägger till ett antal nya API:er till typerna SortedSet<T> och HashSet<T> . Dessa omfattar:

Klassen ConcurrentDictionary<TKey,TValue> innehåller nya överlagringar av AddOrUpdate metoderna och GetOrAdd för att hämta ett värde från ordlistan eller lägga till det om det inte hittas, och för att lägga till ett värde i ordlistan eller uppdatera det om det redan finns.

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

Stöd för beroendeinmatning i Web Forms

Beroendeinmatning (DI) frikopplar objekt och deras beroenden så att ett objekts kod inte längre behöver ändras bara för att ett beroende har ändrats. När du utvecklar ASP.NET program som är inriktade på .NET Framework 4.7.2 kan du:

Stöd för cookies på samma webbplats

SameSite förhindrar att en webbläsare skickar en cookie tillsammans med en begäran mellan webbplatser. .NET Framework 4.7.2 lägger till en HttpCookie.SameSite egenskap vars värde är en System.Web.SameSiteMode uppräkningsmedlem. Om dess värde är SameSiteMode.Strict eller SameSiteMode.Laxlägger SameSite ASP.NET till attributet i set-cookie-huvudet. SameSite-stöd gäller för HttpCookie både objekt och FormsAuthenticationSystem.Web.SessionState cookies.

Du kan ange SameSite för ett HttpCookie objekt på följande sätt:

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

Dim c As New HttpCookie("secureCookie", "same origin")
c.SameSite = SameSiteMode.Lax

Du kan också konfigurera SameSite-cookies på programnivå genom att ändra web.config-filen:

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

Du kan lägga till SameSite för FormsAuthentication och System.Web.SessionState cookies genom att ändra webbkonfigurationsfilen:

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

Nätverk

Implementering av HttpClientHandler-egenskaper

.NET Framework 4.7.1 har lagt till åtta egenskaper i System.Net.Http.HttpClientHandler klassen. Två kastade dock en PlatformNotSupportedException. .NET Framework 4.7.2 tillhandahåller nu en implementering för dessa egenskaper. Egenskaperna är:

SQLClient

Stöd för Azure Active Directory universell autentisering och multifaktorautentisering

Växande krav på efterlevnad och säkerhet kräver att många kunder använder multifaktorautentisering (MFA). Dessutom avråder aktuella metodtips från att inkludera användarlösenord direkt i anslutningssträngar. För att stödja dessa ändringar utökar .NET Framework 4.7.2 SQLClient-anslutningssträngar genom att lägga till ett nytt värde, "Active Directory Interactive", för det befintliga nyckelordet "Autentisering" för att stödja MFA- och Azure AD-autentisering. Den nya interaktiva metoden stöder interna och federerade Azure AD-användare samt Azure AD-gästanvändare. När den här metoden används stöds MFA-autentiseringen som införts av Azure AD för SQL databaser. Dessutom begär autentiseringsprocessen ett användarlösenord för att följa rekommenderade säkerhetsmetoder.

I tidigare versioner av .NET Framework stöds endast SqlAuthenticationMethod.ActiveDirectoryPassword alternativen och SqlAuthenticationMethod.ActiveDirectoryIntegrated SQL anslutning. Båda dessa ingår i det icke-interaktiva ADAL-protokollet, som inte stöder MFA. Med det nya SqlAuthenticationMethod.ActiveDirectoryInteractive alternativet stöder SQL anslutning MFA samt befintliga autentiseringsmetoder (lösenord och integrerad autentisering), vilket gör att användarna kan ange användarlösenord interaktivt utan att spara lösenord i anslutningssträngen.

Mer information och ett exempel finns i "SQL – Stöd för Azure AD Universal- och Multifactor-autentisering" i .NET-bloggen.

Stöd för Always Encrypted version 2

NET Framework 4.7.2 lägger till stöd för enklaverbaserade Always Encrypted. Den ursprungliga versionen av Always Encrypted är en krypteringsteknik på klientsidan där krypteringsnycklar aldrig lämnar klienten. I enklaverbaserade Always Encrypted kan klienten också skicka krypteringsnycklarna till en säker enklav, vilket är en säker beräkningsentitet som kan betraktas som en del av SQL Server men som SQL Server inte kan manipuleras. För att stödja enklaverbaserade Always Encrypted lägger .NET Framework 4.7.2 till följande typer och medlemmar i System.Data.SqlClient namnområdet:

Programkonfigurationsfilen anger sedan en konkret implementering av den abstrakta System.Data.SqlClient.SqlColumnEncryptionEnclaveProvider klassen som tillhandahåller funktionerna för enklavens provider. Ett exempel:

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

Det grundläggande flödet av enklaverbaserade Always Encrypted är:

  1. Användaren skapar en AlwaysEncrypted-anslutning till SQL Server som stöds av enklaverbaserade Always Encrypted. Drivrutinen kontaktar attesteringstjänsten för att säkerställa att den ansluter till rätt enklav.

  2. När enklaven har intygats etablerar föraren en säker kanal med den säkra enklaven som finns på SQL Server.

  3. Drivrutinen delar krypteringsnycklar som godkänts av klienten med den säkra enklaven under den SQL anslutningen.

Windows Presentation Foundation

Hitta ResourceDictionaries efter källa

Från och med .NET Framework 4.7.2 kan en diagnostikassistent hitta de ResourceDictionaries som har skapats från en viss käll-URI. (Den här funktionen används av diagnostikassistenter, inte av produktionsprogram.) Med en diagnostikassistent som Visual Studio "Redigera och fortsätt" kan användaren redigera en ResourceDictionary med avsikten att ändringarna ska tillämpas på det program som körs. Ett steg för att uppnå detta är att hitta alla ResourceDictionaries som programmet som körs har skapat från ordlistan som redigeras. Ett program kan till exempel deklarera en ResourceDictionary vars innehåll kopieras från en viss käll-URI:

<ResourceDictionary Source="MyRD.xaml" />

En diagnostikassistent som redigerar den ursprungliga markeringen i MyRD.xaml kan använda den nya funktionen för att hitta ordlistan. Funktionen implementeras med en ny statisk metod, ResourceDictionaryDiagnostics.GetResourceDictionariesForSource. Diagnostikassistenten anropar den nya metoden med en absolut URI som identifierar den ursprungliga markeringen, vilket illustreras av följande kod:

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

Metoden returnerar en tom uppräkningsbar om den inte VisualDiagnostics är aktiverad och ENABLE_XAML_DIAGNOSTICS_SOURCE_INFO miljövariabeln har angetts.

Hitta ResourceDictionary-ägare

Från och med .NET Framework 4.7.2 kan en diagnostikassistent hitta ägarna till en viss ResourceDictionary. (Funktionen är avsedd för användning av diagnostikassistenter och inte av produktionsprogram.) När en ändring görs i en ResourceDictionary, hittar WPF automatiskt alla DynamicResource-referenser som kan påverkas av ändringen.

En diagnostikassistent, till exempel Visual Studio's "Edit-and-Continue"-anläggning, kanske vill utöka detta för att hantera StaticResource-referenser. Det första steget i den här processen är att hitta ordlistans ägare. för att hitta alla objekt vars Resources egenskap refererar till ordlistan (antingen direkt eller indirekt via ResourceDictionary.MergedDictionaries egenskapen). Tre nya statiska metoder som implementerats på System.Windows.Diagnostics.ResourceDictionaryDiagnostics klassen, en för var och en av de bastyper som har en Resources egenskap, stöder det här steget:

Dessa metoder returnerar en tom uppräkning såvida inte VisualDiagnostics aktiverad och ENABLE_XAML_DIAGNOSTICS_SOURCE_INFO miljövariabeln har angetts.

Hitta StaticResource-referenser

En diagnostikassistent kan nu få ett meddelande när en StaticResource-referens matchas. (Funktionen används av diagnostikassistenter, inte av produktionsprogram.) En diagnostikassistent, till exempel Visual Studio:s "Redigera och fortsätt"-anläggning, kanske vill uppdatera alla användningsområden för en resurs när dess värde i en ResourceDictionary ändring. WPF gör detta automatiskt för DynamicResource-referenser , men det gör det avsiktligt inte för StaticResource-referenser . Från och med .NET Framework 4.7.2 kan diagnostikassistenten använda dessa meddelanden för att hitta dessa användningsområden för den statiska resursen.

Meddelandet implementeras av den nya ResourceDictionaryDiagnostics.StaticResourceResolved händelsen:

public static event EventHandler<StaticResourceResolvedEventArgs> StaticResourceResolved;

Public Shared Event StaticResourceResolved As EventHandler(Of StaticResourceResolvedEventArgs)

Den här händelsen aktiveras när körningen löser en StaticResource-referens . Argumenten StaticResourceResolvedEventArgs beskriver lösningen och anger objektet och egenskapen som är värd för StaticResource-referensen och och ResourceDictionary nyckeln som används för lösningen:

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

Händelsen aktiveras inte (och dess add accessor ignoreras) om den inte VisualDiagnostics är aktiverad och ENABLE_XAML_DIAGNOSTICS_SOURCE_INFO miljövariabeln har angetts.

ClickOnce

HDPI-medvetna program för Windows Forms, Windows Presentation Foundation (WPF) och Visual Studio Tools for Office (VSTO) kan alla distribueras med hjälp av ClickOnce. Om följande post hittas i programmanifestet lyckas distributionen under .NET Framework 4.7.2:

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

För Windows Forms program är den tidigare lösningen med att ange DPI-medvetenhet i programkonfigurationsfilen i stället för programmanifestet inte längre nödvändig för att ClickOnce distributionen ska lyckas.

Nyheter i .NET Framework 4.7.1

.NET Framework 4.7.1 innehåller nya funktioner inom följande områden:

Dessutom är ett stort fokus i .NET Framework 4.7.1 förbättrad tillgänglighet, vilket gör att ett program kan ge en lämplig upplevelse för användare av assistiv teknik. Information om hjälpmedelsförbättringar i .NET Framework 4.7.1 finns i Nyheter i tillgänglighet i .NET Framework.

Basklasser

Stöd för .NET Standard 2.0

.NET Standard definierar en uppsättning API:er som måste vara tillgängliga för varje .NET-implementering som stöder den versionen av standarden. .NET Framework 4.7.1 har fullt stöd för .NET Standard 2.0 och lägger till cirka 200 API:er som definieras i .NET Standard 2.0 och saknas i .NET Framework 4.6.1, 4.6.2 och 4.7. (Observera att dessa versioner av .NET Framework endast stöder .NET Standard 2.0 om ytterligare .NET Standard-supportfiler också distribueras i målsystemet.) Mer information finns i blogginlägget "BCL – .NET Standard 2.0 Support" i blogginlägget .NET Framework 4.7.1 Runtime and Compiler Features.

Stöd för konfigurationsbyggare

Med konfigurationsbyggare kan utvecklare mata in och skapa konfigurationsinställningar för program dynamiskt vid körning. Anpassade konfigurationsbyggare kan användas för att ändra befintliga data i ett konfigurationsavsnitt eller för att skapa ett konfigurationsavsnitt helt från grunden. Utan konfigurationsbyggare är .config filer statiska och deras inställningar definieras en tid innan ett program startas.

Om du vill skapa en anpassad konfigurationsbyggare härleder du byggverktyget från den abstrakta ConfigurationBuilder klassen och åsidosätter dess ConfigurationBuilder.ProcessConfigurationSection och ConfigurationBuilder.ProcessRawXml. Du definierar även dina byggare i .config-filen. Mer information finns i blogginlägget "Configuration Builders" i blogginlägget .NET Framework 4.7.1 ASP.NET och Configuration Features.

Identifiering av körningsfunktioner

Klassen System.Runtime.CompilerServices.RuntimeFeature tillhandahåller en mekanism för att avgöra om en fördefinierad funktion stöds vid en viss .NET-implementering vid kompileringstid eller körning. Vid kompileringstillfället kan en kompilator kontrollera om det finns ett angivet fält för att avgöra om funktionen stöds. I så fall kan den generera kod som drar nytta av den funktionen. Vid körning kan ett program anropa RuntimeFeature.IsSupported metoden innan kod genereras vid körning. Mer information finns i Lägga till hjälpmetod för att beskriva funktioner som stöds av körningen.

Värdetupppeltyper är serialiserbara

Från och med .NET Framework 4.7.1 System.ValueTuple och dess associerade generiska typer markeras som Serializable, vilket tillåter binär serialisering. Detta bör göra det enklare att migrera tuppelns typer, till exempel Tuple<T1,T2,T3> och Tuple<T1,T2,T3,T4>, för att värdera tuppelns typer. Mer information finns i blogginlägget "Compiler -- ValueTuple is Serializable" i blogginlägget "Compiler -- ValueTuple is Serializable" i blogginlägget .NET Framework 4.7.1 Runtime and Compiler Features.

Stöd för skrivskyddade referenser

.NET Framework 4.7.1 lägger till System.Runtime.CompilerServices.IsReadOnlyAttribute. Det här attributet används av språkkompilatorer för att markera medlemmar som har skrivskyddade referensreturtyper eller parametrar. Mer information finns i blogginlägget "Compiler - Support for ReadOnlyReferences" i blogginlägget "Compiler - Support for ReadOnlyReferences" i blogginlägget .NET Framework 4.7.1 Runtime and Compiler Features. Information om referensreturvärden finns i Ref return values and ref locals (C#Guide) and Ref return values (Visual Basic).

CLR (Common language runtime)

Prestandaförbättringar för skräpinsamling

Ändringar av skräpinsamling (GC) i .NET Framework 4.7.1 förbättrar övergripande prestanda, särskilt för loh-allokeringar (large object heap). I .NET Framework 4.7.1 används separata lås för soh-tilldelningar (small object heap) och LOH, vilket gör att LOH-allokeringar kan ske när bakgrunds-GC sveper över SOH. Därför bör program som gör ett stort antal LOH-allokeringar se en minskning av allokeringslåskonkurration och bättre prestanda. Mer information finns i avsnittet "Körning – prestandaförbättringar för GC" i blogginlägget .NET Framework 4.7.1 Runtime and Compiler Features( Körnings- och kompilatorfunktioner).

Nätverk

SHA-2-stöd för Message.HashAlgorithm

I .NET Framework 4.7 och tidigare versioner stöds värdena HashAlgorithm.Md5 för och HashAlgorithm.Sha endast för egenskapenMessage.HashAlgorithm. Från och med .NET Framework 4.7.1, HashAlgorithm.Sha256, HashAlgorithm.Sha384och HashAlgorithm.Sha512 stöds också. Om det här värdet faktiskt används beror på MSMQ, eftersom själva instansen Message inte hashar utan bara skickar värden till MSMQ. Mer information finns i avsnittet "SHA-2-stöd för Message.HashAlgorithm" i blogginlägget .NET Framework 4.7.1 ASP.NET- och konfigurationsfunktioner.

ASP.NET

Körningssteg i ASP.NET program

ASP.NET bearbetar begäranden i en fördefinierad pipeline som innehåller 23 händelser. ASP.NET kör varje händelsehanterare som ett körningssteg. I versioner av ASP.NET upp till .NET Framework 4.7 kan ASP.NET inte flöda körningskontexten på grund av växling mellan interna och hanterade trådar. I stället ASP.NET endast HttpContextflödar selektivt . Från och med .NET Framework 4.7.1 HttpApplication.OnExecuteRequestStep(Action<HttpContextBase,Action>) tillåter metoden även moduler att återställa omgivande data. Den här funktionen är avsedd för bibliotek som handlar om spårning, profilering, diagnostik eller transaktioner, till exempel som bryr sig om programmets körningsflöde. Mer information finns i blogginlägget "ASP.NET körningssteg" i blogginlägget .NET Framework 4.7.1 ASP.NET och konfigurationsfunktioner.

ASP.NET HttpCookie-parsning

.NET Framework 4.7.1 innehåller en ny metod, HttpCookie.TryParse, som ger ett standardiserat sätt att skapa ett HttpCookie objekt från en sträng och korrekt tilldela cookievärden, till exempel förfallodatum och sökväg. Mer information finns i blogginlägget "ASP.NET HttpCookie parsing" i blogginlägget .NET Framework 4.7.1 ASP.NET och Configuration Features.

SHA-2-hashalternativ för ASP.NET formulär för autentiseringsuppgifter

I .NET Framework 4.7 och tidigare versioner tillät ASP.NET utvecklare att lagra användarautentiseringsuppgifter med hashade lösenord i konfigurationsfiler med md5 eller SHA1. Från och med .NET Framework 4.7.1 stöder ASP.NET även nya säkra SHA-2-hashalternativ som SHA256, SHA384 och SHA512. SHA1 förblir standard och en hash-algoritm som inte är standard kan definieras i webbkonfigurationsfilen. Ett exempel:

<system.web>
    <authentication mode="Forms">
        <forms loginUrl="~/login.aspx">
          <credentials passwordFormat="SHA512">
            <user name="jdoe" password="6D003E98EA1C7F04ABF8FCB375388907B7F3EE06F278DB966BE960E7CBBD103DF30CA6D61F7E7FD981B2E4E3A64D43C836A4BEDCA165C33B163E6BCDC538A664" />
          </credentials>
        </forms>
    </authentication>
</system.web>

Nyheter i .NET Framework 4.7

.NET Framework 4.7 innehåller nya funktioner inom följande områden:

En lista över nya API:er som lagts till i .NET Framework 4.7 finns i .NET Framework 4.7 API-ändringar på GitHub. En lista över funktionsförbättringar och felkorrigeringar i .NET Framework 4.7 finns i .NET Framework 4.7 Lista över ändringar på GitHub. Mer information finns i Meddelande om .NET Framework 4.7 i .NET-bloggen.

Basklasser

.NET Framework 4.7 förbättrar serialiseringen med DataContractJsonSerializer:

Förbättrade funktioner med Elliptic Curve Cryptography (ECC)*

I .NET Framework 4.7 ImportParameters(ECParameters) lades metoder till i klasserna ECDsa och ECDiffieHellman så att ett objekt kan representera en redan etablerad nyckel. En ExportParameters(Boolean) metod har också lagts till för att exportera nyckeln med explicita kurvparametrar.

.NET Framework 4.7 lägger också till stöd för ytterligare kurvor (inklusive Brainpool-kurvan) och har lagt till fördefinierade definitioner för enkel skapande via de nya Create metoderna och Create fabriksmetoderna.

Du kan se ett exempel på .NET Framework 4.7-kryptografiförbättringar på GitHub.

Bättre stöd för kontrolltecken från DataContractJsonSerializer

I .NET Framework 4.7 DataContractJsonSerializer serialiserar klassen kontrolltecken i överensstämmelse med ECMAScript 6-standarden. Det här beteendet är aktiverat som standard för program som riktar sig till .NET Framework 4.7 och är en funktion för att välja program som körs under .NET Framework 4.7 men som är inriktad på en tidigare version av .NET Framework. Mer information finns i avsnittet Programkompatibilitet .

Nätverk

.NET Framework 4.7 lägger till följande nätverksrelaterade funktion:

Standardstöd för operativsystemet för TLS-protokoll*

TLS-stacken, som används av System.Net.Security.SslStream och up-stack-komponenter som HTTP, FTP och SMTP, gör det möjligt för utvecklare att använda standardprotokollen för TLS som stöds av operativsystemet. Utvecklare behöver inte längre hårdkoda en TLS-version.

ASP.NET

I .NET Framework 4.7 innehåller ASP.NET följande nya funktioner:

Utökningsbarhet för objektcache

Från och med .NET Framework 4.7 lägger ASP.NET till en ny uppsättning API:er som gör att utvecklare kan ersätta standardimplementeringar ASP.NET för minnesintern cachelagring och minnesövervakning. Utvecklare kan nu ersätta någon av följande tre komponenter om ASP.NET implementeringen inte är tillräcklig:

  • Objektcachelagring. Med hjälp av det nya konfigurationsavsnittet för cacheproviders kan utvecklare ansluta nya implementeringar av en objektcache för ett ASP.NET program med hjälp av det nya ICacheStoreProvider-gränssnittet.

  • Minnesövervakning. Standardminnesövervakaren i ASP.NET meddelar program när de körs nära den konfigurerade gränsen för privata byte för processen, eller när datorn har ont om totalt tillgängligt fysiskt RAM-minne. När dessa gränser är nära utlöses meddelanden. För vissa program utlöses meddelanden för nära de konfigurerade gränserna för att möjliggöra användbara reaktioner. Utvecklare kan nu skriva egna minnesövervakare för att ersätta standardvärdet med hjälp ApplicationMonitors.MemoryMonitor av egenskapen .

  • Minnesgränsreaktioner. Som standard försöker ASP.NET trimma objektcachen och anropa regelbundet GC.Collect när den privata byteprocessgränsen är nära. För vissa program är frekvensen för anrop till GC.Collect eller mängden cache som trimmas ineffektiv. Utvecklare kan nu ersätta eller komplettera standardbeteendet genom att prenumerera på IObserver-implementeringar till programmets minnesövervakare.

Windows Communication Foundation (WCF)

Windows Communication Foundation (WCF) lägger till följande funktioner och ändringar:

Möjlighet att konfigurera standardinställningarna för meddelandesäkerhet till TLS 1.1 eller TLS 1.2

Från och med .NET Framework 4.7 kan du med WCF konfigurera TLS 1.1 eller TLS 1.2 utöver SSL 3.0 och TLS 1.0 som standardprotokoll för meddelandesäkerhet. Det här är en inställning för att välja. om du vill aktivera den måste du lägga till följande post i programkonfigurationsfilen:

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

Förbättrad tillförlitlighet för WCF-program och WCF-serialisering

WCF innehåller ett antal kodändringar som eliminerar konkurrensförhållanden, vilket förbättrar prestanda och tillförlitligheten för serialiseringsalternativ. Dessa omfattar:

  • Bättre stöd för att blanda asynkron och synkron kod i anrop till SocketConnection.BeginRead och SocketConnection.Read.
  • Förbättrad tillförlitlighet när du avbryter en anslutning med SharedConnectionListener och DuplexChannelBinder.
  • Förbättrad tillförlitlighet för serialiseringsåtgärder vid anrop av FormatterServices.GetSerializableMembers(Type) metoden.
  • Förbättrad tillförlitlighet när du tar bort en servitör genom att anropa metoden ChannelSynchronizer.RemoveWaiter .

Windows Forms

I .NET Framework 4.7 förbättrar Windows Forms stödet för höga DPI-övervakare.

Stöd för hög DPI

Från och med program som riktar sig till .NET Framework 4.7 har .NET Framework högt DPI- och dynamiskt DPI-stöd för Windows Forms program. Stöd för hög DPI förbättrar layouten och utseendet på formulär och kontroller på höga DPI-bildskärmar. Dynamisk DPI ändrar layout och utseende för formulär och kontroller när användaren ändrar DPI eller visar skalningsfaktorn för ett program som körs.

Stöd för hög DPI är en opt-in-funktion som du konfigurerar genom att definiera en <System.Windows. Avsnittet Forms.ConfigurationSection> i programkonfigurationsfilen. Mer information om hur du lägger till högt DPI-stöd och dynamiskt DPI-stöd för ditt Windows Forms-program finns i Hög DPI-support i Windows Forms.

Windows Presentation Foundation (WPF)

I .NET Framework 4.7 innehåller WPF följande förbättringar:

Stöd för en touch/stylus-stack baserat på Windows WM_POINTER meddelanden

Nu har du möjlighet att använda en pek-/pennastack baserat på WM_POINTER meddelanden i stället för WISP (Windows Ink Services Platform). Det här är en opt-in-funktion i .NET Framework. Mer information finns i avsnittet Programkompatibilitet .

Ny implementering för WPF-utskrifts-API:er

WPF:s utskrifts-API:er i System.Printing.PrintQueue klassen anropar API:et Windows Print Document Package i stället för det inaktuella XPS Print-API:et. Information om hur den här ändringen påverkar programkompatibiliteten finns i avsnittet Programkompatibilitet .

Nyheter i .NET Framework 4.6.2

.NET Framework 4.6.2 innehåller nya funktioner inom följande områden:

En lista över nya API:er som lagts till i .NET Framework 4.6.2 finns i .NET Framework 4.6.2 API-ändringar på GitHub. En lista över funktionsförbättringar och felkorrigeringar i .NET Framework 4.6.2 finns i .NET Framework 4.6.2 Lista över ändringar på GitHub. Mer information finns i Meddelande .NET Framework 4.6.2 i .NET-bloggen.

ASP.NET

I .NET Framework 4.6.2 innehåller ASP.NET följande förbättringar:

Förbättrat stöd för lokaliserade felmeddelanden i dataanteckningsverifierare

Med validerare för dataanteckning kan du utföra validering genom att lägga till ett eller flera attribut i en klassegenskap. Attributets ValidationAttribute.ErrorMessage element definierar texten i felmeddelandet om verifieringen misslyckas. Från och med .NET Framework 4.6.2 ASP.NET gör det enkelt att lokalisera felmeddelanden. Felmeddelanden kommer att lokaliseras om:

  1. ValidationAttribute.ErrorMessage anges i verifieringsattributet.

  2. Resursfilen lagras i mappen App_LocalResources.

  3. Namnet på den lokaliserade resursfilen har formulärnamnet}.resxDataAnnotation.Localization.{, där namnet är ett kulturnamn i formatet languageCodecountry-/regionCode eller languageCode.

  4. Resursens nyckelnamn är den sträng som tilldelats attributet ValidationAttribute.ErrorMessage och dess värde är det lokaliserade felmeddelandet.

Följande dataanteckningsattribut definierar till exempel standardkulturens felmeddelande för ett ogiltigt omdöme.

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

Du kan sedan skapa en resursfil, DataAnnotation.Localization.fr.resx, vars nyckel är felmeddelandesträngen och vars värde är det lokaliserade felmeddelandet. Filen måste hittas i App.LocalResources mappen. Följande är till exempel nyckeln och dess värde i ett lokaliserat franskt (fr)-felmeddelande:

Name Värde
Klassificeringen måste vara mellan 1 och 10. La note doit être består av entre 1 et 10.

Dessutom är lokalisering av dataanteckning utökningsbar. Utvecklare kan ansluta sin egen stränglokaliserarprovider genom att implementera IStringLocalizerProvider gränssnittet för att lagra lokaliseringssträngar någon annanstans än i en resursfil.

Async-stöd med sessionstillståndslagerleverantörer

ASP.NET tillåter nu att uppgiftsreturmetoder används med sessionstillståndslagerleverantörer, vilket gör det möjligt för ASP.NET appar att få skalbarhetsfördelarna med asynkronisering. För att stödja asynkrona åtgärder med sessionstillståndslagerproviders innehåller ASP.NET ett nytt gränssnitt, System.Web.SessionState.ISessionStateModule, som ärver från IHttpModule och gör det möjligt för utvecklare att implementera sin egen sessionstillståndsmodul och asynkrona sessionslagringsproviders. Gränssnittet definieras på följande sätt:

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

Dessutom SessionStateUtility innehåller klassen två nya metoder, IsSessionStateReadOnly och IsSessionStateRequired, som kan användas för asynkrona åtgärder.

Async-stöd för output-cache-providers

Från och med .NET Framework 4.6.2 kan uppgiftsreturmetoder användas med utdatacacheprovidrar för att ge skalbarhetsfördelarna med async. Leverantörer som implementerar dessa metoder minskar trådblockering på en webbserver och förbättrar skalbarheten för en ASP.NET tjänst.

Följande API:er har lagts till för att stödja asynkrona utdatacacheproviders:

Teckenkategorier

Tecken i .NET Framework 4.6.2 klassificeras baserat på Unicode Standard, version 8.0.0. I .NET Framework 4.6 och .NET Framework 4.6.1 klassificerades tecken baserat på Unicode 6.3-teckenkategorier.

Stödet för Unicode 8.0 är begränsat till klassificeringen av tecken efter CharUnicodeInfo klassen och till typer och metoder som är beroende av den. Dessa inkluderar StringInfo klassen, den överlagrade Char.GetUnicodeCategory metoden och de teckenklasser som identifieras av .NET Framework motor för reguljära uttryck. Tecken- och strängjämförelse och sortering påverkas inte av den här ändringen och fortsätter att förlita sig på det underliggande operativsystemet eller, på Windows 7-system, på teckendata som tillhandahålls av .NET Framework.

Ändringar i teckenkategorier från Unicode 6.0 till Unicode 7.0 finns i Unicode Standard, version 7.0.0 på Unicode Consortiums webbplats. För ändringar från Unicode 7.0 till Unicode 8.0, se Unicode Standard, version 8.0.0 på Unicode Consortiums webbplats.

Kryptografi

Stöd för X509-certifikat som innehåller FIPS 186-3 DSA

.NET Framework 4.6.2 lägger till stöd för DSA-certifikat (digital signaturalgoritm) X509-certifikat vars nycklar överskrider FIPS 186-2 1024-bitarsgränsen.

Förutom att stödja de större nyckelstorlekarna i FIPS 186-3 tillåter .NET Framework 4.6.2 databehandlingssignaturer med SHA-2-serien med hashalgoritmer (SHA256, SHA384 och SHA512). FIPS 186-3-stöd tillhandahålls av den nya System.Security.Cryptography.DSACng klassen.

I enlighet med de senaste ändringarna RSA i klassen i .NET Framework 4.6 och ECDsa klassen i .NET Framework 4.6.1 har den DSA abstrakta basklassen i .NET Framework 4.6.2 ytterligare metoder för att tillåta anropare att använda den här funktionen utan att casta. Du kan anropa DSACertificateExtensions.GetDSAPrivateKey tilläggsmetoden för att signera data, vilket visas i följande exempel.

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

Och du kan anropa DSACertificateExtensions.GetDSAPublicKey tilläggsmetoden för att verifiera signerade data, som i följande exempel visas.

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

Ökad tydlighet för indata till ECDiffieHellman-nyckelhärledningsrutiner

.NET Framework 3.5 lade till stöd för Elliptic Curve Diffie-Hellman Key Agreement med tre olika KDF-rutiner (Key Derivation Function). Indata till rutinerna och själva rutinerna konfigurerades via egenskaper för ECDiffieHellmanCng objektet. Men eftersom inte varje rutin läser varje indataegenskap fanns det gott om utrymme för förvirring om utvecklarens förflutna.

För att åtgärda detta i .NET Framework 4.6.2 har följande tre metoder lagts till i basklassen ECDiffieHellman för att tydligare representera dessa KDF-rutiner och deras indata:

ECDiffieHellman-metod Description
DeriveKeyFromHash(ECDiffieHellmanPublicKey, HashAlgorithmName, Byte[], Byte[]) Härleder nyckelmaterial med hjälp av formeln

HASH(secretPrepend || x || secretAppend)

HASH(secretPrepend OrElse x OrElse secretAppend)

där x är det beräknade resultatet av EC-Diffie-Hellman-algoritmen.
DeriveKeyFromHmac(ECDiffieHellmanPublicKey, HashAlgorithmName, Byte[], Byte[], Byte[]) Härleder nyckelmaterial med hjälp av formeln

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

HMAC(hmacKey, secretPrepend OrElse x OrElse secretAppend)

där x är det beräknade resultatet av EC-Diffie-Hellman-algoritmen.
DeriveKeyTls(ECDiffieHellmanPublicKey, Byte[], Byte[]) Härleder nyckelmaterial med hjälp av prf-härledningsalgoritmen (TLS pseudo-random function).

Stöd för symmetrisk kryptering med bevarad nyckel

Det Windows kryptografibiblioteket (CNG) lade till stöd för lagring av bevarade symmetriska nycklar och användning av maskinvarulagrade symmetriska nycklar, och .NET Framework 4.6.2 gjorde det möjligt för utvecklare att använda den här funktionen. Eftersom begreppet nyckelnamn och nyckelprovidrar är implementeringsspecifikt kräver användning av den här funktionen att konstruktorn för de konkreta implementeringstyperna används i stället för den önskade fabriksmetoden (till exempel att anropa Aes.Create).

Stöd för symmetrisk kryptering med beständig nyckel finns för algoritmerna AES (AesCng) och 3DES (TripleDESCng). Ett exempel:

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-stöd för SHA-2-hashning

.NET Framework 4.6.2 lägger till stöd för SignedXml klassen för RSA-SHA256, RSA-SHA384 och RSA-SHA512 PKCS#1-signaturmetoder och SHA256-, SHA384- och SHA512-referenssammandragsalgoritmer.

URI-konstanterna exponeras på SignedXml:

SigneradeXml-fält Konstant
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"

Alla program som har registrerat en anpassad SignatureDescription hanterare CryptoConfig för att lägga till stöd för dessa algoritmer fortsätter att fungera som tidigare, men eftersom det nu finns plattformsstandarder CryptoConfig är registreringen inte längre nödvändig.

SqlClient

.NET Framework dataprovider för SQL Server (System.Data.SqlClient) innehåller följande nya funktioner i .NET Framework 4.6.2:

Anslutningspooler och tidsgränser för Azure SQL databaser

När anslutningspoolen är aktiverad och ett timeout- eller annat inloggningsfel inträffar cachelagras ett undantag och det cachelagrade undantaget utlöses vid efterföljande anslutningsförsök under de kommande 5 sekunderna till 1 minut. Mer information finns i SQL Server anslutningspool (ADO.NET).

Det här beteendet är inte önskvärt när du ansluter till Azure SQL-databaser, eftersom anslutningsförsök kan misslyckas med tillfälliga fel som vanligtvis återställs snabbt. För att optimera funktionen för återförsök av anslutningar tas beteendet för blockeringsperiod för anslutningspoolen bort när anslutningar till Azure SQL databaser misslyckas.

Med tillägget av det nya PoolBlockingPeriod nyckelordet kan du välja den blockeringsperiod som passar bäst för din app. Exempel på värden:

Auto

Blockeringsperioden för anslutningspoolen för ett program som ansluter till en Azure SQL Database är inaktiverad och blockeringsperioden för anslutningspoolen för ett program som ansluter till andra SQL Server instans är aktiverad. Detta är standardvärdet. Om serverslutpunktens namn slutar med något av följande anses de vara Azure SQL databaser:

  • .database.windows.net

  • .database.chinacloudapi.cn

  • .database.usgovcloudapi.net

  • .database.cloudapi.de

AlwaysBlock

Blockeringsperioden för anslutningspoolen är alltid aktiverad.

NeverBlock

Blockeringsperioden för anslutningspoolen är alltid inaktiverad.

Förbättringar för Always Encrypted

SQLClient introducerar två förbättringar för Always Encrypted:

  • För att förbättra prestanda för parametriserade frågor mot krypterade databaskolumner cachelagras nu krypteringsmetadata för frågeparametrar. Med egenskapen inställd på SqlConnection.ColumnEncryptionQueryMetadataCacheEnabledtrue (vilket är standardvärdet), om samma fråga anropas flera gånger, hämtar klienten parametermetadata från servern bara en gång.

  • Kolumnkrypteringsnyckelposter i nyckelcachen tas nu bort efter ett konfigurerbart tidsintervall som anges med hjälp av SqlConnection.ColumnEncryptionKeyCacheTtl egenskapen .

Windows Communication Foundation

I .NET Framework 4.6.2 har Windows Communication Foundation förbättrats på följande områden:

WCF-transportsäkerhetsstöd för certifikat som lagras med CNG

WCF-transportsäkerhet stöder certifikat som lagras med hjälp av Windows kryptografibibliotek (CNG). I .NET Framework 4.6.2 är det här stödet begränsat till att använda certifikat med en offentlig nyckel som inte har en exponent som är längre än 32 bitar. När ett program har som mål .NET Framework 4.6.2 är den här funktionen aktiverad som standard.

För program som har .NET Framework 4.6.1 och tidigare men som körs på .NET Framework 4.6.2 kan den här funktionen aktiveras genom att lägga till följande rad i <körningsavsnittet> i app.config- eller web.config-filen.

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

Detta kan också göras programmatiskt med kod som följande:

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

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

Bättre stöd för flera regler för sommartidsjustering av Klassen DataContractJsonSerializer

Kunder kan använda en programkonfigurationsinställning för att avgöra om DataContractJsonSerializer klassen stöder flera justeringsregler för en enda tidszon. Det här är en opt-in-funktion. Om du vill aktivera den lägger du till följande inställning i app.config-filen:

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

När den här funktionen är aktiverad använder TimeZoneInfo ett DataContractJsonSerializer objekt typen i stället för TimeZone typen för att avserialisera datum- och tidsdata. TimeZoneInfo Parlamentet stöder flera justeringsregler, vilket gör det möjligt att arbeta med historiska tidszonsdata. TimeZone Inte.

Mer information om struktur- TimeZoneInfo och tidszonsjusteringar finns i Översikt över tidszon.

NetNamedPipeBinding bästa matchning

WCF har en ny appinställning som kan ställas in på klientprogram för att säkerställa att de alltid ansluter till tjänsten och lyssnar på den URI som bäst matchar den som de begär. Med den här appinställningen inställd false på (standard) är det möjligt för klienter som använder NetNamedPipeBinding att försöka ansluta till en tjänst som lyssnar på en URI som är en delsträng av den begärda URI:n.

En klient försöker till exempel ansluta till en tjänst som lyssnar på net.pipe://localhost/Service1, men en annan tjänst på datorn som körs med administratörsbehörighet lyssnar på net.pipe://localhost. Med den här appinställningen inställd falsepå försöker klienten ansluta till fel tjänst. När du har angett appinställningen till trueansluter klienten alltid till den bästa matchande tjänsten.

Anteckning

Klienter som använder NetNamedPipeBinding söktjänster baserat på tjänstens basadress (om den finns) i stället för den fullständiga slutpunktsadressen. För att säkerställa att den här inställningen alltid fungerar bör tjänsten använda en unik basadress.

Om du vill aktivera den här ändringen lägger du till följande appinställning i klientprogrammets App.config- eller Web.config-fil:

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

SSL 3.0 är inte ett standardprotokoll

När du använder NetTcp med transportsäkerhet och en typ av certifikat för autentiseringsuppgifter är SSL 3.0 inte längre ett standardprotokoll som används för att förhandla om en säker anslutning. I de flesta fall bör det inte påverka befintliga appar eftersom TLS 1.0 ingår i protokolllistan för NetTcp. Alla befintliga klienter bör kunna förhandla om en anslutning med minst TLS 1.0. Om Ssl3 krävs använder du någon av följande konfigurationsmekanismer för att lägga till den i listan över förhandlade protokoll.

Windows Presentation Foundation (WPF)

I .NET Framework 4.6.2 har Windows Presentation Foundation förbättrats inom följande områden:

Gruppsortering

Ett program som använder ett CollectionView -objekt för att gruppera data kan nu uttryckligen deklarera hur grupperna ska sorteras. Explicit sortering löser problemet med icke-intuitiv sortering som uppstår när en app dynamiskt lägger till eller tar bort grupper, eller när den ändrar värdet för objektegenskaper som ingår i gruppering. Det kan också förbättra prestanda för processen för att skapa grupper genom att flytta jämförelser av grupperingsegenskaperna från den typ av fullständig samling till typen av grupper.

För att stödja gruppsortering beskriver de nya GroupDescription.SortDescriptions egenskaperna och GroupDescription.CustomSort hur du sorterar samlingen med grupper som skapas av GroupDescription objektet. Detta motsvarar hur de identiskt namngivna ListCollectionView egenskaperna beskriver hur du sorterar dataobjekten.

Två nya statiska egenskaper för PropertyGroupDescription klassen, CompareNameAscending och CompareNameDescending, kan användas för de vanligaste fallen.

Följande XAML grupperar till exempel data efter ålder, sorterar åldersgrupperna i stigande ordning och grupperar objekten i varje åldersgrupp efter efternamn.

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

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

Stöd för pektangentbord

Stöd för touchtangentbord möjliggör fokusspårning i WPF-program genom att automatiskt anropa och stänga pektangentbordet i Windows 10 när touch-indata tas emot av en kontroll som kan ta textinmatning.

I tidigare versioner av .NET Framework kan WPF-program inte välja fokusspårning utan att inaktivera stöd för WPF-penn-/touchgester. Därför måste WPF-program välja mellan fullständigt WPF touch-stöd eller förlita sig på Windows mushöjning.

DPI per övervakare

För att stödja den senaste spridningen av miljöer med hög DPI och hybrid-DPI för WPF-appar möjliggör WPF i .NET Framework 4.6.2 medvetenhet per övervakare. Se exemplen och utvecklarguiden om GitHub för mer information om hur du aktiverar WPF-appen för att bli DPI-medveten per övervakare.

I tidigare versioner av .NET Framework är WPF-appar system-DPI-medvetna. Med andra ord skalas programmets användargränssnitt av operativsystemet efter behov, beroende på DPI för övervakaren som appen renderas på.

För appar som körs under .NET Framework 4.6.2 kan du inaktivera DPI-ändringar per övervakare i WPF-appar genom att lägga till <en konfigurationsuttryck i körningsavsnittet> i programkonfigurationsfilen på följande sätt:

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

Windows Workflow Foundation (WF)

I .NET Framework 4.6.2 har Windows Workflow Foundation förbättrats i följande område:

Stöd för C#-uttryck och IntelliSense i den omvärderade WF-designern

Från och med .NET Framework 4.5 stöder WF C#-uttryck i både Visual Studio Designer och i kodarbetsflöden. Den omvärderade arbetsflödesdesignern är en viktig funktion i WF som gör att arbetsflödesdesignern kan vara i ett program utanför Visual Studio (till exempel i WPF). Windows Workflow Foundation ger stöd för C#-uttryck och IntelliSense i arbetsflödesdesignern med värdomvärd. Mer information finns i bloggen Windows Workflow Foundation.

Availability of IntelliSense when a customer rebuilds a workflow project from Visual StudioI versioner av .NET Framework före 4.6.2 bryts WF Designer IntelliSense när en kund återskapar ett arbetsflödesprojekt från Visual Studio. När projektversionen lyckas finns inte arbetsflödestyperna i designern, och varningar från IntelliSense för de saknade arbetsflödestyperna visas i fönstret Fellista . .NET Framework 4.6.2 åtgärdar problemet och gör IntelliSense tillgängligt.

Arbetsflöde v1-program med arbetsflödesspårning på körs nu i FIPS-läge

Datorer med FIPS-kompatibilitetsläge aktiverat kan nu köra ett version 1-liknande arbetsflödesprogram med arbetsflödesspårning aktiverat. Om du vill aktivera det här scenariot måste du göra följande ändring i app.config-filen:

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

Om det här scenariot inte är aktiverat fortsätter körningen av programmet att generera ett undantag med meddelandet "Den här implementeringen är inte en del av Windows PLATTFORM FIPS-verifierade kryptografiska algoritmer."

Arbetsflödesförbättringar vid användning av dynamisk uppdatering med Visual Studio Workflow Designer

Arbetsflödesdesignern, FlowChart Activity Designer och andra designer för arbetsflödesaktivitet läser nu in och visar arbetsflöden som har sparats efter att metoden anropats DynamicUpdateServices.PrepareForUpdate . I versioner av .NET Framework före .NET Framework 4.6.2 kan inläsning av en XAML-fil i Visual Studio för ett arbetsflöde som har sparats efter anrop DynamicUpdateServices.PrepareForUpdate resultera i följande problem:

  • Arbetsflödesdesignern kan inte läsa in XAML-filen korrekt (när ViewStateData.Id är i slutet av raden).

  • Flödesschemaaktivitetsdesignern eller andra designer av arbetsflödesaktiviteter kan visa alla objekt på sina standardplatser i stället för kopplade egenskapsvärden.

ClickOnce

ClickOnce har uppdaterats för att stödja TLS 1.1 och TLS 1.2 utöver 1.0-protokollet, som det redan stöder. ClickOnce identifierar automatiskt vilket protokoll som krävs. Inga extra steg i ClickOnce-programmet krävs för att aktivera stöd för TLS 1.1 och 1.2.

Konvertera Windows Forms- och WPF-appar till UWP-appar

Windows erbjuder nu funktioner för att ta befintliga Windows skrivbordsappar, inklusive WPF- och Windows Forms-appar, till Universell Windows-plattform (UWP). Den här tekniken fungerar som en brygga genom att du gradvis kan migrera din befintliga kodbas till UWP, vilket gör att din app kommer till alla Windows 10 enheter.

Konverterade skrivbordsappar får en appidentitet som liknar appidentiteten för UWP-appar, vilket gör UWP-API:er tillgängliga för att aktivera funktioner som levande paneler och meddelanden. Appen fortsätter att fungera som tidigare och körs som en app med fullständigt förtroende. När appen har konverterats kan en process för appcontainer läggas till i den befintliga fullständiga förtroendeprocessen för att lägga till ett anpassningsbart användargränssnitt. När alla funktioner flyttas till appcontainerprocessen kan den fullständiga förtroendeprocessen tas bort och den nya UWP-appen kan göras tillgänglig för alla Windows 10 enheter.

Felsökningsförbättringar

Det ohanterade felsöknings-API:et har förbättrats i .NET Framework 4.6.2 för att utföra ytterligare analys när en NullReferenceException genereras så att det är möjligt att avgöra vilken variabel i en enda rad källkod som är null. För att stödja det här scenariot har följande API:er lagts till i det ohanterade felsöknings-API:et.

Nyheter i .NET Framework 4.6.1

.NET Framework 4.6.1 innehåller nya funktioner inom följande områden:

Mer information om .NET Framework 4.6.1 finns i följande avsnitt:

Kryptografi: Stöd för X509-certifikat som innehåller ECDSA

.NET Framework 4.6 har lagt till RSACng-stöd för X509-certifikat. .NET Framework 4.6.1 lägger till stöd för ECDSA-certifikat (Elliptic Curve Digital Signature Algorithm) X509.

ECDSA ger bättre prestanda och är en säkrare kryptografialgoritm än RSA, vilket ger ett utmärkt val där prestanda och skalbarhet för Transport Layer Security (TLS) är ett problem. Implementeringen .NET Framework omsluter anrop till befintliga Windows funktioner.

Följande exempelkod visar hur enkelt det är att generera en signatur för en byteström med hjälp av det nya stödet för ECDSA X509-certifikat som ingår i .NET Framework 4.6.1.

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

Detta ger en tydlig kontrast till den kod som behövs för att generera en signatur i .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

Följande har lagts till i ADO.NET:

Always Encrypted stöd för maskinvaruskyddade nycklar

ADO.NET stöder nu lagring av Always Encrypted kolumnhuvudnycklar internt i maskinvarusäkerhetsmoduler (HSM). Med den här supporten kan kunder utnyttja asymmetriska nycklar som lagras i HSM:er utan att behöva skriva anpassade kolumnhuvudnyckellagringsleverantörer och registrera dem i program.

Kunder måste installera CSP-providern från HSM-leverantören eller CNG-nyckelarkivet på appservrarna eller klientdatorerna för att få åtkomst till Always Encrypted data som skyddas med kolumnhuvudnycklar som lagras i en HSM.

Förbättrat MultiSubnetFailover anslutningsbeteende för AlwaysOn

SqlClient ger nu automatiskt snabbare anslutningar till en AlwaysOn-tillgänglighetsgrupp (AG). Den identifierar transparent om ditt program ansluter till en AlwaysOn-tillgänglighetsgrupp (AG) i ett annat undernät och identifierar snabbt den aktuella aktiva servern och tillhandahåller en anslutning till servern. Före den här versionen var ett program tvunget att ange anslutningssträngen som ska inkluderas "MultisubnetFailover=true" för att indikera att det anslöt till en AlwaysOn-tillgänglighetsgrupp. Utan att ange anslutningsnyckelordet till truekan ett program få en timeout vid anslutning till en AlwaysOn-tillgänglighetsgrupp. Med den här versionen behöver ett program inte längre anges MultiSubnetFailover till true . Mer information om SqlClient-stöd för AlwaysOn-tillgänglighetsgrupper finns i SqlClient-stöd för hög tillgänglighet, haveriberedskap.

Windows Presentation Foundation (WPF)

Windows Presentation Foundation innehåller ett antal förbättringar och ändringar.

Bättre prestanda

Fördröjningen av pekhändelser har åtgärdats i .NET Framework 4.6.1. Dessutom binder inmatning i en RichTextBox kontroll inte längre återgivningstråden vid snabb inmatning.

Förbättringar av stavningskontroll

Stavningskontroll i WPF har uppdaterats på Windows 8.1 och senare versioner för att utnyttja operativsystemets stöd för stavningskontroll av ytterligare språk. Funktionaliteten för Windows versioner har inte ändrats före Windows 8.1.

Precis som i tidigare versioner av .NET Framework identifieras språket för en TextBox kontroll eller ett RichTextBox block genom att söka efter information i följande ordning:

  • xml:lang, om den finns.

  • Aktuellt indataspråk.

  • Aktuell kultur.

Mer information om språkstöd i WPF finns i WPF-blogginlägget om .NET Framework 4.6.1-funktioner.

Ytterligare stöd för anpassade ordlistor per användare

I .NET Framework 4.6.1 identifierar WPF anpassade ordlistor som är registrerade globalt. Den här funktionen är tillgänglig utöver möjligheten att registrera dem per kontroll.

I tidigare versioner av WPF kände anpassade ordlistor inte igen undantagna ord och autokorrigeringslistor. De stöds på Windows 8.1 och Windows 10 med hjälp av filer som kan placeras under %AppData%\Microsoft\Spelling\<language tag> katalogen. Följande regler gäller för dessa filer:

  • Filerna ska ha filnamnstillägg av .dic (för tillagda ord), .exc (för exkluderade ord) eller .acl (för Autokorrigering).

  • Filerna ska vara UTF-16 LE-klartext som börjar med BOM (Byte Order Mark).

  • Varje rad ska bestå av ett ord (i de tillagda och exkluderade ordlistorna) eller ett autokorrigeringspar med orden avgränsade med ett lodrätt fält ("|") (i ordlistan Autokorrigering).

  • Dessa filer anses vara skrivskyddade och ändras inte av systemet.

Anteckning

Dessa nya filformat stöds inte direkt av API:erna för stavningskontroll i WPF, och de anpassade ordlistor som skickas till WPF i program bör fortsätta att använda .lex-filer.

Exempel

Det finns ett antal WPF-exempel på lagringsplatsen Microsoft/WPF-Samples GitHub. Hjälp oss att förbättra våra exempel genom att skicka en pull-begäran eller öppna ett GitHub problem.

DirectX-tillägg

WPF innehåller ett NuGet-paket som tillhandahåller nya implementeringar av D3DImage som gör det enkelt för dig att samverka med DX10- och Dx11-innehåll. Koden för det här paketet har öppen källkod och är tillgänglig på GitHub.

Windows Workflow Foundation: Transaktioner

Metoden Transaction.EnlistPromotableSinglePhase kan nu använda en annan distribuerad transaktionshanterare än MSDTC för att höja upp transaktionen. Du gör detta genom att ange en GUID-transaktionspromotoridentifierare till den nya Transaction.EnlistPromotableSinglePhase(IPromotableSinglePhaseNotification, Guid) överlagringen . Om den här åtgärden lyckas finns det begränsningar för transaktionens funktioner. När en icke-MSDTC-transaktionspromotor har registrerats genererar följande metoder en TransactionPromotionException eftersom dessa metoder kräver befordran till MSDTC:

När en icke-MSDTC-transaktionspromotor har registrerats måste den användas för framtida varaktiga registreringar med hjälp av protokoll som den definierar. Transaktionspromotorns Guid värde kan hämtas med hjälp PromoterType av egenskapen . När transaktionen befordras tillhandahåller transaktionspromotorn en Byte matris som representerar den upphöjda token. Ett program kan hämta den upphöjda token för en icke-MSDTC-befordrad transaktion med GetPromotedToken metoden .

Användare av den nya Transaction.EnlistPromotableSinglePhase(IPromotableSinglePhaseNotification, Guid) överbelastningen måste följa en specifik anropssekvens för att befordringsåtgärden ska slutföras. Dessa regler dokumenteras i metodens dokumentation.

Profilering

Det ohanterade profilerings-API:et har förbättrats på följande sätt:

  • Bättre stöd för åtkomst till PDF-filer i gränssnittet ICorProfilerInfo7 .

    I ASP.NET Core blir det mycket vanligare att sammansättningar kompileras i minnet av Roslyn. För utvecklare som skapar profileringsverktyg innebär det att PDF-filer som tidigare serialiserats på disken kanske inte längre finns. Profiler-verktyg använder ofta PDF-filer för att mappa tillbaka kod till källrader för uppgifter som kodtäckning eller prestandaanalys rad för rad. Gränssnittet ICorProfilerInfo7 innehåller nu två nya metoder, ICorProfilerInfo7::GetInMemorySymbolsLength och ICorProfilerInfo7::ReadInMemorySymbols, för att ge dessa profilerarverktyg åtkomst till minnesintern PDB-data. Genom att använda de nya API:erna kan en profilerare hämta innehållet i en minnesintern PDB som en byte-matris och sedan bearbeta eller serialisera den till disk.

  • Bättre instrumentation med ICorProfiler-gränssnittet.

    Profilerare som använder API:erna ICorProfiler ReJit-funktioner för dynamisk instrumentation kan nu ändra vissa metadata. Tidigare kunde sådana verktyg instrumentera IL när som helst, men metadata kunde bara ändras vid inläsningen av modulen. Eftersom IL refererar till metadata begränsade detta de typer av instrumentation som kunde göras. Vi har hävt vissa av dessa gränser genom att lägga till metoden ICorProfilerInfo7::ApplyMetaData för att stödja en delmängd av metadataredigeringar när modulen har lästs in, särskilt genom att lägga till nya AssemblyRefposter, , TypeRefTypeSpec, MemberRefMemberSpec, och UserString . Den här ändringen gör ett mycket bredare utbud av instrumentation i farten möjlig.

PDU:er (Native Image Generator) (NGEN)

Händelsespårning mellan datorer gör det möjligt för kunder att profilera ett program på dator A och titta på profileringsdata med källradsmappning på dator B. Med hjälp av tidigare versioner av .NET Framework kopierar användaren alla moduler och interna avbildningar från den profilerade datorn till analysdatorn som innehåller IL PDB för att skapa käll-till-intern mappning. Även om den här processen kan fungera bra när filerna är relativt små, till exempel för telefonprogram, kan filerna vara mycket stora på stationära system och kräva betydande tid att kopiera.

Med Ngen-PDF-filer kan NGen skapa en PDB som innehåller il-to-native-mappningen utan beroende av IL PDB. I vårt scenario för händelsespårning mellan datorer är allt som behövs för att kopiera den interna avbildnings-PDB som genereras av dator A till dator B och för att använda API:er för felsökningsgränssnittsåtkomst för att läsa IL PDB:ns käll-till-IL-mappning och den interna avbildningens PDB:s IL-till-native-mappning. Genom att kombinera båda mappningarna får du en käll-till-intern mappning. Eftersom den inbyggda pdb-avbildningen är mycket mindre än alla moduler och interna avbildningar går kopieringsprocessen från dator A till dator B mycket snabbare.

Nyheter i .NET 2015

.NET 2015 introducerar .NET Framework 4.6 och .NET Core. Vissa nya funktioner gäller både och och andra funktioner är specifika för .NET Framework 4.6 eller .NET Core.

  • ASP.NET Core

    .NET 2015 innehåller ASP.NET Core, som är en lean .NET-implementering för att skapa moderna molnbaserade appar. ASP.NET Core är modulär så att du bara kan inkludera de funktioner som behövs i ditt program. Den kan finnas på IIS eller med egen värd i en anpassad process och du kan köra appar med olika versioner av .NET Framework på samma server. Det innehåller ett nytt miljökonfigurationssystem som är utformat för molndistribution.

    MVC, webb-API och webbsidor är enhetliga i ett enda ramverk som kallas MVC 6. Du skapar ASP.NET Core appar via verktyg i Visual Studio 2015 eller senare. Dina befintliga program fungerar på den nya .NET Framework. Men om du vill skapa en app som använder MVC 6 eller SignalR 3 måste du använda projektsystemet i Visual Studio 2015 eller senare.

    Mer information finns i ASP.NET Core.

  • ASP.NET uppdateringar

    • Uppgiftsbaserat API för asynkron svarstöning

      ASP.NET tillhandahåller nu ett enkelt uppgiftsbaserat API för asynkron svarstöning, HttpResponse.FlushAsync, som gör att svar kan tömmas asynkront med hjälp av ditt språks async/await stöd.

    • Modellbindning stöder metoder för uppgiftsretur

      I .NET Framework 4.5 lade ASP.NET till funktionen Modellbindning som aktiverade en utökningsbar, kodfokuserad metod för CRUD-baserade dataåtgärder i Web Forms sidor och användarkontroller. Modellbindningssystemet stöder Tasknu - returnerande modellbindningsmetoder. Med den här funktionen kan Web Forms utvecklare få skalbarhetsfördelarna med asynkront med databindningssystemets enkelhet när de använder nyare versioner av ORM:er, inklusive Entity Framework.

      Asynkron modellbindning styrs av konfigurationsinställningen aspnet:EnableAsyncModelBinding .

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

      I appar som är mål .NET Framework 4.6 är standardvärdet true. För appar som körs på .NET Framework 4.6 som är inriktade på en tidigare version av .NET Framework är false det som standard. Det kan aktiveras genom att ställa in konfigurationsinställningen på true.

    • HTTP/2-support (Windows 10)

      HTTP/2 är en ny version av HTTP-protokollet som ger mycket bättre anslutningsanvändning (färre turer mellan klient och server), vilket resulterar i kortare svarstider för inläsning av webbsidor för användare. Webbsidor (till skillnad från tjänster) drar mest nytta av HTTP/2, eftersom protokollet optimerar för flera artefakter som begärs som en del av en enda upplevelse. HTTP/2-stöd har lagts till i ASP.NET i .NET Framework 4.6. Eftersom det finns nätverksfunktioner i flera lager krävdes nya funktioner i Windows, i IIS och i ASP.NET för att aktivera HTTP/2. Du måste köra på Windows 10 för att kunna använda HTTP/2 med ASP.NET.

      HTTP/2 stöds också och är aktiverat som standard för Windows 10 Universell Windows-plattform appar (UWP) som använder API:etSystem.Net.Http.HttpClient.

      För att ge ett sätt att använda funktionen PUSH_PROMISE i ASP.NET program har en ny metod med två överlagringar PushPromise(String) och PushPromise(String, String, NameValueCollection), lagts till i HttpResponse klassen .

      Anteckning

      Även om ASP.NET Core stöder HTTP/2 har stöd för PUSH PROMISE-funktionen ännu inte lagts till.

      Webbläsaren och webbservern (IIS på Windows) utför allt arbete. Du behöver inte göra några tunga lyft för dina användare.

      De flesta av de större webbläsarna stöder HTTP/2, så det är troligt att användarna kommer att ha stöd för HTTP/2 om servern stöder det.

    • Stöd för tokenbindningsprotokollet

      Microsoft och Google har samarbetat kring en ny metod för autentisering, som kallas tokenbindningsprotokollet. Premissen är att autentiseringstoken (i webbläsarens cacheminne) kan stjälas och användas av brottslingar för att få åtkomst till annars säkra resurser (till exempel ditt bankkonto) utan att kräva ditt lösenord eller någon annan privilegierad kunskap. Det nya protokollet syftar till att åtgärda problemet.

      Tokenbindningsprotokollet implementeras i Windows 10 som en webbläsarfunktion. ASP.NET-appar kommer att delta i protokollet, så att autentiseringstoken verifieras vara legitima. Klient- och serverimplementeringarna upprättar det slutpunkt till slutpunkt-skydd som anges av protokollet.

    • Slumpmässiga stränghashalgoritmer

      .NET Framework 4.5 introducerades en slumpmässig stränghashalgoritm. Det stöddes dock inte av ASP.NET på grund av vissa ASP.NET funktioner var beroende av en stabil hashkod. I .NET Framework 4.6 stöds nu randomiserade stränghashalgoritmer. Om du vill aktivera den här funktionen använder du konfigurationsinställningen aspnet:UseRandomizedStringHashAlgorithm .

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

  • ADO.NET

    ADO .NET stöder nu funktionen Always Encrypted som är tillgänglig i SQL Server 2016. Med Always Encrypted kan SQL Server utföra åtgärder på krypterade data, och bäst av allt finns krypteringsnyckeln hos programmet i kundens betrodda miljö och inte på servern. Always Encrypted skyddar kunddata så att databasadministratörer inte har åtkomst till oformaterade textdata. Kryptering och dekryptering av data sker transparent på drivrutinsnivå, vilket minimerar ändringar som måste göras i befintliga program. Mer information finns i Always Encrypted (databasmotor) och Always Encrypted (klientutveckling).

  • 64-bitars JIT-kompilator för hanterad kod

    .NET Framework 4.6 har en ny version av 64-bitars JIT-kompilatorn (ursprungligen med kodnamnet RyuJIT). Den nya 64-bitars kompilatorn ger betydande prestandaförbättringar jämfört med den äldre 64-bitars JIT-kompilatorn. Den nya 64-bitars kompilatorn är aktiverad för 64-bitarsprocesser som körs ovanpå .NET Framework 4.6. Din app körs i en 64-bitarsprocess om den kompileras som 64-bitars eller AnyCPU och körs på ett 64-bitars operativsystem. Samtidigt som man har varit noga med att göra övergången till den nya kompilatorn så transparent som möjligt, är det möjligt att ändra beteendet.

    Den nya 64-bitars JIT-kompilatorn innehåller även simd-accelerationsfunktioner för maskinvara i kombination med SIMD-aktiverade typer i System.Numerics namnområdet, vilket kan ge bra prestandaförbättringar.

  • Förbättringar av sammansättningsinläsaren

    Sammansättningsinläsaren använder nu minnet mer effektivt genom att ta bort IL-sammansättningar efter att en motsvarande NGEN-avbildning har lästs in. Den här ändringen minskar det virtuella minnet, vilket är särskilt användbart för stora 32-bitarsappar (till exempel Visual Studio) och sparar även fysiskt minne.

  • Ändringar i basklassbiblioteket

    Många nya API:er har lagts till i .NET Framework 4.6 för att aktivera viktiga scenarier. Dessa inkluderar följande ändringar och tillägg:

    • IReadOnlyCollectionT-implementeringar<>

      Ytterligare samlingar implementerar IReadOnlyCollection<T> till exempel Queue<T> och Stack<T>.

    • CultureInfo.CurrentCulture och CultureInfo.CurrentUICulture

      Egenskaperna CultureInfo.CurrentCulture och CultureInfo.CurrentUICulture är nu skrivskyddade i stället för skrivskyddade. Om du tilldelar ett nytt CultureInfo objekt till dessa egenskaper ändras även den aktuella trådkulturen som definieras av Thread.CurrentThread.CurrentCulture egenskapen och den aktuella UI-trådkulturen som definieras av Thread.CurrentThread.CurrentUICulture egenskaperna.

    • Förbättringar av skräpinsamling (GC)

      Klassen GC innehåller TryStartNoGCRegion nu metoderna och EndNoGCRegion som gör att du inte tillåter skräpinsamling under körningen av en kritisk sökväg.

      En ny överlagring av GC.Collect(Int32, GCCollectionMode, Boolean, Boolean) metoden gör att du kan styra om både den lilla objekthögen och den stora objekthögen sveps och komprimeras eller sveps endast.

    • SIMD-aktiverade typer

      Namnområdet System.Numerics innehåller nu ett antal SIMD-aktiverade typer, till exempel Matrix3x2, Matrix4x4, Plane, Quaternion, Vector2, Vector3och Vector4.

      Eftersom den nya 64-bitars JIT-kompilatorn även innehåller maskinvarufunktioner för SIMD-acceleration, finns det särskilt betydande prestandaförbättringar när du använder SIMD-aktiverade typer med den nya 64-bitars JIT-kompilatorn.

    • Kryptografiuppdateringar

      API:et System.Security.Cryptography uppdateras för att stödja Windows CNG-kryptografi-API:er. Tidigare versioner av .NET Framework har förlitat sig helt på en tidigare version av Windows Kryptografi-API:er som grund för implementeringenSystem.Security.Cryptography. Vi har haft förfrågningar om att stödja CNG-API:et, eftersom det stöder moderna kryptografialgoritmer, vilket är viktigt för vissa kategorier av appar.

      .NET Framework 4.6 innehåller följande nya förbättringar för att stödja Windows CNG-kryptografi-API:er:

      • En uppsättning tilläggsmetoder för X509-certifikat och System.Security.Cryptography.X509Certificates.RSACertificateExtensions.GetRSAPublicKey(System.Security.Cryptography.X509Certificates.X509Certificate2)System.Security.Cryptography.X509Certificates.RSACertificateExtensions.GetRSAPrivateKey(System.Security.Cryptography.X509Certificates.X509Certificate2)som returnerar en CNG-baserad implementering i stället för en CAPI-baserad implementering när det är möjligt. (Vissa smartkort osv., kräver fortfarande CAPI, och API:erna hanterar återställningen).

      • Klassen System.Security.Cryptography.RSACng , som tillhandahåller en CNG-implementering av RSA-algoritmen.

      • Förbättringar av RSA-API:et så att vanliga åtgärder inte längre kräver omvandling. Kryptering av data med hjälp av ett X509Certificate2 objekt kräver till exempel kod som följande i tidigare versioner av .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)

        Kod som använder de nya kryptografi-API:erna i .NET Framework 4.6 kan skrivas om på följande sätt för att undvika gjutningen.

        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)

    • Stöd för att konvertera datum och tider till eller från Unix-tid

      Följande nya metoder har lagts till i DateTimeOffset strukturen för att stödja konvertering av datum- och tidsvärden till eller från Unix-tid:

    • Kompatibilitetsväxlar

      Klassen AppContext lägger till en ny kompatibilitetsfunktion som gör det möjligt för biblioteksförfattare att tillhandahålla en enhetlig opt-out-mekanism för nya funktioner för sina användare. Den upprättar ett löst kopplat kontrakt mellan komponenterna för att kunna skicka en avvisningsbegäran. Den här funktionen är vanligtvis viktig när en ändring görs i befintliga funktioner. Omvänt finns det redan ett implicit val för nya funktioner.

      Med AppContextdefinierar och exponerar bibliotek kompatibilitetsväxlar, medan kod som är beroende av dem kan ställa in dessa växlar så att de påverkar biblioteksbeteendet. Som standard tillhandahåller biblioteken de nya funktionerna, och de ändrar den bara (det vill sa att de tillhandahåller den tidigare funktionen) om växeln har angetts.

      Ett program (eller ett bibliotek) kan deklarera värdet för en växel (som alltid är ett Boolean värde) som ett beroende bibliotek definierar. Växeln är alltid implicit false. Om du ställer in växeln på true aktiveras den. Om du uttryckligen anger växeln till false får du det nya beteendet.

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

      AppContext.SetSwitch("Switch.AmazingLib.ThrowOnException", True)

      Biblioteket måste kontrollera om en konsument har deklarerat värdet för växeln och sedan agera på rätt sätt på den.

      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
}

      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
Else
    ' new code
End If

      Det är bra att använda ett konsekvent format för växlar, eftersom de är ett formellt kontrakt som exponeras av ett bibliotek. Följande är två uppenbara format.

      • Växel. namnområde. switchname

      • Växel. bibliotek. switchname

    • Ändringar i det aktivitetsbaserade asynkrona mönstret (TAP)

      För appar som är inriktade på .NET Framework 4.6 Task och Task<TResult> objekt ärver kulturen och användargränssnittskulturen i den anropande tråden. Beteendet för appar som riktar sig mot tidigare versioner av .NET Framework, eller som inte riktar sig mot en specifik version av .NET Framework, påverkas inte. Mer information finns i avsnittet "Kultur- och uppgiftsbaserade asynkrona åtgärder" i klassavsnittet CultureInfo .

      Med System.Threading.AsyncLocal<T> klassen kan du representera omgivande data som är lokala för ett visst asynkront kontrollflöde, till exempel en async metod. Den kan användas för att bevara data mellan trådar. Du kan också definiera en återanropsmetod som meddelas när omgivande data ändras, antingen för att AsyncLocal<T>.Value egenskapen uttryckligen har ändrats eller för att tråden påträffade en kontextövergång.

      Tre bekvämlighetsmetoder, Task.CompletedTask, Task.FromCanceledoch Task.FromException, har lagts till i det uppgiftsbaserade asynkrona mönstret (TAP) för att returnera slutförda aktiviteter i ett visst tillstånd.

      Klassen NamedPipeClientStream stöder nu asynkron kommunikation med dess nya ConnectAsync. Metod.

    • EventSource stöder nu skrivning till händelseloggen

      Nu kan du använda EventSource klassen för att logga administrativa eller operativa meddelanden till händelseloggen, förutom eventuella befintliga ETW-sessioner som skapats på datorn. Tidigare var du tvungen att använda NuGet-paketet Microsoft.Diagnostics.Tracing.EventSource för den här funktionen. Den här funktionen är nu inbyggd i .NET Framework 4.6.

      Både NuGet-paketet och .NET Framework 4.6 har uppdaterats med följande funktioner:

      • Dynamiska händelser

        Tillåter händelser som definierats "i farten" utan att skapa händelsemetoder.

      • Omfattande nyttolaster

        Tillåter att särskilt tillskrivna klasser och matriser samt primitiva typer skickas som en nyttolast

      • Aktivitetsspårning

        Orsakar start- och stopphändelser för att tagga händelser mellan dem med ett ID som representerar alla aktiva aktiviteter.

      Den överlagrade Write metoden har lagts till i klassen för att stödja dessa EventSource funktioner.

  • Windows Presentation Foundation (WPF)

    • HDPI-förbättringar

      HDPI-stöd i WPF är nu bättre i .NET Framework 4.6. Ändringar har gjorts i layoutrundning för att minska instanser av urklipp i kontroller med kantlinjer. Som standard är den här funktionen endast aktiverad om din TargetFrameworkAttribute är inställd på .NET Framework 4.6. Program som riktar sig mot tidigare versioner av ramverket men som körs på .NET Framework 4.6 kan välja det nya beteendet genom att lägga till <följande rad i körningsavsnittet> i app.config-filen:

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

      WPF-fönster som sträcker sig över flera bildskärmar med olika DPI-inställningar (Multi-DPI-installation) återges nu helt utan utspängda regioner. Du kan välja bort det här beteendet genom att lägga till följande rad i <appSettings> avsnittet i app.config-filen för att inaktivera det här nya beteendet:

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

      Stöd för att automatiskt läsa in den högra markören baserat på DPI-inställningen har lagts till i System.Windows.Input.Cursor.

    • Touch är bättre

      Kundrapporter om Anslut som touch ger oförutsägbart beteende har åtgärdats i .NET Framework 4.6. Tröskelvärdet för dubbeltryck för Windows Store-program och WPF-program är nu detsamma i Windows 8.1 och senare.

    • Stöd för transparent underordnat fönster

      WPF i .NET Framework 4.6 stöder transparenta underordnade fönster i Windows 8.1 och senare. På så sätt kan du skapa icke-rektangulära och transparenta underordnade fönster i dina fönster på den översta nivån. Du kan aktivera den här funktionen genom att ange HwndSourceParameters.UsesPerPixelTransparency egenskapen till true.

  • Windows Communication Foundation (WCF)

    • SSL-stöd

      WCF stöder nu SSL-version TLS 1.1 och TLS 1.2, förutom SSL 3.0 och TLS 1.0, när du använder NetTcp med transportsäkerhet och klientautentisering. Nu kan du välja vilket protokoll som ska användas eller inaktivera gamla mindre säkra protokoll. Detta kan göras antingen genom att ange SslProtocols egenskapen eller genom att lägga till följande i en konfigurationsfil.

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

    • Skicka meddelanden med olika HTTP-anslutningar

      WCF gör det nu möjligt för användare att se till att vissa meddelanden skickas med olika underliggande HTTP-anslutningar. Det finns två sätt att göra detta:

      • Använda ett namnprefix för en anslutningsgrupp

        Användare kan ange en sträng som WCF ska använda som prefix för anslutningsgruppens namn. Två meddelanden med olika prefix skickas med olika underliggande HTTP-anslutningar. Du anger prefixet genom att lägga till ett nyckel/värde-par i meddelandets Message.Properties egenskap. Nyckeln är "HttpTransportConnectionGroupNamePrefix"; värdet är det önskade prefixet.

      • Använda olika kanalfabriker

        Användare kan också aktivera en funktion som säkerställer att meddelanden som skickas via kanaler som skapats av olika kanalfabriker använder olika underliggande HTTP-anslutningar. För att aktivera den här funktionen måste användarna ange följande appSetting till true:

        <appSettings>
    <add key="wcf:httpTransportBinding:useUniqueConnectionPoolPerFactory" value="true" />
</appSettings>

  • Windows Workflow Foundation (WWF)

    Du kan nu ange hur många sekunder som en arbetsflödestjänst ska hålla fast vid en begäran om oordnad åtgärd när det finns ett utestående bokmärke av typen "icke-protokoll" innan begäran överskrids. Ett bokmärke som inte är protokoll är ett bokmärke som inte är relaterat till utestående mottagningsaktiviteter. Vissa aktiviteter skapar bokmärken som inte är protokollbokmärken i implementeringen, så det kanske inte är uppenbart att det finns ett bokmärke som inte är protokoll. Dessa inkluderar Tillstånd och Välj. Så om du har en arbetsflödestjänst implementerad med en tillståndsdator eller innehåller en Pick-aktivitet, kommer du förmodligen att ha bokmärken som inte är protokollbokmärken. Du anger intervallet genom att lägga till en rad som liknar följande i appSettings avsnittet i din app.config-fil:

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

    Standardvärdet är 60 sekunder. Om value är inställt på 0 avvisas begäranden som inte är i ordning omedelbart med ett fel med text som ser ut så här:

    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.

    Det här är samma meddelande som du får om ett meddelande om oordnad åtgärd tas emot och det inte finns några bokmärken som inte är protokoll.

    Om värdet för elementet FilterResumeTimeoutInSeconds inte är noll finns det bokmärken som inte är protokollbokmärken och tidsgränsintervallet upphör att gälla. Åtgärden misslyckas med ett timeout-meddelande.

  • Transaktioner

    Nu kan du inkludera den distribuerade transaktionsidentifieraren för transaktionen som har orsakat att ett undantag som härletts från TransactionException genereras. Det gör du genom att lägga till följande nyckel i avsnittet i appSettings app.config-filen:

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

    Standardvärdet är false.

  • Nätverk

    • Återanvändning av socket

      Windows 10 innehåller en ny nätverksalgoritm med hög skalbarhet som bättre utnyttjar datorresurser genom att återanvända lokala portar för utgående TCP-anslutningar. .NET Framework 4.6 stöder den nya algoritmen, vilket gör det möjligt för .NET-appar att dra nytta av det nya beteendet. I tidigare versioner av Windows fanns det en artificiell samtidig anslutningsgräns (vanligtvis 16 384, standardstorleken för det dynamiska portintervallet), vilket kan begränsa skalbarheten för en tjänst genom att orsaka portöverbelastning under belastning.

      I .NET Framework 4.6 har två API:er lagts till för att möjliggöra återanvändning av portar, vilket effektivt tar bort gränsen på 64 KB för samtidiga anslutningar:

      Som standard ServicePointManager.ReusePort är false egenskapen såvida inte HWRPortReuseOnSocketBind värdet för registernyckeln HKLM\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 är inställt på 0x1. Om du vill aktivera återanvändning av lokala portar på HTTP-anslutningar anger du ServicePointManager.ReusePort egenskapen till true. Detta gör att alla utgående TCP-socketanslutningar från HttpClient och HttpWebRequest använder ett nytt Windows 10 socketalternativ, SO_REUSE_UNICASTPORT, som möjliggör återanvändning av lokala portar.

      Utvecklare som skriver ett socketprogram kan ange System.Net.Sockets.SocketOptionName alternativet när de anropar en metod, Socket.SetSocketOption till exempel så att utgående socketar återanvänder lokala portar under bindningen.

    • Stöd för internationella domännamn och PunyCode

      En ny egenskap, IdnHost, har lagts till i Uri klassen för att bättre stödja internationella domännamn och PunyCode.

  • Ändra storlek i Windows Forms kontroller.

    Den här funktionen har expanderats i .NET Framework 4.6 för att inkludera typerna DomainUpDown, NumericUpDown, DataGridViewComboBoxColumnDataGridViewColumn och ToolStripSplitButton och rektangeln som anges av Bounds egenskapen som används när du ritar en UITypeEditor.

    Det här är en opt-in-funktion. Om du vill aktivera det anger du -elementet EnableWindowsFormsHighDpiAutoResizing till true i programkonfigurationsfilen (app.config):

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

  • Stöd för kodning av kodningssidor

    .NET Core har främst stöd för Unicode-kodningar och ger som standard begränsat stöd för kodning av sidor. Du kan lägga till stöd för kodning av kodningssidor som är tillgängliga i .NET Framework men som inte stöds i .NET Core genom att registrera kodning av kodningssidor med Encoding.RegisterProvider metoden . Mer information finns i System.Text.CodePagesEncodingProvider.

  • .NET Native

Universell Windows-plattform-appar (UWP) som är skrivna i C# eller Visual Basic kan dra nytta av en ny teknik som kompilerar appar till intern kod i stället för IL. Den här tekniken skapar appar som har snabbare start- och körningstider. Mer information finns i Kompilera appar med .NET Native. En översikt över .NET Native som undersöker hur den skiljer sig från både JIT-kompilering och NGEN och vad det innebär för din kod finns i .NET Native och Kompilering.

Dina appar kompileras som standard till intern kod när du kompilerar dem med Visual Studio 2015 eller senare. Mer information finns i Komma igång med .NET Native.

För att stödja felsökning .NET Native appar har ett antal nya gränssnitt och uppräkningar lagts till i det ohanterade felsöknings-API:et. Mer information finns i avsnittet Felsökning (ohanterad API-referens).

Nyheter i .NET Framework 4.5.2

  • Nya API:er för ASP.NET appar. Med de nya HttpResponse.AddOnSendingHeaders metoderna och HttpResponseBase.AddOnSendingHeaders kan du granska och ändra svarshuvuden och statuskod när svaret töms till klientappen. Överväg att använda dessa metoder i stället för PreSendRequestHeaders händelserna och PreSendRequestContent . De är mer effektiva och tillförlitliga.

    Med HostingEnvironment.QueueBackgroundWorkItem metoden kan du schemalägga små bakgrundsarbetsobjekt. ASP.NET spårar dessa objekt och förhindrar att IIS plötsligt avslutar arbetsprocessen tills alla bakgrundsarbetsobjekt har slutförts. Den här metoden kan inte anropas utanför en ASP.NET hanterad appdomän.

    De nya HttpResponse.HeadersWritten egenskaperna och HttpResponseBase.HeadersWritten returnerar booleska värden som anger om svarshuvudena har skrivits. Du kan använda de här egenskaperna för att se till att anrop till API:er som HttpResponse.StatusCode (som utlöser undantag om rubrikerna har skrivits) lyckas.

  • Ändra storlek i Windows Forms kontroller. Den här funktionen har utökats. Nu kan du använda system-DPI-inställningen för att ändra storlek på komponenterna i följande ytterligare kontroller (till exempel listrutepilen i kombinationsrutor):

    Det här är en opt-in-funktion. Om du vill aktivera det anger du -elementet EnableWindowsFormsHighDpiAutoResizing till true i programkonfigurationsfilen (app.config):

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

  • Ny arbetsflödesfunktion. En resurshanterare som använder EnlistPromotableSinglePhase metoden (och därför implementerar IPromotableSinglePhaseNotification gränssnittet) kan använda den nya Transaction.PromoteAndEnlistDurable metoden för att begära följande:

    Detta kan göras inom samma appdomän och kräver ingen extra ohanterad kod för att interagera med MSDTC för att utföra befordran. Den nya metoden kan bara anropas när det finns ett enastående anrop från System.Transactions till metoden IPromotableSinglePhaseNotificationPromote som implementeras av promotable-listan.

  • Profileringsförbättringar. Följande nya ohanterade profilerings-API:er ger mer robust profilering:

    Tidigare ICorProfiler implementeringar stödde lat inläsning av beroende sammansättningar. De nya profilerings-API:erna kräver att beroende sammansättningar som matas in av profileraren kan läsas in omedelbart, i stället för att läsas in när appen har initierats helt. Den här ändringen påverkar inte användare av befintliga ICorProfiler API:er.

  • Felsökningsförbättringar. Följande nya ohanterade felsöknings-API:er ger bättre integrering med en profilerare. Nu kan du komma åt metadata som infogats av profileraren samt lokala variabler och kod som skapats av kompilatorns ReJIT-begäranden vid dumpfelsökning.

  • Händelsespårningsändringar. .NET Framework 4.5.2 möjliggör out-of-process, händelsespårning för Windows (ETW)-baserad aktivitetsspårning för en större yta. Detta gör det möjligt för APM-leverantörer (Advanced Power Management) att tillhandahålla enkla verktyg som noggrant spårar kostnaderna för enskilda begäranden och aktiviteter som korsar trådar. Dessa händelser aktiveras endast när ETW-styrenheter aktiverar dem. Ändringarna påverkar därför inte tidigare skriven ETW-kod eller kod som körs med ETW inaktiverat.

  • Främja en transaktion och konvertera den till en varaktig registrering

    Transaction.PromoteAndEnlistDurableär ett nytt API som lagts till i .NET Framework 4.5.2 och 4.6:

    [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

    Metoden kan användas av en lista som tidigare skapades av Transaction.EnlistPromotableSinglePhase som svar på ITransactionPromoter.Promote metoden. Den ber System.Transactions att befordra transaktionen till en MSDTC-transaktion och att "konvertera" promotable-enlistningen till en varaktig registrering. När den här metoden har slutförts IPromotableSinglePhaseNotification kommer gränssnittet inte längre att refereras av System.Transactions, och eventuella framtida meddelanden kommer att skickas till det angivna ISinglePhaseNotification gränssnittet. Den aktuella värvningen måste fungera som en varaktig registrering som stöder transaktionsloggning och återställning. Transaction.EnlistDurable Mer information finns i. Dessutom måste enlistningen ha stöd ISinglePhaseNotificationför . Den här metoden kan bara anropas när ett anrop bearbetas ITransactionPromoter.Promote . Om så inte är fallet utlöses ett TransactionException undantag.

Nyheter i .NET Framework 4.5.1

Uppdateringar för april 2014:

  • Visual Studio uppdatering 2 från 2013 innehåller uppdateringar av mallarna för portabelt klassbibliotek för att stödja följande scenarier:

    • Du kan använda Windows Runtime-API:er i portabla bibliotek som är mål för Windows 8.1, Windows Phone 8.1 och Windows Phone Silverlight 8.1.

    • Du kan inkludera XAML (Windows. UI. XAML-typer) i portabla bibliotek när du använder Windows 8.1 eller Windows Phone 8.1. Följande XAML-mallar stöds: Tom sida, resursordlista, mallkontroll och användarkontroll.

    • Du kan skapa en bärbar Windows Runtime komponent (.winmd-fil) för användning i Store-appar som är avsedda för Windows 8.1 och Windows Phone 8.1.

    • Du kan ommåla ett Windows Store- eller Windows Phone Store-klassbibliotek som ett portabelt klassbibliotek.

    Mer information om dessa ändringar finns i Portabelt klassbibliotek.

  • Den .NET Framework innehållsuppsättningen innehåller nu dokumentation för .NET Native, som är en förkompileringsteknik för att skapa och distribuera Windows appar. .NET Native kompilerar dina appar direkt till intern kod i stället för mellanliggande språk (IL) för bättre prestanda. Mer information finns i Kompilera appar med .NET Native.

  • Referenskällan .NET Framework ger en ny webbupplevelse och förbättrade funktioner. Nu kan du bläddra igenom .NET Framework källkod online, ladda ned referensen för offlinevisning och gå igenom källorna (inklusive korrigeringar och uppdateringar) under felsökningen. Mer information finns i blogginlägget Ett nytt utseende för .NET-referenskälla.

Nya funktioner och förbättringar i basklasserna i .NET Framework 4.5.1 omfattar:

  • Automatisk bindningsomdirigering för sammansättningar. Från och med Visual Studio 2013, när du kompilerar en app som är inriktad på .NET Framework 4.5.1, kan bindningsomdirigeringar läggas till i appkonfigurationsfilen om appen eller dess komponenter refererar till flera versioner av samma sammansättning. Du kan också aktivera den här funktionen för projekt som är inriktade på äldre versioner av .NET Framework. Mer information finns i Så här: Aktivera och inaktivera automatisk bindningsomdirigering.

  • Möjlighet att samla in diagnostikinformation för att hjälpa utvecklare att förbättra prestandan för server- och molnprogram. Mer information finns i WriteEventWithRelatedActivityId metoderna och WriteEventWithRelatedActivityIdCore i EventSource klassen .

  • Möjlighet att uttryckligen komprimera den stora objekthubben (LOH) under skräpinsamling. Mer information finns i egenskapen GCSettings.LargeObjectHeapCompactionMode .

  • Ytterligare prestandaförbättringar som ASP.NET appavstängning, JIT-förbättringar med flera kärnor och snabbare appstart efter en .NET Framework uppdatering. Mer information finns i blogginlägget .NET Framework 4.5.1 och ASP.NET app suspend.

Förbättringar av Windows Forms omfattar:

  • Ändra storlek i Windows Forms kontroller. Du kan använda system-DPI-inställningen för att ändra storlek på komponenter i kontroller (till exempel ikonerna som visas i ett egenskapsrutnät) genom att välja en post i programkonfigurationsfilen (app.config) för din app. Den här funktionen stöds för närvarande i följande Windows Forms kontroller:

    Om du vill aktivera den här funktionen lägger du till ett nytt <appSettings-element i konfigurationsfilen> (app.config) och ställer in elementet EnableWindowsFormsHighDpiAutoResizing på true:

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

Förbättringar när du felsöker dina .NET Framework-appar i Visual Studio 2013 omfattar:

  • Returnera värden i Visual Studio felsökaren. När du felsöker en hanterad app i Visual Studio 2013 visar fönstret Automatiskt returtyper och värden för metoder. Den här informationen är tillgänglig för skrivbord, Windows Store och Windows Phone appar. Mer information finns i Granska returvärden för metodanrop.

  • Redigera och fortsätt för 64-bitarsappar. Visual Studio 2013 stöder funktionen Redigera och fortsätt för 64-bitars hanterade appar för skrivbord, Windows Store och Windows Phone. De befintliga begränsningarna gäller för både 32- och 64-bitarsappar (se det sista avsnittet i artikeln Kodändringar som stöds (C#).

  • Async-medveten felsökning. För att göra det enklare att felsöka asynkrona appar i Visual Studio 2013 döljer anropsstacken infrastrukturkoden som tillhandahålls av kompilatorer för att stödja asynkron programmering och kedjar även in logiska överordnade ramar så att du kan följa körningen av logiska program tydligare. Ett aktivitetsfönster ersätter fönstret Parallella aktiviteter och visar aktiviteter som är relaterade till en viss brytpunkt och visar även andra aktiviteter som för närvarande är aktiva eller schemalagda i appen. Du kan läsa om den här funktionen i avsnittet "Async-aware debugging" i .NET Framework 4.5.1-meddelandet.

  • Bättre undantagsstöd för Windows Runtime komponenter. I Windows 8.1 bevarar undantag som uppstår från Windows Store-appar information om felet som orsakade undantaget, även över språkgränser. Du kan läsa om den här funktionen i avsnittet "Windows Store apputveckling" i .NET Framework 4.5.1-meddelandet.

Från och med Visual Studio 2013 kan du använda det guidade optimeringsverktyget för hanterade profiler (Mpgo.exe) för att optimera Windows 8.x Store-appar och skrivbordsappar.

Nya funktioner i ASP.NET 4.5.1 finns i viktig information om ASP.NET och webbverktyg för Visual Studio 2013.

Nyheter i .NET Framework 4.5

Basklasser

  • Möjlighet att minska systemomstarter genom att identifiera och stänga .NET Framework 4 program under distributionen. Se Minska systemomstarter under .NET Framework 4.5-installationer.

  • Stöd för matriser som är större än 2 gigabyte (GB) på 64-bitarsplattformar. Den här funktionen kan aktiveras i programkonfigurationsfilen. Se elementet< gcAllowVeryLargeObjects>, som även visar andra begränsningar för objektstorlek och matrisstorlek.

  • Bättre prestanda via skräpinsamling i bakgrunden för servrar. När du använder skräpinsamling av servrar i .NET Framework 4.5 aktiveras skräpinsamling i bakgrunden automatiskt. Se avsnittet Skräpinsamling för bakgrundsserver i avsnittet Grunderna för skräpinsamling .

  • JiT-kompilering i bakgrunden (just-in-time), som kan användas på processorer med flera kärnor för att förbättra programmets prestanda. Se ProfileOptimization.

  • Möjlighet att begränsa hur länge motorn för reguljära uttryck försöker lösa ett reguljärt uttryck innan tidsgränsen uppnås. Se egenskapen Regex.MatchTimeout .

  • Möjlighet att definiera standardkulturen för en programdomän. CultureInfo Se klassen.

  • Konsolstöd för Unicode-kodning (UTF-16). Console Se klassen.

  • Stöd för versionshantering av kultursträngsordning och jämförelsedata. SortVersion Se klassen.

  • Bättre prestanda vid hämtning av resurser. Se Paketera och distribuera resurser.

  • Zip-komprimeringsförbättringar för att minska storleken på en komprimerad fil. System.IO.Compression Se namnområdet.

  • Möjlighet att anpassa en reflektionskontext för att åsidosätta standardbeteendet för reflektion via CustomReflectionContext klassen.

  • Stöd för 2008-versionen av IDNA-standarden (Internationalized Domain Names in Applications) när System.Globalization.IdnMapping klassen används på Windows 8.

  • Delegering av strängjämförelse till operativsystemet, som implementerar Unicode 6.0, när .NET Framework används på Windows 8. När du kör på andra plattformar innehåller .NET Framework sina egna strängjämförelsedata, som implementerar Unicode 5.x. String Se klassen och avsnittet Kommentarer i SortVersion klassen.

  • Möjlighet att beräkna hash-koderna för strängar per programdomän. Se <Elementet UseRandomizedStringHashAlgorithm>.

  • Stöd för typreflektion uppdelat mellan Type klasser och TypeInfo klasser. Se Reflektion i .NET Framework för Windows Store-appar.

Managed Extensibility Framework (MEF)

I .NET Framework 4.5 innehåller Managed Extensibility Framework (MEF) följande nya funktioner:

  • Stöd för allmänna typer.

  • Konventionsbaserad programmeringsmodell som gör att du kan skapa delar baserat på namngivningskonventioner snarare än attribut.

  • Flera omfång.

  • En delmängd av MEF som du kan använda när du skapar Windows 8.x Store-appar. Den här delmängden är tillgänglig som ett nedladdningsbart paket från NuGet-galleriet. Om du vill installera paketet öppnar du projektet i Visual Studio, väljer Hantera NuGet-paket på Project-menyn och söker online efter Microsoft.Composition paketet.

Mer information finns i Managed Extensibility Framework (MEF).

Asynkrona filåtgärder

I .NET Framework 4.5 har nya asynkrona funktioner lagts till i C# och Visual Basic språk. De här funktionerna lägger till en uppgiftsbaserad modell för att utföra asynkrona åtgärder. Om du vill använda den här nya modellen använder du de asynkrona metoderna i I/O-klasserna. Se Asynkron fil-I/O.

Verktyg

I .NET Framework 4.5 kan du skapa en .resw-fil Resgen.exe för användning i Windows 8.x Store-appar från en .resources-fil som är inbäddad i en .NET Framework sammansättning. Mer information finns iResgen.exe (Resource File Generator).

Med guidad optimering för hanterad profil (Mpgo.exe) kan du förbättra programmets starttid, minnesanvändning (storlek på arbetsuppsättning) och dataflöde genom att optimera inbyggda bildsammansättningar. Kommandoradsverktyget genererar profildata för inbyggda bildprogramsammansättningar. Se Mpgo.exe (guidat optimeringsverktyg för hanterad profil). Från och med Visual Studio 2013 kan du använda Mpgo.exe för att optimera Windows 8.x Store-appar och skrivbordsappar.

Parallell databehandling

.NET Framework 4.5 innehåller flera nya funktioner och förbättringar för parallell databehandling. Dessa inkluderar förbättrad prestanda, ökad kontroll, förbättrat stöd för asynkron programmering, ett nytt dataflödesbibliotek och förbättrat stöd för parallell felsökning och prestandaanalys. Se posten Nyheter för parallellitet i .NET Framework 4.5 i bloggen Parallell programmering med .NET.

Webb

ASP.NET 4.5 och 4.5.1 lägger till modellbindning för Web Forms, WebSocket-stöd, asynkrona hanterare, prestandaförbättringar och många andra funktioner. Mer information finns i följande resurser:

Nätverk

.NET Framework 4.5 tillhandahåller ett nytt programmeringsgränssnitt för HTTP-program. Mer information finns i de nya System.Net.Http och System.Net.Http.Headers namnrymderna.

Stöd ingår också för ett nytt programmeringsgränssnitt för att acceptera och interagera med en WebSocket-anslutning med hjälp av befintliga HttpListener och relaterade klasser. Mer information finns i det nya System.Net.WebSockets namnområdet och HttpListener klassen.

Dessutom innehåller .NET Framework 4.5 följande nätverksförbättringar:

  • RFC-kompatibelt URI-stöd. Mer information finns i Uri och relaterade klasser.

  • Stöd för IDN-parsning (Internationalized Domain Name). Mer information finns i Uri och relaterade klasser.

  • Stöd för EAI (Email Address Internationalization). Mer information finns i System.Net.Mail namnområdet.

  • Förbättrat IPv6-stöd. Mer information finns i System.Net.NetworkInformation namnområdet.

  • Stöd för socket med dubbla lägen. Mer information finns i klasserna Socket och TcpListener .

Windows Presentation Foundation (WPF)

I .NET Framework 4.5 innehåller Windows Presentation Foundation (WPF) ändringar och förbättringar inom följande områden:

  • Den nya Ribbon kontrollen gör att du kan implementera ett användargränssnitt i menyfliksområdet som är värd för verktygsfältet Snabbåtkomst, Programmeny och flikar.

  • Det nya INotifyDataErrorInfo gränssnittet, som stöder synkron och asynkron dataverifiering.

  • Nya funktioner för klasserna VirtualizingPanel och Dispatcher .

  • Bättre prestanda när du visar stora uppsättningar grupperade data och genom att komma åt samlingar på icke-gränssnittstrådar.

  • Databindning till statiska egenskaper, databindning till anpassade typer som implementerar ICustomTypeProvider gränssnittet och hämtning av databindningsinformation från ett bindningsuttryck.

  • Flytta data när värdena ändras (liveformning).

  • Möjlighet att kontrollera om datakontexten för en objektcontainer är frånkopplad.

  • Möjlighet att ange hur lång tid som ska gå mellan egenskapsändringar och datakällans uppdateringar.

  • Förbättrat stöd för implementering av svaga händelsemönster. Händelser kan också nu acceptera tillägg för pålägg.

Windows Communication Foundation (WCF)

I .NET Framework 4.5 har följande funktioner lagts till för att göra det enklare att skriva och underhålla WCF-program (Windows Communication Foundation):

  • Förenkling av genererade konfigurationsfiler.

  • Stöd för kontrakt-första utveckling.

  • Möjlighet att konfigurera ASP.NET kompatibilitetsläge enklare.

  • Ändringar i standardvärden för transportegenskap för att minska sannolikheten för att du måste ange dem.

  • Uppdateringar av XmlDictionaryReaderQuotas klassen för att minska sannolikheten för att du måste konfigurera kvoter manuellt för XML-ordlisteläsare.

  • Validering av WCF-konfigurationsfiler genom att Visual Studio som en del av byggprocessen, så att du kan identifiera konfigurationsfel innan du kör programmet.

  • Nytt stöd för asynkron strömning.

  • Ny HTTPS-protokollmappning för att göra det enklare att exponera en slutpunkt via HTTPS med Internet Information Services (IIS).

  • Möjlighet att generera metadata i ett enda WSDL-dokument genom att lägga ?singleWSDL till tjänstens URL.

  • Websockets-stöd för att aktivera sann dubbelriktad kommunikation via portarna 80 och 443 med prestandaegenskaper som liknar TCP-transporten.

  • Stöd för att konfigurera tjänster i kod.

  • Knappbeskrivningar för XML-redigeraren.

  • ChannelFactory stöd för cachelagring.

  • Stöd för komprimering av binär kodare.

  • Stöd för en UDP-transport som gör det möjligt för utvecklare att skriva tjänster som använder "fire and forget"-meddelanden. En klient skickar ett meddelande till en tjänst och förväntar sig inget svar från tjänsten.

  • Möjlighet att stödja flera autentiseringslägen på en enda WCF-slutpunkt när du använder HTTP-transport- och transportsäkerheten.

  • Stöd för WCF-tjänster som använder internationaliserade domännamn (IDN).

Mer information finns i Nyheter i Windows Communication Foundation.

Windows Workflow Foundation (WF)

I .NET Framework 4.5 har flera nya funktioner lagts till i Windows Workflow Foundation (WF), inklusive:

  • Tillståndsdatorarbetsflöden, som först introducerades som en del av .NET Framework 4.0.1 (.NET Framework 4 Plattformsuppdatering 1). Den här uppdateringen innehöll flera nya klasser och aktiviteter som gjorde det möjligt för utvecklare att skapa tillståndsdatorarbetsflöden. Dessa klasser och aktiviteter uppdaterades för .NET Framework 4.5 för att inkludera:

    • Möjligheten att ange brytpunkter för tillstånd.

    • Möjligheten att kopiera och klistra in övergångar i arbetsflödesdesignern.

    • Designerstöd för att skapa övergångsövergång för delade utlösare.

    • Aktiviteter för att skapa tillståndsdatorarbetsflöden, inklusive: StateMachine, Stateoch Transition.

  • Förbättrade funktioner i Arbetsflödesdesignern, till exempel följande:

    • Förbättrade funktioner för arbetsflödessökning i Visual Studio, inklusive Snabbsökning och Sök i filer.

    • Möjlighet att automatiskt skapa en sekvensaktivitet när en andra underordnad aktivitet läggs till i en containeraktivitet och att inkludera båda aktiviteterna i sekvensaktiviteten.

    • Stöd för panorering, vilket gör att den synliga delen av ett arbetsflöde kan ändras utan att använda rullningslisterna.

    • En ny dokumentdispositionsvy som visar komponenterna i ett arbetsflöde i en trädliknande dispositionsvy och låter dig välja en komponent i dokumentdispositionsvyn .

    • Möjlighet att lägga till anteckningar i aktiviteter.

    • Möjlighet att definiera och använda aktivitetsdelegater med hjälp av arbetsflödesdesignern.

    • Anslut automatiskt och infoga automatiskt för aktiviteter och övergångar i tillståndsdator- och flödesschemaarbetsflöden.

  • Storage av visningstillståndsinformationen för ett arbetsflöde i ett enda element i XAML-filen, så att du enkelt kan hitta och redigera informationen om visningstillståndet.

  • En NoPersistScope-containeraktivitet för att förhindra att underordnade aktiviteter bevaras.

  • Stöd för C#-uttryck:

    • Arbetsflödesprojekt som använder Visual Basic använder Visual Basic uttryck, och C#-arbetsflödesprojekt använder C#-uttryck.

    • C#-arbetsflödesprojekt som skapades i Visual Studio 2010 och som har Visual Basic uttryck är kompatibla med C#-arbetsflödesprojekt som använder C#-uttryck.

  • Förbättringar av versionshantering:

    • Den nya WorkflowIdentity klassen, som tillhandahåller en mappning mellan en bevarad arbetsflödesinstans och dess arbetsflödesdefinition.

    • Körning sida vid sida av flera arbetsflödesversioner i samma värd, inklusive WorkflowServiceHost.

    • I Dynamisk uppdatering kan du ändra definitionen av en bevarad arbetsflödesinstans.

  • Tjänstutveckling för kontrakt-första arbetsflöde, som ger stöd för att automatiskt generera aktiviteter som matchar ett befintligt tjänstkontrakt.

Mer information finns i Nyheter i Windows Workflow Foundation.

.NET för Windows 8.x Store-appar

Windows 8.x Store-appar är utformade för specifika formfaktorer och utnyttjar kraften i Windows operativsystem. En delmängd av .NET Framework 4.5 eller 4.5.1 är tillgänglig för att skapa Windows 8.x Store-appar för Windows med hjälp av C# eller Visual Basic. Den här delmängden kallas .NET för Windows 8.x Store-appar och beskrivs i en översikt.

Bibliotek för bärbar klass

Med projektet Portable Class Library i Visual Studio 2012 (och senare versioner) kan du skriva och skapa hanterade sammansättningar som fungerar på flera .NET Framework plattformar. Med hjälp av ett portable class library-projekt väljer du plattformarna (till exempel Windows Phone och .NET för Windows 8.x Store-appar) som mål. De tillgängliga typerna och medlemmarna i projektet begränsas automatiskt till vanliga typer och medlemmar på dessa plattformar. Mer information finns i Portabelt klassbibliotek.

Se även