Číst v angličtině

Sdílet prostřednictvím


Novinky v rozhraní .NET Framework

Poznámka

Rozhraní .NET Framework se obsluhuje nezávisle na aktualizacích Windows s opravami chyb zabezpečení a spolehlivosti. Obecně platí, že aktualizace zabezpečení se vydávají čtvrtletně. Rozhraní .NET Framework bude i nadále součástí Windows bez plánů ho odebrat. Aplikace .NET Framework nemusíte migrovat, ale pro nový vývoj použijte .NET 8 nebo novější.

Tento článek shrnuje klíčové nové funkce a vylepšení v následujících verzích rozhraní .NET Framework:

Tento článek neposkytuje komplexní informace o každé nové funkci a může se změnit. Obecné informace o rozhraní .NET Framework naleznete v tématu Začínáme. Podporované platformy najdete v tématu Požadavky na systém. Odkazy ke stažení a pokyny k instalaci naleznete v Průvodce instalací.

Poznámka

Tým rozhraní .NET Framework také vydává funkce mimo pásmo pomocí NuGetu, aby rozšířil podporu platformy a zavedl nové funkce, jako jsou neměnné kolekce a typy vektorů s podporou SIMD. Další informace najdete v sekci Další knihovny tříd a rozhraní API a .NET Framework a verze mimo hlavní vydání. Podívejte se na kompletní seznam balíčků NuGet pro rozhraní .NET Framework.

Představujeme rozhraní .NET Framework 4.8.1

.NET Framework 4.8.1 staví na předchozích verzích rozhraní .NET Framework 4.x přidáním mnoha nových oprav a několika nových funkcí a zároveň zůstává velmi stabilním produktem.

Stažení a instalace rozhraní .NET Framework 4.8.1

Rozhraní .NET Framework 4.8.1 si můžete stáhnout z následujících umístění:

.NET Framework 4.8 je možné nainstalovat na Windows 11, Windows 10 verze 21H2, Windows 10 verze 21H1, Windows 10 verze 20H2 a odpovídající serverové platformy počínaje Windows Serverem 2022. .NET Framework 4.8.1 můžete nainstalovat pomocí webového instalačního programu nebo offline instalačního programu. Doporučeným způsobem pro většinu uživatelů je použití webového instalačního programu.

Ve Visual Studio 2022 17.3 nebo novějším můžete vytvářet aplikace pro .NET Framework 4.8.1 tím, že nainstalujete .NET Framework 4.8.1 Developer Pack.

Novinky v rozhraní .NET Framework 4.8.1

Rozhraní .NET Framework 4.8.1 zavádí nové funkce v následujících oblastech:

Vylepšená přístupnost, která umožňuje aplikaci poskytovat vhodné prostředí pro uživatele technologie usnadnění, je hlavním cílem rozhraní .NET Framework 4.8.1. Informace o vylepšeních přístupnosti v rozhraní .NET Framework 4.8.1 najdete v tématu Novinky v přístupnosti v rozhraní .NET Framework.

.NET Framework 4.8.1 přidává nativní podporu Arm64 do řady .NET Framework. Vaše investice do rozsáhlého ekosystému aplikací a knihoven rozhraní .NET Framework teď můžou využívat výhody spouštění úloh nativně v Arm64 – konkrétně lepší výkon v porovnání se spouštěním kódu x64 emulovaného v Arm64.

Microsoft se zavazuje poskytovat produkty a platformy, které jsou přístupné všem. .NET Framework 4.8.1 nabízí dvě platformy pro vývoj uživatelského rozhraní Windows, z nichž obě poskytují vývojářům podporu potřebnou k vytváření přístupných aplikací. V posledních několika verzích přidaly Windows Forms i WPF nové funkce a opravily řadu problémů se spolehlivostí souvisejících s přístupností. Další informace o tom, co bylo opraveno nebo přidáno v jednotlivých verzích, najdete v tématu Co je nového v přístupnosti v rozhraní .NET Framework.

V této verzi byly Windows Forms i WPF vylepšeny, aby zpracování nápověd bylo přístupnější uživatelům. V obou případech popisy nyní odpovídají pokynům stanoveným v obsahu WCAG2.1 na přejetí myší nebo zaměření. Požadavky na popisy jsou:

  • Popisy musí být zobrazeny buď najetím myší, nebo navedením pomocí klávesnice na ovládací prvek.
  • Popisy by měly být odstranitelné. To znamená, že jednoduchý příkaz klávesnice jako Esc by měl popis zavřít.
  • Popisy by měly být umožňující najetí myší. Uživatelé by měli mít možnost umístit kurzor myši na popisek. To umožňuje využití takových funkcí, jako je lupa, aby si slabozrací uživatelé mohli přečíst vyskakovací okno s informacemi.
  • Nápovědní popisky by měly být trvalé. Popisy by neměly zmizet automaticky po uplynutí určité doby. Místo toho by měl uživatel zavřít popisky přesunutím myši na jiný ovládací prvek nebo příkazem klávesnice.

Ve Windows Forms je tato podpora dostupná jenom v operačních systémech Windows 11 nebo novějších. Windows Forms je tenká spravovaná obálka kolem rozhraní Windows API a nové chování bublinové nápovědy bylo dostupné pouze ve Windows 11. WPF nemá žádné závislosti verzí operačního systému pro jeho přístupné popisy.

WPF implementovalo většinu požadavků na popisky vyhovující WCAG2.1 v rozhraní .NET Framework 4.8. V této verzi WPF vylepšilo prostředí tím, že zajistilo, že popisek v aktuálním okně lze snadno zavřít pomocí klávesy Esc, klávesy Ctrl (jednoduché stisknutí) nebo kombinace Ctrl+Shift+F10. Rozsah klávesy Escape byl v této verzi omezen tak, aby fungoval pouze pro aktuální okno. Dříve to platilo pro jakoukoli otevřenou bublinu nápovědy v aplikaci.

Windows Forms byl první zásobník uživatelského rozhraní Systému Windows vytvořený pro rozhraní .NET Framework. Proto byla původně vytvořena tak, aby využívala starší technologie přístupnosti, která nesplňuje aktuální požadavky na přístupnost. V této verzi windows Forms řeší řadu problémů. Úplný seznam změn souvisejících s přístupností najdete v tématu Novinky v přístupnosti v rozhraní .NET Framework.

Nejdůležitější vylepšení modelu Windows Forms v rozhraní .NET Framework 4.8.1 jsou:

  • podpora vzorů textu– Windows Forms přidala podporu pro vzor textu UIA. Tento vzor umožňuje asistivní technologii procházet obsah textového pole nebo podobného textově orientovaného ovládacího prvku po písmenech. Umožňuje výběr textu v ovládacím prvku a jeho změně a vložení nového textu na kurzor. Windows Forms přidal tuto podporu pro TextBox, DataGridView buňky, ComboBox ovládací prvky a další.

  • Řešení problémů s kontrastem – V několika ovládacích prvcích windows Forms změnil poměr kontrastu obdélníků výběru tak, aby byl tmavší a viditelný.

  • Opravili jsme několik problémů s DataGridView:

    • Názvy posuvníků byly aktualizovány tak, aby byly konzistentní.
    • Program Předčítání se teď může soustředit na prázdné buňky DataGridView.
    • Vývojáři můžou nastavit lokalizovanou vlastnost typu ovládacího prvku pro vlastní buňky DataGridView.
    • Barva odkazu pro buňky DataGridViewLink byla aktualizována tak, aby lépe kontrastovala s pozadím.

Představujeme rozhraní .NET Framework 4.8

.NET Framework 4.8 staví na předchozích verzích rozhraní .NET Framework 4.x přidáním mnoha nových oprav a několika nových funkcí, zatímco zůstává velmi stabilním produktem.

Stažení a instalace rozhraní .NET Framework 4.8

Rozhraní .NET Framework 4.8 si můžete stáhnout z následujících umístění:

.NET Framework 4.8 lze nainstalovat na Windows 10, Windows 8.1, Windows 7 SP1 a odpovídající serverové platformy počínaje Windows Serverem 2008 R2 SP1. .NET Framework 4.8 můžete nainstalovat pomocí webového instalačního programu nebo offline instalačního programu. Doporučeným způsobem pro většinu uživatelů je použití webového instalačního programu.

V sadě Visual Studio 2012 nebo novější můžete cílit na .NET Framework 4.8 tak, že nainstalujete sadu .NET Framework 4.8 Developer Pack.

Novinky v rozhraní .NET Framework 4.8

.NET Framework 4.8 zavádí nové funkce v následujících oblastech:

  • základní třídy
  • Windows Communication Foundation (WCF)
  • Windows Presentation Foundation (WPF)
  • modulu Common Language Runtime

Vylepšená přístupnost, která umožňuje aplikaci poskytovat vhodné prostředí pro uživatele technologie usnadnění, je i nadále hlavním cílem rozhraní .NET Framework 4.8. Informace o vylepšení přístupnosti v rozhraní .NET Framework 4.8 najdete v tématu Novinky v přístupnosti v rozhraní .NET Framework.

Základní třídy

Přímé snížení dopadu FIPS na kryptografii. V předchozích verzích rozhraní .NET Framework vyvolají spravované třídy kryptografických poskytovatelů, jako je SHA256Managed, výjimku CryptographicException, když jsou systémové kryptografické knihovny nastaveny v režimu FIPS. Tyto výjimky jsou vyvolány, protože spravované verze tříd kryptografických poskytovatelů, na rozdíl od systémových kryptografických knihoven, neprošly certifikací FIPS (Federal Information Processing Standards) 140-2. Vzhledem k tomu, že málo vývojářů má své vývojové počítače v režimu FIPS, výjimky jsou běžně vyvolávány v produkčních systémech.

Ve výchozím nastavení v aplikacích, které cílí na rozhraní .NET Framework 4.8, již následující spravované kryptografické třídy již nevyvolají CryptographicException v tomto případě:

Místo toho tyto třídy přesměrují kryptografické operace do systémové kryptografické knihovny. Tato změna efektivně odstraňuje potenciálně matoucí rozdíl mezi vývojovými prostředími a produkčními prostředími a zajišťuje, aby nativní komponenty a spravované komponenty fungovaly ve stejných kryptografických zásadách. Aplikace závislé na těchto výjimkách mohou obnovit předchozí chování nastavením přepínače AppContext Switch.System.Security.Cryptography.UseLegacyFipsThrow na true. Další informace naleznete v tématu Spravované kryptografické třídy nevyvolají výjimku CryptographyException v režimu FIPS.

Použití aktualizované verze ZLib

Počínaje rozhraním .NET Framework 4.5 sestavení clrcompression.dll používá ZLib, nativní externí knihovnu pro kompresi dat, aby poskytlo implementaci algoritmu deflate. Verze rozhraní .NET Framework 4.8 clrcompression.dll se aktualizuje tak, aby používala ZLib verze 1.2.11, která obsahuje několik klíčových vylepšení a oprav.

Windows Communication Foundation (WCF)

zavedení ServiceHealthBehavior

Zdravotní ukazatele jsou široce používány nástroji orchestrace ke správě služeb na základě jejich zdravotního stavu. Kontroly stavu mohou být také používány monitorovacími nástroji ke sledování a poskytování oznámení o dostupnosti a výkonu služby.

ServiceHealthBehavior je chování služby WCF, které rozšiřuje IServiceBehavior. Po přidání do kolekce ServiceDescription.Behaviors chování služby provede následující:

  • Vrátí stav zdraví služby pomocí kódů odpovědí HTTP. V řetězci dotazu můžete zadat stavový kód HTTP pro požadavek sondy stavu HTTP/GET.

  • Publikuje informace o stavu služby. Podrobnosti specifické pro službu, včetně stavu služby, počtu omezení a kapacity, se dají zobrazit pomocí požadavku HTTP/GET s řetězcem dotazu ?health. Usnadnění přístupu k těmto informacím je důležité při řešení potíží s chybnou úpravou služby WCF.

Existují dva způsoby, jak zveřejnit koncový bod stavu a publikovat informace o stavu služby WCF:

  • Prostřednictvím kódu. Například:

    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);
    
  • Pomocí konfiguračního souboru. Například:

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

Stav služby je možné dotazovat pomocí parametrů dotazu, jako jsou OnServiceFailure, OnDispatcherFailure, OnListenerFailure, OnThrottlePercentExceeded) a kód odpovědi HTTP lze zadat pro každý parametr dotazu. Pokud je pro parametr dotazu vynechán kód odpovědi HTTP, použije se ve výchozím nastavení kód odpovědi HTTP 503. Například:

Parametry dotazu a příklady:

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

    Stavový kód odpovědi HTTP 455 je vrácen, pokud je stav některého z dispečerů kanálu větší než CommunicationState.Opened.

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

    Stavový kód odpovědi HTTP 465 je vrácen, pokud je stav kteréhokoli posluchače kanálu větší než CommunicationState.Opened.

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

    Určuje procento {1 – 100}, které aktivuje odpověď a kód odpovědi HTTP {200 – 599}. V tomto příkladu:

    • Pokud je procento větší než 95, vrátí se kód odpovědi HTTP 500.

    • Pokud je procento v rozmezí od 70 do 95, vrátí se hodnota 350.

    • V opačném případě se vrátí hodnota 200.

Stav služby lze zobrazit buď v HTML zadáním řetězce dotazu, jako je https://contoso:81/Service1?health nebo XML zadáním řetězce dotazu, jako je https://contoso:81/Service1?health&Xml. Řetězec dotazu, jako je https://contoso:81/Service1?health&NoContent, vrátí prázdnou stránku HTML.

Windows Presentation Foundation (WPF)

Vylepšení vysokého DPI

V rozhraní .NET Framework 4.8 přidává WPF podporu pro Per-Monitor V2 DPI Awareness a Mixed-Mode škálování DPI. Další informace o vývoji s vysokým rozlišením DPI najdete v tématu Vývoj desktopových aplikací s vysokým rozlišením DPI ve Windows.

Rozhraní .NET Framework 4.8 vylepšuje podporu hostovaných HWNds a interoperaci Windows Forms v aplikacích High-DPI WPF na platformách, které podporují škálování Mixed-Mode DPI (počínaje aktualizací Windows 10 duben 2018 Update). Když se vytvoří hostované ovládací prvky HWND nebo Windows Forms jako Mixed-Mode okna se škálováním DPI pomocí volání SetThreadDpiHostingBehavior a SetThreadDpiAwarenessContext, mohou být hostovány v aplikaci Per-Monitor WPF v2 a odpovídajícím způsobem se přizpůsobí velikosti a škálování. Takový hostovaný obsah se nevykreslí v nativním DPI; operační systém místo toho škáluje hostovaný obsah na odpovídající velikost. Podpora režimu Per-Monitor v2 DPI také umožňuje hostovat ovládací prvky WPF (tj. nadřazené) v nativním okně v aplikaci s vysokým rozlišením DPI.

Pokud chcete povolit podporu Mixed-Mode škálování s vysokým rozlišením DPI, můžete nastavit následující AppContext přepne konfigurační soubor aplikace:

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

Modul CLR (Common Language Runtime)

Modul runtime v rozhraní .NET Framework 4.8 obsahuje následující změny a vylepšení:

vylepšení kompilátoru JIT. Kompilátor JIT (Just-in-Time) v rozhraní .NET Framework 4.8 je založený na kompilátoru JIT v .NET Core 2.1. Mnoho optimalizací a všech oprav chyb provedených v kompilátoru JIT .NET Core 2.1 jsou součástí kompilátoru JIT rozhraní .NET Framework 4.8 JIT.

vylepšení NGEN. Běhové prostředí zlepšilo správu paměti pro obrázky generované pomocí Native Image Generator (NGEN), aby data mapovaná z obrázků NGEN nebyla rezidentní v paměti. Tím se sníží dostupná plocha pro útoky, které se pokusí spustit libovolný kód úpravou paměti, která se spustí.

Antimalwarové skenování pro všechny moduly. V předchozích verzích rozhraní .NET Framework modul runtime prohledával všechna sestavení načtená z disku pomocí Windows Defenderu nebo antimalwarového softwaru od jiného výrobce. Sestavení načtená z jiných zdrojů, například metodou Assembly.Load(Byte[]), se však neskenují a mohou potenciálně obsahovat nedetekovaný malware. Počínaje rozhraním .NET Framework 4.8 spuštěným ve Windows 10 modul runtime aktivuje kontrolu antimalwarovými řešeními, která implementují rozhraní AMSI (Antimalware Scan Interface).

