Potíže s migrací rozhraní .NET Framework 4

Článek
08/01/2011

Toto téma popisuje problémy s migrací mezi .NET Framework verze 3.5 Service Pack 1 a .NET Framework verze 4, včetně oprav, změn ve shodě s normami a v zabezpečení a změn na základě zpětné vazby od zákazníků. Většina těchto změn nevyžaduje žádné programové změny v aplikacích. Informace o těch, které mohou zahrnovat změny, naleznete v tabulce ve sloupci Doporučené změny.

Toto téma popisuje důležité změny v následujících oblastech:

Technologie ASP.NET a web
Jádro
Data
Windows Communication Foundation (WCF)
Windows Presentation Foundation (WPF)
jazyk XML

Přehled problematiky v tomto tématu na vyšší úrovni najdete v části Průvodce migrací do rozhraní .NET Framework 4.

Informace o migraci po verzi Beta 2 najdete v části Otázky ohledně migrace pro aplikace rozhraní .NET Framework 4: Beta 2 na RTM.

Informace o nových vlastnostech naleznete v tématu Novinky v rozhraní .NET Framework 4.

Technologie ASP.NET a web

Obory názvů: System.Web, System.Web.Mobile, System.Web.Security, System.Web.UI.WebControls; sestavení: System.Web (v knihovně System.Web.dll)

