Sdílet prostřednictvím

ASP.NET 4 – nejnovější změny

  • Článek

Tento dokument popisuje změny provedené pro verzi rozhraní .NET Framework verze 4, které můžou potenciálně ovlivnit aplikace vytvořené pomocí předchozích verzí, včetně verzí ASP.NET 4 Beta 1 a Beta 2.

Stáhnout tento dokument White Paper

Obsah

ControlRenderingCompatibilityVersion – Nastavení v souboru Web.config
ClientIDMode – změny
HtmlEncode a UrlEncode Nyní kódování jednoduchých uvozovek
ASP.NET Page (.aspx) Parser is Stricter
Aktualizované definiční soubory prohlížeče
System.Web.Mobile.dll odebrané z konfiguračního souboru kořenového webu
ASP.NET Ověření požadavku
Výchozí algoritmus hashování je teď HMACSHA256.
Chyby konfigurace související s novou kořenovou konfigurací ASP.NET 4
ASP.NET 4 – Podřízené aplikace se nespustí, když ASP.NET 2.0 nebo ASP.NET 3.5
weby ASP.NET 4 se nedaří spustit na počítačích, na kterých je nainstalovaný SharePoint
Vlastnost HttpRequest.FilePath už neobsahuje hodnoty PathInfo.
ASP.NET 2.0 Aplikace můžou generovat chyby HttpException odkazované na eurl.axd
Obslužné rutiny událostí nemusí být vyvolány ve výchozím dokumentu ve službě IIS 7 nebo integrovaném režimu služby IIS 7.5
Změny implementace ASP.NET code Access Security (CAS)
MembershipUser a další typy v oboru názvů System.Web.Security byly přesunuty.
Změny ukládání výstupu do mezipaměti na různé * hlavičky HTTP
Typy System.Web.Security pro Passport jsou zastaralé.
Vlastnost MenuItem.PopOutImageUrl se nepodaří vykreslit obrázek v ASP.NET 4.
Menu.StaticPopOutImageUrl a Menu.DynamicPopOutImageUrl se nedaří vykreslit obrázky, když cesty obsahují zpětná lomítka
Prohlášení

ControlRenderingCompatibilityVersion – Nastavení v souboru Web.config

ASP.NET ovládací prvky byly změněny v rozhraní .NET Framework verze 4, aby bylo možné přesněji určit, jak vykreslují značky. V předchozích verzích rozhraní .NET Framework některé ovládací prvky vygenerovaly značky, které jste neměli možnost zakázat. Ve výchozím nastavení se ASP.NET 4 tento typ značek už negeneruje.

Pokud pomocí sady Visual Studio 2010 upgradujete aplikaci z ASP.NET 2.0 nebo ASP.NET 3.5, nástroj do souboru automaticky přidá nastavení Web.config , které zachová starší verzi vykreslování. Pokud však upgradujete aplikaci změnou fondu aplikací ve službě IIS tak, aby cílil na rozhraní .NET Framework 4, ASP.NET použije ve výchozím nastavení nový režim vykreslování. Pokud chcete zakázat nový režim vykreslování, přidejte do Web.config souboru následující nastavení:

<pages controlRenderingCompatibilityVersion="3.5" />

Hlavní změny vykreslování, které nové chování přináší, jsou následující:

  • Ovládací prvky Image a ImageButton už nevykreslují border="0" atribut.
  • BaseValidator Třída a ověřovací ovládací prvky, které z ní jsou odvozeny, již ve výchozím nastavení nevykreslují červený text.
  • HtmlForm ovládací prvek nevykresluje atribut name.
  • Ovládací prvek Tabulka již nevykresluje border="0" atribut.
  • Ovládací prvky, které nejsou navrženy pro vstup uživatele (například ovládací prvek Popisek ), již nevykreslují disabled="disabled" atribut, pokud je jejich vlastnost Enabled nastavená na false (nebo pokud toto nastavení dědí z ovládacího prvku kontejneru).

ClientIDMode – změny

Nastavení ClientIDMode v ASP.NET 4 umožňuje určit, jak ASP.NET vygeneruje atribut id pro elementy HTML. V předchozích verzích ASP.NET bylo výchozí chování ekvivalentní nastavení AutoIDv ClientIDMode. Výchozí nastavení je ale nyní předvídatelné.

Pokud pomocí sady Visual Studio 2010 upgradujete aplikaci z ASP.NET 2.0 nebo ASP.NET 3.5, nástroj automaticky přidá do Web.config souboru nastavení, které zachová chování starších verzí rozhraní .NET Framework. Pokud však upgradujete aplikaci změnou fondu aplikací ve službě IIS tak, aby cílil na 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 Web.config souboru následující nastavení:

<pages clientIDMode="AutoID" />

HtmlEncode a UrlEncode Nyní kódování jednoduchých uvozovek

V ASP.NET 4 byly metody HtmlEncode a UrlEncode tříd HttpUtility a HttpServerUtility 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.

ASP.NET Page (.aspx) Parser is Stricter

Analyzátor stránek pro ASP.NET stránky (.aspx soubory) a uživatelské ovládací prvky (.ascx soubory) je v ASP.NET 4 přísnější a odmítne více instancí neplatných značek. Například následující dva fragmenty kódu by se úspěšně parsovaly v dřívějších verzích ASP.NET, ale nyní budou vyvolávat chyby analyzátoru v ASP.NET 4.

<asp:HiddenField runat="server" ID="SomeControl" Value="sampleValue"  ; />

Všimněte si neplatného středníku na konci značky HiddenField .

<asp:LinkButton runat="server" ID="SomeControl" onclick="someControlClicked"
      style="display:inline;  CssClass="searchLink"  />

Všimněte si neuzavřeného atributu stylu , který běží do atributu CssClass .

Aktualizované definiční soubory prohlížeče

Definiční soubory 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 některé z definic prohlížeče, které byly odebrány, zobrazí se chyba. Pokud například složka obsahuje definici prohlížeče, App_Browsers která dědí z definice prohlížeče IE2, zobrazí se následující chybová zpráva konfigurace:

  • Prohlížeč nebo element brány s ID IE2 nebyl nalezen.

Poznámka