Novinky v rozhraní .NET Framework 4.7.2

.NET Framework 4.7.2 obsahuje nové funkce v následujících oblastech:

Důraz v rozhraní .NET Framework 4.7.2 je kladen na zlepšení přístupnosti, což umožňuje aplikaci poskytovat vhodné prostředí pro uživatele asistivní technologie. Informace o vylepšeních přístupnosti v rozhraní .NET Framework 4.7.2 najdete v tématu Novinky v usnadnění přístupu v rozhraní .NET Framework.

Základní třídy

Rozhraní .NET Framework 4.7.2 nabízí velké množství kryptografických vylepšení, lepší podporu dekomprese pro archivy ZIP a další rozhraní API kolekcí.

Nová přetížení metod RSA.Create a DSA.Create

Metody DSA.Create(DSAParameters) a RSA.Create(RSAParameters) umožňují zadat parametry klíče při vytváření instance nového DSA nebo klíče RSA. Umožňují nahradit kód podobný tomuto:

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

pomocí kódu jako je tento:

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

Metody DSA.Create(Int32) a RSA.Create(Int32) umožňují vygenerovat nové klíče DSA nebo RSA s konkrétní velikostí klíče. Například:

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

Konstruktory Rfc2898DeriveBytes přijímají název hashovacího algoritmu

Třída Rfc2898DeriveBytes má tři nové konstruktory s parametrem HashAlgorithmName, který identifikuje algoritmus HMAC, který se má použít při odvozování klíčů. Místo použití SHA-1 by vývojáři měli použít HMAC založený na SHA-2, jako je SHA-256, jak je znázorněno v následujícím příkladu:

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);
   }
}

podpora dočasných klíčů

Import PFX může volitelně načíst privátní klíče přímo z paměti a obejít pevný disk. Pokud je nový příznak X509KeyStorageFlags.EphemeralKeySet zadán v konstruktoru X509Certificate2 nebo v jednom z přetížení metody X509Certificate2.Import, privátní klíče budou načteny jako dočasné klíče. Tím zabráníte tomu, aby se klíče zobrazovaly na disku. Nicméně:

  • Vzhledem k tomu, že klíče nejsou trvalé na disku, certifikáty načtené s tímto příznakem nejsou vhodnými kandidáty pro přidání do X509Store.

  • Klíče načtené tímto způsobem jsou téměř vždy načteny prostřednictvím Windows CNG systému. Volající proto musí přistupovat k privátnímu klíči voláním rozšiřujících metod, jako je cert.GetRSAPrivateKey(). Vlastnost X509Certificate2.PrivateKey nefunguje.

  • Vzhledem k tomu, že starší verze vlastnosti X509Certificate2.PrivateKey nefunguje s certifikáty, měli by vývojáři před přepnutím na dočasné klíče provést důkladné testování.

programové vytváření podpisových žádostí o certifikaci PKCS#10 a certifikátů veřejného klíče X.509

Počínaje rozhraním .NET Framework 4.7.2 můžou úlohy generovat žádosti o podepsání certifikátů (CRS), které umožňují generovat žádosti o certifikát do stávajících nástrojů. To je často užitečné v testovacích scénářích.

Další informace a příklady kódu najdete v tématu "Programové vytváření podpisových požadavků PKCS#10 a certifikátů veřejného klíče X.509" vblogu .NET .

Noví členové SignerInfo

Počínaje rozhraním .NET Framework 4.7.2 třída SignerInfo zveřejňuje další informace o podpisu. Hodnotu vlastnosti System.Security.Cryptography.Pkcs.SignerInfo.SignatureAlgorithm můžete načíst a určit algoritmus podpisu používaný podepisující osoby. SignerInfo.GetSignature lze volat k získání kopie kryptografického podpisu tohoto podepisujícího.

Ponechání zabaleného streamu otevřeného po odstranění CryptoStreamu

Počínaje rozhraním .NET Framework 4.7.2 má třída CryptoStream další konstruktor, který umožňuje Dispose nezavírat zabalený datový proud. Pokud chcete nechat zabalený datový proud otevřený po odstranění instance CryptoStream, zavolejte nový konstruktor CryptoStream následujícím způsobem:

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

změny dekomprese v DeflateStream

Počínaje rozhraním .NET Framework 4.7.2 se implementace operací dekomprese ve třídě DeflateStream změnila tak, aby ve výchozím nastavení používala nativní rozhraní API systému Windows. Obvykle to vede ke značnému zlepšení výkonu.

Podpora dekomprese pomocí rozhraní API systému Windows je ve výchozím nastavení povolena pro aplikace, které cílí na rozhraní .NET Framework 4.7.2. Aplikace, které cílí na starší verze rozhraní .NET Framework, ale běží v rozhraní .NET Framework 4.7.2, se můžou k tomuto chování přihlásit přidáním následujícího přepínače AppContext do konfiguračního souboru aplikace:

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

Další API pro kolekce

Rozhraní .NET Framework 4.7.2 přidává do typů SortedSet<T> a HashSet<T> řadu nových rozhraní API. Patří mezi ně:

Třída ConcurrentDictionary<TKey,TValue> zahrnuje nová přetížení AddOrUpdate a GetOrAdd metod pro načtení hodnoty ze slovníku nebo jeho přidání, pokud není nalezena, a přidání hodnoty do slovníku nebo jeho aktualizace, pokud již existuje.

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

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

ASP.NET

Podpora injektáže závislostí ve webových formulářích

injektáž závislostí (DI) oddělí objekty a jejich závislosti tak, aby se kód objektu už nemusel měnit jenom proto, že se změnila závislost. Při vývoji ASP.NET aplikací, které cílí na rozhraní .NET Framework 4.7.2, můžete:

podpora souborů cookie stejných webů

SameSite brání prohlížeči v odesílání souborů cookie spolu s požadavkem mezi weby. Rozhraní .NET Framework 4.7.2 přidává vlastnost HttpCookie.SameSite, jejíž hodnota je členem výčtu System.Web.SameSiteMode. Pokud je jeho hodnota SameSiteMode.Strict nebo SameSiteMode.Lax, ASP.NET přidá atribut SameSite do hlavičky set-cookie. Podpora SameSite se vztahuje na HttpCookie objekty i FormsAuthentication a System.Web.SessionState soubory cookie.

Nastavení SameSite pro objekt HttpCookie můžete provést následujícím způsobem:

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

Soubory cookie SameSite můžete také nakonfigurovat na úrovni aplikace úpravou souboru web.config:

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

SameSite můžete přidat pro soubory cookie FormsAuthentication a System.Web.SessionState úpravou konfiguračního souboru webu:

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

Síťování

Implementace vlastností HttpClientHandler

Rozhraní .NET Framework 4.7.1 přidalo do třídy System.Net.Http.HttpClientHandler osm vlastností. Ale dva hodili PlatformNotSupportedException. Rozhraní .NET Framework 4.7.2 teď poskytuje implementaci těchto vlastností. Vlastnosti zahrnují:

SQLClient

podpora univerzálního ověřování Azure Active Directory a vícefaktorového ověřování

Rostoucí požadavky na dodržování předpisů a zabezpečení vyžadují, aby mnoho zákazníků používalo vícefaktorové ověřování (MFA). Kromě toho, zahrnout hesla uživatelů přímo do připojovacích řetězců nedoporučují aktuální osvědčené postupy. Pro podporu těchto změn rozšiřuje rozhraní .NET Framework 4.7.2 připojovací řetězce SQLClient přidáním nové hodnoty , "Active Directory Interactive", pro existující klíčové slovo Ověřování pro podporu vícefaktorového ověřování a ověřování Azure AD. Nová interaktivní metoda podporuje nativní a federované uživatele Azure AD i uživatele typu host Azure AD. Při použití této metody se pro databáze SQL podporuje vícefaktorové ověřování uložené službou Azure AD. Kromě toho proces ověřování požaduje heslo uživatele, aby dodržoval osvědčené postupy zabezpečení.

V předchozích verzích rozhraní .NET Framework podporovalo připojení SQL pouze možnosti SqlAuthenticationMethod.ActiveDirectoryPassword a SqlAuthenticationMethod.ActiveDirectoryIntegrated. Obě jsou součástí neinteraktivního protokolu ADAL, který nepodporuje vícefaktorové ověřování. Díky nové možnosti SqlAuthenticationMethod.ActiveDirectoryInteractive podporuje připojení SQL vícefaktorové ověřování i existující metody ověřování (heslo a integrované ověřování), které uživatelům umožňuje interaktivně zadávat uživatelská hesla bez zachování hesel v připojovacím řetězci.

Další informace a příklad najdete v tématu Sql – Podpora univerzálního ověřování Azure AD a vícefaktorového ověřování vblogu .NET.

Podpora funkce Always Encrypted verze 2

NET Framework 4.7.2 přidává podporu pro funkci Always Encrypted založenou na enklávě. Původní verze funkce Always Encrypted je technologie šifrování na straně klienta, ve které šifrovací klíče nikdy neopustí klienta. V případě funkce Always Encrypted založené na enklávě může klient volitelně odeslat šifrovací klíče do zabezpečené enklávy, což je zabezpečená výpočetní entita, která může být považována za součást SQL Serveru, ale kód SQL Serveru nemůže manipulovat. Pro podporu funkce Always Encrypted založené na enklávě přidá rozhraní .NET Framework 4.7.2 do oboru názvů System.Data.SqlClient následující typy a členy:

Konfigurační soubor aplikace pak určuje konkrétní implementaci abstraktní System.Data.SqlClient.SqlColumnEncryptionEnclaveProvider třídy, která poskytuje funkce pro zprostředkovatele enklávy. Například:

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

Základní průběh funkce Always Encrypted založené na enklávě je:

  1. Uživatel vytvoří připojení AlwaysEncrypted k SQL Serveru, které podporovaly funkci Always Encrypted založenou na enklávě. Ovladač kontaktuje službu ověřování, aby se ujistil, že se připojuje ke správné enklávě.

  2. Jakmile je enkláva potvrzena, ovladač vytvoří zabezpečený kanál se zabezpečeným enklávem hostovaným na SQL Serveru.

  3. Ovladač sdílí šifrovací klíče autorizované klientem se zabezpečenou enklávou po dobu trvání připojení k SQL.

Windows Presentation Foundation

Hledání knihoven prostředků podle zdroje

Počínaje rozhraním .NET Framework 4.7.2 může diagnostický asistent vyhledat ResourceDictionaries, které byly vytvořeny z daného identifikátoru URI zdroje. (Tato funkce je určená diagnostickými asistenty, ne produkčními aplikacemi.) Diagnostický asistent, jako je například "Edit-and-Continue" sady Visual Studio, umožňuje uživateli upravit ResourceDictionary se záměrem, že se změny použijí pro spuštěnou aplikaci. Jedním z kroků k dosažení tohoto cíle je nalezení všech slovníků zdrojů, které spuštěná aplikace vytvořila z upravovaného slovníku. Aplikace může například deklarovat ResourceDictionary, jehož obsah se zkopíruje z daného zdrojového identifikátoru URI:

<ResourceDictionary Source="MyRD.xaml" />

Diagnostický asistent, který upravuje původní kód v MyRD.xaml může novou funkci použít k vyhledání slovníku. Funkce je implementována novou statickou metodou, ResourceDictionaryDiagnostics.GetResourceDictionariesForSource. Diagnostický asistent volá novou metodu pomocí absolutního identifikátoru URI, který identifikuje původní kód, jak je znázorněno v následujícím kódu:

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

Metoda vrátí prázdný výčet, pokud není povolen VisualDiagnostics nebo není nastavena proměnná prostředí ENABLE_XAML_DIAGNOSTICS_SOURCE_INFO.

Hledání vlastníků ResourceDictionary

Počínaje rozhraním .NET Framework 4.7.2 může diagnostický asistent vyhledat vlastníky daného ResourceDictionary. (Funkce je určená diagnostickými asistenty, nikoli produkčními aplikacemi.) Při každé změně ResourceDictionarywpF automaticky najde všechny DynamicResource odkazy, které by mohly být touto změnou ovlivněny.

Diagnostický asistent, jako je například zařízení "Edit-and-Continue" sady Visual Studio, může chtít tuto možnost rozšířit tak, aby zpracovával odkazy na StaticResource. Prvním krokem v tomto procesu je vyhledání vlastníků slovníku; to znamená, najít všechny objekty, jejichž Resources vlastnost odkazuje na slovník (buď přímo, nebo nepřímo prostřednictvím ResourceDictionary.MergedDictionaries vlastnost). Tři nové statické metody implementované ve třídě System.Windows.Diagnostics.ResourceDictionaryDiagnostics, jedna pro každý základní typ, který má vlastnost Resources, podporuje tento krok:

Tyto metody vrátí prázdný výčet, pokud není povolená VisualDiagnostics a proměnná prostředí ENABLE_XAML_DIAGNOSTICS_SOURCE_INFO je nastavena.

Vyhledávání referencí StaticResource

Diagnostický asistent teď může obdržet oznámení pokaždé, když se vyřeší odkaz StaticResource. (Funkce je určená diagnostickými asistenty, ne produkčními aplikacemi.) Diagnostický asistent, jako je například "Edit-and-Continue" sady Visual Studio, může chtít aktualizovat všechna použití prostředku, když se jeho hodnota v ResourceDictionary změní. WPF to dělá automaticky pro odkazy DynamicResource , ale záměrně to nedělá pro odkazy StaticResource . Počínaje rozhraním .NET Framework 4.7.2 může diagnostický asistent tato oznámení použít k vyhledání použití statických prostředků.

Oznámení implementuje nová událost ResourceDictionaryDiagnostics.StaticResourceResolved:

public static event EventHandler<StaticResourceResolvedEventArgs> StaticResourceResolved;

Tato událost se vyvolá vždy, když modul runtime vyřeší StaticResource referenci. Argumenty StaticResourceResolvedEventArgs popisují rozlišení a označují objekt a vlastnost, které hostují odkaz StaticResource a ResourceDictionary a klíč použitý pro rozlišení:

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

   public Object TargetProperty { get; }

   public ResourceDictionary ResourceDictionary { get; }

   public object ResourceKey { get; }
}

Událost se nevyvolá (a její add přístup se ignoruje), pokud není povolen VisualDiagnostics a není nastavena proměnná prostředí ENABLE_XAML_DIAGNOSTICS_SOURCE_INFO.

ClickOnce

Aplikace pracující s HDPI pro Windows Forms, Windows Presentation Foundation (WPF) a Visual Studio Tools for Office (VSTO) je možné nasadit pomocí Technologie ClickOnce. Pokud se v manifestu aplikace najde následující položka, nasazení bude úspěšné v rozhraní .NET Framework 4.7.2:

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

Pro aplikaci Windows Forms již není nutné, aby nasazení ClickOnce proběhlo úspěšně, nastavovat povědomí o DPI v konfiguračním souboru aplikace místo v manifestu aplikace.

Novinky v rozhraní .NET Framework 4.7.1

.NET Framework 4.7.1 obsahuje nové funkce v následujících oblastech:

Kromě toho se v rozhraní .NET Framework 4.7.1 výrazně zaměřujeme na přístupnost, která umožňuje aplikaci poskytovat vhodné prostředí pro uživatele technologie usnadnění. Informace o vylepšeních přístupnosti v rozhraní .NET Framework 4.7.1 najdete v tématu Novinky v přístupnosti v rozhraní .NET Framework.

Základní třídy

Podpora pro .NET Standard 2.0

.NET Standard definuje sadu API, která musí být dostupná pro každou implementaci .NET, jež podporuje danou verzi standardu. Rozhraní .NET Framework 4.7.1 plně podporuje rozhraní .NET Standard 2.0 a přidává přibližně 200 rozhraní API, která jsou definována v rozhraní .NET Standard 2.0 a chybí v rozhraní .NET Framework 4.6.1, 4.6.2 a 4.7. (Mějte na paměti, že tyto verze rozhraní .NET Framework podporují .NET Standard 2.0 pouze v případě, že jsou v cílovém systému nasazeny také další podpůrné soubory .NET Standard.) Další informace najdete v tématu "BCL - .NET Standard 2.0 Podpora" v .NET Framework 4.7.1 Runtime a funkce kompilátoru blogový příspěvek.

