Újracélzás a .NET-keretrendszer 4.6.x-re való átállásához

Ez a cikk felsorolja azokat az alkalmazáskompatibilitási problémákat, amelyeket a .NET-keretrendszer 4.6, 4.6.1 és 4.6.2 által bevezetett.

.NET-keretrendszer 4.6

ASP.NET

A HtmlTextWriter nem jeleníti meg <br/> megfelelően az elemet

Részletek

A .NET-keretrendszer 4.6-os verziójától kezdődően a RenderBeginTag(String) és RenderEndTag() hívása a <BR /> elemmel helyesen csak egy <BR />-t szúr be (kettő helyett)

Javaslat

Ha egy alkalmazás a további <BR /> címkétől függ, RenderBeginTag(String) akkor második alkalommal kell meghívni. Vegye figyelembe, hogy ez a viselkedésváltozás csak a .NET-keretrendszer 4.6-os vagy újabb verziót célzó alkalmazásokat érinti, ezért a másik lehetőség a .NET-keretrendszer egy korábbi verziójának megcélzása a régi viselkedés elérése érdekében.

Név Érték
Hatókör Edge
Verzió 4,6
Típus Újratargeting

Érintett API-k

ClickOnce

Az SHA-256 kódaláíró tanúsítványt használó ClickOnce-nal közzétett alkalmazások sikertelenek lehetnek Windows 2003 rendszeren

Részletek

A végrehajtható fájl az SHA256-tal van aláírva. Korábban az SHA1-zel írták alá, függetlenül attól, hogy a kódaláíró tanúsítvány SHA-1 vagy SHA-256 volt-e. Ez a következőkre vonatkozik:

  • A Visual Studio 2012 vagy újabb verziójával készült összes alkalmazás.
  • A Visual Studio 2010-et vagy korábbi verziót tartalmazó alkalmazások a .NET-keretrendszer 4.5-ös verziójú rendszereken. Ezenkívül, ha a .NET-keretrendszer 4.5-ös vagy újabb verzió van jelen, a ClickOnce-manifesztumot SHA-256-tal is aláírják, ha SHA-256 tanúsítványok érhetők el, függetlenül attól, hogy melyik .NET-keretrendszer verzióra lett fordítva.

Javaslat

A ClickOnce végrehajtható fájl aláírásának megváltoztatása csak a Windows Server 2003 rendszereket érinti; ezek igénylik a KB 938397 telepítését. A jegyzék sha-256-tal való aláírásának módosítása akkor is, ha egy alkalmazás a .NET-keretrendszer 4.0-s vagy korábbi verzióit célozza, futtatókörnyezeti függőséget vezet be a .NET-keretrendszer 4.5-ös vagy újabb verziójára.

Név Érték
Hatókör Edge
Verzió 4,5
Típus Újratargeting

A ClickOnce támogatja az SHA-256-ot 4.0-s célalkalmazásokon

Részletek

Korábban az SHA-256-tal aláírt tanúsítvánnyal rendelkező ClickOnce-alkalmazásnak .NET-keretrendszer 4.5-ös vagy újabb verziójára lenne szükség, még akkor is, ha az alkalmazás a 4.0-s verziót célozta meg. Most .NET-keretrendszer 4.0-s célzott ClickOnce-alkalmazások akkor is futtathatók .NET-keretrendszer 4.0-n, ha sha-256-tal van aláírva.

Javaslat

Ez a módosítás eltávolítja a függőséget, és lehetővé teszi az SHA-256-tanúsítványok használatát a ClickOnce-alkalmazások aláírásához, amelyek .NET-keretrendszer 4- és korábbi verziót céloznak meg.

Név Érték
Hatókör Csekély
Verzió 4,6
Típus Újratargeting

Alapvető

A CurrentCulture és a CurrentUICulture átterjed a tevékenységek során

Részletek

A .NET-keretrendszer 4.6-tól kezdve a System.Globalization.CultureInfo.CurrentCulture és System.Globalization.CultureInfo.CurrentUICulture tárolása a szál System.Threading.ExecutionContext-jában történik, amely folyamatosan továbbítódik az aszinkron műveleteken keresztül. Ez azt jelenti, hogy a System.Globalization.CultureInfo.CurrentCulture vagy System.Globalization.CultureInfo.CurrentUICulture módosításai megjelennek a később aszinkron módon futó feladatokban. Ez eltér a korábbi .NET-keretrendszer verziók viselkedésétől (ami alaphelyzetbe állítaná System.Globalization.CultureInfo.CurrentCulture, és System.Globalization.CultureInfo.CurrentUICulture minden aszinkron feladatban).

Javaslat

A módosítás által érintett alkalmazások a kívánt System.Globalization.CultureInfo.CurrentCulture vagy System.Globalization.CultureInfo.CurrentUICulture az aszinkron tevékenység első műveletének explicit beállításával megkerülhetik a módosítást. Másik lehetőségként a régi viselkedés (nem áramló System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture) a következő kompatibilitási kapcsoló beállításával választható:

AppContext.SetSwitch("Switch.System.Globalization.NoAsyncCurrentCulture", true);

Ezt a problémát a WPF a .NET-keretrendszer 4.6.2-es verziójában javította. A 4.6-os, 4.6.1-s és KB-3139549 .NET-keretrendszer is kijavítottuk. A .NET-keretrendszer 4.6-os vagy újabb verzióját megcélzó alkalmazások automatikusan a helyes működést biztosítják a WPF-alkalmazásokban – a System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture kijelölések megmaradnak a Dispatcher műveletek során.

Név Érték
Hatókör Csekély
Verzió 4,6
Típus Újracélzás

Érintett API-k

Az ETW-eseménynevek nem térhetnek el csak a "Start" vagy a "Stop" utótagtól

Részletek

A .NET-keretrendszer 4.6-os és 4.6.1-es verziójában a futtatókörnyezet kivételt dob ArgumentException, amikor a Windows eseménykövetésének (ETW) két eseményneve csak a "Start" vagy "Stop" utótagban tér el (például, amikor az egyik esemény neve LogUser, a másiké pedig LogUserStart). Ebben az esetben a futtatókörnyezet nem tudja létrehozni az eseményforrást, amely nem tud naplózást kibocsátni.

Javaslat

A kivétel elkerülése érdekében győződjön meg arról, hogy egyetlen két eseménynév sem tér el csak a "Start" vagy a "Stop" utótagtól. Ez a követelmény a 4.6.2-.NET-keretrendszer kezdve megszűnik; a futtatókörnyezet csak a "Start" és a "Stop" utótaggal eltérő eseményneveket jelezheti.

Név Érték
Hatókör Edge
Verzió 4,6
Típus Újracélzás

Entity Framework

Az Entity Framework edmx Visual Studio 2013-nal való létrehozása meghiúsulhat MSB4062 hibával, ha az EntityDeploySplit vagy az EntityClean feladatokat használja

Részletek

Az MSBuild 12.0-eszközök (a Visual Studio 2013-ban) megváltoztatták az MSBuild fájlhelyeket, ami miatt a régebbi Entity Framework-célfájlok érvénytelenek. Az az eredmény, hogy a EntityDeploySplit és EntityClean feladatok sikertelenek, mert nem találják meg a Microsoft.Data.Entity.Build.Tasks.dll-t. Vegye figyelembe, hogy ez a törés egy eszközkészlet (MSBuild/VS) változása miatt van, nem pedig egy .NET-keretrendszer változás miatt. Ez csak a fejlesztői eszközök frissítésekor fordul elő, nem pedig csak a .NET-keretrendszer frissítésekor.

Javaslat

