.NET-keretrendszer 4 migrálási probléma

Ez a cikk a .NET-keretrendszer 3.5 Service Pack 1-es és 4-es verziójának migrálási problémáit ismerteti, beleértve a javításokat, a szabványoknak való megfelelés és a biztonság változásait, valamint az ügyfelek visszajelzései alapján végzett módosításokat. A módosítások többsége nem igényel programozási módosításokat az alkalmazásokban. Azok esetében, amelyek módosításokat is érinthetnek, tekintse meg a tábla Javasolt módosítások oszlopát. A jelentős módosítások terület szerint vannak lebontva, például ASP.NET és Windows Presentation Foundation (WPF).

A cikkben szereplő problémák magasabb szintű áttekintését a .NET-keretrendszer 4 migrálási útmutatójában találja.

Az új funkciókról további információt a .NET-keretrendszer 4 újdonságai című témakörben talál.

ASP.NET és web

Névterek: System.Web, System.Web.Mobile, System.Web.Security, System.Web.UI.WebControls

Szerelvény: System.Web (System.Web.dll)

Tulajdonság	Különbségek a 3,5 SP1-től	Javasolt módosítások
Böngésződefiníciós fájlok	A böngésződefiníciós fájlok úgy lettek frissítve, hogy az új és frissített böngészőkkel és eszközökkel kapcsolatos információkat tartalmazzanak. A régebbi böngészők és eszközök, például a Netscape Navigator el lettek távolítva, és újabb böngészők és eszközök, például a Google Chrome és az Apple iPhone lettek hozzáadva. Ha az alkalmazás olyan egyéni böngésződefiníciókat tartalmaz, amelyek az eltávolított böngésződefiníciók egyikétől öröklődnek, hibaüzenet jelenik meg. Az HttpBrowserCapabilities objektumot (amelyet az oldal tulajdonsága `Request.Browse` fed le) a böngésződefiníciós fájlok vezérlik. Ezért a 4. ASP.NET objektum egy tulajdonságának elérésével visszaadott információk eltérhetnek az ASP.NET egy korábbi verziójában visszaadott adatoktól.	Ha az alkalmazás a régi böngésződefiníciós fájlokra támaszkodik, a következő mappából másolhatja őket: Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\Browsers Másolja a fájlokat a megfelelő \CONFIG\Browsers mappába a ASP.NET 4-hez. A fájlok másolása után futtassa a Aspnet_regbrowsers.exe parancssori eszközt. További információkért tekintse meg a https://www.asp.net/mobile webhelyet.
A ASP.NET vegyes verzióiban futó gyermekalkalmazások	ASP.NET 4 alkalmazások, amelyek az ASP.NET korábbi verzióit futtató alkalmazások alárendeltjeiként vannak konfigurálva, nem biztos, hogy elindulnak konfigurációs vagy összeállítási hibák miatt. A konkrét hiba attól függ, hogy az alkalmazás az IIS 6.0, vagy az IIS 7 vagy az IIS 7.5 alatt fut-e.	Módosíthatja az érintett alkalmazások konfigurációs fájljait, hogy a konfigurációs rendszer megfelelően felismerje a ASP.NET 4 alkalmazást. A szükséges módosításokkal kapcsolatos információkért tekintse meg az "ASP.NET 4 gyermekalkalmazások nem indulnak el, amikor ASP.NET 2.0 vagy ASP.NET 3.5 alkalmazások alatt futnak" című szakaszt az ASP.NET 4 kompatibilitástörő módosítások dokumentumban az ASP.NET webhelyen.
ClientID-módosítások	A 4. ASP.NET új `clientIDMode` beállításával megadhatja, hogy ASP.NET hogyan hozza létre a `id` HTML-elemek attribútumát. A ASP.NET korábbi verzióiban az alapértelmezett viselkedés egyenértékű volt a `AutoID` beállítással `clientIDMode`. Az alapértelmezett beállítás most `Predictable`. További információ: ASP.NET webkiszolgáló-vezérlőazonosítás.	Ha a Visual Studio használatával frissíti az alkalmazást a ASP.NET 2.0-s vagy ASP.NET 3.5-ös verziójáról, az eszköz automatikusan hozzáad egy beállítást a Web.config fájlhoz, amely megőrzi a .NET-keretrendszer korábbi verzióinak viselkedését. Ha azonban úgy frissít egy alkalmazást, hogy az IIS-ben az alkalmazáskészletet a .NET-keretrendszer 4-re módosítja, ASP.NET alapértelmezés szerint az új módot használja. Az új ügyfél-azonosító mód letiltásához adja hozzá a következő beállítást a Web.config fájlhoz: `<pages clientIDMode="AutoID" />`
Kódhozzáférés biztonsága (CAS)	ASP.NET ASP.NET 3.5-ben hozzáadott 2.0 NET-funkciók a .NET Framework 1.1 és a .NET Framework 2.0 kódelérési biztonsági (CAS) modellt használják. A CAS ASP.NET 4-ben történő implementálását azonban jelentősen átdolgozták. Ennek eredményeképpen a részleges bizalommal rendelkező ASP.NET alkalmazások, amelyek a globális szerelvénygyorsítótárban futó megbízható kódra támaszkodnak, különböző biztonsági kivételekkel meghiúsulhatnak. A gép CAS-szabályzatának széles körű módosítására támaszkodó részleges megbízhatósági alkalmazások szintén meghiúsulhatnak, és biztonsági kivételeket vethetnek ki.	A részleges megbízhatósági ASP.NET 4 alkalmazást visszaállíthatja az 1.1-es és a 2.0-s ASP.NET viselkedésére a `legacyCasModel` konfigurációs elem új `trust` attribútumának használatával, ahogyan az a következő példában látható: `<trust level= "Medium" legacyCasModel="true" />` Fontos: A régebbi CAS-modellre való visszaállítás csökkentheti a biztonságot. Az új ASP.NET 4 kódelérési biztonsági modellről további információt a Code Access Security ASP.NET 4-alkalmazásokban talál.
Konfigurációs fájlok	A .NET-keretrendszer és az ASP.NET 4 gyökérkonfigurációs fájljai (a machine.config fájl és a gyökér Web.config fájl) frissültek, hogy tartalmazzák az alkalmazás Web.config fájlokban az ASP.NET 3.5-os verzióban található legtöbb alapértelmezett konfigurációs információt. A felügyelt IIS 7 és IIS 7.5 konfigurációs rendszerek összetettsége miatt ASP.NET 3.5-ös alkalmazások futtatása a 4. ASP.NET alatt és az IIS 7 és az IIS 7.5 alatt ASP.NET vagy IIS-hibákat eredményezhet.	Frissítse az ASP.NET 3.5-ös alkalmazásokat ASP.NET 4-re a Visual Studio projektfrissítési eszközeinek használatával. A Visual Studio 2010 automatikusan módosítja a ASP.NET 3.5 alkalmazás Web.config fájlját, hogy tartalmazza a ASP.NET 4 megfelelő beállításait. A .NET-keretrendszer 4 használatával azonban újrafordítás nélkül futtathat ASP.NET 3.5-ös alkalmazásokat. Ebben az esetben előfordulhat, hogy manuálisan kell módosítania az alkalmazás Web.config fájlját, mielőtt futtatja az alkalmazást a .NET-keretrendszer 4-ben, illetve az IIS 7 vagy az IIS 7.5 alatt. A szükséges módosítás a szoftver kombinációjától függ, beleértve a Szervizcsomag (SP) kiadásokat is. A módosítás által érintett lehetséges szoftverkombinációkról és az adott kombinációkkal kapcsolatos problémák megoldásáról a ASP.NET webhelyen ASP.NET 4 kompatibilitástörő módosítást ismertető dokumentumban található "Az új ASP.NET 4 gyökérkonfigurációhoz kapcsolódó konfigurációs hibák" című szakaszban talál további információt.
Vezérlő renderelése	A ASP.NET korábbi verzióiban bizonyos vezérlők olyan korrektúrát bocsátottak ki, amelyeket nem sikerült letiltani. Alapértelmezés szerint ez a típusú jelölés már nem jön létre az ASP.NET 4-ben. A megjelenítési módosítások a következő vezérlőket érintik: `Image` és `ImageButton` vezérlők már nem jelenítenek meg `border="0"` attribútumot. * Az `BaseValidator` abból származó osztály- és érvényesítési vezérlők alapértelmezés szerint nem jelenítik meg a piros szöveget. * A `HtmlForm` vezérlő nem jelenít meg attribútumot `name` . * A `Table` vezérlő már nem jelenít meg attribútumot `border="0"` . A nem felhasználói bemenetre (például a `Label` vezérlőre) tervezett vezérlők már nem jelenítik meg az `disabled="disabled"` attribútumot, ha a tulajdonságuk `Enabled` be van állítva `false` (vagy ha ezt a beállítást egy tárolóvezérlőtől öröklik).	Ha a Visual Studio használatával frissíti az alkalmazást a ASP.NET 2.0-s vagy ASP.NET 3.5-ös verziójáról, az eszköz automatikusan hozzáad egy beállítást a Web.config fájlhoz, amely megőrzi az örökölt renderelést. Ha azonban úgy frissít egy alkalmazást, hogy az IIS-ben az alkalmazáskészletet a .NET-keretrendszer 4-re módosítja, ASP.NET alapértelmezés szerint az új renderelési módot használja. Az új megjelenítési mód letiltásához adja hozzá a következő beállítást a Web.config fájlhoz: `<pages controlRenderingCompatibilityVersion="3.5" />`
Eseménykezelők az alapértelmezett dokumentumokban	ASP.NET 4 üres sztringként jeleníti meg a HTML `form` elem `action` attribútumértékét, amikor egy olyan bővítmény nélküli URL-re történik kérés, amelyhez alapértelmezett dokumentum van hozzárendelve. Az ASP.NET korábbi kiadásaiban a `http://contoso.com` kérés a Default.aspx kérését eredményezte. Ebben a dokumentumban a nyitó `form` címke az alábbi példához hasonlóan jelenik meg: `<form action="Default.aspx" />` Az ASP.NET 4-ben egy `http://contoso.com` kérelem egyben egy Default.aspx kérelemként is működik, de most az ASP.NET a HTML-nyitó `form` címkét úgy jeleníti meg, ahogy az az alábbi példában látható. `<form action="" />` Ha az `action` attribútum egy üres sztring, az IIS `DefaultDocumentModule` objektum létrehoz egy új kérelmet Default.aspx-re. A legtöbb feltétel esetén ez a gyermekkérelm transzparens az alkalmazáskód számára, és a Default.aspx oldal normál módon fut. A felügyelt kód és az IIS 7 vagy az IIS 7.5 integrált mód közötti lehetséges interakció azonban azt okozhatja, hogy a felügyelt .aspx lapok nem működnek megfelelően a gyermekkérés során. Ha a következő feltételek teljesülnek, a gyermek egy alapértelmezett .aspx dokumentumra irányuló kérése hibát vagy váratlan viselkedést eredményez: * Egy .aspx lap kerül a böngészőbe továbbításra a `form` elem `action` attribútumával, amely "" van megadva. * Az űrlap visszaküldésre kerül az ASP.NET-hez. * A felügyelt HTTP-modul beolvassa az entitás törzsének egy részét, például `Request.Form` vagy `Request.Params`. Ez azt eredményezi, hogy a POST-kérelem entitástörzse beolvasásra kerül a felügyelt memóriába. Ennek eredményeképpen az entitás törzse már nem érhető el az IIS 7 vagy az IIS 7.5 integrált módban futó natív kódmodulok számára. * Az IIS-objektum `DefaultDocumentModule` végül lefut, és létrehoz egy gyermekkérelmet a Default.aspx dokumentumhoz. Mivel azonban az entitás törzsét már beolvasta egy felügyelt kódrészlet, nincs elérhető entitástörzs, amely elküldhető a gyermekkérelemhez. * Amikor a HTTP-folyamat a gyermekkérelemhez fut, a .aspx fájlok kezelője a kezelő végrehajtási fázisában fut. Mivel nincs entitástörzs, nincsenek űrlapváltozók és nincs nézetállapot. Ezért a .aspx lapkezelő nem tudja meghatározni, hogy milyen eseményt (ha van ilyen) kell létrehozni. Ennek eredményeképpen az érintett .aspx lap futtatásához tartozó postback eseménykezelők egyike sem fut.	A módosítás következtében felmerülő problémák megkerülésének módjairól az ASP.NET webhelyen, az ASP.NET 4 Funkcióváltozások című dokumentumban talál további információt: "Előfordulhat, hogy az eseménykezelők nem feltétlenül futnak le alapértelmezett dokumentumban az IIS 7 vagy az IIS 7.5 integrált módban".
Kivonatoló algoritmus	ASP.NET titkosítási és kivonatolási algoritmusokat is használ az olyan adatok biztonságossá tételéhez, mint az űrlaphitelesítési cookie-k és az állapot megtekintése. Alapértelmezés szerint a ASP.NET 4 az algoritmust használja a HMACSHA256 cookie-k kivonatolási műveleteihez és a megtekintési állapothoz. A ASP.NET korábbi verziói a régebbi HMACSHA1 algoritmust használták.	Ha olyan alkalmazásokat futtat, amelyek ASP.NET 2.0-s és ASP.NET 4-et kevernek, ahol az adatoknak, például az űrlaphitelesítési cookie-knak a .NET-keretrendszer verzióiban kell működnie, konfiguráljon egy ASP.NET 4-webalkalmazást a régebbi HMACSHA1 algoritmus használatára az alábbi beállítás hozzáadásával a Web.config fájlban: `<machineKey validation="SHA1" />`
Üzemeltetési vezérlők az Internet Explorerben	A Windows Forms-vezérlők már nem üzemeltethetők az Internet Explorerben, mert jobb megoldások érhetők el a webes vezérlők üzemeltetésére. Ezért a IEHost.dll és IEExec.exe szerelvények el lettek távolítva a .NET-keretrendszerből.	A webalkalmazások egyéni vezérlésének fejlesztéséhez az alábbi technológiákat használhatja: * Létrehozhat egy Silverlight-alkalmazást, és konfigurálhatja úgy, hogy a böngészőn kívül fusson. További információ: Böngészőn kívüli támogatás. * Létrehozhat egy XAML böngészőalkalmazást (XBAP) a WPF képességeinek kihasználásához (az ügyfélgépeken a .NET-keretrendszer szükséges). További információ: WPF XAML böngészőalkalmazások áttekintése.
HtmlEncode és UrlEncode metódusok	A `HtmlEncode` és `UrlEncode` osztályok HttpUtility és HttpServerUtility módszereit frissítettük, hogy az idézőjel karaktert (') a következőképpen kódolják: * A `HtmlEncode` metódus az egyetlen idézőjel példányait a következőként kódolja: `'` * A `UrlEncode` metódus az egyetlen idézőjel példányait a következőként kódolja: `%27`	Vizsgálja meg a kódot olyan helyeken, ahol használja a `HtmlEncode` metódusokat, `UrlEncode` és győződjön meg arról, hogy a kódolás módosítása nem eredményez olyan változást, amely hatással lenne az alkalmazásra.
HttpException hibák ASP.NET 2.0-s alkalmazásokban	Miután ASP.NET 4 engedélyezve lett az IIS 6-on, ASP.NET 2.0-s alkalmazások, amelyek az IIS 6-on futnak (Windows Server 2003 vagy Windows Server 2003 R2 rendszeren) az alábbihoz hasonló hibákat eredményezhetnek: `System.Web.HttpException: Path '/[yourApplicationRoot]/eurl.axd/[Value]' was not found.`	* Ha ASP.NET 4 nem szükséges a webhely futtatásához, akkor a webhelyet áttérítheti az ASP.NET 2.0 használatára. -vagy- * Ha az ASP.NET 4 szükséges ahhoz, hogy a webhely fusson, helyezze át a gyermek ASP.NET 2.0 virtuális könyvtárakat egy másik webhelyre, amely az ASP.NET 2.0-re van leképezve. -vagy- * Tiltsa le a bővítmény nélküli URL-címeket. További információért lásd az "ASP.NET 2.0-s alkalmazások HttpException-hibákat eredményezhetnek, amelyek az eurl.axd hivatkozásra mutatnak" című dokumentumban található ASP.NET 4 kompatibilitástörő módosítások részt az ASP.NET webhelyen.
Tagságtípusok	Az ASP.NET tagság egyes típusai (például MembershipProvider) átkerültek a System.Web.dll könyvtárból a System.Web.ApplicationServices.dll könyvtárba. A típusok át lettek helyezve az ügyfél és a kiterjesztett .NET-keretrendszer termékváltozatai közötti architekturális rétegzési függőségek feloldása érdekében.	A ASP.NET korábbi verzióiról frissített és áthelyezett tagságtípusokat használó osztálykódtárak fordítása sikertelen lehet, ha egy ASP.NET 4-projektben használják. Ha igen, adjon hozzá egy hivatkozást az osztálykönyvtári projektben a System.Web.ApplicationServices.dll-ra.
Menüvezérlő változásai	A vezérlő módosításai a Menu következő viselkedést eredményezik: * Ha MenuRenderingMode értéke `List`, vagy ha MenuRenderingMode értéke `Default` és ControlRenderingCompatibilityVersion értéke `4.0` vagy újabb, akkor a PopOutImageUrl tulajdonságnak nincs hatása. * Ha a StaticPopOutImageUrl és DynamicPopOutImageUrl tulajdonságokban megadott elérési út fordított perjelet (\) tartalmaz, a képek nem jelennek meg. (Az ASP.NET korábbi verzióiban az elérési út tartalmazhat visszaperjelet.)	* Az egyes menüelemek tulajdonságának beállítása helyett állítsa be a PopOutImageUrl vagy StaticPopOutImageUrl tulajdonságát a szülő DynamicPopOutImageUrl vezérlőn. -vagy- Állítsa be MenuRenderingMode`Table`-re, vagy állítsa be MenuRenderingMode`Default`-ra, és állítsa be ControlRenderingCompatibilityVersion`3.5`-re. Ezek a beállítások miatt a vezérlő a Menu ASP.NET korábbi verzióiban használt HTML-táblázatalapú elrendezést használja. * Ha a StaticPopOutImageUrl vagy DynamicPopOutImageUrl tulajdonság elérési útja fordított perjelet (\) tartalmaz, helyettesítse perjelre (/).
Mobilszerelvény Web.config fájlban	Az ASP.NET korábbi verzióiban egy, a System.Web.Mobile.dll szerelvényre mutató hivatkozás szerepelt a gyökér Web.config fájlban a `assembliessystem.web`/`compilation` szakaszban. A teljesítmény javítása érdekében a rendszer eltávolította a szerelvényre mutató hivatkozást. Megjegyzés: A System.Web.Mobile.dll összeállítás és az ASP.NET mobilvezérlők beletartoznak az ASP.NET 4-hez, de ezek már elavultak.	Ha típusokat szeretne használni ebből a szerelvényből, adjon hozzá egy hivatkozást a szerelvényhez a gyökér Web.config fájlban vagy egy alkalmazás Web.config fájlban.
Kimeneti gyorsítótárazás	Az ASP.NET 1.0-ban egy hiba miatt a kimeneti gyorsítótárként megadott `Location="ServerAndClient"` beállítású gyorsítótárazott oldalak a válaszban `Vary:` HTTP-fejlécet bocsátottak ki. Az az eredménye volt, hogy az ügyfélböngészők soha ne gyorsítótárazzák helyben az oldalt. A ASP.NET 1.1-ben hozzáadta a SetOmitVaryStar metódust, amely meghívható a `Vary:` fejléc letiltásához. A hibajelentések azonban arra utalnak, hogy a fejlesztők nem ismerik a meglévő `SetOmitVaryStar` viselkedést. A ASP.NET 4-ben a `Vary:` HTTP-fejléc már nem lesz kibocsátva a következő irányelvet meghatározó válaszokból: `<%@ OutputCache Location="ServerAndClient" %>` Ennek eredményeképpen a SetOmitVaryStar metódusra már nincs szükség a `Vary:` fejléc letiltásához. Az attribútumhoz a "ServerAndClient" értéket megadó alkalmazásokban a `Location` lapok gyorsítótárazhatók lesznek a böngészőben anélkül, hogy fel kellene hívni SetOmitVaryStar.	Ha az alkalmazás lapjainak ki kell bocsátaniuk `Vary:`, hívja meg a AppendHeader metódust, ahogyan az alábbi példában látható. `System.Web.HttpResponse.AppendHeader("Vary","");` Másik lehetőségként módosíthatja a kimeneti gyorsítótárazási `Location` attribútum értékét "Kiszolgáló" értékre.
Lapelemzés	A ASP.NET weblapok (.aspx fájlok) és a felhasználói vezérlők (.ascx fájlok) lapelemzője szigorúbb ASP.NET 4-ben, mint a ASP.NET korábbi verzióiban, és több korrektúrát jelöl érvénytelennek, mint a korábbi verziókban.	Vizsgálja meg a lap futtatásakor megjelenő hibaüzeneteket, és javítsa ki az érvénytelen korrektúra miatt keletkező hibákat.
Útlevéltípusok	Az ASP.NET 2.0-s verzióba beépített Passport-támogatás elavult, és a Passport (most élő azonosítójú SDK) változásai miatt nem támogatott. Ennek eredményeképpen a Passporthoz System.Web.Security kapcsolódó típusok mostantól az `ObsoleteAttribute` attribútummal vannak megjelölve.	Módosítsa azokat a kódokat, amelyek Passport típusokat használnak a System.Web.Security névtérben, például PassportIdentity, úgy hogy a Windows Live ID SDK-t használják.
PathInfo-információk a FilePath tulajdonságban	ASP.NET 4 már nem tartalmazza a `PathInfo` értéket a visszaadott értékekben olyan tulajdonságok esetében, mint FilePath, AppRelativeCurrentExecutionFilePath és CurrentExecutionFilePath. Ehelyett az `PathInfo` információk a következő helyen PathInfoérhetők el: . Képzelje el például a következő URL-töredékét: `/testapp/Action.mvc/SomeAction` A ASP.NET HttpRequest korábbi verzióiban a tulajdonságok a következő értékekkel rendelkeznek: * FilePath: `/testapp/Action.mvc/SomeAction` * PathInfo: (üres) A ASP.NET 4-ben HttpRequest a tulajdonságok a következő értékekkel rendelkeznek: * FilePath: `/testapp/Action.mvc` * PathInfo: `SomeAction`	Vizsgálja meg a kódot olyan helyeken, ahol az osztály tulajdonságaira támaszkodva adja vissza az HttpRequest elérésiút-információkat. Módosítsa a kódot úgy, hogy az tükrözze az elérésiút-adatok visszaadásának változásait.
Érvényesítés kérése	A kérések érvényesítésének javítása érdekében a ASP.NET kérésérvényesítés a kérelem életciklusának korábbi szakaszában lesz meghívva. Ennek eredményeképpen a nem .aspx fájlokhoz tartozó kérelmek, például a webszolgáltatás-hívások és az egyéni kezelők esetén, lefut az érvényesítés. A kérelmek érvényesítése akkor is aktív lesz, ha egyéni HTTP-modulok futnak a kérelemfeldolgozási folyamatban. A módosítás eredményeként a .aspx fájloktól eltérő erőforrásokra vonatkozó kérelmek érvényesítési hibákat okozhatnak. A kérelemfolyamatban (például egyéni HTTP-modulokban) futó egyéni kód kérésérvényesítési hibákat is eredményezhet.	Ha szükséges, visszaállíthatja a régi viselkedést, hogy csak .aspx lapok aktiválják a kérések érvényesítését a webes konfigurációs fájl alábbi beállításával: `<httpRuntime requestValidationMode="2.0" />` Figyelmeztetés: Ha visszaáll a régi viselkedésre, győződjön meg arról, hogy a meglévő kezelőkben, modulokban és más egyéni kódban lévő összes kód ellenőrzi a potenciálisan nem biztonságos HTTP-bemeneteket, amelyek XSS-támadási vektorok lehetnek.
Útválasztás	Ha fájlrendszerbeli webhelyet hoz létre a Visual Studio 2010-ben, és a webhely egy olyan mappában van, amely tartalmaz egy pont (.) értéket a mappa nevében, az URL-útválasztás nem fog megbízhatóan működni. A rendszer HTTP 404-hibát ad vissza néhány virtuális útvonalról. Ez azért fordul elő, mert a Visual Studio 2010 helytelen elérési úttal indítja el a Visual Studio fejlesztői kiszolgálót a legfelső szintű virtuális könyvtárhoz.	* A fájlalapú webhely Tulajdonságok lapján módosítsa az `Virtual Path` attribútumot "/" értékre. -vagy- * Webhelyprojekt helyett webalkalmazás-projektet hozhat létre. A webalkalmazás-projektek nem rendelkeznek ezzel a problémával, és az URL-útválasztás akkor is működik, ha a projektmappának van egy pont a nevében. -vagy- * Hozzon létre egy IIS-ben üzemeltetett HTTP-alapú webhelyet. Az IIS által üzemeltetett webhelyek pontokkal rendelkezhetnek a virtuális elérési úton és a projektfájl mappájában.
SharePoint-webhelyek	Ha olyan ASP.NET 4-es webhelyet próbál futtatni, amely egy Olyan SharePoint-webhely gyermekeként van üzembe helyezve, amely egy egyéni részleges megbízhatósági szintet tartalmaz, `WSS_Minimal`a következő hibaüzenet jelenik meg: `Could not find permission set named 'ASP.Net'.`	Jelenleg a SharePoint egyik verziója sem kompatibilis a ASP.NET. Ennek eredményeképpen ne kíséreljen meg ASP.NET 4-webhelyet egy SharePoint-webhely gyermekeként futtatni.
XHTML 1.1 szabványok	Az új webhelyek XHTML 1.1-es megfelelőségének engedélyezéséhez a .NET Framework 4 ASP.NET vezérlői létrehoznak XHTML 1.1-kompatibilis HTML-t. Ez a renderelés az elemen belüli `<system.Web>` Web.config fájlban az alábbi beállítással engedélyezve van: `<pages controlRenderingCompatibilityVersion="4.0"/>` Ez a beállítás alapértelmezés szerint 4.0-ra van állítva. A Visual Studio 2008-ról frissített webes projektek esetében engedélyezve van a 3.5-ös beállítás a kompatibilitáshoz.	Nincs.

Központ

Általános funkciók

Tulajdonság	Különbségek a 3,5 SP1-től	Javasolt módosítások
CardSpace	A Windows CardSpace már nem szerepel a .NET-keretrendszerben; külön kell megadni.	Töltse le a Windows CardSpace-t a Microsoft letöltőközpontból.
Konfigurációs fájlok	Kijavítottuk, hogy a .NET-keretrendszer hogyan fér hozzá az alkalmazáskonfigurációs fájlokhoz.	Ha az alkalmazáskonfigurációs fájl neveapplication-name.config, nevezze át application-name.exe.config. Nevezze át például MyApp.configMyApp.exe.config.
C# kódfordító	A `Compiler`, `CompilerError` és `ErrorLevel` osztályok, amelyek a Microsoft.CSharp névtérben voltak, már nem érhetők el, és a szerelvény (cscompmgd.dll) már nem szerepel a .NET-keretrendszerben.	Használja az osztályt CodeDomProvider és más osztályokat a System.CodeDom.Compiler névtérben. További információ: A CodeDOM használata.
Üzemeltetés (nem felügyelt API)	Az üzemeltetési képességek javítása érdekében néhány üzemeltetési aktiválási API elavult. A folyamaton belüli egymás melletti végrehajtási funkciók lehetővé teszik, hogy az alkalmazások ugyanabban a folyamatban tölthessék be és indíthassák el a .NET-keretrendszer több verzióját. Futtathat például olyan alkalmazásokat, amelyek a .NET-keretrendszer 2.0 SP1-en és a .NET-keretrendszer 4-en alapuló bővítményeken (vagy összetevőkön) alapulnak ugyanabban a folyamatban. A régebbi összetevők továbbra is a régebbi .NET-keretrendszerverziót használják, az új összetevők pedig az új .NET-keretrendszert.	Használja a In-Process párhuzamos végrehajtásban leírt konfigurációkat.
Új biztonsági modell	A kódhozzáférés biztonsági (CAS) házirendje ki lett kapcsolva, és egy egyszerűsített modellre váltottuk fel, a .NET-keretrendszer 4 biztonsági változásaiban leírtak szerint.	Előfordulhat, hogy módosításokra lesz szükség, ha az alkalmazásokban a CAS-ra támaszkodik. További információ: Code Access biztonsági házirendek kompatibilitása és migrálása.

Dátum és idő

Névtér: System

Szerelvény: mscorlib (mscorlib.dll)

Tulajdonság	Különbségek a 3,5 SP1-től	Javasolt módosítások
Nyári időszámítás	A rendszerórával való konzisztensség érdekében az időtulajdonságok (például Local és Now) mostantól operációsrendszer-szabályokat használnak más .NET-keretrendszer-adatok helyett a nyári időszámítási műveletekhez.	Nincs.
Sztringek formázása	A kultúraérzékeny formázás támogatása érdekében a TimeSpan struktúra új túlterheléseket tartalmaz a `ToString`, `Parse` és `TryParse` metódusokhoz, valamint új `ParseExact` és `TryParseExact` metódusokat.	Nincs.

Globalizáció

Az új semleges és specifikus kultúrák listájáért tekintse meg a globalizáció és a honosítás újdonságait.

Névtér: System.Globalization

Szerelvény: mscorlib (mscorlib.dll)

Tulajdonság	Különbségek a 3,5 SP1-től	Javasolt módosítások
Kulturális nevek	A következő névváltozások a német, a divehi és az afrikai kultúrát érintik: * CurrencyEnglishName: A német (Svájc) (de-CH) kultúra pénznemneve "sFr"-ről "Fr"-ra változott. Az Divehi (Maldív-szigetek) (dv-MV) kultúra hosszú dátumformátuma megváltozott: a "dd/MMMM/yyyy" helyett most "dd/MM/yyyy" lett. * PMDesignator: Az afrikaans (Dél-Afrika) (af-ZA) kultúra P.M. jelölője "nm"-ről "PM"-re változott.	Vegye észre a kultúra névváltozásait.
LCID paraméter	Az automatizálási kiszolgáló beállításainak várt viselkedésével való konzisztensség érdekében a CLR már nem adja át a paraméter aktuális kultúráját a `LCID` nem felügyelt COM-alapú alkalmazásoknak. Ehelyett az 1033-at (en-us) adja át a kultúrához.	Nincs szükség módosításra, kivéve azokat a natív alkalmazásokat, amelyek egy adott kultúrát igényelnek.
Elavult kulturális típusok	A CultureTypes kulturális és CultureTypes kulturális típusok elavultak. A visszamenőleges kompatibilitás CultureTypes érdekében most az előző .NET-keretrendszerben szereplő semleges és specifikus kultúrákat adja vissza, és CultureTypes most egy üres listát ad vissza.	Használja a CultureTypes felsorolás egyéb értékeit.
Kultúra lekérése	A Windows 7-től kezdődően a .NET-keretrendszer 4 az adatok tárolása helyett lekéri a kulturális adatokat az operációs rendszerből. A .NET-keretrendszer emellett szinkronizálja a Windowst az adatok rendezéséhez és a rendszerezéshez.	Nincs.
Unicode 5.1-szabványok	A .NET-keretrendszer mostantól támogatja az összes Unicode 5.1 karaktert – körülbelül 1400 karakter hozzáadásával. A további karakterek közé tartoznak az új szimbólumok, nyilak, diakritikák, írásjelek, matematikai szimbólumok, CJK-vonások és ideográfok, további malajálam- és telugu numerikus karakterek, valamint különböző mianmari, latin, arab, görög, mongol és cirill karakterek. A következő új szkriptek támogatottak a Unicode 5.1-ben: Sundanese, Lepcha, Ol Chiki, Vai, Saurashtra, Kayah Li, Rejang, Gurmukhi, Odia, Tamil, Telugu és Malayalam karakterek és Cham.	Nincs.

Kivételek

Névterek: System, System.Runtime.ExceptionServices

Szerelvény: mscorlib (mscorlib.dll)

Tulajdonság	Különbségek a 3,5 SP1-től	Javasolt módosítások
A sérült folyamatállapot kivételei	A CLR már nem biztosít kivételeket a sérült folyamatállapothoz a felügyelt kód kivételkezelőinek.	Ezek a kivételek azt jelzik, hogy egy folyamat állapota sérült. Nem javasoljuk, hogy ebben az állapotban futtassa az alkalmazást. További információért nézd meg az HandleProcessCorruptedStateExceptionsAttribute és a Sérült állapot kivételeinek kezelése című írást az MSDN magazinban.
Végrehajtási motor kivételei	ExecutionEngineException mára elavult, mert egy elkapható kivétel lehetővé teszi egy instabil folyamat futtatását. Ez a változás javítja a futásidőben a kiszámíthatóságot és a megbízhatóságot.	Használjon InvalidOperationException a feltétel jelzésére.

Elmélkedés

Névtér: System.Reflection

Szerelvény: mscorlib (mscorlib.dll)

Tulajdonság	Különbségek a 3,5 SP1-től	Javasolt módosítások
Szerelvénykivonat-algoritmusok	A HashAlgorithm tulajdonság most visszatér AssemblyHashAlgorithm, mert a futtatókörnyezet nem ismeri a hivatkozott szerelvény kivonatoló algoritmusát, amikor a szerelvény nincs betöltve. (Ez arra vonatkozik, hogy a tulajdonságot egy hivatkozott szerelvényen használja, például azon, amelyet a GetReferencedAssemblies metódus ad vissza.)	Nincs.
Összeállítás betöltése	A szerelvények redundáns betöltésének megakadályozása és a virtuális címtér megtakarítása érdekében a CLR most már csak a Win32 `MapViewOfFile` függvény használatával tölti be a szerelvényeket. Már nem is hívja meg a függvényt `LoadLibrary` . Ez a változás a diagnosztikai alkalmazásokat a következő módokon érinti: * A ProcessModuleCollection többé nem tartalmaz modulokat egy osztálykönyvtárból (.dll fájlból), amit a `Process.GetCurrentProcess().Modules` hívás eredményez. * A függvényt használó Win32-alkalmazások nem látják az `EnumProcessModules` összes felügyelt modult a listában.	Nincs.
Deklarálás típusa	A DeclaringType tulajdonság most már helyesen null értéket ad vissza, ha a típus nem rendelkezik deklarálási típussal.	Nincs.
meghatalmazottak	A delegált mostantól ArgumentNullException dob, nem pedig NullReferenceException, amikor a delegáló konstruktorának nulla értékű paramétert adnak át.	Győződjön meg arról, hogy a kivételkezelés fogásokat okoz ArgumentNullException.
Globális közös gyűjteménytár helyének módosítása	A .NET Framework 4 szerelvények esetében a globális szerelvénygyorsítótár át lett helyezve a Windows könyvtárból (%WINDIR%) a Microsoft.Net alkönyvtárba (%WINDIR%\Microsoft.Net). A korábbi verziókból származó szerelvények a régebbi mappában maradnak. A nem felügyelt ASM_CACHE_FLAGS enumerálás tartalmazza az új `ASM_CACHE_ROOT_EX` jelzőt. Ez a jelző lekéri a .NET-keretrendszer 4-szerelvények gyorsítótárának helyét, amelyet a GetCachePath függvény szerezhet be.	Nincs, feltéve, hogy az alkalmazások nem használnak explicit útvonalakat az összeállításokhoz, mivel ez nem javasolt eljárás.
Globális szerelvénygyorsítótár-eszköz	A Gacutil.exe (Global Assembly Cache Tool) már nem támogatja a parancshéj bővítmény-megjelenítőt.	Nincs.

Interoperabilitás

Névtér: System.Runtime.InteropServices

Szerelvény: mscorlib (mscorlib.dll)

Tulajdonság	Különbségek a 3,5 SP1-től	Javasolt módosítások
Puffer hossza (nem felügyelt API)	A memória megtakarítása érdekében az `pBufferLengthOffset` paraméterhez tartozó funkcionalitás az ICorProfilerInfo2::GetStringLayout metódusban úgy módosult, hogy megfeleljen a `pStringLengthOffset` paraméternek. Mindkét paraméter most a sztring hosszának eltolási helyére mutat. A puffer hosszát eltávolították a karakterlánc osztály ábrázolásából.	Távolítsa el a puffer hosszával kapcsolatos függőségeket.
JIT-hibakeresés	Az igény szerinti (JIT) hibakeresés regisztrációjának egyszerűsítése érdekében a .NET-keretrendszer hibakeresője mostantól csak az AeDebug beállításkulcsot használja, amely szabályozza a JIT hibakeresési viselkedését a natív kód esetében. Ez a változás a következőket eredményezi: * A továbbiakban nem regisztrálhat két különböző hibakeresőt a felügyelt és a natív kódhoz. * Nem indíthatja el automatikusan a hibakeresőt egy nem interaktív folyamat esetén, de megkérheti a felhasználót egy interaktív folyamatra. * A továbbiakban nem kap értesítést arról, ha a hibakereső nem indul el, vagy ha nincs elindítandó regisztrált hibakereső. * Az alkalmazás interaktivitásától függő automatikus indítási szabályzatok már nem támogatottak.	Szükség szerint módosítsa a hibakeresési műveleteket.
Platformhívási funkció	Az együttműködés teljesítményének javítása érdekében a nem felügyelt kódokkal, a platformhívásoknál használt helytelen hívási konvenciók most az alkalmazás meghibásodását okozzák. A korábbi verziókban a kiosztási réteg megoldotta ezeket a hibákat a hierarchikus rétegekben.	Az alkalmazások hibakeresése a Microsoft Visual Studio-ban figyelmezteti Önt ezekre a hibákra, hogy kijavíthassa azokat. Ha olyan bináris fájlok vannak, amelyek nem frissíthetők, a <NetFx40_PInvokeStackResilience> elemet belefoglalhatja az alkalmazás konfigurációs fájljába, hogy a hívási hibák a korábbi verziókhoz hasonlóan feloldhatók legyenek a veremen. Ez azonban befolyásolhatja az alkalmazás teljesítményét.
Eltávolított felületek (nem felügyelt API)	A fejlesztői félreértések elkerülése érdekében a következő felületek el lettek távolítva, mert nem biztosítottak hasznos futtatókörnyezeti forgatókönyveket, és a CLR nem biztosított és nem fogadott el implementációkat: * INativeImageINativeImageDependency * INativeImageInstallInfo * INativeImageEvaluate * INativeImageConverter * ICorModule * IMetaDataConverter	Nincs.

Adat

Ez a szakasz az adatkészletek és SQL-ügyfelek, az Entity Framework, a LINQ–SQL és a WCF-adatkiszolgálók (korábbi nevén ADO.NET Data Services) használatával kapcsolatos migrálási problémákat ismerteti.