Megosztás a következőn keresztül:

A .NET-keretrendszer újdonságai

  • Cikk

Jegyzet

A .NET-keretrendszer a Windows-frissítésektől függetlenül, biztonsági és megbízhatósági hibajavításokkal működik. A biztonsági frissítések általában negyedévente jelennek meg. A .NET-keretrendszer továbbra is része lesz a Windowsnak, és nem tervezi az eltávolítását. A .NET-keretrendszer alkalmazásait nem kell migrálnia, de új fejlesztéshez használja .NET 8 vagy újabb.

Ez a cikk a .NET-keretrendszer 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 Első lépésekcímű témakörben olvashat. 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ódtárak és API-k és .NET-keretrendszer és sávon kívüli kiadások. Tekintse meg a .NET-keretrendszerhez NuGet-csomagok teljes listáját.

A .NET-keretrendszer 4.8.1 bemutatása

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

A .NET-keretrendszer 4.8.1 letöltése és telepítése

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

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

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

A .NET-keretrendszer 4.8.1 újdonságai

A .NET Framework 4.8.1 az alábbi területeken vezet be új funkciókat:

A .NET Framework 4.8.1 fő témája a továbbfejlesztett akadálymentesség, amely lehetővé teszi, hogy az alkalmazások megfelelő élményt nyújtsanak a kisegítő technológiák felhasználói számára. A .NET-keretrendszer 4.8.1 akadálymentességi fejlesztéseivel kapcsolatos információkért lásd A .NET-keretrendszerkisegítő lehetőségeinek újdonságai című témakört.

A .NET Framework 4.8.1 natív Arm64-támogatást ad hozzá a .NET-keretrendszercsaládhoz. Így a .NET-keretrendszer-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 az Arm64-en emulált x64-kód futtatásához képest.

A Microsoft elkötelezett amellett, hogy olyan termékeket és platformokat biztosítson, amelyek mindenki számára elérhetők. A .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 a Windows Forms és a WPF is új funkciókat adott hozzá, é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 A .NET-keretrendszer kisegítő lehetőségeinek újdonságaicí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 Formsban ez a támogatás csak Windows 11 vagy újabb operációs rendszereken érhető el. A 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é. A WPF nem rendelkezik operációsrendszer-verziófüggőségekkel az elérhető elemleírásokhoz.

A WPF a WCAG2.1-kompatibilis elemleírások legtöbb követelményét implementálta a .NET-keretrendszer 4.8-ban. Ebben a kiadásban a WPF továbbfejlesztette a felhasználói élményt azáltal, hogy az aktuális ablakban lévő elemleírást egyszerűen el lehet utasítani az Esc billentyűvel, a Ctrl billentyűvel (önmagában) vagy a Ctrl +Shift+F10kombiná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.

A Windows Forms volt az első windowsos 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 a Windows Forms számos problémával foglalkozott. Az akadálymentességgel kapcsolatos változások teljes listáját A .NET-keretrendszerkisegítő lehetőségeinek újdonságai című témakörben találja.

A .NET-keretrendszer 4.8.1-ben a Windows Forms fejlesztései a következők:

  • A szövegminta támogatása– A Windows Forms támogatást nyert a UIA szövegmintára. 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 ComboBox-vezérlőkhöz és egyebekhez.

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

  • 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-keretrendszer 4.8 bemutatása

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

A .NET-keretrendszer 4.8 letöltése és telepítése

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

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

A .NET-keretrendszer 4.8-at a Visual Studio 2012-ben vagy újabb verzióiban célozhatja meg a .NET Framework 4.8 Fejlesztői csomagtelepítésével.

A .NET-keretrendszer 4.8 újdonságai

A .NET Framework 4.8 az alábbi 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ő témája. A .NET-keretrendszer 4.8 akadálymentességi fejlesztéseiről további információt A .NET-keretrendszerkisegítő lehetőségeinek újdonságai című témakörben talál.

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 SHA256Managed, kivételt (CryptographicException) dobnak, amikor a rendszer titkosítási kódkö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-keretrendszer 4.8-at célzó alkalmazásokban alapértelmezés szerint a következő felügyelt titkosítási osztályok már nem okoznak CryptographicException hibakódot ebben az 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-keretrendszer 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-keretrendszer 4.8-os 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.

  • OnThrottlePercentExceeded: 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-keretrendszer 4.8-ban a WPF támogatja Per-Monitor V2 DPI-tudatosságot és Mixed-Mode DPI-méretezést. A magas DPI-fejlesztéssel kapcsolatos további információkért tekintse meg a Magas DPI asztali alkalmazásfejlesztés Windows rendszeren.

A .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 Windows 10 2018. április 10-i frissítésétől kezdve). Ha az üzemeltetett HWND-k vagy a Windows Forms-vezérlők mint Mixed-Mode DPI-skálázott ablakok jönnek létre a SetThreadDpiHostingBehavior és SetThreadDpiAwarenessContextmeghívásával, azok egy Per-Monitor V2 WPF-alkalmazásban elhelyezhetők, és megfelelően méretezhetők és skálázhatók. 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, hogy a WPF-vezérlők natív ablakban legyenek elhelyezhetők (azaz szülőablakban) egy nagy DPI-jű 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 az alkalmazáskonfigurációs fájlt:

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

