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

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é změny programování ve vašich aplikacích. U těch, které můžou zahrnovat úpravy, najdete ve sloupci Doporučené změny tabulky. Významné 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)

Vlastnost	Rozdíly od verze 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 iPhone. 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 řádkuAspnet_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, najdete v sekci "Podřízené aplikace ASP.NET 4 se nespustí, když běží pod aplikacemi ASP.NET 2.0 nebo ASP.NET 3.5" 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í k nastavení `AutoIDclientIDMode`. 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)	Funkce ASP.NET 2.0, které byly přidány 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 mohou částečně důvěryhodné aplikace ASP.NET, které spoléhají na důvěryhodný kód běžící v globální mezipaměti sestavení, selhat kvůli různým výjimkám zabezpečení. Částečně důvěryhodné aplikace, které spoléhají na rozsáhlé úpravy zásad CAS počítače, mohou 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 aplikace Web.config 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 před spuštěním aplikace v rozhraní .NET Framework 4 a ve službě IIS 7 nebo IIS 7.5 ručně upravit soubor Web.config aplikace. 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 vygenerovaly značky, které jste nemohli vypnout. 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í prvky `Image` a `ImageButton` již nevykreslují atribut `border="0"`. * Třída `BaseValidator` a ovládací prvky pro ověřování, které jsou z ní odvozeny, již ve výchozím nastavení nevykreslují červený text. * Ovládací prvek `HtmlForm` nevykreslí atribut `name`. * Ovládací prvek `Table` už nevykresluje atribut `border="0"`. 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 `form` HTML `action` 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 vedla žádost na `http://contoso.com` k požadavku na Default.aspx. 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 požadavek na `http://contoso.com` také vede k požadavku na Default.aspx, ale ASP.NET nyní vykresluje otevírací značku HTML `form` 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ý program pro .aspx soubory se spustí během fáze spuštění obslužného programu. Vzhledem k tomu, že neexistuje žádné tělo entity, neexistují žádné proměnné formuláře a ani žádný stav zobrazení. Proto nejsou pro obslužnou rutinu stránky .aspx k dispozici žádné informace, které by určily, jaká událost (pokud vůbec nějaká) má být vyvolána. V důsledku toho se nespustí žádná z obslužných rutin událostí postback pro ovlivněnou stránku .aspx.	Informace o způsobech práce s problémy, 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.
Hashovací algoritmus	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 napříč verzemi 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 ovládací prvky Windows Forms, protože existují lepší řešení pro hostování ovládacích prvků na webu. Proto IEHost.dll a IEExec.exe sestavení byly odebrány 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` tříd HttpUtility a HttpServerUtility byly aktualizovány k tomu, 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é v členství ASP.NET byly přesunuty ze sestavení System.Web.dll do sestavení System.Web.ApplicationServices.dll. Tyto typy byly přesunuty, aby se vyřešily závislosti ve vrstvení architektury mezi typy v klientu a rozšířených verzích 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ádání nabídky	Změny ovládacího prvku Menu vycházejí z následujícího chování: * Pokud je MenuRenderingMode nastavena na `List`, nebo pokud je MenuRenderingMode nastavena na `Default` a ControlRenderingCompatibilityVersion je nastavena na `4.0` nebo na pozdější, PopOutImageUrl nemá žádný účinek. * 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í vlastnosti PopOutImageUrl u jednotlivých položek nabídky nastavte vlastnost StaticPopOutImageUrl nebo DynamicPopOutImageUrl u nadřazeného ovládacího prvku Menu. nebo Nastavte MenuRenderingMode na `Table`, nebo nastavte MenuRenderingMode na `Default` a nastavte ControlRenderingCompatibilityVersion na `3.5`. 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 ve vlastnosti objektu StaticPopOutImageUrl nebo DynamicPopOutImageUrl obsahuje zpětné lomítko (\), nahraďte lomítko (/).
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 Web.config souboru 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 Web.config souboru nebo v aplikaci Web.config souboru.
Ukládání výstupu do mezipaměti	V ASP.NET 1.0 způsobila chyba, že stránky uložené v mezipaměti, které specifikovaly `Location="ServerAndClient"` jako nastavení mezipaměti, generovaly HTTP hlavičku `Vary:` v odpovědi. 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 byla přidána metoda SetOmitVaryStar, kterou lze volat k potlačení `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 už metoda SetOmitVaryStar není potřeba 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 PassportIdentity), aby používal sadu Windows Live ID SDK.
Informace „PathInfo“ ve vlastnosti „FilePath“	ASP.NET 4 již neobsahuje hodnotu `PathInfo` ve vrácených hodnotách z vlastností, jako jsou FilePath, AppRelativeCurrentExecutionFilePath a CurrentExecutionFilePath. Místo toho jsou informace k dispozici v `PathInfo`. 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 `Virtual Path` atribut 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.
Sharepointové weby	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 povolené 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.	Žádné.

Základ