Funkce	Rozdíly od 3.5 SP1	Doporučené změny
Soubory definic prohlížečů	Soubory definice prohlížeče byly aktualizovány, aby obsahovaly informace o nových a aktualizovaných prohlížečích a zařízeních. Starší prohlížeče a zařízení, například Netscape Navigator, byly odstraněny a novější prohlížeče a zařízení, jako jsou aplikace Google Chrome a Apple iPhone, byly přidány. Pokud vaše aplikace obsahuje vlastní definice prohlížeče, které dědí z jedné z definic prohlížečů, které byly odebrány, zobrazí se chyba. Objekt HttpBrowserCapabilities (který je vystaven vlastností Request.Browser stránky) je řízen soubory definic prohlížeče. Proto se může informace, která je vrácena po přístupu k vlastnosti tohoto objektu v technologii ASP.NET 4, lišit od informace, která byla vrácena v předchozí verzi technologie ASP.NET.	Pokud vaše aplikace spoléhá na staré soubory definic prohlíž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 webu http://www.asp. net/mobilehttps://go.microsoft.com/fwlink/?LinkId=182900.
Podřízená aplikace spuštěná v kombinovaných verzích technologie ASP.NET	Aplikace ASP.NET 4, které jsou nakonfigurovány jako podřízené hodnoty aplikací používajících dřívější verze technologie ASP.NET, se nemusí spustit kvůli chybám konfigurace nebo kompilace. Konkrétní chyby, ke kterým dochází, závisí na tom, zda aplikace běží ve verzi IIS 6.0, IIS 7 nebo IIS 7.5.	Můžete provádět změny konfiguračních souborů ovlivněných aplikací, aby konfigurační systém správně rozpoznal aplikaci technologie ASP.NET 4. Informace o změnách, které je třeba provést, naleznete v oddílu „Podřízené aplikace technologie ASP.NET 4 nelze spustit při provozu v aplikacích technologie ASP.NET 2.0 nebo ASP.NET 3.5“ v dokumentu ASP.NET 4 – nejnovější změny na webu ASP.NET.
Změny ID klienta	Nové nastavení ClientIDMode v prostředí ASP.NET 4 umožňuje určit, jak prostředí ASP.NET generuje atribut id pro elementy HTML. V dřívějších verzích technologie ASP.NET výchozí chování odpovídalo nastavení AutoID elementu ClientIDMode. Výchozí nastavení je nyní Predictable. Další informace naleznete v tématu Identifikace ovládacích prvků technologie ASP.NET.	Pokud použijete sadu Visual Studio 2010 k upgradu vaší aplikace z technologie ASP.NET 2.0 nebo ASP.NET 3.5, nástroj automaticky přidá do souboru Web.config nastavení, které zachovává chování starších verzí rozhraní .NET Framework. Nicméně pokud upgradujete aplikaci změnou fondu aplikací ve službě IIS tak, aby bylo cílem rozhraní .NET Framework 4, technologie ASP.NET bude standardně používat nový režim. Chcete-li 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 NET technologie ASP.NET 2.0 NET, které byly přidány do technologie ASP.NET 3.5, používají model CAS (Code Access Security) rozhraní .NET Framework 1.1 a .NET Framework 2.0. Nicméně implementace modelu CAS v technologii ASP.NET 4 byla podstatně reorganizována. V důsledku toho se nemusí zdařit aplikace částečné důvěryhodnosti ASP.NET, které spoléhají na důvěryhodný kód spuštěný v globální mezipaměti sestavení s různými výjimkami zabezpečení. Aplikace s částečnou důvěryhodností, které závisí na rozsáhlých úpravách zásady počítače CAS, mohou také selhat a zapříčinit tak výjimky zabezpečení.	Aplikace s částečnou důvěryhodností technologie ASP.NET 4 můžete vrátit na chování technologie ASP.NET 1.1 a 2.0 pomocí nového atributu legacyCasModel v konfiguračním elementu trust, jak je znázorněno v následujícím příkladu: <trust level= "Medium" legacyCasModel="true" /> Poznámka k zabezpečení Návrat ke staršímu modelu CAS může představovat snížení bezpečnosti. Další informace o novém modelu kódovaného zabezpečení přístupu technologie ASP.NET 4 najdete v části Zabezpečení přístupu ke kódu v aplikacích ASP.NET.
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, aby zahrnovaly většinu často používaných informací o konfiguraci, které byly nalezeny v souborech Web.config aplikace ve verzi ASP.NET 3.5. Z důvodu složitosti spravovaných systémů konfigurace služby IIS 7 a IIS 7.5, spuštění aplikací ASP.NET 3.5 v technologii ASP.NET 4 a službě IIS 7 a IIS 7.5 může mít za následek chyby rozhraní ASP.NET nebo služby IIS.	Upgrade aplikací technologie ASP.NET 3.5 na technologii ASP.NET 4 pomocí nástrojů pro upgrade projektů v aplikaci Visual Studio 2010. Aplikace Visual Studio 2010 automaticky upraví soubor Web.config aplikace technologie ASP.NET 3.5, aby obsahoval příslušná nastavení pro technologii ASP.NET 4. Aplikace technologie ASP.NET 3.5 používající rozhraní .NET Framework 4 lze však spustit bez rekompilace. V takovém případě může být před spuštěním aplikace v rozhraní .NET Framework 4 a ve službě IIS 7 nebo IIS 7.5 nutné ručně upravit soubor Web.config aplikace. Konkrétní změny, které je třeba provést, závisí na kombinaci softwaru, se kterým pracujete, včetně vydání aktualizací Service Pack (SP). Informace o možných kombinacích softwaru, které jsou postiženy touto změnou, a o řešení problémů s konkrétními kombinacemi naleznete v části „Konfigurační chyby související s novou kořenovou konfigurací technologie ASP.NET 4“ v dokumentu ASP.NET 4 – nejnovější změny na webu ASP.NET.
Vykreslování ovládacího prvku	V dřívějších verzích technologie ASP.NET některé ovládací prvky vytvářely značky, které nebylo možné zakázat. Ve výchozím nastavení již tento typ značky nebude vygenerována v technologii ASP.NET 4. Změny vykreslování ovlivňují následující ovládací prvky: Ovládací prvek Image a ImageButton již nevykresluje atribut border="0". Třída BaseValidator a ovládací prvky ověřování, které jsou z ní odvozeny, již nebudou ve výchozím nastavení vykreslovat červený text. Ovládací prvek HtmlForm nevykreslí atribut name. Ovládací prvek Table již vykresluje atribut border="0". Ovládací prvky, které nejsou navrženy pro uživatelský vstup (například ovládací prvek Label) již nevykreslují atribut disabled="disabled", pokud je jeho vlastnost Enabled nastavena na hodnotu false (nebo pokud dědí toto nastavení z ovládacího prvku kontejneru).	Pokud použijete sadu Visual Studio 2010 k upgradu vaší aplikace z technologie ASP.NET 2.0 nebo ASP.NET 3.5, nástroj automaticky přidá do souboru Web.config nastavení, které zachovává starší vykreslování. Nicméně pokud upgradujete aplikaci změnou fondu aplikací ve službě IIS tak, aby bylo cílem rozhraní .NET Framework 4, technologie ASP.NET bude standardně používat nový režim vykreslování. Chcete-li 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	Technologie ASP.NET 4 vykreslí hodnotu atributu HTML form elementu action jako prázdný řetězec, když je proveden požadavek na adresu URL bez přípony, na kterou je napamován výchozí dokument. V dřívějších verzích technologie ASP.NET by měla žádost na adresu https://contoso.com za výsledek žádost na stránku Default.aspx. V tomto dokumentu by počáteční značka form byla vykreslena jako v následujícím příkladu: <form action="Default.aspx" /> V technologii ASP.NET 4 má žádost na adresu https://contoso.com za výsledek také žádost o stránku Default.aspx, ale technologie ASP.NET nyní vykresluje počáteční značku form protokolu HTML tak, jako v následujícím příkladu: <form action="" /> Když je atribut action prázdným řetězcem, objekt DefaultDocumentModule služby IIS vytvoří podřízenou žádost na stránku Default.aspx. Za většiny podmínek je tato podřízená žádost 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 služby IIS 7 nebo IIS 7.5 však může způsobit, že spravované stránky .aspx přestane fungovat správně při podřízeném požadavku. Pokud nastanou následující podmínky, podřízená žádost na výchozí dokument ASPX způsobí chybu nebo neočekávané chování: Stránka ASPX je odeslána do prohlížeče s atributem form elementu action nastaveným na hodnotu "". Formulář je odeslán zpět do prostředí ASP.NET. Spravovaný modul HTTP čte určitou část těla entity, jako například Request.Form nebo Request.Params. To způsobí, že se tělo entity žádosti POST načte do spravované paměti. V důsledku toho není obsah entity nadále k dispozici pro jakékoli moduly nativního kódu modulů, které jsou spuštěny v režimu služby IIS 7 nebo v integrovaném režimu služby IIS 7.5. Objekt IIS DefaultDocumentModule se nakonec spustí a vytvoří podřízený požadavek na dokument Default.aspx. Protože však již bylo tělo entity přečteno kusem spravovaného kódu, není k dispozici žádné tělo entity k odeslání k podřízenému požadavku. Když je kanál HTTP spuštěn pro podřízený požadavek, obslužná rutina pro soubory .aspx se spustí během fáze spuštění obslužné rutiny. Protože neexistuje žádný obsah entity, neexistují žádné proměnné formuláře a žádný stav zobrazení. Proto nejsou pro obsluhu stránky .aspx k dispozici žádné informace určující, k jaké události má dojít (pokud vůbec). V důsledku toho není spuštěna žádná z obslužných rutin události zpětného odeslání pro postiženou stránku ASPX.	Informace o způsobech řešení problémů, které mohou vznikat v důsledku této změny naleznete v části „Obslužné rutiny událostí nemusí být ve výchozím dokumentu v integrovaném režimu služby IIS 7 nebo IIS 7.5 neaktivní“ v dokumentu ASP.NET 4 Breaking Changes na webu ASP.NET.
Algoritmus hash	Technologie ASP.NET využívá šifrování a algoritmy hash na pomoc se zabezpečením dat, jako jsou soubory cookie ověřování formulářů a stav zobrazení. Ve výchozím nastavení technologie ASP.NET 4 používá algoritmus HMACSHA256 pro operace algoritmu hash v souborech cookie a stavu zobrazení. Dřívější verze technologie ASP.NET používaly starší algoritmus HMACSHA1.	Pokud spouštíte aplikace kombinující technologie ASP.NET 2.0 a ASP.NET 4, ve kterých data jako soubory cookie ověřování pomocí formulářů musí fungovat mezi verzemi rozhraní .NET Framework, nakonfigurujte webovou aplikaci technologie ASP.NET 4 pro použití staršího algoritmu HMACSHA1 přidáním následujícího nastavení do souboru Web.config: <machineKey validation="SHA1" />
Hostování ovládacích prvků v aplikaci Internet Explorer	Již nemůžete hostit ovládací prvky formulářů systému Windows v aplikaci Internet Explorer, protože existují lepší řešení pro hostování ovládacích prvků na webu. Sestavení IEHost.dll a IEExec.exe byly tedy odebrány z prostředí .NET Framework.	Pro vývoj vlastního ovládacího prvku ve webových aplikacích můžete použít následující technologie: Můžete vytvořit aplikaci Silverlight a nakonfigurovat ji pro spuštění mimo prohlížeč. Další informace naleznete v tématu Out-of-Browser Support. Můžete vytvořit aplikaci prohlížeče XAML (XBAP) využívat schopností WPF (vyžaduje rozhraní .NET Framework na klientských počítačích). Další informace naleznete v tématu Windows Presentation Foundation XAML Browser Applications Overview.
Metody HtmlEncode a UrlEncode	Metody HtmlEncode a UrlEncode tříd HttpUtility a HttpServerUtility byly aktualizovány, aby mohly provádět kódování znaku jednoduché uvozovky ('), a to takto: Metoda HtmlEncode kóduje instance jednoduchých uvozovek jako ' Metoda UrlEncode kóduje instance jednoduchou uvozovku jako %27.	Zkontrolujte místa v kódu, kde používáte metody HtmlEncode a UrlEncode, a ujistěte se, že změna kódování nemá za následek změnu, která by mohla ovlivnit vaši aplikaci.
Chyby HttpException v aplikacích technologie ASP.NET 2.0	Po povolení technologie ASP.NET 4 ve službě IIS 6 mohou aplikace ASP.NET 2.0, které jsou spouštěny ve službě IIS 6 (v systému Windows Server 2003 nebo Windows Server 2003 R2), generovat chyby, například následující: System.Web.HttpException: Path '/[yourApplicationRoot]/eurl.axd/[Value]' was not found.	Pokud technologie ASP.NET 4 není pro funkci webu nutná, přemapujte web pro použití technologie ASP.NET 2.0. -nebo- Pokud je technologie ASP.NET 4 nutná pro funkci webu, přesuňte všechny podřízené virtuální adresáře ASP.NET 2.0 na jiný web, který je namapován na technologii ASP.NET 2.0. -nebo- Zakažte adresy URL bez přípony. Další informace naleznete v části „Aplikace technologie ASP.NET 2.0 mohou generovat chyby HttpException odkazující na soubor eurl.axd“ v dokumentu ASP.NET 4 – nejnovější změny na webu ASP.NET.
Typy členství	Některé typy (například System.Web.Security.MembershipProvider), které se používají v členství ASP.NET, byly přesunuty ze sestavení System.Web.dll do sestavení System.Web.ApplicationServices.dll. Typy byly přesunuty za účelem vyřešení závislostí architektonických vrstev mezi typy v klientovi a v rozšířených SKU rozhraní .NET Framework.	Knihovny třídy, které byly upgradovány z dřívějších verzí technologie ASP.NET a které používají typy členství, které byly přesunuty, se nemusí podařit kompilovat při použití v projektu ASP.NET 4. Pokud ano, přidejte do projektu knihovny tříd odkaz na soubor System.Web.ApplicationServices.dll.
Změny ovládání nabídky	Změny ovládacího prvku Menu mají za následek následující chování: Pokud je vlastnost System.Web.UI.WebControls.MenuRenderingMode nastavena na hodnotu List nebo vlastnost System.Web.UI.WebControls.MenuRenderingMode nastavena na hodnotu Default a vlastnost PagesSection.ControlRenderingCompatibilityVersion na hodnotu 4.0 nebo vyšší, vlastnost MenuItem.PopOutImageUrl nemá žádný účinek. Pokud cesta nastavená ve vlastnostech Menu.StaticPopOutImageUrl a Menu.DynamicPopOutImageUrl obsahuje zpětné lomítko (\), obrázky nebudou vykresleny. (V dřívějších verzích prostředí ASP.NET cesta pravděpodobně obsahovala zpětné lomítko.)	Namísto nastavení vlastnosti MenuItem.PopOutImageUrl pro jednotlivé položky nabídky nastavte vlastnost Menu.StaticPopOutImageUrl nebo Menu.DynamicPopOutImageUrl nadřazeného ovládacího prvku System.Web.UI.WebControls.Menu. -nebo- Nastavte možnost System.Web.UI.WebControls.MenuRenderingMode na Table, nebo nastavte možnost System.Web.UI.WebControls.MenuRenderingMode na Default a nastavte možnost PagesSection.ControlRenderingCompatibilityVersion na 3.5. Tato nastavení způsobí, že ovládací prvek Menu použije rozložení HTML založené na tabulce, které bylo použito v předchozích verzích technologie ASP.NET. Pokud cesta ve vlastnosti Menu.StaticPopOutImageUrl nebo Menu.DynamicPopOutImageUrl obsahuje zpětné lomítko (\), nahraďte jej znakem lomítka (/).
Mobilní sestavení v souboru Web.config	V dřívějších verzích technologie ASP.NET, byl v kořenovém souboru Web.config v části assemblies v oddílu system.web/compilation zahrnut odkaz na sestavení System.Web.Mobile.dll. Pro účely zlepšení výkonu byl odebrán odkaz na tohoto sestavení. Poznámka Sestavení System.Web.Mobile.dll a mobilní ovládací prvky ASP.NET jsou součástí prostředí ASP.NET 4, ale jsou zastaralé.	Chcete-li 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	Chyba v technologii ASP.NET 1.0 způsobovala, že stránky v mezipaměti, které určily jako nastavení výstupní mezipaměti hodnotu Location="ServerAndClient", vytvářely v odpovědi hlavičky protokolu HTTP Vary:. To mělo za následek předání informace prohlížečům klientů, aby se stránky nikdy lokálně neukládaly do mezipaměti. V technologii ASP.NET 1.1, byla přidána metoda HttpCachePolicy.SetOmitVaryStar, která mohla být volána za účelem potlačení hlavičky Vary:. Hlášení o chybách ale naznačují, že vývojáři si nejsou vědomi existujícího chování SetOmitVaryStar. V technologii ASP.NET 4 již hlavička Vary:* protokolu HTTP není vytvářena z odpovědí, které specifikují následující direktivu: <%@ OutputCache Location="ServerAndClient" %> V důsledku toho již metoda HttpCachePolicy.SetOmitVaryStar není zapotřebí, aby potlačila záhlaví Vary:*. V aplikacích, které určují pro atribut Location hodnotu „ServerAndClient“, bude možné stránky ukládat do mezipaměti v prohlížeči bez nutnosti volání funkce HttpCachePolicy.SetOmitVaryStar.	Pokud stránky v aplikaci musí generovat Vary:, volejte metodu HttpResponse.AppendHeader, jak je znázorněno v následujícím příkladu: HttpResponse.AppendHeader("Vary",""); Alternativně můžete změnit hodnotu atributu ukládání výstupu do mezipaměti Location na hodnotu Server.
Analýza stránek	Analyzátor stránky pro webové stránky ASP.NET (soubory .aspx) a uživatelské ovládací prvky (soubory .ascx) je ve verzi ASP.NET 4 přísnější než v předchozích verzích prostředí ASP.NET a označuje více kódů jako neplatné než v předchozích verzích.	Zkontrolujte chybové zprávy vytvořené při spuštění stránky a opravte chyby vyplývající z neplatné značky.
Typy služby Passport	Podpora služby Passport integrovaná do prostředí ASP.NET 2.0 je zastaralá a není podporována kvůli změnám ve službě Passport (nyní Live ID SDK). V důsledku toho typy vztahující se k účtu služby Passport v System.Web.Security jsou nyní označeny atributem ObsoleteAttribute.	Změňte jakýkoli kód, který používá typy Passport v oboru názvů System.Web.Security (například System.Web.Security.PassportIdentity) k použití Windows Live ID SDK.
Informace PathInfo ve vlastnosti FilePath	Technologie ASP.NET 4 již nezahrnuje hodnotu PathInfo ve vrácených hodnotách z vlastností, jako jsou HttpRequest.FilePath, HttpRequest.AppRelativeCurrentExecutionFilePath a HttpRequest.CurrentExecutionFilePath. Namísto toho je informace PathInfo dostupná v HttpRequest.PathInfo. Představte si například následující fragment adresy URL: /testapp/Action.mvc/SomeAction V dřívějších verzích technologie ASP.NET mají vlastnosti System.Web.HttpRequest následující hodnoty: HttpRequest.FilePath: /testapp/Action.mvc/SomeAction HttpRequest.PathInfo: (prázdný) V technologii ASP.NET 4 mají vlastnosti System.Web.HttpRequest místo toho následující hodnoty: HttpRequest.FilePath: /testapp/Action.mvc HttpRequest.PathInfo: SomeAction	Zkontrolujte místa v kódu, která jsou závislá na vlastnostech třídy System.Web.HttpRequest pro vracení informací o cestě; změňte kód tak, aby odpovídal změnám způsobu vracení informací o cestě.
Ověřování požadavku	Pro účely zlepšení žádosti o ověření je žádost o ověření technologie ASP.NET vyvolána v životním cyklu žádosti dříve. V důsledku toho se spustí požadavek na ověření pro žádosti, které nejsou určeny pro soubory ASPX, například pro volání webové služby a vlastní obslužné rutiny. Ověřování požadavku bude rovněž aktivní, když jsou vlastní moduly protokolu HTTP spuštěny v kanálu zpracování požadavku. V důsledku této změny mohou požadavky na jiné prostředky než soubory ASPX vyvolat chyby ověření požadavku. Vlastní kód, který je spuštěn ve třídě Request Pipeline (například vlastní moduly HTTP) mohou také vrátit chyby ověření požadavku.	Bude-li to nutné, můžete se vrátit ke starému chování, kdy pouze stránky ASPX vyvolávají ověřování žádostí pomocí následujícího nastavení ve webovém konfiguračním souboru: <httpRuntime requestValidationMode="2.0" /> Poznámka k zabezpečení Pokud provádíte vrácení na staré chování, ujistěte se, že veškerý kód v existujících obslužných rutinách, modulech a další vlastní kód provádí vyhledávání potenciálně nebezpečných vstupů HTTP, které by mohly být způsoby útoky XSS.
Směrování	Pokud vytvoříte web v 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í URL nebude fungovat spolehlivě. Chyba HTTP 404 se vrátila z určitých virtuálních cest. Je to způsobeno tím, že aplikace Visual Studio 2010 spustí vývojový server sady Visual Studio (Cassini) pomocí nesprávné cesty pro virtuální kořenový adresář.	Na stránce Vlastnosti pro web založený na souborech změňte atribut Virtuální cesta na "/". -nebo- Vytvořte projekt webové aplikace místo projektu webu. Projekty webové aplikace tento problém nemají a směrování adres URL funguje i v případě, že složka projektu má v názvu tečku. -nebo- Vytvořte web založených na protokolu HTTP, který je hostovaný ve službě IIS. Weby hostované službou IIS mohou obsahovat tečky ve virtuální cestě i ve složce souborů projektu.
Weby SharePoint	Pokud se pokusíte spustit web technologie ASP.NET 4 nasazený jako podřízený webu služby SharePoint, který obsahuje vlastní úroveň částečné důvěryhodnosti s názvem WSS_Minimal, zobrazí se následující chyba: Could not find permission set named 'ASP.Net'.	V současné době nejsou žádné verze služby SharePoint kompatibilní s technologií ASP.NET. V důsledku toho byste se neměli pokoušet o spuštění webu ASP.NET 4 jako podřízeného webu služby SharePoint.
Standardy XHTML 1.1	Aby byl umožněn soulad XHTML 1.1 pro nové weby, ovládací prvky technologie ASP.NET v .NET Framework 4 budou generovat kód XHTML 1.1 kompatibilní s HTML. Toto vykreslování je povoleno pomocí následující možnosti v souboru Web.config: <system.Web> <pages controlRenderingCompatibilityVersion="4.0"/> </system.Web> Tato možnost je standardně nastavena na hodnotu 4.0. Webové projekty, které jsou upgradovány na Visual Studio z Visual Studio 2008 budou mít povoleno nastavení 3.5 pro účely kompatibility.	Žádný

Zpět na začátek

Jádro

Všeobecné funkce

Funkce	Rozdíly od 3.5 SP1	Doporučené změny
služba CardSpace	Služba Windows CardSpace již není zahrnuta v prostředí .NET Framework; je poskytována samostatně.	Stáhněte si službu Windows CardSpace z webu služby Stažení softwaru.
Konfigurační soubory	Byly provedeny opravy ve způsobu přístupu systému .NET Framework ke konfiguračním souborům aplikace.	Pokud se konfigurační soubor vaší aplikace jmenuje Název_aplikace.config, přejmenujte jej na Název_aplikace. exe.config. Přejmenujte například MyApp.config na MyApp.exe.config.
Kompilátor kódu C#	Třídy Compiler, CompilerError a ErrorLevel, které byly v oboru názvů Microsoft.CSharp, již nejsou k dispozici a jejich sestavení (cscompmgd.dll) již není zahrnuto v rozhraní .NET Framework.	Použijte třídu CodeDomProvider a další třídy v oboru názvů System.CodeDom.Compiler. Další informace naleznete v tématu Using the CodeDOM.
Poskytování hostingových služeb (nespravované API)	Pro zlepšení možností hostingových služeb, byly zavrhnuty některá API pro aktivaci hostitelských služeb. Vlastnost souběžného spouštění v procesu povoluje aplikaci načtení a spuštění více verzí rozhraní .NET Framework ve stejném procesu. Například můžete ve stejném procesu spouštět aplikace, které načítají doplňky (nebo komponenty) založené na .NET Framework 2.0 SP1 a doplňky, které jsou založeny na .NET Framework 4. Starší komponenty nadále používají starší verzi rozhraní .NET Framework a nové komponenty používají novou verzi rozhraní .NET Framework.	Použijte konfigurace popsané v proces souběžné spouštění.
Nový model zabezpečení	Zásada zabezpečení přístupu kódu (CAS) byla vypnuta a nahrazena zjednodušeným modelem, jak je popsáno v části Změny zabezpečení v rozhraní .NET Framework 4.	Změny mohou být vyžadovány, pokud jste ve vašich aplikacích závislí na CAS. Další informace naleznete v tématu Kompatibilita a migrace zásad zabezpečení přístupu kódu.

Zpět na začátek

Datum a čas

Obor názvů: System; sestavení: mscorlib (v knihovně mscorlib.dll)

Funkce	Rozdíly od 3.5 SP1	Doporučené změny
Letní čas	Kvůli souladu se systémovými hodinami vlastnosti času (například TimeZoneInfo.Local nebo DateTime.Now) nyní používají pravidla operačního systému pro časové operace letního času místo jiných dat rozhraní .NET Framework.	Žádný
Formátování řetězců	Na podporu formátování, které dodržuje jazykové zvyklosti struktura TimeSpan obsahuje nové přetížení metod ToString, Parse, a TryParse kromě toho, obsahuje nové metody ParseExact a TryParseExact.	Žádný

Zpět na začátek

Globalizace

Seznam nových neutrálních a konkrétních jazykových verzí najdete v části Co je nového v globalizaci a lokalizaci.

Obor názvů: System.Globalization; sestavení: mscorlib (v knihovně mscorlib.dll)

Funkce	Rozdíly od 3.5 SP1	Doporučené změny
Názvy jazykových verzí	Následující změny názvů ovlivňují německé, divehi a africké jazykové verze: CurrencyEnglishName: Název měny pro německou (Švýcarsko) (de-CH) jazykovou verzi se změnil z „sFr.“ na „FN“. LongDatePattern: Dlouhý vzor data jazykové verze Divehi (Maledivy) (dv-MV) se změnil z „dd/MMMM/rrrr“ na „dd/MM/rrrr“. PMDesignator: P.M. označení jazykové verze Afrikánština (Jižní Afrika) (af-ZA) se změnilo z nm na PM.	Všimněte si změn názvů jazykových verzí.
LCID parametr	Kvůli souladu s očekávaným chováním v nastavení automatizačního serveru modul CLR již nepředává aktuální jazykovou verzi pro parametr LCID nespravovaným aplikacím založeným na modelu COM. Namísto toho předává 1033 (en-us) pro jazykovou verzi.	Nejsou nutné žádné úpravy s výjimkou nativních aplikací, které vyžadují specifikovanou jazykovou verzi.
Zastaralé typy jazykových verzí	Typy jazykových verzí FrameworkCultures a WindowsOnlyCultures jsou nyní zastaralé. Z důvodu zpětné kompatibility FrameworkCultures nyní vrací neutrální a specifické jazykové verze, které byly součástí předchozích verzí rozhraní .NET Framework a WindowsOnlyCultures nyní vrací prázdný seznam.	Použije jiné hodnoty výčtu CultureTypes.
Získávání jazykové verze	Počínaje systémem Windows 7 načítá technologie .NET Framework 4 jazykové verze z operačního systému místo uložení vlastních dat. Kromě toho rozhraní .NET Framework se synchronizuje se systémem Windows za účelem řazení a zapouzdření dat.	Žádný
Normy Unicode 5.1	Rozhraní .NET Framework nyní podporuje všechny znaky Unicode 5.1 kromě přibližně 1400 znaků. Další znaky zahrnují nové symboly, šipky, diakritická znaménka, interpunkci, matematické symboly, znaky CJK a ideogramy, další malajámské a telugské číselné znaky, stejně jako různé další znaky barmského písma, latinky, arabštiny, řeckého písma, mongolštiny a cyrilice. Kódování Unicode 5.1 podporuje následující nové skripty: sundánské písmo, lepčské písmo, Ol Chiki, Vai, Saurashtra, Kali, Rejang, gurmuchština, urijština, tamilština, telugština, malajámské znaky a Cham.	Žádný

Zpět na začátek

Výjimky

Obory názvů: System, System.Runtime.ExceptionServices; sestavení: mscorlib (v knihovně mscorlib.dll)

Funkce	Rozdíly od 3.5 SP1	Doporučené změny
Výjimky pro poškozený stav procesu	CLR již dodává výjimky pro poškozený stav procesu do obslužných rutin výjimek ve spravovaném kódu.	Tyto výjimky ukazují, že stav procesu byl poškozen. Nedoporučujeme spouštět aplikaci v tomto stavu. Další informace naleznete v části HandleProcessCorruptedStateExceptionsAttribute a položce Zpracování výjimek v poškozeném stavu v blogu CLR Inside Out.
Vyjímky stroje pro spouštění	ExecutionEngineException je nyní zastaralý, protože zachytitelná výjimka umožní spouštění nestabilního procesu. Tato změna zvyšuje předvídatelnost a spolehlivost v modulu runtime.	Použijte možnost InvalidOperationException k signalizaci stavu.

Výjimky pro poškozený stav procesu

CLR již dodává výjimky pro poškozený stav procesu do obslužných rutin výjimek ve spravovaném kódu.

Tyto výjimky ukazují, že stav procesu byl poškozen. Nedoporučujeme spouštět aplikaci v tomto stavu.

Další informace naleznete v části HandleProcessCorruptedStateExceptionsAttribute a položce Zpracování výjimek v poškozeném stavu v blogu CLR Inside Out.

Vyjímky stroje pro spouštění

ExecutionEngineException je nyní zastaralý, protože zachytitelná výjimka umožní spouštění nestabilního procesu. Tato změna zvyšuje předvídatelnost a spolehlivost v modulu runtime.

Použijte možnost InvalidOperationException k signalizaci stavu.

Zpět na začátek

Reflexe

Obor názvů: System.Reflection; sestavení: mscorlib (v knihovně mscorlib.dll)

Funkce	Rozdíly od 3.5 SP1	Doporučené změny
Hash algoritmy pro sestavení	Vlastnost AssemblyName.HashAlgorithm nyní vrátí hodnotu AssemblyHashAlgorithm.None, protože běh nezná algoritmus hash z odkazovaného sestavení při načtení sestavení. (Tato položka odkazuje na použití vlastnosti v odkazované sestavě, jako je například ta, která byla vrácena metodou Assembly.GetReferencedAssemblies.)	Žádný
Načítání sestavení	Aby se zabránilo redundantnímu načítání sestavení a aby byl uložen virtuální adresový prostor, CLR nyní načte sestavení pouze pomocí funkce Win32 MapViewOfFile. Nadále nevolá funkci LoadLibrary. Tato změna ovlivní diagnostické aplikace v následujících ohledech: ProcessModuleCollection nebude nadále obsahovat všechny moduly z knihovny tříd (.dll soubor) získané z volání Process.GetCurrentProcess().Modules. Aplikace Win32, které používají funkci EnumProcessModules nezobrazí všechny spravované moduly, které jsou uvedeny.	Žádný
Deklarování typu	Vlastnost Type.DeclaringType nyní správně vrátí hodnotu null, pokud typ nemá deklarující typ.	Žádný
Delegáti	Delegování nyní zahodí výjimku ArgumentNullException místo NullReferenceException, když je do konstruktoru delegáta předána hodnota null.	Zajistit, že jakékoli zpracování výjimky zachytí ArgumentNullException.
Změna umístění globální mezipaměti sestavení (GAC)	Pro sestavení rozhraní .NET Framework 4 byla globální mezipaměť sestavení přesunuta z adresáře systému Windows (%WINDIR%) do podadresáře Microsoft.Net (%WINDIR%\Microsoft.Net). Sestavení z dřívějších verzí zůstanou ve starším adresáři. Nespravovaný výčet ASM_CACHE_FLAGS obsahuje nový příznak ASM_CACHE_ROOT_EX. Tento příznak získá umístění mezipaměti pro sestavení .NET Framework 4, které lze získat pomocí funkce GetCachePath.	Žádné, za předpokladu, že aplikace nepoužívají explicitní cesty k sestavením, což není doporučený postup.
Nástroj globální mezipaměti sestavení	Gacutil.exe (Global Assembly Cache Tool) již nepodporuje prohlížeč zásuvných modulů.	Žádný

Vzájemná spolupráce

Obor názvů: System.Runtime.InteropServices; sestavení: mscorlib (v knihovně mscorlib.dll)

Funkce	Rozdíly od 3.5 SP1	Doporučené změny
Velikost vyrovnávací paměti (nespravované API)	Z důvodu úspory paměti byla funkce parametru pBufferLengthOffset pro metodu ICorProfilerInfo2::GetStringLayout změněna tak, že je shodná s parametrem pStringLengthOffset. Oba parametry nyní směřují na místo posunu délky řetězce. Velikost vyrovnávací paměti byla odebrána z reprezentace třídy řetězce.	Odebrat všechny závislosti na velikost vyrovnávací paměti.
Ladění JIT	Ladicí program rozhraní .NET Framework pro zjednodušení registrace pro JIT ladění nyní používá pouze klíč registru AeDebug, který řídí chování JIT ladění pro nativní kód. Výsledky této změny jsou následující: Již není nutné registrovat dva odlišné ladící programy, jeden pro spravovaný a jeden pro nativní kód. Nadále již není nutné spouštět ladicí program automaticky pro neinteraktivní proces, ale je možné vyzvat uživatele k interaktivnímu procesu. Již nebudete upozorňování, když se spuštění ladicího programu nezdaří, nebo když není registrován ladící program, který by měl být spuštěn. Automaticky spouštěné zásady, které závisí na interaktivitě aplikace již nejsou podporovány.	Nastavte operace ladění podle potřeby.
Volání nespravovaného kódu	Pro zvýšení výkonu ve vzájemné funkční spolupráci s nespravovaným kódem všechna nesprávná volání konvencí ve volání nespravovaného kódu nyní způsobí selhání aplikace. V dřívejších verzích tyto chyby řešila vrstva na logicky vyšší úrovni.	Ladění aplikací ve službě Microsoft Visual Studio 2010 vás na tyto chyby upozorní, takže je můžete opravit. Používáte-li binární soubory, které nelze aktualizovat, můžete zahrnout element <NetFx40_PInvokeStackResilience> do konfiguračního souboru aplikace pro povolení volání řešení chyb do zásobníku jako v předchozích verzích. Nicméně může dojít k ovlivnění výkonu vaší aplikace.
Odebraná rozhraní (nespravované API)	Aby se zabránilo zmatení vývojářů, byla odebrána následující rozhraní, protože neposkytla žádné užitečné scénáře doby běhu a modul CLR neposkytl ani neakceptoval jakékoli implementace: INativeImageINativeImageDependency INativeImageInstallInfo INativeImageEvaluate INativeImageConverter ICorModule IMetaDataConverter	Žádný

Zpět na začátek

Data

Tato část popisuje problémy s migrací pro používání datových sad a klientů SQL, rozhraní Entity Framework, LINQ to SQL a datových serverů WCF (dříve známých jako datové služby ADO.NET).