Gyakori nyelvi futtatókörnyezet

A .NET-keretrendszer 4.8-ban futó futtatókörnyezet a következő módosításokat és fejlesztéseket tartalmazza:

A JIT fordítófejlesztései. A .NET Framework 4.8 just-in-time (JIT) fordítója a .NET Core 2.1 JIT-fordítóján alapul. A .NET-keretrendszer 4.8 JIT-fordítója számos optimalizálást és hibajavítást tartalmaz a .NET Core 2.1 JIT-fordítóhoz.

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-keretrendszer 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-en futó .NET-keretrendszer 4.8-tól kezdve a futtatókörnyezet elindítja a Kártevőirtó vizsgálati felület (AMSI)implementálására szolgáló kártevőirtó-megoldások vizsgálatát.

A .NET-keretrendszer 4.7.2 újdonságai

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

A .NET-keretrendszer 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. A .NET-keretrendszer 4.7.2 akadálymentességi fejlesztéseivel kapcsolatos információkért lásd A .NET-keretrendszerkisegítő lehetőségeinek újdonságai című témakört.

Alaposztályok

A .NET Framework 4.7.2 számos titkosítási fejlesztést, jobb tömörítési támogatást biztosít 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 a 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-keretrendszer 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ó és példakód: "A PKCS#10 tanúsítvány-aláírási kérelmek és az X.509 nyilvános kulcsú tanúsítványok programozott létrehozása" című témakör a .NET Blog.

SignerInfo új tagjai

A .NET-keretrendszer 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-keretrendszer 4.7.2-től kezdve a CryptoStream osztály egy további konstruktorsal rendelkezik, 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-keretrendszer 4.7.2-től kezdve a dekompressziós műveletek végrehajtása a DeflateStream osztályban 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 .NET-keretrendszer 4.7.2-et célzó alkalmazások esetében alapértelmezés szerint engedélyezve van a dekompresszió támogatása Windows API-k használatával. A .NET-keretrendszer korábbi verzióit célzó, de a .NET-keretrendszer 4.7.2-ben futó alkalmazások a következő AppContext kapcsoló az alkalmazáskonfigurációs fájlhoz való hozzáadásával engedélyezhetik ezt a viselkedést:

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

További gyűjtemény API-k

A .NET Framework 4.7.2 számos új API-t ad hozzá a SortedSet<T> és HashSet<T> típusokhoz. 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-keretrendszer 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. A .NET Framework 4.7.2 hozzáad egy HttpCookie.SameSite tulajdonságot, amelynek értéke 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építés

HttpClientHandler-tulajdonságok implementálása

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

SQLClient

Az Azure Active Directory univerzális hitelesítésének és többtényezős hitelesítésének támogatása

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ása érdekében a .NET-keretrendszer 4.7.2 kibővíti a SQLClient kapcsolati sztringeket az "Authentication" kulcsszóhoz egy új értéket, az "Active Directory Interactive" hozzáadásával, amely támogatja az MFA-t és az 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óit. 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-keretrendszer korábbi verzióiban az SQL-kapcsolat csak a SqlAuthenticationMethod.ActiveDirectoryPassword és SqlAuthenticationMethod.ActiveDirectoryIntegrated lehetőségeket támogatta. Mindkettő része a nem interaktív ADAL protokoll, amely nem támogatja az MFA-t. Az új SqlAuthenticationMethod.ActiveDirectoryInteractive lehetőséggel az SQL-kapcsolat támogatja az MFA-t, valamint 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 kapcsolati sztringben megőriznék a jelszavakat.

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

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 az SQL Server részét képezheti, de az SQL Server-kód nem módosítható. Az enklávéalapú Always Encrypted támogatásához a .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 AlwaysEncrypted kapcsolatot az SQL Serverrel, amely támogatja az enklávéalapú Always Encrypted szolgáltatást. 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 Serveren ü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 Presentation Foundation

ResourceDictionaries keresése forrás szerint

A .NET-keretrendszer 4.7.2-től kezdve a diagnosztikai asszisztensek megkereshetik az adott forrás uri-ból létrehozott ResourceDictionaries-t. (Ez a funkció diagnosztikai asszisztensek által használható, nem éles alkalmazások számára.) Egy diagnosztikai asszisztens, például a Visual Studio "Szerkesztés és folytatás" szolgáltatása lehetővé teszi a felhasználó számára a ResourceDictionary szerkesztését 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-keretrendszer 4.7.2-től kezdve a diagnosztikai asszisztensek megkereshetik egy adott ResourceDictionarytulajdonosait. (A funkció diagnosztikai asszisztensek és nem termelési alkalmazások által használható.) Valahányszor változtatás történik egy ResourceDictionary-n, a WPF automatikusan megkeresi az összes DynamicResource hivatkozást, amelyet érinthet a változtatás.

