Změna cílení migrace na rozhraní .NET Framework 4.6.x

Tento článek obsahuje seznam problémů s kompatibilitou aplikací, které byly zavedeny v rozhraní .NET Framework 4.6, 4.6.1 a 4.6.2.

.NET Framework 4.6

ASP.NET

HtmlTextWriter nevykresluje <br/> element správně

Detaily

Počínaje rozhraním .NET Framework 4.6 se voláním RenderBeginTag(String) a RenderEndTag() prvkem <BR /> správně vloží pouze jeden <BR /> (místo dvou).

Návrh

Pokud aplikace závisí na další <BR /> značce, RenderBeginTag(String) by se měla volat ještě jednou. Všimněte si, že tato změna chování má vliv pouze na aplikace, které cílí na rozhraní .NET Framework 4.6 nebo novější, takže další možností je cílit na předchozí verzi rozhraní .NET Framework, aby bylo možné získat staré chování.

Jméno Hodnota
Scope Edge
Verze 4.6
Typ Změna cílení

Ovlivněná rozhraní API

ClickOnce

Aplikace publikované pomocí ClickOnce, které používají certifikát SHA-256 pro podepisování kódu, nemusí na systému Windows 2003 fungovat správně.

Detaily

Spustitelný soubor je podepsaný pomocí SHA256. Dříve byla podepsána pomocí SHA1 bez ohledu na to, jestli podpisový certifikát kódu byl SHA-1 nebo SHA-256. Toto se vztahuje na:

  • Všechny aplikace vytvořené pomocí sady Visual Studio 2012 nebo novější
  • Aplikace vytvořené ve Visual Studio 2010 nebo starší na systémech, kde je přítomné rozhraní .NET Framework 4.5. Kromě toho, pokud je k dispozici rozhraní .NET Framework 4.5 nebo novější, je manifest ClickOnce podepsán také pomocí SHA-256 pro certifikáty SHA-256 bez ohledu na verzi rozhraní .NET Framework, pro kterou byl kompilován.

Návrh

Změna v podepisování spustitelného souboru ClickOnce má vliv pouze na systémy Windows Server 2003, které vyžadují instalaci aktualizace KB 938397. Změna při podepisování manifestu pomocí SHA-256, i když aplikace cílí na rozhraní .NET Framework 4.0 nebo starší verze, představuje závislost modulu runtime na rozhraní .NET Framework 4.5 nebo novější verzi.

Jméno Hodnota
Scope Edge
Verze 4.5
Typ Změna cílení

ClickOnce podporuje SHA-256 v 4.0 cílových aplikacích.

Detaily

Dříve by aplikace ClickOnce s certifikátem podepsaným pomocí SHA-256 vyžadovala, aby byla k dispozici rozhraní .NET Framework 4.5 nebo novější, i když aplikace cílí na verzi 4.0. Aplikace ClickOnce cílené na rozhraní .NET Framework 4.0 teď můžou běžet v rozhraní .NET Framework 4.0, i když jsou podepsané pomocí SHA-256.

Návrh

Tato změna odebere tuto závislost a umožní použití certifikátů SHA-256 k podepisování aplikací ClickOnce, které cílí na rozhraní .NET Framework 4 a starší verze.

Jméno Hodnota
Scope Drobné
Verze 4.6
Typ Změna cílení

Základ

Tok CurrentCulture a CurrentUICulture napříč úlohami

Detaily

Počínaje rozhraním .NET Framework 4.6 System.Globalization.CultureInfo.CurrentCulture a System.Globalization.CultureInfo.CurrentUICulture jsou uloženy ve vlákně System.Threading.ExecutionContext, které proudí napříč asynchronními operacemi. To znamená, že změny System.Globalization.CultureInfo.CurrentCulture nebo System.Globalization.CultureInfo.CurrentUICulture se projeví v úlohách, které se později spustí asynchronně. Toto chování se liší od chování předchozích verzí rozhraní .NET Framework (které by resetovaly System.Globalization.CultureInfo.CurrentCulture a System.Globalization.CultureInfo.CurrentUICulture ve všech asynchronních úlohách).

Návrh

Aplikace ovlivněné touto změnou můžou tuto změnu obejít tak, že explicitně nastaví požadovanou System.Globalization.CultureInfo.CurrentCulture nebo System.Globalization.CultureInfo.CurrentUICulture jako první operaci v asynchronní úloze. Můžete také zvolit staré chování (netečování System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture) nastavením následujícího přepínače kompatibility:

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

Tento problém vyřešil WPF v rozhraní .NET Framework 4.6.2. Byl také opraven v rozhraní .NET Frameworks 4.6, 4.6.1 až KB 3139549. Aplikace, které cílí na rozhraní .NET Framework 4.6 nebo novější, automaticky získají správné chování v aplikacích WPF – System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture) se zachovají napříč operacemi Dispatcheru.

Jméno Hodnota
Scope Drobné
Verze 4.6
Typ Změna cílení

Ovlivněná rozhraní API

Názvy událostí ETW se nesmí lišit pouze příponou „Start“ nebo „Stop“.

Detaily

Modul runtime v rozhraní .NET Framework 4.6 a 4.6.1 vyvolá ArgumentException , když se dva názvy událostí trasování událostí pro Windows (ETW) liší pouze příponou Start nebo Stop (jako když je jedna událost pojmenována LogUser a druhá je pojmenovaná LogUserStart). V tomto případě modul runtime nemůže sestavit zdroj událostí, který nemůže generovat žádné protokolování.

Návrh

Chcete-li zabránit výjimce, ujistěte se, že se žádné dva názvy událostí liší pouze příponou Start nebo Stop. Tento požadavek se odebere počínaje rozhraním .NET Framework 4.6.2; modul runtime může nejednoznačit názvy událostí, které se liší pouze příponou Start a Stop.

Jméno Hodnota
Scope Edge
Verze 4.6
Typ Změna cílení

Entity Framework

Sestavení souboru Entity Framework EDMX v sadě Visual Studio 2013 může při použití úloh EntityDeploySplit nebo EntityClean selhat s chybou MSB4062

Detaily

U nástrojů MSBuild 12.0 (zahrnutých v sadě Visual Studio 2013) se změnilo umístění souborů MSBuild, což vede k tomu, že starší soubory cílů Entity Framework jsou neplatné. Úlohy EntityDeploySplit a EntityClean v důsledku toho selhávají, protože nenajdou Microsoft.Data.Entity.Build.Tasks.dll. Poznámka: Toto přerušení je z důvodu změny v sadě nástrojů (MSBuild/VS), nikoliv z důvodu změny v .NET Framework. Projeví se jen při upgradu nástrojů pro vývojáře, ne při samotném upgradu rozhraní .NET Framework.

Návrh

