ASP.NET 4 zásadních změn

Tento dokument popisuje změny provedené pro verzi rozhraní .NET Framework verze 4, které mohou 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

Nastavení ControlRenderingCompatibilityVersion v souboru Web.config
Změny ClientIDMode
HtmlEncode a UrlEncode teď kódují jednoduché uvozovky
ASP.NET (.aspx) je přísnější
Aktualizované definiční soubory prohlížeče
odebrané z kořenového konfiguračního souboru webu
ASP.NET
Výchozí algoritmus hash je teď HMACSHA256
Chyby konfigurace související s novou konfigurací ASP.NET 4 root
ASP.NET 4 podřízené aplikace se nespustí, když jsou aplikace pod ASP.NET 2.0 nebo ASP.NET 3.5
ASP.NET 4 weby se nespustí na počítačích, kde je nainstalovaný SharePoint
Vlastnost HttpRequest.FilePath již neobsahuje hodnoty PathInfo.
Aplikace ASP.NET 2.0 mohou generovat chyby typu HttpException, které odkazují na eurl.axd
Obslužné rutiny událostí nemusí být vyvolány ve výchozím dokumentu v integrovaném režimu služby IIS 7 nebo IIS 7.5.
Změny implementace zabezpečení přístupu kódu (CAS) ASP.NET
MembershipUser a další typy v namespace System.Web.Security byly přesunuty.
Změny ve výstupním ukládání do mezipaměti pro HTTP hlavičku Vary *
Typy v System.Web.Security pro Passport jsou zastaralé
Vlastnost MenuItem.PopOutImageUrl se nepodaří vykreslit obrázek v ASP.NET 4.
Menu.StaticPopOutImageUrl a Menu.DynamicPopOutImageUrl neumí vykreslit obrázky, pokud cesty obsahují zpětná lomítka
Prohlášení

Nastavení ControlRenderingCompatibilityVersion v souboru Web.config

ASP.NET ovládací prvky byly upraveny v rozhraní .NET Framework verze 4, aby bylo možné přesněji kontrolovat způsob, jakým vykreslují značkování. V předchozích verzích .NET Framework některé ovládací prvky generovaly značky, které nebylo možné zakázat. Ve výchozím nastavení v ASP.NET 4 se tento typ značení už negeneruje.

Pokud k upgradu aplikace ze sady ASP.NET 2.0 nebo ASP.NET 3.5 použijete Visual Studio 2010, nástroj automaticky přidá nastavení do Web.config souboru, který zachovává starší verzi vykreslování. Pokud však upgradujete aplikaci změnou fondu aplikací ve službě IIS tak, aby cílila na rozhraní .NET Framework 4, ASP.NET ve výchozím nastavení používá 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é přináší nové chování, jsou následující:

  • Ovládací prvky Image a ImageButton už nevykreslují atribut border="0".
  • BaseValidator – třídy a ověřovací ovládací prvky, které jsou z něj odvozené, už ve výchozím nastavení nevykreslují červený text.
  • Ovládací prvek HtmlForm nevykreslí atribut názvu .
  • Ovládací prvek Table už nevykreslí border="0" atribut.
  • Ovládací prvky, které nejsou určené pro uživatelský vstup (například ovládací prvek Popisek ), již nevykreslují disabled="disabled" atribut, pokud je vlastnost Enabled nastavena na false (nebo pokud dědí toto nastavení z ovládacího prvku kontejneru).

Změny clientIDMode

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

Pokud k upgradu aplikace ze sady ASP.NET 2.0 nebo ASP.NET 3.5 použijete Visual Studio 2010, nástroj automaticky přidá nastavení do Web.config souboru, které zachovává chování předchozích verzí rozhraní .NET Framework. Pokud však upgradujete aplikaci změnou fondu aplikací ve službě IIS tak, aby cílila 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 teď kódují jednoduché uvozovky

V ASP.NET 4 byly metody HtmlEncode a UrlEncode tříd HttpUtility a HttpServerUtility aktualizovány tak, aby kódovaly znak jednoduchých uvozovek ('):

  • HtmlEncode metoda kóduje instance jednoduché uvozovky jako ' .
  • Metoda UrlEncode kóduje instance jednoduché uvozovky jako %27.

Analyzátor ASP.NET (.aspx) je přísnější

Analyzátor stránek pro stránky ASP.NET (.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 teď v ASP.NET 4 způsobí chyby analyzátoru.

<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ý přechází do atributu CssClass.

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

Soubory definic prohlížeče byly aktualizovány tak, aby obsahovaly informace o nových a aktualizovaných prohlížečích a zařízeních. Starší prohlížeče a zařízení, jako je Netscape Navigator, byly odebrány a byly přidány novější prohlížeče a zařízení, jako je Google Chrome a Apple iPhone.

Pokud vaše aplikace obsahuje vlastní definice prohlížeče, které dědí z jedné z odebraných definic prohlížeče, zobrazí se chyba. Pokud App_Browsers například složka obsahuje definici prohlížeče, která dědí z definice prohlížeče IE2, zobrazí se následující chybová zpráva konfigurace:

  • Prvek prohlížeče nebo brány s ID IE2 nebyl nalezen.

Poznámka:

Objekt HttpBrowserCapabilities (který je vystavený 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 kořenového souboru konfigurace 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í. Aby se zlepšil výkon, odkaz na toto sestavení byl odebrán.

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

Ověření požadavku ASP.NET

Funkce ověřování požadavků v ASP.NET poskytuje určitou úroveň výchozí ochrany před útoky na skriptování 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 na ASP.NET stránky (.aspx soubory a jejich soubory třídy) a pouze v případě, že se tyto stránky spouštěly.

Ve výchozím nastavení je ve ASP.NET 4 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žadavku vztahuje na požadavky pro všechny prostředky ASP.NET, nejen .aspx žádosti o stránky. 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 může dojít k chybám ověření požadavků u požadavků, které dříve chyby nezpůsobovaly. Pokud se chcete vrátit k chování funkce ověření požadavku 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 existující obslužné rutiny, moduly nebo jiné vlastní kódy mají potenciálně nebezpečné vstupy HTTP, které by mohly být vektory útoku XSS.

Výchozí algoritmus hash je teď HMACSHA256

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

Vaše aplikace mohou být ovlivněny, pokud provozujete smíšená prostředí ASP.NET 2.0/ASP.NET 4, kde data, jako například cookies pro ověřování formulářů, musí fungovat napříč verzemi rozhraní .NET Framework. 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 často používaných konfiguračních informací, které byly v ASP.NET 3.5 nalezeny v souborech aplikace Web.config . Vzhledem ke složitosti spravovaných konfiguračních systémů IIS 7 a IIS 7.5 může spouštění aplikací ASP.NET 3.5 v rámci ASP.NET 4 a IIS 7 a IIS 7.5 vést k chybám konfigurace ASP.NET nebo služby 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 praktické. Visual Studio 2010 automaticky upraví soubor aplikace Web.config ASP.NET 3.5 tak, aby obsahoval odpovídající nastavení pro ASP.NET 4.

Jedná se však o podporovaný scénář spouštění aplikací ASP.NET 3.5 pomocí rozhraní .NET Framework 4 bez rekompilace. V takovém případě může být nutné 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é možná budete muset udělat pro různé kombinace softwaru.

Windows Vista SP1 nebo Windows Server 2008 SP1, kde nejsou nainstalovány opravy hotfix KB958854 ani SP2. V této konfiguraci nesprávně slučuje konfigurační systém služby IIS 7 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í mít soubory na úrovni Web.config aplikace z rozhraní .NET Framework 3.5 nebo novější definici konfiguračního oddílu system.web.extensions (element), aby nedošlo k selhání ověření služby IIS 7.

Ručně upravené položky souboru na úrovni Web.config aplikace, které přesně neodpovídají původním definicům oddílu konfigurace, které byly zavedeny se sadou Visual Studio 2008, však způsobí chyby konfigurace ASP.NET. (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í atribut allowDefinition a vyžadují atributy konfiguracePermission , které jsou nalezeny v různých definicích oddílu konfigurace. To způsobí neshodu mezi zkrácenou částí konfigurace v souborech na úrovni Web.config aplikace a úplnou definicí v souboru ASP.NET 4 machine.config . V důsledku toho v době běhu vyvolá konfigurační systém ASP.NET 4 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 nainstalována oprava hotfix KB958854.

V tomto scénáři vrátí nativní konfigurační systém služby IIS 7 a IIS 7.5 chybu konfigurace, protože provádí porovnání textu atributu type, který je definován pro obslužnou rutinu sekce spravované konfigurace. Protože všechny Web.config soubory vygenerované sadou Visual Studio 2008 a Visual Studio 2008 SP1 mají v řetězci typu pro obslužné rutiny oddílů konfigurace system.web.extensions (a související) hodnotu 3.5, a protože soubor ASP.NET 4 machine.config má v atributu typu pro stejné obslužné rutiny oddílů konfigurace "4.0", aplikace generované v sadě Visual Studio 2008 nebo Visual Studio 2008 SP1 vždy selžou 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 úrovně aplikace Web.config zahrnutím šablonové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, aby se vyřešilo nesprávné chování při slučování konfigurace konfiguračního systému služby IIS. Po provedení některé z těchto akcí se ale vaše aplikace pravděpodobně setká s chybou konfigurace kvůli problému popsanému ve druhém scénáři.

Alternativním řešením pro druhý scénář je odstranit nebo okomentovat všechny definice konfiguračních oddílů 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 mohou být identifikovány elementem configSections a jeho podřízenými objekty.

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

ASP.NET podřízené aplikace verze 4 se nespustí, pokud běží pod aplikacemi ASP.NET 2.0 nebo ASP.NET 3.5.

ASP.NET 4 aplikací, které jsou nakonfigurované jako podřízené položky aplikací, které používají starší verze ASP.NET, se nemusí spustit kvůli chybám konfigurace nebo kompilace. 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)

Aplikace ve childwebapp složce se nespustí ve službě IIS 7 nebo IIS 7.5 a oznámí chybu konfigurace. Text chyby bude obsahovat zprávu podobnou této:

  • 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 aplikace ve childwebapp složce také nespustí, ale nahlásí jinou chybu. Například text chyby může 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čují konečné sloučené nastavení konfigurace používané podřízenou webovou aplikací ve childwebapp složce. V závislosti na tom, jestli webová aplikace ASP.NET 4 běží ve službě IIS 7 (nebo IIS 7.5) nebo ve službě IIS 6, vrátí konfigurační systém služby IIS nebo ASP.NET 4 chybu.

Kroky, které je potřeba provést, abyste tento problém vyřešili a získali podřízenou aplikaci ASP.NET 4, aby 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 nezbytný pouze v operačních systémech, na kterých běží služba IIS 7 nebo IIS 7.5, včetně systémů 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 služby IIS 7 a IIS 7.5 prohledá element configSections při sloučení 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, který nastane pro podřízenou aplikaci ASP.NET 4.

V 32bitovém operačním systému nebo pro 32bitové fondy 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 pro 64bitové fondy 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 spouštíte 32bitové i 64bitové webové aplikace na 64bitovém počítači, musíte element configSections přesunout do kořenových Web.config souborů pro 32bitové i 64bitové systémy.

Když umístí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, když dokončíte přesunutí prvků.

Poznámka:

V následujícím příkladu byly řádky zabaleny pro čitelnost.

<?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 se vyžaduje, ať už je podřízená webová aplikace ASP.NET 4 spuštěna pomocí IIS 6 nebo IIS 7 (nebo IIS 7.5).

Web.config V souboru nadřazené webové aplikace, na které běží ASP.NET 2 nebo ASP.NET 3.5, přidejte značku umístění, která explicitně určuje (jak pro službu IIS, tak pro konfigurační systémy ASP.NET), které položky konfigurace platí pouze pro nadřazenou webovou aplikaci. Následující příklad ukazuje syntaxi prvku location , který chcete přidat:

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

Následující příklad ukazuje, jak se značka umístění používá k zabalení všech oddílů konfigurace počínaje oddílem appSettings a končí čá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é ASP.NET 4 webové aplikace spustí bez chyb.

ASP.NET 4 weby se nespustí na počítačích, na kterých je nainstalovaný SharePoint

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

Pokud se pokusíte spustit web ASP.NET 4 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 4 (CAS) ASP.NET hledá sadu oprávnění s názvem ASP.NET. Konfigurační soubor částečné důvěryhodnosti, na který odkazuje WSS_Minimal, ale neobsahuje žádné sady oprávnění s tímto názvem.

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

Vlastnost HttpRequest.FilePath již neobsahuje hodnoty PathInfo.

Předchozí verze ASP.NET zahrnovaly 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é)

V 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 mohou generovat chyby HttpException, které odkazují na eurl.axd

Po povolení ASP.NET 4 ve službě IIS 6 můžou ASP.NET aplikace 2.0, které běží ve službě IIS 6 (v systému Windows Server 2003 nebo Windows Server 2003 R2), můžou generovat chyby, jako například:

System.Web.HttpException: Path '/[yourApplicationRoot]/eurl.axd/[Value]' was not found.

K této chybě dochází, protože když ASP.NET zjistí, že je web nakonfigurovaný tak, aby používal 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 nakonfigurované tak, aby používaly ASP.NET 2.0, zpracování adresy URL bez rozšíření tímto způsobem způsobí upravenou adresu 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 ASP.NET 2.0 se pokusí najít soubor s názvem eurl.axd a spustit ho. Vzhledem k tomu, že neexistuje žádný takový soubor, požadavek selže s výjimkou HttpException .

Tento problém můžete vyřešit 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 je pro spuštění webu nutný ASP.NET 4, přesuňte všechny podřízené virtuální adresáře ASP.NET 2.0 na jiný web, který používá 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 se zakáže chování adresy URL bez přípony.
  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 1 umožňuje chování adresy URL bez rozšíření. Toto je výchozí nastavení, pokud není zadána žádná hodnota.

Obslužné prvky událostí nemusí být spuštěny ve výchozím dokumentu v režimu Integrace služby IIS 7 nebo IIS 7.5.

ASP.NET 4 obsahuje úpravy, které mění způsob vykreslení atributu akce elementu formuláře HTML, když se adresa URL bez rozšíření přeloží na výchozí dokument. Příkladem adresy URL bez rozšíření, která se přeloží na výchozí dokument, bude http://contoso.com/výsledkem požadavku na http://contoso.com/Default.aspx.

ASP.NET 4 nyní vykresluje hodnotu atributu action elementu form HTML jako prázdný řetězec, když je požadavek proveden na URL bez přípony, na kterou je namapován výchozí dokument. Například v dřívějších verzích ASP.NET by požadavek na http://contoso.com vedl k požadavku na Default.aspx. V tomto dokumentu by se počáteční form tag zobrazil jako v následujícím příkladu:

<form action="Default.aspx" />

V ASP.NET 4 žádost na http://contoso.com také vyústí v žádost na Default.aspx. ASP.NET ale teď vykresluje počáteční značku formuláře HTML jako v následujícím příkladu:

<form action="" />

Tento rozdíl v tom, jak se atribut akce vykresluje, může způsobit drobné změny způsobu zpracování příspěvku formuláře službou IIS a ASP.NET. Pokud je atribut akce prázdný řetězec, objekt IIS DefaultDocumentModule vytvoří podřízený požadavek na Default.aspx. Ve většině případů je tento dílčí požadavek transparentní pro kód aplikace a Default.aspx stránka běží normálně.

Potenciální interakce mezi spravovaným kódem a integrovaným režimem IIS 7 nebo IIS 7.5 však může způsobit, že spravované .aspx stránky přestanou během podřízeného požadavku správně fungovat. Pokud dojde k následujícím podmínkám, podřízený požadavek na Default.aspx dokument způsobí chybu nebo neočekávané chování:

  1. Do prohlížeče se odešle .aspx stránka s atributem akce elementu formuláře nastaveným na "".
  2. Formulář se odešle zpět do ASP.NET.
  3. Spravovaný modul HTTP čte část těla entity. Například modul přečte Request.Form nebo Request.Params. To způsobí, že tělo entity požadavku POST se načte do spravované paměti. V důsledku toho už tělo entity není k dispozici pro žádné nativní moduly kódu, které běží v integrovaném režimu SLUŽBY IIS 7 nebo IIS 7.5.
  4. Objekt IIS DefaultDocumentModule se nakonec spustí a vytvoří podřízený požadavek na Default.aspx dokument. Vzhledem k tomu, že tělo entity už bylo přečteno částí spravovaného kódu, není k dispozici žádné tělo entity, které by bylo možné odeslat podřízené žádosti.
  5. Když se kanál HTTP spustí pro podřízený požadavek, obslužná rutina pro .aspx soubory se spustí během fáze provádění obslužné rutiny.
  6. Vzhledem k tomu, že neexistuje žádné tělo entity, neexistují žádné proměnné formuláře a žádný stav zobrazení, a proto nejsou k dispozici žádné informace pro obsluhu .aspx stránky k určení, jaká událost (pokud existuje) má být vyvolána. V důsledku toho se nespustí žádná z obslužných rutin událostí postback pro ovlivněnou stránku .aspx.

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

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

  • precondition="managedHandler"

  • Toto nastavení zakáže modul pro požadavky, které služba IIS 7 a IIS 7.5 určuje jako neřízené požadavky. U výchozích žádostí o dokument je první požadavek na adresu URL bez rozšíření. Služba IIS proto nespouští žádné spravované moduly, které splňují podmínku spravovaných rutin, během počáteční fáze zpracování požadavku. Díky tomu spravované moduly nebudou náhodně číst tělo entity, takže tělo entity zůstává dostupné a je předáváno dál k 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é .aspx stránky explicitním nastavením vlastnosti Akce ovládacího prvku System.Web.UI.HtmlControls.HtmlForm stránky na neprázdný řetězec. Pokud je Default.aspxnapříklad výchozí dokument , upravte kód stránky tak, aby explicitně nastavil Vlastnost Akce ovládacího prvku HtmlForm na "Default.aspx".

Změny implementace zabezpečení přístupu kódu (CAS) ASP.NET

ASP.NET 2.0 a také funkce ASP.NET 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 se však podstatně přepracovala. 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í. Částečně důvěryhodné aplikace, které spoléhají na výrazné úpravy zásad CAS počítače, mohou také selhat kvůli bezpečnostním výjimkám.

Můžete vrátit aplikace ASP.NET 4 s částečnou důvěrou k chování ASP.NET 1.1 a 2.0 pomocí nového atributu legacyCasModel v elementu trust, 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, jsou povolena následující stará chování CAS:

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

Jeden scénář nelze obnovit v rozhraní .NET Framework 4: aplikace v částečně důvěryhodném režimu mimo web již nemohou volat určitá rozhraní API v knihovnách System.Web.dll a System.Web.Extensions.dll. V předchozích verzích rozhraní .NET Framework bylo možné, aby newebové částečně důvěryhodné aplikace byly explicitně pověřeny přístupovými právy k AspNetHostingPermission. Tyto aplikace pak mohou 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 aplikací s částečnou důvěryhodností mimo web se už v rozhraní .NET Framework 4 nepodporuje.

Poznámka:

Funkce HtmlEncode a HtmlDecodetřídy System.Web.HttpUtility byla přesunuta do nové třídy .NET Framework 4 System.Net.WebUtility . Pokud to byla jediná ASP.NET funkce, které se používaly, 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 aplikace jsou nyní homogenní domény aplikace. V doméně aplikace jsou k dispozici pouze sady oprávnění s částečnou důvěryhodností a úplnou důvěryhodností.
  • ASP.NET sady udělení částečné důvěryhodnosti jsou nezávislé na zásadách CAS na podnikové úrovni, na úrovni počítače nebo na úrovni uživatele.
  • ASP.NET sestavení dodávaná ve verzi 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á poskytovateli 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 byl atribut APTCA dodržen pouze v prostředích hostování webu. Částečně důvěryhodná prostředí pro hostování mimo webové prostředí, jako je ClickOnce, nebudou moci přistupovat k sestavením ASP.NET.

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.

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

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

Projekty webových stránek nemají problémy kvůli přesunutí těchto typů, protože System.Web.ApplicationServices.dll byl přidán do seznamu odkazovaných sestavení, která se ve výchozím nastavení používají v systému kompilace ASP.NET. Pokud upgradujete projekt webu vytvořený pomocí starší verze ASP.NET na ASP.NET 4 tak, že ho otevřete v sadě Visual Studio 2010, projekt se zkompiluje bez chyb.

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

Kompilované (binární) soubory vytvořené pomocí starších verzí ASP.NET se také spustí bez chyb v ASP.NET 4, i když byly typy členství přesunuty do jiného sestavení. Informace o předávání typů byly přidány do ASP.NET 4 ve verzi System.Web.dll, která automaticky směruje běhové odkazy pro tyto typy na nové umístění.

Knihovny tříd, které používají konkrétní typy členství a které byly upgradovány ze starších verzí ASP.NET, se však při použití v projektu ASP.NET 4 nepodaří zkompilovat. Projekt knihovny tříd může například selhat kompilaci a nahlásit chybu, například:

  • 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 obejít tak, že do projektu knihovny tříd přidáte odkaz na System.Web.ApplicationServices.dll.

Následující seznam ukazuje typy System.Web.Security , které byly přesunuty z System.Web.dll 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 pro různé hlavičky HTTP

V ASP.NET 1.0 způsobila chyba, že stránky uložené v mezipaměti, které měly nastavení výstupní mezipaměti Location="ServerAndClient", generovaly v odpovědi hlavičku HTTP Vary:*. To mělo vliv na to, že klientským prohlížečům říkáte, aby stránku nikdy neuchovávala místně do mezipaměti.

V ASP.NET 1.1 byla přidána metoda System.Web.HttpCachePolicy.SetOmitVaryStar, kterou lze volat k potlačení hlavičky Vary:*. Tato metoda byla zvolena, protože změna vygenerované hlavičky HTTP byla v tuto chvíli považována za potenciálně zásadní změnu. Vývojáři jsou však zmateni chováním v ASP.NET a zprávy o chybách naznačují, že vývojáři neví o stávajícím chování SetOmitVaryStar .

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

<%@OutputCache Location="ServerAndClient" %>

V důsledku toho už setOmitVaryStar není potřeba, aby bylo možné potlačit hlavičku Vary:* .

V aplikacích, které určují Location="ServerAndClient" direktiva @ OutputCache na stránce, uvidíte chování podle názvu hodnoty atributu Location – to znamená, že stránky budou uložené v mezipaměti v prohlížeči bez nutnosti volat metodu SetOmitVaryStar.

Pokud stránky v aplikaci musí generovat Vary:*, zavolejte Metodu AppendHeader , jak je znázorněno v následujícím příkladu:

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

Případně můžete změnit hodnotu atributu Umístění výstupního ukládání do mezipaměti na "Server".

Typy System.Web.Security pro Passport jsou zastaralé

Podpora Passportu integrovaná do ASP.NET 2.0 byla po několik let zastaralá a nepodporovaná kvůli změnám v Passportu (nyní LiveID). V důsledku toho se pět typů souvisejících s Passportem v System.Web.Security nyní označí atributem ObsoleteAttribute .

Vlastnost MenuItem.PopOutImageUrl se nepodaří vykreslit obrázek v ASP.NET 4.

Vlastnost MenuItem.PopOutImageUrl v ASP.NET 3.5 umožňuje zadat adresu URL obrázku, který se zobrazí v položce nabídky, a indikuje, že položka nabídky má dynamickou podnabídku. Následující příklad ukazuje, jak zadat tuto vlastnost v kódu 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 se pro PopOutImageUrl nevykreslí žádný výstup, pokud je vlastnost nastavena pro MenuItem třídy. Místo toho je nutné zadat adresu URL obrázku přímo v ovládacím prvku Nabídky pomocí StaticPopOutImageUrl vlastnost 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 dynamická položka 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, nezobrazí se žá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 místo zpětného lomítka (\) použijte lomítko (/). 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 zadané pomocí Vlastnosti Menu.StaticPopOutImageUrl a Menu.DynamicPopOutImageUrl nevykreslí, pokud cesta obsahuje zpětná lomítka (). Jedná se o změnu ze starších verzí ASP.NET.

Následující příklad ovládacího prvku Menu ukazuje vlastnost StaticPopOutImageUrl nastavenou 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>

Chcete-li tento problém opravit, 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>

Upozorňujeme, že aplikace migrované ze starších verzí ASP.NET na ASP.NET 4 mohou být ovlivněny také, protože vlastnost MenuItem.PopOutImageUrl byla změněna. Další informace naleznete v tématu Vlastnost MenuItem.PopOutImageUrl nevyvolá vykreslení obrázku v ASP.NET 4 jinde v tomto dokumentu.

Disclaimer

Toto je 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 zde.

Informace obsažené v tomto dokumentu představují aktuální pohled společnosti Microsoft Corporation na otázky popsané k datu zveřejnění. Vzhledem k tomu, že Společnost Microsoft musí reagovat na měnící se tržní podmínky, neměla by být interpretována jako závazek na straně společnosti Microsoft a společnost Microsoft nemůže zaručit přesnost jakýchkoli informací uvedených po datu zveřejnění.

Tento dokument White Paper je určen 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.

Dodržování všech příslušných zákonů o autorských právech je odpovědností uživatele. Bez omezení práv podle autorských práv nesmí být žádná část tohoto dokumentu reprodukována, uložena nebo zavedena do systému načítání nebo přenášena v libovolné podobě nebo jakýmkoli způsobem (elektronickým, mechanickým, fotokopií, záznamem nebo jinak) nebo pro jakýkoli účel bez výslovného písemného svolení společnosti Microsoft Corporation.

Microsoft může mít patenty, patentové aplikace, ochranné známky, autorská práva nebo jiná práva duševního vlastnictví, která se týkají předmětu tohoto dokumentu. S výjimkou výslovně uvedených v jakékoli písemné licenční smlouvě od Microsoftu vám vybavení tohoto dokumentu neposkytuje žádnou licenci na tyto patenty, ochranné známky, autorská práva nebo jiné duševní 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, které jsou zde uvedené, fiktivní a žádná asociace s žádnou skutečnou společností, organizací, produktem, názvem domény, e-mailovou adresou, logem, osobou, místem nebo událostí je zamýšlená nebo by měla být odvozena.

© 2010 Microsoft Corporation. Všechna práva vyhrazena.

Microsoft a Windows jsou registrované ochranné známky nebo ochranné známky společnosti Microsoft Corporation ve Spojených státech nebo v jiných zemích.

Názvy skutečných společností a produktů uvedených zde mohou být ochranné známky příslušných vlastníků.

  • Last updated on