Előfordulhat, hogy egy diagnosztikai asszisztens, például a Visual Studio "Szerkesztés és folytatás" létesítménye ki szeretné terjeszteni ezt StaticResource hivatkozásainak 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 implementált három új statikus metódus, 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 éles alkalmazásoknál.) Előfordulhat, hogy 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 megváltozik egy ResourceDictionary-ban. A WPF ezt automatikusan elvégzi DynamicResource-hivatkozások esetében, de szándékosan nem teszi meg StaticResource-hivatkozások esetében. A .NET-keretrendszer 4.7.2-től kezdve a diagnosztikai asszisztens ezeket az értesítéseket használhatja a statikus erőforrás ezen használatá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 Formshoz, a Windows Presentation Foundationhez (WPF) és a Visual Studio Tools for Office-hoz (VSTO) készült HDPI-képes alkalmazások a ClickOnce használatával telepíthetők. Ha az alábbi bejegyzés található az alkalmazásjegyzékben, az üzembe helyezés sikeres lesz a .NET-keretrendszer 4.7.2-ben:

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

Windows Forms-alkalmazás esetén már nem szükséges a DPI-tudatossági beállítás korábbi módszere az alkalmazás konfigurációs fájljában az alkalmazásjegyzék helyett, hogy a ClickOnce üzembe helyezése sikeres legyen.

A .NET-keretrendszer 4.7.1 újdonságai

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

Emellett a .NET-keretrendszer 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. A .NET-keretrendszer 4.7.1 akadálymentességi fejlesztéseivel kapcsolatos információkért lásd A .NET-keretrendszerkisegítő lehetőségeinek újdonságai című témakört.

Alaposztályok