podpora pro tvůrce konfigurací

Tvůrci konfigurací umožňují vývojářům vkládat a vytvářet nastavení konfigurace pro aplikace dynamicky za běhu. Vlastní tvůrce konfigurací je možné použít k úpravě existujících dat v konfiguračním oddílu nebo k zcela úplně od začátku sestavení konfiguračního oddílu. Bez tvůrce konfigurace jsou soubory .config statické a jejich nastavení jsou definována určitou dobu před spuštěním aplikace.

Chcete-li vytvořit vlastní konfiguraci builder, odvodíte builder z abstraktní třídy ConfigurationBuilder a přepíšete jeho ConfigurationBuilder.ProcessConfigurationSection a ConfigurationBuilder.ProcessRawXml. V souboru .config také definujete buildry. Další informace najdete v části Tvůrci konfigurace v blogovém příspěvku .NET Framework 4.7.1 ASP.NET a funkce konfigurace.

zjišťování funkcí za běhu

Třída System.Runtime.CompilerServices.RuntimeFeature poskytuje mechanismus pro určení, zda je předdefinovaná funkce podporována v dané implementaci .NET v době kompilace nebo za běhu. V době kompilace může kompilátor zkontrolovat, zda zadané pole existuje, a určit, zda je tato funkce podporována; pokud ano, může generovat kód, který tuto funkci využívá. Během běhu může aplikace zavolat metodu RuntimeFeature.IsSupported před generováním kódu. Další informace najdete v tématu Přidání pomocné metody pro popis funkcí podporovaných modulem runtime.

Typy n-tic hodnot jsou serializovatelné

Počínaje rozhraním .NET Framework 4.7.1 jsou System.ValueTuple a jeho přidružené obecné typy označeny jako Serializovatelné, což umožňuje binární serializaci. To by mělo usnadnit migraci typů n-tic, jako jsou Tuple<T1,T2,T3> a Tuple<T1,T2,T3,T4>, na typy hodnotových n-tic. Další informace naleznete v části "Kompilátor - ValueTuple je serializovatelný" v příspěvku na blogu o funkcích runtime a kompilátoru .NET Framework 4.7.1 .

Podpora odkazů jen pro čtení

.NET Framework 4.7.1 přidává System.Runtime.CompilerServices.IsReadOnlyAttribute. Tento atribut používají kompilátory jazyka k označení členů, kteří mají návratové typy nebo parametry jen pro čtení. Další informace viz "Kompilátor – Podpora pro ReadOnlyReferences" v článku na blogu .NET Framework 4.7.1 Runtime a kompilátorové funkce. Informace o Ref návratových hodnotách naleznete v tématu Ref návratové hodnoty a Ref lokální hodnoty a Ref návratové hodnoty (Visual Basic).

Clr (Common Language Runtime)

vylepšení výkonu garbage collection

Změny v garbage collection (GC) v rozhraní .NET Framework 4.7.1 zlepšují celkový výkon, zvláště při přidělování velkých objektů v haldě (LOH). V rozhraní .NET Framework 4.7.1 se používají samostatné zámky pro přidělování paměti na malé haldě objektů (SOH) a velké haldě objektů (LOH), což umožňuje, aby přidělování LOH probíhalo i během procesu uvolňování paměti na pozadí u SOH. V důsledku toho by aplikace, které provádějí velký počet alokací LOH, měly vidět snížení souběhu při alokaci a zlepšení výkonu. Další informace najdete v oddíle „Runtime – Vylepšení výkonu GC“ v blogovém příspěvku .NET Framework 4.7.1 Runtime a funkce kompilátoru.

Síťování

Podpora SHA-2 pro funkci Message.HashAlgorithm

V rozhraní .NET Framework 4.7 a starších verzích Message.HashAlgorithm vlastnost podporuje pouze hodnoty HashAlgorithm.Md5 a HashAlgorithm.Sha. Od rozhraní .NET Framework 4.7.1 se podporují také HashAlgorithm.Sha256, HashAlgorithm.Sha384a HashAlgorithm.Sha512. To, zda se tato hodnota skutečně používá, závisí na MSMQ, protože Message instance sama neprovádí žádné hashování, ale jednoduše předává hodnoty do MSMQ. Další informace najdete v části "Podpora SHA-2 pro Message.HashAlgorithm" v .NET Framework 4.7.1 ASP.NET a funkce konfigurace blogový příspěvek.

ASP.NET

kroky provádění v ASP.NET aplikacích

ASP.NET zpracovává požadavky v předdefinovaném kanálu, který obsahuje 23 událostí. ASP.NET spustí každou obslužnou rutinu události jako vykonávací krok. Ve verzích ASP.NET až po .NET Framework 4.7 nelze v ASP.NET propagovat kontext provádění kvůli přepínání mezi nativními a spravovanými vlákny. Místo toho ASP.NET selektivně přenáší pouze HttpContext. Počínaje rozhraním .NET Framework 4.7.1, metoda HttpApplication.OnExecuteRequestStep(Action<HttpContextBase,Action>) také umožňuje modulům obnovit kontextová data. Tato funkce se zaměřuje na knihovny zaměřené na trasování, profilaci, diagnostiku nebo transakce, například na tok provádění aplikace. Další informace najdete v blogovém příspěvku o funkci kroku provádění ASP.NET v rámci příspěvku .NET Framework 4.7.1 ASP.NET a funkcí konfigurace.

ASP.NET parsování HttpCookie

Rozhraní .NET Framework 4.7.1 obsahuje novou metodu HttpCookie.TryParse, která poskytuje standardizovaný způsob, jak vytvořit objekt HttpCookie z řetězce a přesně přiřadit hodnoty cookie, jako je datum vypršení platnosti a cesta. Další informace naleznete viz "ASP.NET HttpCookie analýza" v blogovém příspěvku o rozhraní .NET Framework 4.7.1, funkcích ASP.NET a konfiguraci.

možnosti hash SHA-2 pro přihlašovací údaje pro ověřování formulářů ASP.NET

V rozhraní .NET Framework 4.7 a starších verzích ASP.NET vývojářům povolit ukládání uživatelských přihlašovacích údajů s hashovanými hesly v konfiguračních souborech pomocí MD5 nebo SHA1. Počínaje rozhraním .NET Framework 4.7.1 ASP.NET také podporuje nové zabezpečené možnosti hash SHA-2, jako jsou SHA256, SHA384 a SHA512. SHA1 zůstává výchozí a v konfiguračním souboru webu je možné definovat jiný než výchozí hashovací algoritmus.

Důležité

Microsoft doporučuje používat nejbezpečnější dostupný tok ověřování. Pokud se připojujete k Azure SQL, spravované identity pro prostředky Azure je doporučená metoda ověřování.

Novinky v rozhraní .NET Framework 4.7

.NET Framework 4.7 obsahuje nové funkce v následujících oblastech:

Seznam nových rozhraní API přidaných do rozhraní .NET Framework 4.7 najdete v tématu změny rozhraní API rozhraní .NET Framework 4.7 na GitHubu. Seznam vylepšení funkcí a oprav chyb v rozhraní .NET Framework 4.7 najdete v tématu .NET Framework 4.7 Seznam změn na GitHubu. Další informace naleznete v tématu Oznámení rozhraní .NET Framework 4.7 v blogu .NET.

Základní třídy

Rozhraní .NET Framework 4.7 zlepšuje serializaci DataContractJsonSerializer.

Vylepšená funkcionalita díky kryptografii eliptických křivek (ECC)*

V rozhraní .NET Framework 4.7 byly do tříd ECDsa a ECDiffieHellman přidány metody ImportParameters(ECParameters), aby objekt mohl představovat již vytvořený klíč. Byla přidána také metoda ExportParameters(Boolean) pro export klíče pomocí explicitních parametrů křivky.

.NET Framework 4.7 také přidává podporu dalších křivek (včetně sady křivek Brainpool) a přidal předdefinované definice pro snadné vytvoření prostřednictvím nových továrních metod Create a Create.

Můžete si prohlédnout příklad vylepšení kryptografie rozhraní .NET Framework 4.7 na GitHubu.

Lepší podpora řídicích znaků pomocí DataContractJsonSerializer

V rozhraní .NET Framework 4.7 třída DataContractJsonSerializer serializuje řídicí znaky v souladu se standardem ECMAScript 6. Toto chování je ve výchozím nastavení povolené pro aplikace, které cílí na rozhraní .NET Framework 4.7, a je to funkce výslovného souhlasu pro aplikace, které běží v rozhraní .NET Framework 4.7, ale cílí na předchozí verzi rozhraní .NET Framework. Další informace najdete v části Kompatibilita aplikací.

Síťování

Rozhraní .NET Framework 4.7 přidává následující funkci související se sítí:

výchozí podpora operačního systému pro protokoly TLS*

Zásobník TLS, který používá komponenty System.Net.Security.SslStream a up-stack, jako je HTTP, FTP a SMTP, umožňuje vývojářům používat výchozí protokoly TLS podporované operačním systémem. Vývojáři už nemusí pevně kódovat verzi protokolu TLS.

ASP.NET

V rozhraní .NET Framework 4.7 ASP.NET obsahuje následující nové funkce:

rozšiřitelnost mezipaměti objektů

Počínaje rozhraním .NET Framework 4.7 ASP.NET přidá novou sadu rozhraní API, která vývojářům umožní nahradit výchozí ASP.NET implementace pro ukládání objektů do mezipaměti a monitorování paměti v paměti. Vývojáři teď můžou nahradit některou z následujících tří komponent, pokud implementace ASP.NET není adekvátní:

  • úložiště mezipaměti objektů. Pomocí oddílu konfigurace nových poskytovatelů mezipaměti můžou vývojáři připojit nové implementace mezipaměti objektů pro ASP.NET aplikaci pomocí nového rozhraní ICacheStoreProvider.

  • monitorování paměti. Výchozí monitorování paměti v ASP.NET upozorní aplikace, když běží blízko nakonfigurovaného limitu privátních bajtů pro tento proces, nebo když je počítač nízký na celkové dostupné fyzické paměti RAM. Když jsou tyto limity blízko, oznámení se odesílají. U některých aplikací se oznámení aktivují příliš blízko nakonfigurovaných limitů, aby umožňovala užitečné reakce. Vývojáři teď můžou napsat vlastní monitorování paměti, které nahradí výchozí nastavení pomocí vlastnosti ApplicationMonitors.MemoryMonitor.

  • reakce na paměťové omezení. Ve výchozím nastavení se ASP.NET snaží omezit mezipaměť objektů a také pravidelně volat GC.Collect, když se blíží limit spotřeby privátních bajtů. U některých aplikací je frekvence volání do GC.Collect nebo množství mezipaměti, která je oříznuta, neefektivní. Vývojáři teď můžou nahradit nebo doplnit výchozí chování tím, že přihlásí implementace IObserver jako odběratele monitoru paměti aplikace.

Windows Communication Foundation (WCF)

Windows Communication Foundation (WCF) přidává následující funkce a změny:

Možnost nakonfigurovat výchozí nastavení zabezpečení zpráv na protokol TLS 1.1 nebo TLS 1.2

Počínaje rozhraním .NET Framework 4.7 umožňuje WCF nakonfigurovat protokol TLS 1.1 nebo TLS 1.2 kromě protokolu SSL 3.0 a TLS 1.0 jako výchozí protokol zabezpečení zpráv. Toto je nastavení výslovného souhlasu; pokud ho chcete povolit, musíte do konfiguračního souboru aplikace přidat následující položku:

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

vyšší spolehlivost aplikací WCF a serializace WCF

WCF obsahuje řadu změn kódu, které eliminují kritické závodní podmínky, což zlepšuje výkon a spolehlivost možností serializace. Patří mezi ně:

  • Lepší podpora kombinování asynchronního a synchronního kódu ve voláních SocketConnection.BeginRead a SocketConnection.Read.
  • Vyšší spolehlivost při ukončení spojení s SharedConnectionListener a DuplexChannelBinder.
  • Vylepšili jsme spolehlivost operací serializace při volání metody FormatterServices.GetSerializableMembers(Type).
  • Vylepšili jsme spolehlivost při odebírání číšníka voláním metody ChannelSynchronizer.RemoveWaiter.

Windows Forms

V rozhraní .NET Framework 4.7 windows Forms zlepšuje podporu pro monitorování s vysokým rozlišením DPI.

podpora vysokého DPI

Počínaje aplikacemi, které cílí na rozhraní .NET Framework 4.7, má rozhraní .NET Framework vysokou dpi a dynamickou podporu DPI pro aplikace Windows Forms. Podpora vysokého DPI zlepšuje rozložení a vzhled formulářů a ovládacích prvků na monitorech s vysokým rozlišením DPI. Dynamické DPI změní rozložení a vzhled formulářů a ovládacích prvků, když uživatel změní měřítko DPI nebo faktor měřítka zobrazení spuštěné aplikace.

Podpora vysokého DPI je funkce výslovného souhlasu, kterou konfigurujete definováním oddílu <System.Windows.Forms.ConfigurationSection> v konfiguračním souboru aplikace. Další informace o přidání podpory vysokého DPI a dynamického DPI do aplikace Windows Forms naleznete v tématu Podpora vysokého DPI ve Windows Forms.

Windows Presentation Foundation (WPF)

V rozhraní .NET Framework 4.7 obsahuje WPF následující vylepšení:

Podpora pro technologický stack dotykového/stylusového ovládání založeného na zprávách systému Windows WM_POINTER

Teď máte možnost používat zásobník dotykového ovládání/stylus založený na WM_POINTER zprávách místo platformy WISP (Windows Ink Services Platform). Toto je funkce výslovného souhlasu v rozhraní .NET Framework. Další informace najdete v části Kompatibilita aplikací.

nová implementace rozhraní API pro tisk WPF

Rozhraní API pro tisk WPF ve třídě System.Printing.PrintQueue volají rozhraní API pro tisk dokumentů systému Windows místo zastaralého rozhraní XPS Print API. Dopad této změny na kompatibilitu aplikací najdete v části kompatibility aplikací.

Novinky v rozhraní .NET Framework 4.6.2

.NET Framework 4.6.2 obsahuje nové funkce v následujících oblastech:

Seznam nových rozhraní API přidaných do rozhraní .NET Framework 4.6.2 najdete v tématu změny rozhraní API rozhraní .NET Framework 4.6.2 na GitHubu. Seznam vylepšení funkcí a oprav chyb v rozhraní .NET Framework 4.6.2 najdete v tématu .NET Framework 4.6.2 Seznam změn na GitHubu. Další informace najdete v tématu Oznámení rozhraní .NET Framework 4.6.2 v blogu .NET.

ASP.NET

V rozhraní .NET Framework 4.6.2 ASP.NET zahrnuje následující vylepšení:

vylepšená podpora lokalizovaných chybových zpráv v validátorech datových poznámek

Validátory datových poznámek umožňují provést ověření přidáním jednoho nebo více atributů do vlastnosti třídy. Prvek ValidationAttribute.ErrorMessage atributu definuje text chybové zprávy, pokud se ověření nezdaří. Počínaje rozhraním .NET Framework 4.6.2 ASP.NET usnadňuje lokalizaci chybových zpráv. Chybové zprávy budou lokalizovány v následujících případech:

  1. ValidationAttribute.ErrorMessage je k dispozici v ověřovacím atributu.

  2. Soubor prostředků je uložen ve složce App_LocalResources.

  3. Název lokalizovaného souboru prostředků má tvar DataAnnotation.Localization.{název}.resx, kde název je název jazykové verze ve formátu jazykový kód-kód země/regionu nebo jazykový kód.

  4. Název klíče prostředku je řetězec přiřazený k atributu ValidationAttribute.ErrorMessage a jeho hodnota je lokalizovaná chybová zpráva.

Například následující atribut datové poznámky definuje chybovou zprávu výchozího nastavení kultury pro neplatné hodnocení.

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

Pak můžete vytvořit soubor prostředků DataAnnotation.Localization.fr.resx, jehož klíčem je řetězec chybové zprávy a jehož hodnotou je lokalizovaná chybová zpráva. Soubor musí být nalezen ve složce App.LocalResources. Například následující je klíč a jeho hodnota v lokalizované chybové zprávě ve francouzštině (fr):