Soubory cílů Entity Framework jsou ve verzi .NET Framework 4.6 opraveny tak, aby fungovaly s novým rozložením nástrojů MSBuild. Upgradem na tuto verzi rozhraní Framework se problém vyřeší. Případně můžete opravit soubory cílů přímo pomocí tohoto alternativního řešení.

Jméno Hodnota
Scope Hlavní
Verze 4.5.1
Typ Změna cílení

JIT

IL ret není povolen v oblasti try

Detaily

Na rozdíl od kompilátoru JIT64 za běhu nepovoluje nástroj RyuJIT (použitý v rozhraní .NET Framework 4.6) pokyn k retu v il v oblasti try. Vrácení z oblasti try je zakázáno specifikací ECMA-335 a žádný známý spravovaný kompilátor nevygeneruje takový IL. Kompilátor JIT64 však provede takový IL kód, pokud je vygenerován pomocí emitování reflexe.

Návrh

Pokud aplikace generuje IL, která obsahuje ret opcode v oblasti try, může aplikace cílit na rozhraní .NET Framework 4.5, aby používala starou JIT a vyhnula se tomuto přerušení. Případně může být vygenerovaná IL aktualizována tak, aby se vrátila po oblasti try.

Jméno Hodnota
Scope Edge
Verze 4.6
Typ Změna cílení

Nový 64bitový kompilátor JIT v rozhraní .NET Framework 4.6

Detaily

Počínaje rozhraním .NET Framework 4.6 se pro kompilaci za běhu používá nový 64bitový kompilátor JIT. V některých případech se vyvolá neočekávaná výjimka nebo se zjistí jiné chování, než když se aplikace spustí pomocí 32bitového kompilátoru nebo staršího 64bitového kompilátoru JIT. Tato změna nemá vliv na 32bitový kompilátor JIT. Mezi známé rozdíly patří:

  • Za určitých podmínek může operace rozbalení vyvolat v buildech vydané verze se zapnutou NullReferenceException optimalizací.
  • V některých případech může spuštění produkčního kódu v objemném těle metody vyvolat StackOverflowException.
  • Za určitých podmínek se struktury předané metodě považují za odkazové typy, nikoli jako typy hodnot v buildech Release. Jedním z projevů tohoto problému je, že jednotlivé položky v kolekci se zobrazují v neočekávaném pořadí.
  • Za určitých podmínek je porovnání UInt16 hodnot s vysokou bitovou sadou nesprávné, pokud je povolená optimalizace.
  • Za určitých podmínek, zejména při inicializaci hodnot pole, příkaz OpCodes.Initblk IL může inicializovat paměť s nesprávnou hodnotou. Výsledkem může být neošetřená výjimka nebo nesprávný výstup.
  • Za určitých výjimečných podmínek může podmíněný bitový test vrátit nesprávnou Boolean hodnotu nebo vyvolat výjimku, pokud jsou povoleny optimalizace kompilátoru.
  • Za určitých podmínek platí, že pokud if příkaz se použije k otestování podmínky předtím, než se zadeje do try bloku a opouští try blok, a stejná podmínka se vyhodnocuje v catch nebo finally bloku, nový 64bitový JIT kompilátor odebere podmínku if z catch nebo finally bloku při optimalizaci kódu. V důsledku toho se kód uvnitř if příkazu v catch nebo finally bloku provede bezpodmínečně.

Návrh

Zmírnění známých problémů
Pokud narazíte na výše uvedené problémy, můžete je vyřešit některým z následujících způsobů:

  • Upgradujte na rozhraní .NET Framework 4.6.2. Nový 64bitový kompilátor, který je součástí rozhraní .NET Framework 4.6.2, řeší každý z těchto známých problémů.

  • Spuštěním služba Windows Update se ujistěte, že je vaše verze Windows aktuální. Aktualizace služeb pro rozhraní .NET Framework 4.6 a 4.6.1 řeší všechny tyto problémy s výjimkou NullReferenceException operace rozbalování.

  • Zkompilujte pomocí staršího 64bitového kompilátoru JIT. Další informace o tom, jak to udělat, najdete v části Zmírnění dalších problémů . Zmírnění jiných problémů
    Pokud narazíte na jakýkoli jiný rozdíl v chování mezi kódem zkompilovaným pomocí staršího 64bitového kompilátoru a nového 64bitového kompilátoru JIT nebo mezi verzemi ladění a verze aplikace, které jsou kompilovány s novým 64bitovým kompilátorem JIT, můžete aplikaci zkompilovat pomocí staršího 64bitového kompilátoru JIT:

  • Na základě jednotlivých aplikací můžete přidat < prvek do konfiguračního souboru vaší aplikace. Následující příkaz zakáže kompilaci s novým 64bitovým kompilátorem JIT a místo toho používá starší 64bitový kompilátor JIT.

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

  • Pro jednotlivé uživatele můžete přidat hodnotu pojmenovanou REG_DWORDuseLegacyJit k HKEY_CURRENT_USER\SOFTWARE\Microsoft\.NETFramework klíči registru. Hodnota 1 umožňuje starší 64bitový kompilátor JIT; hodnota 0 ji zakáže a povolí nový 64bitový kompilátor JIT.

  • Na jednotlivých počítačích můžete přidat hodnotu REG_DWORD pojmenovanou useLegacyJit ke klíči registru HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework. Hodnota 1 povolí starší 64bitový kompilátor JIT. Hodnota 0 ho zakáže a povolí nový 64bitový kompilátor JIT. O problému nám také můžete dát vědět tím, že nahlásíte chybu v Microsoft Connectu.

Jméno Hodnota
Scope Edge
Verze 4.6
Typ Změna cílení

Sítě

Ověření OID pro EKU certifikáty

Detaily

Počínaje rozhraním .NET Framework 4.6 třídy SslStream nebo ServicePointManager provádějí ověřování identifikátoru objektu (OID) pro rozšířené použití klíče (EKU). Rozšíření funkce rozšířeného použití klíče (EKU) je kolekce identifikátorů objektů (OID), které označují aplikace, které používají klíč. Ověřování EKU OID používá zpětné volání vzdáleného certifikátu k zajištění toho, aby vzdálený certifikát měl správné identifikátory OID pro zamýšlený účel.

Návrh