.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. A .NET-keretrendszer 4.7.1 teljes mértékben támogatja a .NET Standard 2.0-t, és a .NET Standard 2.0-ban definiált, a .NET-keretrendszer 4.6.1-ből, 4.6.2-ből és 4.7-ből hiányzó, körülbelül 200 API-t. (Vegye figyelembe, hogy a .NET-keretrendszer ezen verziói csak akkor támogatják a .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-keretrendszer 4.7.1 futtatókörnyezeti és fordítói funkciói blogbejegyzésben.

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

A konfigurációszerkesztő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ót a .NET-keretrendszer 4.7.1-es ASP.NET és konfigurációs funkcióinak "Configuration Builders" című szakaszában blogbejegyzésben talál.

futásidejű funkcióészlelés

A System.Runtime.CompilerServices.RuntimeFeature osztály egy 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 futásidőben. 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 RuntimeFeature.IsSupported metódust, mielőtt futtatáskor kódot bocsát ki. 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-keretrendszer 4.7.1-től kezdve a System.ValueTuple és a hozzá tartozó általános típusok szerializálhatóként vannak megjelölve, ami 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óért lásd a .NET-keretrendszer 4.7.1-es futtatókörnyezeti és fordítófunkcióinak blogbejegyzésében a "Compiler -- ValueTuple is Serializable" című témakört.

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

A .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ót a .NET-keretrendszer 4.7.1 futtatókörnyezeti és fordítófunkcióinak blogbejegyzésében "Compiler -- Support for ReadOnlyReferences" című témakörben talál. Az ref visszatérési értékekről további információt a Ref visszatérési értékek és a ref locals és a Ref visszatérési értékek (Visual Basic)című témakörben talál.

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

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

A .NET-keretrendszer 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 kupa (LOH) foglalások esetében. A .NET Framework 4.7.1-ben a rendszer külön zárolásokat használ a kis objektumhalomhoz (SOH) és a LOH-foglalásokhoz, ami lehetővé teszi a LOH-foglalások végrehajtását az alatt, hogy a háttérben futó GC takarítja az SOH-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óért lásd a „Runtime -- GC teljesítményjavítások” című részt a .NET-keretrendszer 4.7.1 futtatási és fordítói funkciók blogbejegyzésében.

Hálózatépítés

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

A .NET-keretrendszer 4.7-ben és korábbi verzióiban a Message.HashAlgorithm tulajdonság csak HashAlgorithm.Md5 és HashAlgorithm.Sha értékeit támogatta. A .NET-keretrendszer 4.7.1-től kezdve HashAlgorithm.Sha256, HashAlgorithm.Sha384és HashAlgorithm.Sha512 is támogatottak. 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-keretrendszer 4.7.1-es ASP.NET és konfigurációs funkcióinak .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 .NET-keretrendszer 4.7-ig ASP.NET verzióiban a ASP.NET nem tudja lefutni 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 kizárólag a HttpContext-t folyatja. A .NET-keretrendszer 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óért lásd a „Végrehajtási lépés funkció” című részt a .NET-keretrendszer 4.7.1 ASP.NET és konfigurációs funkciók blogbejegyzésében.

ASP.NET HttpCookie elemzési

A .NET-keretrendszer 4.7.1-ben egy új, HttpCookie.TryParsemetódus található, amely szabványosított módot biztosít egy HttpCookie objektum sztringből való létrehozására, és pontosan hozzárendelhet 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-keretrendszer 4.7.1 ASP.NET és konfigurációs szolgáltatások blogbejegyzésben.

SHA-2 kivonat opciók ASP.NET űrlapok hitelesítési adataihoz

A .NET-keretrendszer 4.7-ös é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-keretrendszer 4.7.1-től kezdve a ASP.NET támogatja az olyan új biztonságos SHA-2 kivonatolási lehetőségeket is, 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 azure SQL-hez csatlakozik, Azure-erőforrások felügyelt identitásai ajánlott hitelesítési módszer.

A .NET-keretrendszer 4.7 újdonságai

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

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

Alaposztályok

A .NET Framework 4.7 fejleszti a szerializálást a DataContractJsonSerializeráltal:

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

A .NET-keretrendszer 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.

A .NET Framework 4.7 további görbék (köztük a Brainpool-görbecsomag) támogatását is támogatja, é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.

A GitHubon .NET Framework 4.7 titkosítási fejlesztéseinek példája látható.

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-keretrendszer 4.7-es verzióját megcélzó alkalmazások esetében, és a .NET-keretrendszer 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építés

A .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-keretrendszer 4.7-ben ASP.NET a következő új funkciókat tartalmazza:

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

A .NET-keretrendszer 4.7-től kezdve a ASP.NET új API-kat ad hozzá, amelyek lehetővé teszik a fejlesztők számára, hogy lecserélik a memóriabeli objektumok gyorsítótárazására és a memóriamonitorozásra vonatkozó alapértelmezett ASP.NET-implementációkat. A fejlesztők a következő 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 felületen 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 folyamathoz beállított privát bájtkorlát 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 IObserver implementációkat rendelnek az alkalmazás memóriafigyelőjének.

Windows Communication Foundation (WCF)

A 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-keretrendszer 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.
  • Nagyobb megbízhatóság SharedConnectionListener és DuplexChannelBinderkapcsolat megszakításakor.
  • 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-keretrendszer 4.7-ben a Windows Forms javítja a magas DPI-monitorok támogatását.

magas DPI-támogatás

A .NET-keretrendszer 4.7-et célzó alkalmazásoktól kezdve a .NET-keretrendszer magas DPI- és dinamikus DPI-támogatást biztosít a 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 olyan bejelentkezési funkció, amelyet egy <System.Windows.Forms.ConfigurationSection> szakasz definiálásával konfigurálhat az alkalmazáskonfigurációs fájlban. További információ a magas DPI-támogatás és a dinamikus DPI-támogatás Windows Forms-alkalmazáshoz való hozzáadásáról: Magas DPI-támogatás a Windows Forms.

Windows Presentation Foundation (WPF)

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

Érintés/stylus verem támogatása, amely a Windows WM_POINTER-üzeneteken alapul

Mostantól lehetősége van a Windows Ink Services Platform (WISP) helyett WM_POINTER üzenetek alapján érintési/toll stack-et használni,. Ez egy jóváhagyási funkció a .NET-keretrendszerben. További információ: alkalmazáskompatibilitási szakasz.

WPF nyomtatási API-k új implementációja

A WPF System.Printing.PrintQueue osztályában található nyomtatási API-k az elavult XPS Print APIhelyett a Windows Print Document Package 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-keretrendszer 4.6.2 újdonságai

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

A .NET-keretrendszer 4.6.2-es verziójához hozzáadott új API-k listáját a .NET Framework 4.6.2 API Changes a GitHubon .NET Framework 4.6.2 API Changes című témakörben találja. A .NET-keretrendszer 4.6.2 funkciófejlesztéseinek és hibajavításainak listáját a GitHubon található .NET-keretrendszer 4.6.2 változások listája fejezetben tekintheti meg. További információ: .NET-keretrendszer 4.6.2- bejelentése a .NET blogban.

ASP.NET

A .NET-keretrendszer 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-keretrendszer 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 örökli, é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-keretrendszer 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. Azok a szolgáltatók, amelyek implementálják ezeket a módszereket, 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:

Karakterkategóriák

A .NET-keretrendszer 4.6.2-es verziójának karakterei a Unicode Standard 8.0.0-salapján vannak besorolva. A .NET-keretrendszer 4.6-os és .NET-keretrendszer 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 .NET-keretrendszer normál kifejezésmotorja által felismert karakterosztályok. 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 rendszereken a .NET-keretrendszer által biztosított karakteradatokra támaszkodik.

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

A .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-keretrendszer 4.6.2-es verziója lehetővé teszi az aláírások számítástechnikai használatát az SHA-2 kivonatoló algoritmuscsaláddal (SHA256, SHA384 és SHA512). A FIPS 186-3 támogatást az új System.Security.Cryptography.DSACng osztály biztosítja.

A .NET-keretrendszer 4.6-os RSA osztályának és a .NET-keretrendszer 4.6.1-es ECDsa osztályának legutóbbi változásaival összhangban a .NET-keretrendszer 4.6.2-es DSA absztrakt alaposztálya további módszerekkel teszi lehetővé a hívók számára, hogy öntés nélkül használják ezt a funkciót. 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

A .NET-keretrendszer 3.5-ös verziója 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.

Ennek a .NET-keretrendszer 4.6.2-es verziója során a következő három metódus lett hozzáadva az ECDiffieHellman alaposztályhoz, hogy egyértelműbbé tüntesse 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ára (CNG) támogatja a megmaradó szimmetrikus kulcsok tárolását és a hardveresen tárolt szimmetrikus kulcsok használatát, a .NET Framework 4.6.2 pedig 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

A .NET Framework 4.6.2 támogatja az RSA-SHA256, RSA-SHA384 és RSA-SHA512 PKCS#1 aláírási metódusok, valamint az 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

Az SQL Serverhez készült .NET-keretrendszer adatszolgáltatója (System.Data.SqlClient) a .NET-keretrendszer 4.6.2-ben a következő új funkciókat tartalmazza:

Kapcsolatkészletek és 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 Database-hez való csatlakozáskor, mivel a csatlakozási 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 kapcsolatkészlet blokkolási időszakának viselkedése törlődik, ha az Azure SQL Database-hez 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-hez 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, azOkat Azure SQL Database-nek tekintjük:

  • .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-keretrendszer 4.6.2-ben a Windows Communication Foundation a következő területeken lett továbbfejlesztve:

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-keretrendszer 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 a .NET-keretrendszer 4.6.2-et célozza meg, ez a funkció alapértelmezés szerint be van kapcsolva.

A .NET-keretrendszer 4.6.1-es és korábbi verzióit célzó, de a .NET-keretrendszer 4.6.2-es verzióján futó alkalmazások esetében ez a funkció a app.config vagy web.config fájl <futtatókörnyezeti> 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 TimeZone típus helyett a TimeZoneInfo 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-keretrendszer 4.6.2-ben a Windows Presentation Foundation a következő területeken lett továbbfejlesztve:

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 a WPF-alkalmazásokban azáltal, hogy automatikusan invokálják és elvetik az érintőbillentyűzetet a Windows 10-ben, amikor az érintéses bevitelt egy olyan vezérlő fogadja, amely szöveges bemenetet tud fogadni.

A .NET-keretrendszer korábbi verzióiban a WPF-alkalmazások nem tudnak a fókuszkövetést választani a WPF toll-/érintéses kézmozdulat támogatásának letiltása nélkül. Ennek eredményeképpen a WPF-alkalmazásoknak választaniuk kell a teljes WPF érintéses támogatás vagy a Windows általi egérként való kezelés között.

Monitoronkénti DPI

A WPF-alkalmazások magas DPI- és hibrid DPI-környezeteinek közelmúltbeli elterjedésének támogatására a .NET-keretrendszer 4.6.2-ben a WPF lehetővé teszi a monitoronkénti DPI-érzékenységet. A GitHubon található minták és a fejlesztői útmutató további információkat nyújtanak arról, hogyan teheti a WPF-alkalmazását monitoronkénti DPI-tudatossá.

A .NET-keretrendszer korábbi verzióiban a WPF-alkalmazások rendszer-DPI-vel tisztában vannak. 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-keretrendszer 4.6.2-es verziójában futó alkalmazások esetében letilthatja a figyelési DPI-módosításokat a WPF-alkalmazásokban, ha hozzáad egy konfigurációs utasítást az alkalmazáskonfigurációs fájl <futtatókörnyezeti> szakaszához, 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 a Visual Studio Designerben és a kód-munkafolyamatokban is. Az áthelyezett munkafolyamat-tervező a WF egyik fő funkciója, amely lehetővé teszi, hogy a Munkafolyamat-tervező a Visual Studión kívül (például a WPF-ben) legyen egy alkalmazásban. A 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 a Visual Studióból. 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. A .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."

munkafolyamat-fejlesztések a Visual Studio Munkafolyamat-tervezővel végzett dinamikus frissítés 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-keretrendszer 4.6.2 előtti verzióiban az XAML-fájl betöltése a Visual Studióban a DynamicUpdateServices.PrepareForUpdate hívása után mentett munkafolyamathoz a következő 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á

A Windows mostantól lehetővé teszi a meglévő asztali Windows-alkalmazások, köztük a WPF- és a Windows Forms-alkalmazások univerzális Windows-platformra (UWP) való eljuttatására szolgáló képességeket. 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-es eszközre.

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 minden Windows 10-eszköz számára elérhetővé tehető.

Hibakeresési fejlesztések

A .NET-keretrendszer 4.6.2-es verziójában továbbfejlesztettük a nem felügyelt hibakeresési API-, hogy további elemzéseket végezhessünk egy NullReferenceException dobáskor, hogy meghatározható legyen, 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-keretrendszer 4.6.1 újdonságai

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

A .NET-keretrendszer 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

A .NET Framework 4.6 rsACng-támogatást adott hozzá az X509-tanúsítványokhoz. A .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-keretrendszer 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 a .NET-keretrendszer 4.6-os keretrendszerében az aláírás létrehozásához szükséges kóddal szemben.

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őket adták hozzá ADO.NET-hez:

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

ADO.NET mostantól támogatja az Always Encrypted oszlop főkulcsainak natív tárolását hardveres biztonsági modulokban (HSM-ek). 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 kapcsolati sztringet, hogy szerepeljen benne a "MultisubnetFailover=true", jelezve, hogy egy AlwaysOn elérhetőségi 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)

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

