Nyheter i .NET Framework
Not
.NET Framework hanteras oberoende av Windows-uppdateringar med felkorrigeringar för säkerhet och tillförlitlighet. I allmänhet släpps säkerhetsuppdateringar kvartalsvis. .NET Framework fortsätter att ingå i Windows, utan några planer på att ta bort det. Du behöver inte migrera dina .NET Framework-appar, men för ny utveckling använder du .NET 8 eller senare.
Den här artikeln sammanfattar viktiga nya funktioner och förbättringar i följande versioner av .NET Framework:
- .NET Framework 4.8.1
- .NET Framework 4.8
- .NET Framework 4.7.2
- .NET Framework 4.7.1
- .NET Framework 4.7
- .NET Framework 4.6.2
- .NET Framework 4.6.1
- .NET 2015 och .NET Framework 4.6
- .NET Framework 4.5.2
- .NET Framework 4.5.1
- .NET Framework 4.5
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. För plattformar som stöds, se Systemkrav. Nedladdningslänkar och installationsinstruktioner finns i installationsguiden för .
Not
.NET Framework-teamet släpper även funktioner utan band, med Hjälp av NuGet, för att utöka plattformsstöd och introducera nya funktioner, till exempel oföränderliga samlingar och SIMD-aktiverade vektortyper. Mer information finns i Ytterligare klassbibliotek och API:er och .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.1
.NET Framework 4.8.1 bygger på tidigare versioner av .NET Framework 4.x genom att lägga till många nya korrigeringar och flera nya funktioner samtidigt som de är en mycket stabil produkt.
Ladda ned och installera .NET Framework 4.8.1
Du kan ladda ned .NET Framework 4.8.1 från följande platser:
.NET Framework 4.8 kan installeras på Windows 11, Windows 10 version 21H2, Windows 10 version 21H1, Windows 10 version 20H2 och motsvarande serverplattformar från och med Windows Server 2022. Du kan installera .NET Framework 4.8.1 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 in dig på .NET Framework 4.8.1 i Visual Studio 2022 17.3 eller senare genom att installera .NET Framework 4.8.1 Developer Pack.
Nyheter i .NET Framework 4.8.1
.NET Framework 4.8.1 introducerar nya funktioner inom följande områden:
- Internt stöd för Arm64
- WCAG2.1-kompatibla tillgängliga verktygstips
- Windows Forms – Tillgänglighetsförbättringar
Förbättrad tillgänglighet, vilket gör att ett program kan ge en lämplig upplevelse för användare av assistiv teknik, är ett stort fokus för .NET Framework 4.8.1. Information om tillgänglighetsförbättringar i .NET Framework 4.8.1 finns i Nyheter om tillgänglighet i .NET Framework.
.NET Framework 4.8.1 lägger till inbyggt Arm64-stöd till .NET Framework-familjen. Dina investeringar i det stora ekosystemet med .NET Framework-appar och -bibliotek kan nu dra nytta av fördelarna med att köra arbetsbelastningar internt på Arm64, nämligen bättre prestanda jämfört med att köra x64-kod som emuleras på Arm64.
Microsoft har ett åtagande att tillhandahålla produkter och plattformar som är tillgängliga för alla. .NET Framework 4.8.1 erbjuder två utvecklingsplattformar för Windows-användargränssnittet, som båda ger utvecklare den support som krävs för att skapa tillgängliga program. Under de senaste versionerna har både Windows Forms och WPF lagt till nya funktioner och åtgärdat många tillförlitlighetsproblem som rör tillgänglighet. Du kan läsa mer om detaljerna om vad som har åtgärdats eller lagts till i varje release genom att besöka Nyheter i tillgänglighet i .NET Framework.
I den här versionen har både Windows Forms och WPF förbättrat hanteringen av knappbeskrivningar för att göra dem mer tillgängliga. I båda fallen följer verktygstips nu de riktlinjer som anges i WCAG2.1-innehåll om hovring eller fokus enligt-vägledningen. Kraven för knappbeskrivningar är:
- Knappbeskrivningar måste visas antingen via muspekaren eller genom tangentbordsnavigering till kontrollen.
- Knappbeskrivningar bör vara stängbara. Det vill säga att ett enkelt tangentbordskommando som Esc ska avvisa verktygstipset.
- Verktygstips bör kunna hovras över. Användarna bör kunna placera musmarkören över verktygstipset. Detta gör det möjligt för scenarier som att använda förstoringsglas för att kunna läsa knappbeskrivningen för användare med nedsatt syn.
- Knappbeskrivningarna bör vara beständiga. Verktygstips bör inte försvinna automatiskt efter att en viss tid har gått. I stället bör verktygstips avfärdas när användaren flyttar musen till en annan kontroll eller med ett tangentbordskommando.
I Windows Forms är det här stödet endast tillgängligt på Windows 11- eller senare operativsystem. Windows Forms är en tunn hanterad omslutning runt Windows-API:et och det nya beteendet för verktygstips blev endast tillgängligt i Windows 11. WPF har inga operativsystemversionsberoenden för dess tillgängliga knappbeskrivningar.
WPF hade implementerat de flesta kraven för WCAG2.1-kompatibla knappbeskrivningar i .NET Framework 4.8. I den här versionen förbättrade WPF upplevelsen genom att säkerställa att ett verktygstips i det aktuella fönstret enkelt kan stängas med hjälp av tangenten Esc, tangenten Ctrl eller genom tangentkombinationen Ctrl+Shift+F10. Escape-nyckelns omfattning minskades i den här versionen så att den endast gäller för det aktuella fönstret. Tidigare tillämpades detta på alla öppna verktygstips i programmet.
Windows Forms var den första Windows UI-stacken som skapades för .NET Framework. Därför skapades den ursprungligen för att använda äldre hjälpmedelsteknik, som inte uppfyller de aktuella tillgänglighetskraven. I den här versionen har Windows Forms åtgärdat ett antal problem. En fullständig lista över hjälpmedelsrelaterade ändringar finns i Nyheter i hjälpmedel i .NET Framework.
Höjdpunkterna i Förbättringar av Windows Forms i .NET Framework 4.8.1 är:
Stöd för textmönster– Windows Forms har lagt till stöd för UIA-textmönstret. Det här mönstret gör det möjligt för hjälpmedelstekniken att bläddra igenom innehållet i en textruta eller liknande textbaserad kontrollbokstav per bokstav. Det gör att text kan väljas i kontrollen och ändras, och ny text kan infogas vid markören. Windows Forms har lagt till det här stödet för TextBox, DataGridView-celler, ComboBox-kontroller med mera.
Åtgärda kontrastproblem – I flera kontroller har Windows Forms ändrat kontrastförhållandet för markeringsrektanglar så att de blir mörkare och mer synliga.
Flera DataGridView-problem har åtgärdats:
- Rullningslistnamnen har uppdaterats så att de är konsekventa.
- Narrator kan nu fokusera på tomma DataGridView-celler.
- Utvecklare kan ange egenskapen för lokaliserad kontrolltyp för Custom DataGridView-celler.
- Länkfärgen för DataGridViewLink-celler har uppdaterats för att få bättre kontrast till bakgrunden.
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 de är en mycket stabil produkt.
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 in dig på .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:
- basklasser
- Windows Communication Foundation (WCF)
- Windows Presentation Foundation (WPF)
- Gemensam språk-körmiljö
Förbättrad tillgänglighet, som gör att ett program kan tillhandahålla en lämplig upplevelse för användare av assistiv teknik, fortsätter att vara ett stort fokus för .NET Framework 4.8. Information om hjälpmedelsförbättringar i .NET Framework 4.8 finns i Nyheter i hjälpmedel i .NET Framework.
Basklasser
Minskad FIPS-påverkan på kryptografi. I tidigare versioner av .NET Framework har hanterade kryptografiska providerklasser som SHA256Managed generera en CryptographicException när 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.
Som standard i program som riktar in sig på .NET Framework 4.8 genererar följande hanterade kryptografiklasser inte längre en CryptographicException i det här fallet:
- MD5Cng
- MD5CryptoServiceProvider
- RC2CryptoServiceProvider
- RijndaelManaged
- RIPEMD160Managed
- SHA256Managed
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 de här undantagen kan återställa det tidigare beteendet genom att ställa in AppContext-växeln Switch.System.Security.Cryptography.UseLegacyFipsThrow
till true
. Mer information finns i Hanterade kryptografiklasser utlöser inte en CryptographyException 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 har uppdaterats 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 av ServiceHealthBehavior
Hälsoendpunkter används ofta av orkestreringsverktyg för att hantera tjänster baserat på tjänsternas hälsotillstånd. Hälsokontroller kan också användas av övervakningsverktyg för att spåra och tillhandahålla meddelanden om tillgänglighet och prestanda för en tjänst.
ServiceHealthBehavior är ett WCF-tjänstbeteende som utökar IServiceBehavior. När den läggs till i ServiceDescription.Behaviors-samlingen gör ett tjänstbeteende följande:
Returnerar tjänstens hälsostatus med HTTP-svarskoder. Du kan i en frågesträng ange HTTP-statuskoden för en HTTP/GET-hälsoavsökningsbegäran.
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
?health
frågesträng. Enkel åtkomst till sådan information är viktigt när du felsöker en felaktig WCF-tjänst.
Det finns två sätt att exponera hälsoslutpunkten och publicera hälsoinformation för WCF-tjänsten:
Via kod. Till 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. Till 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. Till exempel:
OnServiceFailure:
https://contoso:81/Service1?health&OnServiceFailure=450
En 450 HTTP-svarsstatuskod returneras när ServiceHost.State är större än CommunicationState.Opened.
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 kanallyssnarna ä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)
höga DPI-förbättringar
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 finns i Utveckling av DPI-skrivbordsprogram i Windows.
.NET Framework 4.8 förbättrar stödet för värdbaserade HWND:er och Windows Forms-interoperation i High-DPI WPF-program på plattformar som stöder Mixed-Mode DPI-skalning (från och med Windows 10 April 2018 Update). När värdbaserade HWND- 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 skalas på rätt sätt. Sådant värdbaserat innehåll återges inte i den interna DPI:en. I stället skalar operativsystemet det värdbaserade innehållet till rätt storlek. Stödet för Per-Monitor v2 DPI-medvetenhetsläge möjliggör också att WPF-kontroller kan integreras (dvs. skapas som överordnade) i ett inbyggt fönster i en applikation med hög DPI.
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>
Körning av vanligt språk
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 .NET Core 2.1 JIT-kompilatorn ingår i .NET Framework 4.8 JIT-kompilatorn.
NGEN-förbättringar. Körtiden har förbättrat minneshanteringen för NGEN-avbildningar (Native Image Generator) så att data som mappas från NGEN-avbildningar inte längre finns i minnet. Detta minskar ytan 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 för 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 metoden Assembly.Load(Byte[]), 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 lösningar för 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 tillhandahålla en lämplig upplevelse för användare av assistiv teknik. Information om tillgänglighetsförbättringar i .NET Framework 4.7.2 finns i Vad är nytt inom tillgänglighet 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 insamlings-API:er.
Nya överlagringar av RSA. Skapa och DSA. Skapa
Med metoderna DSA.Create(DSAParameters) 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 metoderna DSA.Create(Int32) och RSA.Create(Int32) kan du generera nya DSA eller RSA nycklar med en specifik nyckelstorlek. Till 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 hashalgoritmnamn
Klassen Rfc2898DeriveBytes har tre nya konstruktorer med en HashAlgorithmName parameter som identifierar HMAC-algoritmen som ska användas när nycklar härleds. 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 metoden X509Certificate2.Import läses de privata nycklarna in som tillfälliga nycklar. Detta förhindrar att nycklarna visas på disken. Emellertid:
Eftersom nycklarna inte sparas på disken är certifikat som läses in med den här flaggan inte bra kandidater att lägga till i en X509Store.
Nycklar som läses in på det här sättet 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ösa tester innan de byter till tillfälliga nycklar.
Programmatic-skapande av begäranden om PKCS#10-certifieringssignering 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äran kan mellanlagras till befintliga verktyg. Detta är ofta användbart i testscenarier.
För mer information och kodexempel, se "Programmatisk skapande av PKCS#10-certifikatbegäran och X.509-offentliga nyckelcertifikat" i .NET Blogg.
Nya SignerInfo-medlemmar
Från och med .NET Framework 4.7.2 visar klassen SignerInfo mer information om signaturen. Du kan hämta värdet för egenskapen System.Security.Cryptography.Pkcs.SignerInfo.SignatureAlgorithm 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ämnar en inkapslad ström öppen efter att CryptoStream har kasserats
Från och med .NET Framework 4.7.2 har klassen CryptoStream ytterligare en konstruktor som gör att Dispose inte stänger den omslutna strömmen. Om du vill lämna den omslutna strömmen öppen när CryptoStream-instansen har avyttrats anropar du den nya CryptoStream konstruktorn enligt följande:
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 klassen DeflateStream ä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 riktar in sig på .NET Framework 4.7.2. 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 till 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 för SortedSet<T> och HashSet<T> typer. Dessa inkluderar:
TryGetValue
metoder som utökar try-mönstret som används i andra samlingstyper till dessa två typer. Metoderna är:Enumerable.To*
tilläggsmetoder som konverterar en samling till en HashSet<T>:Nya HashSet<T> konstruktorer som gör att du kan ange samlingens kapacitet, vilket ger en prestandafördel när du vet storleken på HashSet<T> i förväg:
Klassen ConcurrentDictionary<TKey,TValue> innehåller nya överlagringar av AddOrUpdate- och GetOrAdd-metoderna för att hämta ett värde från ordlistan eller lägga till det om det inte hittas, 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 riktar sig mot .NET Framework 4.7.2 kan du:
Använd setter-baserad, gränssnittsbaserad och konstruktorbaserad injektion i -hanterare och moduler, Page-instanseroch användarkontroller för ASP.NET webbapplikationsprojekt.
Använd setter-baserad och gränssnittsbaserad injektion i -hanterare och moduler, Page-instanseroch användarkontroller inom ASP.NET-webbplatsprojekt.
Anslut olika beroendeinmatningsramverk.
Support 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 värdet är SameSiteMode.Strict eller SameSiteMode.Laxlägger ASP.NET till attributet SameSite
i set-cookie-huvudet. SameSite-stöd gäller för HttpCookie objekt, samt för FormsAuthentication och System.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ätverkande
Implementering av HttpClientHandler-egenskaper
.NET Framework 4.7.1 har lagt till åtta egenskaper i klassen System.Net.Http.HttpClientHandler. Men två kastade 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 Universal Authentication 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ödde SQL-anslutningen endast alternativen SqlAuthenticationMethod.ActiveDirectoryPassword och SqlAuthenticationMethod.ActiveDirectoryIntegrated. 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 multifaktorautentisering" i .NET-blogg.
Stöd för Always Encrypted version 2
NET Framework 4.7.2 lägger till stöd för enklaverbaserad Always Encrypted. Den ursprungliga versionen av Always Encrypted är en krypteringsteknik på klientsidan där krypteringsnycklar aldrig lämnar klienten. I enklaverbaserad 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-koden inte kan manipuleras med. För att stödja enklaverbaserad Always Encrypted lägger .NET Framework 4.7.2 till följande typer och medlemmar i System.Data.SqlClient namnområde:
SqlConnectionStringBuilder.EnclaveAttestationUrl, som anger Uri för enklaverbaserad Always Encrypted.
SqlColumnEncryptionEnclaveProvider, som är en abstrakt klass som alla enklavprovidrar härleds från.
SqlEnclaveSession, som kapslar in tillståndet för en viss enklavsession.
SqlEnclaveAttestationParameters, som tillhandahåller attesteringsparametrarna som används av SQL Server för att få information som krävs för att köra ett visst attesteringsprotokoll.
Programkonfigurationsfilen anger sedan en konkret implementering av den abstrakta System.Data.SqlClient.SqlColumnEncryptionEnclaveProvider-klassen som tillhandahåller funktionerna för enklavprovidern. Till 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 enklaverbaserad Always Encrypted är:
Användaren skapar en AlwaysEncrypted-anslutning till SQL Server som stöder enklaverbaserad Always Encrypted. Drivrutinen kontaktar attesteringstjänsten för att säkerställa att den ansluter till rätt enklav.
När enklaven har intygats etablerar drivrutinen en säker kanal med den säkra enklaven som finns på SQL Server.
Drivrutinen delar krypteringsnycklar som har auktoriserats av klienten med den säkra enklaven under SQL-anslutningens varaktighet.
Windows Presentation Foundation
Hitta resursordlistor efter käll-
Från och med .NET Framework 4.7.2 kan en diagnostikassistent hitta 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, till exempel Visual Studio's "Edit-and-Continue"-anläggning, 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 det program 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 hjälp av en absolut URI som identifierar den ursprungliga markering, 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äkning såvida inte VisualDiagnostics är aktiverat och ENABLE_XAML_DIAGNOSTICS_SOURCE_INFO
miljövariabeln har angetts.
Att hitta Resursordboksägare
Från och med .NET Framework 4.7.2 kan en diagnostikassistent hitta ägarna till en viss ResourceDictionary. (Funktionen är till för användning av diagnostikassistenter och inte av produktionsprogram.) När en ändring görs i en ResourceDictionaryhittar WPF automatiskt alla DynamicResource- referenser som kan påverkas av ändringen.
En diagnostikassistent som 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 ägarna till ordlistan. för att hitta alla objekt vars Resources
egenskap refererar till ordlistan (antingen direkt eller indirekt via egenskapen ResourceDictionary.MergedDictionaries). Tre nya statiska metoder som implementerats i klassen System.Windows.Diagnostics.ResourceDictionaryDiagnostics, 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 är aktiverat och ENABLE_XAML_DIAGNOSTICS_SOURCE_INFO
miljövariabeln har angetts.
Att hitta StaticResource-referenser
En diagnostikassistent kan nu få ett meddelande när en StaticResource- referens har lösts. (Funktionen är till för användning av diagnostikassistenter, inte av produktionsprogram.) En diagnostikassistent som Visual Studio:s "Edit-and-Continue"-anläggning kanske vill uppdatera alla användningar av en resurs när dess värde i en ResourceDictionary ändras. 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ändningar av 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 genereras när programkörningen löser en StaticResource-referens. De StaticResourceResolvedEventArgs argumenten beskriver lösningen och anger objektet och egenskapen som är värd för referensen StaticResource och ResourceDictionary och 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 utlöses inte (och dess add
-accessor ignoreras) om 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-programmet ä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 det möjligt för ett program att tillhandahålla en lämplig upplevelse för användare av Assistive Technology. Information om förbättringar för tillgänglighet i .NET Framework 4.7.1 finns i Nyheter inom 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 stöder helt .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 "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 stund innan ett program startas.
Om du vill skapa en anpassad konfigurationsbyggare härleder du byggaren från den abstrakta ConfigurationBuilder-klassen och åsidosätter dess ConfigurationBuilder.ProcessConfigurationSection och ConfigurationBuilder.ProcessRawXml. Du definierar även dina byggare i din .config-fil. Mer information finns i avsnittet "Configuration Builders" i blogginlägget .NET Framework 4.7.1 ASP.NET och Configuration Features.
Funktionsdetektion vid körtid
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örningstid. 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 utnyttjar den funktionen. Vid körning kan ett program anropa metoden RuntimeFeature.IsSupported innan det genererar kod. Mer information finns i Lägg till hjälpmetod för att beskriva funktioner som stöds av körningsmiljön.
Värde tuppeln typer är serialiserbara
Från och med .NET Framework 4.7.1 markeras System.ValueTuple och dess associerade generiska typer som Serializable, vilket tillåter binär serialisering. Detta bör göra det enklare att migrera Tupletyper, såsom Tuple<T1,T2,T3> och Tuple<T1,T2,T3,T4>, till värdetupletyper. Mer information finns i "Compiler - ValueTuple is Serializable" i blogginlägget .NET Framework 4.7.1 Runtime and Compiler Features.
Stöd för läs-och-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 "Compiler - Support for ReadOnlyReferences" i blogginlägget .NET Framework 4.7.1 Runtime and Compiler Features. Information om referensreturvärden finns i Referensreturvärden och ref lokala variabler och Referensreturvärden (Visual Basic).
Common Language Runtime (CLR)
Förbättringar av prestanda för skräpsamling
Ändringar av garbage collection (GC) i .NET Framework 4.7.1 förbättrar den övergripande prestandan, särskilt för allokeringar i large object heap (LOH). I .NET Framework 4.7.1 används separata lås för SOH-allokeringar (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ås-konkurrens och förbättrad prestanda. Mer information finns i avsnittet "Runtime - GC Performance Improvements" i blogginlägget .NET Framework 4.7.1 Runtime and Compiler Features.
Nätverkande
SHA-2-stöd för Message.HashAlgorithm
I .NET Framework 4.7 och tidigare versioner stöds Message.HashAlgorithm-egenskapen endast värden för HashAlgorithm.Md5 och HashAlgorithm.Sha. Från och med .NET Framework 4.7.1 stöds även HashAlgorithm.Sha256, HashAlgorithm.Sha384och HashAlgorithm.Sha512. Om det här värdet faktiskt används beror på MSMQ, eftersom själva Message-instansen inte hashar utan bara skickar värden till MSMQ. Mer information finns i avsnittet "SHA-2-stöd för Message.HashAlgorithm" i .NET Framework 4.7.1 ASP.NET- och konfigurationsfunktioner blogginlägg.
ASP.NET
Körningssteg i ASP.NET-applikationer
ASP.NET bearbetar begäranden i en fördefinierad pipeline som innehåller 23 händelser. Varje händelsehanterare körs som ett körningssteg av ASP.NET. 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 överför ASP.NET selektivt endast HttpContext. Från och med .NET Framework 4.7.1 tillåter metoden HttpApplication.OnExecuteRequestStep(Action<HttpContextBase,Action>) även moduler att återställa omgivande data. Den här funktionen riktar sig till bibliotek som handlar om spårning, profilering, diagnostik eller transaktioner, till exempel som bryr sig om programmets körningsflöde. Mer information finns i funktionen "ASP.NET Execution Step" i blogginlägget .NET Framework 4.7.1 ASP.NET och Configuration Features.
ASP.NET HttpCookie parsing
.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 som förfallodatum och sökväg. Mer information finns i "ASP.NET HttpCookie parsing" i blogginlägget .NET Framework 4.7.1 ASP.NET och Configuration Features.
SHA-2-hashalternativ för autentiseringsuppgifter för ASP.NET formulär
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 är fortfarande standard och en hash-algoritm som inte är standard kan definieras i webbkonfigurationsfilen.
Viktig
Microsoft rekommenderar att du använder det säkraste tillgängliga autentiseringsflödet. Om du ansluter till Azure SQL är hanterade identiteter för Azure-resurser den rekommenderade autentiseringsmetoden.
Nyheter i .NET Framework 4.7
.NET Framework 4.7 innehåller nya funktioner inom följande områden:
- basklasser
- Nätverk
- ASP.NET
- Windows Communication Foundation (WCF)
- Windows Forms
- Windows Presentation Foundation (WPF)
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. För mer information, se Tillkännagivande av .NET Framework 4.7 i .NET-bloggen.
Basklasser
.NET Framework 4.7 förbättrar serialiseringen med DataContractJsonSerializer:
Förbättrad funktionalitet med Elliptic Curve Cryptography (ECC)*
I .NET Framework 4.7 lades ImportParameters(ECParameters)
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 hjälp av explicita kurvparametrar.
.NET Framework 4.7 lägger också till stöd för ytterligare kurvor (inklusive Brainpool-kurvsviten) och har lagt till fördefinierade definitioner för enkel skapande via de nya Create- och Create fabriksmetoderna.
Du kan se ett exempel på kryptografiförbättringarna i .NET Framework 4.7 på GitHub.
Bättre stöd för kontrolltecken från DataContractJsonSerializer
I .NET Framework 4.7 serialiserar DataContractJsonSerializer-klassen kontrolltecken i enlighet med ECMAScript 6-standarden. Det här beteendet är aktiverat som standard för program som är inriktade på .NET Framework 4.7 och är en funktion för att anmäla sig för program som körs under .NET Framework 4.7 men som riktar sig mot en tidigare version av .NET Framework. Mer information finns i avsnittet Programkompatibilitet.
Nätverkande
.NET Framework 4.7 lägger till följande nätverksrelaterade funktion:
Standardoperativsystemstöd 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 standardimplementeringarna 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:
Object Cache Store. Med hjälp av konfigurationsavsnittet för nya cacheproviders kan utvecklare ansluta nya implementeringar av ett 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 närmar sig 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 av egenskapen ApplicationMonitors.MemoryMonitor.
minnesbegränsningsreaktioner. Som standard försöker ASP.NET trimma objektcacheminnet och anropar 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 cacheminne som trimmas ineffektiv. Utvecklare kan nu ersätta eller komplettera standardbeteendet genom att registrera IObserver-implementeringar på 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 frivillig inställning; för att aktivera den måste du lägga till följande post i din konfigurationsfil:
<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 inkluderar:
- 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 metoden FormatterServices.GetSerializableMembers(Type).
- Förbättrad tillförlitlighet när du tar bort en servitör genom att anropa metoden ChannelSynchronizer.RemoveWaiter.
Windows-formulär
I .NET Framework 4.7 förbättrar Windows Forms stöd 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ög-DPI-skä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 ett <System.Windows.Forms.ConfigurationSection>-avsnittet i programkonfigurationsfilen. Mer information om hur du lägger till stöd för hög DPI och dynamiskT DPI i ditt Windows Forms-program finns i stöd för hög DPI 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 pek-/pennastack baserat på Windows-WM_POINTER meddelanden
Nu kan du använda en pek-/pennastack baserat på WM_POINTER meddelanden i stället för Windows Ink Services Platform (WISP). 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 klassen System.Printing.PrintQueue anropar API:et för Dokumentpaket för windows utskriftspaket i stället för det inaktuella XPS Print API. 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 Announcing .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 validering av dataanteckningar 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:
ValidationAttribute.ErrorMessage anges i valideringsattributet.
Resursfilen lagras i mappen App_LocalResources.
Namnet på den lokaliserade resursfilen har formuläret
DataAnnotation.Localization.{
namn}.resx
, där namn är ett kulturnamn i formatet languageCode-
country/regionCode eller languageCode.Resursens nyckelnamn är strängen 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 mappen App.LocalResources
. Ett exempel på detta är nyckeln och dess värde i ett felmeddelande på lokaliserad franska (fr).
Namn | Värde |
---|---|
Klassificeringen måste vara mellan 1 och 10. | Betyget måste vara mellan 1 och 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åndslagringsleverantö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åndsleverantörer har 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 sessionstillståndsleverantörer. 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 innehåller klassen SessionStateUtility två nya metoder, IsSessionStateReadOnly och IsSessionStateRequired, som kan användas för asynkrona åtgärder.
Asynkront stöd för utdatacache-leverantörer
Från och med .NET Framework 4.6.2 kan uppgiftsreturmetoder användas med utdatacacheproviders för att ge skalbarhetsfördelarna med asynkronisering. 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 utdatacacheleverantörer.
Klassen System.Web.Caching.OutputCacheProviderAsync, som ärver från System.Web.Caching.OutputCacheProvider och gör det möjligt för utvecklare att implementera en asynkron utdatacacheprovider.
Klassen OutputCacheUtility, som innehåller hjälpmetoder för att konfigurera utdatacachen.
18 nya metoder i klassen System.Web.HttpCachePolicy. Dessa inkluderar GetCacheability, GetCacheExtensions, GetETag, GetETagFromFileDependencies, GetMaxAge, GetMaxAge, GetNoStore, GetNoTransforms, GetOmitVaryStar, GetProxyMaxAge, GetRevalidation, GetUtcLastModified, GetVaryByCustom, HasSlidingExpirationoch IsValidUntilExpires.
2 nya metoder i klassen System.Web.HttpCacheVaryByContentEncodings: GetContentEncodings och SetContentEncodings.
2 nya metoder i klassen System.Web.HttpCacheVaryByHeaders: GetHeaders och SetHeaders.
2 nya metoder i klassen System.Web.HttpCacheVaryByParams: GetParams och SetParams.
I klassen System.Web.Caching.AggregateCacheDependencyGetFileDependencies metoden.
I metoden CacheDependencyGetFileDependencies.
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öd för Unicode 8.0 är begränsat till klassificering av tecken efter klassen CharUnicodeInfo och till typer och metoder som är beroende av den. Dessa omfattar klassen StringInfo, den överbelastade metoden Char.GetUnicodeCategory och teckenklasserna som känns igen av .NET Framework-motorn 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 (algoritm för digital signatur) X509 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 datorsignaturer 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 i klassen RSA i .NET Framework 4.6 och klassen ECDsa i .NET Framework 4.6.1 har DSA abstrakt basklass 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, vilket visas i följande exempel.
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 har lagt 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äste 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 den ECDiffieHellman basklassen för att tydligare representera dessa KDF-rutiner och deras indata:
ECDiffieHellman-metod | Beskrivning |
---|---|
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 Eller x Eller 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 bestående nycklar
Windows kryptografibibliotek (CNG) har lagt 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). Till 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 signaturmetoderna RSA-SHA256, RSA-SHA384 och RSA-SHA512 PKCS#1 samt SHA256-, SHA384- och SHA512-referenssammandragsalgoritmer.
URI-konstanterna exponeras alla på SignedXml:
SigneradXml-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 i 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 är CryptoConfig registrering inte längre nödvändigt.
SqlClient
.NET Framework Data Provider för SQL Server (System.Data.SqlClient) innehåller följande nya funktioner i .NET Framework 4.6.2:
Anslutningspooler och tidsgränser med Azure SQL-databaser
När anslutningspoolen är aktiverad och ett timeoutfel eller ett 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 Databases, 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 Databases misslyckas.
Med det nya nyckelordet PoolBlockingPeriod
kan du välja den blockeringsperiod som passar bäst för din app. Värden inkluderar:
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 en annan SQL Server-instans är aktiverad. Det här är standardvärdet. Om serverslutpunktens namn slutar med något av följande anses de vara Azure SQL Databases:
.database.windows.net
.database.chinacloudapi.cn
.database.usgovcloudapi.net
.database.cloudapi.de
Blockeringsperioden för anslutningspoolen är alltid aktiverad.
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 prestandan för parametriserade frågor mot krypterade databaskolumner cachelagras nu krypteringsmetadata för frågeparametrar. Med egenskapen SqlConnection.ColumnEncryptionQueryMetadataCacheEnabled inställd på
true
(vilket är standardvärdet), om samma fråga anropas flera gånger, hämtar klienten endast parametermetadata från servern en gång.Kolumnkrypteringsnyckelposter i nyckelcachen avlägsnas nu efter ett konfigurerbart tidsintervall som anges med egenskapen SqlConnection.ColumnEncryptionKeyCacheTtl.
Windows Communication Foundation
I .NET Framework 4.6.2 har Windows Communication Foundation förbättrats inom 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 riktar in sig på .NET Framework 4.6.2 är den här funktionen aktiverad som standard.
För program som riktar in sig på .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 klassen DataContractJsonSerializer 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 din app.config-fil:
<runtime>
<AppContextSwitchOverrides value="Switch.System.Runtime.Serialization.DoNotUseTimeZoneInfo=false" />
</runtime>
När den här funktionen är aktiverad använder ett DataContractJsonSerializer-objekt den TimeZoneInfo typen i stället för den TimeZone typen för att deserialisera datum- och tidsdata. TimeZoneInfo stöder flera justeringsregler, vilket gör det möjligt att arbeta med historiska tidszonsdata. TimeZone gör det inte.
Mer information om TimeZoneInfo struktur- och tidszonsjusteringar finns i Tidszonsöversikt.
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 som lyssnar på den URI som bäst matchar den som de begär. Med den här appinställningen inställd på false
(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 på false
försöker klienten ansluta till fel tjänst. När du har angett appinställningen till true
ansluter klienten alltid till den bästa matchande tjänsten.
Not
Klienter som använder NetNamedPipeBinding hitta tjä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.
Egenskapen SslStreamSecurityBindingElement.SslProtocols
Egenskapen TcpTransportSecurity.SslProtocols
Avsnittet <transport> i delen <netTcpBinding>
Avsnittet <sslStreamSecurity> i avsnittet <customBinding>
Windows Presentation Foundation (WPF)
I .NET Framework 4.6.2 har Windows Presentation Foundation förbättrats inom följande områden:
Grupperingssortering
Ett program som använder ett CollectionView-objekt för att gruppera data kan nu uttryckligen deklarera hur grupperna ska sorteras. Explicit sortering åtgärdar problemet med icke-intuitiv ordning 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 prestandan för gruppskapandeprocessen genom att flytta jämförelser av grupperingsegenskaperna från den typ av den fullständiga samlingen till typen av grupper.
För att stödja gruppsortering beskriver de nya egenskaperna GroupDescription.SortDescriptions och GroupDescription.CustomSort hur du sorterar samlingen med grupper som skapas av GroupDescription-objektet. Detta motsvarar hur de identiskt namngivna egenskaperna ListCollectionView beskriver hur du sorterar dataobjekten.
Två nya statiska egenskaper för klassen PropertyGroupDescription, CompareNameAscending och CompareNameDescending, kan användas för de vanligaste fallen.
Till exempel grupperar följande XAML-data efter ålder, sorterar åldersgrupperna i stigande ordning och grupperar objekten inom varje åldersgrupp efter efternamn.
<GroupDescriptions>
<PropertyGroupDescription
PropertyName="Age"
CustomSort=
"{x:Static PropertyGroupDescription.CompareNamesAscending}"/>
</PropertyGroupDescription>
</GroupDescriptions>
<SortDescriptions>
<SortDescription PropertyName="LastName"/>
</SortDescriptions>
Touch-tangentbordsstöd
Stöd för pektangentbord 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-pekskärmsstöd eller förlita sig på Windows-musemulation.
DPI för varje skärm
För att stödja den senaste ökningen av miljöer med hög DPI och hybrid-DPI för WPF-appar aktiverar WPF i .NET Framework 4.6.2 medvetenhet för varje skärm. Se exempel och utvecklarguide på GitHub för mer information om hur du kan göra din WPF-app DPI-medveten per monitor.
I tidigare versioner av .NET Framework är WPF-appar system-DPI-medvetna. Med andra ord skalas applikationens användargränssnitt av operativsystemet efter behov, beroende på DPI för bildskärmen där appen visas.
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 avsnittet <körning> 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 inom följande område:
Stöd för C#-uttryck och IntelliSense i den Rehostade WF Designer
Från och med .NET Framework 4.5 stöder WF C#-uttryck i både Visual Studio Designer och i kodarbetsflöden. Arbetsflödesdesignern för omvärdering är en viktig funktion i WF som gör att arbetsflödesdesignern kan finnas i ett program utanför Visual Studio (till exempel i WPF). Windows Workflow Foundation ger möjlighet att stödja C#-uttryck och IntelliSense i arbetsflödesdesignern för värdbaserad. Mer information finns i bloggen Windows Workflow Foundation.
Availability of IntelliSense when a customer rebuilds a workflow project from Visual Studio
I 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. Även om projektversionen lyckas, hittas 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.
V1-arbetsflödesprogram med arbetsflödesspårning körs nu i FIPS-läge
Datorer med FIPS-kompatibilitetsläge aktiverat kan nu köra ett arbetsflöde version 1-liknande program med arbetsflödesspårning på. Om du vill aktivera det här scenariot måste du göra följande ändring i din app.config-fil:
<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 windowsplattformens FIPS-verifierade kryptografiska algoritmer."
arbetsflödesförbättringar när du använder dynamisk uppdatering med Visual Studio Workflow Designer
Arbetsflödesdesignern, FlowChart Activity Designer och andra arbetsflödesaktivitetsdesigners läser nu in och visar arbetsflöden som har sparats efter att ha anropat metoden 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 att DynamicUpdateServices.PrepareForUpdate anropats 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 arbetsflödesaktivitetsdesigners 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 TLS 1.1- och 1.2-stöd.
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 UWP (Universal Windows Platform). Den här tekniken fungerar som en brygga genom att göra det möjligt för dig att gradvis migrera din befintliga kodbas till UWP, vilket gör att din app 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 fullständig förtroendeapp. När appen har konverterats kan en appcontainerprocess 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 kastas, så att det blir möjligt att avgöra vilken variabel i en enda rad med källkod som null
. För att stödja det här scenariot har följande API:er lagts till i det ohanterade felsöknings-API:et.
ICorDebugCode4, ICorDebugVariableHomeoch ICorDebugVariableHomeEnum-gränssnitten, som exponerar ursprungliga platser för hanterade variabler. Detta gör det möjligt för felsökare att utföra kodflödesanalys när en NullReferenceException inträffar och återgå för att fastställa den hanterade variabeln som motsvarar den inbyggda platsen som var
null
.Metoden ICorDebugType2::GetTypeID innehåller en mappning för ICorDebugType till COR_TYPEID, vilket gör att felsökaren kan hämta en COR_TYPEID utan en instans av ICorDebugType. Befintliga API:er på COR_TYPEID kan sedan användas för att fastställa klasslayouten för typen.
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:
.NET Framework API diff (på GitHub)
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. .NET Framework-implementeringen 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 använda asymmetriska nycklar som lagras i HSM:er utan att behöva skriva anpassade huvudnyckellagringsleverantörer för kolumner och registrera dem i program.
Kunder måste installera den CSP-leverantör eller CNG-nyckellagring som tillhandahålls av HSM-leverantören på appservrarna eller klientdatorerna för att få åtkomst till data som är Always Encrypted och skyddas med kolumnmästernycklar 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 så att den inkluderade "MultisubnetFailover=true"
för att indikera att den anslöt till en AlwaysOn-tillgänglighetsgrupp. Utan att ställa in anslutningsnyckelordet på true
kan ett program få en timeout vid anslutning till en AlwaysOn-tillgänglighetsgrupp. Med den här versionen behöver inte ett program ange MultiSubnetFailover till true
längre. 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.
Förbättrad prestanda
Fördröjningen vid aktivering av touchhändelser har åtgärdats i .NET Framework 4.6.1. Dessutom binder skrivning i en RichTextBox-kontroll inte längre renderingstråden vid snabb inmatning.
förbättringar av stavningskontroll
Stavningskontroll i WPF har uppdaterats i Windows 8.1 och senare versioner för att utnyttja operativsystemsstöd för stavningskontroll av ytterligare språk. Det finns ingen ändring i funktionaliteten i Windows-versioner 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 blogginlägget WPF 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 kontrollobjekt.
I tidigare versioner av WPF kände anpassade ordlistor inte igen undantagna ord- och autokorrigeringslistor. De stöds i Windows 8.1 och Windows 10 med hjälp av filer som kan placeras under katalogen %AppData%\Microsoft\Spelling\<language tag>
. Följande regler gäller för dessa filer:
Filerna ska ha tillägg av .dic (för tillagda ord), .exc (för undantagna ord) eller .acl (för Autokorrigering).
Filerna ska vara UTF-16 LE klartext som börjar med Byte Order Mark (BOM).
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.
Notera
Dessa nya filformat stöds inte direkt av API:erna för stavningskontroll av WPF, och de anpassade ordlistor som tillhandahålls till WPF i program bör fortsätta att använda .lex-filer.
exempel
Det finns ett antal WPF-exempel på Microsoft/WPF-Samples GitHub-lagringsplats. 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-transaktionsbefrämjande identifierare för den nya Transaction.EnlistPromotableSinglePhase(IPromotableSinglePhaseNotification, Guid) överlagring . Om den här åtgärden lyckas finns det begränsningar för transaktionens funktioner. När en icke-MSDTC-transaktionspromotor har tillhandahållits, utlöser följande metoder en TransactionPromotionException eftersom dessa metoder kräver befordran till MSDTC:
När en icke-MSDTC-transaktionsenlistare har registrerats måste den användas för framtida beständiga åtaganden med hjälp av protokoll som den definierar. Transaktionsarrangörens Guid kan hämtas med hjälp av egenskapen PromoterType. När transaktionen marknadsförs tillhandahåller transaktionsfrämjaren en Byte array som representerar den marknadsförda token. Ett program kan hämta en promoverad token för en icke-MSDTC-promoverad transaktion med metoden GetPromotedToken.
Användare av den nya Transaction.EnlistPromotableSinglePhase(IPromotableSinglePhaseNotification, Guid) överbelastning måste följa en specifik anropssekvens för att befordran ska slutföras. Dessa regler dokumenteras i metodens dokumentation.
Profilering
Api:et för ohanterad profilering 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 gör profileringsverktyg innebär det att PDF-filer som historiskt har 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 in-memory PDB-data kan en profilerare genom att använda de nya API:erna hämta innehållet i en minnesintern PDB som bytematris och sedan bearbeta eller serialisera den till disk.
Bättre instrumentation med ICorProfiler-gränssnittet.
Profilerare som använder
ICorProfiler
API:er ReJit-funktioner för dynamisk instrumentering kan nu ändra vissa metadata. Tidigare kunde sådana verktyg instrumentera IL när som helst, men metadata kunde bara ändras vid modulens inläsningstid. Eftersom IL refererar till metadata begränsade detta de typer av instrumentation som kunde göras. Vi har lyft vissa av dessa gränser genom att lägga till metoden ICorProfilerInfo7::ApplyMetaData för att stödja en delmängd metadataredigeringar efter att modulen har lästs in, särskilt genom att lägga till nyaAssemblyRef
,TypeRef
,TypeSpec
,MemberRef
,MemberSpec
ochUserString
poster. Den här ändringen gör ett mycket bredare utbud av instrumentation i farten möjlig.
NGEN-PDB-filer (Native Image Generator)
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 bilder 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-PDB-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 att kopiera det ursprungliga bild-PDB som genereras av dator A till dator B och använda felsökningsgränssnittsåtkomst-API:er för att läsa IL PDB:ns käll-to-IL-mappning och det ursprungliga bild-PDB:ns IL-till-native-mappning. Genom att kombinera båda mappningarna får du en käll-till-intern mappning. Eftersom den inbyggda bildens PDB är mycket mindre än alla moduler och inbyggda bilder, ä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 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ärt så att du bara kan inkludera de funktioner som behövs i ditt program. Den kan finnas på IIS eller lokalt i en anpassad process och du kan köra appar med olika versioner av .NET Framework på samma server. Den 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å det 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
aktivitetsbaserat API för Asynkron svarsspolning
ASP.NET tillhandahåller nu ett enkelt uppgiftsbaserat API för asynkron svarsspolning, HttpResponse.FlushAsync, som gör att svar kan rensas asynkront med hjälp av språkets
async/await
stöd.Modellbindning stöder uppgiftsreturmetoder
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 webbformulärsidor och användarkontroller. Modellbindningssystemet stöder nu Task-returnerande modellbindningsmetoder. Med den här funktionen kan webbformulärsutvecklare få skalbarhetsfördelarna med asynkronisering med det enkla databindningssystemet när du 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ålet för .NET Framework 4.6 är standardinställningen
true
. För appar som körs på .NET Framework 4.6 som riktar sig mot en tidigare version av .NET Framework är detfalse
som standard. Det kan aktiveras genom att ställa in konfigurationsinställningen påtrue
.HTTP/2-stöd (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 lägre svarstidswebbsideinläsning för användare. Webbsidor (i stället för 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 nätverksfunktioner finns i flera lager krävdes nya funktioner i Windows, 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 UWP-appar (Windows 10 Universal Windows Platform) som använder System.Net.Http.HttpClient-API:et.
För att kunna 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 klassen HttpResponse.
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 i 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 dra nytta av HTTP/2-stöd om servern stöder det.
stöd för tokenbindningsprotokollet
Microsoft och Google har samarbetat om en ny metod för autentisering, som kallas Token Binding Protocol. Premissen är att autentiseringstoken (i webbläsarens cacheminne) kan stjälas och användas av brottslingar för att komma åt 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. Klienten och serverimplementeringarna upprättar det slutpunkt till slutpunkt-skydd som anges i protokollet.
algoritmer för randomiserad stränghash
.NET Framework 4.5 introducerade en randomiserad stränghashalgoritm. Det stöddes dock inte av ASP.NET på grund av vissa ASP.NET funktioner var beroende av en stabil hash-kod. I .NET Framework 4.6 stöds nu slumpmässiga algoritmer för stränghash. 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 med 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. Appen körs i en 64-bitarsprocess om den kompileras som 64-bitars eller AnyCPU och körs på ett 64-bitars operativsystem. Även om 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 namnrymd, vilket kan ge bra prestandaförbättringar.
Förbättringar av samlingsladdaren
Sammansättningsinläsaren använder nu minnet mer effektivt genom att ta bort IL-sammansättningar när en motsvarande NGEN-avbildning har lästs in. Den här ändringen minskar det virtuella minnet, vilket är särskilt fördelaktigt för stora 32-bitarsappar (till exempel Visual Studio) och sparar även fysiskt minne.
Base-klassbiblioteket ändras
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:
IReadOnlyCollection<T> implementeringar
Ytterligare samlingar implementerar IReadOnlyCollection<T> som Queue<T> och Stack<T>.
CultureInfo.CurrentCulture och CultureInfo.CurrentUICulture
Egenskaperna CultureInfo.CurrentCulture och CultureInfo.CurrentUICulture är nu läs- och skrivbara 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 egenskapen
Thread.CurrentThread.CurrentCulture
och den aktuella UI-trådkulturen som definieras avThread.CurrentThread.CurrentUICulture
egenskaper.Förbättringar av skräpinsamling (GC)
Klassen GC innehåller nu TryStartNoGCRegion och EndNoGCRegion metoder som gör att du inte tillåter skräpinsamling under körningen av en kritisk sökväg.
En ny överlagring av metoden GC.Collect(Int32, GCCollectionMode, Boolean, Boolean) låter dig styra om både den lilla objekthögen och den stora objekthögen ska svepas och komprimeras eller endast svepas.
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 API:er för Windows CNG-kryptografi. Tidigare versioner av .NET Framework har helt förlitat sig på en tidigare version av Windows Cryptography API:er som grund för System.Security.Cryptography implementeringen. Vi har fått förfrågningar om att stödja CNG-API:et eftersom det stöder moderna kryptografialgoritmer, som är viktiga för vissa kategorier av appar.
.NET Framework 4.6 innehåller följande nya förbättringar som stöder API:er för Windows CNG-kryptografi:
En uppsättning tilläggsmetoder för X509-certifikat,
System.Security.Cryptography.X509Certificates.RSACertificateExtensions.GetRSAPublicKey(System.Security.Cryptography.X509Certificates.X509Certificate2)
ochSystem.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 gjutning. 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 typkonverteringen.
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 den 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. Det upprättar ett löst kopplat kontrakt mellan komponenter för att kommunicera en begäran om avbeställning. Den här funktionen är vanligtvis viktig när en ändring görs i befintliga funktioner. Omvänt finns det redan en implicit opt-in för nya funktioner.
Med AppContextdefinierar och exponerar bibliotek kompatibilitetsväxlar, medan kod som är beroende av dem kan ange att dessa växlar påverkar bibliotekets beteende. Som standardinställning tillhandahåller biblioteken de nya funktionerna, och de ändrar den bara (det vill säga, de tillhandahåller den tidigare funktionen) om en inställning är aktiverad.
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. Genom att uttryckligen ställa in växeln påfalse
möjliggö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 switchen och sedan vidta lämpliga åtgärder.
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 fördelaktigt att använda ett konsekvent format för omkopplare, eftersom de är ett formellt kontrakt som tillhandahålls av ett bibliotek. Följande är två uppenbara format.
Switch.namnområde.switchnamn
Växla.bibliotek.switchname
Ändringar i det aktivitetsbaserade asynkrona mönstret (TAP)
För appar som riktar sig mot .NET Framework 4.6 ärver Task- och Task<TResult>-objekt 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 aktivitetsbaserade asynkrona åtgärder" i CultureInfo-klassavsnittet.
Med klassen System.Threading.AsyncLocal<T> 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 notifieras när omgivningsdata ändras, antingen på grund av att egenskapen AsyncLocal<T>.Value uttryckligen har ändrats eller på grund av att tråden stötte på en kontextövergång.Tre bekvämlighetsmetoder, Task.CompletedTask, Task.FromCanceledoch Task.FromException, har lagts till i det aktivitetsbaserade asynkrona mönstret (TAP) för att returnera slutförda uppgifter i ett visst tillstånd.
Klassen NamedPipeClientStream stöder nu asynkron kommunikation med den nya ConnectAsync. metod.
EventSource stöder nu skrivning till händelseloggen
Nu kan du använda klassen EventSource för att logga administrativa eller operativa meddelanden till händelseloggen, utöver alla 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 specialt attribuerade klasser och matriser samt primitiva typer skickas som en nyttolast
Aktivitetsspårning
Orsakar att start- och stopphändelser taggar händelser mellan dem med ett ID som representerar alla för närvarande aktiva aktiviteter.
För att stödja dessa funktioner har den överlagrade Write-metoden lagts till i klassen EventSource.
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 rundning av layouten för att minska förekomsten av klippning 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 in sig på 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 avsnittet <körning> i app.config-filen:
<AppContextSwitchOverrides value="Switch.MS.Internal.DoNotApplyLayoutRoundingToMarginsAndBorderThickness=false" />
WPF-fönster som sträcker sig över flera skärmar med olika DPI-inställningar (Multi-DPI-konfiguration) renderas nu helt utan svarta områden. Du kan avregistrera dig från det här beteendet genom att lägga till följande rad i avsnittet
<appSettings>
i filen app.config 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
Rapporter från kunder om oförutsägbart beteende vid beröring på Connect 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.
Transparent barnfönsterstöd
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 egenskapen HwndSourceParameters.UsesPerPixelTransparency till
true
.
Windows Communication Foundation (WCF)
SSL-stöd
WCF stöder nu SSL-version TLS 1.1 och TLS 1.2, utöver SSL 3.0 och TLS 1.0, när du använder NetTcp med transportsäkerhet och klientautentisering. Nu är det möjligt att välja vilket protokoll som ska användas eller att inaktivera gamla mindre säkra protokoll. Detta kan göras antingen genom att ange egenskapen SslProtocols 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 anslutningsgruppsnamn-prefix
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 egenskap Message.Properties. Nyckeln är "HttpTransportConnectionGroupNamePrefix"; värdet är det önskade prefixet.
Använda olika kanalfabrikskoncept
Användare kan också aktivera en funktion som säkerställer att meddelanden som skickas med kanaler som skapats av olika kanalfabriker använder olika underliggande HTTP-anslutningar. Om du vill aktivera den här funktionen måste användarna ange följande
appSetting
tilltrue
:<appSettings> <add key="wcf:httpTransportBinding:useUniqueConnectionPoolPerFactory" value="true" /> </appSettings>
Windows Workflow Foundation (WWF)
Nu kan du ange hur många sekunder en arbetsflödestjänst ska behålla en begäran om åtgärd utanför ordning när det finns ett utestående bokmärke av typen "icke-protokoll" innan begäran går till timeout. Ett "icke-protokoll" bokmärke är ett bokmärke som inte hör ihop med utestående mottagningsaktiviteter. Vissa aktiviteter skapar bokmärken som inte är protokoll i implementeringen, så det kanske inte är uppenbart att det finns ett bokmärke som inte är protokoll. Dessa inkluderar Läge och Val. Så om du har en arbetsflödestjänst implementerad med en tillståndsdator eller innehåller en Pick-aktivitet har du förmodligen bokmärken som inte är protokoll. Du anger intervallet genom att lägga till en rad som följande i avsnittet
appSettings
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 icke-protokollbokmärken.
Om värdet för
FilterResumeTimeoutInSeconds
-elementet inte är noll, det finns bokmärken som inte är protokollbokmärken och tidsgränsintervallet upphör att gälla misslyckas åtgärden med ett timeout-meddelande.Transaktioner
Nu kan du inkludera den distribuerade transaktionsidentifieraren för den transaktion som har lett till att ett undantag som härletts från TransactionException kastas. Det gör du genom att lägga till följande nyckel i avsnittet
appSettings
i din app.config-fil:<add key="Transactions:IncludeDistributedTransactionIdInExceptionMessage" value="true"/>
Standardvärdet är
false
.Nätverk
Återanvändning av socketar
Windows 10 innehåller en ny nätverksalgoritm med hög skalbarhet som bättre använder 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 att .NET-appar kan dra nytta av det nya beteendet. I tidigare versioner av Windows fanns det en artificiell gräns för samtidig anslutning (vanligtvis 16 384, standardstorleken för det dynamiska portintervallet), vilket skulle kunna begränsa skalbarheten för en tjänst genom att orsaka portöverbelastning vid belastning.
I .NET Framework 4.6 har två API:er lagts till för att aktivera återanvändning av portar, vilket effektivt tar bort gränsen på 64 KB för samtidiga anslutningar:
Uppräkningsvärdet för System.Net.Sockets.SocketOptionName.
Egenskapen ServicePointManager.ReusePort.
Som standard är egenskapen ServicePointManager.ReusePort
false
såvida inteHWRPortReuseOnSocketBind
värdet förHKLM\SOFTWARE\Microsoft\.NETFramework\v4.0.30319
-registernyckeln är inställt på 0x1. Om du vill aktivera återanvändning av lokal port på HTTP-anslutningar anger du egenskapen ServicePointManager.ReusePort tilltrue
. 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 lokal port.Utvecklare som skriver ett socketprogram kan ange alternativet System.Net.Sockets.SocketOptionName när de anropar en metod som Socket.SetSocketOption 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 klassen Uri för att bättre stödja internationella domännamn och PunyCode.
Storleksändring i Windows Forms-kontroller.
Den här funktionen har expanderats i .NET Framework 4.6 för att inkludera typerna DomainUpDown, NumericUpDown, DataGridViewComboBoxColumn, DataGridViewColumn och ToolStripSplitButton och den rektangel som anges av egenskapen Bounds som används när du ritar en UITypeEditor.
Det här är en opt-in-funktion. Om du vill aktivera det anger du
EnableWindowsFormsHighDpiAutoResizing
-elementet tilltrue
i programkonfigurationsfilen (app.config) :<appSettings> <add key="EnableWindowsFormsHighDpiAutoResizing" value="true" /> </appSettings>
Stöd för teckenuppsättningar
.NET Core har främst stöd för Unicode-kodningar och ger som standard begränsat stöd för kodsidkodningar. Du kan lägga till stöd för kodeksidor som är tillgängliga i .NET Framework men inte stöds i .NET Core genom att registrera kodeksidor med metoden Encoding.RegisterProvider. Mer information finns i System.Text.CodePagesEncodingProvider.
.NET Native
UWP-appar (Universal Windows Platform) som är skrivna i C# eller Visual Basic kan dra nytta av en ny teknik som kompilerar appar till inbyggd 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 and Compilation.
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 av interna .NET-appar har ett antal nya gränssnitt och uppräkningar lagts till i det ohanterade felsöknings-API:et. För mer information, se avsnittet Felsökning (ohanterad API-referens).
.NET Framework-paket med öppen källkod
.NET Core-paket som oföränderliga samlingar, SIMD-API:eroch nätverks-API:er som de som finns i System.Net.Http namnområdet är nu tillgängliga som paket med öppen källkod på GitHub. Information om hur du kommer åt koden finns i .NET på GitHub. Mer information och hur du bidrar till dessa paket finns i Introduktion till .NET, .NET-startsida på GitHub.
Nyheter i .NET Framework 4.5.2
Nya API:er för ASP.NET appar. Med de nya metoderna HttpResponse.AddOnSendingHeaders och HttpResponseBase.AddOnSendingHeaders kan du inspektera och ändra svarshuvuden och statuskoder när svaret skickas till klientappen. Överväg att använda dessa metoder i stället för händelserna PreSendRequestHeaders och PreSendRequestContent. de är mer effektiva och tillförlitliga.
Med metoden HostingEnvironment.QueueBackgroundWorkItem 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 egenskaperna HttpResponse.HeadersWritten och HttpResponseBase.HeadersWritten returnerar booleska värden som anger om svarsrubrikerna 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 på 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
EnableWindowsFormsHighDpiAutoResizing
-elementet tilltrue
i programkonfigurationsfilen (app.config) :<appSettings> <add key="EnableWindowsFormsHighDpiAutoResizing" value="true" /> </appSettings>
Ny arbetsflödesfunktion. En resurshanterare som använder metoden EnlistPromotableSinglePhase (och därför implementerar IPromotableSinglePhaseNotification-gränssnittet) kan använda den nya metoden Transaction.PromoteAndEnlistDurable för att begära följande:
Flytta upp transaktionen till en MSDTC-transaktion (Microsoft Distributed Transaction Coordinator).
Ersätt IPromotableSinglePhaseNotification med ett ISinglePhaseNotification, vilket är en varaktig inskrivning som stöder enfasbekräftelser.
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 den IPromotableSinglePhaseNotification
Promote
metod som implementeras av promotable-listan.Profileringsförbättringar. Följande nya ohanterade profilerings-API:er ger mer robust profilering:
- COR_PRF_ASSEMBLY_REFERENCE_INFO Struktur
- COR_PRF_HIGH_MONITOR uppräkning
- GetAssemblyReferences-metoden
- GetEventMask2 Method
- SetEventMask2-metod
- AddAssemblyReference-metod
Tidigare
ICorProfiler
-implementationer stödde fördröjd inläsning av beroende komponenter. 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 befintligaICorProfiler
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 skapas av reJIT-begäranden för kompilatorn vid dumpfelsökning.
Ändringar i händelsespårning. .NET Framework 4.5.2 möjliggör utanför-processen-baserad händelsespårning för Windows (ETW)-baserad aktivitetsspårning över ett större område. 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 inaktiverad.
Att förmedla en transaktion och konvertera den till en varaktig rekrytering
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å metoden ITransactionPromoter.Promote. Den ber
System.Transactions
att befordra transaktionen till en MSDTC-transaktion och konvertera den promoterbara inblandningen till en beständig inblandning. När den här metoden har slutförts kommer IPromotableSinglePhaseNotification-gränssnittet inte längre att refereras avSystem.Transactions
, och eventuella framtida meddelanden kommer att skickas till det angivna ISinglePhaseNotification-gränssnittet. Den aktuella listan måste fungera som en varaktig registrering som stöder transaktionsloggning och återställning. Mer information finns i Transaction.EnlistDurable. Dessutom måste listan ha stöd för ISinglePhaseNotification. Den här metoden kan bara anropas vid bearbetning av ett ITransactionPromoter.Promote-anrop. Om så inte är fallet, utlöses ett TransactionException-undantag.
Nyheter i .NET Framework 4.5.1
april 2014 uppdateras:
Visual Studio 2013 Update 2 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 bärbara bibliotek som är avsedda för Windows 8.1, Windows Phone 8.1 och Windows Phone Silverlight 8.1.
Du kan inkludera XAML (Windows.UI.XAML-typer) i bärbara bibliotek när du riktar in dig på 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 ändra målet för ett klassbibliotek för Windows Store eller Windows Phone Store likt ett bärbart klassbibliotek.
Mer information om dessa ändringar finns i Portable Class Library.
.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 till 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ällkoden 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 är:
Automatisk bindningsomdirigering för sammansättningar. Från och med Visual Studio 2013, när du kompilerar en app som riktar sig mot .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 riktar sig till äldre versioner av .NET Framework. Mer information finns i Så här: Aktivera och inaktivera automatisk omdirigering av bindning.
Möjlighet att samla in diagnostikinformation som hjälper utvecklare att förbättra prestanda för server- och molnprogram. Mer information finns i metoderna WriteEventWithRelatedActivityId och WriteEventWithRelatedActivityIdCore i klassen EventSource.
Möjlighet att explicit komprimera den stora objekthögen (LOH) under skräpinsamling. För mer information, se 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 .NET Framework 4.5.1-meddelandet och ASP.NET-appens paus blogginlägg.
Förbättringar av Windows-formulär är:
Storleksändring 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:
- PropertyGrid
- TreeView
- Vissa aspekter av DataGridView (se nya funktioner i 4.5.2 för ytterligare kontroller som stöds)
Om du vill aktivera den här funktionen lägger du till ett nytt <appInställningar>-element i konfigurationsfilen (app.config) och anger
EnableWindowsFormsHighDpiAutoResizing
-elementet tilltrue
:<appSettings> <add key="EnableWindowsFormsHighDpiAutoResizing" value="true" /> </appSettings>
Förbättringar vid felsökning av .NET Framework-appar i Visual Studio 2013 är:
Returnera värden i Visual Studio-felsökningsprogrammet. När du felsöker en hanterad app i Visual Studio 2013 visar Autos-fönstret returtyper och värden för metoder. Den här informationen är tillgänglig för skrivbords-, 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 fortfarande för både 32-bitars- och 64-bitarsappar (se det sista avsnittet i artikeln kodändringar som stöds (C#)).
Asynkronmedveten 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 i 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 ä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-medveten felsökning" i .NET Framework 4.5.1-meddelande.
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 "Utveckling av Windows Store-appar" i .NET Framework 4.5.1-meddelande.
Från och med Visual Studio 2013 kan du använda det guidade optimeringsverktyget för hanterad profil (Mpgo.exe) för att optimera Windows 8.x Store-appar samt skrivbordsappar.
För nya funktioner i ASP.NET 4.5.1, se ASP.NET och webbverktyg för Visual Studio 2013 versionsanteckningar.
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 installation av .NET Framework 4.5.
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 <gcAllowVeryLargeObjects> elementet, 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 serverskräpinsamling i .NET Framework 4.5 aktiveras automatiskt skräpinsamling i bakgrunden. Se avsnittet Skräpinsamling för bakgrundsserver i avsnittet grunderna i skräpinsamling.
Bakgrunds-JIT-kompilering (just-in-time), som eventuellt är tillgänglig på processorer med flera kärnor för att förbättra applikationens 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. Se klassen CultureInfo.
Konsolstöd för Unicode-kodning (UTF-16). Se klassen Console.
Stöd för versionshantering av kultursträngsordning och jämförelsedata. Se klassen SortVersion.
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. Se namnområdet System.IO.Compression.
Möjlighet att anpassa en reflektionskontext för att åsidosätta standardbeteendet för reflektion via klassen CustomReflectionContext.
Stöd för 2008-versionen av IDNA-standarden (Internationalized Domain Names in Applications) när klassen System.Globalization.IdnMapping används i Windows 8.
Delegering av strängjämförelse med operativsystemet, som implementerar Unicode 6.0, när .NET Framework används i Windows 8. När det körs på andra plattformar innehåller .NET Framework sina egna strängjämförelsedata, som implementerar Unicode 5.x. Se klassen String och avsnittet Anmärkningar i klassen SortVersion.
Möjlighet att beräkna hash-koderna för strängar per programdomän. Se elementet <UseRandomizedStringHashAlgorithm>.
Typreflektionsstöd fördelas mellan Type och TypeInfo klasser. Se reflektion i .NET Framework för Windows Store-appar.
Managed Extensibility Framework (MEF)
I .NET Framework 4.5 tillhandahåller Managed Extensibility Framework (MEF) följande nya funktioner:
Stöd för generiska typer.
Konventionsbaserad programmeringsmodell som gör att du kan skapa delar baserat på namngivningskonventioner i stället för 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 från menyn Project 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 språken C# och Visual Basic. 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 asynkrona metoder i I/O-klasserna. Se asynkron fil-I/O.
Arbetsredskap
I .NET Framework 4.5 kan du skapa en .resw-fil för användning i Windows 8.x Store-appar från en .resourcesResgen.exe-fil som är inbäddad i en .NET Framework-sammansättning. Mer information finns i Resgen.exe (Resursfilgenerator).
Med guidad optimering av 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 samt skrivbordsappar.
Parallellberäkning
.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 du till modellbindning för webbformulär, 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 den nya System.Net.WebSockets namnrymden och klassen HttpListener.
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 parsning av internationaliserat domännamn (IDN). Mer information finns i Uri och relaterade klasser.
Stöd för EAI (Email Address Internationalization). Mer information finns i namnområdet System.Net.Mail.
Förbättrat IPv6-stöd. Mer information finns i namnområdet System.Net.NetworkInformation.
Stöd för dubbellägesuttag. 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, som gör att du kan implementera ett menyfliksgränssnitt som innehåller 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 vid visning av stora uppsättningar grupperade data och genom att komma åt samlingar på trådar som inte är användargränssnitt.
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 förflutit mellan egenskapsändringar och uppdateringar av datakällor.
Förbättrat stöd för implementering av svaga händelsemönster. Händelser kan nu också acceptera markup-tillä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 kontraktsbaserad 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 klassen XmlDictionaryReaderQuotas för att minska sannolikheten för att du måste konfigurera kvoter för XML-ordlisteläsare manuellt.
Validering av WCF-konfigurationsfiler av 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 till
?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 cachelagringsstöd.
Stöd för binärkodningskompression.
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).
För mer information, se 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 Platform Update 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.
Stöd för designer vid skapande av övergångar 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 dokumentdisposition vy som visar komponenterna i ett arbetsflöde i en dispositionsvy i trädformat och låter dig välja en komponent i vyn dokumentdisposition.
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.
Lagring av visningstillståndsinformation 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 aktivitet i NoPersistScope-containern 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 instans av ett beständiga arbetsflöde 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 instans av ett beständiga arbetsflöde.
Utveckling av den första arbetsflödestjänsten för kontrakt, vilket 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-operativsystemet. 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.
Portabla klassbibliotek
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. Tillgängliga typer och medlemmar i projektet begränsas automatiskt till vanliga typer och medlemmar på dessa plattformar. Mer information finns i Portable Class Library.