Pokud je tato změna nežádoucí, můžete zakázat ověření identifikátoru EKU certifikátu přidáním následujícího přepínače do <AppContextSwitchOverrides> v konfiguračním ` souboru aplikace:

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

Důležité

Toto nastavení je k dispozici pouze pro zpětnou kompatibilitu. Jeho použití se jinak nedoporučuje.

Jméno Hodnota
Scope Drobné
Verze 4.6
Typ Změna cílení

Ovlivněná rozhraní API

Protokoly Tls 1.0, 1.1 a 1.2 jsou podporovány v System.Net.ServicePointManager a System.Net.Security.SslStream

Detaily

Počínaje rozhraním .NET Framework 4.6 ServicePointManager mohou třídy SslStream používat pouze jeden z následujících tří protokolů: Tls1.0, Tls1.1 nebo Tls1.2. Protokol SSL3.0 a šifry RC4 se nepodporují.

Návrh

Doporučeným zmírněním rizik je upgrade aplikace na straně serveru na Tls1.0, Tls1.1 nebo Tls1.2. Pokud to není možné nebo pokud jsou klientské aplikace přerušené, System.AppContext můžete třídu použít k odhlášení z této funkce jedním ze dvou způsobů:

<AppContextSwitchOverrides value="Switch.System.Net.DontEnableSchUseStrongCrypto=true"/>
Jméno Hodnota
Scope Drobné
Verze 4.6
Typ Změna cílení

Ovlivněná rozhraní API

Protokol TLS 1.x ve výchozím nastavení předává příznak SCH_SEND_AUX_RECORD do základního rozhraní API SCHANNEL.

Detaily

Při použití protokolu TLS 1.x se rozhraní .NET Framework spoléhá na základní rozhraní WINDOWS SCHANNEL API. Počínaje rozhraním .NET Framework 4.6 je příznak SCH_SEND_AUX_RECORD ve výchozím nastavení předáván SCHANNEL. To způsobí, že SCHANNEL rozdělí data k zašifrování do dvou samostatných záznamů, přičemž první záznam má jeden bajt a druhý má n-1 bajtů. Ve výjimečných případech se tím přeruší komunikace mezi klienty a existujícími servery, které předpokládají, že se data nacházejí v jednom záznamu.

Návrh

Pokud tato změna přeruší komunikaci s existujícím serverem, můžete zakázat odesílání příznaku SCH_SEND_AUX_RECORD a obnovit předchozí chování, kdy nedochází k rozdělování dat do samostatných záznamů, přidáním následujícího přepínače do elementu <AppContextSwitchOverrides> v části <runtime> konfiguračního souboru vaší aplikace:

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

Důležité

Toto nastavení je k dispozici pouze pro zpětnou kompatibilitu. Jeho použití se jinak nedoporučuje.

Jméno Hodnota
Scope Edge
Verze 4.6
Typ Změna cílení

Ovlivněná rozhraní API

WCF (Windows Communication Foundation)

Volání CreateDefaultAuthorizationContext s argumentem null se změnilo.

Detaily

Implementace System.IdentityModel.Policy.AuthorizationContext, která byla vrácena voláním System.IdentityModel.Policy.AuthorizationContext.CreateDefaultAuthorizationContext(IList<IAuthorizationPolicy>) s argumentem authorizationPolicies jako null, změnila svou implementaci v rozhraní .NET Framework 4.6.

Návrh

Ve výjimečných případech můžou aplikace WCF, které používají vlastní ověřování, vidět rozdíly v chování. V takových případech je možné předchozí chování obnovit jedním ze dvou způsobů:

  • Překompilujte aplikaci tak, aby cílila na starší verzi rozhraní .NET Framework než 4.6. Pro služby hostované službou IIS použijte <httpRuntime targetFramework="x.x"> element k cílení na starší verzi rozhraní .NET Framework.

  • Do části souboru app.config přidejte následující řádek <appSettings> :

    <add key="appContext.SetSwitch:Switch.System.IdentityModel.EnableCachedEmptyDefaultAuthorizationContext" value="true" />
Jméno Hodnota
Scope Drobné
Verze 4.6
Typ Změna cílení

Ovlivněná rozhraní API

model Windows Forms

Icon.ToBitmap úspěšně převede ikony s rámečky PNG na bitmapové objekty

Detaily

Počínaje aplikacemi, které cílí na rozhraní .NET Framework 4.6, Icon.ToBitmap metoda úspěšně převede ikony se snímky PNG na bitmapové objekty.

V aplikacích, které cílí na rozhraní .NET Framework 4.5.2 a starší verze, vyvolá metoda Icon.ToBitmap výjimku, ArgumentOutOfRangeException pokud objekt Icon má rámce PNG.

Tato změna má vliv na aplikace, které jsou rekompilovány tak, aby cílily na rozhraní .NET Framework 4.6 a implementují speciální zpracování pro ArgumentOutOfRangeException vyvolání, pokud objekt Icon má rámce PNG. Při spuštění v rozhraní .NET Framework 4.6 je převod úspěšný, ArgumentOutOfRangeException již není vyvolána, a proto obslužná rutina výjimky již není vyvolána.

Návrh

Pokud je toto chování nežádoucí, můžete předchozí chování zachovat přidáním následujícího prvku do <runtime> části souboru app.config:

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

Pokud soubor app.config již obsahuje AppContextSwitchOverrides prvek, měla by se nová hodnota sloučit s atributem value takto:

<AppContextSwitchOverrides
value="Switch.System.Drawing.DontSupportPngFramesInIcons=true;<previous key>=<previous value>" />
Jméno Hodnota
Scope Drobné
Verze 4.6
Typ Změna cílení

Ovlivněná rozhraní API

Windows Presentation Foundation (WPF)

CurrentCulture se v rámci operací dispečeru WPF nezachovává.

Detaily

Počínaje rozhraním .NET Framework 4.6 budou změny provedené ve System.Globalization.CultureInfo.CurrentCulture nebo System.Globalization.CultureInfo.CurrentUICulture v rámci System.Windows.Threading.Dispatcher ztraceny na konci dané operace dispečera. Podobně se změny System.Globalization.CultureInfo.CurrentCulture provedené mimo operaci Dispatcher nemusí projevit, když se tato operace spustí. Prakticky to znamená, že změny System.Globalization.CultureInfo.CurrentCulture a System.Globalization.CultureInfo.CurrentUICulture nemusí být šířeny mezi zpětnými voláními WPF UI a jinými části kódu v aplikaci WPF. Důvodem je změna v System.Threading.ExecutionContext, která vede k tomu, že System.Globalization.CultureInfo.CurrentCulture a System.Globalization.CultureInfo.CurrentUICulture se ukládají do kontextu spouštění počínaje aplikacemi zaměřenými na .NET Framework 4.6. Operace dispečera WPF ukládají kontext spuštění použitý k zahájení operace a obnovení předchozího kontextu po dokončení operace. Protože System.Globalization.CultureInfo.CurrentCulture a System.Globalization.CultureInfo.CurrentUICulture jsou nyní součástí tohoto kontextu, změny během operace plánovače se neuchovávají mimo operaci.

Návrh

Aplikace ovlivněné touto změnou můžou tuto změnu obejít uložením požadovaného System.Globalization.CultureInfo.CurrentCulture nebo System.Globalization.CultureInfo.CurrentUICulture do pole a kontrolou ve všech tělech operací dispečera (včetně obslužných rutin zpětného volání událostí uživatelského rozhraní), že System.Globalization.CultureInfo.CurrentCulture a System.Globalization.CultureInfo.CurrentUICulture jsou správně nastavené. Alternativně, změna ExecutionContext, která je základem této změny WPF, má vliv pouze na aplikace, které se zaměřují na rozhraní .NET Framework 4.6 nebo novější. Lze se tomu vyhnout zaměřením na rozhraní .NET Framework 4.5.2. Aplikace, které jsou zaměřeny na rozhraní .NET Framework 4.6 nebo novější, mohou tento problém také obejít nastavením následujícího přepínače kompatibility:

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

Tento problém vyřešil WPF v rozhraní .NET Framework 4.6.2. Byl také opraven v rozhraní .NET Frameworks 4.6, 4.6.1 až KB 3139549. Aplikace, které cílí na rozhraní .NET Framework 4.6 nebo novější, automaticky získají požadované chování v aplikacích WPF – System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture) se zachovají napříč operacemi Dispečera.

Jméno Hodnota
Scope Drobné
Verze 4.6
Typ Změna cílení

Zaokrouhlování okrajů v rozložení WPF se změnilo.

Detaily

Způsob, jakým jsou okraje zaoblené a ohraničení a pozadí uvnitř nich se změnilo. Výsledkem této změny:

  • Šířka nebo výška prvků se může zvětšit nebo zmenšit maximálně o jeden pixel.
  • Umístění objektu se může pohybovat maximálně o jeden pixel.
  • Prvky zarovnané na střed mohou být mírně posunuty svisle nebo vodorovně maximálně o jeden pixel od středu. Ve výchozím nastavení je toto nové rozložení povolené jenom pro aplikace, které cílí na rozhraní .NET Framework 4.6.

Návrh

Vzhledem k tomu, že tato změna má tendenci eliminovat výřez pravého nebo dolního rohu ovládacích prvků WPF s vysokou úrovní DPI, aplikace, které cílí na dřívější verze rozhraní .NET Framework, ale jsou spuštěné v rozhraní .NET Framework 4.6, mohou se k tomuto novému chování přihlásit přidáním následujícího řádku do <runtime> části souboru app.config:

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

Aplikace, které cílí na rozhraní .NET Framework 4.6, ale chtějí, aby se ovládací prvky WPF vykreslují pomocí předchozího algoritmu rozložení, můžou provést přidáním následujícího řádku do <runtime> části souboru app.config:

<AppContextSwitchOverrides value="Switch.MS.Internal.DoNotApplyLayoutRoundingToMarginsAndBorderThickness=true" />
Jméno Hodnota
Scope Drobné
Verze 4.6
Typ Změna cílení

XML, XSLT

XmlWriter vyvolá výjimku při neplatných náhradních párech

Detaily

U aplikací, které cílí na rozhraní .NET Framework 4.5.2 nebo předchozí verze, zápis neplatného náhradního páru pomocí náhradního zpracování výjimek nevyvolá výjimku vždy. U aplikací, které cílí na rozhraní .NET Framework 4.6, pokus o zápis neplatného náhradního páru vyvolá výjimku System.ArgumentException.

Návrh

V případě potřeby se tomuto přerušení můžete vyhnout tím, že cílíte na rozhraní .NET Framework 4.5.2 nebo starší. Alternativně je možné před zápisem neplatné náhradní páry předem zpracovat na platný XML.

Jméno Hodnota
Scope Edge
Verze 4.6
Typ Změna cílení

Ovlivněná rozhraní API

Ověření schématu XSD teď správně detekuje porušení jedinečných omezení, pokud se používají složené klíče a jeden klíč je prázdný.

Detaily

Verze rozhraní .NET Framework před verzí 4.6 měly chybu, která způsobila ověřování XSD, aby nerozpoznala jedinečná omezení složených klíčů, pokud jeden z klíčů byl prázdný. V rozhraní .NET Framework 4.6 je tento problém opraven. Výsledkem bude přesnější ověření, ale může to také vést k tomu, že se některá XML neověří, která by se dříve ověřila.

Návrh

Pokud je potřeba uvolněné ověřování rozhraní .NET Framework 4.0, může ověřovací aplikace cílit na verzi 4.5 (nebo dřívější) rozhraní .NET Framework. Při opětovném cílení na rozhraní .NET Framework 4.6 byste ale měli provést kontrolu kódu, abyste měli jistotu, že se neočekává ověření duplicitních složených klíčů (jak je popsáno v popisu tohoto problému).

Jméno Hodnota
Scope Edge
Verze 4.6
Typ Změna cílení

.NET Framework 4.6.1

Základ

Změna znaku oddělovače cest ve vlastnosti FullName objektů ZipArchiveEntry

Detaily

U aplikací, které cílí na .NET Framework 4.6.1 a novější verze, se znak oddělovače cesty změnil z zpětného lomítka ("\") na lomítko ("/") ve vlastnosti FullName objektů, které jsou vytvořeny přetíženími metody ZipArchiveEntryCreateFromDirectory. Tato změna přináší implementaci rozhraní .NET do souladu s oddílem 4.4.17.1 specifikace formátu souboru .ZIP a umožňuje dekompresi archivů .ZIP v systémech mimo Windows.
Dekomprese souboru ZIP vytvořeného aplikací, která cílí na předchozí verzi rozhraní .NET Framework v operačních systémech jiných než Windows, jako je Například Macintosh, nedokáže zachovat adresářovou strukturu. Například na počítači Macintosh vytvoří sadu souborů, jejichž název zřetězí cestu k adresáři spolu s libovolnými znaky zpětného lomítka ("\") a název souboru. V důsledku toho není zachována adresářová struktura dekomprimovaných souborů.

Návrh

Dopad této změny na .ZIP soubory, které jsou dekomprimovány na operační systém Windows rozhraními API v oboru názvů rozhraní .NET Framework System.IO , by mělo být minimální, protože tato rozhraní API mohou bez problémů zpracovat lomítko ("/") nebo zpětné lomítko ("\") jako znak oddělovače cesty.
Pokud je tato změna nežádoucí, můžete se z ní odhlásit přidáním konfiguračního nastavení do <runtime> části konfiguračního souboru vaší aplikace. Následující příklad ukazuje <runtime> oddíl i Switch.System.IO.Compression.ZipFile.UseBackslash přepínač pro odhlášení:

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

Aplikace, které cílí na předchozí verze rozhraní .NET Framework, ale jsou spuštěné v rozhraní .NET Framework 4.6.1 a novějších verzích, se můžou k tomuto chování přihlásit přidáním nastavení konfigurace do <runtime> části konfiguračního souboru aplikace. Následující zobrazuje jak sekci <runtime>, tak přepínač pro výslovný souhlas Switch.System.IO.Compression.ZipFile.UseBackslash.

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.Compression.ZipFile.UseBackslash=false" />
</runtime>
Jméno Hodnota
Scope Edge
Verze 4.6.1
Typ Změna cílení

Ovlivněná rozhraní API

WCF (Windows Communication Foundation)

Vazba WCF s režimem zabezpečení TransportWithMessageCredential

Detaily

Počínaje rozhraním .NET Framework 4.6.1 lze vazbu WCF, která používá režim zabezpečení TransportWithMessageCredential, nastavit tak, aby přijímala zprávy s nepodepsanými hlavičkami "to" pro asymetrické klíče zabezpečení. Ve výchozím nastavení budou hlavičky bez znaménka do nadále odmítnuty v rozhraní .NET Framework 4.6.1. Budou přijaty pouze v případě, že aplikace aktivuje nový provozní režim pomocí konfiguračního přepínače Switch.System.ServiceModel.AllowUnsignedToHeader.

Návrh

Vzhledem k tomu, že se jedná o funkci výslovného souhlasu, neměla by mít vliv na chování stávajících aplikací.
Pokud chcete určit, jestli se nové chování používá, nebo ne, použijte následující nastavení konfigurace:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.ServiceModel.AllowUnsignedToHeader=true" />
</runtime>
Jméno Hodnota
Scope Průhledné
Verze 4.6.1
Typ Změna cílení

Ovlivněná rozhraní API

X509CertificateClaimSet.FindClaims Zohledňuje všechny typy nároků

Detaily

V aplikacích, které cílí na rozhraní .NET Framework 4.6.1, pokud je sada deklarací identity X509 inicializována z certifikátu, který má v poli SAN více položek DNS, System.IdentityModel.Claims.X509CertificateClaimSet.FindClaims(String, String) se metoda pokusí shodovat s argumentem claimType se všemi položkami DNS. U aplikací, které cílí na předchozí verze rozhraní .NET Framework, se System.IdentityModel.Claims.X509CertificateClaimSet.FindClaims(String, String) metoda pokusí shodovat s argumentem claimType pouze s poslední položkou DNS.

Návrh

Tato změna má vliv pouze na aplikace, které cílí na rozhraní .NET Framework 4.6.1. Tuto změnu lze vypnout (nebo zapnout, pokud se jedná o verze před 4.6.1) pomocí přepínače kompatibility DisableMultipleDNSEntries.

Jméno Hodnota
Scope Drobné
Verze 4.6.1
Typ Změna cílení

Ovlivněná rozhraní API

model Windows Forms

Application.FilterMessage se už nevyvolá pro opětovné implementace IMessageFilter.PreFilterMessage

Detaily

Před verzí .NET Framework 4.6.1 by volání FilterMessage(Message) s PreFilterMessage(Message), které volalo System.Windows.Forms.Application.AddMessageFilter(IMessageFilter) nebo System.Windows.Forms.Application.RemoveMessageFilter(IMessageFilter) (při současném volání DoEvents()), způsobilo System.IndexOutOfRangeException.

Počínaje aplikacemi, které cílí na rozhraní .NET Framework 4.6.1, už se tato výjimka nevyvolá a filtry opětovného vyvolání, jak je popsáno výše, lze použít.

Návrh

Mějte na paměti, že FilterMessage(Message) již nebude vyvolávat výjimku pro reentrantní chování PreFilterMessage(Message) popsané výše. To se týká jenom aplikací, které cílí na rozhraní .NET Framework 4.6.1.Apps, které cílí na rozhraní .NET Framework 4.6.1, se můžou od této změny odhlásit (nebo aplikace, které cílí na starší architektury, se můžou přihlásit) pomocí přepínače kompatibility DontSupportReentrantFilterMessage .

Jméno Hodnota
Scope Edge
Verze 4.6.1
Typ Změna cílení

Ovlivněná rozhraní API

Windows Presentation Foundation (WPF)

Volání System.Windows.Input.PenContext.Disable v systémech s podporou dotykového ovládání mohou vyvolat výjimku ArgumentException.

Detaily

Za určitých okolností mohou volání interní metody System.Windows.Input.PenContext.Disable v systémech s podporou dotykového ovládání způsobit neošetřenou výjimku z důvodu znovuzavolání.

Návrh

Tento problém je vyřešený v rozhraní .NET Framework 4.7. Pokud chcete této výjimce zabránit, upgradujte na verzi rozhraní .NET Framework počínaje rozhraním .NET Framework 4.7.

Jméno Hodnota
Scope Edge
Verze 4.6.1
Typ Změna cílení

.NET Framework 4.6.2

ASP.NET

HttpRuntime.AppDomainAppPath vyvolá výjimku NullReferenceException

Detaily

V rozhraní .NET Framework 4.6.2 vyvolá modul runtime T:System.NullReferenceException při načítání P:System.Web.HttpRuntime.AppDomainAppPath hodnoty, která obsahuje nulové znaky. V rozhraní .NET Framework 4.6.1 a starších verzích modul runtime vyvolá T:System.ArgumentNullException.

Návrh

Na tuto změnu můžete odpovědět některým z následujících kroků:

  • Zpracujte T:System.NullReferenceException, pokud je aplikace spuštěna v rozhraní .NET Framework 4.6.2.
  • Upgradujte na rozhraní .NET Framework 4.7, který obnoví předchozí chování a vyvolá chybu T:System.ArgumentNullException.
Jméno Hodnota
Scope Edge
Verze 4.6.2
Typ Změna cílení

Ovlivněná rozhraní API

Základ

Dešifrovač AesCryptoServiceProvider poskytuje opakovaně použitelnou transformaci.

Detaily

Počínaje aplikacemi, které cílí na rozhraní .NET Framework 4.6.2, AesCryptoServiceProvider dešifrovací nástroj poskytuje opakovaně použitelnou transformaci. Po volání System.Security.Cryptography.CryptoAPITransform.TransformFinalBlock(Byte[], Int32, Int32)se transformace znovu inicializuje a dá se znovu použít. U aplikací, které cílí na starší verze rozhraní .NET Framework, pokus o opětovné použití dešifrovacího nástroje voláním System.Security.Cryptography.CryptoAPITransform.TransformBlock(Byte[], Int32, Int32, Byte[], Int32) po volání System.Security.Cryptography.CryptoAPITransform.TransformFinalBlock(Byte[], Int32, Int32) vyvolá CryptographicException nebo vytvoří poškozená data.

Návrh

Dopad této změny by měl být minimální, protože se jedná o očekávané chování. Aplikace, které závisí na předchozím chování, se můžou z tohoto chování odhlásit přidáním následujícího nastavení konfigurace do <runtime> části konfiguračního souboru aplikace:

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

Aplikace, které cílí na předchozí verzi rozhraní .NET Framework, ale běží pod verzí rozhraní .NET Framework počínaje rozhraním .NET Framework 4.6.2, se k ní můžou přihlásit přidáním následujícího nastavení konfigurace do <runtime> části konfiguračního souboru aplikace:

<runtime>
<AppContextSwitchOverrides value="Switch.System.Security.Cryptography.AesCryptoServiceProvider.DontCorrectlyResetDecryptor=false"/>
</runtime>
Jméno Hodnota
Scope Drobné
Verze 4.6.2
Typ Změna cílení

Ovlivněná rozhraní API

Volání konstruktorů ClaimsIdentity

Detaily

Počínaje rozhraním .NET Framework 4.6.2 došlo ke změně způsobu, jakým ClaimsIdentity konstruktory s parametrem System.Security.Principal.IIdentity nastavují System.Security.Claims.ClaimsIdentity.Actor vlastnost. System.Security.Principal.IIdentity Pokud argument je ClaimsIdentity objekt a System.Security.Claims.ClaimsIdentity.Actor vlastnost tohoto ClaimsIdentity objektu není null, System.Security.Claims.ClaimsIdentity.Actor vlastnost je připojena pomocí Clone() metody. V rozhraní .NET Framework 4.6.1 a starších verzích je vlastnost System.Security.Claims.ClaimsIdentity.Actor připojena jako existující odkaz. Vzhledem k této změně, počínaje .NET Framework 4.6.2, vlastnost System.Security.Claims.ClaimsIdentity.Actor nového objektu ClaimsIdentity není rovna vlastnosti System.Security.Claims.ClaimsIdentity.Actor argumentu konstruktoru System.Security.Principal.IIdentity. V rozhraní .NET Framework 4.6.1 a starších verzích je stejný.

Návrh

Pokud je toto chování nežádoucí, můžete předchozí chování obnovit nastavením Switch.System.Security.ClaimsIdentity.SetActorAsReferenceWhenCopyingClaimsIdentity přepínače v konfiguračním souboru aplikace na true. To vyžaduje, abyste do <runtime> části souboru web.config přidali následující položky:

<configuration>
  <runtime>
    <AppContextSwitchOverrides value="Switch.System.Security.ClaimsIdentity.SetActorAsReferenceWhenCopyingClaimsIdentity=true" />
  </runtime>
</configuration>
Jméno Hodnota
Scope Edge
Verze 4.6.2
Typ Změna cílení

Ovlivněná rozhraní API

Změny normalizace cest

Detaily

Počínaje aplikacemi, které cílí na rozhraní .NET Framework 4.6.2, způsob, jakým modul runtime normalizuje cesty, se změnily. Normalizace cesty zahrnuje úpravu řetězce, který identifikuje cestu nebo soubor tak, aby odpovídal platné cestě v cílovém operačním systému. Normalizace obvykle zahrnuje:

  • Kanonizace komponent a oddělovačů adresářů.
  • Aplikování aktuálního adresáře na relativní cestu
  • Vyhodnocení relativního adresáře (.) nebo nadřazeného adresáře (..) v cestě
  • Oříznutí zadaných znaků Počínaje aplikacemi, které cílí na rozhraní .NET Framework 4.6.2, jsou ve výchozím nastavení povoleny následující změny normalizace cest:
  • Normalizace už nezahrnuje oříznutí konce segmentů adresáře (například mezeru na konci názvu adresáře).
  • Podpora syntaxe cesty zařízení v plné důvěře, včetně \\.\, a pro rozhraní API pro vstupně-výstupní operace souborů v mscorlib.dll, \\?\.
  • Modul runtime neověřuje cesty syntaxe zařízení.
  • Podporuje se použití syntaxe zařízení pro přístup k alternativním datovým proudům. Tyto změny zlepšují výkon a umožňují metodám přístup k dříve nepřístupným cestám. Tyto změny neovlivní aplikace, které cílí na rozhraní .NET Framework 4.6.1 a starší verze, ale jsou spuštěné v rozhraní .NET Framework 4.6.2 nebo novější.

Návrh

Aplikace, které cílí na rozhraní .NET Framework 4.6.2 nebo novější, můžou tuto změnu vyloučit a používat starší normalizaci přidáním následujícího oddílu <runtime> konfiguračního souboru aplikace:

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

Aplikace, které cílí na rozhraní .NET Framework 4.6.1 nebo starší, ale běží na rozhraní .NET Framework 4.6.2 nebo novější, můžou povolit změny normalizace cest přidáním následujícího řádku do <runtime> části souboru .configuration aplikace:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.UseLegacyPathHandling=false" />
</runtime>
Jméno Hodnota
Scope Drobné
Verze 4.6.2
Typ Změna cílení

Tok CurrentCulture a CurrentUICulture napříč úlohami

Detaily

Počínaje rozhraním .NET Framework 4.6 System.Globalization.CultureInfo.CurrentCulture a System.Globalization.CultureInfo.CurrentUICulture jsou uloženy ve vlákně System.Threading.ExecutionContext, které proudí napříč asynchronními operacemi. To znamená, že změny System.Globalization.CultureInfo.CurrentCulture nebo System.Globalization.CultureInfo.CurrentUICulture se projeví v úlohách, které se později spustí asynchronně. Toto chování se liší od chování předchozích verzí rozhraní .NET Framework (které by resetovaly System.Globalization.CultureInfo.CurrentCulture a System.Globalization.CultureInfo.CurrentUICulture ve všech asynchronních úlohách).

Návrh

Aplikace ovlivněné touto změnou můžou tuto změnu obejít tak, že explicitně nastaví požadovanou System.Globalization.CultureInfo.CurrentCulture nebo System.Globalization.CultureInfo.CurrentUICulture jako první operaci v asynchronní úloze. Můžete také zvolit staré chování (netečování System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture) nastavením následujícího přepínače kompatibility:

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

Tento problém vyřešil WPF v rozhraní .NET Framework 4.6.2. Byl také opraven v rozhraní .NET Frameworks 4.6, 4.6.1 až KB 3139549. Aplikace, které cílí na rozhraní .NET Framework 4.6 nebo novější, automaticky získají správné chování v aplikacích WPF – System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture) se zachovají napříč operacemi Dispatcheru.

Jméno Hodnota
Scope Drobné
Verze 4.6
Typ Změna cílení

Ovlivněná rozhraní API

Názvy událostí ETW se nesmí lišit pouze příponou „Start“ nebo „Stop“.

Detaily

Modul runtime v rozhraní .NET Framework 4.6 a 4.6.1 vyvolá ArgumentException , když se dva názvy událostí trasování událostí pro Windows (ETW) liší pouze příponou Start nebo Stop (jako když je jedna událost pojmenována LogUser a druhá je pojmenovaná LogUserStart). V tomto případě modul runtime nemůže sestavit zdroj událostí, který nemůže generovat žádné protokolování.

Návrh

Chcete-li zabránit výjimce, ujistěte se, že se žádné dva názvy událostí liší pouze příponou Start nebo Stop. Tento požadavek se odebere počínaje rozhraním .NET Framework 4.6.2; modul runtime může nejednoznačit názvy událostí, které se liší pouze příponou Start a Stop.

Jméno Hodnota
Scope Edge
Verze 4.6
Typ Změna cílení

Podpora dlouhých cest

Detaily

Počínaje aplikacemi, které cílí na rozhraní .NET Framework 4.6.2, jsou podporovány dlouhé cesty (až 32 tisíc znaků) a bylo odebráno omezení délky cesty o délce 260 znaků (nebo MAX_PATH). U aplikací, které jsou rekompilované tak, aby cílily na rozhraní .NET Framework 4.6.2, cesty kódu, které dříve vyvolaly System.IO.PathTooLongException cestu, protože cesta překročila 260 znaků, teď vyvolá System.IO.PathTooLongException pouze za následujících podmínek:

  • Délka cesty je větší než MaxValue (32 767) znaků.
  • Operační systém vrátí COR_E_PATHTOOLONG nebo jeho ekvivalent. U aplikací, které cílí na rozhraní .NET Framework 4.6.1 a starší verze, modul runtime automaticky vyvolá System.IO.PathTooLongException pokaždé, když cesta překročí 260 znaků.

Návrh

U aplikací, které cílí na rozhraní .NET Framework 4.6.2, se můžete odhlásit z podpory dlouhých cest, pokud není žádoucí, přidáním následujícího do sekce <runtime> ve vašem souboru app.config:

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

U aplikací, které cílí na starší verze rozhraní .NET Framework, ale běží na rozhraní .NET Framework 4.6.2 nebo novější, můžete aktivovat podporu dlouhých cest přidáním následujícího do <runtime> sekce vašeho souboru app.config.

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.BlockLongPaths=false" />
</runtime>
Jméno Hodnota
Scope Drobné
Verze 4.6.2
Typ Změna cílení

Kontroly dvojtečky cest jsou přísnější.

Detaily

V rozhraní .NET Framework 4.6.2 bylo provedeno několik změn, které podporovaly dříve nepodporované cesty (délku i formát). Kontroly správnosti syntaxe oddělovače jednotek (dvojtečka) byly opraveny, což mělo vedlejší účinek blokování některých cest URI v několika vybraných rozhraních cest API, kde se dříve tolerovaly.

Návrh

Pokud předáte identifikátor URI ovlivněným rozhraním API, nejprve upravte řetězec na platnou cestu.

  • Schéma odeberte z adres URL ručně (například odebrat file:// z adres URL).

  • Předejte identifikátor URI do Uri třídy a použijte LocalPath.

Alternativně můžete zrušit normalizaci nové cesty nastavením Switch.System.IO.UseLegacyPathHandling přepínače AppContext na true.

Jméno Hodnota
Scope Edge
Verze 4.6.2
Typ Změna cílení

Ovlivněná rozhraní API

Zabezpečení

RsACng teď správně načte klíče RSA s nestandardní velikostí klíče.

Detaily

Ve verzích rozhraní .NET Framework starších než 4.6.2 nemají zákazníci s nestandardními velikostmi klíčů pro certifikáty RSA přístup k těmto klíčům prostřednictvím metod rozšíření System.Security.Cryptography.X509Certificates.RSACertificateExtensions.GetRSAPublicKey(X509Certificate2) a System.Security.Cryptography.X509Certificates.RSACertificateExtensions.GetRSAPrivateKey(X509Certificate2). K výjimce System.Security.Cryptography.CryptographicException byla přidána zpráva "Požadovaná velikost klíče není podporována". V rozhraní .NET Framework 4.6.2 byl tento problém opraven. Podobně, ImportParameters(RSAParameters) a ImportParameters(RSAParameters) nyní pracuje s nestandardními velikostmi klíčů aniž by vyvolaly System.Security.Cryptography.CryptographicException.

Návrh

Pokud existuje nějaká logika zpracování výjimek, která spoléhá na předchozí chování, kdy System.Security.Cryptography.CryptographicException se vyvolá při použití nestandardních velikostí klíčů, zvažte odebrání logiky.

Jméno Hodnota
Scope Edge
Verze 4.6.2
Typ Změna cílení

Ovlivněná rozhraní API

SignedXml.GetPublicKey vrátí RSACng v prostředí net462 (nebo při využití "light-up") bez změny retargetingu.

Detaily

Počínaje rozhraním .NET Framework 4.6.2 se konkrétní typ objektu vráceného SignedXml.GetPublicKey metodou změnil (bezquirku) z implementace CryptoServiceProvider na implementaci Cng. Důvodem je to, že implementace se změnila z použití certificate.PublicKey.Key na použití interního certificate.GetAnyPublicKey , který předává RSACertificateExtensions.GetRSAPublicKey.

Návrh

Počínaje aplikacemi spuštěnými v rozhraní .NET Framework 4.7.1 můžete použít implementaci CryptoServiceProvider, která se ve výchozím nastavení používá v rozhraní .NET Framework 4.6.1 a starších verzích, a to přidáním následujícího přepínače konfigurace do části runtime konfiguračního souboru aplikace:

<AppContextSwitchOverrides value="Switch.System.Security.Cryptography.Xml.SignedXmlUseLegacyCertificatePrivateKey=true" />
Jméno Hodnota
Scope Edge
Verze 4.6.2
Typ Změna cílení

Ovlivněná rozhraní API

WCF (Windows Communication Foundation)

K zablokování může dojít při použití reentrantních služeb

Detaily

Zablokování může vést ke službě Reentrant, která omezuje instance služby na jedno vlákno spuštění najednou. Služby náchylné k tomuto problému budou mít v kódu následující ServiceBehaviorAttribute :

[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Reentrant)]

Návrh

Pokud chcete tento problém vyřešit, můžete udělat toto:

[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Reentrant)]
  • Nainstalujte nejnovější aktualizaci rozhraní .NET Framework 4.6.2 nebo upgradujte na novější verzi rozhraní .NET Framework. Tím se deaktivuje tok ExecutionContext v OperationContext.Current. Toto chování je konfigurovatelné; je ekvivalentní přidání následujícího nastavení aplikace do konfiguračního souboru:
<appSettings>
  <add key="Switch.System.ServiceModel.DisableOperationContextAsyncFlow" value="true" />
</appSettings>

Hodnota Switch.System.ServiceModel.DisableOperationContextAsyncFlow by nikdy neměla být nastavena na false pro reentrantní služby.

Jméno Hodnota
Scope Drobné
Verze 4.6.2
Typ Změna cílení

Ovlivněná rozhraní API

OperationContext.Current může vrátit hodnotu null při zavolání v klauzuli using

Detaily

OperationContext.Current může vrátit null a NullReferenceException může mít za následek, jsou-li splněny všechny následující podmínky:

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

    // ...
}

Návrh

Pokud chcete tento problém vyřešit, můžete udělat toto:

  • Následujícím způsobem upravte kód tak, aby vytvořil instanci nového objektu bez nullCurrent objektu:

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

    // ...
}

  • Nainstalujte nejnovější aktualizaci rozhraní .NET Framework 4.6.2 nebo upgradujte na novější verzi rozhraní .NET Framework. To zakáže tok ExecutionContext v OperationContext.Current a vrátí chování aplikací WCF v rozhraní .NET Framework 4.6.1 a starších verzích. Toto chování je konfigurovatelné; je ekvivalentní přidání následujícího nastavení aplikace do konfiguračního souboru:

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

    Pokud je tato změna nežádoucí a vaše aplikace závisí na toku kontextu spuštění mezi kontexty operací, můžete tok povolit následujícím způsobem:

    <appSettings>
  <add key="Switch.System.ServiceModel.DisableOperationContextAsyncFlow" value="false" />
</appSettings>
Jméno Hodnota
Scope Edge
Verze 4.6.2
Typ Změna cílení

Ovlivněná rozhraní API

Zabezpečení přenosu WCF podporuje certifikáty uložené pomocí CNG

Detaily

Počínaje aplikacemi, které cílí na rozhraní .NET Framework 4.6.2, podporuje zabezpečení přenosu WCF certifikáty uložené pomocí knihovny CNG (Windows Cryptography Library). Tato podpora je omezená na certifikáty s veřejným klíčem, který má exponent nejvýše 32 bitů. Když aplikace cílí na rozhraní .NET Framework 4.6.2, je tato funkce ve výchozím nastavení zapnutá. V dřívějších verzích rozhraní .NET Framework vyvolá pokus o použití certifikátů X509 s poskytovatelem úložiště klíčů CSG výjimku.

Návrh

Aplikace, které cílí na rozhraní .NET Framework 4.6.1 a starší, ale běží na rozhraní .NET Framework 4.6.2, můžou povolit podporu certifikátů CNG přidáním následujícího řádku do <runtime> části souboru app.config nebo web.config:

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

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

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

AppContext.SetSwitch(disableCngCertificates, false);

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

Všimněte si, že kvůli této změně se už nebude spouštět jakýkoli kód zpracování výjimek, který závisí na pokusu o zahájení zabezpečené komunikace s certifikátem CNG.

Jméno Hodnota
Scope Drobné
Verze 4.6.2
Typ Změna cílení

model Windows Forms

Nesprávná implementace MemberDescriptor.Equals

Detaily

Původní implementace metody MemberDescriptor.Equals porovnává dvě různé řetězcové vlastnosti porovnávaných objektů: název kategorie a popis. Oprava je porovnat Category prvního objektu s Category druhého, a Description prvního s Description druhého.

Návrh

Pokud vaše aplikace závisí na tom, že MemberDescriptor.Equals někdy vrací false, když jsou deskriptory rovnocenné, a cílíte na rozhraní .NET Framework 4.6.2 nebo vyšší, máte několik možností:

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

Pokud vaše aplikace cílí na rozhraní .NET Framework 4.6.1 nebo starší a běží na rozhraní .NET Framework 4.6.2 nebo novější a chcete tuto změnu povolit, můžete přepínač false kompatibility nastavit tak, že do souboru app.config přidáte následující hodnotu:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.MemberDescriptorEqualsReturnsFalseIfEquivalent=false" />
</runtime>
Jméno Hodnota
Scope Edge
Verze 4.6.2
Typ Změna cílení

Ovlivněná rozhraní API

Windows Presentation Foundation (WPF)

CurrentCulture se v rámci operací dispečeru WPF nezachovává.

Detaily

Počínaje rozhraním .NET Framework 4.6 budou změny provedené ve System.Globalization.CultureInfo.CurrentCulture nebo System.Globalization.CultureInfo.CurrentUICulture v rámci System.Windows.Threading.Dispatcher ztraceny na konci dané operace dispečera. Podobně se změny System.Globalization.CultureInfo.CurrentCulture provedené mimo operaci Dispatcher nemusí projevit, když se tato operace spustí. Prakticky to znamená, že změny System.Globalization.CultureInfo.CurrentCulture a System.Globalization.CultureInfo.CurrentUICulture nemusí být šířeny mezi zpětnými voláními WPF UI a jinými části kódu v aplikaci WPF. Důvodem je změna v System.Threading.ExecutionContext, která vede k tomu, že System.Globalization.CultureInfo.CurrentCulture a System.Globalization.CultureInfo.CurrentUICulture se ukládají do kontextu spouštění počínaje aplikacemi zaměřenými na .NET Framework 4.6. Operace dispečera WPF ukládají kontext spuštění použitý k zahájení operace a obnovení předchozího kontextu po dokončení operace. Protože System.Globalization.CultureInfo.CurrentCulture a System.Globalization.CultureInfo.CurrentUICulture jsou nyní součástí tohoto kontextu, změny během operace plánovače se neuchovávají mimo operaci.

Návrh

Aplikace ovlivněné touto změnou můžou tuto změnu obejít uložením požadovaného System.Globalization.CultureInfo.CurrentCulture nebo System.Globalization.CultureInfo.CurrentUICulture do pole a kontrolou ve všech tělech operací dispečera (včetně obslužných rutin zpětného volání událostí uživatelského rozhraní), že System.Globalization.CultureInfo.CurrentCulture a System.Globalization.CultureInfo.CurrentUICulture jsou správně nastavené. Alternativně, změna ExecutionContext, která je základem této změny WPF, má vliv pouze na aplikace, které se zaměřují na rozhraní .NET Framework 4.6 nebo novější. Lze se tomu vyhnout zaměřením na rozhraní .NET Framework 4.5.2. Aplikace, které jsou zaměřeny na rozhraní .NET Framework 4.6 nebo novější, mohou tento problém také obejít nastavením následujícího přepínače kompatibility:

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

Tento problém vyřešil WPF v rozhraní .NET Framework 4.6.2. Byl také opraven v rozhraní .NET Frameworks 4.6, 4.6.1 až KB 3139549. Aplikace, které cílí na rozhraní .NET Framework 4.6 nebo novější, automaticky získají správné chování v aplikacích WPF – System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture) se zachovají napříč operacemi Dispatcheru.

Jméno Hodnota
Scope Drobné
Verze 4.6
Typ Změna cílení
  • Last updated on