Jméno Hodnota
Hodnocení musí být v rozmezí od 1 do 10. Známka musí být mezi 1 a 10.

Kromě toho je lokalizace datových poznámek rozšiřitelná. Vývojáři mohou integrovat vlastního poskytovatele lokalizace řetězců implementací rozhraní IStringLocalizerProvider k ukládání lokalizačního řetězce jinam než do souboru prostředků.

podpora asynchronní synchronizace s poskytovateli úložiště stavu relace

ASP.NET nyní umožňuje používat metody vracející úlohy s poskytovateli úložiště stavu relace, což umožňuje ASP.NET aplikacím získat výhody škálovatelnosti asynchronního programování. Pro podporu asynchronních operací s poskytovateli úložiště stavů relací ASP.NET zahrnuje nové rozhraní, System.Web.SessionState.ISessionStateModule, které dědí z IHttpModule a umožňuje vývojářům implementovat vlastní modul stavu relace a asynchronní zprostředkovatele úložiště relací. Rozhraní je definováno takto:

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

Kromě toho třída SessionStateUtility obsahuje dvě nové metody, IsSessionStateReadOnly a IsSessionStateRequired, které lze použít k podpoře asynchronních operací.

Asynchronní podpora pro poskytovatele výstupní mezipaměti

Počínaje rozhraním .NET Framework 4.6.2 je možné s poskytovateli výstupní mezipaměti použít metody vrácení úloh, které poskytují výhody škálovatelnosti asynchronního protokolu. Poskytovatelé, kteří tyto metody implementují, omezují blokování vláken na webovém serveru a zlepšují škálovatelnost služby ASP.NET.

Přidali jsme následující rozhraní API pro podporu asynchronních poskytovatelů výstupní mezipaměti:

Kategorie znaků

Znaky v rozhraní .NET Framework 4.6.2 jsou klasifikovány na základě standardu Unicode verze 8.0.0. V rozhraní .NET Framework 4.6 a .NET Framework 4.6.1 byly znaky klasifikovány na základě kategorií znaků Unicode 6.3.

Podpora kódování Unicode 8.0 je omezena na klasifikaci znaků podle třídy CharUnicodeInfo a na typy a metody, které na něj spoléhají. Patří sem třída StringInfo, přetížená metoda Char.GetUnicodeCategory a třídy znaků rozpoznané modulem regulárních výrazů rozhraní .NET Framework. Porovnávání a řazení znaků a řetězců zůstává touto změnou neovlivněno a nadále spoléhá na základ operačního systému, nebo v systémech Windows 7 na znaková data poskytovaná rozhraním .NET Framework.

Viz Standard Unicode, verze 7.0.0 na webu Unicode Consortium pro změny v kategoriích znaků z Unicode 6.0 na Unicode 7.0. Změny z Unicode 7.0 na Unicode 8.0 naleznete pod Standard Unicode, verze 8.0.0 na webu konsorcia Unicode.

Kryptografie

Podpora certifikátů X509 obsahujících FIPS 186-3 DSA

Rozhraní .NET Framework 4.6.2 přidává podporu pro certifikáty X509 dsA (Digital Signature Algorithm), jejichž klíče překračují limit FIPS 186-2 1024 bitů.

Kromě podpory větších velikostí klíčů FIPS 186-3 umožňuje rozhraní .NET Framework 4.6.2 výpočetní podpisy pomocí řady hash SHA-2 (SHA256, SHA384 a SHA512). Podpora FIPS 186-3 je poskytována novou třídou System.Security.Cryptography.DSACng.

V souladu s nedávnými změnami třídy RSA v rozhraní .NET Framework 4.6 a třídy ECDsa v rozhraní .NET Framework 4.6.1 má abstraktní základní třída DSA v rozhraní .NET Framework 4.6.2 další metody, které umožňují volajícím používat tuto funkci bez nutnosti přetypování. Můžete zavolat metodu rozšíření DSACertificateExtensions.GetDSAPrivateKey pro podepsání dat, jak ukazuje následující příklad.

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

Můžete zavolat rozšiřující metodu DSACertificateExtensions.GetDSAPublicKey k ověření podepsaných dat, jak je vidět na následujícím příkladu.

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

vyšší srozumitelnost vstupů do rutin odvozování klíče ECDiffieHellman

.NET Framework 3.5 přidal podporu pro Elliptic Curve Diffie-Hellman Key Agreement se třemi různými rutinami funkce KDF (Key Derivation Function). Vstupy do rutin a samotné rutiny byly nakonfigurovány prostřednictvím vlastností v objektu ECDiffieHellmanCng. Ale vzhledem k tomu, že ne každá rutina čte každou vstupní vlastnost, bylo v minulosti vývojáře více místa pro nejasnosti.

Abychom to vyřešili v rozhraní .NET Framework 4.6.2, byly do ECDiffieHellman základní třídy přidány následující tři metody, které jasněji představují tyto rutiny KDF a jejich vstupy:

ECDiffieHellman – metoda Popis
DeriveKeyFromHash(ECDiffieHellmanPublicKey, HashAlgorithmName, Byte[], Byte[]) Odvození klíčového materiálu pomocí vzorce

HASH(secretPrepend || x || secretAppend)

HASH(secretPrepend OrElse x OrElse secretAppend)

kde x je vypočítaný výsledek algoritmu EC Diffie-Hellman.
DeriveKeyFromHmac(ECDiffieHellmanPublicKey, HashAlgorithmName, Byte[], Byte[], Byte[]) Odvození klíčového materiálu pomocí vzorce

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

HMAC(hmacKey, secretPrepend nebo x nebo secretAppend)

kde x je vypočítaný výsledek algoritmu EC Diffie-Hellman.
DeriveKeyTls(ECDiffieHellmanPublicKey, Byte[], Byte[]) Odvozuje klíčový materiál pomocí algoritmu odvození pseudonáhodné funkce TLS (PRF).

podpora pro trvalé symetrické šifrování klíčů

Kryptografická knihovna systému Windows (CNG) přidala podporu pro ukládání trvalých symetrických klíčů a používání hardwarově uložených symetrických klíčů a rozhraní .NET Framework 4.6.2 umožnilo vývojářům využívat tuto funkci. Vzhledem k tomu, že pojem klíčových názvů a poskytovatelů klíčů je specifický pro implementaci, vyžaduje použití této funkce využití konstruktoru konkrétních typů implementace místo preferované metody továrny (například volání Aes.Create).

Pro algoritmy AES (AesCng) a 3DES (TripleDESCng) existuje podpora symetrického šifrování s trvalým klíčem. Například:

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);
        }
    }
}

podporuje SignedXml pro hashování SHA-2

.NET Framework 4.6.2 přidává podporu do třídy SignedXml pro RSA-SHA256, RSA-SHA384 a RSA-SHA512 PKCS#1 podpisové metody a algoritmy SHA256, SHA384 a SHA512 reference digest.

Všechny konstanty identifikátoru URI jsou vystaveny na SignedXml:

Pole SignedXml Konstanta
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"

Všechny programy, které zaregistrovaly vlastní obslužnou rutinu SignatureDescription do CryptoConfig pro přidání podpory těchto algoritmů budou dál fungovat stejně jako v minulosti, ale vzhledem k tomu, že teď jsou výchozí hodnoty platformy, CryptoConfig registrace už není nutná.

SqlClient

Zprostředkovatel dat rozhraní .NET Framework pro SQL Server (System.Data.SqlClient) obsahuje následující nové funkce rozhraní .NET Framework 4.6.2:

Sdružování připojení a časové limity v rámci databází Azure SQL

Pokud je povolené sdružování připojení a dojde k vypršení časového limitu nebo jiné chyby přihlášení, dojde k výjimce uložené v mezipaměti a při každém následném pokusu o připojení po dobu dalších 5 sekund až 1 minut se vyvolá výjimka uložená v mezipaměti. Další informace najdete v tématu sdružování připojení SQL Serveru (ADO.NET).

Toto chování není žádoucí při připojování ke službě Azure SQL Database, protože pokusy o připojení můžou selhat s přechodnými chybami, které se obvykle rychle obnoví. Pro lepší optimalizaci procesu opakování připojení bylo odstraněno blokování fondu připojení při selhání připojení k databázím Azure SQL.

Přidání nového klíčového slova PoolBlockingPeriod umožňuje vybrat období blokování, které je pro vaši aplikaci nejvhodnější. Mezi hodnoty patří:

Auto

Doba blokování fondu připojení pro aplikaci, která se připojuje ke službě Azure SQL Database, je zakázaná a doba blokování fondu připojení pro aplikaci, která se připojuje k jakékoli jiné instanci SQL Serveru, je povolená. Toto je výchozí hodnota. Pokud název koncového bodu serveru končí některým z následujících bodů, považují se za azure SQL Database:

  • .database.windows.net

  • .database.chinacloudapi.cn

  • .database.usgovcloudapi.net

  • .database.cloudapi.de

AlwaysBlock

Období blokování fondu připojení je vždy aktivní.

NeverBlock

Doba blokování fondu připojení je vždy vypnutá.

Vylepšení pro funkci Always Encrypted

SQLClient zavádí dvě vylepšení funkce Always Encrypted:

  • Kvůli zlepšení výkonu parametrizovaných dotazů vůči šifrovaným databázovým sloupcům se teď ukládají metadata šifrování parametrů dotazu do mezipaměti. Když je vlastnost SqlConnection.ColumnEncryptionQueryMetadataCacheEnabled nastavená na true (což je výchozí hodnota), pokud se stejný dotaz volá vícekrát, klient načte metadata parametrů ze serveru pouze jednou.

  • Položky šifrovacího klíče sloupce v mezipaměti klíčů se teď vyřazují po konfigurovatelném časovém intervalu nastaveném pomocí vlastnosti SqlConnection.ColumnEncryptionKeyCacheTtl.

Windows Communication Foundation

V rozhraní .NET Framework 4.6.2 byla služba Windows Communication Foundation vylepšena v následujících oblastech:

podpora zabezpečení přenosu WCF pro certifikáty uložené pomocí CNG

Zabezpečení přenosu WCF podporuje certifikáty uložené pomocí knihovny kryptografie systému Windows (CNG). V rozhraní .NET Framework 4.6.2 je tato podpora omezena na použití certifikátů s veřejným klíčem, který má exponent ne delší než 32 bitů. Pokud aplikace cílí na rozhraní .NET Framework 4.6.2, je tato funkce ve výchozím nastavení zapnutá.

Pro aplikace, které cílí na rozhraní .NET Framework 4.6.1 a starší, ale jsou spuštěny v rozhraní .NET Framework 4.6.2, můžete tuto funkci povolit přidáním následujícího řádku do <modulu runtime> oddílu app.config nebo web.config souboru.

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

Můžete to také provést programově pomocí kódu, jako je následující:

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

Lepší podpora více pravidel úpravy letního času pomocí třídy DataContractJsonSerializer

Zákazníci můžou pomocí nastavení konfigurace aplikace určit, jestli třída DataContractJsonSerializer podporuje více pravidel úprav pro jedno časové pásmo. Toto je funkce výslovného souhlasu. Pokud ho chcete povolit, přidejte do souboru app.config následující nastavení:

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

Pokud je tato funkce povolená, objekt DataContractJsonSerializer používá k deserializaci dat data a času TimeZoneInfo typ místo typu TimeZone. TimeZoneInfo podporuje více pravidel úpravy, která umožňují pracovat s historickými daty časového pásma; TimeZone ne.

Další informace o struktuře TimeZoneInfo a úpravách časového pásma najdete v tématu Přehled časového pásma.

NetNamedPipeBinding nejlepší shoda

WCF má nové nastavení aplikace, které lze nastavit v klientských aplikacích, aby se zajistilo, že se vždy připojí ke službě, která naslouchá na identifikátoru URI, který nejlépe odpovídá požadovanému identifikátoru. Když je toto nastavení aplikace nastavené na false (výchozí), je možné, aby se klienti používající NetNamedPipeBinding pokusili připojit ke službě naslouchající na URI, který je podřetězcem požadovaného URI.

Klient se například pokusí připojit ke službě naslouchácí na net.pipe://localhost/Service1, ale jiná služba na tomto počítači s oprávněním správce naslouchá na net.pipe://localhost. Když je toto nastavení aplikace nastavené na false, klient se pokusí připojit k nesprávné službě. Po nastavení nastavení aplikace na truese klient vždy připojí k nejvhodnější službě.

Poznámka

Klienti používající NetNamedPipeBinding najdou služby na základě základní adresy služby (pokud existuje) místo úplné adresy koncového bodu. Aby toto nastavení vždy fungovalo, měla by služba používat jedinečnou základní adresu.

Pokud chcete tuto změnu povolit, přidejte do souboru App.config nebo Web.config klientské aplikace následující nastavení aplikace:

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

SSL 3.0 není výchozí protokol

Při použití NetTcp se zabezpečením přenosu a typem přihlašovacích údajů certifikátu už ssl 3.0 není výchozí protokol používaný k vyjednávání zabezpečeného připojení. Ve většině případů by na existující aplikace nemělo mít žádný vliv, protože protokol TLS 1.0 je součástí seznamu protokolů pro NetTcp. Všichni stávající klienti by měli být schopni vyjednat připojení s použitím alespoň protokolu TLS 1.0. Pokud se vyžaduje ssl3, přidejte ho do seznamu vyjednaných protokolů pomocí jednoho z následujících mechanismů konfigurace.

Windows Presentation Foundation (WPF)

V rozhraní .NET Framework 4.6.2 byla služba Windows Presentation Foundation vylepšena v následujících oblastech:

řazení skupin

Aplikace, která používá objekt CollectionView k seskupení dat, teď může explicitně deklarovat způsob řazení skupin. Explicitní řazení řeší problém neintuitivnějšího řazení, ke kterému dochází, když aplikace dynamicky přidává nebo odebírá skupiny, nebo když změní hodnotu vlastností položek zahrnutých do seskupení. Může také zlepšit výkon procesu vytváření skupin tím, že přesune porovnání vlastností seskupení z řazení celé kolekce do řazení skupin.

Pokud chcete podporovat řazení skupin, nové GroupDescription.SortDescriptions a GroupDescription.CustomSort vlastnosti popisují, jak seřadit kolekci skupin vytvořených objektem GroupDescription. Je to podobné způsobu, jakým identicky pojmenované vlastnosti ListCollectionView popisují způsob řazení datových položek.

Pro nejběžnější případy lze použít dvě nové statické vlastnosti třídy PropertyGroupDescription, CompareNameAscending a CompareNameDescending.

Například následující XAML seskupí data podle věku, seřadí věkové skupiny vzestupně a položky v každé věkové skupině seskupí podle příjmení.

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

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

Podpora dotykové klávesnice

Podpora dotykové klávesnice umožňuje sledování fokusu v aplikacích WPF automatickým vyvoláním a zavřením dotykové klávesnice ve Windows 10 při přijetí dotykového vstupu ovládacím prvku, který může přijímat textové zadání.

V předchozích verzích rozhraní .NET Framework se aplikace WPF nemůžou přihlásit ke sledování fokusu bez zakázání podpory gest pera nebo dotykového ovládání WPF. V důsledku toho si musí aplikace WPF zvolit mezi plnou podporou dotykového ovládání WPF nebo spoléhat na emulaci myši ve Windows.

DPI na monitor

Pro podporu nedávného rozšíření prostředí s vysokým DPI a hybridním DPI pro aplikace WPF umožňuje WPF v rozhraní .NET Framework 4.6.2 informovanost o jednotlivých monitorech. Další informace o tom, jak povolit, aby se vaše aplikace WPF stala s povědomím o DPI jednotlivých monitorů, najdete v ukázkách a příručce pro vývojáře na GitHubu.

V předchozích verzích rozhraní .NET Framework byly aplikace WPF vědomé systémového DPI. Jinými slovy, uživatelské rozhraní aplikace se podle potřeby škáluje podle operačního systému v závislosti na DPI monitoru, na kterém se aplikace vykresluje.

U aplikací spuštěných v rozhraní .NET Framework 4.6.2 můžete zakázat změny DPI pro monitorování v aplikacích WPF přidáním konfiguračního příkazu do oddílu <runtime> konfiguračního souboru aplikace následujícím způsobem:

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

Windows Workflow Foundation (WF)

V rozhraní .NET Framework 4.6.2 byla služba Windows Workflow Foundation vylepšena v následující oblasti:

Podpora výrazů C# a IntelliSense v rehostovaném návrháři WF

Počínaje rozhraním .NET Framework 4.5 podporuje WF výrazy jazyka C# v návrháři sady Visual Studio i v pracovních postupech kódu. Návrhář pracovních postupů využívající rehostování je klíčovou funkcí WF, která umožňuje, aby návrhář pracovních postupů byl v aplikaci nacházející se mimo Visual Studio (například ve WPF). Windows Workflow Foundation poskytuje možnost podporovat výrazy jazyka C# a IntelliSense v přehostovaném návrháři pracovních postupů. Pro více informací viz blog Windows Workflow Foundation.

Availability of IntelliSense when a customer rebuilds a workflow project from Visual Studio Ve verzích rozhraní .NET Framework starších než 4.6.2 je technologie IntelliSense návrháře WF přerušena, když zákazník znovu sestaví projekt pracovního postupu ze sady Visual Studio. I když je sestavení projektu úspěšné, typy pracovních postupů se v návrháři nenajdou a v okně Seznam chyb se zobrazí upozornění technologie IntelliSense pro chybějící typy pracovních postupů. .NET Framework 4.6.2 řeší tento problém a zpřístupní Technologii IntelliSense.

aplikace pracovního postupu V1 se sledováním pracovních postupů nyní běží v režimu FIPS

Počítače s povoleným režimem dodržování předpisů FIPS teď můžou úspěšně spustit aplikaci ve stylu pracovního postupu verze 1 se sledováním pracovního postupu. Pokud chcete tento scénář povolit, musíte v souboru app.config provést následující změnu:

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

Pokud tento scénář není povolený, spuštění aplikace bude dál generovat výjimku se zprávou "Tato implementace není součástí kryptografických algoritmů ověřených platformou Windows FIPS.".

vylepšení pracovního postupu při použití dynamické aktualizace pomocí návrháře pracovních postupů sady Visual Studio

Návrhář pracovních postupů, Návrhář aktivity vývojových diagramů a další návrháři aktivit pracovních postupů nyní úspěšně načtou a zobrazí pracovní postupy uložené po volání metody DynamicUpdateServices.PrepareForUpdate. Ve verzích rozhraní .NET Framework před rozhraním .NET Framework 4.6.2 načtení souboru XAML v sadě Visual Studio pro pracovní postup, který byl uložen po volání DynamicUpdateServices.PrepareForUpdate může vést k následujícím problémům:

  • Návrhář pracovního postupu nemůže správně načíst soubor XAML (pokud je ViewStateData.Id na konci řádku).

  • Návrhář aktivity vývojového diagramu nebo jiní návrháři aktivit pracovního postupu můžou zobrazit všechny objekty v jejich výchozích umístěních na rozdíl od připojených hodnot vlastností.

ClickOnce

ClickOnce byl aktualizován tak, aby podporoval protokol TLS 1.1 a TLS 1.2 kromě protokolu 1.0, který již podporuje. ClickOnce automaticky zjistí, který protokol je vyžadován; K povolení podpory protokolu TLS 1.1 a 1.2 nejsou potřeba žádné další kroky v aplikaci ClickOnce.

Převod aplikací Windows Forms a WPF na aplikace pro UPW

Windows teď nabízí funkce pro přenesení stávajících desktopových aplikací pro Windows, včetně aplikací WPF a Windows Forms, na univerzální platformu Windows (UPW). Tato technologie funguje jako most tím, že umožňuje postupně migrovat stávající základ kódu do UPW, čímž aplikaci přenesete na všechna zařízení s Windows 10.

Převedené desktopové aplikace získají identitu aplikace podobnou identitě aplikace pro UPW, což zpřístupňuje rozhraní API pro UPW pro povolení funkcí, jako jsou živé dlaždice a oznámení. Aplikace se chová stejně jako předtím a běží jako úplná důvěryhodná aplikace. Po převodu aplikace je možné přidat proces kontejneru aplikace do existujícího úplného procesu důvěryhodnosti a přidat adaptivní uživatelské rozhraní. Když se všechny funkce přesunou do procesu kontejneru aplikace, můžete celý proces důvěryhodnosti odebrat a nová aplikace pro UPW se dá zpřístupnit pro všechna zařízení s Windows 10.

Vylepšení ladění

Rozhraní API nespravovaného ladění bylo v rozhraní .NET Framework 4.6.2 vylepšeno, aby bylo možné provést další analýzu, pokud dojde k vyvolání NullReferenceException, aby bylo možné určit, která proměnná v jednom řádku zdrojového kódu je null. Pro podporu tohoto scénáře byly do nespravovaného rozhraní API pro ladění přidána následující rozhraní API.

Novinky v rozhraní .NET Framework 4.6.1

.NET Framework 4.6.1 obsahuje nové funkce v následujících oblastech:

Další informace o rozhraní .NET Framework 4.6.1 najdete v následujících tématech:

Kryptografie: Podpora certifikátů X509 obsahujících ECDSA

Rozhraní .NET Framework 4.6 přidalo podporu RSACng pro certifikáty X509. Rozhraní .NET Framework 4.6.1 přidává podporu certifikátů ECDSA (Elliptic Curve Digital Signature Algorithm) X509.

ECDSA nabízí lepší výkon a je bezpečnějším kryptografickým algoritmem než RSA, což z něj činí vynikající volbu tam, kde je výkon a škálovatelnost Transport Layer Security (TLS) důležitá. Implementace rozhraní .NET Framework zabalí volání do stávajících funkcí Systému Windows.

Následující ukázkový kód ukazuje, jak snadné je vygenerovat podpis pro bajtový stream pomocí nové podpory certifikátů ECDSA X509 zahrnutých v rozhraní .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);
    }
}

To nabízí výrazný kontrast s kódem potřebným k vygenerování podpisu v rozhraní .NET Framework 4.6.

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

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

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

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

ADO.NET

Do ADO.NET byly přidány následující položky:

podpora funkce Always Encrypted pro klíče chráněné hardwarem

ADO.NET teď podporuje ukládání hlavních klíčů sloupců Always Encrypted nativně v modulech hardwarového zabezpečení (HSM). Díky této podpoře mohou zákazníci využívat asymetrické klíče uložené v HSM, aniž by museli psát vlastní poskytovatele hlavního úložiště klíčů pro sloupce a registrovat je v aplikacích.

Zákazníci musí nainstalovat poskytovatele CSP od dodavatele HSM nebo poskytovatele úložiště klíčů CNG na aplikační servery nebo klientské počítače, aby měli přístup k datům Always Encrypted chráněným hlavními klíči sloupců uloženými v HSM.

Vylepšené chování připojení pro AlwaysOn MultiSubnetFailover

SqlClient teď automaticky poskytuje rychlejší připojení ke skupině dostupnosti AlwaysOn (AG). Transparentně zjišťuje, jestli se vaše aplikace připojuje ke skupině dostupnosti AlwaysOn v jiné podsíti, a rychle zjistí aktuální aktivní server a poskytne připojení k serveru. Před touto verzí musela aplikace nastavit připojovací řetězec tak, aby zahrnoval "MultisubnetFailover=true", aby indikovala, že se připojila ke skupině dostupnosti AlwaysOn. Bez nastavení klíčového slova připojení na truemůže při připojování ke skupině dostupnosti AlwaysOn dojít k vypršení časového limitu. V této verzi aplikace už nemusí nastavit MultiSubnetFailover na true. Další informace o podpoře SqlClient pro skupiny dostupnosti AlwaysOn naleznete v tématu Podpora SqlClient pro vysokou dostupnost, zotavení po havárii.

Windows Presentation Foundation (WPF)

Windows Presentation Foundation obsahuje řadu vylepšení a změn.

vylepšený výkon

Zpoždění při aktivaci dotykových událostí bylo opraveno v rozhraní .NET Framework 4.6.1. Kromě toho zadávání do ovládacího prvku RichTextBox už během rychlého vstupu nezatěžuje vlákno vykreslování.

vylepšení kontroly pravopisu

Kontrola pravopisu ve WPF byla aktualizována ve Windows 8.1 a novějších verzích, aby využívala podporu operačního systému pro kontrolu pravopisu v dalších jazycích. Ve verzích Windows starších než Windows 8.1 nedošlo ke změně funkčnosti.

Stejně jako v předchozích verzích rozhraní .NET Framework je jazyk pro ovládací prvek TextBox nebo blok RichTextBox zjištěn vyhledáním informací v následujícím pořadí:

  • xml:lang, pokud je k dispozici.

  • Aktuální jazyk zadávání

  • Aktuální kultura.

Další informace o podpoře jazyků ve WPF naleznete v příspěvku na blogu o funkcích .NET Framework 4.6.1 .

další podpora vlastních slovníků pro jednotlivé uživatele

V rozhraní .NET Framework 4.6.1 wpF rozpozná vlastní slovníky, které jsou registrovány globálně. Tato funkce je k dispozici kromě možnosti registrace jednotlivých ovládacích prvků.

V předchozích verzích WPF vlastní slovníky nerozpoznaly seznamy vyloučených slov a seznamy automatických oprav. Podporují se ve Windows 8.1 a Windows 10 prostřednictvím souborů, které je možné umístit do adresáře %AppData%\Microsoft\Spelling\<language tag>. Následující pravidla platí pro tyto soubory:

  • Soubory by měly mít přípony .dic (pro přidaná slova), .exc (pro vyloučená slova) nebo .acl (pro automatické opravy).

  • Soubory by měly být UTF-16 LE plaintext, který začíná značkou pořadí bajtů (BOM).

  • Každý řádek by měl obsahovat slovo (v přidaných a vyloučených seznamech slov) nebo pár automatických oprav se slovy oddělenými svislým pruhem (|). (v seznamu automatických oprav slov).

  • Tyto soubory jsou považovány za jen pro čtení a systém je nemění.

Poznámka

Tyto nové formáty souborů nejsou přímo podporovány rozhraními API pro kontrolu pravopisu WPF a vlastní slovníky, které jsou součástí WPF v aplikacích, by měly dál používat soubory .lex.

Ukázky

V úložišti Microsoft/WPF-Samples GitHubu existuje celá řada ukázek WPF. Pomozte nám vylepšit naše ukázky odesláním žádosti o přijetí změn nebo otevřením problému GitHubu.

rozšíření DirectX

WPF obsahuje balíček NuGet, který poskytuje nové implementace D3DImage, které usnadňují spolupráci s obsahem DX10 a Dx11. Kód pro tento balíček byl open source a je k dispozici na GitHubu.

Windows Workflow Foundation: Transakce

Metoda Transaction.EnlistPromotableSinglePhase nyní může použít jiného správce distribuovaných transakcí než MSDTC k řízení transakce. Provedete to zadáním identifikátoru zprostředkovatele transakce GUID do nového Transaction.EnlistPromotableSinglePhase(IPromotableSinglePhaseNotification, Guid) přetížení. Pokud je tato operace úspěšná, existují omezení schopností transakce. Jakmile je zapsán propagátor transakce jiného typu než MSDTC, následující metody způsobí chybu TransactionPromotionException, protože tyto metody vyžadují povýšení na MSDTC.

Jakmile je zaregistrován ne-MSDTC transakční promotér, musí být použit pro budoucí trvalá zapojení s využitím jím definovaných protokolů. K získání Guid promotéra transakce lze použít vlastnost PromoterType. Když je transakce propagována, propagátor transakcí poskytuje Byte pole, které představuje propagovaný token. Aplikace může získat povýšený token pro ne-MSDTC povýšenou transakci metodou GetPromotedToken.

Uživatelé nového Transaction.EnlistPromotableSinglePhase(IPromotableSinglePhaseNotification, Guid) přetížení musí postupovat podle konkrétní posloupnosti volání, aby se operace povýšení úspěšně dokončila. Tato pravidla jsou zdokumentovaná v dokumentaci metody.

Profilování

Profilovací rozhraní API pro neřízené prostředí bylo vylepšeno následujícím způsobem:

  • Lepší podpora přístupu k souborům PDB v rozhraní ICorProfilerInfo7.

    V ASP.NET Core se stává mnohem častější, aby sestavení byla kompilována v paměti pomocí Roslyn. Pro vývojáře, kteří vytvářejí nástroje pro profilaci, to znamená, že soubory PDB, které byly historicky serializovány na disku, již nemusí být přítomny. Profilační nástroje často používají PDB soubory k mapování kódu zpět na zdrojové řádky pro úlohy, jako je pokrytí kódu nebo analýza výkonu po řádcích. Rozhraní ICorProfilerInfo7 nyní obsahuje dvě nové metody, ICorProfilerInfo7::GetInMemorySymbolsLength a ICorProfilerInfo7::ReadInMemorySymbols, které poskytují těmto nástrojům profileru přístup k datům PDB v paměti. Pomocí nových rozhraní API může profiler získat obsah dat PDB v paměti jako pole bajtů a pak ho zpracovat nebo serializovat na disk.

  • Lepší instrumentace s rozhraním ICorProfiler.

    Profilátory, které používají funkci reJit rozhraní API ICorProfiler pro dynamickou instrumentaci, teď můžou upravit některá metadata. Dříve tyto nástroje mohly instrumentovat IL kdykoli, ale metadata se dají upravovat pouze v době načítání modulu. Vzhledem k tomu, že IL odkazuje na metadata, omezuje to druhy instrumentace, které by bylo možné provést. Některé z těchto omezení jsme zrušili přidáním metody ICorProfilerInfo7::ApplyMetaData, která podporuje podmnožinu úprav metadat po načtení modulu, zejména přidáním nových AssemblyRef, TypeRef, TypeSpec, MemberRef, MemberSpeca UserString záznamů. Tato změna umožňuje mnohem širší škálu možností instrumentace.

Soubory PDB pro NGEN (Native Image Generator)

Trasování událostí mezi počítači umožňuje zákazníkům profilovat program na počítači A a poté zobrazit profilovací data s mapováním zdrojových řádků na počítači B. Při použití předchozích verzí rozhraní .NET Framework by uživatel zkopíroval všechny moduly a nativní obrazy z profilovaného počítače do počítače pro analýzu, který obsahuje soubor IL PDB, aby vytvořil mapování zdroje na nativní kód. I když tento proces může fungovat dobře, když jsou soubory relativně malé, například pro telefonní aplikace, mohou být soubory v desktopových systémech velmi velké a vyžadují značné množství času na kopírování.

S NGen PDB může NGen vytvořit PDB, který obsahuje mapování z IL na nativní kód bez závislosti na IL PDB. V našem scénáři trasování událostí napříč počítači je potřeba zkopírovat nativní bitovou kopii PDB generovanou počítačem A do počítače B a použít rozhraní API pro přístup k ladicímu rozhraní ke čtení zdrojovéhoto-IL mapování IL PDB a mapování IL na nativní image PDB. Kombinace obou mapování poskytuje mapování typu source-to-native. Vzhledem k tomu, že soubor PDB nativní bitové kopie je mnohem menší než všechny moduly a nativní bitové kopie, proces kopírování z počítače A do počítače B je mnohem rychlejší.

Novinky v .NET 2015

