Tento článek popisuje kumulativní opravu hotfix, která je dostupná pro Microsoft .NET Framework 4.6.1 a 4.6. Další informace o problémech, které tato kumulativní oprava hotfix řeší, najdete v části Problémy, které tato kumulativní oprava oprav opravuje .
Řešení
Stáhnout informace
Oprava hotfix, která odpovídá aktualizaci KB3139549, byla nahnána nejnovějšími aktualizacemi .NET Framework, které obsahují všechny opravy, které byly dříve součástí aktualizace KB3139549. Doporučujeme nainstalovat nejnovější aktualizace .NET Framework.
Další informace o stahování souborů podpory společnosti Microsoft naleznete v následujícím článku znalostní báze Microsoft Knowledge Base:
119591 Jak získat soubory podpory Microsoftu z online služeb, naskenoval Microsoft tento soubor na viry. Společnost Microsoft použila nejnovější software pro zjišťování virů, který byl k datu, kdy byl soubor publikován, dostupný. Soubor je uložený na serverech s vyšším zabezpečením, které pomáhají zabránit neoprávněným změnám souboru.
Další informace
Požadavky
Pokud chcete použít tuto opravu hotfix, musíte mít nainstalovaný .NET Framework 4.6.1 nebo .NET Framework 4.6.
Požadavky na restartování
Pokud se používají nějaké ovlivněné soubory, musíte po instalaci této opravy hotfix restartovat počítač. Před použitím této opravy hotfix doporučujeme ukončit všechny .NET Framework založené na aplikacích.
Informace o nahrazení opravy Hotfix
Tento balíček oprav hotfix nenahrazuje dříve vydaný balíček oprav hotfix.
Problémy, které tato kumulativní oprava hotfix řeší
Problém 1
Když aplikace WPF používá prvek TreeViewItem mimo kontext TreeView, může aplikace narazit na výjimku InvalidCastException, jejíž trasování zásobníku začíná takto:
Systém. Windows. Controls.VirtualizingStackPanel.FindScrollOffset(Visual v)
Poznámka: K této výjimce dochází, když je prvek TreeViewItem v ovládacím prvku virtualizovaného seznamu (například ovládací prvek ListBox, DataGrid nebo ListView), který se snaží najít posun posunu položky TreeViewItem nebo jednoho z jeho potomků. Pokud například deklarovat TreeViewItem jako kořen DataTemplate a DataTemplate se používá jako CellTemplate sloupce DataGrid, dojde k této výjimce.
Problém 2
Obě system.web. Ukládání do mezipaměti a System.Runtime. Ukládání do mezipaměti o velikosti paměti používané celou doménou Aplikace místo velikosti paměti používané položkami mezipaměti.
Jedná se o regresní problém z .NET Framework 4.5, ve kterém byla provedena změna implementace časovače. Kromě vykazování nesprávné velikosti mohou další objekty, na které mezipaměť odkazuje, významně ovlivnit latenci Gen2 GC. V ASP.NET hostitelských scénářích mezipaměť také nesprávně vypočítala velikost všech mezipamětí ve všech doménách aplikací (nahlášených prostřednictvím limitu paměti procesu mezipaměti pro ukládání ASP.NET) při recyklaci domén aplikací.
Oprava odebere neúmyslné odkazy z mezipaměti do ostatních objektů domény aplikace a pak se vykázala správná velikost. Zahrnuje také změny, které zlepšují latenci pro System.Runtime. Ukládání do mezipaměti na vícejádrových počítačích, které používají Server GC. A nakonec tato oprava vypočítá velikost všech mezipamětí ve scénářích recyklace domény aplikace správně.
Problém 3
Pokud máte aplikaci Windows Presentation Foundation (WPF), která využívá propagaci pohybu myší, aby bylo možné zpracovat interakci uživatelů s dotykovým pohybem (místo přímého používání událostí dotykového ovládání), může docházet k neobvykle nízkému objemu propagovaných pohybů myši.
V minulosti se propagace dotykového ovládání pomocí myši s omezením WPF pohyboval, protože objem dotykového ovládání se pohyboval zahlcený dispečerem. V .NET Framework 4.6.1 byla pro toto chování provedena oprava. Oprava zkrátí počet zpracovaných dotykových pohybů. Omezení propagačních akcí myši proto způsobilo další snížení generování pohybů myší. V této kumulativní aktualizaci se odebralo omezení propagačních akcí myši a teď by se měla blížit korespondenci mezi událostmi přesunutí dotykového ovládání a propagovat události přesunutí myši.
Problém 4
Předpokládejme, že pracujete s aplikací WPF, která se zaměřuje na .NET Framework 4.6. Předpokládejme například, že se pokusíte nastavit CurrentThread.CurrentCulture nebo CurrentThread.CurrentUICulture v jakékoli metodě (například obslužnou rutinu události uživatelského rozhraní nebo konstruktor MainWindow), která je volána dispečerem WPF pomocí DispatcherOperation. V takovém případě se hodnoty CurrentCulture a CurrentUICulture resetují na jejich předchozí hodnoty na konci metody. Pokud aplikace nastaví currentuiculture v jeho mainwindow konstruktéru nebo obslužnou rutinu kliknutí na tlačítko, toto nastavení se vrátí zpět na jazykovou verzi uživatelského rozhraní systému.
Tato oprava zajistí, aby hodnoty CurrentThread.CurrentCulture/CurrentUICulture, které je možné nastavit v metodách v aplikaci WPF, přetrvávají stejně jako před .NET Framework 4.6.
Problém 5
V .NET Framework 4.6 byl do knihovny úkolů přidán nový příznak TaskContinuationOptions.RunContinuationsAsynchronously. Pokud ale použijete tento příznak ve spojení s task.whenall, task.whenany nebo task.unwrap, nemá to žádný vliv. Příznak byl zaveden, aby se zabránilo určitým podmínkám zablokování. Tato oprava zajistí, aby všechny typy pokračování úkolů respektoval nový příznak.
Problém 6
AppContext je součástí infrastruktury, která snižuje přerušné změny. Pomocí appcontextu můžete nastavit a načíst příznaky a rozhodovat se v aplikaci, která je založená na těchto datech. V .NET Framework 4.6 je v AppContextu chyba, ve které je nesprávně implementována bezpečnost metod AppContext.
Tato oprava umožňuje správnou bezpečnost vlákna pro metody v appcontextu, které souvisejí s nastavením a načítáním hodnot přepínačů.
Problém 7
Když narazíte na hraniční případ se svým alokací a modelem přežití a potřebujete nový segment na spravované haldě, může systém uvolňování paměti vypočítat velikost potvrzení, která je menší, než by měla být. To způsobí porušení přístupu během kompaktní fáze, protože se systém uvolňování paměti snaží zapsat do nepověřené paměti. Tato oprava vypočítá velikost správně.
Problém 8
Při vytváření nativního kódu pro určité metody může dojít k .NET Framework aplikací a NGEN.
Problém 9
RyuJit vygeneruje nesprávné pokyny pro porovnání 16bitových celých čísel bez znaménka v registrech. Výsledkem jsou nesprávné výsledky, pokud vstupní hodnoty mají různé hodnoty MSB, a vygenerují proto pokyny pro porovnání, které používají jenom operandy registru. Tato oprava vygeneruje správné pokyny.