Objekt HttpBrowserCapabilities (který je zpřístupněn vlastností Request.Browser stránky) je řízen soubory definic prohlížeče. Proto se informace vrácené přístupem k vlastnosti tohoto objektu v ASP.NET 4 mohou lišit od informací vrácených v dřívější verzi ASP.NET.

Ke starým definičním souborům prohlížeče se můžete vrátit zkopírováním definičních souborů prohlížeče z následující složky:

Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\Browsers

Zkopírujte soubory do odpovídající \CONFIG\Browsers složky pro ASP.NET 4. Po zkopírování souborů spusťte nástroj příkazového řádku Aspnet_regbrowsers.exe.

System.Web.Mobile.dll odebrání z konfiguračního souboru kořenového webu

V předchozích verzích ASP.NET byl odkaz na sestavení System.Web.Mobile.dll zahrnut do kořenového Web.config souboru v části sestavení pod. Za účelem zvýšení výkonu byl odebrán odkaz na toto sestavení.

Sestavení System.Web.Mobile.dll je součástí ASP.NET 4, ale je zastaralé. Pokud chcete použít typy z System.Web.Mobile.dll sestavení, přidejte odkaz na toto sestavení buď na kořenový Web.config soubor, nebo na soubor aplikace Web.config . Pokud například chcete použít některý z (zastaralých) ASP.NET mobilních ovládacích prvků, musíte do Web.config souboru přidat odkaz na sestavení System.Web.Mobile.dll.

ASP.NET ověření požadavku

Funkce ověření požadavků v ASP.NET poskytuje určitou úroveň výchozí ochrany před útoky skriptováním mezi weby (XSS). V předchozích verzích ASP.NET bylo ve výchozím nastavení povoleno ověření požadavku. Použila se však pouze pro ASP.NET stránky (.aspx soubory a soubory jejich třídy) a pouze v případě, že byly tyto stránky spuštěny.

Ve ASP.NET 4 je ve výchozím nastavení pro všechny požadavky povolené ověření požadavku, protože je povolené před fází BeginRequest požadavku HTTP. V důsledku toho se ověření požadavků vztahuje na požadavky na všechny ASP.NET prostředky, nejen na žádosti o stránku .aspx. To zahrnuje požadavky, jako jsou volání webové služby a vlastní obslužné rutiny HTTP. Ověření požadavku je také aktivní, když vlastní moduly HTTP čtou obsah požadavku HTTP.

V důsledku toho teď může docházet k chybám ověření požadavků u požadavků, které dříve chyby neaktivovalo. Pokud se chcete vrátit k chování funkce ověřování požadavků ASP.NET 2.0, přidejte do Web.config souboru následující nastavení:

<httpRuntime requestValidationMode="2.0" />

Doporučujeme však analyzovat všechny chyby ověření požadavků, abyste zjistili, jestli stávající obslužné rutiny, moduly nebo jiný vlastní kód přistupují k potenciálně nebezpečným vstupům HTTP, které by mohly být vektory útoku XSS.

Výchozí algoritmus hashování je teď HMACSHA256.

ASP.NET používá šifrovací i hashovací algoritmy k zabezpečení dat, jako jsou soubory cookie ověřování formulářů a zobrazení stavu. Ve výchozím nastavení teď ASP.NET 4 používá algoritmus HMACSHA256 pro operace hash souborů cookie a zobrazení stavu. Starší verze ASP.NET používaly starší algoritmus HMACSHA1.

Aplikace mohou být ovlivněny, pokud spustíte smíšená prostředí ASP.NET 2.0/ASP.NET 4, kde data, jako jsou soubory cookie ověřování formulářů, musí fungovat across.NET verzích rozhraní. Pokud chcete nakonfigurovat webovou aplikaci ASP.NET 4 tak, aby používala starší algoritmus HMACSHA1, přidejte do Web.config souboru následující nastavení:

<machineKey validation="SHA1" />

Kořenové konfigurační soubory ( machine.config soubor a kořenový Web.config soubor) pro rozhraní .NET Framework 4 (a proto ASP.NET 4) byly aktualizovány tak, aby zahrnovaly většinu informací o konfiguraci, které byly v ASP.NET 3.5 nalezeny v souborech aplikace Web.config . Vzhledem ke složitosti spravovaných konfiguračních systémů služby IIS 7 a IIS 7.5 může spuštění aplikací ASP.NET 3.5 v ASP.NET 4 a ve službě IIS 7 a IIS 7.5 způsobit chyby konfigurace ASP.NET nebo IIS.

Doporučujeme upgradovat aplikace ASP.NET 3.5 na ASP.NET 4 pomocí nástrojů pro upgrade projektu v sadě Visual Studio 2010, pokud je to vhodné. Visual Studio 2010 automaticky upraví soubor aplikace Web.config ASP.NET 3.5 tak, aby obsahoval odpovídající nastavení pro ASP.NET 4.

Je však podporovaným scénářem spouštění aplikací ASP.NET 3.5 pomocí rozhraní .NET Framework 4 bez rekompilace. V takovém případě možná budete muset ručně upravit soubor aplikace Web.config před spuštěním aplikace v rozhraní .NET Framework 4 a ve službě IIS 7 nebo IIS 7.5.

Následující dvě části popisují změny, které může být potřeba provést pro různé kombinace softwaru.

Windows Vista SP1 nebo Windows Server 2008 SP1, kde není nainstalována oprava hotfix KB958854 ani SP2. V této konfiguraci konfigurační systém služby IIS 7 nesprávně sloučí spravovanou konfiguraci aplikace porovnáním souboru na úrovni Web.config aplikace se soubory ASP.NET 2.0 machine.config . Z tohoto důvodu musí soubory na úrovni Web.config aplikace z rozhraní .NET Framework 3.5 nebo novější obsahovat definici oddílu konfigurace system.web.extensions (element), aby nedošlo k selhání ověřování služby IIS 7.

Ručně upravené položky souboru na úrovni Web.config aplikace, které přesně neodpovídají definici původní často používané konfigurace oddílu, které byly zavedeny v sadě Visual Studio 2008, však způsobí ASP.NET chyby konfigurace. (Výchozí položky konfigurace vygenerované sadou Visual Studio 2008 fungují správně.) Běžným problémem je, že ručně upravené Web.config soubory vynechávají atributy konfigurace allowDefinition a requirePermission , které se nacházejí v definicích různých oddílů konfigurace. To způsobí neshodu mezi zkráceným konfiguračním oddílem v souborech na úrovni Web.config aplikace a úplnou definicí v souboru ASP.NET 4 machine.config . V důsledku toho za běhu konfigurační systém ASP.NET 4 vyvolá chybu konfigurace.