.NET 2015 zavádí rozhraní .NET Framework 4.6 a .NET Core. Některé nové funkce platí pro obě a další funkce jsou specifické pro rozhraní .NET Framework 4.6 nebo .NET Core.

  • ASP.NET Core

    .NET 2015 zahrnuje ASP.NET Core, což je štíhlá implementace .NET pro vytváření moderních cloudových aplikací. ASP.NET Core je modulární, takže můžete zahrnout jenom ty funkce, které jsou ve vaší aplikaci potřeba. Je možné ji hostovat ve službě IIS nebo v místním hostování ve vlastním procesu a můžete spouštět aplikace s různými verzemi rozhraní .NET Framework na stejném serveru. Zahrnuje nový konfigurační systém prostředí, který je určený pro cloudové nasazení.

    MVC, webové rozhraní API a webové stránky jsou sjednocené do jediné architektury s názvem MVC 6. Aplikace ASP.NET Core můžete vytvářet prostřednictvím nástrojů v sadě Visual Studio 2015 nebo novější. Vaše stávající aplikace budou fungovat na nové rozhraní .NET Framework; Pokud ale chcete vytvořit aplikaci, která používá MVC 6 nebo SignalR 3, musíte použít projektový systém v sadě Visual Studio 2015 nebo novější.

    Informace najdete v tématu ASP.NET Core.

  • Aktualizace ASP.NET

    • rozhraní API založené na úlohách pro asynchronní vyprázdnění odpovědí

      ASP.NET nyní poskytuje jednoduché rozhraní API založené na úlohách pro asynchronní vyčištění odpovědí HttpResponse.FlushAsync, které umožňuje asynchronní zpracování odpovědí prostřednictvím podpory jazyka async/await.

    • vazba modelu podporuje metody vracející úlohy

      V rozhraní .NET Framework 4.5 ASP.NET přidali funkci vazby modelu, která umožňovala rozšiřitelný přístup založený na kódu k datovým operacím založeným na CRUD na stránkách webových formulářů a uživatelských ovládacích prvcích. Systém vazby modelu teď podporuje metody vazby modelu vracející Task. Tato funkce umožňuje vývojářům webových formulářů získat výhody škálovatelnosti asynchronního systému s jednoduchým systémem datových vazeb při použití novějších verzí ORM, včetně Entity Frameworku.

      Asynchronní vazby modelu se řídí nastavením konfigurace aspnet:EnableAsyncModelBinding.

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

      V aplikacích, které cílí na rozhraní .NET Framework 4.6, se ve výchozím nastavení používá true. U aplikací spuštěných v rozhraní .NET Framework 4.6, které cílí na starší verzi rozhraní .NET Framework, je ve výchozím nastavení false. Lze ho povolit nastavením nastavení konfigurace na true.

    • podpora HTTP/2 (Windows 10)

      HTTP/2 je nová verze protokolu HTTP, která poskytuje mnohem lepší využití připojení (méně odezv mezi klientem a serverem), což vede k nižší latenci načítání webových stránek pro uživatele. Webové stránky (na rozdíl od služeb) využívají nejvíce http/2, protože protokol je optimalizovaný pro více artefaktů, které jsou požadovány v rámci jednoho prostředí. Podpora HTTP/2 byla přidána do ASP.NET v rozhraní .NET Framework 4.6. Vzhledem k tomu, že síťové funkce existují ve více vrstvách, byly v systému Windows, ve službě IIS a v ASP.NET vyžadovány nové funkce pro povolení protokolu HTTP/2. Abyste mohli používat protokol HTTP/2 s ASP.NET, musíte být ve Windows 10.

      Protokol HTTP/2 je také podporovaný a ve výchozím nastavení je zapnutý pro aplikace pro Univerzální platformu Windows (UPW) pro Windows 10, které používají rozhraní API System.Net.Http.HttpClient.

      Aby bylo možné použít funkci PUSH_PROMISE v aplikacích ASP.NET, byla do třídy HttpResponse přidána nová metoda se dvěma přetíženími, PushPromise(String) a PushPromise(String, String, NameValueCollection).

      Poznámka

      I když ASP.NET Core podporuje PROTOKOL HTTP/2, podpora funkce PUSH PROMISE ještě nebyla přidána.

      Prohlížeč a webový server (IIS ve Windows) dělají všechno. Nemusíte dělat žádnou těžkou práci pro své uživatele.

      Většina hlavních prohlížečů podporuje http/2, takže je pravděpodobné, že vaši uživatelé budou těžit z podpory HTTP/2, pokud to váš server podporuje.

    • Podpora protokolu vazby tokenů

      Společnost Microsoft a Google spolupracují na novém přístupu k ověřování, kterému se říká protokol vazby tokenů . Premisa je, že ověřovací tokeny (v mezipaměti prohlížeče) mohou být odcizeny a používány zločinci pro přístup k jinak zabezpečeným prostředkům (například k vašemu bankovnímu účtu), aniž by bylo potřeba vaše heslo nebo jakékoli jiné privilegované znalosti. Cílem nového protokolu je tento problém zmírnit.

      Protokol vazby tokenu se ve Windows 10 implementuje jako funkce prohlížeče. ASP.NET se aplikace budou účastnit protokolu, aby ověřovací tokeny byly ověřeny jako legitimní. Implementace klienta a serveru zajišťují kompletní ochranu určenou protokolem.

    • Náhodné hashovací algoritmy pro řetězce

      Rozhraní .NET Framework 4.5 zavedlo algoritmus hašování řetězců s náhodností . Služba ASP.NET ji ale nepodporuje, protože některé funkce ASP.NET závisely na stabilním hashovacím kódu. V rozhraní .NET Framework 4.6 se teď podporují náhodné algoritmy hash řetězců. Pokud chcete tuto funkci povolit, použijte nastavení konfigurace aspnet:UseRandomizedStringHashAlgorithm.

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

    ADO .NET teď podporuje funkci Always Encrypted dostupnou v SQL Serveru 2016. Díky funkci Always Encrypted může SQL Server provádět operace s šifrovanými daty a nejlepší ze všech šifrovacích klíčů se nachází s aplikací v důvěryhodném prostředí zákazníka, a ne na serveru. Funkce Always Encrypted zabezpečuje zákaznická data, takže dbA nemají přístup k datům ve formátu prostého textu. Šifrování a dešifrování dat probíhá transparentně na úrovni ovladače, což minimalizuje změny, které musí být provedeny u stávajících aplikací. Podrobnosti najdete v tématu Always Encrypted (databázový stroj) a Always Encrypted (vývoj pro klienta).

  • 64-bitový kompilátor JIT pro spravovaného kódu

    Rozhraní .NET Framework 4.6 obsahuje novou verzi 64bitového kompilátoru JIT (původně s názvem RyuJIT). Nový 64bitový kompilátor poskytuje významné vylepšení výkonu oproti staršímu 64bitovému kompilátoru JIT. Nový 64bitový kompilátor je povolený pro 64bitové procesy spuštěné nad rozhraním .NET Framework 4.6. Aplikace se spustí v 64bitovém procesu, pokud je zkompilovaná jako 64bitová nebo AnyCPU a běží v 64bitovém operačním systému. I když jsme se postarali o co nejprůhlednější přechod na nový kompilátor, změny chování jsou možné.

    Nový 64bitový kompilátor JIT také zahrnuje hardwarové funkce akcelerace SIMD, které jsou ve spojení s typy s podporou SIMD v oboru názvů System.Numerics, což může přinést dobré vylepšení výkonu.

  • vylepšení zavaděče sestavení

    Zavaděč sestavení teď používá paměť efektivněji tím, že uvolňuje IL sestavení po načtení odpovídajícího obrazu NGEN. Tato změna snižuje virtuální paměť, což je zvláště výhodné pro velké 32bitové aplikace (například Visual Studio) a také šetří fyzickou paměť.

  • Změny základní třídní knihovny

    Do rozhraní .NET Framework 4.6 bylo přidáno mnoho nových rozhraní API, která umožňují klíčové scénáře. Patří mezi ně následující změny a doplňky:

    • implementace IReadOnlyCollection<T>

      Další kolekce implementují IReadOnlyCollection<T>, jako jsou Queue<T> a Stack<T>.

    • CultureInfo.CurrentCulture a CultureInfo.CurrentUICulture

      Vlastnosti CultureInfo.CurrentCulture a CultureInfo.CurrentUICulture jsou nyní pro čtení i zápis, nikoli jen pro čtení. Pokud přiřadíte k těmto vlastnostem nový objekt CultureInfo, změní se také aktuální jazyková verze vlákna definovaná vlastností Thread.CurrentThread.CurrentCulture a aktuální jazykovou verzí vlákna uživatelského rozhraní definovanou vlastnostmi Thread.CurrentThread.CurrentUICulture.

    • Vylepšení uvolňování paměti (GC)

      Třída GC nyní obsahuje metody TryStartNoGCRegion a EndNoGCRegion, které umožňují zabránit uvolňování paměti během provádění kritické sekce.

      Nové přetížení metody GC.Collect(Int32, GCCollectionMode, Boolean, Boolean) umožňuje řídit, zda jsou malá i velká halda objektů vyčištěny a zkompaktovány, nebo pouze vyčištěny.

    • typy s podporou SIMD

      Obor názvů System.Numerics teď obsahuje řadu typů s podporou SIMD, jako jsou Matrix3x2, Matrix4x4, Plane, Quaternion, Vector2, Vector3a Vector4.

      Vzhledem k tomu, že nový 64bitový kompilátor JIT obsahuje také hardwarové funkce akcelerace SIMD, existují obzvláště významná vylepšení výkonu při použití typů s podporou SIMD s novým 64bitovým kompilátorem JIT.

    • aktualizace kryptografie

      Rozhraní API System.Security.Cryptography se aktualizuje na podporu rozhraní API kryptografie CNG systému Windows . Předchozí verze rozhraní .NET Framework se zcela spoléhaly na starší verzi rozhraní API kryptografie systému Windows jako základ pro implementaci System.Security.Cryptography. Měli jsme požadavky na podporu rozhraní CNG API, protože podporuje moderní kryptografické algoritmy, které jsou důležité pro určité kategorie aplikací.

      Rozhraní .NET Framework 4.6 obsahuje následující nová vylepšení pro podporu kryptografických rozhraní API CNG systému Windows:

      • Sada rozšiřujících metod pro certifikáty X509, System.Security.Cryptography.X509Certificates.RSACertificateExtensions.GetRSAPublicKey(System.Security.Cryptography.X509Certificates.X509Certificate2) a System.Security.Cryptography.X509Certificates.RSACertificateExtensions.GetRSAPrivateKey(System.Security.Cryptography.X509Certificates.X509Certificate2), které vracejí implementaci založenou na CNG, nikoli implementaci založenou na CAPI, pokud je to možné. (Některé chytré karty a podobně stále vyžadují CAPI a rozhraní API zpracovávají záložní režim).

      • Třída System.Security.Cryptography.RSACng, která poskytuje implementaci CNG algoritmu RSA.

      • Vylepšení rozhraní RSA API tak, aby běžné akce už nevyžadovaly typování. Například šifrování dat pomocí objektu X509Certificate2 vyžaduje kód podobný následujícímu kódu v předchozích verzích rozhraní .NET Framework.

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

        Kód, který v rozhraní .NET Framework 4.6 využívá nová kryptografická rozhraní API, lze přepsat následujícím způsobem, aby se zabránilo přetypování.

        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);
        
    • Podpora převodu kalendářních dat a časů do nebo z unixového času

      Do struktury DateTimeOffset byly přidány následující nové metody, které podporují převod hodnot data a času do nebo z unixového času:

    • přepínače kompatibility

      Třída AppContext přidává novou funkci kompatibility, která umožňuje autorům knihoven poskytovat jednotný mechanismus odhlášení pro nové funkce pro své uživatele. Vytvoří volně propojený kontrakt mezi součástmi za účelem sdělení žádosti o odhlášení. Tato funkce je obvykle důležitá, když dojde ke změně stávajících funkcí. Naopak pro nové funkce už existuje implicitní výslovný souhlas.

      Pomocí AppContextknihovny definují a zveřejňují přepínače kompatibility, zatímco kód, který na nich závisí, může tyto přepínače nastavit tak, aby ovlivnily chování knihovny. Ve výchozím nastavení poskytují knihovny nové funkce a mění je pouze (tj. poskytují předchozí funkce), pokud je přepínač nastavený.

      Aplikace (nebo knihovna) může deklarovat hodnotu přepínače (což je vždy hodnota Boolean), kterou definuje závislá knihovna. Přepínač je vždy implicitně false. Nastavení přepínače na true ho povolí. Explicitní nastavení přepínače na false poskytuje nové chování.

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

      Knihovna musí zkontrolovat, jestli uživatel deklaroval hodnotu přepínače, a pak na ni odpovídajícím způsobem reagovat.

      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
      }
      

      Pro přepínače je výhodné používat konzistentní formát, protože jde o formální kontrakt vystavený knihovnou. Následují dva běžné formáty.

      • přepínač.obor názvů.název přepínače

      • přepínač.knihovna.název přepínače

    • Změny asynchronního vzoru založeného na úlohách (TAP)

      Aplikace, které pracují s rozhraním .NET Framework 4.6, objekty Task a Task<TResult> dědí kulturu a uživatelské rozhraní volajícího vlákna. Chování aplikací, které cílí na předchozí verze rozhraní .NET Framework nebo které necílí na konkrétní verzi rozhraní .NET Framework, nemá vliv. Další informace najdete v části "Kulturní a asynchronní operace založené na úlohách" tématu třídy CultureInfo.

      Třída System.Threading.AsyncLocal<T> umožňuje znázorňovat okolní data, která jsou místní pro daný asynchronní tok řízení, jako je například async metoda. Dá se použít k zachování dat napříč vlákny. Můžete také definovat metodu zpětného volání, která je upozorněna vždy, když se okamžitá data změní buď proto, že byla AsyncLocal<T>.Value vlastnost explicitně změněna, nebo protože vlákno narazilo na kontextový přechod.

      Do asynchronního vzoru založeného na úlohách (TAP) byly přidány tři pomocné metody, Task.CompletedTask, Task.FromCanceleda Task.FromException, které umožňují vrátit dokončené úkoly ve specifickém stavu.

      Třída NamedPipeClientStream nyní podporuje asynchronní komunikaci s novou ConnectAsync. metoda.

    • EventSource teď podporuje zápis do protokolu událostí

      Nyní můžete pomocí třídy EventSource zaznamenávat administrativní nebo provozní zprávy do protokolu událostí, a to kromě existujících relací ETW vytvořených na počítači. V minulosti jste museli pro tuto funkci použít balíček NuGet Microsoft.Diagnostics.Tracing.EventSource. Tato funkce je teď integrovaná v rozhraní .NET Framework 4.6.

      Balíček NuGet i rozhraní .NET Framework 4.6 byly aktualizovány následujícími funkcemi:

      • dynamické události

        Umožňuje události definované "za běhu" bez vytváření metod událostí.

      • bohaté obsahy

        Umožňuje předat speciálně přiřazené třídy a pole a také primitivní typy jako datovou část.

      • sledování aktivit

        Způsobí, že události Start a Stop označí události mezi nimi pomocí ID, které představuje všechny aktuálně aktivní aktivity.

      Pro podporu těchto funkcí byla přetížená metoda Write přidána do třídy EventSource.

  • Windows Presentation Foundation (WPF)

    • vylepšení HDPI

      Podpora HDPI ve WPF je nyní lepší v rozhraní .NET Framework 4.6. Byly provedeny změny rozložení zaokrouhlení, aby se snížily výskyty výřezů v ovládacích prvcích s ohraničením. Ve výchozím nastavení je tato funkce povolená pouze v případě, že je vaše TargetFrameworkAttribute nastavená na rozhraní .NET Framework 4.6. Aplikace, které cílí na starší verze rozhraní, ale jsou spuštěné na rozhraní .NET Framework 4.6, mohou zapnout nové chování přidáním následujícího řádku do oddílu <runtime> souboru app.config:

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

      Okna WPF, která se rozprostírá na více monitorech s různými nastaveními DPI (nastavení s více DPI), se teď zcela vykreslují bez začerněných oblastí. Toto chování můžete zrušit přidáním následujícího řádku do části <appSettings> souboru app.config a zakázat toto nové chování:

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

      Podpora automatického načítání pravého kurzoru na základě nastavení DPI byla přidána do System.Windows.Input.Cursor.

    • Touch je lepší

      Zákaznická hlášení na Connect o nepředvídatelném chování způsobeném dotykem byla vyřešena v rozhraní .NET Framework 4.6. Prahová hodnota dvojitého klepnutí pro aplikace pro Windows Store a aplikace WPF je teď stejná ve Windows 8.1 a novějších verzích.

    • Podpora transparentního podřízeného okna

      WPF v rozhraní .NET Framework 4.6 podporuje průhledná podřízená okna ve Windows 8.1 a novějších verzích. Díky tomu můžete v oknech nejvyšší úrovně vytvářet nepravoúhlá a průhledná podřízená okna. Tuto funkci můžete povolit nastavením vlastnosti HwndSourceParameters.UsesPerPixelTransparency na true.

  • Windows Communication Foundation (WCF)

    • podpora protokolu SSL

      WCF teď podporuje protokoly SSL verze TLS 1.1 a TLS 1.2, kromě SSL 3.0 a TLS 1.0 při použití netTcp s přenosovým zabezpečením a ověřováním klientů. Nyní je možné vybrat protokol, který se má použít, nebo zakázat staré méně zabezpečené protokoly. Můžete to provést buď nastavením vlastnosti SslProtocols, nebo přidáním následujícího příkazu do konfiguračního souboru.

      <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>
      
    • Odesílání zpráv pomocí různých připojení HTTP

      WCF teď umožňuje uživatelům zajistit, aby se určité zprávy odesílaly pomocí různých podkladových připojení HTTP. Můžete to udělat dvěma způsoby:

      • Použití předpony názvu skupiny připojení

        Uživatelé mohou zadat řetězec, který WCF použije jako předponu pro název skupiny připojení. Dvě zprávy s různými předponami se odesílají pomocí různých podkladových připojení HTTP. Předponu nastavíte přidáním páru klíč/hodnota do vlastnosti Message.Properties zprávy. Klíč je HttpTransportConnectionGroupNamePrefix; hodnota je požadovaná předpona.

      • Použití různých kanálových továren

        Uživatelé mohou také povolit funkci, která zajišťuje, že zprávy odeslané pomocí kanálů vytvořených různými továrnami kanálů budou používat různá základní připojení HTTP. Pokud chcete tuto funkci povolit, musí uživatelé nastavit následující appSetting na true:

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

    Nyní můžete zadat počet sekund, po které bude služba pracovního postupu uchovávat požadavek na zpracování mimo pořadí, pokud je před vypršením časového limitu požadavku nevyřízená záložka "bez protokolu". Záložka bez protokolu je záložka, která nesouvisí s nevyřízenými aktivitami přijímání. Některé aktivity vytvářejí v rámci své implementace záložky bez protokolu, takže nemusí být zřejmé, že záložka bez protokolu existuje. Patří sem State a Pick. Pokud tedy máte službu pracovního postupu implementovanou se stavovým počítačem nebo obsahující aktivitou Pick, pravděpodobně budete mít záložky bez protokolu. Interval zadáte tak, že do oddílu appSettings souboru app.config přidáte řádek podobný následujícímu:

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

    Výchozí hodnota je 60 sekund. Pokud je value nastavená na hodnotu 0, požadavky mimo objednávku se okamžitě zamítnou chybou s textem, který vypadá takto:

    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.
    

    Jedná se o stejnou zprávu, kterou obdržíte, pokud je přijata zpráva o operaci mimo pořadí a neexistují žádné záložky, které nejsou v rámci protokolu.

    Pokud je hodnota prvku FilterResumeTimeoutInSeconds nenulová, existují záložky bez protokolu a vyprší časový limit, operace selže se zprávou časového limitu.

  • Transakce

    Nyní můžete zahrnout identifikátor distribuované transakce pro transakci, která způsobila vyvolání výjimky odvozené z TransactionException. Uděláte to tak, že do oddílu appSettings souboru app.config přidáte následující klíč:

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

    Výchozí hodnota je false.

  • Síťování

    • opětovné použití soketů

      Windows 10 obsahuje nový síťový algoritmus s vysokou škálovatelností, který lépe využívá prostředky počítače opětovným použitím místních portů pro odchozí připojení TCP. Rozhraní .NET Framework 4.6 podporuje nový algoritmus, který umožňuje aplikacím .NET využívat nové chování. V předchozích verzích Windows došlo k umělému souběžnému limitu připojení (obvykle 16 384, výchozí velikost dynamického rozsahu portů), který by mohl omezit škálovatelnost služby tím, že při zatížení způsobuje vyčerpání portů.

      V rozhraní .NET Framework 4.6 byly přidány dvě rozhraní API, která umožňují opakované použití portů, což efektivně odebere limit 64 kB pro souběžná připojení:

      Ve výchozím nastavení je vlastnost ServicePointManager.ReusePortfalse, pokud není HWRPortReuseOnSocketBind hodnota klíče registru HKLM\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 nastavena na 0x1. Chcete-li povolit opakované použití místního portu u připojení HTTP, nastavte vlastnost ServicePointManager.ReusePort na true. To způsobí, že všechna odchozí připojení soketu TCP z HttpClient a HttpWebRequest budou používat novou možnost soketu Windows 10, SO_REUSE_UNICASTPORT, která umožňuje opakované použití místního portu.

      Vývojáři, kteří zapisují aplikaci jen pro sokety, můžou při volání metody, jako je Socket.SetSocketOption, určit možnost System.Net.Sockets.SocketOptionName, aby odchozí sokety během vazby opakovaně používaly místní porty.

    • Podpora mezinárodních názvů domén a PunyCode

      Do třídy Uri byla přidána nová vlastnost IdnHost, která lépe podporuje mezinárodní názvy domén a PunyCode.

  • Změna velikosti v ovládacích prvcích Windows Forms.

    Tato funkce byla rozšířena v rozhraní .NET Framework 4.6 tak, aby zahrnovala DomainUpDown, NumericUpDown, DataGridViewComboBoxColumn, typy DataGridViewColumn a ToolStripSplitButton a obdélník určený vlastností Bounds použitý při kreslení UITypeEditor.

    Toto je funkce výslovného souhlasu. Pokud ho chcete povolit, nastavte prvek EnableWindowsFormsHighDpiAutoResizing na true v souboru konfigurace aplikace (app.config):

    <appSettings>
        <add key="EnableWindowsFormsHighDpiAutoResizing" value="true" />
    </appSettings>
    
  • Podpora kódování znakových stránek

    .NET Core primárně podporuje kódování Unicode a ve výchozím nastavení poskytuje omezenou podporu kódování znakových stránek. Podporu kódování kódových stránek, které jsou dostupné v rozhraní .NET Framework, ale nepodporuje se v .NET Core, můžete přidat tak, že zaregistrujete kódování znakových stránek pomocí metody Encoding.RegisterProvider. Další informace najdete v tématu System.Text.CodePagesEncodingProvider.

  • .NET Native