Az Entity Framework célfájljai módosítva lettek, hogy együttműködjenek az új MSBuild-elrendezéssel, amely a .NET-keretrendszer 4.6-os verziójától kezdődik. A keretrendszer erre a verziójára való frissítés megoldja ezt a problémát. Alternatív megoldásként ez a megoldás közvetlenül használható a célfájlok kijavítására.

Név Érték
Hatókör Fő
Verzió 4.5.1
Típus Újracélzás

JIT

Az IL újrapróbálkozása nem engedélyezett a próbarégióban

Részletek

A JIT64 igény szerinti fordítóval ellentétben a RyuJIT (a .NET-keretrendszer 4.6-os verziójában) nem engedélyezi az IL ret utasítást a try régióban. A próbarégióból való visszatérést az ECMA-335 specifikáció nem engedélyezi, és egy ismert felügyelt fordító sem hoz létre ilyen IL-t. A JIT64 fordító azonban akkor hajtja végre az ilyen IL-t, ha azt reflexiókibocsátással hozzák létre.

Javaslat

Ha egy alkalmazás olyan IL-t hoz létre, amely egy ret opkódot tartalmaz egy próbarészben, az alkalmazás a .NET-keretrendszer 4.5-öt célozhatja meg, hogy a régi JIT-et használja, és elkerülje ezt a hibát. Másik lehetőségként a létrehozott IL frissíthető, hogy a próbarégió után visszatérjen.

Név Érték
Hatókör Edge
Verzió 4,6
Típus Újracélzás

Új 64 bites JIT-fordító a .NET-keretrendszer 4.6-ban

Részletek

A .NET-keretrendszer 4.6-ostól kezdve egy új, 64 bites JIT-fordítót használunk az igény szerinti fordításhoz. Bizonyos esetekben váratlan kivétel történik, vagy más viselkedés figyelhető meg, mint ha egy alkalmazást a 32 bites fordítóval vagy a régebbi 64 bites JIT-fordítóval futtatnak. Ez a módosítás nem érinti a 32 bites JIT-fordítót. Az ismert különbségek a következők:

  • Bizonyos feltételek mellett a kicsomagolási művelet egy NullReferenceException hibát okozhat Release build esetén, ha az optimalizálás be van kapcsolva.
  • Bizonyos esetekben az éles kód végrehajtása során egy nagy metódustörzsben dobhat egy StackOverflowException.
  • Bizonyos feltételek mellett a metódusnak átadott struktúrákat nem értéktípusokként, hanem referenciatípusokként kezelik a kiadási buildekben. A probléma egyik megnyilvánulása, hogy a gyűjtemény egyes elemei váratlan sorrendben jelennek meg.
  • Bizonyos feltételek mellett az értékek és a nagy bitkészlet összehasonlítása UInt16 helytelen, ha az optimalizálás engedélyezve van.
  • Bizonyos feltételek mellett, különösen a tömbértékek inicializálása esetén az IL utasítás memória inicializálása helytelen értékkel inicializálhatja a OpCodes.Initblk memóriát. Ez nem kezelt kivételt vagy helytelen kimenetet eredményezhet.
  • Bizonyos ritka körülmények között a feltételes bitteszt visszaadhatja a helytelen Boolean értéket, vagy kivételt okozhat, ha a fordítóoptimalizálás engedélyezve van.
  • Bizonyos feltételek mellett, ha egy if utasítást egy feltétel tesztelésére használunk egy try blokkba való belépés előtt, és ugyanazt a feltételt kiértékeljük a kilépéskor a try blokkból, valamint a catch vagy a finally blokkban, az új 64 bites JIT-fordító optimalizálás közben eltávolítja a if feltételt a catch vagy finally blokkból. Ennek eredményeképpen a rendszer feltétel nélkül végrehajtja az if utasításban vagy catch blokkban finally lévő kódot.

Javaslat

Ismert problémák elhárítása
Ha a fent felsorolt problémákat tapasztalja, az alábbiak bármelyikével elháríthatja őket:

  • Frissítsen a .NET-keretrendszer 4.6.2-re. A .NET-keretrendszer 4.6.2-ben található új 64 bites fordító az ismert problémák mindegyikét kezeli.

  • A Windows Update futtatásával győződjön meg arról, hogy a Windows verziója naprakész. A .NET keretrendszer 4.6 és 4.6.1 szolgáltatásfrissítései minden problémát kezelnek, kivéve a NullReferenceException kicsomagolási műveletet.

  • Fordítás a régebbi, 64 bites JIT-fordítóval. Ennek módjáról további információt az egyéb problémák elhárítása című szakaszban talál. Egyéb problémák elhárítása
    Ha a régebbi 64 bites fordítóval és az új 64 bites JIT-fordítóval lefordított kód, illetve az új 64 bites JIT-fordítóval lefordított alkalmazás hibakeresési és kiadási verziói között bármilyen más eltérést tapasztal, az alábbiakat követve fordíthatja le az alkalmazást a régebbi 64 bites JIT-fordítóval:

  • Alkalmazásonként hozzáadhatja az elemet az < alkalmazás konfigurációs fájljához. A következő letiltja a fordítást az új 64 bites JIT-fordítóval, és ehelyett az örökölt 64 bites JIT-fordítót használja.

    <?xml version ="1.0"?>
<configuration>
  <runtime>
   <useLegacyJit enabled="1" />
  </runtime>
</configuration>

  • Felhasználónként hozzáadhat egy HKEY_CURRENT_USER\SOFTWARE\Microsoft\.NETFramework értéket, amelyet useLegacyJit néven a REG_DWORD kulcshoz a beállításjegyzékben. Az 1 érték lehetővé teszi az örökölt 64 bites JIT-fordítót; a 0 érték letiltja, és engedélyezi az új 64 bites JIT-fordítót.

  • Gépenként hozzáadhat egy HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework értéket a useLegacyJit beállításjegyzék kulcsához REG_DWORD néven. Egy érték 1 lehetővé teszi az örökölt 64 bites JIT-fordítót; egy érték 0 letiltja azt, és engedélyezi az új 64 bites JIT-fordítót. A problémáról úgy is tudathatja velünk, ha hibajelentést küld a Microsoft Connect szolgáltatásra.

Név Érték
Hatókör Edge
Verzió 4,6
Típus Újracélzás

hálózat

EKU OID tanúsítvány érvényesítése

Részletek

A .NET-keretrendszer 4.6-os verziójától kezdve az SslStream vagy ServicePointManager osztályok továbbfejlesztett kulcshasználati (EKU) objektumazonosító (OID) érvényesítést hajtanak végre. A továbbfejlesztett kulcshasználati (EKU) bővítmény objektumazonosítók (OID-k) gyűjteménye, amelyek a kulcsot használó alkalmazásokat jelzik. Az EKU OID érvényesítése távoli tanúsítványvisszahívásokkal biztosítja, hogy a távoli tanúsítvány a megfelelő OID-kkel rendelkezzen a kívánt célra.

Javaslat

