A .NET-keretrendszer újdonságai

Jegyzet

.NET keretrendszer a biztonsági és megbízhatósági hibajavításokkal Windows frissítésektől függetlenül működik. A biztonsági frissítések általában negyedévente jelennek meg. .NET keretrendszer továbbra is szerepelni fog a Windowszal, és nincs terv annak eltávolítására. Nem kell migrálnia a .NET Framework-alkalmazásokat, de új fejlesztéshez használja .NET-et a .NET Framework helyett.

Ez a cikk a .NET Framework alábbi verzióinak legfontosabb új funkcióit és fejlesztéseit foglalja össze:

Ez a cikk nem nyújt átfogó információt az egyes új funkciókról, és változhat. A .NET-keretrendszerről a Getting Started című témakörben talál általános információt. A támogatott platformokért lásd rendszerkövetelmények. A letöltési hivatkozásokért és a telepítési utasításokért lásd telepítési útmutatót.

Jegyzet

A .NET-keretrendszer csapata a NuGet használatával sávon kívül is kiadja a funkciókat a platformtámogatás kibővítéséhez, és új funkciókat vezet be, például nem módosítható gyűjteményeket és SIMD-kompatibilis vektortípusokat. További információ: További osztálykönyvtárak és API-k és .NET-keretrendszer és különálló kiadások. A .NET-keretrendszerhez tekintse meg a NuGet-csomagok kiegészítési listáját.

A .NET Framework 4.8.1 bemutatása

.NET Framework 4.8.1 a .NET Framework 4.x korábbi verzióira épül, mivel számos új javítást és számos új funkciót ad hozzá, miközben nagyon stabil termék marad.

.NET Framework 4.8.1 letöltése és telepítése

A .NET Framework 4.8.1-et a következő helyekről töltheti le:

.NET Framework 4.8 telepíthető a Windows 11, a Windows 10 21H2-es, 21H1-es, és 20H2-es verzióira, valamint a Windows Server 2022-vel kezdődő megfelelő kiszolgálóplatformokra. A .NET Framework 4.8.1-et a webtelepítő vagy az offline telepítő használatával telepítheti. A legtöbb felhasználó számára ajánlott a webtelepítő használata.

A .NET Framework 4.8.1 fejlesztői csomag telepítésével a Visual Studio 2022 17.3-s vagy újabb verziójában .NET Framework 4.8.1-et célozhatja meg.

A .NET Framework 4.8.1 újdonságai

.NET Framework 4.8.1 a következő területeken vezet be új funkciókat:

A továbbfejlesztett akadálymentesség, amely lehetővé teszi, hogy egy alkalmazás megfelelő élményt nyújtson a kisegítő technológiák felhasználóinak, a .NET Framework 4.8.1 fő témája. További információ a .NET Framework 4.8.1 akadálymentességi fejlesztéseiről: Az .NET Keretrendszer akadálymentességi újdonságai.

.NET Framework 4.8.1 natív Arm64-támogatást ad hozzá a .NET Framework családhoz. Így a .NET Framework-alkalmazások és -kódtárak hatalmas ökoszisztémájába való befektetései most már kihasználhatják az Arm64-en natív számítási feladatok futtatásának előnyeit– nevezetesen jobb teljesítményt, ha összehasonlítjuk az Arm64-en emulált x64-kód futtatásával.

A Microsoft elkötelezett amellett, hogy olyan termékeket és platformokat biztosítson, amelyek mindenki számára elérhetők. .NET Framework 4.8.1 két Windows felhasználói felületi fejlesztési platformot kínál, amelyek mindegyike biztosítja a fejlesztők számára az akadálymentes alkalmazások létrehozásához szükséges támogatást. Az elmúlt több kiadásban mind a Windows Forms, mind a WPF új funkciókkal bővült, és számos, az akadálymentességgel kapcsolatos megbízhatósági problémát kijavított. Az egyes kiadásokban kijavított vagy hozzáadott adatokról az Az .NET Keretrendszer akadálymentességi újdonságai című témakörben olvashat bővebben.

Ebben a kiadásban mind a Windows Forms, mind a WPF továbbfejlesztette az elemleírások kezelését, hogy akadálymentesebbé tegyék őket. Mindkét esetben az eszköztippek most megfelelnek a WCAG2.1 irányelveknek a és a tartalom alapján, amelyek a hover vagy a fókusz állapotra vonatkoznak. Az elemleírások követelményei a következők:

  • Az elemleírásoknak egérmutatóval vagy a vezérlőhöz való billentyűzet-navigációval kell megjelennie.
  • Az elemleírásoknak eltávolíthatóknak kell lenniük. Vagyis egy egyszerű billentyűzetparancsnak, például Esc, el kell távolítania a tippet.
  • Az elemleírásoknak rámutathatónak kell lenniük. A felhasználóknak képesnek kell lenniük az egérmutatót a lebegő súgóra helyezni. Ez lehetővé teszi az olyan helyzeteket, mint amikor a nagyítót használják, hogy elolvashassák az elemleírást a gyengén látó felhasználók számára.
  • Az elemleírásoknak állandónak kell lenniük. A súgók nem tűnjenek el automatikusan egy bizonyos idő eltelte után. Ehelyett az elemleírásoknak el kell tűnniük, ha a felhasználó áthelyezi az egeret egy másik vezérlőre, vagy egy billentyűkód segítségével.

A Windows Forms ez a támogatás csak Windows 11 vagy újabb operációs rendszereken érhető el. Windows Forms egy vékony felügyelt burkoló a Windows API-hez, és az új eszköztipp viselkedés csak a Windows 11-ben vált elérhetővé. WPF nem rendelkezik operációsrendszer-verziófüggőségekkel az elérhető elemleírásokhoz.

WPF a WCAG2.1-kompatibilis elemleírások legtöbb követelményét implementálta .NET Framework 4.8-ban. Ebben a kiadásban a WPF javította a felhasználói élményt azáltal, hogy az aktuális ablakban lévő elemleírást könnyen el lehet utasítani a Esc billentyűvel, a Ctrl billentyűvel (önmagában), vagy a Ctrl+Shift+F10 kombinációval. A feloldókulcs hatóköre ebben a kiadásban csökkent, hogy csak az aktuális ablakra vonatkozhasson. Korábban az alkalmazás bármelyik nyitott ugró tippjére vonatkozott.

Windows Forms volt az első Windows felhasználói felületi verem, amelyet a .NET-keretrendszerhez hoztak létre. Ezért eredetileg az örökölt akadálymentességi technológia használatára lett létrehozva, amely nem felel meg a jelenlegi akadálymentességi követelményeknek. Ebben a kiadásban Windows Forms számos problémával foglalkozott. Az akadálymentességgel kapcsolatos változások teljes listáját a Az .NET Keretrendszer akadálymentességi újdonságai című témakörben találja.

A .NET Framework 4.8.1 Windows Forms fejlesztései a következők:

  • Szövegminta támogatása – Windows Forms támogatja a UIA szövegmintát. Ez a minta lehetővé teszi a kisegítő technológia számára, hogy a TextBox vagy ahhoz hasonló szövegalapú vezérlőelemek tartalmát betűről betűre bejárja. Lehetővé teszi a vezérlőelemen belüli szöveg kijelölését és módosítását, valamint új szöveg beszúrását a kurzorhoz. A Windows Forms hozzáadta ezt a támogatást a TextBoxhoz, a DataGridView cellákhoz, a kombinált listákhoz és egyebekhez.

  • Kontrasztproblémák elhárítása – A Windows Forms számos vezérlőben sötétebbre és láthatóbbá változtatta a kijelölési téglalapok kontrasztarányát.

  • Kijavítottunk néhány DataGridView-problémát:

    • A görgetősáv neveit frissítették a következetesség érdekében.
    • A Narrátor mostantól képes üres DataGridView-cellákra összpontosítani.
    • A fejlesztők beállíthatják az egyéni DataGridView-cellák honosított vezérlőtípus-tulajdonságát.
    • A DataGridViewLink-cellák hivatkozásszíne frissült, hogy jobban kontrasztos legyen a háttérrel.

A .NET Framework 4.8 bemutatása

.NET Framework 4.8 a .NET Framework 4.x korábbi verzióira épül, mivel számos új javítást és számos új funkciót ad hozzá, miközben nagyon stabil termék marad.

.NET Framework 4.8 letöltése és telepítése

A .NET Framework 4.8-at a következő helyekről töltheti le:

.NET Framework 4.8 telepíthető Windows 10, Windows 8.1, Windows 7 SP1 és a megfelelő kiszolgálóplatformokra a Windows Server 2008 R2 SP1-től kezdve. A .NET Framework 4.8-at a webtelepítő vagy az offline telepítő használatával telepítheti. A legtöbb felhasználó számára ajánlott a webtelepítő használata.

A .NET Framework 4.8-at a 2012-Visual Studio vagy újabb verziókban a .NET Framework 4.8 fejlesztői csomag telepítésével célozhatja meg.

A .NET Framework 4.8 újdonságai

.NET Framework 4.8 a következő területeken vezet be új funkciókat:

A továbbfejlesztett akadálymentesség, amely lehetővé teszi, hogy egy alkalmazás megfelelő élményt nyújtson a kisegítő technológia felhasználói számára, továbbra is a .NET Framework 4.8 fő fókusza. További információ a .NET Framework 4.8 akadálymentességi fejlesztéseiről: A .NET Keretrendszer akadálymentességi újdonságai.

Alaposztályok

A FIPS csökkentett hatása a titkosításra. A .NET-keretrendszer korábbi verzióiban a felügyelt titkosítási szolgáltatói osztályok, például a SHA256Managed, dobnak egy CryptographicException-t, amikor a rendszer titkosítási könyvtárai "FIPS módban" vannak konfigurálva. Ezek a kivételek azért merülnek fel, mert a titkosítási szolgáltatói osztályok felügyelt verziói a rendszer titkosítási kódtáraitól eltérően nem mentek át a FIPS (Federal Information Processing Standards) 140-2 minősítésen. Mivel kevés fejlesztő rendelkezik fips módban a fejlesztői gépekkel, a kivételeket gyakran éles rendszerekben alkalmazzák.

A .NET Framework 4.8-at megcélzó alkalmazásokban alapértelmezés szerint a következő felügyelt titkosítási osztályok már nem dobnak kivételt ilyen esetben:

Ehelyett ezek az osztályok átirányítják a titkosítási műveleteket egy rendszer titkosítási könyvtárába. Ez a módosítás hatékonyan eltávolítja a fejlesztői környezetek és az éles környezetek közötti esetlegesen zavaró eltérést, és a natív összetevőket, valamint a felügyelt összetevőket azonos titkosítási irányelvek alatt működteti. Az ilyen kivételektől függő alkalmazások visszaállíthatják az előző viselkedést az AppContext kapcsoló Switch.System.Security.Cryptography.UseLegacyFipsThrowtruebeállításával. További információ: felügyelt titkosítási osztályok nem adnak CryptographyException-t FIPS módban.

A ZLib frissített verziójának használata

A .NET Framework 4.5-től kezdődően a clrcompression.dll-szerelvény a ZLib, egy natív külső kódtárat használ az adattömörítéshez, hogy implementációt biztosítson a deflátumalgoritmus számára. A clrcompression.dll .NET Framework 4.8 verziója a ZLib 1.2.11-es verziójára frissül, amely számos fontos fejlesztést és javítást tartalmaz.

Windows Communication Foundation (WCF)

ServiceHealthBehavior bemutatása

Az egészségügyi végpontokat az orchestration eszközök széles körben használják a szolgáltatások állapotuk alapján történő kezelésére. Az állapot-ellenőrzéseket a monitorozási eszközök is használhatják a szolgáltatás rendelkezésre állásáról és teljesítményéről szóló értesítések nyomon követésére és biztosítására.

ServiceHealthBehavior a WCF szolgáltatás viselkedése, amely kiterjeszti IServiceBehavior. Amikor hozzáadja a ServiceDescription.Behaviors gyűjteményhez, a szolgáltatás viselkedése a következő:

  • A szolgáltatás állapotának visszaadása HTTP-válaszkódokkal. Egy lekérdezési sztringben megadhatja egy HTTP/GET állapotadat-mintavételi kérelem HTTP-állapotkódját.

  • A szolgáltatás állapotával kapcsolatos információkat tesz közzé. A szolgáltatásspecifikus részletek, beleértve a szolgáltatás állapotát, a korlátozások számát és a kapacitást, HTTP/GET kéréssel jeleníthetők meg a ?health lekérdezési sztringgel. Az ilyen információk könnyű elérése fontos a WCF-szolgáltatás helytelen viselkedésének hibaelhárítása során.

Kétféleképpen teheti közzé az állapotvégpontot, és közzéteheti a WCF szolgáltatás állapotadatait:

  • Kódon keresztül. Például:

    ServiceHost host = new ServiceHost(typeof(Service1),
                   new Uri("http://contoso:81/Service1"));
ServiceHealthBehavior healthBehavior =
    host.Description.Behaviors.Find<ServiceHealthBehavior>();
healthBehavior ??= new ServiceHealthBehavior();
host.Description.Behaviors.Add(healthBehavior);

    Dim host As New ServiceHost(GetType(Service1),
            New Uri("http://contoso:81/Service1"))
Dim healthBehavior As ServiceHealthBehavior =
   host.Description.Behaviors.Find(Of ServiceHealthBehavior)()
If healthBehavior Is Nothing Then
   healthBehavior = New ServiceHealthBehavior()
End If
host.Description.Behaviors.Add(healthBehavior)

  • Konfigurációs fájl használatával. Például:

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

A szolgáltatás állapota lekérdezési paraméterekkel kérdezhető le, például OnServiceFailure, OnDispatcherFailure, OnListenerFailure, OnThrottlePercentExceeded), és minden lekérdezési paraméterhez megadható HTTP-válaszkód. Ha a HTTP-válaszkód hiányzik egy lekérdezési paraméterhez, a rendszer alapértelmezés szerint egy 503-at használó HTTP-válaszkódot használ. Például:

Lekérdezési paraméterek és példák:

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

    A rendszer 455 HTTP-válaszállapot-kódot ad vissza, ha a csatorna diszpécsereinek állapota nagyobb, mint CommunicationState.Opened.

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

    A rendszer 465 HTTP-válaszállapot-kódot ad vissza, ha bármely csatornahallgató állapota meghaladja a CommunicationState.Openedértéket.

  • OnThrottlePercentTúllépve: https://contoso:81/Service1?health&OnThrottlePercentExceeded= 70:350,95:500

    Megadja a választ aktiváló {1 – 100} százalékos értéket és a(z) {200 – 599} HTTP-válaszkódot. Ebben a példában:

    • Ha a százalékos érték nagyobb, mint 95, a rendszer 500 HTTP-válaszkódot ad vissza.

    • Ha a százalékos érték 70 és 95 között van, a függvény 350-et ad vissza.

    • Ellenkező esetben a 200 értéket adja vissza a függvény.