Aplikace univerzální platformy Windows (UPW), které jsou napsané v jazyce C# nebo Visual Basic, můžou využívat novou technologii, která kompiluje aplikace do nativního kódu, a ne il. Tato technologie vytváří aplikace, které mají rychlejší dobu spouštění a provádění. Další informace najdete v tématu Kompilace aplikací pomocí rozhraní .NET Native. Přehled rozhraní .NET Native, který zkoumá, jak se liší od kompilace JIT a NGEN a co to znamená pro váš kód, najdete v tématu .NET Native a kompilace.

Aplikace se ve výchozím nastavení kompilují do nativního kódu, když je zkompilujete pomocí sady Visual Studio 2015 nebo novější. Další informace najdete v tématu Začínáme s rozhraním .NET Native.

Pro podporu ladění aplikací .NET Native byla do nespravovaného rozhraní API pro ladění přidána řada nových rozhraní a výčtů. Pro více informací se podívejte do tématu ladění (referenční dokumentace nespravovaného rozhraní API).

  • Balíčky open-source rozhraní .NET Framework

    Balíčky .NET Core, jako jsou neměnné kolekce, rozhraní API SIMDa síťová rozhraní API, jako jsou ty, které se nacházejí v oboru názvů System.Net.Http, jsou nyní k dispozici jako opensourcové balíčky na GitHubu . Pokud chcete získat přístup k kódu, podívejte se na .NET na GitHubu. Další informace a jak přispívat k těmto balíčkům najdete v tématu Úvod k .NET, domovské stránce .NET na GitHubu.

Novinky v rozhraní .NET Framework 4.5.2

  • Nová rozhraní API pro ASP.NET aplikace Nové metody HttpResponse.AddOnSendingHeaders a HttpResponseBase.AddOnSendingHeaders umožňují kontrolovat a upravovat HTTP hlavičky odpovědí a stavový kód odpovědi, zatímco se odpověď postupně odesílá do klientské aplikace. Zvažte použití těchto metod místo událostí PreSendRequestHeaders a PreSendRequestContent; jsou efektivnější a spolehlivější.

    Metoda HostingEnvironment.QueueBackgroundWorkItem umožňuje naplánovat malé pracovní položky na pozadí. ASP.NET sleduje tyto položky a brání službě IIS v náhlém ukončení pracovního procesu, dokud se nedokončily všechny pracovní položky na pozadí. Tuto metodu nelze volat mimo doménu spravované aplikace ASP.NET.

    Nové HttpResponse.HeadersWritten a HttpResponseBase.HeadersWritten vlastnosti vrací logické hodnoty, které označují, jestli byly hlavičky odpovědi zapsány. Pomocí těchto vlastností se můžete ujistit, že volání rozhraní API jako HttpResponse.StatusCode (které vyvolávají výjimky, pokud byly hlavičky zapsány) budou úspěšná.

  • Změna velikosti ovládacích prvků ve Windows Forms Tato funkce byla rozšířena. Teď můžete pomocí nastavení DPI systému změnit velikost součástí následujících dalších ovládacích prvků (například šipka rozevíracího seznamu v polích se seznamem):

    Toto je funkce výslovného souhlasu. Pokud ho chcete povolit, nastavte prvek EnableWindowsFormsHighDpiAutoResizing na true v souboru konfigurace aplikace (app.config):

    <appSettings>
        <add key="EnableWindowsFormsHighDpiAutoResizing" value="true" />
    </appSettings>
    
  • Nová funkce pracovního postupu Správce prostředků, který používá metodu EnlistPromotableSinglePhase (a proto implementuje rozhraní IPromotableSinglePhaseNotification), může k vyžádání následujících požadavků použít novou metodu Transaction.PromoteAndEnlistDurable:

    To je možné provést ve stejné doméně aplikace a nevyžaduje další nespravovaný kód pro interakci s MSDTC k provedení povýšení. Novou metodu lze volat pouze tehdy, když existuje nevyřízené volání z System.Transactions na IPromotableSinglePhaseNotificationPromote metodu implementovanou povoleným zařazením.

  • Vylepšení profilace Následující nová nespravovaná rozhraní API pro profilaci poskytují robustnější profilaci:

    Předchozí ICorProfiler implementace podporovaly opožděné načítání závislých sestavení. Nová rozhraní API pro profilaci vyžadují, aby závislá sestavení vložená profilerem byla načtena okamžitě, místo aby se načetla po úplné inicializaci aplikace. Tato změna nemá vliv na uživatele stávajících rozhraní API ICorProfiler.

  • Vylepšení ladění. Následující nová nespravovaná ladicí rozhraní API poskytují lepší integraci s profilerem. Při ladění paměťových výpisů teď můžete přistupovat k metadatům vloženým profilerem i k místním proměnným a kódu vytvořeným požadavky kompilátoru ReJIT.

  • Změny trasování událostí .NET Framework 4.5.2 umožňuje trasování aktivit založených na událostech systému Windows (ETW) mimo proces pro větší plochu. To umožňuje dodavatelům pokročilé správy napájení (APM) poskytovat efektivní nástroje, které přesně sledují náklady na jednotlivé požadavky a aktivity, které procházejí vlákny. Tyto události jsou vyvolány pouze tehdy, když je povolí ETW kontrolery; změny proto nemají vliv na dříve napsaný kód pro ETW ani na kód, který běží se zakázaným ETW.

  • Podpora transakce a její převod na trvalé zařazení

    Transaction.PromoteAndEnlistDurable je nové rozhraní API přidané do rozhraní .NET Framework 4.5.2 a 4.6:

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

    Metodu může použít zařazovací proces, který byl dříve vytvořen ve Transaction.EnlistPromotableSinglePhase v reakci na metodu ITransactionPromoter.Promote. Žádá System.Transactions o povýšení transakce na MSDTC transakci a o "převod" povýšitelného zařazení na trvalé zařazení. Jakmile se tato metoda úspěšně dokončí, rozhraní IPromotableSinglePhaseNotification již nebude odkazováno na System.Transactionsa veškerá budoucí oznámení dorazí na poskytnuté ISinglePhaseNotification rozhraní. Dotyčné přihlášení musí fungovat jako trvalé přihlášení, které podporuje protokolování transakcí a obnovení. Podrobnosti najdete v Transaction.EnlistDurable. Kromě toho musí nábor podporovat ISinglePhaseNotification. Tato metoda může při zpracování volání ITransactionPromoter.Promote volána pouze. Pokud tomu tak není, vyvolá se výjimka TransactionException.

Novinky v rozhraní .NET Framework 4.5.1

Aktualizace z dubna 2014:

  • Visual Studio 2013 Update 2 obsahuje aktualizace šablon knihovny přenosných tříd, které podporují tyto scénáře:

    • Rozhraní API prostředí Windows Runtime můžete použít v přenosných knihovnách, které cílí na Windows 8.1, Windows Phone 8.1 a Windows Phone Silverlight 8.1.

    • Xaml (Typy Windows.UI.XAML) můžete zahrnout do přenosných knihoven, když cílíte na Windows 8.1 nebo Windows Phone 8.1. Podporují se následující šablony XAML: Prázdná stránka, Slovník prostředků, Ovládací prvek s šablonou a Uživatelský ovládací prvek.

    • Můžete vytvořit přenosnou komponentu prostředí Windows Runtime (soubor .winmd) pro použití v aplikacích pro Store, které cílí na Windows 8.1 a Windows Phone 8.1.

    • Můžete změnit cílení knihovny tříd pro Windows Store nebo Windows Phone Store, jako je přenosná knihovna tříd.

    Další informace o těchto změnách naleznete v tématu Portable Class Library.

  • Sada obsahu rozhraní .NET Framework teď obsahuje dokumentaci pro .NET Native, což je technologie předkompilace pro sestavování a nasazování aplikací pro Windows. .NET Native kompiluje aplikace přímo do nativního kódu, nikoli do zprostředkujícího jazyka (IL), aby se zlepšil výkon. Podrobnosti najdete v tématu Kompilace aplikací pomocí rozhraní .NET Native.

  • Referenční rozhraní .NET Framework poskytuje nové prostředí procházení a vylepšené funkce. Teď můžete procházet zdrojový kód rozhraní .NET Framework online, stáhnout referenční pro zobrazení offline a procházet zdroje (včetně oprav a aktualizací) během ladění. Další informace najdete v blogovém příspěvku Nový vzhled referenčního zdroje .NET.

Mezi nové funkce a vylepšení základních tříd v rozhraní .NET Framework 4.5.1 patří:

  • Automatické přesměrování vazby pro sestavení. Počínaje sadou Visual Studio 2013 můžete při kompilaci aplikace, která cílí na rozhraní .NET Framework 4.5.1, přidat přesměrování vazby do konfiguračního souboru aplikace, pokud vaše aplikace nebo její komponenty odkazují na více verzí stejného sestavení. Tuto funkci můžete také povolit pro projekty, které cílí na starší verze rozhraní .NET Framework. Další informace naleznete v tématu Návod: Povolení a vypnutí automatického přesměrování vazby.

  • Schopnost shromažďovat diagnostické informace, které vývojářům pomáhají zlepšit výkon serverových a cloudových aplikací. Další informace naleznete v metodách WriteEventWithRelatedActivityId a WriteEventWithRelatedActivityIdCore ve třídě EventSource.

  • Schopnost explicitně zkomprimovat velkou haldu objektu (LOH) během uvolňování paměti. Další informace najdete ve vlastnosti GCSettings.LargeObjectHeapCompactionMode.

  • Další vylepšení výkonu, jako je pozastavení aplikace ASP.NET, optimalizace při spuštění (JIT) s více jádry a rychlejší spuštění aplikace po aktualizaci rozhraní .NET Framework. Podrobnosti najdete v oznámení rozhraní .NET Framework 4.5.1 a v blogovém příspěvku o pozastavení aplikace ASP.NET .

Mezi vylepšení modelu Windows Forms patří:

  • Změna velikosti v ovládacích prvcích Windows Forms Nastavení dpi systému můžete použít ke změně velikosti součástí ovládacích prvků (například ikon, které se zobrazují v mřížce vlastností), a to tak, že se přihlásíte k položce v konfiguračním souboru aplikace (app.config) pro vaši aplikaci. Tato funkce je aktuálně podporovaná v následujících ovládacích prvcích Windows Forms:

    Pokud chcete tuto funkci povolit, přidejte nový element <appSettings> do konfiguračního souboru (app.config) a nastavte element EnableWindowsFormsHighDpiAutoResizing na true:

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

Mezi vylepšení při ladění aplikací .NET Framework ve Visual Studio 2013 patří:

  • Vrácené hodnoty v ladicím programu sady Visual Studio. Při ladění spravované aplikace v sadě Visual Studio 2013 se v okně Autos zobrazí návratové typy a hodnoty pro metody. Tyto informace jsou k dispozici pro desktopové aplikace, Windows Store a Windows Phone. Další informace naleznete v tématu Kontrola návratových hodnot volání metody.

  • Upravit a pokračovat pro 64bitové aplikace Visual Studio 2013 podporuje funkci Upravit a pokračovat pro 64bitové spravované aplikace pro stolní počítače, Windows Store a Windows Phone. Stávající omezení zůstávají platná pro 32bitové i 64bitové aplikace (viz poslední část článku podporované změny kódu (C#)).

  • Ladění s podporou asynchronních dat. Aby bylo snazší ladit asynchronní aplikace v sadě Visual Studio 2013, zásobník volání skryje infrastrukturu kódu, kterou poskytují překladače pro podporu asynchronního programování, a také propojí logické nadřazené rámce, takže můžete jasněji sledovat logické provádění programu. Okno Úkoly nahrazuje okno Paralelní úkoly a zobrazuje úkoly související s konkrétní zarážkou a také všechny další úkoly, které jsou aktuálně aktivní nebo naplánované v aplikaci. O této funkci si můžete přečíst v oznámení rozhraní .NET Framework 4.5.1, v části o ladění s podporou asynchronního zpracování.

  • Lepší podpora výjimek pro komponenty prostředí Windows Runtime Ve Windows 8.1 výjimky, které vznikají z aplikací pro Windows Store, uchovávají informace o chybě, která výjimku způsobila, i přes hranice jazyka. O této funkci si můžete přečíst v části Vývoj aplikací pro Windows Store v oznámení .NET Framework 4.5.1.

Od sady Visual Studio 2013 můžete k optimalizaci aplikací pro Windows 8.x Store a desktopových aplikací použít nástroj pro optimalizaci s asistencí spravovaného profilu (Mpgo.exe).

Nové funkce v ASP.NET 4.5.1 najdete v poznámkách k verzi ASP.NET a Webové nástroje pro Visual Studio 2013.

Novinky v rozhraní .NET Framework 4.5

Základní třídy

  • Schopnost snížit restartování systému detekcí a zavřením aplikací rozhraní .NET Framework 4 během nasazování Viz Snížení počtu restartování systému během instalace rozhraní .NET Framework 4.5.

  • Podpora polí, která jsou větší než 2 gigabajty (GB) na 64bitových platformách. Tuto funkci lze povolit v konfiguračním souboru aplikace. Viz <gcAllowVeryLargeObjects> element, který také uvádí další omezení velikosti objektu a velikosti pole.

  • Lepší výkon prostřednictvím správy paměti na pozadí pro servery. Při použití správy paměti na serveru v .NET Framework 4.5 je správa paměti na pozadí automaticky povolena. Viz část zaměřenou na uvolňování paměti serveru na pozadí v tématu Základy uvolňování paměti.

  • Kompilace JIT (just-in-time) na pozadí, která je volitelně k dispozici na vícejádrových procesorech za účelem zlepšení výkonu aplikace. Viz ProfileOptimization.

  • Schopnost omezit, jak dlouho se modul regulárních výrazů pokusí vyřešit regulární výraz před uplynutím časového limitu. Podívejte se na vlastnost Regex.MatchTimeout.

  • Možnost definovat výchozí kulturu aplikační domény Podívejte se na třídu CultureInfo.

  • Podpora konzoly pro kódování Unicode (UTF-16). Podívejte se na třídu Console.

  • Podpora verzování dat pro řazení a porovnávání kulturních řetězců. Podívejte se na třídu SortVersion.

  • Lepší výkon při získávání prostředků. Viz Balíček a nasazení prostředků.

  • Vylepšení komprese zip pro zmenšení velikosti komprimovaného souboru. Podívejte se na názvový prostor System.IO.Compression.

  • Možnost přizpůsobit kontext reflexe pro přepsání výchozího chování reflexe prostřednictvím třídy CustomReflectionContext.

  • Podpora pro verzi 2008 standardu Internationalized Domain Names in Applications (IDNA) při použití třídy System.Globalization.IdnMapping v systému Windows 8.

  • Předání porovnávání řetězců operačnímu systému, který implementuje Unicode 6.0, pokud se ve Windows 8 používá rozhraní .NET Framework. Při spouštění na jiných platformách obsahuje rozhraní .NET Framework vlastní data porovnání řetězců, která implementuje Unicode 5.x. Podívejte se na třídu String a na část Poznámky třídy SortVersion.

  • Schopnost vypočítat hash kódy pro řetězce v rámci každé aplikační domény. Viz. <UseRandomizedStringHashAlgorithm> Element.

  • Podpora reflexe typů je rozdělena mezi třídy Type a TypeInfo. Viz Reflexe v rozhraní .NET Framework pro aplikace pro Windows Store.

Rozhraní pro řízenou rozšiřitelnost (Managed Extensibility Framework, MEF)

V rozhraní .NET Framework 4.5 poskytuje rozhraní MEF (Managed Extensibility Framework) následující nové funkce:

  • Podpora obecných typů

  • Programovací model založený na konvencích, který umožňuje vytvářet části založené na konvencích vytváření názvů, nikoli na atributech.

  • Více oborů.

  • Podmnožinu MEF, kterou můžete použít při vytváření aplikací pro Windows 8.x Store. Tato podmnožina je k dispozici jako balíček ke stažení z galerie NuGet. Pro instalaci balíčku otevřete projekt v sadě Visual Studio, v nabídce Project zvolte Spravovat balíčky NuGet a vyhledejte online balíček Microsoft.Composition.

Další informace naleznete v části Managed Extensibility Framework (MEF).

Asynchronní operace se soubory

V rozhraní .NET Framework 4.5 byly do jazyků C# a Visual Basic přidány nové asynchronní funkce. Tyto funkce přidávají model založený na úlohách pro provádění asynchronních operací. Pokud chcete tento nový model použít, použijte asynchronní metody ve třídách vstupně-výstupních operací. Viz vstupně-výstupní asynchronní souborové.

Nářadí

V rozhraní .NET Framework 4.5 umožňuje Generátor souborů prostředků (Resgen.exe) vytvořit soubor .resw pro použití v aplikacích pro Windows 8.x Store ze souboru .resources vloženého v sestavení rozhraní .NET Framework. Další informace najdete v tématu Resgen.exe (Generátor souborů prostředků).

Optimalizace spravovaného profilu s asistencí (Mpgo.exe) umožňuje zlepšit dobu spuštění aplikace, využití paměti (velikost pracovní sady) a propustnost optimalizací sestavení nativních imagí. Nástroj příkazového řádku generuje data profilu pro sestavení aplikací nativního obrazu. Viz Mpgo.exe (nástroj pro optimalizaci s asistencí spravovaného profilu). Počínaje sadou Visual Studio 2013 můžete pomocí Mpgo.exe optimalizovat aplikace pro Windows 8.x Store i desktopové aplikace.

Paralelní výpočty

.NET Framework 4.5 poskytuje několik nových funkcí a vylepšení pro paralelní výpočty. Patří mezi ně vyšší výkon, zvýšená kontrola, vylepšená podpora asynchronního programování, nová knihovna toku dat a vylepšená podpora paralelního ladění a analýzy výkonu. Podívejte se na položku Co je nového pro paralelismus v rozhraní .NET Framework 4.5 v blogu Paralelní programování s .NET.

Web

ASP.NET 4.5 a 4.5.1 přidávají vazbu modelu pro Web Forms, podporu protokolu WebSocket, asynchronní obslužné rutiny, vylepšení výkonu a mnoho dalších funkcí. Další informace najdete v následujících zdrojích informací:

Síťové

.NET Framework 4.5 poskytuje nové programovací rozhraní pro aplikace HTTP. Další informace najdete v nových jmenných prostorech System.Net.Http a System.Net.Http.Headers.

Podpora je také součástí nového programovacího rozhraní pro příjem a interakci s připojením WebSocket pomocí existujících HttpListener a souvisejících tříd. Další informace najdete v novém oboru názvů System.Net.WebSockets a třídě HttpListener.

Kromě toho rozhraní .NET Framework 4.5 zahrnuje následující vylepšení sítě:

  • Podpora identifikátoru URI kompatibilního s RFC. Další informace viz Uri a související třídy.

  • Podpora parsování internationalizovaného názvu domény (IDN). Další informace viz Uri a související třídy.

  • Podpora internationalizace e-mailových adres (EAI). Pro více informací viz System.Net.Mail jmenný prostor.

  • Vylepšili jsme podporu protokolu IPv6. Další informace najdete v jmenném prostoru System.Net.NetworkInformation.

  • Podpora duálního režimu soketů. Další informace najdete ve třídách Socket a TcpListener.

Windows Presentation Foundation (WPF)

V rozhraní .NET Framework 4.5 obsahuje Windows Presentation Foundation (WPF) změny a vylepšení v následujících oblastech:

  • Nový ovládací prvek Ribbon, který umožňuje implementovat uživatelské rozhraní pásu karet, které obsahuje panel nástrojů Rychlý přístup, nabídku aplikace a karty.

  • Nové rozhraní INotifyDataErrorInfo, které podporuje synchronní a asynchronní ověřování dat.

  • Nové funkce pro třídy VirtualizingPanel a Dispatcher

  • Lepší výkon při zobrazení velkých sad seskupených dat a přístup k kolekcím na vláknech bez uživatelského rozhraní.

  • Datová vazba na statické vlastnosti, datová vazba na vlastní typy, které implementují rozhraní ICustomTypeProvider, a získání informací o datové vazbě z výrazu vazby.

  • Změna umístění dat při změně hodnot (živé tvarování)

  • Možnost zkontrolovat, jestli je odpojený kontext dat pro kontejner položek.

  • Možnost nastavit dobu, která by měla uplynout mezi změnami vlastností a aktualizacemi zdroje dat.

  • Vylepšená podpora pro implementaci slabých vzorů událostí Události teď také můžou přijímat rozšíření značek.

Windows Communication Foundation (WCF)

V rozhraní .NET Framework 4.5 byly přidány následující funkce, které usnadňují psaní a údržbu aplikací WCF (Windows Communication Foundation):

  • Zjednodušení vygenerovaných konfiguračních souborů.

  • Podpora vývoje na základě smlouvy.

  • Snadnější konfigurace režimu kompatibility ASP.NET

  • Změní výchozí hodnoty vlastnosti přenosu, aby se snížila pravděpodobnost, že je budete muset nastavit.

  • Aktualizuje XmlDictionaryReaderQuotas třídu, aby se snížila pravděpodobnost, že budete muset ručně nakonfigurovat kvóty pro čtečky slovníku XML.

  • Ověřování konfiguračních souborů WCF v sadě Visual Studio v rámci procesu sestavení, abyste před spuštěním aplikace mohli detekovat chyby konfigurace.

  • Nová podpora asynchronního streamování

  • Nové mapování protokolu HTTPS, které usnadňuje zveřejnění koncového bodu přes HTTPS pomocí internetové informační služby (IIS).

  • Možnost generovat metadata v jednom dokumentu WSDL připojením ?singleWSDL k adrese URL služby.

  • Podpora protokolu Websocket umožňuje skutečnou obousměrnou komunikaci přes porty 80 a 443 s charakteristikou výkonu podobnou přenosu TCP.

  • Podpora konfigurace služeb v kódu

  • Tooltipy editoru XML

  • ChannelFactory podpora ukládání do mezipaměti.

  • Podpora komprese binárního kodéru

  • Podpora přenosu UDP, který vývojářům umožňuje psát služby, které používají "fire and forget" zasílání zpráv. Klient odešle do služby zprávu a neočekává od služby žádnou odpověď.

  • Možnost podporovat více režimů ověřování na jednom koncovém bodu WCF při použití přenosu HTTP a zabezpečení transportu.

  • Podpora služeb WCF, které používají mezinárodní názvy domén (IDN).

Další informace naleznete v tématu Co je nového ve Windows Communication Foundation.

Windows Workflow Foundation (WF)

V rozhraní .NET Framework 4.5 bylo do windows Workflow Foundation (WF) přidáno několik nových funkcí, mezi které patří:

  • Pracovní postupy stavového počítače, které byly poprvé zavedeny jako součást rozhraní .NET Framework 4.0.1 (.NET Framework 4 Platform Update 1). Tato aktualizace zahrnovala několik nových tříd a aktivit, které vývojářům umožnily vytvářet pracovní postupy stavových počítačů. Tyto třídy a aktivity byly aktualizovány pro rozhraní .NET Framework 4.5, aby zahrnovaly:

    • Možnost nastavit zarážky u stavů.

    • Možnost kopírovat a vkládat přechody v návrháři pracovního postupu.

    • Podpora návrháře pro vytvoření sdíleného přechodu triggeru

    • Aktivity pro vytváření pracovních postupů stavových počítačů, včetně: StateMachine, Statea Transition.

  • Vylepšené funkce Návrháře pracovních postupů, například následující:

    • Vylepšené možnosti vyhledávání pracovních postupů v sadě Visual Studio, včetně Quick Find a Find in Files.

    • Možnost automatického vytvoření aktivity sekvence při přidání druhé podřízené aktivity do kontejnerové aktivity a zahrnutí obou aktivit do aktivity sekvence.

    • Podpora posouvání, která umožňuje změnit viditelnou část pracovního postupu bez použití posuvníků.

    • Nové zobrazení osnovy dokumentu , které zobrazuje součásti pracovního postupu v zobrazení osnovy ve stylu stromu a umožňuje vybrat komponentu v zobrazení osnovy dokumentu.

    • Možnost přidávat poznámky k aktivitám

    • Možnost definovat a využívat delegáty aktivit pomocí návrháře pracovního postupu

    • Automatické připojení a automatické vkládání pro aktivity a přechody v pracovních postupech stavového počítače a vývojového diagramu

  • Uložení informací o stavu zobrazení pro pracovní postup v jednom prvku v souboru XAML, abyste mohli snadno vyhledat a upravit informace o stavu zobrazení.

  • Aktivita kontejneru NoPersistScope, aby se zabránilo zachování podřízených aktivit.

  • Podpora výrazů jazyka C#:

    • Projekty pracovních postupů, které používají Jazyk Visual Basic, budou používat výrazy jazyka Visual Basic a projekty pracovních postupů jazyka C# budou používat výrazy jazyka C#.

    • Projekty pracovních postupů jazyka C#, které byly vytvořeny v sadě Visual Studio 2010 a které mají výrazy jazyka Visual Basic, jsou kompatibilní s projekty pracovních postupů jazyka C#, které používají výrazy jazyka C#.

  • Vylepšení správy verzí:

    • Nová třída WorkflowIdentity, která poskytuje mapování mezi trvalou instancí pracovního postupu a definicí pracovního postupu.

    • Souběžné spouštění více verzí pracovního postupu ve stejném hostiteli, včetně WorkflowServiceHost.

    • V dynamické aktualizaci lze upravit definici trvalé instance pracovního postupu.

  • Vývoj služeb pomocí kontraktu na prvním místě, který poskytuje podporu pro automatické generování aktivit tak, aby odpovídaly existující smlouvě o službě.

Další informace naleznete v tématu Co je nového ve Windows Workflow Foundation.

.NET pro aplikace Windows Store pro Windows 8.x

Aplikace pro Windows 8.x Store jsou navržené pro konkrétní formáty a využívají možnosti operačního systému Windows. Podmnožina rozhraní .NET Framework 4.5 nebo 4.5.1 je k dispozici pro vytváření aplikací pro Windows 8.x Store pro Windows pomocí jazyka C# nebo Visual Basic. Tato podmnožina se nazývá .NET pro aplikace pro Windows 8.x Store a je popsána v přehledu .

přenosné knihovny tříd

Projekt Portable Class Library v sadě Visual Studio 2012 (a novějších verzích) umožňuje psát a sestavovat spravovaná sestavení, která fungují na více platformách .NET Framework. Pomocí projektu Knihovny přenosných tříd zvolíte platformy (například Windows Phone a .NET pro aplikace pro Windows 8.x Store), na které chcete cílit. Dostupné typy a členy v projektu jsou automaticky omezeny na běžné typy a členy na těchto platformách. Další informace naleznete v tématu Portable Class Library.

Viz také