Ha ez a módosítás nem kívánatos, letilthatja a tanúsítvány EKU OID-ellenőrzését úgy, hogy hozzáadja az alábbi kapcsolót az <AppContextSwitchOverrideshez> az ` alkalmazáskonfigurációs fájlban:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.Net.DontCheckCertificateEKUs=true" />
</runtime>

Fontos

Ez a beállítás csak a visszamenőleges kompatibilitás érdekében van megadva. Használata egyébként nem ajánlott.

Név Érték
Hatókör Csekély
Verzió 4,6
Típus Újracélzás

Érintett API-k

Csak a System.Net.ServicePointManagerben és a System.Net.Security.SslStreamben támogatott Tls 1.0-s, 1.1-s és 1.2-s protokollok támogatottak

Részletek

A .NET-keretrendszer 4.6-os verziójától kezdve az ServicePointManager osztályok csak SslStream a következő három protokoll egyikét használhatják: Tls1.0, Tls1.1 vagy Tls1.2. Az SSL3.0 protokoll és az RC4 titkosítás nem támogatott.

Javaslat

A javasolt kockázatcsökkentés az, ha a féloldali alkalmazást Tls1.0, Tls1.1 vagy Tls1.2 verzióra frissíti. Ha ez nem kivitelezhető, vagy ha az ügyfélalkalmazások meghibásodnak, az System.AppContext osztály két módon is letiltható a szolgáltatásból:

<AppContextSwitchOverrides value="Switch.System.Net.DontEnableSchUseStrongCrypto=true"/>
Név Érték
Hatókör Csekély
Verzió 4,6
Típus Újracélzás

Érintett API-k

A TLS 1.x alapértelmezés szerint átadja a SCH_SEND_AUX_RECORD jelzőt a mögöttes SCHANNEL API-nak

Részletek

A TLS 1.x használatakor a .NET-keretrendszer a mögöttes Windows SCHANNEL API-ra támaszkodik. A .NET-keretrendszer 4.6-ostól kezdve a SCH_SEND_AUX_RECORD jelző alapértelmezés szerint át lesz adva az SCHANNEL-nek. Ez azt eredményezi, hogy az SCHANNEL két külön rekordra osztja fel az adatokat, az elsőt egyetlen bájtra, a másodikat pedig n-1 bájtra. Ritkán ez megszakítja az ügyfelek és a meglévő kiszolgálók közötti kommunikációt, amelyek feltételezik, hogy az adatok egyetlen rekordban találhatók.

Javaslat

Ha ez a módosítás megszakítja a meglévő kiszolgálóval való kommunikációt, letilthatja a SCH_SEND_AUX_RECORD jelző küldését, és visszaállíthatja az adatok külön rekordokra való felosztásának korábbi viselkedését az alábbi kapcsoló hozzáadásával az <AppContextSwitchOverrides><runtime> alkalmazáskonfigurációs fájl szakaszának eleméhez:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.Net.DontEnableSchSendAuxRecord=true" />
</runtime>

Fontos

Ez a beállítás csak a visszamenőleges kompatibilitás érdekében van megadva. Használata egyébként nem ajánlott.

Név Érték
Hatókör Edge
Verzió 4,6
Típus Újracélzás

Érintett API-k

Windows Communication Foundation (WCF)

Módosult a CreateDefaultAuthorizationContext meghívása null argumentummal

Részletek

A System.IdentityModel.Policy.AuthorizationContext.CreateDefaultAuthorizationContext(IList<IAuthorizationPolicy>) hívása, amelynek az authorizationPolicies argumentuma null, a .NET-keretrendszer 4.6-os verziójában megváltoztatta a System.IdentityModel.Policy.AuthorizationContext végrehajtását.

Javaslat

Ritkán előfordulhat, hogy az egyéni hitelesítést használó WCF-alkalmazások viselkedésbeli különbségeket tapasztalnak. Ilyen esetekben az előző viselkedés kétféleképpen állítható vissza:

  • Fordítsa újra az alkalmazását a .NET-keretrendszer egy 4.6-nál korábbi verziójának megcélzásához. Az IIS által üzemeltetett szolgáltatások esetében használja az elemet a <httpRuntime targetFramework="x.x"> .NET-keretrendszer egy korábbi verziójának megcélzásához.

  • Adja hozzá a következő sort az <appSettings> app.config fájl szakaszához:

    <add key="appContext.SetSwitch:Switch.System.IdentityModel.EnableCachedEmptyDefaultAuthorizationContext" value="true" />
Név Érték
Hatókör Csekély
Verzió 4,6
Típus Újracélzás

Érintett API-k

Windows Forms

Az Icon.ToBitmap sikeresen konvertálja a PNG-keretekkel rendelkező ikonokat Bitmap-objektumokká

Részletek

A .NET-keretrendszer 4.6-ot megcélzó alkalmazásoktól kezdve a metódus sikeresen konvertálja a Icon.ToBitmap PNG-keretekkel rendelkező ikonokat Bitmap-objektumokká.

A .NET-keretrendszer 4.5.2-s és korábbi verzióit megcélzó alkalmazásokban a Icon.ToBitmap metódus kivételt ArgumentOutOfRangeException eredményez, ha az Icon objektum PNG-keretekkel rendelkezik.

Ez a változtatás azokat az alkalmazásokat érinti, amelyeket a .NET-keretrendszer 4.6-ra újrafordítottak, és amelyek különleges kezelést valósítanak meg a ArgumentOutOfRangeException kivétellel kapcsolatban, amely az ikonobjektumok PNG-kereteinél jelentkezik. Ha a program a .NET-keretrendszer 4.6 alatt fut, az átalakítás sikeres, így a ArgumentOutOfRangeException már nem váltódik ki, ezért a kivételkezelő sem lesz meghívva.

Javaslat

Ha ez a viselkedés nem kívánatos, megtarthatja az előző viselkedést úgy, hogy hozzáadja az alábbi elemet az <runtime> app.config fájl szakaszához:

<AppContextSwitchOverrides
value="Switch.System.Drawing.DontSupportPngFramesInIcons=true" />

Ha az app.config fájl már tartalmazza az AppContextSwitchOverrides elemet, az új értéket egyesíteni kell az alábbi értékattribútummal:

<AppContextSwitchOverrides
value="Switch.System.Drawing.DontSupportPngFramesInIcons=true;<previous key>=<previous value>" />
Név Érték
Hatókör Csekély
Verzió 4,6
Típus Újracélzás

Érintett API-k

Windows Presentation Foundation (WPF)

A CurrentCulture nem marad meg a WPF-ütemező műveletek között

Részletek

A .NET-keretrendszer 4.6-os verziójától kezdve a System.Globalization.CultureInfo.CurrentCulture vagy a System.Globalization.CultureInfo.CurrentUICulture módosításai, amelyeket a System.Windows.Threading.Dispatcher belül hajtanak végre, elvesznek a diszpécser művelet végén. Hasonlóképpen előfordulhat, hogy a System.Globalization.CultureInfo.CurrentCulture diszpécserművelet vagy a System.Globalization.CultureInfo.CurrentUICulture kívül végzett módosítások nem jelennek meg a művelet végrehajtásakor. Gyakorlatilag ez azt jelenti, hogy a System.Globalization.CultureInfo.CurrentCulture és System.Globalization.CultureInfo.CurrentUICulture közötti változások nem biztos, hogy áramlanak a WPF felhasználói felületi visszahívások és egyéb WPF-alkalmazási kódok között. Ennek oka, hogy a System.Threading.ExecutionContext-ben bekövetkezett változás miatt System.Globalization.CultureInfo.CurrentCulture és System.Globalization.CultureInfo.CurrentUICulture a végrehajtási környezetben kerül tárolásra a .NET-keretrendszer 4.6-os verzióját célzó alkalmazásokban. A WPF-diszpécserműveletek a művelet megkezdéséhez használt végrehajtási környezetet tárolják, és a művelet befejezésekor visszaállítják az előző környezetet. System.Globalization.CultureInfo.CurrentCulture és System.Globalization.CultureInfo.CurrentUICulture most már a környezet részét képezik, így a diszpécserműveleten belüli módosítások nem maradnak meg a műveleten kívül.

Javaslat

A változás által érintett alkalmazások megkerülhetik ezt azzal, hogy a kívánt System.Globalization.CultureInfo.CurrentCulture vagy System.Globalization.CultureInfo.CurrentUICulture egy mezőbe tárolják, és minden Dispatcher-műveleti törzsben (beleértve a felhasználói felület esemény-visszahívási kezelőit is) ellenőrzik, hogy a megfelelő System.Globalization.CultureInfo.CurrentCulture és System.Globalization.CultureInfo.CurrentUICulture be vannak állítva. Alternatív megoldásként, mivel a WPF-változás alapjául szolgáló ExecutionContext-módosítás csak a .NET-keretrendszer 4.6-os vagy újabb verziót célzó alkalmazásokat érinti, ez a törés elkerülhető a .NET-keretrendszer 4.5.2.-.NET-keretrendszer 4.6-os vagy újabb verziót célzó alkalmazások esetében is, ha a következő kompatibilitási kapcsolót állítja be:

AppContext.SetSwitch("Switch.System.Globalization.NoAsyncCurrentCulture", true);

Ezt a problémát a WPF a .NET-keretrendszer 4.6.2-es verziójában javította. A 4.6-os, 4.6.1-s és KB-3139549 .NET-keretrendszer is kijavítottuk. A .NET-keretrendszer 4.6-os vagy újabb verzióját megcélzó alkalmazások automatikusan a helyes működést biztosítják a WPF-alkalmazásokban – a System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture kijelölések megmaradnak a Dispatcher műveletek során.

Név Érték
Hatókör Csekély
Verzió 4,6
Típus Újratargeting

A WPF-elrendezésben a margók kerekítése megváltozott

Részletek

A margók lekerekítésének módja, a szegélyek és a bennük lévő háttér megváltozott. A változás eredményeként:

  • Az elemek szélessége vagy magassága legfeljebb egy képponttal nőhet vagy csökkenhet.
  • Egy objektum elhelyezése legfeljebb egy képponttal mozgatható.
  • A középre igazított elemek legfeljebb egy képponttal eltérhetnek a középponttól függőlegesen vagy vízszintesen. Alapértelmezés szerint ez az új elrendezés csak a .NET-keretrendszer 4.6-ot célzó alkalmazások esetében engedélyezett.

Javaslat

Mivel ez a módosítás általában megszünteti a WPF-vezérlők jobb vagy alsó részének kivágását a magas DPI-knél, a .NET-keretrendszer korábbi verzióit célzó, de a .NET-keretrendszer 4.6-on futó alkalmazások az alábbi sor hozzáadásával engedélyezhetik ezt az új viselkedést az app.config fájl szakaszához<runtime>:

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

Azok az alkalmazások, amelyek a .NET-keretrendszer 4.6-ot célozzák meg, de szeretnék, ha a WPF-vezérlők az előző elrendezési algoritmussal jelenjenek meg, ezt megtehetik, ha az alábbi sort hozzáadják az app.config fájl <runtime> szakaszában:

<AppContextSwitchOverrides value="Switch.MS.Internal.DoNotApplyLayoutRoundingToMarginsAndBorderThickness=true" />
Név Érték
Hatókör Csekély
Verzió 4,6
Típus Célközönség újra-megkeresése

XML, XSLT

XmlWriter kivételt dob érvénytelen helyettesítő párok esetén

Részletek

A .NET-keretrendszer 4.5.2-es vagy korábbi verziót megcélzott alkalmazások esetében a kivétel-tartalékkezelést használó érvénytelen helyettesítő párok írása nem mindig okoz kivételt. A .NET-keretrendszer 4.6-ot megcélzó alkalmazások esetében érvénytelen helyettesítő pár írására tett kísérlet egy System.ArgumentException.

Javaslat

Szükség esetén ez a törés elkerülhető a .NET-keretrendszer 4.5.2 vagy korábbi verziójának megcélzásával. Másik lehetőségként az érvénytelen helyettesítő párok írásuk előtt előre feldolgozhatók érvényes XML-fájlba.

Név Érték
Hatókör Edge
Verzió 4,6
Típus Újratargeting

Érintett API-k

Az XSD-séma érvényesítése mostantól helyesen észleli az egyedi korlátozások megsértését összetett kulcsok használata esetén, és egy kulcs üres

Részletek

A .NET-keretrendszer 4.6 előtti verzióiban hiba lépett fel, amely miatt az XSD-ellenőrzés nem észlelt egyedi korlátozásokat az összetett kulcsokon, ha az egyik kulcs üres volt. A 4.6-os .NET-keretrendszer ez a probléma ki van javítva. Ez helyesebb érvényesítést eredményez, de előfordulhat, hogy bizonyos XML nem érvényesíti azokat, amelyek korábban már előfordultak volna.

Javaslat

Ha lazább .NET-keretrendszer 4.0-s érvényesítésre van szükség, az érvényesítő alkalmazás a .NET-keretrendszer 4.5-ös (vagy korábbi) verzióját célozhatja meg. Amikor a .NET keretrendszer 4.6-os verziójára történik az újracélzás, azonban a kódellenőrzést el kell végezni annak biztosítására, hogy a probléma leírásában szereplő duplikált összetett kulcsokat nem kívánják érvényesíteni.

Név Érték
Hatókör Edge
Verzió 4,6
Típus Újracélzás

.NET-keretrendszer 4.6.1-es verziója

Alapvető

Útvonalelválasztó karakter módosítása a ZipArchiveEntry objektumok FullName tulajdonságában

Részletek

A .NET-keretrendszer 4.6.1-es és újabb verzióit célzó alkalmazásoknál az elérési út elválasztó karaktere visszaper ("\") helyett perjel ("/") lett a FullName tulajdonságában a ZipArchiveEntry objektumoknak, amelyeket a CreateFromDirectory metódus túlterheléseivel hoztak létre. A változás a .NET-implementációt a .ZIP fájlformátum specifikációjának 4.4.17.1 szakaszával összhangban hozza létre, és lehetővé teszi .ZIP archívumok tömörítését a nem Windows rendszerű rendszereken.
Az alkalmazás által létrehozott zip-fájl kibontása, amely a .NET-keretrendszer egy korábbi verzióját célozza nem Windows rendszerű operációs rendszereken, például a Macintosh rendszeren, nem tudja megőrizni a címtárstruktúrát. A Macintoshon például létrehoz egy fájlkészletet, amelynek fájlneve összefűzi a könyvtár elérési útját, valamint a fordított perjel ("\") karaktereket és a fájlnevet. Ennek eredményeképpen a tömörített fájlok könyvtárszerkezete nem marad meg.

Javaslat

Ennek a változásnak a windowsos operációs rendszeren az API-k által a .NET-keretrendszer System.IO névtérben tömörített .ZIP fájlokra gyakorolt hatása minimális, mivel ezek az API-k zökkenőmentesen kezelhetik a perjelet ("/") vagy a fordított perjelet ("\") elérési útelválasztó karakterként.
Ha ez a módosítás nem kívánatos, letilthatja azt úgy, hogy hozzáad egy konfigurációs beállítást az <runtime> alkalmazáskonfigurációs fájl szakaszához. Az alábbi példa mutatja mind a <runtime> szakaszt, mind az Switch.System.IO.Compression.ZipFile.UseBackslash opt-out kapcsolót:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.Compression.ZipFile.UseBackslash=true" />
</runtime>

Emellett azok az alkalmazások, amelyek a .NET-keretrendszer korábbi verzióit célják, de a .NET-keretrendszer 4.6.1-es és újabb verzióiban futnak, az alkalmazáskonfigurációs <runtime> fájl szakaszához hozzáadva engedélyezhetik ezt a viselkedést. Az alábbiakban a <runtime> szakasz és a Switch.System.IO.Compression.ZipFile.UseBackslash opt-in kapcsoló is látható.

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.Compression.ZipFile.UseBackslash=false" />
</runtime>
Név Érték
Hatókör Edge
Verzió 4.6.1
Típus Újratargeting

Érintett API-k

Windows Communication Foundation (WCF)

WCF-kötés a TransportWithMessageCredential biztonsági móddal

Részletek

A .NET-keretrendszer 4.6.1-től kezdődően a TransportWithMessageCredential biztonsági módot használó WCF-kötés beállítható úgy, hogy az aszimmetrikus biztonsági kulcsok alá nem írt "to" fejlécekkel rendelkező üzeneteket fogadjon. Alapértelmezés szerint a nem aláírt "to" fejlécek továbbra is el lesznek utasítva a .NET-keretrendszer 4.6.1-ben. Ezek csak akkor lesznek elfogadva, ha egy alkalmazás a Switch.System.ServiceModel.AllowUnsignedToHeader konfigurációs kapcsolóval engedélyezi ezt az új üzemmódot.

Javaslat

Mivel ez egy bejelentkezési funkció, nem befolyásolhatja a meglévő alkalmazások viselkedését.
Az új viselkedés használatának ellenőrzéséhez használja a következő konfigurációs beállítást:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.ServiceModel.AllowUnsignedToHeader=true" />
</runtime>
Név Érték
Hatókör Átlátható
Verzió 4.6.1
Típus Újratargeting

Érintett API-k

X509CertificateClaimSet.FindClaims Az összes jogcímtípust figyelembe veszi

Részletek

A .NET-keretrendszer 4.6.1-et megcélzott alkalmazásokban, ha egy X509-jogcímkészlet inicializálva van egy olyan tanúsítványból, amelynek a SAN-mezőjében több DNS-bejegyzés található, a System.IdentityModel.Claims.X509CertificateClaimSet.FindClaims(String, String) metódus megpróbálja egyezni a claimType argumentummal az összes DNS-bejegyzéssel. A .NET-keretrendszer korábbi verzióit célzó alkalmazások esetében a System.IdentityModel.Claims.X509CertificateClaimSet.FindClaims(String, String) metódus csak az utolsó DNS-bejegyzéssel próbál megegyezni a claimType argumentummal.

Javaslat

Ez a módosítás csak a .NET-keretrendszer 4.6.1-et célzó alkalmazásokat érinti. Ez a módosítás a DisableMultipleDNSEntries kompatibilitási kapcsolóval letiltható (vagy engedélyezhető, ha a 4.6.1 előtti célértéket célozza).

Név Érték
Hatókör Csekély
Verzió 4.6.1
Típus Újracélzás

Érintett API-k

Windows Forms

Az Application.FilterMessage többé nem dob kivételt az IMessageFilter.PreFilterMessage rekurzív megvalósításai esetén

Részletek

A .NET-keretrendszer 4.6.1 előtt a FilterMessage(Message) meghívása PreFilterMessage(Message)-vel, amely meg is hívta a System.Windows.Forms.Application.AddMessageFilter(IMessageFilter)-t vagy System.Windows.Forms.Application.RemoveMessageFilter(IMessageFilter)-t (miközben a DoEvents()-t is hívta), egy System.IndexOutOfRangeException-t okozott.

A .NET-keretrendszer 4.6.1-et célzó alkalmazásoktól kezdve ez a kivétel már nem jelentkezik, és a fent leírt újrabehozott szűrők használhatók.

Javaslat

Ne feledje, hogy FilterMessage(Message) a továbbiakban nem fog dobni a fent leírt újrakezdő PreFilterMessage(Message) viselkedésre. Ez csak a .NET-keretrendszer 4.6.1-et megcélzó alkalmazásokat érinti. Azok az alkalmazások, amelyek a .NET-keretrendszer 4.6.1-et célozzák meg, a DontSupportReentrantFilterMessage kompatibilitási kapcsolóval kikapcsolhatják ezt a módosítást (vagy a régebbi keretrendszereket célzó alkalmazások is aktiválhatják).

Név Érték
Hatókör Edge
Verzió 4.6.1
Típus Újracélzás

Érintett API-k

Windows Presentation Foundation (WPF)

A System.Windows.Input.PenContext.Disable hívásai érintésérzékeny rendszereken ArgumentException kivételt okozhatnak.

Részletek

Bizonyos körülmények között előfordulhat, hogy a belső System.Windows.Intput.PenContext.Disable metódus érintéssel kompatibilis rendszereken történő hívásai az újraküldés miatt nem kezelt T:System.ArgumentException állapotba kerülnek.

Javaslat

Ezt a problémát a .NET-keretrendszer 4.7-ben hárítottuk el. A kivétel elkerülése érdekében frissítsen a .NET-keretrendszer egy verziójára a .NET-keretrendszer 4.7-es verziójától kezdve.

Név Érték
Hatókör Edge
Verzió 4.6.1
Típus Újracélzás

.NET-keretrendszer 4.6.2

ASP.NET

HttpRuntime.AppDomainAppPath NullReferenceException kivételt dob

Részletek

A .NET-keretrendszer 4.6.2-ben a futtatókörnyezet egy T:System.NullReferenceException-t dob, amikor egy P:System.Web.HttpRuntime.AppDomainAppPath értéket olvas be, amely null karaktereket tartalmaz. A .NET-keretrendszer 4.6.1 és korábbi verzióiban a futtatókörnyezet egy T:System.ArgumentNullException-t dob.

Javaslat

A módosításra az alábbiak bármelyikével válaszolhat:

  • Kezelje a T:System.NullReferenceException elemet, ha az alkalmazása a .NET-keretrendszer 4.6.2-n fut.
  • Frissítsen a .NET Framework 4.7 verzióra, amely visszaállítja az előző viselkedést, és kivételt dob egy T:System.ArgumentNullException.
Név Érték
Hatókör Edge
Verzió 4.6.2
Típus Újracélzás

Érintett API-k

Alapvető

Az AesCryptoServiceProvider visszafejtése újrafelhasználható átalakítást biztosít

Részletek

A .NET-keretrendszer 4.6.2-t célzó alkalmazásoktól kezdve a AesCryptoServiceProvider visszafejtő újrahasználható átalakítást biztosít. A System.Security.Cryptography.CryptoAPITransform.TransformFinalBlock(Byte[], Int32, Int32) hívás után az átalakítás újrainicializálódik, és ismét felhasználható. A .NET-keretrendszer korábbi verzióit megcélzó alkalmazásoknál, ha System.Security.Cryptography.CryptoAPITransform.TransformFinalBlock(Byte[], Int32, Int32)-t követően meghívja System.Security.Cryptography.CryptoAPITransform.TransformBlock(Byte[], Int32, Int32, Byte[], Int32)-t azzal a céllal, hogy ismételten használja a visszafejtőt, CryptographicException hibát dob, vagy sérült adatokat hoz létre.

Javaslat

Ennek a változásnak minimálisnak kell lennie, mivel ez a várt viselkedés. Az előző viselkedéstől függő alkalmazások az alábbi konfigurációs beállítás <runtime> hozzáadásával letilthatják azt az alkalmazás konfigurációs fájljának szakaszához:

<runtime>
<AppContextSwitchOverrides value="Switch.System.Security.Cryptography.AesCryptoServiceProvider.DontCorrectlyResetDecryptor=true"/>
</runtime>

Ezenkívül azok az alkalmazások, amelyek a .NET Framework egy korábbi verzióját célozzák meg, de a .NET Framework 4.6.2 verziótól kezdve futnak, dönthetnek úgy, hogy engedélyezik, ha a következő konfigurációs beállítást hozzáadják az alkalmazás konfigurációs fájljának <runtime> szakaszához:

<runtime>
<AppContextSwitchOverrides value="Switch.System.Security.Cryptography.AesCryptoServiceProvider.DontCorrectlyResetDecryptor=false"/>
</runtime>
Név Érték
Hatókör Csekély
Verzió 4.6.2
Típus Újratargeting

Érintett API-k

A ClaimsIdentity konstruktoraihoz intézett hívások

Részletek

A .NET-keretrendszer 4.6.2 verziójától kezdve megváltozik, ahogy a ClaimsIdentity konstruktorok egy System.Security.Principal.IIdentity paraméterrel beállítják a System.Security.Claims.ClaimsIdentity.Actor tulajdonságot. Ha az System.Security.Principal.IIdentity argumentum egy ClaimsIdentity objektum, és az System.Security.Claims.ClaimsIdentity.Actor objektum tulajdonsága ClaimsIdentity nem null, a System.Security.Claims.ClaimsIdentity.Actor tulajdonság a metódussal Clone() lesz csatolva. A Framework 4.6.1 és korábbi verzióiban a System.Security.Claims.ClaimsIdentity.Actor tulajdonság meglévő hivatkozásként van csatolva. A változás miatt a 4.6.2 .NET-keretrendszer kezdve az System.Security.Claims.ClaimsIdentity.Actor új ClaimsIdentity objektum tulajdonsága nem egyenlő a System.Security.Claims.ClaimsIdentity.Actor konstruktor argumentumának tulajdonságávalSystem.Security.Principal.IIdentity. A .NET-keretrendszer 4.6.1-ben és a korábbi verziókban ez egyenlő.

Javaslat

Ha ez a viselkedés nem kívánatos, visszaállíthatja az előző viselkedést az alkalmazáskonfigurációs fájl Switch.System.Security.ClaimsIdentity.SetActorAsReferenceWhenCopyingClaimsIdentitykapcsolójának beállításávaltrue. Ehhez hozzá kell adnia a következőket a <runtime> web.config fájl szakaszához:

<configuration>
  <runtime>
    <AppContextSwitchOverrides value="Switch.System.Security.ClaimsIdentity.SetActorAsReferenceWhenCopyingClaimsIdentity=true" />
  </runtime>
</configuration>
Név Érték
Hatókör Edge
Verzió 4.6.2
Típus Újracélzás

Érintett API-k

Az elérési út normalizálásának változásai

Részletek

A .NET-keretrendszer 4.6.2-t célzó alkalmazásoktól kezdve a futtatókörnyezet normalizálásának módja megváltozott. Az elérési út normalizálásához módosítani kell az elérési utat vagy fájlt azonosító sztringet, hogy az megfeleljen a cél operációs rendszer érvényes elérési útjának. A normalizálás általában a következőket foglalja magában:

  • Az összetevők és könyvtárelválasztók kanonizálása.
  • Az aktuális könyvtár alkalmazása egy relatív elérési útra.
  • A relatív könyvtár (.) vagy a szülőkönyvtár (..) kiértékelése egy elérési úton.
  • Megadott karakterek levágása. A 4.6.2-.NET-keretrendszer megcélzott alkalmazásoktól kezdve alapértelmezés szerint a következő változások engedélyezve vannak az elérési út normalizálásában:
  • A normalizálás mostantól nem foglalja magában a könyvtárszegmensek végének levágását (például szóköz a könyvtárnév végén).
  • Az eszközútvonal szintaxisának támogatása teljes megbízhatóságban, beleértve \\.\ a mscorlib.dll fájl I/O API-jait is. \\?\
  • A futtatókörnyezet nem ellenőrzi az eszközszyntax elérési útvonalait.
  • Támogatott az eszközszintaxis használata a másodlagos adatfolyamokhoz való hozzáféréshez. Ezek a módosítások javítják a teljesítményt, miközben lehetővé teszik a metódusok számára a korábban elérhetetlen útvonalak elérését. A módosítás nem érinti azokat az alkalmazásokat, amelyek a .NET-keretrendszer 4.6.1 vagy korábbi verzióját célozzák meg, de a .NET-keretrendszer 4.6.2 vagy újabb verziójában futnak.

Javaslat

A .NET-keretrendszer 4.6.2-es vagy újabb verzióját megcélzott alkalmazások kikapcsolhatják ezt a módosítást, és régi normalizálást használhatnak az alkalmazáskonfigurációs <runtime> fájl következő szakaszához való hozzáadásával:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.UseLegacyPathHandling=true" />
</runtime>

Azok az alkalmazások, amelyek a .NET-keretrendszer 4.6.1-es vagy korábbi verzióját célozzák, de a .NET-keretrendszer 4.6.2-es vagy újabb verzióján futnak, engedélyezhetik az útvonal normalizálásának változásait úgy, hogy hozzáadják az alábbi sort az alkalmazás .configuration fájljának a <runtime> szakaszához:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.UseLegacyPathHandling=false" />
</runtime>
Név Érték
Hatókör Csekély
Verzió 4.6.2
Típus Újratargeting

CurrentCulture és CurrentUICulture áramlása a feladatok között

Részletek

A .NET-keretrendszer 4.6-tól kezdve a System.Globalization.CultureInfo.CurrentCulture és System.Globalization.CultureInfo.CurrentUICulture tárolása a szál System.Threading.ExecutionContext-jában történik, amely folyamatosan továbbítódik az aszinkron műveleteken keresztül. Ez azt jelenti, hogy a System.Globalization.CultureInfo.CurrentCulture vagy System.Globalization.CultureInfo.CurrentUICulture módosításai megjelennek a később aszinkron módon futó feladatokban. Ez eltér a korábbi .NET-keretrendszer verziók viselkedésétől (ami alaphelyzetbe állítaná System.Globalization.CultureInfo.CurrentCulture, és System.Globalization.CultureInfo.CurrentUICulture minden aszinkron feladatban).

Javaslat

A módosítás által érintett alkalmazások a kívánt System.Globalization.CultureInfo.CurrentCulture vagy System.Globalization.CultureInfo.CurrentUICulture az aszinkron tevékenység első műveletének explicit beállításával megkerülhetik a módosítást. Másik lehetőségként a régi viselkedés (nem áramló System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture) a következő kompatibilitási kapcsoló beállításával választható:

AppContext.SetSwitch("Switch.System.Globalization.NoAsyncCurrentCulture", true);

Ezt a problémát a WPF a .NET-keretrendszer 4.6.2-es verziójában javította. A 4.6-os, 4.6.1-s és KB-3139549 .NET-keretrendszer is kijavítottuk. A .NET-keretrendszer 4.6-os vagy újabb verzióját megcélzó alkalmazások automatikusan a helyes működést biztosítják a WPF-alkalmazásokban – a System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture kijelölések megmaradnak a Dispatcher műveletek során.

Név Érték
Hatókör Csekély
Verzió 4,6
Típus Újracélzás

Érintett API-k

Az ETW-eseménynevek nem térhetnek el csak a "Start" vagy a "Stop" utótagtól

Részletek

A .NET-keretrendszer 4.6-os és 4.6.1-es verziójában a futtatókörnyezet kivételt dob ArgumentException, amikor a Windows eseménykövetésének (ETW) két eseményneve csak a "Start" vagy "Stop" utótagban tér el (például, amikor az egyik esemény neve LogUser, a másiké pedig LogUserStart). Ebben az esetben a futtatókörnyezet nem tudja létrehozni az eseményforrást, amely nem tud naplózást kibocsátni.

Javaslat

A kivétel elkerülése érdekében győződjön meg arról, hogy egyetlen két eseménynév sem tér el csak a "Start" vagy a "Stop" utótagtól. Ez a követelmény a 4.6.2-.NET-keretrendszer kezdve megszűnik; a futtatókörnyezet csak a "Start" és a "Stop" utótaggal eltérő eseményneveket jelezheti.

Név Érték
Hatókör Edge
Verzió 4,6
Típus Újracélzás

Hosszú út támogatása

Részletek

A 4.6.2-.NET-keretrendszer megcélzott alkalmazásoktól kezdve a hosszú (legfeljebb 32 000 karakter hosszúságú) elérési utak támogatottak, és a 260 karakteres (vagy MAX_PATH) elérési utak hosszára vonatkozó korlátozás el lett távolítva. A .NET-keretrendszer 4.6.2-re újrafordított alkalmazások esetében a korábban a 260 karakternél hosszabb elérési út miatt korábban elvetett System.IO.PathTooLongException kódútvonalak mostantól csak a következő feltételek mellett jelennek megSystem.IO.PathTooLongException:

  • Az elérési út hossza nagyobb, mint MaxValue (32 767) karakter.
  • Az operációs rendszer COR_E_PATHTOOLONG vagy annak megfelelőjét adja vissza. A .NET-keretrendszer 4.6.1-et és korábbi verziót megcélzott alkalmazások esetében a futtatókörnyezet automatikusan eldob egy System.IO.PathTooLongException 260 karakternél hosszabb elérési utat.

Javaslat

A 4.6.2-es .NET-keretrendszer megcélzott alkalmazások esetében kikapcsolhatja a hosszú elérési út támogatását, ha ez nem kívánatos, ha hozzáadja az alábbiakat a <runtime> fájl szakaszáhozapp.config:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.BlockLongPaths=true" />
</runtime>

A .NET-keretrendszer korábbi verzióira tervezett, de a .NET-keretrendszer 4.6.2-es vagy újabb verzióján futó alkalmazások esetében a hosszú elérési utak támogatását az alábbiak <runtime> szakaszának hozzáadásával engedélyezheti az app.config fájlban:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.BlockLongPaths=false" />
</runtime>
Név Érték
Hatókör Kisebb
Verzió 4.6.2
Típus Újracélzás

A kettőspont-ellenőrzés az elérési útvonalakon szigorúbb.

Részletek

A .NET-keretrendszer 4.6.2-ben számos módosítás történt a korábban nem támogatott útvonalak támogatásához (hosszban és formátumban is). A meghajtóelválasztó (kettőspont) szintaxis ellenőrzése helyesebben történt, ami azzal a mellékhatással járt, hogy néhány URI-útvonal blokkolódott bizonyos Path API-kban, ahol azokat korábban még elfogadták.

Javaslat

Ha egy URI-t ad át az érintett API-knak, először módosítsa a karakterláncot, hogy az érvényes elérési út legyen.

  • Távolítsa el manuálisan a sémát az URL-címekről (például távolítsa el file:// az URL-címekről).

  • Adja át az URI-t a Uri osztálynak, és használja LocalPath.

Másik lehetőségként az AppContext kapcsoló Switch.System.IO.UseLegacyPathHandlingbeállításával true kikapcsolhatja az új elérési út normalizálását.

Név Érték
Hatókör Edge
Verzió 4.6.2
Típus Újracélzás

Érintett API-k

Biztonság

Az RSACng most már megfelelően betölti a nem standard méretű RSA-kulcsokat

Részletek

A 4.6.2 előtti .NET-keretrendszer verziókban az RSA-tanúsítványokhoz nem szabványos kulcsmérettel rendelkező ügyfelek nem férhetnek hozzá ezekhez a kulcsokhoz a System.Security.Cryptography.X509Certificates.RSACertificateExtensions.GetRSAPublicKey(X509Certificate2)System.Security.Cryptography.X509Certificates.RSACertificateExtensions.GetRSAPrivateKey(X509Certificate2) bővítménymetelyeken keresztül. Ekkor System.Security.Cryptography.CryptographicException dobódik a "A kért kulcsméret nem támogatott" üzenet. A .NET-keretrendszer 4.6.2-ben ez a probléma ki lett javítva. Hasonlóképpen, ImportParameters(RSAParameters) és ImportParameters(RSAParameters) most már nem szabványos kulcsméretekkel is dolgozik anélkül, hogy egy System.Security.Cryptography.CryptographicException-t dobna.

Javaslat

Ha van olyan kivételkezelési logika, amely az előző viselkedésre támaszkodik, és akkor dobódik ki egy System.Security.Cryptography.CryptographicException kivétel, amikor nem szokványos kulcsméreteket használnak, fontolja meg a logika eltávolítását.

Név Érték
Hatókör Edge
Verzió 4.6.2
Típus Újracélzás

Érintett API-k

A SignedXml.GetPublicKey az RSACng értéket ad vissza net462-en (vagy lightup), anélkül, hogy megváltoztatná a célzást.

Részletek

A .NET-keretrendszer 4.6.2-es verziójától kezdve a metódus által SignedXml.GetPublicKey visszaadott objektum konkrét típusa a CryptoServiceProvider implementációról Cng-implementációra változott (nem volt változás). Ennek az az oka, hogy az implementáció a certificate.PublicKey.Key használatáról átváltott a belső certificate.GetAnyPublicKey-re, amely a RSACertificateExtensions.GetRSAPublicKey-re továbbítja.

Javaslat

A .NET-keretrendszer 4.7.1-es verzióján futó alkalmazásoktól kezdve használhatja az alapértelmezés szerint használt CryptoServiceProvider-implementációt a .NET-keretrendszer 4.6.1-es és korábbi verzióiban, ha hozzáadja a következő konfigurációs kapcsolót az alkalmazás konfigurációs fájljának futtatókörnyezeti szakaszához:

<AppContextSwitchOverrides value="Switch.System.Security.Cryptography.Xml.SignedXmlUseLegacyCertificatePrivateKey=true" />
Név Érték
Hatókör Edge
Verzió 4.6.2
Típus Újracélzás

Érintett API-k

Windows Communication Foundation (WCF)

Holtpontot okozhat a Reentrant-szolgáltatások használata

Részletek

A holtpont reentrant szolgáltatást eredményezhet, amely a szolgáltatás példányait egyszerre egy végrehajtási szálra korlátozza. A problémára hajlamos szolgáltatások kódjában a következők ServiceBehaviorAttribute jelennek meg:

[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Reentrant)]

Javaslat

A probléma megoldásához tegye a következőket:

[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Reentrant)]
  • Telepítse a legújabb frissítést a .NET-keretrendszer 4.6.2-es verziójára, vagy frissítsen a .NET-keretrendszer egy későbbi verziójára. Ez letiltja a ExecutionContext folyamát OperationContext.Current-ban. Ez a viselkedés konfigurálható; ez egyenértékű azzal, hogy hozzáadja a következő alkalmazásbeállítást a konfigurációs fájlhoz:
<appSettings>
  <add key="Switch.System.ServiceModel.DisableOperationContextAsyncFlow" value="true" />
</appSettings>

Reentrant szolgáltatások esetében az Switch.System.ServiceModel.DisableOperationContextAsyncFlow értékét soha nem szabad false beállítani.

Név Érték
Hatókör Csekély
Verzió 4.6.2
Típus Újracélzás

Érintett API-k

Az OperationContext.Current null értéket adhat vissza, ha egy használati záradékban meghívják

Részletek

OperationContext.Current visszatérhet null , és NullReferenceException is bekövetkezhet, ha az alábbi feltételek mindegyike teljesül:

using (new OperationContextScope(OperationContext.Current))
{
    // OperationContext.Current is null.
    OperationContext context = OperationContext.Current;

    // ...
}

Javaslat

A probléma megoldásához tegye a következőket:

  • Módosítsa a kódot az alábbiak szerint egy új null-típusú objektum Current nélküli példányosításához:

    OperationContext ocx = OperationContext.Current;
using (new OperationContextScope(OperationContext.Current))
{
    OperationContext.Current = new OperationContext(ocx.Channel);

    // ...
}

  • Telepítse a legújabb frissítést a .NET-keretrendszer 4.6.2-es verziójára, vagy frissítsen a .NET-keretrendszer egy későbbi verziójára. Ez letiltja a ExecutionContext adatfolyamát OperationContext.Current-ben, és visszaállítja a WCF-alkalmazások viselkedését a .NET 4.6.1-es verziójában és a korábbi verziókban. Ez a viselkedés konfigurálható; ez egyenértékű azzal, hogy hozzáadja a következő alkalmazásbeállítást a konfigurációs fájlhoz:

    <appSettings>
  <add key="Switch.System.ServiceModel.DisableOperationContextAsyncFlow" value="true" />
</appSettings>

    Ha ez a módosítás nem kívánatos, és az alkalmazás a műveleti környezetek között folyó végrehajtási környezettől függ, az alábbiak szerint engedélyezheti a folyamatot:

    <appSettings>
  <add key="Switch.System.ServiceModel.DisableOperationContextAsyncFlow" value="false" />
</appSettings>
Név Érték
Hatókör Edge
Verzió 4.6.2
Típus Újracélzás

Érintett API-k

A WCF átviteli biztonsága támogatja a CNG használatával tárolt tanúsítványokat

Részletek

A 4.6.2-.NET-keretrendszer megcélzott alkalmazásoktól kezdve a WCF átviteli biztonsága támogatja a Windows titkosítási könyvtár (CNG) használatával tárolt tanúsítványokat. Ez a támogatás olyan nyilvános kulccsal rendelkező tanúsítványokra korlátozódik, amelyek kitevője legfeljebb 32 bit hosszúságú. Ha egy alkalmazás a .NET-keretrendszer 4.6.2-t célozza, ez a funkció alapértelmezés szerint be van kapcsolva. A .NET-keretrendszer korábbi verzióiban az X509-tanúsítványok CSG-kulcstároló-szolgáltatóval való használatára tett kísérlet kivételt eredményez.

Javaslat

Azok az alkalmazások, amelyek a .NET-keretrendszer 4.6.1-es vagy korábbi verziót célják, de a .NET-keretrendszer 4.6.2-es verzióján futnak, engedélyezhetik a CNG-tanúsítványok támogatását az app.config vagy web.config fájl szakaszához a következő sor <runtime> hozzáadásával:

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

Ez programozott módon is elvégezhető a következő kóddal:

private const string DisableCngCertificates = @"Switch.System.IdentityModel.DisableCngCertificate";

AppContext.SetSwitch(disableCngCertificates, false);

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

Vegye figyelembe, hogy a módosítás miatt a CNG-tanúsítvánnyal való biztonságos kommunikáció sikertelenségére tett kísérlettől függő kivételkezelési kód a továbbiakban nem lesz végrehajtva.

Név Érték
Hatókör Csekély
Verzió 4.6.2
Típus Újracélzás

Windows Forms

A MemberDescriptor.Equals helytelen implementálása

Részletek

A metódus eredeti implementációja MemberDescriptor.Equals két különböző karakterlánc-tulajdonságot hasonlít össze az összehasonlítandó objektumoktól: a kategória nevét és a leírási sztringet. A javítás célja, hogy összehasonlítsa az Category első objektumot a Category második objektummal, az Description elsőt pedig a Description másodikval.

Javaslat

Ha az alkalmazás attól függ, hogy MemberDescriptor.Equals esetenként false-t ad vissza, amikor a leírók egyenértékűek, és a .NET-keretrendszer 4.6.2-es vagy újabb verzióját célozza meg, több lehetősége is van:

  • A MemberDescriptor.Equals metódus meghívása mellett módosítsa a kódot, hogy a Category és Description mezőket manuálisan is összehasonlítsa.
  • A módosítás letiltásához adja hozzá a következő értéket az app.config fájlhoz:
<runtime>
  <AppContextSwitchOverrides value="Switch.System.MemberDescriptorEqualsReturnsFalseIfEquivalent=true" />
</runtime>

Ha az alkalmazás a 4.6.1-.NET-keretrendszer vagy korábbi verziót célozza, és a .NET-keretrendszer 4.6.2 vagy újabb verzión fut, és engedélyezni szeretné ezt a módosítást, beállíthatja a kompatibilitási kapcsolót false úgy, hogy hozzáadja a következő értéket az app.config fájlhoz:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.MemberDescriptorEqualsReturnsFalseIfEquivalent=false" />
</runtime>
Név Érték
Hatókör Edge
Verzió 4.6.2
Típus Célzott újracélzás

Érintett API-k

Windows Presentation Foundation (WPF)

A CurrentCulture nem marad meg a WPF-ütemező műveletek között

Részletek

A .NET-keretrendszer 4.6-os verziójától kezdve a System.Globalization.CultureInfo.CurrentCulture vagy a System.Globalization.CultureInfo.CurrentUICulture módosításai, amelyeket a System.Windows.Threading.Dispatcher belül hajtanak végre, elvesznek a diszpécser művelet végén. Hasonlóképpen előfordulhat, hogy a System.Globalization.CultureInfo.CurrentCulture diszpécserművelet vagy a System.Globalization.CultureInfo.CurrentUICulture kívül végzett módosítások nem jelennek meg a művelet végrehajtásakor. Gyakorlatilag ez azt jelenti, hogy a System.Globalization.CultureInfo.CurrentCulture és System.Globalization.CultureInfo.CurrentUICulture közötti változások nem biztos, hogy áramlanak a WPF felhasználói felületi visszahívások és egyéb WPF-alkalmazási kódok között. Ennek oka, hogy a System.Threading.ExecutionContext-ben bekövetkezett változás miatt System.Globalization.CultureInfo.CurrentCulture és System.Globalization.CultureInfo.CurrentUICulture a végrehajtási környezetben kerül tárolásra a .NET-keretrendszer 4.6-os verzióját célzó alkalmazásokban. A WPF-diszpécserműveletek a művelet megkezdéséhez használt végrehajtási környezetet tárolják, és a művelet befejezésekor visszaállítják az előző környezetet. System.Globalization.CultureInfo.CurrentCulture és System.Globalization.CultureInfo.CurrentUICulture most már a környezet részét képezik, így a diszpécserműveleten belüli módosítások nem maradnak meg a műveleten kívül.

Javaslat

A változás által érintett alkalmazások megkerülhetik ezt azzal, hogy a kívánt System.Globalization.CultureInfo.CurrentCulture vagy System.Globalization.CultureInfo.CurrentUICulture egy mezőbe tárolják, és minden Dispatcher-műveleti törzsben (beleértve a felhasználói felület esemény-visszahívási kezelőit is) ellenőrzik, hogy a megfelelő System.Globalization.CultureInfo.CurrentCulture és System.Globalization.CultureInfo.CurrentUICulture be vannak állítva. Alternatív megoldásként, mivel a WPF-változás alapjául szolgáló ExecutionContext-módosítás csak a .NET-keretrendszer 4.6-os vagy újabb verziót célzó alkalmazásokat érinti, ez a törés elkerülhető a .NET-keretrendszer 4.5.2.-.NET-keretrendszer 4.6-os vagy újabb verziót célzó alkalmazások esetében is, ha a következő kompatibilitási kapcsolót állítja be:

AppContext.SetSwitch("Switch.System.Globalization.NoAsyncCurrentCulture", true);

A problémát a .NET-keretrendszer 4.6.2 verziója a WPF segítségével javította. A javítást a 4.6-os és 4.6.1-es .NET-keretrendszer verziók esetében a KB 3139549 frissítéssel is végrehajtották. A 4.6-os vagy újabb .NET-keretrendszer megcélzott alkalmazások automatikusan a megfelelő viselkedést kapják a WPF-alkalmazásokban – System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulturea ) a Dispatcher-műveletek között megmaradnak.

Név Érték
Hatókör Csekély
Verzió 4,6
Típus Retargetálás
  • Last updated on