Jobb teljesítmény

A .NET-keretrendszer 4.6.1-ben kijavítottuk az érintéses események késleltetését. 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 és újabb verziókban 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-et megelőző Windows-verziók funkciói nem változnak.

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

  • 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ólWPF blogbejegyzésben talál.

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

A .NET-keretrendszer 4.6.1-ben a 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. Windows 8.1 és Windows 10 rendszereken 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 a WPF helyesírás-ellenőrző API-k nem támogatják közvetlenül, és az alkalmazásokban a WPF-nek 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 nekünk javítani a mintáinkat azáltal, hogy beküldesz egy pull-requestet, vagy megnyitsz egy GitHub hibát.

DirectX-bővítmények

A 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 a 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.

Profil

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-ban egyre gyakoribb, hogy az assembly-ket (összeállításokat) a Roslyn a memóriában fordítja. 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 az ügyfelek számára, hogy 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 az IL PDB-t tartalmazó elemzőgépre másolja 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 a B gépre másolja, és hibakeresési felületi hozzáférési API-kat használni az IL PDB forrásának,to-IL leképezésének é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 .NET 2015 újdonságai

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

  • ASP.NET Core

    A .NET 2015 tartalmazza a ASP.NET Core-t, 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. ASP.NET Core-alkalmazásokat a Visual Studio 2015 vagy újabb verzióiban használható eszközökkel 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ás létrehozásához azonban a Visual Studio 2015-ben vagy újabb verziójában 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-keretrendszer 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 űrlaplapokon és a felhasználói vezérlőkben. 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>

      A .NET-keretrendszer 4.6-ot célzó alkalmazások esetében az alapértelmezett érték a true. A .NET-keretrendszer 4.6-os verzióján futó, de a keretrendszer egy korábbi verzióját célzó 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. HTTP/2 támogatás hozzá lett adva az ASP.NET-hez a .NET keretrendszer 4.6-os verziójához. Mivel a hálózati funkciók több rétegben is léteznek, új funkciókra volt szükség a Windowsban, az IIS-ben és a ASP.NET a HTTP/2 engedélyezéséhez. A HTTP/2 és a ASP.NET használatához Windows 10 rendszeren kell futnia.

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

      Annak érdekében, hogy a PUSH_PROMISE funkció használható legyen ASP.NET alkalmazásokban, a HttpResponse osztályhoz hozzáadtunk egy új, két túlterheléssel rendelkező metódust, PushPromise(String) és PushPromise(String, String, NameValueCollection).

      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 Token Binding Protocol böngészőfunkcióként lesz implementálva a Windows 10-ben. 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

      A .NET Framework 4.5 bevezetett egy randomizált sztringkivonat-algoritmust. A ASP.NET azonban nem támogatta, mert bizonyos ASP.NET funkciók stabil kivonatkódtól függtek. A .NET-keretrendszer 4.6-os verziója mostantól támogatja a véletlenszerű sztringkivonat-algoritmusokat. 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 az SQL Server 2016-ban elérhető Always Encrypted funkciót. Az Always Encrypted használatával az 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 (adatbázismotor) és Always Encrypted (ügyfélfejlesztési).

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

    A .NET Framework 4.6 a 64 bites JIT-fordító (eredetileg RyuJIT kódnevű) ú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-keretrendszer 4.6-os verzióján 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 hasznos a nagy 32 bites alkalmazások (például a Visual Studio) számára, és fizikai memóriát is ment.

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

    Számos új API lett hozzáadva a .NET-keretrendszer 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, hogy támogassa a Windows CNG titkosítási API-kat. A .NET-keretrendszer korábbi verziói teljes mértékben a Windows titkosítási API-k korábbi 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.

      A .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 a .NET-keretrendszer korábbi verzióiban az alábbihoz hasonló kód szükséges.

        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-keretrendszer 4.6-os keretrendszerében az új titkosítási API-kat használó kód az alábbiak szerint írható át a leadás 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. Az olyan alkalmazások viselkedése, amelyek a .NET-keretrendszer korábbi verzióit célozzák, vagy amelyek nem a .NET-keretrendszer egy adott verzióját célozzák, nem érintik. 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-keretrendszer 4.6-ba.

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

      • 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 WPF HDPI-támogatása mostantól jobb a .NET-keretrendszer 4.6-os verziója esetén. 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 engedélyezett, ha a TargetFrameworkAttribute .NET-keretrendszer 4.6-os értékre van állítva. Azok az alkalmazások, amelyek a keretrendszer korábbi verzióit célozzák, de a .NET-keretrendszer 4.6-os verzióján futnak, az alábbi sor hozzáadásával engedélyezhetik az új viselkedést a app.config fájl <futtatókörnyezeti> szakaszához:

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

      A WPF-ablakok több különböző DPI-beállítással (multi-DPI beállítás) rendelkező monitort teljes mértékben renderelnek elsötétített régiók nélkül. 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 támogatás hozzá lett adva a System.Windows.Input.Cursor-hoz, hogy a DPI-beállítás alapján automatikusan betöltse a megfelelő kurzort.

    • Touch jobb

      A .NET-keretrendszer 4.6-os verziójában az Connect érintéstől kiszámíthatatlan viselkedést okozó ügyféljelentések megoldásra kerültek. A Windows Áruházbeli alkalmazások és a WPF-alkalmazások dupla koppintásos küszöbértéke mostantól megegyezik a Windows 8.1 és újabb verziókban.

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

      A WPF a .NET Framework 4.6-ban támogatja a windows 8.1 és újabb rendszereken futó transzparens gyermekablakokat. Í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.

  • hálózatépítés

    • Foglalat újrafelhasználása

      A Windows 10 tartalmaz egy új, nagy méretezhetőségű hálózati algoritmust, amely a kimenő TCP-kapcsolatokhoz a helyi portok újrahasználatával teszi jobbá a gépi erőforrások használatát. A .NET Framework 4.6 támogatja az új algoritmust, így a .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), amely korlátozhatja a szolgáltatás méretezhetőségét azáltal, hogy terhelés alatt portkimerülést okoz.

      A .NET-keretrendszer 4.6-os verziója két API-t ad hozzá a portok újrafelhasználásának engedélyezéséhez, amelyek hatékonyan eltávolítják az egyidejű kapcsolatokra vonatkozó 64 KB-os korlátot:

      Alapértelmezés szerint a ServicePointManager.ReusePort tulajdonság false, kivéve, ha a HKLM\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 szabályozókulcs HWRPortReuseOnSocketBind é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 HttpWebRequest összes kimenő TCP-socket kapcsolata egy új Windows 10 socket opciót, a SO_REUSE_UNICASTPORT-t használ, 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.

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

    A .NET-keretrendszer 4.6-os verziója bővítette ezt a funkciót, amely tartalmazza a DomainUpDown, NumericUpDown, DataGridViewComboBoxColumn, DataGridViewColumn és ToolStripSplitButton típusokat, valamint a UITypeEditorrajzolásakor használt Bounds tulajdonság által megadott téglalapot .

    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

    A .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 a .NET Core-ban nem támogatott kódlapkódolások támogatásához a kódlapkódolásokat a Encoding.RegisterProvider metódussal regisztrálhatja. További információ: System.Text.CodePagesEncodingProvider.

  • .NET natív