Windows Vista SP2, Windows Server 2008 SP2, Windows 7, Windows Server 2008 R2 a také Windows Vista SP1 a Windows Server 2008 SP1, kde je nainstalovaná oprava hotfix KB958854.

V tomto scénáři služba IIS 7 a IIS 7.5 nativní konfigurační systém vrátí chybu konfigurace, protože provádí textové porovnání atributu typu , který je definován pro spravovanou obslužnou rutinu oddílu konfigurace. Vzhledem k tomu, že všechny Web.config soubory generované sadou Visual Studio 2008 a Visual Studio 2008 SP1 mají "3.5" v řetězci typu pro obslužné rutiny oddílu konfigurace system.web.extensions (a související) a protože soubor ASP.NET 4 machine.config má "4.0" v atributu type pro stejné obslužné rutiny konfiguračního oddílu, aplikace, které jsou generovány v sadě Visual Studio 2008 nebo Visual Studio 2008 SP1 vždy nezdaří ověření konfigurace ve službě IIS 7 a IIS 7.5.

Řešení těchto problémů

Alternativním řešením pro první scénář je aktualizace souboru na úrovni Web.config aplikace zahrnutím často používaného konfiguračního textu ze Web.config souboru, který byl automaticky vygenerován sadou Visual Studio 2008.

Alternativním alternativním řešením pro první scénář je instalace aktualizace Service Pack 2 pro systém Vista nebo Windows Server 2008 do počítače, abyste opravili nesprávné chování konfiguračního systému služby IIS při slučování konfigurace. Po provedení některé z těchto akcí však ve vaší aplikaci pravděpodobně dojde k chybě konfigurace kvůli problému popsanému v druhém scénáři.

Alternativním řešením pro druhý scénář je odstranit nebo zakomentovat všechny definice oddílů konfigurace system.web.extensions a definice skupin oddílů konfigurace ze souboru na úrovni Web.config aplikace. Tyto definice jsou obvykle v horní části souboru na úrovni Web.config aplikace a lze je identifikovat pomocí elementu configSections a jeho podřízených prvků.

V obou scénářích se doporučuje ručně odstranit také oddíl system.codedom , i když to není nutné.

ASP.NET 4 – Podřízené aplikace se nespustí, pokud ASP.NET 2.0 nebo ASP.NET 3.5

ASP.NET 4 aplikace, které jsou nakonfigurované jako podřízené položky aplikací se staršími verzemi ASP.NET se nemusí spustit kvůli chybám konfigurace nebo kompilace. Následující příklad ukazuje adresářovou strukturu pro ovlivněnou aplikaci.

/parentwebapp (nakonfigurované pro použití ASP.NET 2.0 nebo ASP.NET 3.5)
/childwebapp (nakonfigurované pro použití ASP.NET 4)

Aplikaci ve childwebapp složce se nepodaří spustit ve službě IIS 7 nebo IIS 7.5 a ohlásí chybu konfigurace. Text chyby bude obsahovat zprávu podobnou následující:

  • The requested page cannot be accessed because the related configuration data for the page is invalid.

  • The configuration section 'configSections' cannot be read because it is missing a section declaration.

Ve službě IIS 6 se aplikaci ve childwebapp složce také nepodaří spustit, ale ohlásí jinou chybu. Text chyby může například obsahovat následující informace:

  • The value for the 'compilerVersion' attribute in the provider options must be 'v4.0' or later if you are compiling for version 4.0 or later of the .NET Framework. To compile this Web application for version 3.5 or earlier of the .NET Framework, remove the 'targetFramework' attribute from the element of the Web.config file

K těmto scénářům dochází, protože informace o konfiguraci z nadřazené aplikace ve parentwebapp složce jsou součástí hierarchie konfiguračních informací, která určuje konečné sloučené nastavení konfigurace, která jsou používána podřízenou webovou aplikací ve childwebapp složce . V závislosti na tom, zda je webová aplikace ASP.NET 4 spuštěna ve službě IIS 7 (nebo IIS 7.5) nebo iis 6, vrátí konfigurační systém služby IIS nebo systém kompilace ASP.NET 4 chybu.

Postup, který je potřeba provést k vyřešení tohoto problému a k tomu, aby podřízená aplikace ASP.NET 4 fungovala, závisí na tom, jestli aplikace ASP.NET 4 běží ve službě IIS 6 nebo iis 7 (nebo IIS 7.5).

Krok 1 (pouze IIS 7 nebo IIS 7.5)

Tento krok je nutný pouze v operačních systémech se službou IIS 7 nebo IIS 7.5, které zahrnují Windows Vista, Windows Server 2008, Windows 7 a Windows Server 2008 R2.

Přesuňte definici configSections v Web.config souboru nadřazené aplikace (aplikace, která běží ASP.NET 2.0 nebo ASP.NET 3.5) do kořenového Web.config souboru pro the.NET Framework 2.0. Nativní konfigurační systém IIS 7 a IIS 7.5 kontroluje element configSections při slučování hierarchie konfiguračních souborů. Přesunutí definice configSections ze souboru nadřazené webové aplikace Web.config do kořenového Web.config souboru efektivně skryje prvek z procesu sloučení konfigurace, ke kterému dochází pro podřízenou aplikaci ASP.NET 4.

V 32bitovém operačním systému nebo 32bitových fondech aplikací se kořenový Web.config soubor pro ASP.NET 2.0 a ASP.NET 3.5 obvykle nachází v následující složce:

C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG

V 64bitovém operačním systému nebo 64bitových fondech aplikací se kořenový Web.config soubor pro ASP.NET 2.0 a ASP.NET 3.5 obvykle nachází v následující složce:

C:\Windows\Microsoft.NET\Framework64\v2.0.50727\CONFIG

Pokud spustíte 32bitové i 64bitové webové aplikace na 64bitovém počítači, musíte přesunout element configSections nahoru do kořenovýchWeb.config souborů pro 32bitové i 64bitové systémy.

Když vložíte element configSections do kořenového Web.config souboru, vložte oddíl bezprostředně za element konfigurace . Následující příklad ukazuje, jak by měla vypadat horní část kořenového Web.config souboru po dokončení přesunu prvků.

Poznámka

V následujícím příkladu jsou řádky zabalené kvůli čitelnosti.

<?xml version="1.0" encoding="utf-8"?>
<!-- The root web configuration file -->
<configuration>
  <configSections>
    <sectionGroup name="system.web.extensions"
        type="System.Web.Configuration.SystemWebExtensionsSectionGroup, 
      System.Web.Extensions, Version=3.5.0.0, Culture=neutral,  
      PublicKeyToken=31BF3856AD364E35">

      <sectionGroup name="scripting"
        type="System.Web.Configuration.ScriptingSectionGroup, 
        System.Web.Extensions, Version=3.5.0.0, Culture=neutral, 
        PublicKeyToken=31BF3856AD364E35">

        <section name="scriptResourceHandler"
          type="System.Web.Configuration.ScriptingScriptResourceHandlerSection, 
          System.Web.Extensions, Version=3.5.0.0, Culture=neutral, 
          PublicKeyToken=31BF3856AD364E35" requirePermission="false"
          allowDefinition="MachineToApplication" />

        <sectionGroup name="webServices"
          type="System.Web.Configuration.ScriptingWebServicesSectionGroup,
          System.Web.Extensions, Version=3.5.0.0, Culture=neutral, 
          PublicKeyToken=31BF3856AD364E35">

          <section name="jsonSerialization"
            type="System.Web.Configuration.ScriptingJsonSerializationSection, 
            System.Web.Extensions, Version=3.5.0.0, Culture=neutral, 
            PublicKeyToken=31BF3856AD364E35" requirePermission="false"
            allowDefinition="Everywhere" />

          <section name="profileService"
            type="System.Web.Configuration.ScriptingProfileServiceSection, 
            System.Web.Extensions, Version=3.5.0.0, Culture=neutral, 
            PublicKeyToken=31BF3856AD364E35" requirePermission="false"
            allowDefinition="MachineToApplication" />
          <section name="authenticationService"
            type="System.Web.Configuration.ScriptingAuthenticationServiceSection, 
          System.Web.Extensions, Version=3.5.0.0, Culture=neutral, 
          PublicKeyToken=31BF3856AD364E35" requirePermission="false"
            allowDefinition="MachineToApplication" />

          <section name="roleService"
            type="System.Web.Configuration.ScriptingRoleServiceSection, 
          System.Web.Extensions, Version=3.5.0.0, Culture=neutral, 
          PublicKeyToken=31BF3856AD364E35" requirePermission="false"
            allowDefinition="MachineToApplication" />

        </sectionGroup>
      </sectionGroup>
    </sectionGroup>
  </configSections>

Krok 2 (všechny verze služby IIS)

Tento krok je povinný, pokud je podřízená webová aplikace ASP.NET 4 spuštěná ve službě IIS 6 nebo IIS 7 (nebo IIS 7.5).

Web.config Do souboru nadřazené webové aplikace se systémem ASP.NET 2 nebo ASP.NET 3.5 přidejte značku umístění, která explicitně určuje (pro systémy konfigurace služby IIS i ASP.NET), že položky konfigurace platí pouze pro nadřazenou webovou aplikaci. Následující příklad ukazuje syntaxi elementu location , který chcete přidat:

<location path="" inheritInChildApplications="false" >
  <!-- Additional settings -->
</location>

Následující příklad ukazuje, jak se značka location používá k zabalení všech oddílů konfigurace počínaje oddílem appSettings a končící částí system.webServer .

<location path="" inheritInChildApplications="false" >
  <appSettings />
  <connectionStrings />
  <system.web>
    <!-- Removed for brevity -->
  </system.web>
  <system.codedom>
    <!-- Removed for brevity -->
  </system.codedom>
  <system.webServer>
    <!-- Removed for brevity -->
</system.webServer>
</location>

Po dokončení kroků 1 a 2 se podřízené webové aplikace ASP.NET 4 spustí bez chyb.

Weby ASP.NET 4 se nespustí v počítačích s nainstalovaným serverem SharePoint

Webové servery se službou Web.config SharePoint mají soubor, který je nasazen v kořenovém adresáři webu služby SharePoint (například c:\inetpub\wwwroot\web.config pro výchozí web). SharePoint v tomto Web.config souboru nastaví vlastní úroveň částečné důvěryhodnosti s názvem WSS_Minimal.

Pokud se pokusíte spustit web ASP.NET 4, který je nasazen jako podřízený server tohoto typu webu služby SharePoint, zobrazí se následující chyba:

Could not find permission set named 'ASP.NET'.

K této chybě dochází, protože infrastruktura zabezpečení přístupu kódu (CAS) ASP.NET 4 hledá sadu oprávnění s názvem ASP.NET. Konfigurační soubor s částečným vztahem důvěryhodnosti, na který odkazuje WSS_Minimal, však neobsahuje žádné sady oprávnění s tímto názvem.

V současné době není k dispozici verze SharePointu, která by byla kompatibilní s ASP.NET. V důsledku toho byste se neměli pokoušet spustit web ASP.NET 4 jako podřízený web pod weby služby SharePoint.

Vlastnost HttpRequest.FilePath už neobsahuje hodnoty PathInfo.

Předchozí verze ASP.NET obsahovaly hodnotu PathInfo v hodnotě vrácené z různých vlastností souvisejících s cestou k souboru, včetně HttpRequest.FilePath, HttpRequest.AppRelativeCurrentExecutionFilePath a HttpRequest.CurrentExecutionFilePath. ASP.NET 4 již neobsahuje hodnotu PathInfo ve vrácených hodnotách z těchto vlastností. Místo toho jsou informace PathInfo k dispozici v HttpRequest.PathInfo. Představte si například následující fragment adresy URL:

/testapp/Action.mvc/SomeAction

Ve starších verzích ASP.NET mají vlastnosti HttpRequest následující hodnoty:

HttpRequest.FilePath: /testapp/Action.mvc/SomeAction

HttpRequest.PathInfo: (prázdné)

Ve ASP.NET 4 mají vlastnosti HttpRequest místo toho následující hodnoty:

HttpRequest.FilePath: /testapp/Action.mvc

HttpRequest.PathInfo: SomeAction

ASP.NET 2.0 Aplikace můžou generovat chyby HttpException odkazované na eurl.axd

Po povolení ASP.NET 4 ve službě IIS 6 můžou aplikace ASP.NET 2.0 spuštěné 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.

K této chybě dochází, protože když ASP.NET zjistí, že web je nakonfigurován pro použití ASP.NET 4, nativní komponenta ASP.NET 4 předá adresu URL bez rozšíření spravované části ASP.NET k dalšímu zpracování. Pokud jsou však virtuální adresáře pod webem ASP.NET 4 nakonfigurovány tak, aby používaly ASP.NET 2.0, výsledkem zpracování adresy URL bez rozšíření tímto způsobem bude upravená adresa URL, která obsahuje řetězec "eurl.axd". Tato upravená adresa URL se pak odešle do aplikace ASP.NET 2.0. ASP.NET 2.0 nelze rozpoznat formát eurl.axd. Proto se ASP.NET 2.0 pokusí najít soubor s názvem eurl.axd a spustit ho. Vzhledem k tomu, že žádný takový soubor neexistuje, požadavek selže s výjimkou HttpException .

Tento problém můžete obejít pomocí jedné z následujících možností.

Možnost 1

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.

Možnost 2

Pokud ke spuštění webu potřebujete ASP.NET 4, přesuňte všechny podřízené virtuální adresáře ASP.NET 2.0 na jiný web, který je mapován na ASP.NET 2.0.

Možnost 3

Pokud není praktické přemapovat web na ASP.NET 2.0 nebo změnit umístění virtuálního adresáře, explicitně zakažte zpracování adresy URL bez rozšíření v ASP.NET 4. Použijte následující postup:

  1. V registru systému Windows otevřete následující uzel:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\4.0.30319.0

  1. Vytvořte novou hodnotu DWORD s názvem EnableExtensionlessUrls.
  2. Nastavte EnableExtensionlessUrls na 0. Tím zakážete chování adresy URL bez rozšíření.
  3. Uložte hodnotu registru a zavřete editor registru.
  4. Spusťte nástroj příkazového řádku iisreset , který způsobí, že služba IIS přečte novou hodnotu registru.

Poznámka

Nastavení EnableExtensionlessUrls na hodnotu 1 umožňuje chování adresy URL bez rozšíření. Toto je výchozí nastavení, pokud není zadaná žádná hodnota.

Obslužné rutiny událostí nemusí být ve výchozím dokumentu ve službě IIS 7 nebo v integrovaném režimu služby IIS 7.5 aktivovány

ASP.NET 4 obsahuje úpravy, které mění způsob vykreslení atributu action elementu formuláře HTML při překladu adresy URL bez rozšíření na výchozí dokument. Příkladem adresy URL bez rozšíření, která se překládá na výchozí dokument, je http://contoso.com/, což vede k požadavku na http://contoso.com/Default.aspx.

ASP.NET 4 nyní vykresluje hodnotu atributu actionelementu formuláře HTML jako prázdný řetězec, když je požadavek na adresu URL bez rozšíření, která má namapovaný výchozí dokument. Například v dřívějších verzích ASP.NET by požadavek na http://contoso.com vyústit v požadavek na Default.aspx. V tomto dokumentu by se značka formuláře pro otevření vykreslovala jako v následujícím příkladu:

<form action="Default.aspx" />

V ASP.NET 4 je výsledkem požadavku http://contoso.com také požadavek na Default.aspxadresu . ASP.NET teď ale vykresluje značku formuláře pro otevření HTML , jak je znázorněno v následujícím příkladu:

<form action="" />

Tento rozdíl ve způsobu vykreslení atributu akce může způsobit drobné změny ve zpracování příspěvku formuláře službou IIS a ASP.NET. Pokud je atributem action prázdný řetězec, objekt IIS DefaultDocumentModule vytvoří podřízený požadavek na Default.aspx. Ve většině podmínek je tento podřízený požadavek pro kód aplikace transparentní a Default.aspx stránka 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řestanou správně fungovat během podřízeného požadavku. Pokud dojde k následujícím podmínkám, podřízený požadavek na Default.aspx dokument způsobí chybu nebo neočekávané chování:

  1. Do prohlížeče se odešle stránka .aspx s atributem action elementu formuláře nastaveným na hodnotu .
  2. Formulář se odešle zpět do ASP.NET.
  3. Spravovaný modul HTTP čte část těla entity. Modul například čte Request.Form nebo Request.Params. To způsobí, že se tělo entity požadavku POST načte do spravované paměti. Výsledkem je, že tělo entity již není k dispozici pro žádné moduly nativního kódu, které běží v integrovaném režimu služby IIS 7 nebo IIS 7.5.
  4. Objekt IIS DefaultDocumentModule se nakonec spustí a vytvoří podřízený požadavek na Default.aspx dokument. Vzhledem k tomu, že tělo entity již 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.
  5. Při spuštění kanálu HTTP pro podřízený požadavek se obslužná rutina pro .aspx soubory spustí během fáze provádění obslužné rutiny.
  6. Vzhledem k tomu, že neexistuje žádné tělo entity, neexistují žádné proměnné formuláře a stav zobrazení, a proto nejsou k dispozici žádné informace pro obslužnou rutinu stránky .aspx, která by určila, jaká událost (pokud existuje) by měla být vyvolána. V důsledku toho se nespustí žádná obslužná rutina události postback pro ovlivněnou stránku .aspx.

Toto chování můžete obejít následujícími způsoby:

  • Identifikujte modul HTTP, který přistupuje k tělu entity požadavku během výchozích požadavků na dokumenty, a určete, jestli je možné ho nakonfigurovat tak, aby se spouštěl pouze pro spravované požadavky. V integrovaném režimu pro IIS 7 i IIS 7.5 je možné moduly HTTP označit tak, aby běžely jenom pro spravované požadavky, a to přidáním následujícího atributu do položky modulu system.webServer/modules :

  • precondition="managedHandler"

  • Toto nastavení zakáže modul pro požadavky, které služby IIS 7 a IIS 7.5 považují za nespravované požadavky. U výchozích žádostí o dokumenty je první požadavek na adresu URL bez rozšíření. Služba IIS proto během počátečního zpracování požadavku nespouští žádné spravované moduly, které jsou označené podmínkou spravované obslužné rutiny. V důsledku toho spravované moduly nechtěně nepřečtou tělo entity, a proto je tělo entity stále dostupné a předává se podřízenému požadavku a výchozímu dokumentu.

  • Pokud problematické moduly HTTP musí běžet pro všechny požadavky (pro statické soubory, pro adresy URL bez rozšíření, které se přeloží na objekt DefaultDocumentModule , pro spravované požadavky atd.), upravte ovlivněné stránky .aspx explicitním nastavením vlastnosti Action stránky ovládacího prvku System.Web.UI.HtmlControls.HtmlForm na neprázdný řetězec. Pokud je Default.aspxnapříklad výchozí dokument , upravte kód stránky tak, aby vlastnost Action ovládacího prvku HtmlForm explicitně nastavil na Default.aspx.

Změny implementace ASP.NET Code Access Security (CAS)

ASP.NET 2.0 a navíc ASP.NET funkce přidané ve verzi 3.5 používají model zabezpečení přístupu kódu (CAS) rozhraní .NET Framework 1.1 a 2.0. Implementace CAS v ASP.NET 4 však byla podstatně přepracována. V důsledku toho můžou aplikace s částečnou důvěryhodností ASP.NET, které spoléhají na důvěryhodný kód spuštěný v globální mezipaměti sestavení (GAC), selhat s různými výjimkami zabezpečení. Aplikace s částečnou důvěryhodností, které se spoléhají na rozsáhlé úpravy zásad CAS počítače, můžou selhat také s výjimkami zabezpečení.

Pomocí nového atributu legacyCasModel v elementu konfigurace důvěryhodnosti můžete vrátit chování aplikací ASP.NET 1.1 a 2.0 ASP.NET 4, jak je znázorněno v následujícím příkladu:

<trust level= "Medium" legacyCasModel="true" />

Když se vrátíte ke starší verzi modelu CAS, povolí se následující stará chování CAS:

  • Zásady CAS počítače se dodržují.
  • V jedné doméně aplikace je povoleno více různých sad oprávnění.
  • Explicitní kontrolní výrazy oprávnění nejsou vyžadovány pro sestavení v GAC, která jsou vyvolána pouze v případě, že je v zásobníku pouze ASP.NET nebo jiný kód rozhraní .NET Framework.

V rozhraní .NET Framework 4 nelze vrátit jeden scénář: jiné než webové aplikace s částečnou důvěryhodností již nemohou volat určitá rozhraní API v System.Web.dll a System.Web.Extensions.dll. V předchozích verzích rozhraní .NET Framework bylo možné aplikacím, které nejsou webovou částečnou důvěryhodností, explicitně udělena oprávnění AspNetHostingPermission . Tyto aplikace by pak mohly používat System.Web.HttpUtility, typy v oborech názvů System.Web.ClientServices.* a typy související s členstvím, rolemi a profily. Volání těchto typů z jiných než webových aplikací s částečnou důvěryhodností již není podporováno v rozhraní .NET Framework 4.

Poznámka

Funkce HtmlEncode a HtmlDecodesystem.Web.HttpUtility třídy byla přesunuta do nové třídy System.Net.WebUtility rozhraní .NET Framework 4. Pokud se jednalo o jedinou ASP.NET funkce, která byla použita, upravte kód aplikace tak, aby místo toho používal novou třídu WebUtility .

Následuje souhrnný souhrn změn výchozí implementace CAS v ASP.NET 4:

  • ASP.NET domény aplikací jsou teď homogenní domény aplikací. V doméně aplikace jsou k dispozici pouze sady udělení částečné důvěryhodnosti a úplná důvěryhodnost.
  • ASP.NET sady udělení částečné důvěryhodnosti jsou nezávislé na zásadách CAS na úrovni podniku, počítače nebo uživatele.
  • ASP.NET sestavení dodávaná ve 3.5 a 3.5 SP1 byla převedena tak, aby používala model transparentnosti rozhraní .NET Framework 4.
  • Použití atributu ASP.NET AspNetHostingPermission bylo podstatně sníženo. Většina instancí tohoto atributu byla odebrána z veřejných rozhraní API ASP.NET.
  • Dynamicky kompilovaná sestavení vytvořená zprostředkovateli sestavení ASP.NET byla aktualizována tak, aby explicitně označovala sestavení jako transparentní.
  • Všechna ASP.NET sestavení jsou nyní označena tak, aby atribut APTCA byl respektován pouze v prostředích hostování webu. Částečně důvěryhodná prostředí pro hostování mimo web, jako je ClickOnce, nebudou moci volat ASP.NET sestavení.

Další informace o novém modelu zabezpečení přístupu kódu ASP.NET 4 naleznete v tématu Použití zabezpečení přístupu kódu v aplikacích ASP.NET na webu MSDN.

MembershipUser a další typy v oboru názvů System.Web.Security byly přesunuty.

Některé typy používané v ASP.NET členství byly přesunuty z System.Web.dll nového sestavení System.Web.ApplicationServices.dll. Typy byly přesunuty, aby se vyřešily závislosti vrstvení architektury mezi typy v klientovi a v rozšířených SKU rozhraní .NET Framework.

Webové projekty nemají problémy v důsledku přesunutí těchto typů, protože System.Web.ApplicationServices.dll byl přidán do seznamu odkazovaných sestavení, který je používán ve výchozím nastavení ASP.NET kompilační systém. Pokud upgradujete projekt webu vytvořený pomocí starší verze ASP.NET na ASP.NET 4 otevřením v sadě Visual Studio 2010, projekt se zkompiluje bez chyb.

Podobně platí, že pokud upgradujete projekt webové aplikace vytvořený ve starší verzi ASP.NET na ASP.NET 4 tím, že ho otevřete v sadě Visual Studio 2010, proces upgradu přidá odkaz na System.Web.ApplicationServices.dll do projektu. Proto upgradované projekty webových aplikací budou také zkompilovány bez chyb.

Kompilované (binární) soubory vytvořené pomocí dřívějších verzí ASP.NET budou také spuštěny bez chyb na ASP.NET 4, i když typy členství byly přesunuty do jiného sestavení. Informace o předávání typů byly přidány do ASP.NET 4 verze nástroje System.Web.dll , který automaticky směruje odkazy za běhu pro tyto typy do nového umístění pro typy.

