Problémy s migrací rozhraní .NET Framework 4

Článek
03/02/2024

Tento článek popisuje problémy s migrací mezi rozhraním .NET Framework verze 3.5 Service Pack 1 a rozhraním .NET Framework verze 4, včetně oprav, změn dodržování standardů a zabezpečení a změn na základě zpětné vazby zákazníků. Většina těchto změn nevyžaduje žádné programové změny v aplikacích. U těch, které můžou zahrnovat úpravy, najdete ve sloupci Doporučené změny tabulky. Velmi vhodné změny jsou rozděleny podle oblasti, například ASP.NET a Windows Presentation Foundation (WPF).

Přehled problémů v tomto článku najdete v průvodci migrací na rozhraní .NET Framework 4.

Informace o nových funkcích naleznete v tématu Co je nového v rozhraní .NET Framework 4.

ASP.NET a web

Obory názvů: System.Web, System.Web.Mobile, System.Web.Security, System.Web.UI.WebControls

Sestavení: System.Web (v System.Web.dll)

Funkce	Rozdíly mezi aktualizací 3.5 SP1	Doporučené změny
Definiční soubory prohlížeče	Soubory definic prohlížeče byly aktualizovány tak, aby obsahovaly informace o nových a aktualizovaných prohlížečích a zařízeních. Starší prohlížeče a zařízení, jako je Netscape Navigator, byly odebrány a byly přidány novější prohlížeče a zařízení, jako je Google Chrome a Apple i Telefon. Pokud vaše aplikace obsahuje vlastní definice prohlížeče, které dědí z jedné z odebraných definic prohlížeče, zobrazí se chyba. Objekt HttpBrowserCapabilities (vystavený vlastností stránky `Request.Browse` ) je řízen definičními soubory prohlížeče. Proto informace vrácené přístupem k vlastnosti tohoto objektu v ASP.NET 4 se mohou lišit od informací vrácených v dřívější verzi ASP.NET.	Pokud vaše aplikace spoléhá na staré definiční soubory prohlížeče, můžete je zkopírovat z následující složky: Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\Browsers Zkopírujte soubory do odpovídající složky \CONFIG\Browsers pro ASP.NET 4. Po zkopírování souborů spusťte nástroj příkazového řádku Aspnet_regbrowsers.exe . Další informace naleznete na https://www.asp.net/mobile webu.
Podřízené aplikace spuštěné ve smíšených verzích ASP.NET	ASP.NET 4 aplikací, které jsou nakonfigurované jako podřízené položky aplikací, které používají starší verze ASP.NET, se nemusí spustit kvůli chybám konfigurace nebo kompilace. Konkrétní chyba, ke které dochází, závisí na tom, zda aplikace běží ve službě IIS 6.0 nebo ve službě IIS 7 nebo IIS 7.5.	V konfiguračních souborech ovlivněných aplikací můžete provádět změny tak, aby konfigurační systém správně rozpoznal aplikaci ASP.NET 4. Informace o změnách, které je nutné provést, naleznete v části "ASP.NET 4 Podřízené aplikace se nedaří spustit Při ASP.NET 2.0 nebo ASP.NET 3.5 Aplikace" v dokumentu ASP.NET 4 Zásadní změny na webu ASP.NET.
Změny ID klienta	Nové `clientIDMode` nastavení v ASP.NET 4 umožňuje určit, jak ASP.NET generuje atribut pro elementy `id` HTML. V předchozích verzích ASP.NET bylo výchozí chování ekvivalentní `AutoID` nastavení `clientIDMode`. Výchozí nastavení je nyní `Predictable`. Další informace naleznete v tématu ASP.NET Identifikace ovládacího prvku webového serveru.	Pokud pomocí sady Visual Studio upgradujete aplikaci z ASP.NET 2.0 nebo ASP.NET 3.5, nástroj automaticky přidá nastavení do souboru Web.config, který zachovává chování starších verzí rozhraní .NET Framework. Pokud však upgradujete aplikaci změnou fondu aplikací ve službě IIS na cíl rozhraní .NET Framework 4, ASP.NET ve výchozím nastavení použije nový režim. Pokud chcete zakázat nový režim ID klienta, přidejte do souboru Web.config následující nastavení: `<pages clientIDMode="AutoID" />`
Zabezpečení přístupu kódu (CAS)	ASP.NET funkce 2.0 NET přidané v ASP.NET 3.5 používají model zabezpečení přístupu kódu (CAS) rozhraní .NET Framework 1.1 a .NET Framework 2.0. Implementace CAS v ASP.NET 4 se však podstatně přepracovala. V důsledku toho můžou částečné vztahy důvěryhodnosti ASP.NET aplikace, které spoléhají na důvěryhodný kód spuštěný v globální mezipaměti sestavení, selhat s různými výjimkami zabezpečení. Částečně důvěryhodné aplikace, které spoléhají na rozsáhlé úpravy zásad cas počítače, můžou také selhat a vyvolat výjimky zabezpečení.	Částečné vztahy důvěryhodnosti ASP.NET 4 aplikace můžete vrátit k chování ASP.NET 1.1 a 2.0 pomocí nového `legacyCasModel` atributu v elementu konfigurace, jak je znázorněno v následujícím příkladu `trust` : `<trust level= "Medium" legacyCasModel="true" />` Důležité: Návrat ke staršímu modelu CAS může představovat snížené zabezpečení. Další informace o novém modelu zabezpečení přístupu kódu ASP.NET 4 najdete v tématu Zabezpečení přístupu kódu v aplikacích ASP.NET 4.
Konfigurační soubory	Kořenové konfigurační soubory (soubor machine.config a kořenový soubor Web.config) pro rozhraní .NET Framework a ASP.NET 4 byly aktualizovány tak, aby zahrnovaly většinu často používaných konfiguračních informací, které byly nalezeny v souborech Web.config aplikace v ASP.NET 3.5. Vzhledem ke složitosti spravovaných konfiguračních systémů IIS 7 a IIS 7.5 může spouštění aplikací ASP.NET 3.5 v rámci ASP.NET 4 a služby IIS 7 a IIS 7.5 vést k chybám ASP.NET nebo chybám služby IIS.	Upgradujte ASP.NET aplikace 3.5 na ASP.NET 4 pomocí nástrojů pro upgrade projektu v sadě Visual Studio. Visual Studio 2010 automaticky upraví soubor Web.config aplikace ASP.NET 3.5 tak, aby obsahoval odpovídající nastavení pro ASP.NET 4. Můžete však spouštět aplikace ASP.NET 3.5 pomocí rozhraní .NET Framework 4 bez rekompilace. V takovém případě možná budete muset ručně upravit soubor Web.config aplikace před spuštěním aplikace v rozhraní .NET Framework 4 a v iis 7 nebo IIS 7.5. Konkrétní změna, kterou musíte provést, závisí na kombinaci softwaru, se kterým pracujete, včetně verzí Service Pack (SP). Informace o možných kombinacích softwaru ovlivněných touto změnou a o řešení problémů s konkrétními kombinacemi naleznete v části Chyby konfigurace související s novou ASP.NET 4 kořenovou konfigurací v dokumentu ASP.NET 4 Zásadní změny na webu ASP.NET.
Řízení vykreslování	V předchozích verzích ASP.NET některé ovládací prvky vygenerované značky, které nelze zakázat. Ve výchozím nastavení se tento typ kódu už v ASP.NET 4 negeneruje. Změny vykreslování mají vliv na následující ovládací prvky: * Ovládací `ImageImageButton` prvky již nevykreslují `border="0"` atribut. * Ovládací `BaseValidator` prvky třídy a ověřování, které jsou odvozeny od ní, již ve výchozím nastavení nevykreslují červený text. * Ovládací `HtmlForm` prvek nevykreslí `name` atribut. * Ovládací `Table` prvek už nevykreslí `border="0"` atribut. Ovládací prvky, které nejsou určené pro uživatelský vstup (například `Label` ovládací prvek), již nevykreslují `disabled="disabled"` atribut, pokud je jejich `Enabled` vlastnost nastavena `false` (nebo pokud toto nastavení dědí z ovládacího prvku kontejneru).	Pokud pomocí sady Visual Studio upgradujete aplikaci z ASP.NET 2.0 nebo ASP.NET 3.5, nástroj automaticky přidá nastavení do souboru Web.config, který zachovává starší verzi vykreslování. Pokud však upgradujete aplikaci změnou fondu aplikací ve službě IIS na cílovou rozhraní .NET Framework 4, ASP.NET ve výchozím nastavení použije nový režim vykreslování. Pokud chcete zakázat nový režim vykreslování, přidejte do souboru Web.config následující nastavení: `<pages controlRenderingCompatibilityVersion="3.5" />`
Obslužné rutiny událostí ve výchozích dokumentech	ASP.NET 4 vykreslí hodnotu atributu elementu `action` HTML `form` jako prázdný řetězec, pokud je požadavek proveden na adresu URL bez rozšíření, která má výchozí dokument namapovaný na něj. V dřívějších verzích ASP.NET by žádost `http://contoso.com` o Default.aspx byla výsledkem požadavku. V tomto dokumentu by se počáteční `form` značka vykreslovala jako v následujícím příkladu: `<form action="Default.aspx" />` V ASP.NET 4 se požadavek `http://contoso.com` na Default.aspx také zobrazí, ale ASP.NET teď vykresluje počáteční `form` značku HTML jako v následujícím příkladu: `<form action="" />` `action` Pokud je atribut prázdný řetězec, objekt IIS `DefaultDocumentModule` vytvoří podřízený požadavek na Default.aspx. Za většiny podmínek je tento podřízený požadavek transparentní pro kód aplikace a stránka Default.aspx běží normálně. Potenciální interakce mezi spravovaným kódem a integrovaným režimem IIS 7 nebo IIS 7.5 však může způsobit, že spravované .aspx stránky přestanou během podřízeného požadavku správně fungovat. Pokud dojde k následujícím podmínkám, podřízený požadavek na výchozí dokument .aspx způsobí chybu nebo neočekávané chování: * Do prohlížeče se odešle .aspx stránka s atributem elementu `formaction` nastaveným na "". * Formulář se publikuje zpět do ASP.NET. * Spravovaný modul HTTP čte část těla entity, například `Request.Form` .`Request.Params` To způsobí, že tělo entity požadavku POST se načte do spravované paměti. V důsledku toho už tělo entity není k dispozici pro žádné nativní moduly kódu, které běží v integrovaném režimu SLUŽBY IIS 7 nebo IIS 7.5. * Objekt IIS `DefaultDocumentModule` se nakonec spustí a vytvoří podřízený požadavek na dokument Default.aspx. Vzhledem k tomu, že tělo entity už bylo přečteno částí spravovaného kódu, není k dispozici žádné tělo entity, které by bylo možné odeslat podřízené žádosti. * Když se kanál HTTP spustí pro podřízený požadavek, obslužná rutina pro .aspx soubory se spustí během fáze provádění obslužné rutiny. Vzhledem k tomu, že neexistuje žádný text entity, neexistují žádné proměnné formuláře a žádný stav zobrazení. Proto nejsou pro obslužnou rutinu stránky .aspx k dispozici žádné informace, které by měly být vyvolány události (pokud existují). V důsledku toho se žádná z obslužných rutin událostí postback pro ovlivněnou .aspx stránku spustí.	Informace o způsobech řešení problémů, které mohou vzniknout v důsledku této změny, naleznete v tématu "Obslužné rutiny událostí nemusí být vyvolány ve výchozím dokumentu v integrovaném režimu služby IIS 7 nebo IIS 7.5" v dokumentu ASP.NET 4 Zásadní změny na webu ASP.NET.
Algoritmus hash	ASP.NET používá algoritmy šifrování i hash k zabezpečení dat, jako jsou soubory cookie ověřování formulářů a zobrazení stavu. Ve výchozím nastavení ASP.NET 4 používá HMACSHA256 algoritmus pro operace hash u souborů cookie a zobrazení stavu. Starší verze ASP.NET používaly starší HMACSHA1 algoritmus.	Pokud spouštíte aplikace, které kombinují ASP.NET 2.0 a ASP.NET 4, kde data, jako jsou soubory cookie ověřování formulářů, musí fungovat ve verzích rozhraní .NET Framework, nakonfigurujte webovou aplikaci ASP.NET 4 tak, aby používala starší HMACSHA1 algoritmus přidáním následujícího nastavení do souboru Web.config: `<machineKey validation="SHA1" />`
Hostování ovládacích prvků v Internet Exploreru	V Internet Exploreru už nemůžete hostovat model Windows Forms ovládací prvky, protože existují lepší řešení pro hostování ovládacích prvků na webu. Proto IEHost.dll a IEExec.exe sestavení byla odebrána z rozhraní .NET Framework.	Pro vývoj vlastních ovládacích prvků ve webových aplikacích můžete použít následující technologie: * Můžete vytvořit aplikaci Silverlight a nakonfigurovat ji tak, aby běžela mimo prohlížeč. Další informace najdete v tématu Podpora mimo prohlížeč. * Můžete vytvořit aplikaci prohlížeče XAML (XBAP), abyste mohli využívat možnosti WPF (vyžaduje rozhraní .NET Framework na klientských počítačích). Další informace naleznete v tématu WPF XAML Browser Applications Overview.
Metody HtmlEncode a UrlEncode	Metody `HtmlEncode` a `UrlEncode` metody HttpUtility a HttpServerUtility třídy byly aktualizovány tak, aby kódovaly znak jednoduchých uvozovek (') následujícím způsobem: * Metoda `HtmlEncode` kóduje instance jednoduché uvozovky jako `'` * Metoda `UrlEncode` kóduje instance jednoduché uvozovky jako `%27`	Prozkoumejte kód na místech, kde používáte `HtmlEncode` a `UrlEncode` metody, a ujistěte se, že změna kódování nemá za následek změnu, která by ovlivnila vaši aplikaci.
Chyby HttpException v aplikacích ASP.NET 2.0	Po povolení ASP.NET 4 ve službě IIS 6 můžou ASP.NET aplikace 2.0, které běží ve službě IIS 6 (v systému Windows Server 2003 nebo Windows Server 2003 R2), můžou generovat chyby, jako například: `System.Web.HttpException: Path '/[yourApplicationRoot]/eurl.axd/[Value]' was not found.`	* Pokud ASP.NET 4 není nutné ke spuštění webu, přemapujte web tak, aby místo toho používal ASP.NET 2.0. nebo * Pokud je pro spuštění webu vyžadována ASP.NET 4, přesuňte všechny podřízené ASP.NET virtuální adresáře 2.0 na jiný web mapovaný na ASP.NET 2.0. nebo * Zakažte adresy URL bez rozšíření. Další informace naleznete v tématu "ASP.NET 2.0 Aplikace mohou generovat chyby HttpException, které odkazují na eurl.axd" v dokumentu ASP.NET 4 zásadní změny na webu ASP.NET.
Typy členství	Některé typy (například MembershipProvider) používané ve ASP.NET členství byly přesunuty z System.Web.dll do System.Web.ApplicationServices.dll sestavení. Tyto typy byly přesunuty, aby se vyřešily závislosti vrstvení architektury mezi typy v klientovi a rozšířené skladové položky rozhraní .NET Framework.	Knihovny tříd, které byly upgradovány z dřívějších verzí ASP.NET a které používají typy členství, které byly přesunuty, se nemusí při použití v projektu ASP.NET 4 zkompilovat. Pokud ano, přidejte do projektu knihovny tříd odkaz na System.Web.ApplicationServices.dll.
Změny ovládacího prvku nabídky	Změny výsledku Menu ovládacího prvku v následujícím chování: * Pokud MenuRenderingMode je nastavena na `List`hodnotu , nebo pokud MenuRenderingMode je nastavena `Default` na a ControlRenderingCompatibilityVersion je nastavena `4.0` na nebo novější, PopOutImageUrl vlastnost nemá žádný vliv. * Pokud cesta, která je nastavena v StaticPopOutImageUrl a DynamicPopOutImageUrl vlastnosti obsahuje zpětné lomítko (\), obrázky se nevykreslují. (V dřívějších verzích ASP.NET by cesta mohla obsahovat zpětné lomítko.)	* Místo nastavení PopOutImageUrl vlastnosti pro jednotlivé položky nabídky nastavte StaticPopOutImageUrl nebo DynamicPopOutImageUrl nadřazený Menu ovládací prvek. nebo Nastavte MenuRenderingMode na hodnotu , nebo nastavte ControlRenderingCompatibilityVersion MenuRenderingMode`Default3.5`na hodnotu .`Table` Tato nastavení způsobují, Menu že ovládací prvek použije rozložení založené na tabulce HTML, které se použilo v dřívějších verzích ASP.NET. * Pokud cesta v objektu StaticPopOutImageUrl nebo DynamicPopOutImageUrl vlastnosti obsahuje zpětné lomítko (\), nahraďte znak lomítka (/).
Mobilní sestavení v souboru Web.config	V předchozích verzích ASP.NET byl odkaz na sestavení System.Web.Mobile.dll zahrnutý v kořenovém souboru Web.config v `assemblies` části `system.web`/`compilation`. Kvůli zvýšení výkonu byl odkaz na toto sestavení odebrán. Poznámka: Sestavení System.Web.Mobile.dll a mobilní ovládací prvky ASP.NET jsou součástí ASP.NET 4, ale jsou zastaralé.	Pokud chcete použít typy z tohoto sestavení, přidejte odkaz na sestavení v kořenovém souboru Web.config nebo v souboru Web.config aplikace.
Ukládání výstupu do mezipaměti	V ASP.NET 1.0 způsobila chyba stránky uložené v mezipaměti zadané `Location="ServerAndClient"` jako výstupní nastavení mezipaměti, které v odpovědi vygenerovalo hlavičku `Vary:` HTTP. To mělo vliv na to, že klientským prohlížečům říkáte, aby stránku nikdy neuchovávala místně do mezipaměti. V ASP.NET 1.1 SetOmitVaryStar byla přidána metoda, kterou lze volat, aby bylo možné potlačit `Vary:` záhlaví. Zprávy o chybách však naznačují, že vývojáři neví o stávajícím `SetOmitVaryStar` chování. V ASP.NET 4 se hlavička `Vary:` HTTP už nevygeneruje z odpovědí, které určují následující direktivu: `<%@ OutputCache Location="ServerAndClient" %>` V důsledku toho SetOmitVaryStar už není metoda potřebná k potlačení hlavičky `Vary:` . V aplikacích, které pro `Location` atribut zadávají "ServerAndClient", budou stránky uloženy v mezipaměti v prohlížeči, aniž by bylo nutné volat SetOmitVaryStar.	Pokud stránky v aplikaci musí generovat `Vary:`, zavolejte metodu AppendHeader , jak je znázorněno v následujícím příkladu: `System.Web.HttpResponse.AppendHeader("Vary","");` Případně můžete změnit hodnotu atributu ukládání výstupu do mezipaměti `Location` na "Server".
Analýza stránky	Analyzátor stránek pro webové stránky ASP.NET (soubory .aspx) a uživatelských ovládacích prvků (soubory .ascx) je v ASP.NET 4 přísnější než v dřívějších verzích ASP.NET a označí více značek jako neplatné než v předchozích verzích.	Zkontrolujte chybové zprávy, které se vytvoří při spuštění stránky, a opravte chyby, které jsou výsledkem neplatného kódu.
Typy passportů	Podpora Passportu integrovaná do ASP.NET 2.0 je zastaralá a nepodporuje se kvůli změnám v Passportu (teď Live ID SDK). V důsledku toho jsou teď typy související s Passportem System.Web.Security označené atributem `ObsoleteAttribute` .	Změňte veškerý kód, který používá typy Passportu v System.Web.Security oboru názvů (například) tak, PassportIdentityaby používal sadu Windows Live ID SDK.
Informace PathInfo ve vlastnosti FilePath	ASP.NET 4 již neobsahuje `PathInfo` hodnotu ve vrácených hodnotách z vlastností, jako FilePathje , AppRelativeCurrentExecutionFilePatha CurrentExecutionFilePath. `PathInfo` Místo toho jsou informace k dispozici v PathInfosouboru . Představte si například následující fragment adresy URL: `/testapp/Action.mvc/SomeAction` Ve starších verzích ASP.NET HttpRequest mají vlastnosti následující hodnoty: * FilePath: `/testapp/Action.mvc/SomeAction` * PathInfo: (prázdné) V ASP.NET 4 mají HttpRequest vlastnosti místo toho následující hodnoty: * FilePath: `/testapp/Action.mvc` * PathInfo: `SomeAction`	Prozkoumejte kód na místech, kde spoléháte na vlastnosti HttpRequest třídy k vrácení informací o cestě. Změňte kód tak, aby odrážel změny ve způsobu vrácení informací o cestě.
Ověření požadavku	K vylepšení ověřování požadavků se ASP.NET ověření žádosti vyvolá dříve v životním cyklu požadavku. V důsledku toho se ověření požadavku spustí pro žádosti, které nejsou určené pro .aspx soubory, jako jsou volání webové služby a vlastní obslužné rutiny. Ověření požadavku bude aktivní také při spuštění vlastních modulů HTTP v kanálu zpracování požadavků. V důsledku této změny můžou žádosti o jiné prostředky než .aspx soubory vyvolat chyby ověření požadavku. Vlastní kód, který se spouští v kanálu požadavku (například vlastní moduly HTTP), může také vyvolat chyby ověření požadavku.	V případě potřeby se můžete vrátit k původnímu chování, když máte pouze .aspx stránky, které aktivují ověření požadavku, pomocí následujícího nastavení v konfiguračním souboru webu: `<httpRuntime requestValidationMode="2.0" />` Upozornění: Pokud se vrátíte ke starému chování, ujistěte se, že veškerý kód v existujících obslužných rutinách, modulech a dalším vlastním kódu provádí kontroly potenciálně nebezpečných vstupů HTTP, které by mohly být vektory útoku XSS.
Směrování	Pokud vytvoříte web systému souborů v sadě Visual Studio 2010 a web je ve složce, která obsahuje tečku (.) v názvu složky, směrování adres URL nebude spolehlivě fungovat. Z některých virtuálních cest se vrátí chyba HTTP 404. K tomu dochází, protože Visual Studio 2010 spustí Vývojový server sady Visual Studio pomocí nesprávné cesty pro kořenový virtuální adresář.	* Na stránce Vlastnosti pro souborový web změňte atribut Virtuální cesta na /. nebo * Místo projektu webu vytvořte projekt webové aplikace. Projekty webových aplikací tento problém nemají a směrování adres URL funguje i v případě, že má složka projektu tečku v názvu. nebo * Vytvořte web založený na protokolu HTTP, který je hostovaný ve službě IIS. Weby hostované službou IIS můžou mít ve virtuální cestě i ve složce souboru projektu tečky.
Weby SharePoint	Pokud se pokusíte spustit web ASP.NET 4 nasazený jako podřízený web služby SharePoint, který obsahuje vlastní úroveň důvěryhodnosti s názvem `WSS_Minimal`částečné důvěryhodnosti, zobrazí se následující chyba: `Could not find permission set named 'ASP.Net'.`	V současné době nejsou žádné verze SharePointu kompatibilní s ASP.NET. V důsledku toho byste se neměli pokoušet spustit web ASP.NET 4 jako podřízený web služby SharePoint.
Standardy XHTML 1.1	Chcete-li povolit dodržování předpisů XHTML 1.1 pro nové weby, ASP.NET ovládací prvky v rozhraní .NET Framework 4 vygenerují kód HTML kompatibilní s XHTML 1.1. Toto vykreslování je povoleno pomocí následující možnosti v souboru Web.config uvnitř elementu `<system.Web>` : `<pages controlRenderingCompatibilityVersion="4.0"/>` Tato možnost je ve výchozím nastavení nastavená na hodnotu 4.0. Webové projekty upgradované ze sady Visual Studio 2008 mají povolené nastavení 3.5 pro zajištění kompatibility.	Nezaokrouhlovat.

Základ