A C# vagy Visual Basic nyelven írt univerzális Windows Platform -alkalmazások kihasználhatják egy új technológia előnyeit, amely az alkalmazásokat natív kódra fordítja, nem pedig IL-ra. 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óért lásd: Alkalmazások fordítása a .NET Native használatával. A .NET Native áttekintéséhez, 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 a kódja számára, tekintse meg .NET Native és fordítás.

Az alkalmazások alapértelmezés szerint natív kódra vannak lefordítva, amikor a Visual Studio 2015-höz vagy újabb verzióhoz fordítja őket. További információ: .NET natívhasználatának első lépései.

A .NET natív alkalmazások hibakeresésének támogatásához számos új felület és számbavétel lett hozzáadva a nem felügyelt hibakeresési API-hoz. További információ: hibakeresés (nem felügyelt API-referencia) témakör.

A .NET-keretrendszer 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 munkavégző 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 a Windows Forms vezérlőiben. 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. A .NET-keretrendszer 4.5.2-es verziója lehetővé teszi a folyamaton kívüli, Event Tracing for Windows (ETW)-alapú tevékenységkövetést egy nagyobb felülethez. 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-t adtunk hozzá a .NET-keretrendszer 4.5.2-es és 4.6-os verzióhoz:

    [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-keretrendszer 4.5.1 újdonságai

2014. áprilisi frissítések:

  • Visual Studio 2013 Update 2 tartalmazza a Portable Class Library sablonok frissítéseit az alábbi forgatókönyvek támogatásához:

    • A Windows Runtime API-kat a Windows 8.1, a Windows Phone 8.1 és a Windows Phone Silverlight 8.1 rendszerű hordozható kódtárakban használhatja.

    • Windows 8.1 vagy Windows Phone 8.1 megcélzásakor a hordozható könyvtárakban XAML (Windows.UI.XAML-típusok) is szerepelhet. 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-futtatókörnyezeti összetevőt (.winmd fájlt) a Windows 8.1-et és a Windows Phone 8.1-et célzó Áruházbeli alkalmazásokban való használatra.

    • A Windows Áruház vagy a Windows Phone Áruház osztálykönyvtárait átirányíthatja például hordozható osztálykönyvtárként is.

    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 most már tartalmazza a .NET Native dokumentációját, amely a Windows-alkalmazások létrehozásának és üzembe helyezésének előre összeállított technológiája. A .NET Native közvetlenül natív kódra fordítja az alkalmazásokat, nem pedig a köztes nyelvre (IL) a jobb teljesítmény érdekében. További információ: Alkalmazások fordítása a .NET Native segítségével.

  • A .NET-keretrendszer referenciaforrásának új böngészési élményt és továbbfejlesztett funkciókat biztosít. Most már online böngészhet a .NET-keretrendszer forráskódja között, letöltheti a hivatkozási 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). További információkért lásd a blogbejegyzést, .NET-referenciaforrás új megjelenése.

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

  • Automatikus kötésátirányítás szerelvényekhez. A Visual Studio 2013-tól kezdve a .NET-keretrendszer 4.5.1-et célzó alkalmazások fordításakor kötésá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 projektek esetében 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 EventSource osztály WriteEventWithRelatedActivityId és WriteEventWithRelatedActivityIdCore 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 tekintse meg 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 részletekért lásd a .NET-keretrendszer 4.5.1 bejelentése és az ASP.NET alkalmazás felfüggesztése blogbejegyzést.

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

  • Átméretezés a Windows Forms vezérlőiben. 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:

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

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

  • Értékeket ad vissza a Visual Studio hibakeresőjében. Ha a Visual Studio 2013-ban hibakeresést hajt végre egy felügyelt alkalmazásban, 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. A Visual Studio 2013 támogatja a Szerkesztés és folytatás funkciót az asztali, Windows Áruházbeli és Windows Phone rendszerű, 64 bites felügyelt alkalmazásokhoz. 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ási verem elrejti a fordítók által az aszinkron programozás támogatásához biztosított infrastruktúrakódot, és a logikai szülőkereteket összefűzi, hogy a logikai programvégrehajtást világosabban követni tudja. 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-keretrendszer 4.5.1-es bejelentési"Aszinkron hibakeresés" című szakaszában olvashat.

  • Jobb kivételtámogatás a Windows Futtatókörnyezet-összetevőkhöz. A Windows 8.1-ben a 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-keretrendszer 4.5.1-es bejelentési"Windows Áruházbeli alkalmazásfejlesztés" szakaszában olvashat.