A szolgáltatás állapota megjeleníthető HTML-ben egy lekérdezési sztring (például https://contoso:81/Service1?health) megadásával vagy XML-ben egy olyan lekérdezési sztring megadásával, mint a https://contoso:81/Service1?health&Xml. Az https://contoso:81/Service1?health&NoContent-hez hasonló lekérdezési sztring üres HTML-oldalt ad vissza.

Windows Presentation Foundation (WPF)

magas DPI-fejlesztések

A .NET Framework 4.8-ban WPF támogatja Per-Monitor V2 DPI-tudatosságot és Mixed-Mode DPI-méretezést. További információkért a magas DPI-vel történő fejlesztésről tekintse meg a High DPI asztali alkalmazásfejlesztés a Windows rendszeren.

.NET Framework 4.8 javítja az üzemeltetett HWND-k és Windows Forms együttműködések támogatását High-DPI WPF alkalmazásokban olyan platformokon, amelyek támogatják Mixed-Mode DPI-skálázást (a 2018. április Windows 10 i frissítéstől kezdve). Ha támogatott HWND-k vagy Windows Forms vezérlők vegyes módú DPI-skálázású ablakként jönnek létre a SetThreadDpiHostingBehavior és SetThreadDpiAwarenessContext meghívásával, akkor egy Per-Monitor V2 WPF alkalmazásban üzemeltethetők, és megfelelő méretűek és skálázottak. Az ilyen üzemeltetett tartalom nem jelenik meg a natív DPI-n; ehelyett az operációs rendszer a üzemeltetett tartalmat a megfelelő méretre skálázza. A Per-Monitor v2 DPI tudatossági mód támogatása lehetővé teszi WPF vezérlők natív ablakban való üzemeltetését (azaz szülőként) egy magas DPI-alkalmazásban.

A Mixed-Mode magas DPI-skálázás támogatásának engedélyezéséhez állítsa be az alábbi AppContext kapcsolókat az alkalmazás konfigurációs fájljában:

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

közös nyelvi futásidejű környezet

A .NET Framework 4.8 futtatókörnyezete a következő módosításokat és fejlesztéseket tartalmazza:

A JIT fordítófejlesztései. Az .NET Framework 4.8 igény szerinti (JIT) fordítója a .NET Core 2.1-ben található JIT-fordítón alapul. A .NET Core 2.1 JIT-fordító számos optimalizálása és hibajavítása megtalálható a .NET Framework 4.8 JIT-fordítóban.

NGEN-fejlesztések. A futtatókörnyezet javította natív képgenerátor (NGEN) rendszerképek memóriakezelését, hogy az NGEN-képekről leképezett adatok ne legyenek memória-rezidensek. Ez csökkenti azoknak a támadásoknak a felületét, amelyek tetszőleges kódot próbálnak végrehajtani a végrehajtandó memória módosításával.

Kártevőirtó vizsgálat az összes szerelvény. A .NET Framework korábbi verzióiban a futtatókörnyezet megvizsgálja a lemezről betöltött összes szerelvényt Windows Defender vagy külső kártevőirtó szoftver használatával. Más forrásokból, például a Assembly.Load(Byte[]) metódussal betöltött összetevőket nem ellenőrzik, és így esetleg észleletlen malware-t is tartalmazhatnak. A Windows 10 futó .NET Framework 4.8-tól kezdve a futtatókörnyezet a Antimalware Scan Interface (AMSI) implementálására szolgáló kártevőirtó-megoldások általi vizsgálatot indít el.

A .NET Framework 4.7.2 újdonságai

.NET Framework 4.7.2 az alábbi területeken tartalmaz új funkciókat:

A .NET Framework 4.7.2-ben továbbra is a továbbfejlesztett akadálymentesség áll, amely lehetővé teszi, hogy az alkalmazás megfelelő élményt nyújtson a kisegítő technológia felhasználói számára. További információ a .NET Framework 4.7.2 akadálymentességi fejlesztéseiről: A .NET Keretrendszer akadálymentességi újdonságai.

Alaposztályok

.NET Framework 4.7.2 számos titkosítási fejlesztést, jobb tömörítési támogatást nyújt a ZIP-archívumokhoz, és további gyűjtemény API-kat is tartalmaz.

Az RSA.Create és DSA.Create új túlterhelései

A DSA.Create(DSAParameters) és RSA.Create(RSAParameters) metódusokkal kulcsparamétereket adhat meg új DSA vagy RSA kulcsok létrehozásakor. A következőhöz hasonló kód cseréjét teszik lehetővé:

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

' Before .NET Framework 4.7.2
Using rsa = RSA.Create()
   rsa.ImportParameters(rsaParameters)
   ' Other code to execute using the rsa instance.
End Using

a következőhöz hasonló kóddal:

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

' Starting with .NET Framework 4.7.2
Using rsa = RSA.Create(rsaParameters)
   ' Other code to execute using the rsa instance.
End Using

A DSA.Create(Int32) és RSA.Create(Int32) metódusokkal új DSA vagy RSA kulcsokat hozhat létre egy adott kulcsmérettel. Például:

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

Using dsa = DSA.Create(2048)
   ' Other code to execute using the dsa instance.
End Using

Rfc2898DeriveBytes konstruktorok elfogadják a kivonatoló algoritmus nevét

A Rfc2898DeriveBytes osztály három új konstruktorsal rendelkezik, amelyek HashAlgorithmName paraméterrel azonosítják a kulcsok származtatásakor használni kívánt HMAC-algoritmust. Az SHA-1 használata helyett a fejlesztőknek sha-2-alapú HMAC-t kell használniuk, például az SHA-256-ot, ahogy az alábbi példában látható:

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

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

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

Private Shared Function DeriveKey(password As String, ByRef iterations As Integer,
                                  ByRef salt AS Byte(), ByRef algorithm As HashAlgorithmName) As Byte()
   iterations = 100000
   algorithm = HashAlgorithmName.SHA256

   Const SaltSize As Integer = 32
   Const  DerivedValueSize As Integer = 32

   Using pbkdf2 = New Rfc2898DeriveBytes(password, SaltSize, iterations, algorithm)
      salt = pbkdf2.Salt
      Return pbkdf2.GetBytes(DerivedValueSize)
   End Using
End Function

Rövid élettartamú kulcsok támogatása

A PFX-importálás opcionálisan közvetlenül a memóriából töltheti be a titkos kulcsokat, megkerülve a merevlemezt. Ha az új X509KeyStorageFlags.EphemeralKeySet jelző egy X509Certificate2 konstruktorban vagy a X509Certificate2.Import metódus egyik túlterhelésében van használva, a privát kulcsok ideiglenes kulcsként lesznek betöltve. Ez megakadályozza, hogy a kulcsok megjelenjenek a lemezen. Azonban:

  • Mivel a kulcsok nem maradnak meg a lemezen, az ezzel a jelzővel betöltött tanúsítványok nem alkalmasak az X509Store-hoz való hozzáadásra.

  • Az ilyen módon betöltött kulcsok szinte mindig Windows CNG-n keresztül töltődnek be. Ezért a hívóknak kiterjesztési metódusok meghívásával, például: tanúsítvány.GetRSAPrivateKey(), kell hozzáférniük a titkos kulcshoz. A X509Certificate2.PrivateKey tulajdonság nem működik.

  • Mivel az örökölt X509Certificate2.PrivateKey tulajdonság nem működik tanúsítványokkal, a fejlesztőknek szigorú tesztelést kell végrehajtaniuk, mielőtt rövid élettartamú kulcsokra váltanának.

PKCS#10 tanúsítvány-aláírási kérelmek és X.509 nyilvános kulcsú tanúsítványok programozott létrehozása

A .NET Framework 4.7.2-től kezdve a számítási feladatok tanúsítvány-aláírási kéréseket (CSR-eket) hozhatnak létre, amelyek lehetővé teszik a tanúsítványkérelmek létrehozását a meglévő eszközkészletbe való előkészítéshez. Ez gyakran hasznos tesztforgatókönyvekben.

További információkért és kódpéldákért tekintse meg a "PKCS#10 tanúsítvány-aláírási kérelmek és X.509 nyilvános kulcsú tanúsítványok programozott létrehozása" című témakört a .NET blogban.

SignerInfo új tagjai

A .NET Framework 4.7.2-től kezdve a SignerInfo osztály további információkat tesz közzé az aláírásról. Az aláíró által használt aláírási algoritmus meghatározásához lekérheti a System.Security.Cryptography.Pkcs.SignerInfo.SignatureAlgorithm tulajdonság értékét. SignerInfo.GetSignature meghívható, hogy másolatot kapjon az aláíró titkosítási aláírásáról.

Burkolt stream nyitva hagyása, miután a CryptoStream el lett bontva

A .NET Framework 4.7.2-től kezdve a CryptoStream osztály egy további konstruktort is biztosít, amely lehetővé teszi, hogy Dispose ne zárja be a becsomagolt streamet. Ha a CryptoStream példány megsemmisítése után nyitva szeretné hagyni a burkolt streamet, hívja meg az új CryptoStream konstruktort az alábbiak szerint:

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

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

DeflateStream dekompressziós változásai

A .NET Framework 4.7.2-től kezdve a DeflateStream osztály dekompressziós műveleteinek megvalósítása alapértelmezés szerint natív Windows API-k használatára módosult. Ez általában jelentős teljesítménybeli javulást eredményez.

A Windows API-k használatával történő dekompresszió támogatása alapértelmezés szerint engedélyezve van a .NET Framework 4.7.2-t célzó alkalmazások esetében. A .NET-keretrendszer korábbi verzióit célzó, de a .NET Framework 4.7.2-ben futó alkalmazások a következő AppContext kapcsoló hozzáadásával engedélyezhetik ezt a viselkedést az alkalmazáskonfigurációs fájlban:

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

További gyűjtemény API-k

.NET Framework 4.7.2 számos új API-t ad hozzá a SortedSet<T> és HashSet<T> típushoz. Ezek a következők:

A ConcurrentDictionary<TKey,TValue> osztály új túlterheléseket tartalmaz a AddOrUpdate és GetOrAdd metódusok esetében, hogy lekérjen egy értéket a szótárból, vagy ha az nem található, hogy hozzáadjon egyet. Ezen kívül, ha az érték már létezik, akkor azt frissíti a szótárban.

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

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

Public AddOrUpdate(Of TArg)(key As TKey, addValueFactory As Func(Of TKey, TArg, TValue), updateValueFactory As Func(Of TKey, TValue, TArg, TValue), factoryArgument As TArg) As TValue

Public GetOrAdd(Of TArg)(key As TKey, valueFactory As Func(Of TKey, TArg, TValue), factoryArgument As TArg) As TValue

ASP.NET

Függőséginjektálás támogatása a Web Forms

Függőséginjektálás (DI) leválasztja az objektumokat és azok függőségeit, így az objektum kódját már nem kell módosítani csak azért, mert egy függőség megváltozott. A .NET Framework 4.7.2-et célzó ASP.NET alkalmazások fejlesztésekor a következőt teheti:

Azonos webhelyű cookie-k támogatása

SameSite megakadályozza, hogy a böngésző cookie-t küldjön egy webhelyközi kéréssel együtt. .NET Framework 4.7.2 hozzáad egy HttpCookie.SameSite tulajdonságot, amelynek értéke egy System.Web.SameSiteMode enumerálási tag. Ha értéke SameSiteMode.Strict vagy SameSiteMode.Lax, ASP.NET hozzáadja a SameSite attribútumot a set-cookie fejléchez. A SameSite-támogatás HttpCookie objektumokra, valamint FormsAuthentication és System.Web.SessionState cookie-kra vonatkozik.

A SameSite-t az alábbiak szerint állíthatja be egy HttpCookie objektumhoz:

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

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

A SameSite cookie-kat alkalmazásszinten is konfigurálhatja a web.config fájl módosításával:

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

A webkonfigurációs fájl módosításával hozzáadhat SameSite-t FormsAuthentication és System.Web.SessionState cookie-khoz:

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

hálózat

HttpClientHandler-tulajdonságok implementálása

.NET Framework 4.7.1 nyolc tulajdonságot adott hozzá a System.Net.Http.HttpClientHandler osztályhoz. Azonban ketten dobtak egy PlatformNotSupportedException-t. .NET Framework 4.7.2 mostantól implementációt biztosít ezekhez a tulajdonságokhoz. A tulajdonságok a következők:

SQLClient

Támogatás Azure Active Directory univerzális hitelesítéshez és többtényezős hitelesítéshez

A növekvő megfelelőségi és biztonsági követelmények megkövetelik, hogy sok ügyfél többtényezős hitelesítést (MFA) használjon. Emellett a jelenlegi ajánlott eljárások nem javasolják, hogy a felhasználói jelszavakat közvetlenül a kapcsolati karakterláncokban szerepeltessük. A módosítások támogatásához .NET Framework 4.7.2 kibővíti a SQLClient kapcsolati sztringeket a meglévő "Authentication" kulcsszóhoz hozzáadott új "Active Directory Interactive" értékkel, amely támogatja az MFA-t és a Azure AD-hitelesítést. Az új interaktív módszer támogatja a natív és összevont Azure AD-felhasználókat, valamint az Azure AD-vendégfelhasználókat. Ha ezt a módszert használja, az Azure AD által előírt MFA-hitelesítés támogatott az SQL-adatbázisok esetében. A hitelesítési folyamat emellett felhasználói jelszót kér a biztonsági ajánlott eljárások betartásához.

A .NET Framework korábbi verzióiban az SQL-kapcsolat csak a SqlAuthenticationMethod.ActiveDirectoryPassword és SqlAuthenticationMethod.ActiveDirectoryIntegrated beállításokat támogatta. Mindkettő része a nem interaktív ADAL protokoll, amely nem támogatja az MFA-t. Az új SqlAuthenticationMethod.ActiveDirectoryInteractive beállítással az SQL-kapcsolat támogatja az MFA-t és a meglévő hitelesítési módszereket (jelszó és integrált hitelesítés), amely lehetővé teszi a felhasználók számára, hogy interaktívan adjanak meg felhasználói jelszavakat anélkül, hogy a jelszavakat megőriznék a connection string.

További információ és egy példa: "SQL -- Azure AD univerzális és többtényezős hitelesítés támogatása" a .NET blogban.

Always Encrypted 2-es verziójának támogatása

A NET Framework 4.7.2 támogatja az enklávéalapú Always Encrypted használatát. Az Always Encrypted eredeti verziója egy ügyféloldali titkosítási technológia, amelyben a titkosítási kulcsok soha nem hagyják el az ügyfelet. Az enklávéalapú Always Encryptedben az ügyfél opcionálisan elküldheti a titkosítási kulcsokat egy biztonságos enklávénak, amely egy biztonságos számítási entitás, amely a SQL Server része lehet, de a SQL Server kód nem módosítható. Az enklávéalapú Always Encrypted támogatásához .NET Framework 4.7.2 a következő típusokat és tagokat adja hozzá a System.Data.SqlClient névtérhez:

Az alkalmazáskonfigurációs fájl ezután megadja az absztrakt System.Data.SqlClient.SqlColumnEncryptionEnclaveProvider osztály konkrét implementációját, amely biztosítja az enklávészolgáltató funkcióit. Például:

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

Az enklávéalapú Always Encrypted alapfolyamata a következő:

  1. A felhasználó létrehoz egy Always Encrypted kapcsolatot a SQL Serverhez, amely támogatja az enklávéalapú Always Encrypted funkciót. Az illesztőprogram kapcsolatba lép az igazolási szolgáltatással, hogy megbizonyosodjon arról, hogy a megfelelő enklávéhoz csatlakozik.

  2. Az enklávé igazolása után az illesztőprogram biztonságos csatornát hoz létre az SQL Server által üzemeltetett biztonságos enklávéval.

  3. Az illesztőprogram megosztja az ügyfél által engedélyezett titkosítási kulcsokat a biztonságos enklávéval az SQL-kapcsolat időtartama alatt.

Windows megjelenítési alaprendszer

ResourceDictionaries keresése forrás szerint

A .NET Framework 4.7.2-től kezdve a diagnosztikai asszisztens megkeresheti az egy adott forrás Uri-jából létrehozott ResourceDictionaries. (Ez a funkció diagnosztikai asszisztensek által használható, nem éles alkalmazások számára.) Egy diagnosztikai asszisztens, például Visual Studio "Szerkesztés és folytatás" eszközével a felhasználó szerkesztheti a ResourceDictionaryt azzal a szándékkal, hogy a módosítások a futó alkalmazásra legyenek alkalmazva. Ennek egyik lépése az összes ResourceDictionaries megtalálása, amelyet a futó alkalmazás a szerkesztett szótárból hozott létre. Egy alkalmazás például deklarálhat egy ResourceDictionary-t, amelynek tartalmát egy adott forrás URI-ból másolja:

<ResourceDictionary Source="MyRD.xaml" />

A MyRD.xaml eredeti jelölést szerkesztő diagnosztikai asszisztens az új funkcióval megkeresheti a szótárt. A funkciót egy új statikus módszer, ResourceDictionaryDiagnostics.GetResourceDictionariesForSourcevalósítja meg. A diagnosztikai asszisztens egy abszolút Uri használatával hívja meg az új metódust, amely azonosítja az eredeti korrektúrát, ahogyan azt az alábbi kód is szemlélteti:

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

Dim dictionaries As IEnumerable(Of ResourceDictionary) = ResourceDictionaryDiagnostics.GetResourceDictionariesForSource(New Uri("pack://application:,,,/MyApp;component/MyRD.xaml"))

A metódus üres számbavételt ad vissza, kivéve, ha VisualDiagnostics engedélyezve van, és a ENABLE_XAML_DIAGNOSTICS_SOURCE_INFO környezeti változó be van állítva.

ResourceDictionary-tulajdonosok megkeresése

A .NET Framework 4.7.2-től kezdve a diagnosztikai asszisztensek megkereshetik egy adott ResourceDictionary tulajdonosait. (A funkció diagnosztikai asszisztensek számára készült, nem pedig éles alkalmazások használatára.) Amikor egy ResourceDictionary-t módosítanak, a WPF automatikusan megkeresi az összes DynamicResource hivatkozást, amelyet a változás érinthet.

Előfordulhat, hogy egy diagnosztikai asszisztens, például Visual Studio "Szerkesztés és folytatás" létesítménye ki szeretné terjeszteni ezt StaticResource hivatkozások kezelésére. Ennek a folyamatnak az első lépése a szótár tulajdonosainak megkeresése; vagyis az összes olyan objektum megkeresése, amelynek Resources tulajdonsága a szótárra hivatkozik (közvetlenül vagy közvetve a ResourceDictionary.MergedDictionaries tulajdonságon keresztül). A System.Windows.Diagnostics.ResourceDictionaryDiagnostics osztályban három új statikus metódus van implementálva, amelyek mindegyike Resources tulajdonságú alaptípushoz tartozik, támogatja ezt a lépést:

Ezek a metódusok üres számbavételt adnak vissza, kivéve, ha VisualDiagnostics engedélyezve van, és a ENABLE_XAML_DIAGNOSTICS_SOURCE_INFO környezeti változó be van állítva.

StaticResource-hivatkozások keresése

A diagnosztikai asszisztens mostantól értesítést kaphat, ha egy StaticResource-hivatkozás feloldása történik. (A funkció diagnosztikai asszisztensek számára használható, nem pedig éles alkalmazásokban.) Egy diagnosztikai asszisztens, például a Visual Studio "Szerkesztés és folytatás" funkciója, szeretné frissíteni az erőforrás minden használatát, amikor annak értéke egy ResourceDictionary-ben megváltozik. WPF automatikusan elvégzi ezt a DynamicResource hivatkozások esetében, de szándékosan nem teszi ezt StaticResource hivatkozások esetében. A .NET Framework 4.7.2-től kezdve a diagnosztikai asszisztens ezeket az értesítéseket használhatja a statikus erőforrás ezen felhasználásának megkereséséhez.

Az értesítést az új ResourceDictionaryDiagnostics.StaticResourceResolved esemény valósítja meg:

public static event EventHandler<StaticResourceResolvedEventArgs> StaticResourceResolved;

Public Shared Event StaticResourceResolved As EventHandler(Of StaticResourceResolvedEventArgs)

Ez az esemény akkor jön létre, amikor a futtatókörnyezet felold egy StaticResource-hivatkozást. A StaticResourceResolvedEventArgs argumentumok leírják a felbontást, és jelzik a StaticResource hivatkozását, valamint a megoldáshoz használt ResourceDictionary és kulcsot tartalmazó objektumot és tulajdonságot:

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

   public Object TargetProperty { get; }

   public ResourceDictionary ResourceDictionary { get; }

   public object ResourceKey { get; }
}

Public Class StaticResourceResolvedEventArgs : Inherits EventArgs
   Public ReadOnly Property TargetObject As Object
   Public ReadOnly Property TargetProperty As Object
   Public ReadOnly Property ResourceDictionary As ResourceDictionary
   Public ReadOnly Property ResourceKey As Object
End Class

Az eseményt nem emeli ki (és a add tartozékát figyelmen kívül hagyja), kivéve, ha VisualDiagnostics engedélyezve van, és a ENABLE_XAML_DIAGNOSTICS_SOURCE_INFO környezeti változó be van állítva.

ClickOnce

A WINDOWS FORMS, Windows Presentation Foundation (WPF) és Visual Studio Office-eszközökhöz (VSTO) használható HDPI-képes alkalmazások a ClickOnce használatával telepíthetők. Ha a következő bejegyzés található az alkalmazásjegyzékben, az üzembe helyezés sikeres lesz a .NET Framework 4.7.2-ben:

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

A Windows Forms alkalmazások esetében már nem szükséges a DPI-tudatosság alkalmazáskonfigurációs fájlban történő beállításának korábbi kerülő megoldása az alkalmazásjegyzék helyett a ClickOnce telepítéséhez.

A .NET Framework 4.7.1 újdonságai

.NET Framework 4.7.1 a következő területeken tartalmaz új funkciókat:

Emellett a .NET Framework 4.7.1 fő témája a továbbfejlesztett akadálymentesség, amely lehetővé teszi, hogy az alkalmazás megfelelő élményt nyújtson a kisegítő technológia felhasználói számára. További információ a .NET Framework 4.7.1 akadálymentességi fejlesztéseiről: Az .NET Keretrendszer akadálymentességi újdonságai.

Alaposztályok

A .NET Standard 2.0 támogatása

.NET Standard olyan API-kat határoz meg, amelyeknek elérhetőnek kell lenniük minden olyan .NET implementációban, amely támogatja a szabvány ezen verzióját. .NET Framework 4.7.1 teljes mértékben támogatja a .NET Standard 2.0-t, és a 200 API-t adja hozzá, amelyek .NET Standard 2.0-s verzióban vannak definiálva, és hiányoznak .NET Framework 4.6.1-ből, 4.6.2-ből és 4.7-ből. (Vegye figyelembe, hogy a .NET Keretrendszer ezen verziói csak akkor támogatják .NET Standard 2.0-t, ha további .NET Standard támogatási fájlok is üzembe vannak helyezve a célrendszeren.) További információ: "BCL - .NET Standard 2.0 támogatás" a .NET Framework 4.7.1 futtatókörnyezeti és fordítófunkciók blogbejegyzésben.