Knihovny tříd, které používají konkrétní typy členství a které byly upgradovány z dřívějších verzí ASP.NET, se však nepodaří zkompilovat při použití v projektu ASP.NET 4. Projekt knihovny tříd se například nemusí podařit zkompilovat a nahlásit chybu, například následující:

  • The type 'System.Web.Security.MembershipUser' is defined in an assembly that is not referenced. You must add a reference to assembly 'System.Web.ApplicationServices, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'.

  • The type name 'MembershipUser' could not be found. This type has been forwarded to assembly 'System.Web.ApplicationServices, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. Consider adding a reference to that assembly.

Tento problém můžete vyřešit přidáním odkazu do projektu knihovny tříd, který System.Web.ApplicationServices.dll.

Následující seznam obsahuje typy System.Web.Security , které byly přesunuty z System.Web.dll do System.Web.ApplicationServices.dll:

  • System.Web.Security.MembershipCreateStatus
  • System.Web.Security.Membership.CreateUserException
  • System.Web.Security.MembershipPasswordException
  • System.Web.Security.MembershipPasswordFormat
  • System.Web.Security.MembershipProvider
  • System.Web.Security.MembershipProviderCollection
  • System.Web.Security.MembershipUser
  • System.Web.Security.MembershipUserCollection
  • System.Web.Security.MembershipValidatePasswordEventHandler
  • System.Web.Security.ValidatePasswordEventArgs
  • System.Web.Security.RoleProvider
  • System.Web.Configuration.MembershipPasswordCompatibilityMode

Změny ukládání výstupu do mezipaměti na různé * Hlavička HTTP

V ASP.NET 1.0 chyba způsobila, že stránky uložené v mezipaměti, které jako nastavení output-cache vygenerovaly Location="ServerAndClient" hlavičku Vary:* HTTP v odpovědi. To mělo za následek to, že klientské prohlížeče mají nikdy ukládat stránku do mezipaměti místně.

V ASP.NET 1.1 byla přidána metoda System.Web.HttpCachePolicy.SetOmitVaryStar , kterou můžete voláním potlačit hlavičku Vary:* . Tato metoda byla zvolena, protože změna vygenerované hlavičky HTTP byla v té době považována za potenciálně zásadní změnu. Vývojáři však byli zmateni chováním v ASP.NET a zprávy o chybách naznačují, že vývojáři neznají stávající chování SetOmitVaryStar .

V ASP.NET 4 jsme se rozhodli původní problém vyřešit. Hlavička Vary:* HTTP se už negeneruje z odpovědí, které určují následující direktivu:

<%@OutputCache Location="ServerAndClient" %>

V důsledku toho setOmitVaryStar již není potřeba k potlačení hlavičky Vary:* .

V aplikacích, které určují Location="ServerAndClient" v direktivě @ OutputCache na stránce, nyní uvidíte chování odvozené z názvu hodnoty atributu Location – to znamená, že stránky budou v mezipaměti v prohlížeči bez nutnosti volání SetOmitVaryStar metoda.

Pokud stránky ve vaší aplikaci musí generovat Vary:*, zavolejte metodu AppendHeader , jako v následujícím příkladu:

HttpResponse.AppendHeader("Vary","*");

Alternativně můžete změnit hodnotu atributu Location pro ukládání výstupu do mezipaměti na "Server".

Typy System.Web.Security pro Passport jsou zastaralé

Podpora passportu integrovaná do ASP.NET 2.0 je už několik let zastaralá a nepodporovaná kvůli změnám v Passportu (teď LiveID). Výsledkem je, že pět typů souvisejících s Passportem v System.Web.Security je nyní označeno atributem ObsoleteAttribute .

Vlastnost MenuItem.PopOutImageUrl nevykresluje obrázek v ASP.NET 4

Ve ASP.NET 3.5 vám vlastnost MenuItem.PopOutImageUrl umožňuje zadat adresu URL obrázku, který se zobrazí v položce nabídky a označuje, že položka nabídky má dynamickou podnabídku. Následující příklad ukazuje, jak zadat tuto vlastnost ve značkách v ASP.NET 3.5.

<asp:menu id="NavigationMenu"
    staticdisplaylevels="1"
    staticsubmenuindent="10" 
    orientation="Vertical" 
    target="_blank"  
    runat="server">
  <items>
    <asp:menuitem navigateurl="default2.aspx" 
        text="Home" 
        PopOutImageUrl="~/Images/Popout.gif"   
        tooltip="Home">
      <asp:menuitem navigateurl="default3.aspx"
          text="Movies"
          PopOutImageUrl="~/Images/Popout.gif"
          tooltip="Movies"> 
      </asp:menuitem>
    </asp:menuitem>
  </items>
</asp:menu>

V důsledku změny návrhu v ASP.NET 4, není vykreslen žádný výstup pro PopOutImageUrl , pokud je vlastnost nastavena pro MenuItem třídy. Místo toho musíte zadat adresu URL obrázku přímo v ovládacím prvku Menu pomocí vlastnosti StaticPopOutImageUrl nebo DynamicPopOutImageUrl vlastnost. Při práci se statickou nabídkou určuje vlastnost Menu.StaticPopOutImageUrl adresu URL obrázku, který se zobrazí, aby bylo možné označit, že položka statické nabídky má podnabídku, jak je znázorněno v následujícím příkladu:

<asp:menu id="NavigationMenu"
    staticdisplaylevels="1"
    staticsubmenuindent="10" 
    orientation="Vertical" 
    target="_blank" 
    StaticPopOutImageTextFormatString="More..."
    StaticPopOutImageUrl="Images/Popout.gif"   
    runat="server">
  <items>
    <asp:menuitem navigateurl="default2.aspx" 
        text="Home" 
        tooltip="Home">
      <asp:menuitem navigateurl="default3.aspx"
          text="Movies"
          tooltip="Movies"> 
      </asp:menuitem>
    </asp:menuitem>
  </items>
</asp:menu>

Pokud pracujete s dynamickou nabídkou, použijte vlastnost Menu.DynamicPopOutImageUrl k určení adresy URL obrázku, který označuje, že položka dynamické nabídky má podnabídku. Následující příklad je podobný předchozímu, ale ukazuje, jak nastavit DynamicPopOutImageUrl vlastnost dynamické nabídky.

<asp:menu id="NavigationMenu"
    staticdisplaylevels="1"
    staticsubmenuindent="10" 
    orientation="Vertical" 
    target="_blank" 
    DynamicPopOutImageTextFormatString="More..."
    DynamicPopOutImageUrl="Images/Popout.gif" 
    runat="server">
  <items>
    <asp:menuitem navigateurl="default2.aspx" 
        text="Home" 
        tooltip="Home">
      <asp:menuitem navigateurl="default3.aspx"
          text="Movies"
          tooltip="Movies"> 
      </asp:menuitem>
    </asp:menuitem>
  </items>
</asp:menu>

Pokud Menu.DynamicPopOutImageUrl vlastnost není nastavena a Menu.DynamicEnableDefaultPopOutImage vlastnost je nastavena na false, není zobrazen žádný obrázek. Podobně pokud StaticPopOutImageUrl vlastnost není nastavena a StaticEnableDefaultPopOutImage vlastnost je nastavena na false, nezobrazí se žádný obrázek.

Při nastavování cest pro tyto vlastnosti použijte lomítko (/) místo zpětného lomítka (). Další informace najdete v tématu Menu.StaticPopOutImageUrl a Menu.DynamicPopOutImageUrl se nepodaří vykreslit obrázky, pokud cesty obsahují zpětná lomítka jinde v tomto dokumentu.

V ASP.NET 4 se obrázky, které zadáte pomocí vlastností Menu.StaticPopOutImageUrl a Menu.DynamicPopOutImageUrl , nevykreslí, pokud cesta obsahuje zpětná lomítka (). Jedná se o změnu oproti dřívějším verzím ASP.NET.

Následující příklad Menu ovládacího prvku značky ukazuje StaticPopOutImageUrl sada vlastností pomocí cesty, která obsahuje zpětné lomítko. V ASP.NET 4 se obrázek zadaný ve vlastnosti nevykreslí.

<asp:menu id="NavigationMenu"
    staticdisplaylevels="1"
    staticsubmenuindent="10" 
    orientation="Vertical 
    target="_blank" 
    StaticPopOutImageTextFormatString="More..."
    StaticPopOutImageUrl="Images\Popout.gif"   
    runat="server">
  <items>
    <asp:menuitem navigateurl="default2.aspx" 
        text="Home" 
        tooltip="Home">
      <asp:menuitem navigateurl="default3.aspx"
          text="Movies"
          tooltip="Movies"> 
      </asp:menuitem>
    </asp:menuitem>
  </items>
</asp:menu>

Pokud chcete tento problém vyřešit, změňte hodnoty cesty zadané ve vlastnostech StaticPopOutImageUrl a DynamicPopOutImageUrl tak, aby používaly lomítka (/). Následující příklad ukazuje tuto změnu:

<asp:menu id="NavigationMenu"
    staticdisplaylevels="1"
    staticsubmenuindent="10" 
    orientation="Vertical 
    target="_blank" 
    StaticPopOutImageTextFormatString="More..."
    StaticPopOutImageUrl="Images/Popout.gif"   
    runat="server">
  <items>
    <asp:menuitem navigateurl="default2.aspx" 
        text="Home" 
        tooltip="Home">
      <asp:menuitem navigateurl="default3.aspx"
          text="Movies"
          tooltip="Movies"> 
      </asp:menuitem>
    </asp:menuitem>
  </items>
</asp:menu>

Aplikace, které byly migrovány z dřívějších verzí ASP.NET do ASP.NET 4, mohou být ovlivněny také, protože vlastnost MenuItem.PopOutImageUrl byla změněna. Další informace najdete v tématu Vlastnost MenuItem.PopOutImageUrl se v ASP.NET 4 v tomto dokumentu nevykreslí obrázek .

Disclaimer

Jedná se o předběžný dokument, který může být podstatně změněn před konečným komerčním vydáním softwaru popsaného v tomto dokumentu.

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Vzhledem k tomu, že společnost Microsoft musí reagovat na měnící se podmínky na trhu, neměla by být interpretována jako závazek společnosti Microsoft a společnost Microsoft nemůže zaručit přesnost jakýchkoli informací předložených po datu zveřejnění.

Tato kniha white paper je určena pouze pro informační účely. SPOLEČNOST MICROSOFT NEPOSKYTUJE ŽÁDNÉ ZÁRUKY, VÝSLOVNÉ, PŘEDPOKLÁDANÉ NEBO ZÁKONNÉ, POKUD JDE O INFORMACE V TOMTO DOKUMENTU.

Za dodržování všech platných zákonů o autorských právech zodpovídá uživatel. Bez omezení práv vyplývajících z autorských práv nesmí být žádná část tohoto dokumentu reprodukována, ukládána do vyhledávacího systému ani přenášena v jakékoli formě nebo jakýmkoli způsobem (elektronická, mechanická, fotokopie, záznam nebo jinak) ani za jakýmkoli účelem, bez výslovného písemného souhlasu společnosti Microsoft Corporation.

Společnost Microsoft může mít patenty, patentové přihlášky, ochranné známky, autorská práva nebo jiná práva k duševnímu vlastnictví, která se týkají předmětu tohoto dokumentu. S výjimkou případů výslovně uvedených v písemné licenční smlouvě se společností Microsoft vám poskytnutí tohoto dokumentu neposkytuje žádnou licenci k těmto patentům, ochranným známkám, autorským právům nebo jinému duševnímu vlastnictví.

Pokud není uvedeno jinak, jsou ukázkové společnosti, organizace, produkty, názvy domén, e-mailové adresy, loga, lidé, místa a události popsané v tomto dokumentu fiktivní a není zamýšleno ani by se nemělo odvozovat žádné spojení se skutečnou společností, organizací, produktem, názvem domény, e-mailovou adresou, logem, osobou, místem nebo událostí.

© 2010 Microsoft Corporation. All rights reserved.

Microsoft a Windows jsou registrované ochranné známky nebo ochranné známky společnosti Microsoft Corporation v USA a/nebo jiných zemích.

The names of actual companies and products mentioned herein may be the trademarks of their respective owners.