A Visual Studio 2013-tól kezdve a Felügyelt profil irányított optimalizálási eszközével (Mpgo.exe) optimalizálhatja a Windows 8.x Áruházbeli alkalmazásokat és az asztali alkalmazásokat.

A ASP.NET 4.5.1-es verziójának új funkcióit a Visual Studio 2013 ASP.NET és Web Tools kibocsátási megjegyzéseicímű témakörben talál.

A .NET-keretrendszer 4.5 újdonságai

Alaposztályok

  • A rendszer újraindításának csökkentése a .NET-keretrendszer 4-alkalmazások észlelésével és bezárásával az üzembe helyezés során. Lásd A rendszer újraindításának csökkentése a .NET-keretrendszer 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. Lásd a <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-keretrendszer 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: 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 használt verziójának támogatása, ha a System.Globalization.IdnMapping osztályt Windows 8 rendszeren használják.

  • A Unicode 6.0-t implementáló operációs rendszerrel való sztring-összehasonlítás delegálása a .NET-keretrendszer Windows 8-on való használatakor. Ha más platformokon fut, 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: Tükröződés a Windows Áruházbeli alkalmazások .NET-keretrendszerében.

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

A .NET-keretrendszer 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 a 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 Studióban, válassza a NuGet-csomagok kezelése lehetőséget a Project menüjében, és keressen rá 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 a 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-keretrendszer 4.5-ös verziójában az erőforrásfájl-generátor (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]). A Visual Studio 2013-tól kezdve a Mpgo.exe használatával optimalizálhatja a Windows 8.x Áruházbeli alkalmazásokat és az asztali alkalmazásokat.