Konfigurációkészítők támogatása

A konfigurációkészítők lehetővé teszik a fejlesztők számára, hogy futásidőben dinamikusan injektálják és létrehozzák az alkalmazások konfigurációs beállításait. Az egyéni konfigurációszerkesztők a konfigurációs szakaszban lévő meglévő adatok módosítására vagy egy konfigurációs szakasz teljesen az alapoktól való létrehozására használhatók. Konfigurációkészítők nélkül .config fájlok statikusak, és a beállításokat az alkalmazás elindítása előtt egy ideig definiálják.

Egyéni konfigurációszerkesztő létrehozásához az absztrakt ConfigurationBuilder osztályból származtathatja a szerkesztőt, és felülbírálhatja annak ConfigurationBuilder.ProcessConfigurationSection és ConfigurationBuilder.ProcessRawXml. A szerkesztőket a .config fájlban is definiálhatja. További információért lásd a .NET Framework 4.7.1-es ASP.NET és konfigurációs szolgáltatások blogbejegyzés "Konfigurációs építők" részét.

Futtatókörnyezeti funkciók észlelése

A System.Runtime.CompilerServices.RuntimeFeature osztály mechanizmust biztosít annak meghatározására, hogy egy előre definiált funkció támogatott-e egy adott .NET-implementációban fordításkor vagy futtatókörnyezetben. Fordításkor a fordító ellenőrizheti, hogy létezik-e egy adott mező annak megállapításához, hogy a szolgáltatás támogatott-e; ha igen, olyan kódot bocsáthat ki, amely kihasználja ezt a funkciót. Futásidőben az alkalmazás meghívhatja a metódust, RuntimeFeature.IsSupported mielőtt kódot bocsát ki futásidőben. További információ: Kisegítő módszer hozzáadása a futtatókörnyezetiáltal támogatott funkciók leírásához.

Értéktuple típusok sorosíthatóak

A .NET Framework 4.7.1-től kezdve a System.ValueTuple és a hozzá tartozó generikus típusok Serializable jelzőt kapnak, amely lehetővé teszi a bináris szerializálást. Ez megkönnyíti a Tuple-típusok, például a Tuple<T1,T2,T3> és Tuple<T1,T2,T3,T4>, érték Tuple-típusokra történő átállítását. További információt a .NET Framework 4.7.1 futtatókörnyezeti és fordítófunkciói blogbejegyzésében talál a "Compiler -- ValueTuple is Serializable" című témakörben.

Írásvédett hivatkozások támogatása

.NET Framework 4.7.1 hozzáadja a System.Runtime.CompilerServices.IsReadOnlyAttribute. Ezt az attribútumot használják a nyelvfordítók az írásvédett ref visszatérési típusokkal vagy paraméterekkel rendelkező tagok megjelölésére. További információ: "Compiler -- Support for ReadOnlyReferences" (A ReadOnlyReferences támogatása) a .NET Framework 4.7.1 futtatókörnyezeti és fordítói funkciói blogbejegyzésben. Ref visszatérési értékekkel kapcsolatos információért lásd: Ref visszatérési értékek, ref helyiek, és Ref visszatérési értékek (Visual Basic).

közös nyelvi futtatókörnyezet (CLR)

Szemétgyűjtési teljesítmény javítása

A .NET Framework 4.7.1-ben a szemétgyűjtés (GC) változásai javítják az általános teljesítményt, különösen a nagy objektum kupac (LOH) foglalások esetében. A .NET Framework 4.7.1-ben külön lockokat használnak a kis objektum halomhoz (SOH) és a LOH-foglalásokhoz, ami lehetővé teszi a LOH-foglalások végrehajtását, míg a háttérben futó GC a SOH-t söpri át. Ennek eredményeképpen a nagy számú LOH-foglalást végző alkalmazásoknak a foglalási zárolási versengés csökkenését és javuló teljesítményt kell tapasztalniuk. További információ: "Futtatókörnyezet – GC teljesítménybeli fejlesztések" című szakasz a .NET Framework 4.7.1 futtatókörnyezeti és fordítófunkciók blogbejegyzésben.

hálózat

SHA-2 támogatása a Message.HashAlgorithm esetében

A .NET Framework 4.7 és korábbi verzióiban a Message.HashAlgorithm tulajdonság csak HashAlgorithm.Md5 és HashAlgorithm.Sha értékeit támogatta. A .NET Framework 4.7.1-től kezdve HashAlgorithm.Sha256, HashAlgorithm.Sha384 és HashAlgorithm.Sha512 is támogatott. Az, hogy ezt az értéket ténylegesen használják-e, az MSMQ-tól függ, mivel maga a Message példány nem végez kivonatolást, hanem egyszerűen átadja az értékeket az MSMQ-nak. További információt a .NET Framework 4.7.1 ASP.NET és konfigurációs funkciói blogbejegyzésben található "SHA-2 támogatás a Message.HashAlgorithm-hez" című szakaszban talál.

ASP.NET

Végrehajtási lépések ASP.NET alkalmazásokban

ASP.NET egy előre definiált folyamatban dolgozza fel a kéréseket, amely 23 eseményt tartalmaz. ASP.NET végrehajtja az egyes eseménykezelőket végrehajtási lépésként. A ASP.NET .NET Framework 4.7-ig terjedő verzióiban a ASP.NET nem tudja átfolyni a végrehajtási környezetet a natív és a felügyelt szálak közötti váltás miatt. Ehelyett az ASP.NET szelektíven csak a HttpContext árasztja. A .NET Framework 4.7.1-től kezdve a HttpApplication.OnExecuteRequestStep(Action<HttpContextBase,Action>) metódus lehetővé teszi a modulok számára a környezeti adatok visszaállítását is. Ez a funkció a nyomkövetéssel, profilkészítéssel, diagnosztikával vagy tranzakciókkal foglalkozó kódtárakra irányul, például az alkalmazás végrehajtási folyamatával kapcsolatosak. További információt a .NET Framework 4.7.1 ASP.NET és konfigurációs funkciói blogbejegyzésében található "ASP.NET végrehajtási lépés funkció" című témakörben talál.

ASP.NET HttpCookie elemzése

.NET Framework 4.7.1 tartalmaz egy új metódust, a HttpCookie.TryParse, amely szabványosított módot biztosít egy HttpCookie objektum sztringből való létrehozására, és pontosan hozzárendeli a cookie-értékeket, például a lejárati dátumot és az elérési utat. További információ: "ASP.NET HttpCookie elemzés" a .NET Framework 4.7.1 ASP.NET és konfigurációs funkciók blogbejegyzésben.

SHA-2 kivonatolási lehetőségek ASP.NET űrlap hitelesítési hitelesítő adataihoz

A .NET Framework 4.7 és korábbi verzióiban ASP.NET lehetővé tette a fejlesztők számára, hogy kivonatolt jelszavakkal tárolják a felhasználói hitelesítő adatokat az MD5 vagy SHA1 konfigurációs fájlokban. A .NET Framework 4.7.1-től kezdve a ASP.NET olyan új biztonságos SHA-2 kivonatolási lehetőségeket is támogat, mint az SHA256, az SHA384 és az SHA512. Az SHA1 marad az alapértelmezett, és a webes konfigurációs fájlban meghatározható egy nem alapértelmezett kivonatoló algoritmus.

Fontos

A Microsoft azt javasolja, hogy a legbiztonságosabb hitelesítési folyamatot használja. Ha az Azure SQL-hez csatlakozik, az Azure erőforrások felügyelt identitásai az ajánlott hitelesítési módszer.

A .NET Framework 4.7 újdonságai

.NET Framework 4.7 az alábbi területeken tartalmaz új funkciókat:

A .NET Framework 4.7-hez hozzáadott új API-k listáját a GitHub .NET Framework 4.7 API-módosításai című témakörben találja. A .NET Framework 4.7 szolgáltatásfejlesztéseinek és hibajavításainak listáját a .NET Framework 4.7 Változások listája GitHub című témakörben találja. További információ: A .NET Framework 4.7 bejelentése a .NET blogban.

Alaposztályok

.NET Framework 4.7 javítja a szerializálást a DataContractJsonSerializer által:

Továbbfejlesztett funkciók háromoldalú íves titkosítással (ECC)*

A .NET Framework 4.7-ben ImportParameters(ECParameters) metódusok lettek hozzáadva a ECDsa és ECDiffieHellman osztályokhoz, hogy egy objektum egy már meglévő kulcsot képviseljen. Egy ExportParameters(Boolean) metódus is hozzáadva a kulcs explicit görbeparaméterekkel való exportálásához.

.NET Framework 4.7 további görbéket is támogat (beleértve a Brainpool-görbecsomagot is), és előre definiált definíciókat is hozzáadott a könnyű létrehozáshoz az új Create és Create gyári módszerekkel.

Láthat egy példát a .NET Framework 4.7 titkosítási fejlesztéseiről a GitHubon.

A DataContractJsonSerializer jobban támogatja a vezérlőkarakterek használatát

A .NET Framework 4.7-ben a DataContractJsonSerializer osztály az ECMAScript 6 szabványnak megfelelően szerializálja a vezérlőkarakterek használatát. Ez a viselkedés alapértelmezés szerint engedélyezve van a .NET Framework 4.7-et megcélzott alkalmazások esetében, és a .NET Framework 4.7-es verziójában futó, de a .NET-keretrendszer egy korábbi verzióját célzó alkalmazásokra vonatkozó engedélyezési funkció. További információ: alkalmazáskompatibilitási szakasz.

hálózat

.NET Framework 4.7 a következő hálózattal kapcsolatos funkciót adja hozzá:

TLS-protokollok alapértelmezett operációsrendszer-támogatása*

A TLS-verem, amelyet a System.Net.Security.SslStream és az újabb összetevők, például a HTTP, az FTP és az SMTP használnak, lehetővé teszi a fejlesztők számára, hogy az operációs rendszer által támogatott alapértelmezett TLS-protokollokat használják. Fejlesztőknek már nem kell hardkódolniuk a TLS-verziót.

ASP.NET

A .NET Framework 4.7-ben a ASP.NET a következő új funkciókat tartalmazza:

Objektumgyorsítótár bővíthetőség

A .NET Framework 4.7-től kezdve a ASP.NET új API-kat ad hozzá, amelyekkel a fejlesztők lecserélhetik a memóriabeli objektumok gyorsítótárazásához és a memória monitorozásához használt alapértelmezett ASP.NET implementációkat. A fejlesztők az alábbi három összetevő bármelyikét lecserélhetik, ha a ASP.NET implementáció nem megfelelő:

  • Objektum gyorsítótár tároló. Az új gyorsítótár-szolgáltatók konfigurációs szakaszának használatával a fejlesztők az új ICacheStoreProvider interfész használatával csatlakoztathatják az objektumgyorsítótár új implementációit egy ASP.NET alkalmazáshoz.

  • memóriafigyelés. Az alapértelmezett memóriafigyelő ASP.NET értesíti az alkalmazásokat, ha a folyamat konfigurált privát bájtkorlátjának közelében futnak, vagy ha a gép alacsony a teljes rendelkezésre álló fizikai RAM-on. Ha ezek a korlátok közel vannak, az értesítések aktiválódnak. Egyes alkalmazások esetében az értesítések túl közel vannak a konfigurált korlátokhoz, hogy hasznos reakciókat lehessen lehetővé tenni. A fejlesztők most már írhatnak saját memóriafigyelőket az alapértelmezett helyett a ApplicationMonitors.MemoryMonitor tulajdonság használatával.

  • reakciók a memóriakorlátokra. Alapértelmezés szerint ASP.NET megpróbálja levágni az objektumgyorsítótárat, és rendszeres időközönként meghívja GC.Collect, ha a privát bájtfolyamat-korlát közel van. Egyes alkalmazások esetében a GC.Collect hívásainak gyakorisága vagy a levágott gyorsítótár mennyisége nem hatékony. A fejlesztők mostantól lecserélhetik vagy kiegészíthetik az alapértelmezett viselkedést úgy, hogy az implementációkat az alkalmazás memóriamonitorára rendelik IObserver .

Windows Communication Foundation (WCF)

Windows Communication Foundation (WCF) a következő funkciókat és módosításokat adja hozzá:

Az alapértelmezett üzenetbiztonsági beállítások konfigurálása TLS 1.1 vagy TLS 1.2

A .NET Framework 4.7-től kezdve a WCF lehetővé teszi a TLS 1.1 vagy TLS 1.2 konfigurálását az SSL 3.0 és a TLS 1.0 mellett alapértelmezett üzenetbiztonsági protokollként. Ez egy bejelentkezési beállítás; az engedélyezéshez a következő bejegyzést kell hozzáadnia az alkalmazáskonfigurációs fájlhoz:

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

Javított WCF-alkalmazások megbízhatósága és WCF-szerializálás

A WCF számos olyan kódmódosítást tartalmaz, amelyek kiküszöbölik a versenyfeltételeket, ezáltal javítva a teljesítményt és a szerializálási lehetőségek megbízhatóságát. Ezek a következők:

  • Az aszinkron és szinkron kód keverésének jobb támogatása a SocketConnection.BeginRead és SocketConnection.Readhívásokban.
  • A megbízhatóság javult, amikor megszakít egy kapcsolatot a SharedConnectionListener és a DuplexChannelBinder segítségével.
  • A szerializálási műveletek megbízhatóságának javítása a FormatterServices.GetSerializableMembers(Type) metódus meghívásakor.
  • Nagyobb megbízhatóság egy pincér eltávolításakor a ChannelSynchronizer.RemoveWaiter metódus meghívásával.

Windows Forms

A .NET Framework 4.7-ben Windows Forms javítja a magas DPI-monitorok támogatását.

magas DPI-támogatás

A .NET Framework 4.7-et célzó alkalmazásoktól kezdve a .NET-keretrendszer magas DPI- és dinamikus DPI-támogatást nyújt Windows Forms alkalmazásokhoz. A magas DPI-támogatás javítja az űrlapok és vezérlők elrendezését és megjelenését a magas DPI-monitorokon. A dinamikus DPI megváltoztatja az űrlapok és vezérlők elrendezését és megjelenését, amikor a felhasználó módosítja egy futó alkalmazás DPI-jét vagy megjelenítési méretezési tényezőjét.

A magas DPI-támogatás egy választható funkció, amelyet úgy konfigurálhat, hogy definiál egy <System.Windows.Forms.ConfigurationSection> szakaszt az alkalmazáskonfigurációs fájlban. A magas DPI-támogatás és a dinamikus DPI-támogatás Windows Forms alkalmazáshoz való hozzáadásáról további információt a A DPI-támogatás Windows Forms című témakörben talál.

Windows Presentation Foundation (WPF)

A .NET Framework 4.7-ben a WPF a következő fejlesztéseket tartalmazza:

Windows WM_POINTER üzeneteken alapuló érintés/ceruza támogatás

Mostantól a WM_POINTER üzeneteken alapuló érintéses/toll alapú megoldást használhat a Windows Szabadkézi Szolgáltatások Platform (WISP) helyett. Ez a .NET-keretrendszerben található bejelentkezési funkció. További információ: alkalmazáskompatibilitási szakasz.

Új implementáció WPF nyomtatási API-khoz

WPF System.Printing.PrintQueue osztályban található nyomtatási API-k az elavult XPS Nyomtatási API helyett a Windows Nyomtatási csomag API-t hívják meg. A változás alkalmazáskompatibilitásra gyakorolt hatásáról az alkalmazáskompatibilitási című szakaszban olvashat.

A .NET Framework 4.6.2 újdonságai

.NET Framework 4.6.2 az alábbi területeken tartalmaz új funkciókat:

A .NET Framework 4.6.2-es verziójához hozzáadott új API-k listáját a GitHub .NET Framework 4.6.2 API-módosításai című témakörben találja. A .NET Framework 4.6.2 szolgáltatásfejlesztéseinek és hibajavításainak listáját a GitHub .NET Framework 4.6.2 Változások listája című témakörben találja. További információ: A .NET Framework 4.6.2 bejelentése a .NET blogban.

ASP.NET

A .NET Framework 4.6.2-ben ASP.NET a következő fejlesztéseket tartalmazza:

Az adatjegyzet-érvényesítők honosított hibaüzeneteinek továbbfejlesztett támogatása

Az adatjegyzet-érvényesítők lehetővé teszik az érvényesítést egy vagy több attribútum osztálytulajdonsághoz való hozzáadásával. Az attribútum ValidationAttribute.ErrorMessage eleme határozza meg a hibaüzenet szövegét, ha az ellenőrzés sikertelen. A .NET Framework 4.6.2-től kezdve a ASP.NET megkönnyíti a hibaüzenetek honosítását. A hibaüzenetek a következő esetekben lesznek honosítva:

  1. A ValidationAttribute.ErrorMessage az érvényesítési attribútumban található.

  2. Az erőforrásfájl a App_LocalResources mappában van tárolva.

  3. A honosított erőforrásfájl neve DataAnnotation.Localization.{name}.resxalakú, ahol a name egy kultúra nevének a formátuma languageCode-country/regionCode vagy languageCode.

  4. Az erőforrás kulcsneve a ValidationAttribute.ErrorMessage attribútumhoz rendelt sztring, értéke pedig a honosított hibaüzenet.

Az alábbi adatjegyzet attribútum például az alapértelmezett kultúra hibaüzenetét határozza meg egy érvénytelen minősítéshez.

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

Public Class RatingInfo
   <Required(ErrorMessage = "The rating must be between 1 and 10.")>
   <Display(Name = "Your Rating")>
   Public Property Rating As Integer = 1
End Class

Ezután létrehozhat egy DataAnnotation.Localization.fr.resx nevű erőforrásfájlt, amelynek kulcsa a hibaüzenet sztringje, és amelynek értéke a honosított hibaüzenet. A fájlt a App.LocalResources mappában kell megtalálni. Például a következő a kulcs és annak értéke egy honosított francia (fr) nyelvű hibaüzenetben:

Név Érték
A minősítésnek 1 és 10 közöttinek kell lennie. La note doit être entre 1 et 10.

Emellett az adatjelölés lokalizációja bővíthető. A fejlesztők a IStringLocalizerProvider felület implementálásával csatlakoztathatják a saját sztring-honosító szolgáltatójukat, hogy a honosítási sztringet máshol tárolják, mint egy erőforrásfájlban.

aszinkron támogatás a munkamenet-állapottár-szolgáltatókkal

ASP.NET mostantól lehetővé teszi a feladat-visszaváltozó metódusok használatát a munkamenet-állapottár-szolgáltatókkal, ezáltal lehetővé téve ASP.NET alkalmazások számára az aszinkron skálázhatósági előnyeit. A munkamenet-állapottár-szolgáltatókkal végzett aszinkron műveletek támogatásához ASP.NET tartalmaz egy új felületet, a System.Web.SessionState.ISessionStateModule, amely a IHttpModule-tól öröklődik, és lehetővé teszi a fejlesztők számára, hogy saját munkamenet-állapot modult és aszinkron munkamenettároló-szolgáltatókat implementáljanak. Az interfész a következőképpen van definiálva:

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

Public Interface ISessionStateModule : Inherits IHttpModule
   Sub ReleaseSessionState(context As HttpContext)
   Function ReleaseSessionStateAsync(context As HttpContext) As Task
End Interface

Emellett a SessionStateUtility osztály két új metódust is tartalmaz, IsSessionStateReadOnly és IsSessionStateRequired, amelyek az aszinkron műveletek támogatására használhatók.

kimeneti gyorsítótár-szolgáltatók aszinkron támogatása

A .NET Framework 4.6.2-től kezdve a feladat-visszatérési módszerek a kimeneti gyorsítótár-szolgáltatókkal is használhatók az aszinkron skálázhatósági előnyeinek biztosításához. Az ezeket a módszereket megvalósító szolgáltatók csökkentik a webkiszolgálók szálblokkolását, és javítják a ASP.NET szolgáltatás méretezhetőségét.

A következő API-k lettek hozzáadva az aszinkron kimeneti gyorsítótár-szolgáltatók támogatásához:

Karakter kategóriák

A .NET Framework 4.6.2-ben szereplő karakterek besorolása a Unicode Standard 8.0.0 alapján van besorolva. A .NET Framework 4.6 és .NET Framework 4.6.1-ben a karakterek Unicode 6.3 karakterkategóriák alapján lettek besorolva.

A Unicode 8.0 támogatása a karakterek CharUnicodeInfo osztály általi besorolására, valamint az arra épülő típusokra és metódusokra korlátozódik. Ezek közé tartozik a StringInfo osztály, a túlterhelt Char.GetUnicodeCategory metódus, valamint a character osztályok amelyeket a .NET Framework reguláris kifejezésmotor ismer fel. A karakter- és sztring-összehasonlítást és -rendezést ez a változás nem érinti, és továbbra is az alapul szolgáló operációs rendszerre vagy Windows 7 rendszerekre támaszkodik a .NET Framework által biztosított karakteradatokra.

A Unicode 6.0-ról Unicode 7.0-ra módosított karakterkategóriákról a Unicode Konzorcium webhelyén A Unicode Standard 7.0.0-s verziójának című témakörben talál további információt. A Unicode 7.0-ról Unicode 8.0-ra való módosításokat a Unicode Consortium webhelyén A Unicode Standard 8.0.0-s verziójának című témakörben talál.

Kriptográfia

FIPS 186-3 DSA tartalmazó X509-tanúsítványok támogatása

.NET Framework 4.6.2 támogatja a DSA (digitális aláírási algoritmus) X509-tanúsítványokat, amelyek kulcsai túllépik a FIPS 186-2 1024 bites korlátját.

A FIPS 186-3 nagyobb kulcsméreteinek támogatása mellett a .NET Framework 4.6.2 lehetővé teszi az sha-2 kivonatoló algoritmuscsalád (SHA256, SHA384 és SHA512) számítástechnikai aláírásainak használatát. A FIPS 186-3 támogatást az új System.Security.Cryptography.DSACng osztály biztosítja.

A .NET Framework 4.6 RSA osztályának és a .NET Framework 4.6.1 ECDsa osztályának legutóbbi változásainak megfelelően a .NET Framework 4.6.2 DSA absztrakt alaposztálya további metódusokat tartalmaz, amelyek lehetővé teszik a hívók számára, hogy ezt a funkciót típuskonverzió nélkül használják. Az adatok aláírásához meghívhatja a DSACertificateExtensions.GetDSAPrivateKey bővítménymetódust, ahogy az az alábbi példában is látható.

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

Public Shared Function SignDataDsaSha384(data As Byte(), cert As X509Certificate2) As Byte()
    Using DSA As DSA = cert.GetDSAPrivateKey()
        Return DSA.SignData(data, HashAlgorithmName.SHA384)
    End Using
End Function

Az aláírt adatok ellenőrzéséhez pedig meghívhatja a DSACertificateExtensions.GetDSAPublicKey bővítménymetódust, ahogyan az az alábbi példában is látható.

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

 Public Shared Function VerifyDataDsaSha384(data As Byte(), signature As Byte(), cert As X509Certificate2) As Boolean
    Using dsa As DSA = cert.GetDSAPublicKey()
        Return dsa.VerifyData(data, signature, HashAlgorithmName.SHA384)
    End Using
End Function

Az ECDiffieHellman kulcs származtatási rutinjaihoz való bemenetek nagyobb átláthatósága

.NET Framework 3.5 három különböző KDF-rutinnal bővítette az elliptikus görbe Diffie-Hellman kulcsszerződés támogatását. A rutinok bemenetei és maguk a rutinok a ECDiffieHellmanCng objektum tulajdonságain keresztül lettek konfigurálva. Mivel azonban nem minden rutin olvasta be az összes bemeneti tulajdonságot, jelentős zavart okozhatott a fejlesztőknek.

A .NET Framework 4.6.2-ben a következő három metódust adták hozzá a ECDiffieHellman alaposztályhoz, hogy jobban képviseljék ezeket a KDF-rutinokat és azok bemeneteit:

ECDiffieHellman metódus Leírás
DeriveKeyFromHash(ECDiffieHellmanPublicKey, HashAlgorithmName, Byte[], Byte[]) A fő anyag származtatása a képlet használatával

HASH(secretPrepend || x || secretAppend)

HASH(secretPrepend OrElse x OrElse secretAppend)

ahol x az EC Diffie-Hellman algoritmus kiszámított eredménye.
DeriveKeyFromHmac(ECDiffieHellmanPublicKey, HashAlgorithmName, Byte[], Byte[], Byte[]) A fő anyag származtatása a képlet használatával

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

HMAC(hmacKey, secretPrepend OrElse x OrElse secretAppend)

ahol x az EC Diffie-Hellman algoritmus kiszámított eredménye.
DeriveKeyTls(ECDiffieHellmanPublicKey, Byte[], Byte[]) A kulcsanyagot a TLS pszeudo-véletlenszerű függvény (PRF) származtatási algoritmusával nyeri ki.

A tartós kulcsú szimmetrikus titkosítás támogatása

A Windows titkosítási kódtár (CNG) támogatja a megmaradó szimmetrikus kulcsok tárolását és a hardver által tárolt szimmetrikus kulcsok használatát, és .NET Framework 4.6.2 lehetővé tette a fejlesztők számára a funkció használatát. Mivel a kulcsnevek és kulcsszolgáltatók fogalma implementációspecifikus, ennek a funkciónak a használatához a konkrét implementációtípusok konstruktorát kell használni az előnyben részesített gyári megközelítés helyett (például Aes.Createhívása).

Az AES (AesCng) és a 3DES (TripleDESCng) algoritmusok esetében létezik tartós kulcs szimmetrikus titkosítási támogatás. Például:

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

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

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

Public Shared Function EncryptDataWithPersistedKey(data As Byte(), iv As Byte()) As Byte()
    Using Aes As Aes = New AesCng("AesDemoKey", CngProvider.MicrosoftSoftwareKeyStorageProvider)
        Aes.IV = iv

        ' Using the zero-argument overload Is required to make use of the persisted key
        Using encryptor As ICryptoTransform = Aes.CreateEncryptor()
            If Not encryptor.CanTransformMultipleBlocks Then
                Throw New InvalidOperationException("This is a sample, this case wasn't handled...")
            End If
            Return encryptor.TransformFinalBlock(data, 0, data.Length)
        End Using
    End Using
End Function

SignedXml támogatása az SHA-2 hash-eléséhez

.NET Framework 4.6.2 támogatja az RSA-SHA256, RSA-SHA384 és RSA-SHA512 PKCS#1 aláírási metódusok és SHA256, SHA384 és SHA512 referencia-kivonatoló algoritmusok SignedXml osztályát.

Minden URI-állandó ki van téve a következő helyen: SignedXml:

SignedXml mező Állandó
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"

Azok a programok, amelyek egyéni SignatureDescription kezelőt regisztráltak a CryptoConfig-be, hogy támogatást adjanak ezekhez az algoritmusokhoz, továbbra is ugyanúgy fognak működni, mint korábban, de mivel már vannak platformalapértelmezettek, a CryptoConfig regisztrációra már nincs szükség.

SqlClient

.NET Keretrendszer adatkapcsolat-kezelője az SQL Serverhez (System.Data.SqlClient) a következő új funkciókat tartalmazza a .NET Framework 4.6.2-ben:

Kapcsolat csoportosítás és kapcsolat időkorlátok Azure SQL adatbázisokkal

Ha engedélyezve van a kapcsolatkészletezés, és időtúllépés vagy más bejelentkezési hiba történik, a rendszer kivételt gyorsítótáraz, és a gyorsítótárazott kivételt dobja minden következő kapcsolati kísérletnél az 5 másodperc és 1 perc közötti időszakban. További információ: SQL Server Kapcsolatkészletezés (ADO.NET).

Ez a viselkedés nem kívánatos az Azure SQL-adatbázisokhoz való csatlakozáskor, mivel a kapcsolati kísérletek átmeneti hibákkal meghiúsulhatnak, amelyek általában gyorsan helyreállnak. A kapcsolat újrapróbálkozási élményének jobb optimalizálása érdekében a rendszer eltávolítja a kapcsolatkészlet blokkolási időszakának viselkedését, ha a Azure SQL adatbázisokhoz való csatlakozás sikertelen.

Az új PoolBlockingPeriod kulcsszó hozzáadásával kiválaszthatja az alkalmazáshoz leginkább illő blokkolási időszakot. Az értékek a következők:

Auto

Az Azure SQL Database csatlakozó alkalmazások kapcsolatkészlet-blokkolási időszaka le van tiltva, és engedélyezve van a kapcsolatkészlet blokkolási időszaka egy olyan alkalmazás esetében, amely bármely más SQL Server-példányhoz csatlakozik. Ez az alapértelmezett érték. Ha a kiszolgáló végpontjának neve az alábbiak bármelyikével végződik, Azure SQL adatbázisoknak minősülnek:

  • .database.windows.net

  • .database.chinacloudapi.cn

  • .database.usgovcloudapi.net

  • .database.cloudapi.de

AlwaysBlock

A kapcsolatkészlet blokkolási időszaka mindig engedélyezve van.

NeverBlock

A kapcsolatkészlet blokkolási időszaka mindig ki van kapcsolva.

Továbbfejlesztések az Always Encrypted számára

Az SQLClient két fejlesztést vezet be az Always Encryptedhez:

  • A titkosított adatbázisoszlopok paraméteres lekérdezéseinek teljesítményének javítása érdekében a rendszer gyorsítótárazza a lekérdezési paraméterek titkosítási metaadatait. Ha az SqlConnection.ColumnEncryptionQueryMetadataCacheEnabled tulajdonság értéke true (ez az alapértelmezett érték), ha ugyanazt a lekérdezést többször is meghívják, az ügyfél csak egyszer kéri le a paraméter metaadatait a kiszolgálóról.

  • A kulcsgyorsítótár oszloptitkosítási kulcs bejegyzéseit a rendszer egy konfigurálható időintervallum után kiüríti, amelyet a SqlConnection.ColumnEncryptionKeyCacheTtl tulajdonság használatával állít be.

Windows Communication Foundation

A .NET Framework 4.6.2-ben a Windows Communication Foundation a következő területeken bővült:

WCF átviteli biztonsági támogatása a CNG- használatával tárolt tanúsítványokhoz

A WCF átviteli biztonsága támogatja a Windows titkosítási kódtár (CNG) használatával tárolt tanúsítványokat. A .NET Framework 4.6.2-ben ez a támogatás csak olyan nyilvános kulccsal rendelkező tanúsítványok használatára korlátozódik, amelyek kitevője legfeljebb 32 bit hosszúságú. Ha egy alkalmazás .NET Framework 4.6.2-t céloz meg, ez a funkció alapértelmezés szerint be van kapcsolva.

A .NET Framework 4.6.1-es és korábbi verzióit célzó, de .NET Framework 4.6.2-es verzióján futó alkalmazások esetében ez a funkció a <runtime> fájl app.config vagy web.config szakaszához való hozzáadásával engedélyezhető.

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

Ez programozott módon is elvégezhető az alábbi kóddal:

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

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

Jobb támogatás a többféle nyári időszámítási szabály beállításhoz a DataContractJsonSerializer osztály által

Az ügyfelek alkalmazáskonfigurációs beállítással megállapíthatják, hogy a DataContractJsonSerializer osztály támogatja-e egy adott időzóna több beállítási szabályát. Ez egy bejelentkezési funkció. Az engedélyezéshez adja hozzá a következő beállítást a app.config fájlhoz:

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

Ha ez a funkció engedélyezve van, egy DataContractJsonSerializer objektum a TimeZoneInfo típus helyett a TimeZone típust használja a dátum- és időadatok deszerializálásához. TimeZoneInfo több kiigazítási szabályt is támogat, ami lehetővé teszi a korábbi időzónák adatainak használatát; TimeZone nem.

A TimeZoneInfo struktúrával és időzóna-módosításokkal kapcsolatos további információkért lásd időzóna áttekintése.

NetNamedPipeBinding legjobb egyezése

A WCF egy új alkalmazásbeállítással rendelkezik, amely beállítható az ügyfélalkalmazásokon, hogy mindig a kérésnek megfelelő URI-n keresztül csatlakozzanak a szolgáltatáshoz. Ezzel az alkalmazásbeállítással false (az alapértelmezett) esetén a NetNamedPipeBinding-et használó ügyfelek megpróbálhatnak csatlakozni egy olyan szolgáltatáshoz, amely egy URI-t figyel, amely a kért URI egy részszövege.

Egy ügyfél például megpróbál csatlakozni egy net.pipe://localhost/Service1figyelő szolgáltatáshoz, de a rendszergazdai jogosultsággal rendelkező gépen egy másik szolgáltatás figyeli a net.pipe://localhost. Ha az alkalmazás beállítása false, az ügyfél nem a megfelelő szolgáltatáshoz próbál csatlakozni. Miután az alkalmazásbeállítást trueértékre állítja, az ügyfél mindig a legjobb egyező szolgáltatáshoz fog csatlakozni.

Jegyzet

Az NetNamedPipeBinding használó ügyfelek a szolgáltatás alapcíme (ha létezik) alapján keresnek szolgáltatásokat a teljes végpontcím helyett. Annak érdekében, hogy ez a beállítás mindig működjön, a szolgáltatásnak egyedi alapcímet kell használnia.

A módosítás engedélyezéséhez adja hozzá az alábbi alkalmazásbeállítást az ügyfélalkalmazás App.config vagy Web.config fájljához:

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

SSL 3.0 nem alapértelmezett protokoll

Ha a NetTcp átviteli biztonsággal és hitelesítő adat típusú tanúsítvánnyal rendelkezik, az SSL 3.0 már nem egy alapértelmezett protokoll a biztonságos kapcsolat egyeztetéséhez. A legtöbb esetben nincs hatással a meglévő alkalmazásokra, mivel a TLS 1.0 szerepel a NetTcp protokolllistájában. Minden meglévő ügyfélnek legalább TLS 1.0 használatával meg kell tudnia egyeztetni a kapcsolatot. Ha ssl3 szükséges, az alábbi konfigurációs mechanizmusok egyikével vegye fel a tárgyalásos protokollok listájára.

Windows Presentation Foundation (WPF)

A .NET Framework 4.6.2-ben a Windows Presentation Foundation a következő területeken bővült:

Csoportok rendezése

Az adatok csoportosításához CollectionView objektumot használó alkalmazások mostantól explicit módon deklarálhatják a csoportok rendezésének módját. Az explicit rendezés a nem intuitív rendezés problémáját kezeli, amely akkor fordul elő, amikor egy alkalmazás dinamikusan hozzáad vagy eltávolít csoportokat, vagy ha módosítja a csoportosításban érintett elemtulajdonságok értékét. A csoportlétrehozási folyamat teljesítményét úgy is javíthatja, hogy a csoportosítási tulajdonságok összehasonlítását a teljes gyűjteményből a csoportok soraiba helyezi át.

A csoportrendezés támogatásához az új GroupDescription.SortDescriptions és GroupDescription.CustomSort tulajdonságok azt írják le, hogyan rendezheti a GroupDescription objektum által létrehozott csoportok gyűjteményét. Ez hasonló ahhoz, ahogyan az azonos nevű ListCollectionView tulajdonságok az adatelemek rendezését írják le.

A leggyakoribb esetekben a PropertyGroupDescription osztály két új statikus tulajdonsága, a CompareNameAscending és a CompareNameDescendinghasználható.

Az alábbi XAML-csoportok például életkor szerint csoportosítják az adatokat, növekvő sorrendbe rendezik a korcsoportokat, és vezetéknév szerint csoportosítják az egyes korcsoportok elemeit.

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

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

Érintőképernyős billentyűzet támogatása

Az érintéses billentyűzet támogatása lehetővé teszi a fókuszkövetést WPF alkalmazásokban az érintéses billentyűzet automatikus meghívásával és elvetésével Windows 10, amikor az érintéses bemenetet olyan vezérlő fogadja, amely szöveges bemenetet tud fogadni.

A .NET-keretrendszer korábbi verzióiban WPF alkalmazások nem tudnak a fókuszkövetést választani anélkül, hogy letiltanák WPF toll/érintéses kézmozdulat támogatását. Ennek eredményeképpen WPF alkalmazásoknak választaniuk kell a teljes WPF érintéses támogatás között, vagy Windows egér-előléptetésre kell támaszkodniuk.

Monitoronkénti DPI

A közelmúltban elterjedt magas DPI- és hibrid DPI-környezetek támogatására a WPF alkalmazásokban a .NET Framework 4.6.2-ben bevezették a monitoronkénti DPI-kezelést. Keresse a Minták és Fejlesztői útmutató elemet a GitHubon további információért arról, hogyan teheti a WPF-alkalmazását monitoronkénti DPI-tudatossá.

A .NET Framework korábbi verzióiban WPF alkalmazások rendszer DPI-vel vannak tisztában. Más szóval az alkalmazás felhasználói felületét az operációs rendszer szükség szerint skálázza annak a monitornak a DPI-jától függően, amelyen az alkalmazás megjelenik.

A .NET Framework 4.6.2-es verziójában futó alkalmazások esetében letilthatja WPF alkalmazások monitoronkénti DPI-módosításait úgy, hogy hozzáad egy konfigurációs utasítást a <runtime> alkalmazáskonfigurációs fájlhoz az alábbiak szerint:

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

Windows Workflow Foundation (WF)

A .NET Framework 4.6.2-ben a Windows Workflow Foundation a következő területen lett továbbfejlesztve:

C#-kifejezések és IntelliSense támogatása az újrahosztolt WF Designerben

A .NET Framework 4.5-től kezdve a WF támogatja a C#-kifejezéseket mind a Visual Studio Designerben, mind a kód-munkafolyamatokban. Az áthelyezett munkafolyamat-tervező a WF egyik fő funkciója, amely lehetővé teszi, hogy a Munkafolyamat-tervező egy Visual Studio kívüli alkalmazásban legyen (például WPF). Windows Workflow Foundation lehetővé teszi a C#-kifejezések és az IntelliSense támogatását az áthelyezett munkafolyamat-tervezőben. További információ: Windows Workflow Foundation blog.

Availability of IntelliSense when a customer rebuilds a workflow project from Visual Studio A .NET-keretrendszer 4.6.2 előtti verzióiban a WF Designer IntelliSense megszakad, amikor egy ügyfél újraépít egy munkafolyamat-projektet Visual Studio. Bár a projekt buildelése sikeres, a munkafolyamat-típusok nem találhatók a tervezőben, és az IntelliSense figyelmeztetései a hiányzó munkafolyamattípusokra vonatkozóan megjelennek a hibalista ablakban. .NET Framework 4.6.2 kezeli ezt a problémát, és elérhetővé teszi az IntelliSense-t.

V1-munkafolyamat alkalmazások a Workflow Tracking funkcióval mostantól FIPS módban futnak

Az engedélyezett FIPS megfelelőségi móddal rendelkező gépek mostantól sikeresen futtathatnak egy 1-es verziójú munkafolyamat-alkalmazást, amelyen a munkafolyamat-nyomkövetés be van kapcsolva. A forgatókönyv engedélyezéséhez az alábbi módosításokat kell végrehajtania a app.config fájlon:

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

Ha ez a forgatókönyv nincs engedélyezve, az alkalmazás futtatása továbbra is kivételt okoz a következő üzenettel: "Ez a megvalósítás nem része a Windows platform FIPS által ellenőrzött titkosítási algoritmusainak."

Munkafolyam fejlesztései a dinamikus frissítés Visual Studio Munkafolyamat-tervezővel való használatakor

A Munkafolyamat-tervező, a Folyamatábra tevékenységtervező és más munkafolyamat-tevékenységtervezők mostantól sikeresen betöltik és megjelenítik a DynamicUpdateServices.PrepareForUpdate metódus meghívása után mentett munkafolyamatokat. A .NET-keretrendszer .NET Framework 4.6.2 előtti verzióiban a Visual Studio egy XAML-fájl betöltése a DynamicUpdateServices.PrepareForUpdate hívása után mentett munkafolyamathoz az alábbi problémákat okozhatja:

  • A Munkafolyamat-tervező nem tudja megfelelően betölteni az XAML-fájlt (ha a ViewStateData.Id a sor végén található).

  • A folyamatábra tevékenységtervezője vagy más munkafolyamat-tevékenységtervezők a csatolt tulajdonságértékek helyett az összes objektumot megjeleníthetik az alapértelmezett helyükön.

ClickOnce

A ClickOnce a már támogatott 1.0 protokoll mellett a TLS 1.1 és a TLS 1.2 támogatására lett frissítve. A ClickOnce automatikusan észleli, hogy melyik protokollra van szükség; A ClickOnce alkalmazáson belül nincs szükség további lépésekre a TLS 1.1 és 1.2 támogatásának engedélyezéséhez.

Windows Forms és WPF alkalmazások átalakítása UWP-alkalmazásokká

Windows mostantól a meglévő Windows asztali alkalmazásokat, köztük WPF és Windows Forms alkalmazásokat is elérhetővé teszi a Universal Windows Platform (UWP). Ez a technológia hídként működik azáltal, hogy lehetővé teszi a meglévő kódbázis fokozatos migrálását az UWP-be, ezáltal az alkalmazást az összes Windows 10 eszközre elérhetővé teszi.

Az átalakított asztali alkalmazások az UWP-alkalmazások alkalmazási identitásához hasonló alkalmazásidentitást kapnak, ami akadálymentessé teszi az UWP API-kat az olyan funkciók engedélyezéséhez, mint az élő csempék és az értesítések. Az alkalmazás továbbra is ugyanúgy működik, mint korábban, és teljes megbízhatósági alkalmazásként fut. Az alkalmazás konvertálása után egy alkalmazástároló-folyamat hozzáadható a meglévő teljes megbízhatósági folyamathoz egy adaptív felhasználói felület hozzáadásához. Amikor az összes funkció átkerül az alkalmazástároló folyamatába, a teljes megbízhatósági folyamat eltávolítható, és az új UWP-alkalmazás elérhetővé tehető az összes Windows 10 eszköz számára.

hibakeresési fejlesztések

A nem felügyelt hibakeresési API .NET Framework 4.6.2-es verziójában továbbfejlesztettük, hogy további elemzéseket hajthassunk végre egy NullReferenceException dobásakor, így meghatározható, hogy egy forráskódsor melyik változója null. A forgatókönyv támogatásához a következő API-k lettek hozzáadva a nem felügyelt hibakeresési API-hoz.

  • Az ICorDebugCode4, ICorDebugVariableHomeés ICorDebugVariableHomeEnum felületek, amelyek a felügyelt változók natív otthonait teszik elérhetővé. Ez lehetővé teszi, hogy a hibakeresők kódfolyamat-elemzést végezzenek egy NullReferenceException bekövetkezésekor, és visszafelé dolgozva meghatározzák a felügyelt változót, amely megfelel a nullnatív helynek.

  • A ICorDebugType2::GetTypeID metódus egy leképezést biztosít az ICorDebugType és a COR_TYPEIDközött, amely lehetővé teszi a hibakereső számára, hogy ICorDebugType példány nélkül is megszerezzen egy COR_TYPEID-t. A COR_TYPEID meglévő API-jait ezután használhatja a típus osztályelrendezésének meghatározásához.

A .NET Framework 4.6.1 újdonságai

.NET Framework 4.6.1 az alábbi területeken tartalmaz új funkciókat:

A .NET Framework 4.6.1-ről az alábbi témakörökben talál további információt:

Titkosítás: ECDSA-t tartalmazó X509-tanúsítványok támogatása

.NET Framework 4.6 hozzáadott RSACng-támogatást az X509-tanúsítványokhoz. .NET Framework 4.6.1 támogatja az ECDSA (Elliptic Curve Digital Signature Algorithm) X509-tanúsítványokat.

Az ECDSA jobb teljesítményt nyújt, és biztonságosabb titkosítási algoritmus, mint az RSA, kiváló választás, ahol a Transport Layer Security (TLS) teljesítménye és méretezhetősége aggodalomra ad okot. A .NET-keretrendszer implementációja a hívásokat a meglévő Windows funkciókba csomagolja.

Az alábbi példakód bemutatja, milyen egyszerű aláírást létrehozni egy bájtfolyamhoz a .NET Framework 4.6.1-ben található ECDSA X509-tanúsítványok új támogatásával.

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

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

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

Imports System.Security.Cryptography
Imports System.Security.Cryptography.X509Certificates

Public Class Net461Code
    Public Shared Function SignECDsaSha512(data As Byte(), cert As X509Certificate2) As Byte()
        Using privateKey As ECDsa = cert.GetECDsaPrivateKey()
            Return privateKey.SignData(data, HashAlgorithmName.SHA512)
        End Using
    End Function

    Public Shared Function SignECDsaSha512(data As Byte, privateKey As ECDsa) As Byte()
        Return privateKey.SignData(data, HashAlgorithmName.SHA512)
    End Function
End Class

Ez markáns kontrasztot biztosít az aláírás létrehozásához szükséges kóddal a .NET Framework 4.6-ban.

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

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

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

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

Imports System.Security.Cryptography
Imports System.Security.Cryptography.X509Certificates

Public Class Net46Code
    Public Shared Function SignECDsaSha512(data As Byte(), cert As X509Certificate2) As Byte()
        ' This would require using cert.Handle and a series of p/invokes to get at the
        ' underlying key, then passing that to a CngKey object, and passing that to
        ' new ECDsa(CngKey).  It's a lot of work.
        Throw New Exception("That's a lot of work...")
    End Function

    Public Shared Function SignECDsaSha512(data As Byte(), privateKey As ECDsa) As Byte()
        ' This way works, but SignData probably better matches what you want.
        Using hasher As SHA512 = SHA512.Create()
            Dim signature1 As Byte() = privateKey.SignHash(hasher.ComputeHash(data))
        End Using

        ' This might not be the ECDsa you got!
        Dim ecDsaCng As ECDsaCng = CType(privateKey, ECDsaCng)
        ecDsaCng.HashAlgorithm = CngAlgorithm.Sha512
        Return ecDsaCng.SignData(data)
    End Function
End Class

ADO.NET

A következők kerültek hozzáadásra az ADO.NET-hez:

Always Encrypted támogatása hardveres védelemmel ellátott kulcsokhoz

Az ADO.NET mostantól támogatja az Always Encrypted oszlop főkulcsainak natív tárolását a hardveres biztonsági modulokban (HSM-ekben). Ezzel a támogatással az ügyfelek anélkül használhatják a HSM-ben tárolt aszimmetrikus kulcsokat, hogy egyéni oszlop főkulcstároló-szolgáltatókat kellene írniuk, és regisztrálniuk kellene őket az alkalmazásokban.

Az ügyfeleknek telepíteniük kell a HSM szállító által biztosított CSP-szolgáltatót vagy CNG-kulcstároló-szolgáltatókat az alkalmazáskiszolgálókra vagy ügyfélszámítógépekre, hogy hozzáférjenek a HSM-ben tárolt oszlop-főkulcsokkal védett Always Encrypted-adatokhoz.

Továbbfejlesztett MultiSubnetFailover kapcsolat viselkedése az AlwaysOn esetében

Az SqlClient mostantól automatikusan gyorsabb kapcsolatokat biztosít egy AlwaysOn rendelkezésre állási csoporthoz (AG). Transzparensen észleli, hogy az alkalmazás egy másik alhálózaton lévő AlwaysOn rendelkezésre állási csoporthoz (AG) csatlakozik-e, és gyorsan felderíti az aktuális aktív kiszolgálót, és kapcsolatot biztosít a kiszolgálóval. A kiadás előtt egy alkalmazásnak úgy kellett beállítania a connection string, hogy tartalmazza a "MultisubnetFailover=true", hogy jelezze, hogy egy AlwaysOn rendelkezésre állási csoporthoz kapcsolódik. A kapcsolati kulcsszó truebeállítása nélkül előfordulhat, hogy egy alkalmazás időtúllépést tapasztal egy AlwaysOn rendelkezésre állási csoporthoz való csatlakozáskor. Ezzel a kiadással az alkalmazásnak többé nem kell MultiSubnetFailovertrue beállítania. Az Always On rendelkezésre állási csoportok SqlClient-támogatásáról további információt a SqlClient magas rendelkezésre állású és vészhelyreállításicímű témakörben talál.

Windows Presentation Foundation (WPF)

Windows Presentation Foundation számos fejlesztést és módosítást tartalmaz.

Jobb teljesítmény

A tüzelési érintéses események késleltetését kijavítottuk .NET Framework 4.6.1-ben. Ezenkívül a RichTextBox vezérlőbe való gépelés többé nem akasztja meg a renderelési szálat gyors bemenet közben.

Helyesírás-ellenőrzési fejlesztések

A WPF helyesírás-ellenőrzője Windows 8.1 és újabb verziókon frissült, hogy az operációs rendszer további nyelveket is használjon a helyesírás-ellenőrzéshez. A Windows 8.1 előtti Windows verziók funkciói nem változnak.

A .NET-keretrendszer korábbi verzióihoz hasonlóan az TextBox vezérlőelem vagy a RichTextBox blokk nyelvét is észleli a rendszer az alábbi sorrendben történő információkereséssel:

  • xml:lang, ha jelen van.

  • Aktuális beviteli nyelv.

  • Jelenlegi kultúra.

A WPF nyelvi támogatásáról további információt a .NET Framework 4.6.1 funkcióiról szóló WPF blogbejegyzésben talál.

Felhasználónkénti egyéni szótárak további támogatása

A .NET Framework 4.6.1-ben WPF felismeri a globálisan regisztrált egyéni szótárakat. Ez a képesség azon kívül is elérhető, hogy vezérlőnként regisztrálja őket.

A WPF korábbi verzióiban a saját szótárak nem ismerik fel a kizárt szavakat és az automatikus javítási listákat. A Windows 8.1 és Windows 10 a %AppData%\Microsoft\Spelling\<language tag> könyvtár alá helyezhető fájlok használatával támogatottak. A következő szabályok vonatkoznak ezekre a fájlokra:

  • A fájloknak .dic (hozzáadott szavak esetén), .exc (kizárt szavak esetén) vagy .acl (automatikus javítás esetén) kiterjesztéssel kell rendelkezniük.

  • A fájloknak UTF-16 LE egyszerű szövegnek kell lenniük, amely a byte order mark (BOM) kezdetű.

  • Minden sornak egy szóból (a hozzáadott és kizárt szólistákból) vagy egy automatikus javítási párból kell állnia, amelynek a szavait függőleges sáv ("|") választja el egymástól. (az Automatikus javítás szólistában).

  • Ezek a fájlok írásvédettnek minősülnek, és a rendszer nem módosítja őket.

Jegyzet

Ezeket az új fájlformátumokat nem támogatják közvetlenül a WPF helyesírás-ellenőrző API-k, és az alkalmazásokban a WPF számára biztosított egyéni szótáraknak továbbra is .lex fájlokat kell használniuk.

Minták

Számos WPF minta található a Microsoft/WPF-Samples GitHub adattárban. Segítség a minták fejlesztéséhez egy lekéréses kérelem elküldésével vagy egy GitHub probléma megnyitásával.

DirectX-bővítmények

WPF tartalmaz egy NuGet-csomagot, amely a D3DImage új implementációit biztosítja, amelyek megkönnyítik a DX10 és dx11 tartalmakkal való együttműködést. A csomag kódja nyílt forráskódú, és on GitHub érhető el.

Windows Workflow Foundation: Tranzakciók

A Transaction.EnlistPromotableSinglePhase metódus mostantól az MSDTC-t kivéve egy elosztott tranzakciókezelőt is használhat a tranzakció előléptetéséhez. Ehhez meg kell adnia egy GUID azonosítót a tranzakciótámogató számára az új Transaction.EnlistPromotableSinglePhase(IPromotableSinglePhaseNotification, Guid) túlterheléshez. Ha ez a művelet sikeres, korlátozások vonatkoznak a tranzakció képességeire. Ha egy nem-MSDTC tranzakciós terjesztő be van jegyezve, a következő eljárások TransactionPromotionException hibát adnak, mert ezek az eljárások előléptetést igényelnek MSDTC-re.

Amint egy nem MSDTC-tranzakciós előléptetőt felvesznek, azt a jövőbeli tartós csatlakozásokhoz az általa meghatározott protokollok használatával kell alkalmazni. A tranzakciószervező Guid megszerezhető a PromoterType tulajdonság használatával. Amikor a tranzakció előmozdul, a tranzakció elősegítője biztosít egy Byte tömböt, amely az előléptetett zsetont jelöli. Egy alkalmazás a GetPromotedToken módszerrel megszerezheti a nem-MSDTC által előléptetett tranzakcióhoz tartozó előléptetett jogkivonatot.

Az új Transaction.EnlistPromotableSinglePhase(IPromotableSinglePhaseNotification, Guid) túlterhelés felhasználóinak egy adott hívássorrendet kell követniük, hogy az előléptetési művelet sikeresen befejeződjön. Ezek a szabályok a metódus dokumentációjában vannak dokumentálva.

Profilkészítés

A nem felügyelt profilkészítési API az alábbiak szerint lett továbbfejlesztve:

  • Jobb támogatás a PDF-fájlok eléréséhez az ICorProfilerInfo7 felületen.

    Az ASP.NET Core esetében egyre gyakoribb, hogy az assembly-ket a Roslyn a memóriában fordítja le. A profilkészítési eszközöket készítő fejlesztők számára ez azt jelenti, hogy a lemezen korábban szerializált PDF-ek már nem lehetnek jelen. A profilkészítő eszközök gyakran használnak PDF-eket a kód forrássorokra való leképezéséhez olyan feladatokhoz, mint a kódlefedettség vagy a soronkénti teljesítményelemzés. Az ICorProfilerInfo7 felület mostantól két új metódust tartalmaz, ICorProfilerInfo7::GetInMemorySymbolsLength és ICorProfilerInfo7::ReadInMemorySymbols, hogy ezek a profiler-eszközök hozzáférjenek a memóriabeli PDB-adatokhoz, Az új API-k használatával a profilkészítők bájttömbként beolvashatják a memóriában lévő PDB tartalmát, majd feldolgozhatják vagy szerializálhatják a lemezre.

  • Jobb mérési eszközök az ICorProfiler felülettel.

    Az ICorProfiler API-k ReJit funkcióját dinamikus műszereléshez használó profilkészítők mostantól módosíthatnak néhány metaadatot. Korábban ezek az eszközök bármikor be tudták illeszteni az IL-t, de a metaadatok csak a modul betöltésekor módosíthatók. Mivel az IL a metaadatokra hivatkozik, ez korlátozta a megvalósítható műszerezés típusait. A ICorProfilerInfo7::ApplyMetaData metódus hozzáadásával a modul betöltése után a metaadat-módosítások egy részhalmazát támogatjuk, különösen új AssemblyRef, TypeRef, TypeSpec, MemberRef, MemberSpecés UserString rekordok hozzáadásával. Ez a változás a valós idejű mérés sokkal szélesebb körét teszi lehetővé.

Natív képgenerátor (NGEN) PDF-ek

A gépközi eseménykövetés lehetővé teszi, hogy az ügyfelek profilt készítsenek egy programról az A gépen, és a B gépen forrásvonal-leképezéssel tekintse meg a profilkészítési adatokat. A .NET-keretrendszer korábbi verzióival a felhasználó a profilozott gép összes modulját és natív rendszerképét átmásolná az il PDB-t tartalmazó elemző gépre a forrás–natív leképezés létrehozásához. Bár ez a folyamat jól működik, ha a fájlok viszonylag kicsik, például telefonos alkalmazások esetében, a fájlok nagyon nagyok lehetnek az asztali rendszereken, és jelentős időt igényelnek a másoláshoz.

NGen PDB-kkel az NGen létrehozhat egy PDB-t, amely az IL és a natív kód közötti leképezést tartalmazza, az IL PDB-hez való függőség nélkül. A gépközi eseménykövetési forgatókönyvben mindössze annyit kell tennie, hogy az A gép által létrehozott natív kép PDB-t másolja a B gépre, és használja a hibakeresési felületi hozzáférési API-kat az IL PDB forrás-IL és a natív kép PDB IL-natív leképezésének olvasásához. Mindkét leképezés kombinálása forrás–natív leképezést biztosít. Mivel a natív kép PDF-fájlja sokkal kisebb, mint az összes modul és natív rendszerkép, a másolás folyamata az A gépről a B gépre sokkal gyorsabb.

A 2015-ös .NET újdonságai

.NET 2015 .NET Framework 4.6 és .NET Core verziót vezet be. Egyes új funkciók mindkettőre érvényesek, más funkciók pedig a .NET Framework 4.6-ra vagy .NET Core-ra vonatkoznak.

  • ASP.NET Core

    .NET 2015 tartalmazza a ASP.NET Core, amely egy lean .NET implementáció a modern felhőalapú alkalmazások létrehozásához. ASP.NET Core moduláris, így csak az alkalmazáshoz szükséges funkciókat használhatja. IIS-en vagy saját üzemeltetésűen is üzemeltethető egyéni folyamatban, és ugyanazon a kiszolgálón futtathat alkalmazásokat a .NET-keretrendszer különböző verzióival. Tartalmaz egy új környezetkonfigurációs rendszert, amelyet felhőbeli üzembe helyezésre terveztek.

    Az MVC, a webes API és a weblapok egyetlen, MVC 6 nevű keretrendszerbe vannak egyesítve. A 2015-ös vagy újabb Visual Studio eszközökkel ASP.NET Core alkalmazásokat hozhat létre. A meglévő alkalmazások az új .NET-keretrendszeren fognak működni; az MVC 6-ot vagy SignalR 3-at használó alkalmazások létrehozásához azonban a 2015-ös vagy újabb Visual Studio kell használnia a projektrendszert.

    További információ: ASP.NET Core.

  • ASP.NET Frissítések

    • Feladatalapú API aszinkron válaszkiürítéshez

      ASP.NET mostantól egy egyszerű feladatalapú API-t biztosít az aszinkron válasz kiürítéséhez, HttpResponse.FlushAsync, amely lehetővé teszi a válaszok aszinkron kiürítését a nyelv async/await támogatásával.

    • modellkötés támogatja a feladatvisszaküldött metódusokat

      A .NET Framework 4.5-ben ASP.NET hozzáadta a Modellkötés funkciót, amely lehetővé tette a CRUD-alapú adatműveletek bővíthető, kódközpontú megközelítését a webes űrlapok lapjaiban és felhasználói vezérlőiben. A modellkötési rendszer mostantól támogatja Taskvisszaadott modellkötési módszereket. Ez a funkció lehetővé teszi a webűrlapok fejlesztői számára az aszinkron skálázhatósági előnyeit az adatkötési rendszer egyszerű használatával, amikor újabb ORM-verziókat használnak, beleértve az Entity Frameworkt is.

      Az aszinkron modell kötését a aspnet:EnableAsyncModelBinding konfigurációs beállítás szabályozza.

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

      Azoknál az alkalmazásoknál, amelyek a .NET Framework 4.6-ot célozzák meg, alapértelmezés szerint true. A .NET-keretrendszer egy korábbi verzióját célzó .NET Framework 4.6-os verzióján futó alkalmazások esetében alapértelmezés szerint false. Ezt úgy engedélyezheti, hogy a konfigurációs beállítást trueértékre állítja.

    • HTTP/2 támogatás (Windows 10)

      HTTP/2 a HTTP protokoll új verziója, amely sokkal jobb kapcsolatkihasználtságot biztosít (kevesebb ciklikus utazás az ügyfél és a kiszolgáló között), ami alacsonyabb késést eredményez a weblapok betöltésében a felhasználók számára. A weblapok (a szolgáltatások helyett) a HTTP/2 előnyeit élvezik a legjobban, mivel a protokoll egyetlen felület részeként több összetevőre optimalizál. Az HTTP/2 támogatás hozzá lett adva az ASP.NET-ben, a .NET Framework 4.6-ban. Mivel a hálózati funkciók több rétegben is léteznek, új funkciókra volt szükség a Windows, az IIS és a HTTP/2 engedélyezéséhez ASP.NET. A HTTP/2 és ASP.NET használatához Windows 10 kell futnia.

      A HTTP/2 az System.Net.Http.HttpClient API-t használó Windows 10 Universal Windows Platform (UWP) alkalmazások esetében is támogatott és alapértelmezés szerint be van kapcsolva.

      A PUSH_PROMISE funkció ASP.NET alkalmazásokban való használatának módja érdekében a PushPromise(String) osztályhoz hozzáadtunk egy új, két túlterheléssel rendelkező metódust, PushPromise(String, String, NameValueCollection) és HttpResponse.

      Jegyzet

      Bár ASP.NET Core támogatja a HTTP/2-t, a PUSH PROMISE funkció támogatása még nem lett hozzáadva.

      A böngésző és a webkiszolgáló (Windows IIS) végzi az összes munkát. Nem kell nehéz munkát végeznie a felhasználók érdekében.

      A fő böngészők többsége támogatja a HTTP/2, ezért valószínű, hogy a felhasználók http/2 támogatásban részesülnek, ha a kiszolgáló támogatja.

    • Token Binding Protocol támogatása

      A Microsoft és a Google együttműködik a hitelesítés új megközelítésén, az úgynevezett Token Binding Protocol. A feltételezés az, hogy a hitelesítési jogkivonatokat (a böngésző gyorsítótárában) ellophatják és felhasználhatják a bűnözők az egyébként biztonságos erőforrásokhoz (például a bankszámlájához) anélkül, hogy jelszót vagy más emelt szintű ismeretet igényelnek. Az új protokoll célja, hogy enyhítse ezt a problémát.

      A tokenkötési protokoll böngészőfunkcióként lesz implementálva Windows 10. ASP.NET alkalmazások részt vesznek a protokollban, hogy a hitelesítési jogkivonatok érvényesek legyenek. Az ügyfél és a kiszolgáló implementációi létrehozzák a protokoll által meghatározott végpontok közötti védelmet.

    • véletlen-szerű karaktersor kivonat algoritmusok

      .NET Framework 4.5 bevezetett egy véletlenszerű karakterlánc kivonatoló algoritmust. A ASP.NET azonban nem támogatta, mert bizonyos ASP.NET funkciók stabil kivonatkódtól függtek. A .NET Framework 4.6-ban mostantól támogatottak a véletlenszerű sztringkivonat-algoritmusok. A funkció engedélyezéséhez használja a aspnet:UseRandomizedStringHashAlgorithm konfigurációs beállítást.

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

  • ADO.NET

    Az ADO .NET mostantól támogatja a 2016-os SQL Server elérhető Always Encrypted funkciót. Az Always Encrypted használatával a SQL Server műveleteket hajthat végre titkosított adatokon, és a legjobb megoldás az, hogy az alkalmazás az ügyfél megbízható környezetében található, és nem a kiszolgálón. Az Always Encrypted biztonságossá teszi az ügyféladatokat, így a dbA-k nem férnek hozzá egyszerű szöveges adatokhoz. Az adatok titkosítása és visszafejtése transzparens módon történik az illesztőprogram szintjén, minimalizálva a meglévő alkalmazásokon végrehajtott módosításokat. További információ: Always Encrypted (Database Engine) és Always Encrypted (ügyfélfejlesztés).

  • 64 bites JIT fordító a felügyelt kódhoz

    .NET Framework 4.6 a 64 bites JIT-fordító (eredeti nevén RyuJIT) új verzióját tartalmazza. Az új 64 bites fordító jelentős teljesítménybeli fejlesztéseket biztosít a régebbi, 64 bites JIT-fordítóval szemben. Az új 64 bites fordító engedélyezve van a .NET Framework 4.6-on futó 64 bites folyamatokhoz. Az alkalmazás 64 bites folyamatban fog futni, ha 64 bites vagy AnyCPU-ként van lefordítva, és 64 bites operációs rendszeren fut. Bár ügyeltek arra, hogy az új fordítóra való áttérés a lehető legátláthatóbb legyen, a viselkedésbeli változások lehetségesek.

    Az új 64 bites JIT-fordító hardveres SIMD-gyorsítási funkciókat is tartalmaz, ha a SIMD-kompatibilis típusok a System.Numerics névtérben vannak, ami jó teljesítménybeli javulást eredményezhet.

  • Betöltőprogram fejlesztések

    Az szerelvénybetöltő mostantól hatékonyabban használja a memóriát, ha egy megfelelő NGEN-rendszerkép betöltése után eltávolítja az IL-szerelvényeket. Ez a változás csökkenti a virtuális memóriát, ami különösen előnyös a nagy, 32 bites alkalmazások (például Visual Studio) számára, és fizikai memóriát is megtakarít.

  • Alaposztálytár módosítása

    Számos új API-t adtak hozzá a .NET Framework 4.6-hoz a kulcsfontosságú forgatókönyvek engedélyezéséhez. Ezek közé tartoznak a következő módosítások és kiegészítések:

    • IReadOnlyCollection<T> implementációk

      A további gyűjtemények olyan IReadOnlyCollection<T> implementálnak, mint a Queue<T> és a Stack<T>.

    • CultureInfo.CurrentCulture és CultureInfo.CurrentUICulture

      A CultureInfo.CurrentCulture és CultureInfo.CurrentUICulture tulajdonságok mostantól írhatók és olvashatók, nem pedig csak olvashatók. Ha új CultureInfo objektumot rendel ezekhez a tulajdonságokhoz, a Thread.CurrentThread.CurrentCulture tulajdonság által definiált aktuális szálkultúra és a Thread.CurrentThread.CurrentUICulture tulajdonságok által definiált aktuális felhasználói felületi szálkultúra is megváltozik.

    • A szemétgyűjtés (GC) fejlesztései

      A GC osztály mostantól TryStartNoGCRegion és EndNoGCRegion metódusokat is tartalmaz, amelyekkel letilthatja a szemétgyűjtést egy kritikus útvonal végrehajtása során.

      A GC.Collect(Int32, GCCollectionMode, Boolean, Boolean) metódus új túlterhelése lehetővé teszi annak szabályozását, hogy a kis objektumcsomó és a nagy objektum halom csak söpörve és tömörítve vagy sodorva van-e.

    • SIMD-kompatibilis típusok

      A System.Numerics névtér mostantól számos SIMD-kompatibilis típust tartalmaz, például Matrix3x2, Matrix4x4, Plane, Quaternion, Vector2, Vector3és Vector4.

      Mivel az új 64 bites JIT-fordító hardveres SIMD gyorsítási funkciókat is tartalmaz, a SIMD-kompatibilis típusok és az új 64 bites JIT-fordító használata különösen jelentős teljesítménybeli javulást jelent.

    • titkosítási frissítések

      A System.Security.Cryptography API frissítése folyamatban van a Windows CNG titkosítási API-k támogatásához. A .NET-keretrendszer korábbi verziói teljes mértékben a Windows titkosítási API-k earlier verziójára támaszkodtak a System.Security.Cryptography implementáció alapjaként. Kérésünk volt a CNG API támogatására, mivel támogatja modern titkosítási algoritmusokat, amelyek bizonyos alkalmazások kategóriái számára fontosak.

      .NET Framework 4.6 a következő új fejlesztéseket tartalmazza a Windows CNG titkosítási API-k támogatásához:

      • Az X509-tanúsítványok, System.Security.Cryptography.X509Certificates.RSACertificateExtensions.GetRSAPublicKey(System.Security.Cryptography.X509Certificates.X509Certificate2) és System.Security.Cryptography.X509Certificates.RSACertificateExtensions.GetRSAPrivateKey(System.Security.Cryptography.X509Certificates.X509Certificate2)bővítménymetócióinak készlete, amelyek lehetőség szerint nem CAPI-alapú, hanem CNG-alapú implementációt adnak vissza. (Néhány intelligens kártya stb. még mindig CAPI-t igényel, és az API-k kezelik a visszaesést).

      • A System.Security.Cryptography.RSACng osztály, amely az RSA-algoritmus CNG-implementációját biztosítja.

      • Az RSA API fejlesztései, hogy a gyakori műveletekhez többé ne legyen szükség öntésre. Az adatok X509Certificate2 objektum használatával történő titkosításához például az alábbihoz hasonló kód szükséges a .NET Framework korábbi verzióiban.

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

        Dim rsa As RSACryptoServiceProvider = CType(cert.PrivateKey, RSACryptoServiceProvider)
Dim oaepEncrypted() As Byte = rsa.Encrypt(data, True)
Dim pkcs1Encrypted() As Byte = rsa.Encrypt(data, False)

        A .NET Framework 4.6-ban az új titkosítási API-kat használó kód a következőképpen írható át a típuskonverzió elkerülése érdekében.

        RSA rsa = cert.GetRSAPrivateKey();
if (rsa == null)
   throw new InvalidOperationException("An RSA certificate was expected");

byte[] oaepEncrypted = rsa.Encrypt(data, RSAEncryptionPadding.OaepSHA1);
byte[] pkcs1Encrypted = rsa.Encrypt(data, RSAEncryptionPadding.Pkcs1);

        Dim rsa As RSA = cert.GetRSAPrivateKey()
If rsa Is Nothing Then
    Throw New InvalidOperationException("An RSA certificate was expected")
End If

Dim oaepEncrypted() As Byte = rsa.Encrypt(data, RSAEncryptionPadding.OaepSHA1)
Dim pkcs1Encrypted() As Byte = rsa.Encrypt(data, RSAEncryptionPadding.Pkcs1)

    • Dátumok és időpontok Unix-időre és Unix-időről való konvertálásának támogatása

      A következő új metódusok lettek hozzáadva a DateTimeOffset struktúrához, hogy támogassák a dátum- és időértékek Unix-időre vagy Unix-időről való konvertálását:

    • kompatibilitási kapcsolók

      A AppContext osztály új kompatibilitási funkciót ad hozzá, amely lehetővé teszi a kódtár-írók számára, hogy egységes leiratkozási mechanizmust biztosítsanak az új funkciókhoz a felhasználók számára. Lazán összekapcsolt szerződést hoz létre az összetevők között a leiratkozási kérelem közlése érdekében. Ez a képesség általában fontos a meglévő funkciók módosításakor. Ezzel szemben már implicit módon is engedélyezve van az új funkciók használata.

      A AppContextkapcsolók használatával a könyvtárak kompatibilitási lehetőségeket határoznak meg és tárnak fel; a kód, amely ezekre támaszkodik, beállíthatja ezeket a kapcsolókat, hogy befolyásolja a könyvtár viselkedését. Alapértelmezés szerint a kódtárak biztosítják az új funkciókat, és csak akkor módosítják (vagyis az előző funkciót) ha a kapcsoló be van állítva.

      Az alkalmazások (vagy tárak) deklarálhatják egy kapcsoló értékét (amely mindig egy Boolean érték), amelyet egy függő kódtár határoz meg. A kapcsoló mindig implicit módon false. A kapcsoló beállítása true-ra ennek engedélyezését teszi lehetővé. Ha a kapcsolót kifejezetten false értékre állítja, az biztosítja az új viselkedést.

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

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

      A kódtárnak ellenőriznie kell, hogy a fogyasztó deklarálta-e a kapcsoló értékét, majd megfelelően cselekedjen ennek alapján.

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

// The library can use the value of shouldThrow to throw exceptions or not.
if (shouldThrow)
{
    // old code
}
else
{
    // new code
}

      If Not AppContext.TryGetSwitch("Switch.AmazingLib.ThrowOnException", shouldThrow) Then
    ' This is the case where the switch value was not set by the application.
    ' The library can choose to get the value of shouldThrow by other means.
    ' If no overrides nor default values are specified, the value should be 'false'.
    ' A false value implies the latest behavior.
End If

' The library can use the value of shouldThrow to throw exceptions or not.
If shouldThrow Then
    ' old code
Else
    ' new code
End If

      Érdemes konzisztens formátumot használni a kapcsolókhoz, mivel ezek egy kódtár által közzétett hivatalos szerződés. Az alábbiak két nyilvánvaló formátumot jelentenek.

      • Kapcsoló.névtér.kapcsolónév

      • Kapcsoló.könyvtár.kapcsolónév

    • Változások a tevékenységalapú aszinkron mintán (TAP)

      A .NET Framework 4.6-ot megcélozó alkalmazások esetében Task és Task<TResult> objektumok öröklik a hívószál kulturális és felhasználói felületi kultúráját. A .NET-keretrendszer korábbi verzióit célzó vagy a .NET-keretrendszer egy adott verzióját nem célzó alkalmazások viselkedése nem változik. További információt a CultureInfo osztály témakörének "Kultúra és feladatalapú aszinkron műveletek" című szakaszában talál.

      A System.Threading.AsyncLocal<T> osztály lehetővé teszi egy adott aszinkron vezérlési folyamat helyi környezeti adatainak, például egy async metódusnak a megjelenítését. Az adatok több szálon keresztüli megőrzésére használható. Megadhat egy visszahívási módszert is, amely értesítést kap, ha a környezeti adatok megváltoznak, vagy azért, mert a AsyncLocal<T>.Value tulajdonságot explicit módon módosították, vagy mert a szál környezeti áttűnést észlelt.

      A tevékenységalapú aszinkron mintához (TAP) három kényelmi módszer lett hozzáadva, Task.CompletedTask, Task.FromCanceledés Task.FromException, hogy adott állapotban adja vissza a befejezett tevékenységeket.

      A NamedPipeClientStream osztály mostantól támogatja az aszinkron kommunikációt az új ConnectAsync-nak köszönhetően. módszer.

    • EventSource mostantól támogatja az eseménynaplóba való írást

      Most már a EventSource osztály használatával naplózhatja a rendszergazdai vagy működési üzeneteket az eseménynaplóba, a gépen létrehozott meglévő ETW-munkameneteken kívül. Korábban a Microsoft.Diagnostics.Tracing.EventSource NuGet csomagot kellett használnia ehhez a funkcióhoz. Ez a funkció már be van építve a .NET Framework 4.6-os verziójába.

      A NuGet-csomag és a .NET Framework 4.6 a következő funkciókkal frissült:

      • dinamikus események

        Lehetővé teszi a "menet közben" definiált eseményeket eseménymetelyek létrehozása nélkül.

      • Bőséges hasznos teher

        Lehetővé teszi, hogy a speciálisan hozzárendelt osztályok és tömbök, valamint a primitív típusok hasznos adatként legyenek átadva

      • tevékenységkövetés

        Az Indítás és Leállítás események lehetővé teszik, hogy a közöttük lévő eseményeket olyan azonosítóval lássuk el, amely az összes jelenleg aktív tevékenységet reprezentálja.

      A funkciók támogatásához a túlterhelt Write metódus hozzá lett adva a EventSource osztályhoz.

  • Windows Presentation Foundation (WPF)

    • HDPI-fejlesztések

      A HDPI támogatása WPF mostantól jobb a .NET Framework 4.6-ban. Az elrendezés korrekcióját módosították, hogy csökkentsék a szegélyekkel rendelkező vezérlők vágási esetek előfordulását. Ez a funkció alapértelmezés szerint csak akkor van engedélyezve, ha a TargetFrameworkAttribute .NET Framework 4.6-ra van állítva. Azok az alkalmazások, amelyek a keretrendszer korábbi verzióit célozzák, de a .NET Framework 4.6-on futnak, az új viselkedést bekapcsolhatják az app.config fájl <runtime> szakaszához az alábbi sort hozzáadva:

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

      WPF különböző DPI-beállításokkal (Multi-DPI beállítás) rendelkező több monitort tartalmazó windowsok mostantól teljesen elsötétített régiók nélkül jelennek meg. Ezt a viselkedést úgy tilthatja le, ha hozzáadja a következő sort a app.config fájl <appSettings> szakaszához az új viselkedés letiltásához:

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

      A DPI-beállítás alapján automatikusan betöltődő megfelelő kurzor támogatása hozzá lett adva a System.Windows.Input.Cursor.

    • Az érintés jobb

      A Connect érintéssel kiszámíthatatlan viselkedést eredményező ügyféljelentéseit a .NET Framework 4.6-ban kezeltük. Az Windows Store-alkalmazások és WPF alkalmazások dupla koppintásos küszöbértéke mostantól megegyezik Windows 8.1 és annál magasabb értéken.

    • Átlátszó gyerekablak támogatása

      WPF .NET Keretrendszer 4.6-os verziója támogatja a transzparens gyermekablakokat Windows 8.1 és újabb verziókban. Így nem téglalap alakú és átlátszó gyermekablakokat hozhat létre a felső szintű ablakokban. Ezt a funkciót úgy engedélyezheti, hogy a HwndSourceParameters.UsesPerPixelTransparency tulajdonságot trueértékre állítja.

  • Windows Communication Foundation (WCF)

    • SSL-támogatás

      A WCF mostantól támogatja az SSL TLS 1.1-es és TLS 1.2-es verzióját az SSL 3.0 és a TLS 1.0 mellett, ha a NetTcp-t átviteli biztonsággal és ügyfél-hitelesítéssel használja. Most már kiválaszthatja, hogy melyik protokollt használja, vagy letilthatja a régebbi, kevésbé biztonságos protokollokat. Ez a SslProtocols tulajdonság beállításával vagy a következő konfigurációs fájlhoz való hozzáadásával végezhető el.

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

    • Üzenetek küldése különböző HTTP-kapcsolatokkal

      A WCF lehetővé teszi a felhasználók számára, hogy bizonyos üzeneteket különböző mögöttes HTTP-kapcsolatok használatával küldjenek. Ezt kétféleképpen teheti meg:

      • Kapcsolatcsoportnév-előtag használata

        A felhasználók megadhatnak egy sztringet, amelyet a WCF a kapcsolatcsoport nevének előtagjaként fog használni. A rendszer két különböző előtaggal rendelkező üzenetet küld különböző mögöttes HTTP-kapcsolatok használatával. Az előtagot úgy állíthatja be, hogy hozzáad egy kulcs/érték párot az üzenet Message.Properties tulajdonságához. A kulcs a "HttpTransportConnectionGroupNamePrefix"; az érték a kívánt előtag.

      • Különböző csatorna gyárak használata

        A felhasználók olyan funkciót is engedélyezhetnek, amely biztosítja, hogy a különböző csatornagyárak által létrehozott csatornákon küldött üzenetek különböző mögöttes HTTP-kapcsolatokat használjanak. A funkció engedélyezéséhez a felhasználóknak a következő appSetting-t kell beállítaniuk true-re.

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

  • Windows Workflow Foundation (WWF)

    Most megadhatja, hogy a munkafolyamat-szolgáltatás hány másodpercet tartson a rendelésen kívüli műveletkéréshez, ha van egy "nem protokoll" könyvjelző a kérés időzítése előtt. A "nem protokollos" könyvjelző olyan könyvjelző, amely nem kapcsolódik a függőben lévő fogadási tevékenységekhez. Egyes tevékenységek nem protokollos könyvjelzőket hoznak létre a megvalósításuk során, ezért nem feltétlenül nyilvánvaló, hogy létezik nem protokollalapú könyvjelző. Ezek közé tartozik az Állam és a Pick. Ha tehát egy munkafolyamat-szolgáltatást egy állapotgéppel valósít meg, vagy pick tevékenységet tartalmaz, valószínűleg nem protokoll szerinti könyvjelzőkkel fog rendelkezni. Az időközt úgy adhatja meg, hogy az alábbihoz hasonló sort ad hozzá a app.config fájl appSettings szakaszához:

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

    Az alapértelmezett érték 60 másodperc. Ha value értéke 0, a rendszer azonnal elutasítja a rendelésen kívüli kérelmeket az alábbihoz hasonló szöveghiba miatt:

    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.

    Ez ugyanaz az üzenet, amelyet akkor kap, ha egy rendelésen kívüli művelet üzenete érkezik, és nincsenek protokollon kívüli könyvjelzők.

    Ha a FilterResumeTimeoutInSeconds elem értéke nem nulla, akkor nem protokoll típusú könyvjelzők vannak, és az időtúllépési időköz lejár, a művelet időtúllépési üzenettel meghiúsul.

  • Tranzakciók

    Mostantól hozzáadhatja az elosztott tranzakcióazonosítót ahhoz a tranzakcióhoz, amely egy TransactionException-ből származó kivétel dobását okozta. Ehhez adja hozzá a következő kulcsot a app.config fájl appSettings szakaszához:

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

    Az alapértelmezett érték a false.

  • Networking

    • Foglalat újrafelhasználása

      Windows 10 tartalmaz egy új, nagy méretezhetőségű hálózati algoritmust, amely a kimenő TCP-kapcsolatok helyi portjainak újrafelhasználásával teszi jobbá a gépi erőforrások használatát. .NET Framework 4.6 támogatja az új algoritmust, így .NET alkalmazások kihasználhatják az új viselkedés előnyeit. A Windows korábbi verzióiban mesterséges egyidejű kapcsolati korlát (általában 16 384, a dinamikus porttartomány alapértelmezett mérete) volt érvényben, amely korlátozhatja a szolgáltatás méretezhetőségét azáltal, hogy terhelés alatt portkimerülést okoz.

      A .NET Framework 4.6-os keretrendszerében két API-t adtak hozzá a portok újrafelhasználásának engedélyezéséhez, amely gyakorlatilag eltávolítja az egyidejű kapcsolatokra vonatkozó 64 KB-os korlátot:

      Alapértelmezés szerint a ServicePointManager.ReusePort tulajdonság false, kivéve, ha a HWRPortReuseOnSocketBind szabályozókulcs HKLM\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 értékét 0x1-re állítják. Ha engedélyezni szeretné a helyi portok http-kapcsolatokon való újrafelhasználását, állítsa a ServicePointManager.ReusePort tulajdonságot trueértékre. Emiatt a HttpClient és a HttpWebRequest kimenő TCP socket kapcsolatai egy új Windows 10 socket opciót, a SO_REUSE_UNICASTPORT-ot használják, amely lehetővé teszi a helyi portok újrafelhasználását.

      A csak socketeket használó alkalmazásokat író fejlesztők megadhatják a System.Net.Sockets.SocketOptionName lehetőséget egy olyan metódus meghívásakor, mint például a Socket.SetSocketOption, hogy a kimenő socketek újrafelhasználják a helyi portokat a kötés során.

    • nemzetközi tartománynevek és PunyCode támogatása

      A IdnHostúj tulajdonság lett hozzáadva a Uri osztályhoz, hogy jobban támogassa a nemzetközi tartományneveket és a PunyCode-ot.

  • Méretezés a Windows Forms vezérlőkben.

    Ez a funkció a .NET Framework 4.6-ban bővült, így a DomainUpDown, NumericUpDown, DataGridViewComboBoxColumn, DataGridViewColumn és ToolStripSplitButton típusokat, valamint a Bounds tulajdonság által megadott téglalapot is tartalmazza, amelyet a UITypeEditor rajzolásakor használnak.

    Ez egy bejelentkezési funkció. Az engedélyezéshez állítsa a EnableWindowsFormsHighDpiAutoResizing elemet true az alkalmazáskonfigurációs (app.config) fájlban:

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

  • Kódlapkódolások támogatása

    .NET Core elsősorban a Unicode-kódolásokat támogatja, és alapértelmezés szerint korlátozott támogatást nyújt a kódoldal-kódolásokhoz. A .NET Keretrendszerben elérhető, de .NET Core-ban nem támogatott kódlapkódolások támogatásához a Encoding.RegisterProvider metódussal regisztrálhat kódlapkódolásokat. További információért lásd System.Text.CodePagesEncodingProvider.

  • .NET natív

Universal Windows Platform (UWP) C# vagy Visual Basic nyelven írt alkalmazások kihasználhatják egy új technológia előnyeit, amely az alkalmazásokat az IL helyett natív kódra fordítja. Ez a technológia olyan alkalmazásokat hoz létre, amelyek gyorsabb indítási és végrehajtási idővel rendelkeznek. További információ: Alkalmazások .NET natív. A .NET Native bemutatásáért, amely azt vizsgálja, hogy miben különbözik a JIT-fordítástól és az NGEN-től, és hogy ez mit jelent az ön kódja számára, tekintse meg a .NET Native és Fordítás.

Az alkalmazások alapértelmezés szerint natív kódra vannak lefordítva, amikor a 2015-ös vagy újabb Visual Studio fordítja le őket. További információ: Etting Started with .NET Native.

A natív alkalmazások .NET hibakeresésének támogatásához új felületek és enumerációk lettek hozzáadva a nem felügyelt hibakeresési API-hoz. További információ: Hibakeresés (nem felügyelt API-referencia).

  • nyílt forráskódú .NET-keretrendszercsomagok

    .NET alapcsomagok, például a nem módosítható gyűjtemények, a SIMD API-k és a System.Net.Http névtérben található hálózati API-k mostantól nyílt forráskódú csomagokként érhetők el GitHub. A kód eléréséhez lásd: .NET GitHub. További információkért és arról, hogyan járulhat hozzá ezekhez a csomagokhoz, lásd: Bevezetés a .NET-be, .NET kezdőlap GitHub-on.

A .NET Framework 4.5.2 újdonságai

  • Új API-k ASP.NET alkalmazásokhoz. Az új HttpResponse.AddOnSendingHeaders és HttpResponseBase.AddOnSendingHeaders metódusokkal megvizsgálhatja és módosíthatja a válaszfejléceket és az állapotkódot, miközben a válasz ki van ürítve az ügyfélalkalmazásba. Fontolja meg ezeket a metódusokat a PreSendRequestHeaders és PreSendRequestContent események helyett; hatékonyabbak és megbízhatóbbak.

    A HostingEnvironment.QueueBackgroundWorkItem metódussal kis háttérbeli munkaelemeket ütemezhet. ASP.NET nyomon követi ezeket az elemeket, és megakadályozza, hogy az IIS hirtelen leállítja a feldolgozói folyamatot, amíg az összes háttérmunkaelem be nem fejeződik. Ez a metódus nem hívható meg ASP.NET felügyelt alkalmazástartományon kívül.

    Az új HttpResponse.HeadersWritten és HttpResponseBase.HeadersWritten tulajdonságok logikai értékeket adnak vissza, amelyek jelzik, hogy a válaszfejlécek meg lettek-e írva. Ezekkel a tulajdonságokkal meggyőződhet arról, hogy az API-k, például a HttpResponse.StatusCode (amelyek kivételeket adnak, ha a fejlécek meg vannak írva) sikeresek lesznek.

  • Átméretezés Windows Forms vezérlőkben. Ez a funkció ki lett bontva. Mostantól a rendszer DPI-beállításával átméretezheti a következő további vezérlők összetevőit (például a kombinált listák legördülő nyilat):

    Ez egy bejelentkezési funkció. Az engedélyezéshez állítsa a EnableWindowsFormsHighDpiAutoResizing elemet true az alkalmazáskonfigurációs (app.config) fájlban:

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

  • Új munkafolyamat-funkció. A EnlistPromotableSinglePhase metódust használó erőforrás-kezelők (és így a IPromotableSinglePhaseNotification felület implementálása) az új Transaction.PromoteAndEnlistDurable metódust használhatják a következők igényléséhez:

    Ez ugyanazon alkalmazástartományon belül is elvégezhető, és nem igényel további nem felügyelt kódot az MSDTC-vel való interakcióhoz az előléptetés végrehajtásához. Az új módszer csak akkor hívható meg, ha van egy fennmaradó hívás a System.Transactions-ból a IPromotableSinglePhaseNotificationPromote módszerre, amit az előléptethető enlistment implementál.

  • Profilkészítési fejlesztések. A következő, nem felügyelt profilkészítési API-k robusztusabb profilkészítést biztosítanak:

    A korábbi ICorProfiler implementációk támogatták a függő összeállítások halasztott betöltését. Az új profilkészítési API-k megkövetelik, hogy a profilozó által beszúrt függő szerelvények azonnal betölthetők legyenek, ahelyett, hogy az alkalmazás teljes inicializálása után betöltenék őket. Ez a módosítás nem érinti a meglévő ICorProfiler API-k felhasználóit.

  • Hibakeresési fejlesztések. Az alábbi, nem felügyelt hibakeresési API-k jobb integrációt biztosítanak egy profilkészítővel. Mostantól hozzáférhet a profilkészítő által beszúrt metaadatokhoz, valamint a reJIT-kérelmek által létrehozott helyi változókhoz és kódhoz a hibakereséskor.

  • Eseménykövetési változások. .NET Framework 4.5.2 lehetővé teszi a folyamaton kívüli, eseménykövetést Windows (ETW)-alapú tevékenységkövetést nagyobb felületen. Ez lehetővé teszi az Advanced Power Management (APM) szállítói számára, hogy olyan egyszerűsített eszközöket biztosítsanak, amelyek pontosan nyomon követik a szálakat keresztező egyedi kérések és tevékenységek költségeit. Ezek az események csak akkor aktiválódnak, ha az ETW-vezérlők engedélyezik őket; így a módosítások nem érintik a korábban írt ETW-kódot vagy a letiltott ETW-vel futó kódot.

  • Tranzakció népszerűsítése és megerősített bevonásra alakítása

    A Transaction.PromoteAndEnlistDurable egy új API, amely a .NET Framework 4.5.2-es és 4.6-os verzióhoz van hozzáadva:

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

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

    A metódust használhatja egy olyan beléptetés, amelyet korábban Transaction.EnlistPromotableSinglePhase hozott létre a ITransactionPromoter.Promote metódusra válaszul. Felkéri System.Transactions, hogy előléptesse a tranzakciót MSDTC-tranzakcióvá, és "konvertálja" a előléptethető beléptetést tartós beléptetéssé. A módszer sikeres elvégzése után a IPromotableSinglePhaseNotification felületre a továbbiakban nem hivatkozik a System.Transactions, és a jövőbeli értesítések a megadott ISinglePhaseNotification felületre érkeznek. A szóban forgó regisztrációnak tartós regisztrációként kell működnie, amely támogatja a tranzakciók naplózását és helyreállítását. Részletekért tekintse meg a Transaction.EnlistDurable. Ezenkívül a beléptetésnek támogatnia kell ISinglePhaseNotification. Ez a módszer csak hívható meg egy ITransactionPromoter.Promote hívás feldolgozása során. Ha ez nem így van, a rendszer TransactionException kivételt ad ki.

A .NET Framework 4.5.1 újdonságai

2014. áprilisi frissítések:

  • Visual Studio 2013 2-frissítés a Hordozható osztálytár sablonok frissítéseit tartalmazza az alábbi forgatókönyvek támogatásához:

    • A Windows Runtime API-kat olyan hordozható kódtárakban használhatja, amelyek Windows 8.1, Windows Phone 8.1 és Windows Phone Silverlight 8.1-et céloznak meg.

    • Hordozható kódtárakban használhatja a XAML-t (Windows.UI.XAML típusokat), ha Windows 8.1 vagy Windows Phone 8.1-et céloz meg. A következő XAML-sablonok támogatottak: Üres lap, Erőforrás-szótár, Sablonalapú vezérlő és Felhasználói vezérlő.

    • Létrehozhat egy hordozható Windows Runtime összetevőt (.winmd fájlt) a Windows 8.1 és Windows Phone 8.1-et célzó Áruházbeli alkalmazásokban való használatra.

    • Egy Windows Store vagy Windows Phone Store osztálykönyvtárat újracélozhat, például hordozható osztálykönyvtárként.

    Ezekről a változásokról további információt Hordozható osztálytárcímű témakörben talál.

  • A .NET-keretrendszer tartalomkészlete mostantól tartalmazza a natív .NET dokumentációját, amely a Windows-alkalmazások létrehozásának és üzembe helyezésének előkészületi technológiája. .NET natív fordítás az alkalmazásokat közvetlenül natív kódra fordítja, nem pedig köztes nyelvre (IL) a jobb teljesítmény érdekében. További részletekért lásd a következőt: Alkalmazások fordítása .NET Native használatával.

  • A .NET keretrendszer referenciaforrása új böngészési élményt és továbbfejlesztett funkciókat biztosít. Mostantól online böngészhet a .NET-keretrendszer forráskódja között, letöltéssel letöltheti a hivatkozást offline megtekintésre, és a hibakeresés során végiglépkedhet a forrásokon (beleértve a javításokat és frissítéseket is). További információt a A .NET referenciaforrás új megjelenése című blogbejegyzésben talál.

A .NET Framework 4.5.1 alaposztályainak új funkciói és fejlesztései a következők:

  • Automatikus kötésátirányítás szerelvényekhez. A 2013-as Visual Studio-tól kezdve a .NET Framework 4.5.1-et célzó alkalmazások fordításakor kötési átirányítások is hozzáadhatók az alkalmazás konfigurációs fájljához, ha az alkalmazás vagy összetevői ugyanazon szerelvény több verziójára hivatkoznak. Ezt a funkciót olyan projektekhez is engedélyezheti, amelyek a .NET-keretrendszer régebbi verzióit célozzák. További információ: Az automatikus kötésátirányítás engedélyezése és letiltása.

  • Diagnosztikai információk gyűjtése a fejlesztőknek a kiszolgáló- és felhőalkalmazások teljesítményének javítása érdekében. További információkért tekintse meg a WriteEventWithRelatedActivityId osztály WriteEventWithRelatedActivityIdCore és EventSource metódusát.

  • A nagyméretű objektum halom (LOH) explicit tömörítésének képessége a szemétgyűjtés során. További információért lásd a GCSettings.LargeObjectHeapCompactionMode tulajdonságot.

  • További teljesítménybeli fejlesztések, például ASP.NET alkalmazás felfüggesztése, többmagos JIT-fejlesztések és gyorsabb alkalmazásindítás a .NET-keretrendszer frissítése után. További információt a .NET Framework 4.5.1 közleményében és a ASP.NET alkalmazás felfüggesztése blogbejegyzésben talál.

A Windows Forms fejlesztései a következők:

  • Átméretezés Windows Forms vezérlőkben. A rendszer DPI-beállításával átméretezheti a vezérlők összetevőit (például a tulajdonságrácson megjelenő ikonokat) azáltal, hogy beleegyezik az alkalmazás konfigurációs fájljában található bejegyzés használatába (app.config). Ez a funkció jelenleg a következő Windows Forms vezérlőkben támogatott:

    A funkció engedélyezéséhez adjon hozzá egy új <appSettings> elemet a konfigurációs fájlhoz (app.config), és állítsa a EnableWindowsFormsHighDpiAutoResizing elemet true értékre.

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

A 2013-Visual Studio-ban a .NET Framework-alkalmazások hibakeresésének fejlesztései közé tartoznak a következők:

  • Értékeket ad vissza a Visual Studio hibakeresőben. Ha egy felügyelt alkalmazásban hibakeresést hajt végre a Visual Studio 2013-ban, az Autos ablak megjeleníti a metódusok visszatérési típusait és értékeit. Ezek az információk asztali, Windows Áruházbeli és Windows Phone-alkalmazásokhoz érhetők el. További információ: Metódushívások visszatérési értékeinek vizsgálata.

  • 64 bites alkalmazások szerkesztése és folytatása. Visual Studio 2013 támogatja a Szerkesztés és folytatás funkciót a 64 bites felügyelt alkalmazásokhoz asztali, Windows Áruházbeli és Windows Phone-telefonokhoz. A meglévő korlátozások a 32 bites és a 64 bites alkalmazásokra is érvényesek maradnak (lásd a támogatott kódmódosítások (C#) cikk utolsó szakaszát).

  • Aszinkronfigyelő hibakeresés. A Visual Studio 2013-ban az aszinkron alkalmazások hibakeresésének megkönnyítése érdekében a hívásverem elrejti az aszinkron programozás támogatásához a fordítók által biztosított infrastruktúrakódot, valamint a logikai szülőhívásokat is összefűzi, hogy az alkalmazás logikai végrehajtását tisztábban követhetővé tegye. A Feladatok ablak lecseréli a Párhuzamos feladatok ablakot, és megjeleníti az adott törésponthoz kapcsolódó tevékenységeket, valamint megjeleníti az alkalmazásban jelenleg aktív vagy ütemezett egyéb tevékenységeket is. Erről a funkcióról a .NET Framework 4.5.1 közlemény "Aszinkron hibakeresés" szakaszában olvashat.

  • Jobb kivételtámogatás Windows Runtime összetevőkhöz. A Windows 8.1 az Windows Áruházbeli alkalmazásokból származó kivételek megőrzik a kivételt okozó hibával kapcsolatos információkat, még a nyelvi határokon is. Erről a funkcióról a .NET Framework 4.5.1 közlemény "Windows Áruházbeli alkalmazásfejlesztés" című szakaszában olvashat.

2013 Visual Studio-tól kezdve használhatja a Managed Profile Guided Optimization Tool (Mpgo.exe) a Windows 8.x Áruházbeli alkalmazások és az asztali alkalmazások optimalizálásához.

Az ASP.NET 4.5.1 új funkcióit tekintse meg a ASP.NET és Webeszközök a Visual Studio 2013-hoz kiadási megjegyzésekben.

A .NET Framework 4.5 újdonságai

Alaposztályok

  • A rendszer újraindításának csökkentése .NET Framework 4-alkalmazások észlelésével és bezárásával az üzembe helyezés során. Lásd: A rendszer újraindítások csökkentése a .NET Framework 4.5 telepítése során.

  • 2 gigabájtnál (GB) nagyobb tömbök támogatása 64 bites platformokon. Ez a funkció engedélyezhető az alkalmazáskonfigurációs fájlban. Tekintse meg az <gcAllowVeryLargeObjects> elemet, amely az objektumméretre és a tömbméretre vonatkozó egyéb korlátozásokat is felsorolja.

  • Jobb teljesítmény a kiszolgálók háttérbeli szemétgyűjtésén keresztül. Ha kiszolgálói szemétgyűjtést használ a .NET Framework 4.5-ben, a háttérbeli szemétgyűjtés automatikusan engedélyezve lesz. Tekintse meg a Szemétgyűjtés alapjai témakör Háttérkiszolgáló szemétgyűjtés című szakaszát.

  • Háttérben történő valós idejű (JIT) fordítás, amely elérhető többmagos processzorokon az alkalmazás teljesítményének javítása érdekében. Lásd a(z) ProfileOptimization.

  • Annak korlátozása, hogy a reguláris kifejezésmotor mennyi ideig kísérel meg feloldani egy reguláris kifejezést, mielőtt túllépi az időkorlátot. Lásd a Regex.MatchTimeout tulajdonságot.

  • Az alkalmazástartomány alapértelmezett kultúrájának definiálása. Tekintse meg a CultureInfo osztályt.

  • A Unicode (UTF-16) kódolás konzoltámogatása. Tekintse meg a Console osztályt.

  • A kulturális karakterláncok sorrendjének és összehasonlítási adatainak verziókezelésének támogatása. Tekintse meg a SortVersion osztályt.

  • Jobb teljesítmény az erőforrások lekérésekor. Lásd: Csomagok és erőforrások üzembe helyezése.

  • A tömörített fájlok méretének csökkentése érdekében a zip-tömörítés fejlesztései. Tekintse meg a System.IO.Compression névteret.

  • A tükrözési környezet testreszabása az alapértelmezett tükröződési viselkedés felülbírálásához az CustomReflectionContext osztályon keresztül.

  • Az Internationalized Domain Names in Applications (IDNA) szabvány 2008-ban készült verziójának támogatása, ha a System.Globalization.IdnMapping osztályt Windows 8 használja.

  • A sztring-összehasonlítás delegálása az Unicode 6.0-t implementáló operációs rendszerre, amikor a .NET-keretrendszert Windows 8-on használnak. Más platformokon való futtatáskor a .NET-keretrendszer saját sztring-összehasonlító adatokat tartalmaz, amelyek a Unicode 5.x-et implementálják. Lásd a String osztályt és a SortVersion osztály Megjegyzések szakaszát.

  • A sztringek kivonatkódjainak kiszámítása alkalmazástartományonként. Lásd:<UseRandomizedStringHashAlgorithm> Elem.

  • A típusreflexió támogatása megosztva a Type és TypeInfo osztályok között. Lásd: Reflection a Windows Áruházbeli alkalmazásokhoz készült .NET-keretrendszerben.

Felügyelt bővíthetőségi keretrendszer (MEF)

A .NET Framework 4.5-ben a felügyelt bővíthetőségi keretrendszer (MEF) a következő új funkciókat biztosítja:

  • Általános típusok támogatása.

  • Konvencióalapú programozási modell, amely lehetővé teszi, hogy attribútumok helyett elnevezési konvenciók alapján hozzon létre részeket.

  • Több hatókör.

  • A MEF egy részhalmaza, amelyet Windows 8.x Áruházbeli alkalmazások létrehozásakor használhat. Ez az alkészlet letölthető csomagként érhető el, a NuGet-katalógusból. A csomag telepítéséhez nyissa meg a projektet a Visual Studio, válassza a Manage NuGet Packages lehetőséget a Projekt menüből, és keressen online a Microsoft.Composition csomagra.

További információ: Felügyelt bővíthetőségi keretrendszer (MEF).

Aszinkron fájlműveletek

A .NET Framework 4.5-ben új aszinkron funkciók lettek hozzáadva a C# és Visual Basic nyelvekhez. Ezek a funkciók egy feladatalapú modellt adnak hozzá az aszinkron műveletek végrehajtásához. Az új modell használatához használja az Aszinkron metódusokat az I/O-osztályokban. Lásd: Aszinkron fájl I/O.

Eszközök

A .NET Framework 4.5-ben a Resource File Generator (Resgen.exe) lehetővé teszi, hogy .resw fájlt hozzon létre a Windows 8.x Áruházbeli alkalmazásokban való használatra egy .NET-keretrendszer-szerelvénybe beágyazott .resources-fájlból. További információ: Resgen.exe (Resource File Generator).

A felügyelt profilok irányított optimalizálása (Mpgo.exe) lehetővé teszi az alkalmazások indítási idejének, a memóriahasználatnak (a munkakészlet méretének) és az átviteli sebességnek a javítását a natív rendszerkép-szerelvények optimalizálásával. A parancssori eszköz profiladatokat hoz létre a natív képalkalmazás-szerelvényekhez. Lásd: Mpgo.exe (Managed Profile Guided Optimization Tool [felügyelt profil irányított optimalizálási eszköz]). 2013 Visual Studio kezdve a Mpgo.exe használatával optimalizálhatja Windows 8.x Áruházbeli alkalmazásokat és asztali alkalmazásokat.

Párhuzamos számítástechnika

.NET Framework 4.5 számos új funkciót és fejlesztést biztosít a párhuzamos számítástechnika terén. Ezek közé tartozik a jobb teljesítmény, a nagyobb vezérlés, az aszinkron programozás továbbfejlesztett támogatása, egy új adatfolyam-kódtár, valamint a párhuzamos hibakeresés és a teljesítményelemzés továbbfejlesztett támogatása. A "Parallel Programming with .NET" blogban tekintse meg a Újdonságok a párhuzamosság terén a .NET Framework 4.5-ben című bejegyzést.

web

ASP.NET 4.5 és 4.5.1 modellkötést adhat hozzá a Web Formshoz, a WebSocket támogatásához, az aszinkron kezelőkhöz, a teljesítménybeli fejlesztésekhez és sok más funkcióhoz. További információ:

Hálózatépítés

.NET Framework 4.5 új programozási felületet biztosít a HTTP-alkalmazásokhoz. További információt az új System.Net.Http és System.Net.Http.Headers névterekben talál.

A WebSocket-kapcsolat elfogadásához és használatához a meglévő HttpListener és a kapcsolódó osztályok használatával egy új programozási felület is támogatást nyújt. További információ: az új System.Net.WebSockets névtér és a HttpListener osztály.

Emellett a .NET Framework 4.5 a következő hálózatkezelési fejlesztéseket tartalmazza:

  • RFC-kompatibilis URI-támogatás. További információ: Uri és a kapcsolódó osztályok.

  • Az internationalizált tartománynév (IDN) elemzésének támogatása. További információ: Uri és a kapcsolódó osztályok.

  • Az e-mail-címek nemzetköziesítésének (EAI) támogatása. További információ: System.Net.Mail névtér.

  • Továbbfejlesztett IPv6-támogatás. További információ: System.Net.NetworkInformation névtér.

  • Kettős módú aljzatok támogatása. További információ: Socket és TcpListener osztályok.

Windows Presentation Foundation (WPF)

A .NET Framework 4.5-ben a Windows Presentation Foundation (WPF) a következő területeken tartalmaz módosításokat és fejlesztéseket:

  • Az új Ribbon vezérlő, amely lehetővé teszi egy menüszalag felhasználói felületének implementálását, amely gyorselérési eszköztárat, alkalmazásmenüt és lapokat üzemeltet.

  • Az új INotifyDataErrorInfo felület, amely támogatja a szinkron és aszinkron adatérvényesítést.

  • Új funkciók a VirtualizingPanel és Dispatcher osztályokhoz.

  • Nagyobb teljesítmény a nagy méretű csoportosított adatok megjelenítésekor és a nem felhasználói felületi szálak gyűjteményeinek elérésekor.

  • Adatkötés statikus tulajdonságokhoz, adatkötés egyéni típusokhoz, amelyek implementálják a ICustomTypeProvider felületet, és adatkötési információk lekérése egy kötési kifejezésből.

  • Az adatok áthelyezése az értékek változásával (élő formázás).

  • Annak ellenőrzése, hogy az elemtároló adatkörnyezete leválasztva van-e.

  • Megadhatja, hogy mennyi idő teljen el a tulajdonságváltozások és az adatforrás-frissítések között.

  • Továbbfejlesztett támogatás gyenge eseményminták implementálására. Az események mostantól jelölőbővítményeket is elfogadhatnak.

Windows Communication Foundation (WCF)

A .NET Framework 4.5-ben a következő funkciókkal bővült a Windows Communication Foundation (WCF) alkalmazások írása és karbantartása:

  • A létrehozott konfigurációs fájlok egyszerűsítése.

  • A szerződésközpontú fejlesztés támogatása.

  • A ASP.NET kompatibilitási mód egyszerűbb konfigurálásának lehetősége.

  • Az alapértelmezett átviteli tulajdonságértékek módosítása annak érdekében, hogy csökkenjen annak a valószínűsége, hogy be kell állítania őket.

  • A XmlDictionaryReaderQuotas osztály frissítései annak valószínűségének csökkentése érdekében, hogy manuálisan kell konfigurálnia a kvótákat az XML-szótárolvasók számára.

  • A WCF-konfigurációs fájlok ellenőrzése Visual Studio a buildelési folyamat részeként, így az alkalmazás futtatása előtt észlelheti a konfigurációs hibákat.

  • Új aszinkron streamtámogatás.

  • Új HTTPS protokollleképezés, amely megkönnyíti a végpontok HTTPS-en keresztüli elérhetővé tétele Internet Information Services (IIS) használatával.

  • Metaadatok létrehozása egyetlen WSDL-dokumentumban a szolgáltatás URL-címéhez ?singleWSDL hozzáfűzésével.

  • A Websocketek támogatják a valódi kétirányú kommunikációt a 80-as és 443-as portokon, TCP-átvitelhez hasonló teljesítményjellemzőkkel.

  • Szolgáltatások kódban való konfigurálásának támogatása.

  • XML-szerkesztő elemleírásai.

  • ChannelFactory gyorsítótárazási támogatás.

  • Bináris kódoló tömörítési támogatása.

  • UDP-átvitel támogatása, amely lehetővé teszi a fejlesztők számára a "fire and forget" üzenetküldést használó szolgáltatások írását. Az ügyfél üzenetet küld egy szolgáltatásnak, és nem vár választ a szolgáltatástól.

  • Több hitelesítési mód támogatása egyetlen WCF-végponton a HTTP átviteli és átviteli biztonság használatakor.

  • A nemzetközi tartományneveket (IDN-eket) használó WCF-szolgáltatások támogatása.

További információért lásd: What's New in Windows Communication Foundation.

Windows Workflow Foundation (WF)

A .NET Framework 4.5-ben számos új funkció lett hozzáadva Windows Workflow Foundationhez (WF), többek között a következőkhöz:

  • A .NET Framework 4.0.1 (.NET Framework 4 Platform Update 1) részeként bevezetett állapotgép-munkafolyamatok. Ez a frissítés számos új osztályt és tevékenységet tartalmazott, amelyek lehetővé ták a fejlesztők számára az állapotgép-munkafolyamatok létrehozását. Ezeket az osztályokat és tevékenységeket frissítettük a .NET Framework 4.5-ös verziója esetében a következőkre:

    • Az állapotok töréspontjainak beállítása.

    • Áttűnések másolása és beillesztése a munkafolyamat-tervezőben.

    • Tervezői támogatás a megosztott eseményindító-áttűnések létrehozásához.

    • Állapotgép-munkafolyamatok létrehozására szolgáló tevékenységek, például: StateMachine, Stateés Transition.

  • Továbbfejlesztett Munkafolyamat-tervező funkciók, például a következők:

    • Továbbfejlesztett munkafolyamat-keresési funkciók a Visual Studio-ban, amelyek tartalmazzák a Quick Find és a Find in Files lehetőségeket.

    • Képes automatikusan létrehozni egy szekvenciatevékenységet, amikor egy második gyermektevékenységet adnak hozzá egy tárolótevékenységhez, és mindkét tevékenységet belefoglalhatja a Szekvencia tevékenységbe.

    • Pásztázó támogatás, amely lehetővé teszi a munkafolyamat látható részének módosítását a görgetősávok használata nélkül.

    • Új Dokumentumszerkezet nézet, amely egy munkafolyamat összetevőit jeleníti meg fastílusú vázlat nézetben, és lehetővé teszi, hogy kijelöljön egy összetevőt a Dokumentumszerkezet nézetben.

    • Széljegyzetek hozzáadása tevékenységekhez.

    • Tevékenységdelegáltak definiálásának és felhasználásának lehetősége a munkafolyamat-tervezővel.

    • Automatikus csatlakozás és automatikus beszúrás állapotgép- és folyamatábra-munkafolyamatokban végzett tevékenységekhez és átmenetekhez.

  • A munkafolyamatok nézetállapot-információinak tárolása az XAML-fájl egyetlen elemében, így könnyen megtalálhatja és szerkesztheti a nézetállapot adatait.

  • Egy NoPersistScope-konténer tevékenység, amely megakadályozza a gyerek tevékenységek állandósítását.

  • C#-kifejezések támogatása:

    • A Visual Basic használó munkafolyamat-projektek Visual Basic kifejezéseket, a C# munkafolyamat-projektek pedig C# kifejezéseket fognak használni.

    • A 2010-ben Visual Studio létrehozott és Visual Basic kifejezésekkel rendelkező C# munkafolyamat-projektek kompatibilisek a C# kifejezéseket használó C# munkafolyamat-projektekkel.

  • Verziókezelési fejlesztések:

    • Az új WorkflowIdentity osztály, amely megfeleltetést biztosít egy megőrzött munkafolyamat-példány és annak munkafolyamat-definíciója között.

    • Több munkafolyamat-verzió egymás melletti futtatása ugyanabban a kiszolgálóban, beleértve a WorkflowServiceHost.

    • A dinamikus frissítésben lehetőség van egy megmaradt munkafolyamat-példány definíciójának módosítására.

  • Szerződés-első munkafolyamat-szolgáltatásfejlesztés, amely támogatást nyújt a meglévő szolgáltatási szerződésnek megfelelő tevékenységek automatikus generálásához.

További információért lásd a következőt: What's New in Windows Workflow Foundation.

.NET Windows 8.x Áruházbeli alkalmazásokhoz

A Windows 8.x Áruházbeli alkalmazások speciális formai tényezőkre vannak tervezve, és kihasználják az Windows operációs rendszer előnyeit. A .NET Framework 4.5 vagy 4.5.1 egy részhalmaza Windows 8.x Áruházbeli alkalmazásokat készít Windows C# vagy Visual Basic használatával. Ezt az alkészletet Windows 8.x Store alkalmazásokhoz .NET-nek nevezik, és egy áttekintés tárgyalja.

Hordozható osztálykönyvtárak

A Visual Studio 2012 (és újabb verziók) hordozható osztálytár projektje lehetővé teszi kezelt összetevők írását és fordítását, amelyek több .NET-keretrendszer-platformon működnek. A Portable Class Library projekt használatával kiválaszthatja a megcélzott platformokat (például Windows Phone és .NET Windows 8.x Áruházbeli alkalmazásokhoz). A projektben elérhető típusok és tagok automatikusan a platformok gyakori típusaira és tagjaira korlátozódnak. További információ: Portable Class Library.

Lásd még:

  • Last updated on