Párhuzamos számítástechnika

A .NET Framework 4.5 számos új funkciót és fejlesztést biztosít a párhuzamos számítástechnika számára. 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. Keresd a „Újdonságok a párhuzamosság terén a .NET keretrendszer 4.5-ben” című bejegyzést a „Párhuzamos programozás a .NET-tel” blogon.

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

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

A .NET Framework 4.5 emellett az alábbi hálózatkezelési fejlesztéseket is 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 Visual Studio általi ellenőrzése 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 az 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ó: A Windows Communication Foundationújdonságai.

Windows Workflow Foundation (WF)

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

  • Állapotgép-munkafolyamatok, amelyek először a .NET-keretrendszer 4.0.1 részeként lettek bevezetve (.NET Framework 4 Platform Update 1). 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. Ezek az osztályok és tevékenységek frissültek a .NET-keretrendszer 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 képességek a Visual Studióban, beleértve gyorskeresési és Keresés fájlokban.

    • 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 Basicet használó munkafolyamat-projektek Visual Basic-kifejezéseket, a C# munkafolyamat-projektek pedig C# kifejezéseket használnak.

    • A Visual Studio 2010-ben 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ó: A Windows Workflow Foundationújdonságai.

.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 a Windows operációs rendszer előnyeit. A .NET-keretrendszer 4.5-ös vagy 4.5.1-ös részhalmaza windowsos Windows 8.x Áruházbeli alkalmazások C# vagy Visual Basic használatával történő létrehozásához érhető el. Ezt az alkészletet .NET-nek nevezzük Windows 8.x Áruház alkalmazásokhoz, és egy áttekintésbenkerül bemutatásra.

Hordozható osztálykönyvtárak

A Visual Studio 2012 (és újabb verziók) Hordozható osztálytár projektje lehetővé teszi felügyelt szerelvények írását és összeállítását, amelyek több .NET-keretrendszerplatformon működnek. A Portable Class Library projekt használatával kiválaszthatja a megcélzott platformokat (például Windows Phone és .NET for 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: