Condividi tramite

Modifiche importanti in ASP.NET 4

  • Articolo

Questo documento descrive le modifiche apportate per la versione .NET Framework versione 4 che possono potenzialmente influire sulle applicazioni create usando versioni precedenti, incluse le versioni ASP.NET 4 Beta 1 e Beta 2.

Scaricare questo white paper

Contenuto

Impostazione ControlRenderingCompatibilityVersion nel file di Web.config
Modifiche clientIDMode
HtmlEncode e UrlEncode ora codificare virgolette singole
Page (.aspx) Parser è più rigoroso
File di definizione del browser aggiornati
rimosso dal file di configurazione Web radice
Convalida richiesta
L'algoritmo hash predefinito è ora HMACSHA256
Errori di configurazione correlati alla nuova configurazione ASP.NET 4 radice
4 applicazioni figlio non possono iniziare quando in ASP.NET 2.0 o ASP.NET 3.5 applicazioni
4 siti Web non è possibile avviare nei computer in cui è installato SharePoint
La proprietà HttpRequest.FilePath non include più valori PathInfo
2.0 Applicazioni potrebbero generare errori httpException che fanno riferimento a eurl.axd
I gestori eventi potrebbero non essere generati in un documento predefinito in modalità integrata IIS 7 o IIS 7.5
Modifiche apportate all'implementazione della sicurezza di accesso al codice (CAS) ASP.NET
AppartenenzaUtente e altri tipi nello spazio dei nomi System.Web.Security sono stati spostati
Modifiche alla memorizzazione nella cache di output in variano * Intestazione HTTP
I tipi system.Web.security per Passport sono obsoleti
La proprietà MenuItem.PopOutImageUrl non riesce a eseguire il rendering di un'immagine in ASP.NET 4
Menu.StaticPopOutImageUrl e menu.DynamicPopOutImageUrl Non è possibile eseguire il rendering delle immagini quando i percorsi contengono barre rovesciate
Disclaimer

Impostazione ControlRenderingCompatibilityVersion nel file di Web.config

ASP.NET controlli sono stati modificati in .NET Framework versione 4 per consentire di specificare in modo più preciso il modo in cui esegue il rendering del markup. Nelle versioni precedenti di .NET Framework alcuni controlli emettono markup che non è stato possibile disabilitare. Per impostazione predefinita, ASP.NET 4 questo tipo di markup non viene più generato.

Se si usa Visual Studio 2010 per aggiornare l'applicazione da ASP.NET 2.0 o ASP.NET 3.5, lo strumento aggiunge automaticamente un'impostazione al Web.config file che mantiene il rendering legacy. Se tuttavia si aggiorna un'applicazione modificando il pool di applicazioni in IIS per impostare come destinazione .NET Framework 4, ASP.NET usa la nuova modalità di rendering per impostazione predefinita. Per disabilitare la nuova modalità di rendering, aggiungere l'impostazione seguente nel Web.config file:

<pages controlRenderingCompatibilityVersion="3.5" />

Le modifiche di rendering principali apportate al nuovo comportamento sono le seguenti:

  • I controlli Image e ImageButton non eseguono più il rendering di un border="0" attributo.
  • Per impostazione predefinita, la classe BaseValidator e i controlli di convalida che derivano da esso non eseguono più il rendering del testo rosso.
  • Il controllo HtmlForm non esegue il rendering di un attributo name .
  • Il controllo Table non esegue più il rendering di un border="0" attributo.
  • I controlli non progettati per l'input utente (ad esempio, il controllo Label ) non eseguono più il rendering dell'attributo se la disabled="disabled" proprietà Enabled è impostata su false (o se ereditano questa impostazione da un controllo contenitore).

Modifiche clientIDMode

L'impostazione ClientIDMode in ASP.NET 4 consente di specificare come ASP.NET genera l'attributo ID per gli elementi HTML. Nelle versioni precedenti di ASP.NET, il comportamento predefinito equivale all'impostazione AutoIDMode di ClientIDMode. Tuttavia, l'impostazione predefinita è ora Prevedibile.

Se si usa Visual Studio 2010 per aggiornare l'applicazione da ASP.NET 2.0 o ASP.NET 3.5, lo strumento aggiunge automaticamente un'impostazione al Web.config file che mantiene il comportamento delle versioni precedenti di .NET Framework. Se tuttavia si aggiorna un'applicazione modificando il pool di applicazioni in IIS per impostare come destinazione .NET Framework 4, ASP.NET usa la nuova modalità per impostazione predefinita. Per disabilitare la nuova modalità ID client, aggiungere l'impostazione seguente nel Web.config file:

<pages clientIDMode="AutoID" />

HtmlEncode e UrlEncode ora codificare virgolette singole

In ASP.NET 4, i metodi HtmlEncode e UrlEncode delle classi HttpUtility e HttpServerUtility sono stati aggiornati per codificare il carattere di virgolette singolo (') come segue:

  • Il metodo HtmlEncode codifica le istanze della virgolette singole come ' .
  • Il metodo UrlEncode codifica le istanze della virgolette singole come %27.

ASP.NET Page (.aspx) Parser è più rigoroso

Il parser di pagina per le pagine ASP.NET (file) e i controlli utente (.aspx.ascx file) è più restrittivo in ASP.NET 4 e rifiuterà più istanze di markup non valido. Ad esempio, i due frammenti di codice seguenti analizzano correttamente nelle versioni precedenti di ASP.NET, ma ora generano errori di parser in ASP.NET 4.

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

Si noti il punto e virgola non valido alla fine del tag HiddenField .

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

Si noti l'attributo di stile non chiuso che viene eseguito nell'attributo CssClass .

File di definizione del browser aggiornati

I file di definizione del browser sono stati aggiornati per includere informazioni su browser e dispositivi nuovi e aggiornati. Sono stati rimossi browser e dispositivi precedenti come Netscape Navigator e sono stati aggiunti browser e dispositivi più recenti come Google Chrome e Apple iPhone.

Se l'applicazione in uso contiene definizioni del browser personalizzate che derivano da una delle definizioni del browser rimosse, viene visualizzato un errore. Ad esempio, se la App_Browsers cartella contiene una definizione del browser che eredita dalla definizione del browser IE2, verrà visualizzato il messaggio di errore di configurazione seguente:

  • Impossibile trovare l'elemento browser o gateway con ID 'IE2'.

Nota

L'oggetto HttpBrowserCapabilities (esposto dalla proprietà Request.Browser della pagina) è basato sui file di definizioni del browser. Pertanto, le informazioni restituite accedendo a una proprietà di questo oggetto in ASP.NET 4 potrebbero essere diverse rispetto alle informazioni restituite in una versione precedente di ASP.NET.

È possibile ripristinare i file di definizione del browser precedenti copiando i file di definizione del browser dalla cartella seguente:

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

Copiare i file nella cartella corrispondente \CONFIG\Browsers per ASP.NET 4. Dopo la copia dei file eseguire lo strumento della riga di comando Aspnet_regbrowsers.exe.

System.Web.Mobile.dll rimosso dal file di configurazione Web radice

Nelle versioni precedenti di ASP.NET è stato incluso un riferimento all'assembly System.Web.Mobile.dll nel file radice Web.config nella sezione assembly . Per migliorare le prestazioni, il riferimento a questo assembly è stato rimosso.

L'assembly System.Web.Mobile.dll è incluso in ASP.NET 4, ma è deprecato. Se si desidera usare i tipi dall'assembly System.Web.Mobile.dll, aggiungere un riferimento a questo assembly al file radice Web.config o a un file dell'applicazione Web.config . Ad esempio, se si vuole usare uno dei controlli mobili (deprecati) ASP.NET dispositivi mobili, è necessario aggiungere un riferimento all'assembly System.Web.Mobile.dll al Web.config file.

ASP.NET convalida della richiesta

La funzionalità di convalida della richiesta in ASP.NET offre un determinato livello di protezione predefinita contro gli attacchi XSS (Cross-Site Scripting). Nelle versioni precedenti di ASP.NET, la convalida della richiesta è stata abilitata per impostazione predefinita. Tuttavia, si applica solo alle pagine ASP.NET (.aspx file e i relativi file di classe) e solo quando queste pagine sono in esecuzione.

In ASP.NET 4, per impostazione predefinita, la convalida della richiesta è abilitata per tutte le richieste, perché è abilitata prima della fase BeginRequest di una richiesta HTTP. Di conseguenza, la convalida della richiesta si applica alle richieste per tutte le risorse ASP.NET, non solo alle richieste di pagina con estensione aspx. Sono incluse richieste quali chiamate al servizio Web e gestori HTTP personalizzati. La convalida della richiesta è attiva anche quando i moduli HTTP personalizzati stanno leggendo il contenuto di una richiesta HTTP.

Di conseguenza, gli errori di convalida della richiesta potrebbero verificarsi per le richieste che in precedenza non attivavano errori. Per ripristinare il comportamento della funzionalità di convalida delle richieste ASP.NET 2.0, aggiungere l'impostazione seguente nel Web.config file:

<httpRuntime requestValidationMode="2.0" />

È tuttavia consigliabile analizzare eventuali errori di convalida delle richieste per determinare se i gestori, i moduli o altri input HTTP personalizzati potenzialmente non sicuri che potrebbero essere vettori di attacco XSS.

L'algoritmo hash predefinito è ora HMACSHA256

Per la protezione di dati come i cookie di autenticazione modulo e lo stato di visualizzazione, ASP.NET usa sia la crittografia che gli algoritmi hash. Per impostazione predefinita, ASP.NET 4 usa ora l'algoritmo HMACSHA256 per le operazioni hash sui cookie e sullo stato di visualizzazione. Versioni precedenti di ASP.NET usato l'algoritmo HMACSHA1 precedente.

Le applicazioni potrebbero essere interessate se si eseguono ASP.NET ambienti 2.0/ASP.NET 4 in cui i dati, ad esempio i cookie di autenticazione moduli, devono funzionare across.NET Versioni di Framework. Per configurare un'applicazione Web ASP.NET 4 per usare l'algoritmo HMACSHA1 precedente, aggiungere l'impostazione seguente nel Web.config file:

<machineKey validation="SHA1" />

I file di configurazione radice (il file e il machine.config file radice Web.config ) per .NET Framework 4 (e quindi ASP.NET 4) sono stati aggiornati per includere la maggior parte delle informazioni di configurazione della barra caldaia che in ASP.NET 3.5 sono state trovate nei file dell'applicazione Web.config . A causa della complessità dei sistemi di configurazione iis 7 e IIS 7.5 gestiti, l'esecuzione di applicazioni ASP.NET 3.5 in ASP.NET 4 e in IIS 7 e IIS 7.5 può causare errori di configurazione ASP.NET o IIS.

È consigliabile aggiornare le applicazioni ASP.NET 3.5 a ASP.NET 4 usando gli strumenti di aggiornamento del progetto in Visual Studio 2010, se pratico. Visual Studio 2010 modifica automaticamente il file dell'applicazione Web.config ASP.NET 3.5 per contenere le impostazioni appropriate per ASP.NET 4.

Tuttavia, è uno scenario supportato per eseguire ASP.NET applicazioni 3.5 usando .NET Framework 4 senza ricompilazione. In questo caso, potrebbe essere necessario modificare manualmente il file dell'applicazione Web.config prima di eseguire l'applicazione in .NET Framework 4 e in IIS 7 o IIS 7.5.

Le due sezioni successive descrivono le modifiche che potrebbe essere necessario apportare per combinazioni diverse di software.

Windows Vista SP1 o Windows Server 2008 SP1, in cui non sono installati né l'hotfix KB958854 né SP2. In questa configurazione, il sistema di configurazione IIS 7 unisce erroneamente la configurazione gestita di un'applicazione confrontando il file a livello Web.config di applicazione con i file ASP.NET 2.0 machine.config . Per questo motivo, i file a livello Web.config di applicazione di .NET Framework 3.5 o versioni successive devono avere una definizione di sezione di configurazione system.web.extensions (l'elemento) per non causare un errore di convalida iis 7.

Tuttavia, le voci di file a livello Web.config di applicazione modificate manualmente che non corrispondono esattamente alle definizioni di sezione di configurazione boilerplate originali introdotte con Visual Studio 2008 causeranno errori di configurazione ASP.NET. Le voci di configurazione predefinite generate da Visual Studio 2008 funzionano correttamente. Un problema comune è che i file modificati Web.config manualmente escono dagli attributi di configurazione allowDefinition e requirePermission trovati in varie definizioni di sezione di configurazione. Ciò causa una mancata corrispondenza tra la sezione di configurazione abbreviata nei file a livello Web.config di applicazione e la definizione completa nel file ASP.NET 4 machine.config . Di conseguenza, in fase di esecuzione, il sistema di configurazione ASP.NET 4 genera un errore di configurazione.

Windows Vista SP2, Windows Server 2008 SP2, Windows 7, Windows Server 2008 R2 e Windows Vista SP1 e Windows Server 2008 SP1 in cui è installato l'hotfix KB958854.

In questo scenario, il sistema di configurazione nativa IIS 7 e IIS 7.5 restituisce un errore di configurazione perché esegue un confronto di testo sull'attributo di tipo definito per un gestore della sezione di configurazione gestita. Poiché tutti i Web.config file generati da Visual Studio 2008 e Visual Studio 2008 SP1 hanno "3.5" nella stringa di tipo per i gestori di sezione di configurazione system.web.extensions (e correlati), e poiché il file ASP.NET 4 machine.config ha "4.0" nell'attributo di tipo per gli stessi gestori di sezioni di configurazione, le applicazioni generate in Visual Studio 2008 o Visual Studio 2008 SP1 hanno sempre esito negativo convalida della configurazione in IIS 7 e IIS 7.5.

Risoluzione di questi problemi

La soluzione alternativa per il primo scenario consiste nell'aggiornare il file a livello Web.config di applicazione includendo il testo di configurazione boilerplate da un Web.config file generato automaticamente da Visual Studio 2008.

Una soluzione alternativa per il primo scenario consiste nell'installare Service Pack 2 per Vista o Windows Server 2008 nel computer per correggere il comportamento di unione della configurazione non corretto del sistema di configurazione IIS. Tuttavia, dopo aver eseguito una di queste azioni, è probabile che l'applicazione verifichi un errore di configurazione a causa del problema descritto per il secondo scenario.

La soluzione alternativa per il secondo scenario consiste nell'eliminare o impostare come commento tutte le definizioni di sezione di configurazione system.web.extensions e le definizioni dei gruppi di sezioni di configurazione dal file a livello Web.config di applicazione. Queste definizioni sono in genere all'inizio del file a livello Web.config di applicazione e possono essere identificate dall'elemento configSections e dai relativi elementi figlio.

Per entrambi gli scenari, è consigliabile eliminare manualmente anche la sezione system.codedom , anche se questa operazione non è necessaria.

ASP.NET 4 applicazioni figlio non possono essere avviate quando in ASP.NET 2.0 o ASP.NET 3.5 applicazioni

Le applicazioni ASP.NET 4 configurate come elementi figlio di applicazioni che eseguono versioni precedenti di ASP.NET potrebbero non avviarsi a causa di errori di compilazione o di configurazione. Nell'esempio seguente viene illustrata una struttura di directory per un'applicazione interessata.

/parentwebapp (configurato per l'uso di ASP.NET 2.0 o ASP.NET 3.5)
/childwebapp (configurato per l'uso di ASP.NET 4)

L'applicazione nella childwebapp cartella non verrà avviata in IIS 7 o IIS 7.5 e verrà visualizzato un errore di configurazione. Il testo dell'errore includerà un messaggio simile al seguente:

  • 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.

In IIS 6 l'applicazione nella childwebapp cartella non verrà avviata, ma verrà visualizzato un errore diverso. Ad esempio, il testo dell'errore potrebbe indicare quanto segue:

  • 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

Questi scenari si verificano perché le informazioni di configurazione dell'applicazione padre nella parentwebapp cartella fanno parte della gerarchia di informazioni di configurazione che determinano le impostazioni di configurazione unite finali utilizzate dall'applicazione Web figlio nella childwebapp cartella. A seconda che l'applicazione Web ASP.NET 4 sia in esecuzione in IIS 7 (o IIS 7.5) o in IIS 6, il sistema di configurazione IIS o il sistema di compilazione ASP.NET 4 restituirà un errore.

I passaggi da seguire per risolvere questo problema e per ottenere il funzionamento dell'applicazione figlio ASP.NET 4 dipendono dal fatto che l'applicazione ASP.NET 4 venga eseguita in IIS 6 o in IIS 7 (o IIS 7.5).

Passaggio 1 (solo IIS 7 o IIS 7.5)

Questo passaggio è necessario solo nei sistemi operativi che eseguono IIS 7 o IIS 7.5, che include Windows Vista, Windows Server 2008, Windows 7 e Windows Server 2008 R2.

Spostare la definizione configSections nel Web.config file dell'applicazione padre (l'applicazione che esegue ASP.NET 2.0 o ASP.NET 3.5) nel file radice Web.config per the.NET Framework 2.0. Il sistema di configurazione nativa IIS 7 e IIS 7.5 analizza l'elemento configSections quando unisce la gerarchia dei file di configurazione. Lo spostamento della definizione configSections dal file dell'applicazione Web.config Web padre al file radice Web.config nasconde efficacemente l'elemento dal processo di unione di configurazione che si verifica per l'applicazione figlio ASP.NET 4.

In un sistema operativo a 32 bit o per pool di applicazioni a 32 bit, il file radice Web.config per ASP.NET 2.0 e ASP.NET 3.5 si trova normalmente nella cartella seguente:

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

In un sistema operativo a 64 bit o per i pool di applicazioni a 64 bit, il file radice Web.config per ASP.NET 2.0 e ASP.NET 3.5 si trova normalmente nella cartella seguente:

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

Se si eseguono sia applicazioni Web a 32 bit che a 64 bit in un computer a 64 bit, è necessario spostare l'elemento configSections in file radice Web.config sia per i sistemi a 32 bit che per i sistemi a 64 bit.

Quando si inserisce l'elemento configSections nel file radice Web.config , incollare la sezione immediatamente dopo l'elemento di configurazione . Nell'esempio seguente viene illustrato l'aspetto della parte superiore del file radice Web.config al termine dello spostamento degli elementi.

Nota

Nell'esempio seguente le righe sono state disposte per la leggibilità.

<?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>

Passaggio 2 (tutte le versioni di IIS)

Questo passaggio è necessario se l'applicazione Web figlio ASP.NET 4 è in esecuzione in IIS 6 o in IIS 7 (o IIS 7.5).

Web.config Nel file dell'applicazione Web padre in esecuzione ASP.NET 2 o ASP.NET 3.5 aggiungere un tag di posizione che specifica in modo esplicito (sia per IIS che per ASP.NET sistemi di configurazione) che le voci di configurazione si applicano solo all'applicazione Web padre. Nell'esempio seguente viene illustrata la sintassi dell'elemento location da aggiungere:

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

L'esempio seguente mostra come viene usato il tag location per eseguire il wrapping di tutte le sezioni di configurazione che iniziano con la sezione appSettings e terminano con la sezione 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>

Dopo aver completato i passaggi 1 e 2, le applicazioni Web figlio ASP.NET 4 verranno avviate senza errori.

ASP.NET 4 siti Web non è possibile avviare nei computer in cui è installato SharePoint

I server Web che eseguono SharePoint hanno un Web.config file distribuito nella radice di un sito Web di SharePoint, c:\inetpub\wwwroot\web.config ad esempio per sito Web predefinito. In questo Web.config file, SharePoint imposta un livello di attendibilità parziale personalizzato denominato WSS_Minimal.

Se si tenta di eseguire un sito Web ASP.NET 4 distribuito come figlio di questo tipo di sito Web di SharePoint, verrà visualizzato l'errore seguente:

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

Questo errore si verifica perché l'infrastruttura di sicurezza dall'accesso di codice (CAS) ASP.NET 4 cerca un set di autorizzazioni denominato ASP.NET. Tuttavia, il file di configurazione parzialmente attendibile a cui fa riferimento WSS_Minimal non contiene set di autorizzazioni con tale nome.

Attualmente non è disponibile una versione di SharePoint compatibile con ASP.NET. Di conseguenza, non è consigliabile tentare di eseguire un sito Web ASP.NET 4 come sito figlio sotto i siti Web di SharePoint.

La proprietà HttpRequest.FilePath non include più valori PathInfo

Le versioni precedenti di ASP.NET includevano un valore PathInfo nel valore restituito da varie proprietà correlate al percorso del file, tra cui HttpRequest.FilePath, HttpRequest.AppRelativeCurrentExecutionFilePath e HttpRequest.CurrentExecutionFilePath. ASP.NET 4 non include più il valore PathInfo nei valori restituiti da queste proprietà. Le informazioni PathInfo sono invece disponibili in HttpRequest.PathInfo. Considerare ad esempio il frammento di URL seguente:

/testapp/Action.mvc/SomeAction

Nelle versioni precedenti di ASP.NET, le proprietà HttpRequest hanno i valori seguenti:

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

HttpRequest.PathInfo: (vuoto)

In ASP.NET 4, le proprietà HttpRequest hanno invece i valori seguenti:

HttpRequest.FilePath: /testapp/Action.mvc

HttpRequest.PathInfo: SomeAction

ASP.NET applicazioni 2.0 potrebbero generare errori HttpException che fanno riferimento a eurl.axd

Dopo l'abilitazione di ASP.NET 4 in IIS 6, le applicazioni ASP.NET 2.0 in esecuzione su IIS 6 (in Windows Server 2003 o Windows Server 2003 R2) possono generare errori come il seguente:

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

Questo errore si verifica perché quando ASP.NET rileva che un sito Web è configurato per l'uso di ASP.NET 4, un componente nativo di ASP.NET 4 passa un URL senza estensione alla parte gestita di ASP.NET per un'ulteriore elaborazione. Tuttavia, se le directory virtuali sottostanti a un sito Web ASP.NET 4 sono configurate per l'uso ASP.NET 2.0, l'elaborazione dell'URL senza estensione in questo modo genera un URL modificato contenente la stringa "eurl.axd". Questo URL modificato viene quindi inviato all'applicazione ASP.NET 2.0. ASP.NET 2,0 non è in grado di riconoscere il formato "eurl.axd". Pertanto, ASP.NET 2.0 tenta di trovare un file denominato eurl.axd ed eseguirlo. Poiché non esiste alcun file di questo tipo, la richiesta ha esito negativo con un'eccezione HttpException .

È possibile risolvere questo problema usando una delle opzioni seguenti.

Opzione 1

Se ASP.NET 4 non è necessario per eseguire il sito Web, eseguire nuovamente il mapping del sito per usare ASP.NET 2.0.

Opzione 2

Se ASP.NET 4 è necessario per eseguire il sito Web, spostare le directory virtuali ASP.NET 2.0 figlio in un sito Web diverso mappato a ASP.NET 2.0.

Opzione 3

Se non è pratico eseguire il mapping del sito Web a ASP.NET 2.0 o per modificare il percorso di una directory virtuale, disabilitare in modo esplicito l'elaborazione degli URL senza estensione in ASP.NET 4. Utilizzare la procedura seguente:

  1. Nel Registro di sistema di Windows aprire il nodo seguente:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\4.0.30319.0

  1. Creare un nuovo valore DWORD denominato EnableExtensionlessUrls.
  2. Impostare EnableExtensionlessUrls su 0. In questo modo viene disabilitato il comportamento dell'URL senza estensione.
  3. Salvare il valore del Registro di sistema e chiudere l'editor del Registro di sistema.
  4. Eseguire lo strumento da riga di comando iisreset , che determina la lettura del nuovo valore del Registro di sistema da parte di IIS.

Nota

L'impostazione di EnableExtensionlessUrls su 1 abilita il comportamento dell'URL senza estensione. Questa è l'impostazione predefinita se non viene specificato alcun valore.

I gestori eventi potrebbero non essere generati in un documento predefinito in modalità integrata IIS 7 o IIS 7.5

ASP.NET 4 include modifiche che modificano il modo in cui viene eseguito il rendering dell'attributo action dell'elemento del modulo HTML quando un URL senza estensione viene risolto in un documento predefinito. Un esempio di URL senza estensione che risolve in un documento predefinito è http://contoso.com/, generando una richiesta a http://contoso.com/Default.aspx.

ASP.NET 4 esegue ora il rendering del valore dell'attributo action dell'elemento del modulo HTML come stringa vuota quando viene effettuata una richiesta a un URL senza estensione con un documento predefinito mappato. Nelle versioni precedenti di ASP.NET, ad esempio, una richiesta a http://contoso.com genera una richiesta a Default.aspx. In tale documento viene eseguito il rendering del tag modulo di apertura come nell'esempio seguente:

<form action="Default.aspx" />

In ASP.NET 4, una richiesta a http://contoso.com restituisce anche una richiesta a Default.aspx. Tuttavia, ASP.NET ora esegue il rendering del tag modulo di apertura HTML come nell'esempio seguente:

<form action="" />

Questa differenza nel modo in cui viene eseguito il rendering dell'attributo action può causare piccole modifiche nel modo in cui un post modulo viene elaborato da IIS e ASP.NET. Quando l'attributo dell'azione è una stringa vuota, l'oggetto IIS DefaultDocumentModule creerà una richiesta figlio a Default.aspx. Nella maggior parte delle condizioni, questa richiesta figlio è trasparente al codice dell'applicazione e la Default.aspx pagina viene eseguita normalmente.

Tuttavia una potenziale interazione tra il codice gestito e la modalità integrata di IIS 7 o IIS 7.5 può interrompere il funzionamento corretto delle pagine gestite con estensione aspx durante la richiesta figlio. Se si verificano le condizioni seguenti, la richiesta figlio a un Default.aspx documento genererà un errore o un comportamento imprevisto:

  1. Una pagina aspx viene inviata al browser con l'attributo action dell'elemento form impostato su "".
  2. Il modulo viene pubblicato di nuovo in ASP.NET.
  3. Un modulo HTTP gestito legge una parte del corpo dell'entità. Ad esempio, un modulo legge Request.Form o Request.Params. Di conseguenza il corpo dell'entità della richiesta POST viene letto nella memoria gestita. Pertanto il corpo dell'entità non è più disponibile per i moduli di codice nativo che sono in esecuzione in modalità integrata IIS 7 o IIS 7.5.
  4. L'oggetto IIS DefaultDocumentModule viene eseguito e crea una richiesta figlio al Default.aspx documento. Tuttavia poiché il corpo dell'entità è già stato letto da un frammento di codice gestito, non è disponibile alcun corpo di entità da inviare alla richiesta figlio.
  5. Quando la pipeline HTTP viene eseguita per la richiesta figlio, il gestore per .aspx i file viene eseguito durante la fase di esecuzione del gestore.
  6. Poiché non è presente alcun corpo dell'entità, non sono presenti variabili di modulo e non esiste alcun stato di visualizzazione e pertanto non sono disponibili informazioni per il gestore di pagine .aspx per determinare l'evento (se presente) deve essere generato. Pertanto non viene eseguito nessun gestore dell'evento di postback per la pagina con estensione aspx interessata.

È possibile aggirare questo comportamento nei modi seguenti:

  • Identificare il modulo HTTP che accede al corpo dell'entità della richiesta durante le richieste di documenti predefinite e determinare se può essere configurato per l'esecuzione solo per le richieste gestite. In modalità integrata per IIS 7 e IIS 7.5, i moduli HTTP possono essere contrassegnati per l'esecuzione solo per le richieste gestite aggiungendo l'attributo seguente alla voce system.webServer/modules del modulo:

  • precondition="managedHandler"

  • Questa impostazione disabilita il modulo per le richieste che IIS 7 e IIS 7.5 determinano come non essere richieste gestite. Per le richieste di documento predefinite, la prima richiesta è un URL senza estensione. Pertanto, IIS non esegue moduli gestiti contrassegnati con una precondizione del gestore gestito durante l'elaborazione iniziale della richiesta. Di conseguenza, i moduli gestiti non leggeranno accidentalmente il corpo dell'entità e quindi il corpo dell'entità è ancora disponibile e viene passato insieme alla richiesta figlio e al documento predefinito.

  • Se i moduli HTTP problematici devono essere eseguiti per tutte le richieste (per i file statici, per gli URL senza estensione che si risolvono all'oggetto DefaultDocumentModule , per le richieste gestite e così via), modificare le pagine aspx interessate impostando in modo esplicito la proprietà Action del controllo System.Web.UI.HtmlControls.HtmlForm della pagina su una stringa non vuota. Ad esempio, se il documento predefinito è Default.aspx, modificare il codice della pagina per impostare in modo esplicito la proprietà Action del controllo HtmlForm su "Default.aspx".

Modifiche apportate all'implementazione della sicurezza di accesso al codice (CAS) ASP.NET

ASP.NET 2.0 e per estensione le funzionalità di ASP.NET aggiunte nella versione 3.5, usare il modello .NET Framework 1.1 e 2.0 code access security (CAS). Tuttavia l'implementazione di CAS in ASP.NET 4 è stata modificata in modo sostanziale. Di conseguenza, le applicazioni di attendibilità parziale ASP.NET che si basano sul codice attendibile in esecuzione nella global assembly cache (GAC) potrebbero non riuscire con varie eccezioni di sicurezza. Le applicazioni di attendibilità parziale che si basano su modifiche estese ai criteri cas del computer potrebbero anche non riuscire con eccezioni di sicurezza.

È possibile ripristinare il trust parziale ASP.NET 4 applicazioni al comportamento di ASP.NET 1.1 e 2.0 usando il nuovo attributo legacyCasModelnell'elemento di configurazione trust, come illustrato nell'esempio seguente:

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

Quando si ripristina il modello cas legacy, sono abilitati i comportamenti cas precedenti seguenti:

  • I criteri cas del computer sono onorati.
  • Sono consentiti più set di autorizzazioni diversi in un singolo dominio applicazione.
  • Le asserzioni di autorizzazione esplicite non sono necessarie per gli assembly nella gaC richiamata quando solo ASP.NET o altro codice .NET Framework si trova nello stack.

Uno scenario non può essere ripristinato in .NET Framework 4: le applicazioni non parziali non possono più chiamare determinate API in System.Web.dll e System.Web.Extensions.dll. Nelle versioni precedenti di .NET Framework, è stato possibile che le applicazioni di attendibilità parziale non Web siano concesse in modo esplicito alle autorizzazioni AspNetHostingPermission . Queste applicazioni possono quindi usare System.Web.HttpUtility, tipi negli spazi dei nomi System.Web.ClientServices.* e tipi correlati all'appartenenza, ai ruoli e ai profili. La chiamata di questi tipi da applicazioni di attendibilità parziale non Web non è più supportata in .NET Framework 4.

Nota

La funzionalità HtmlEncode e HtmlDecode della classe System.Web.HttpUtility è stata spostata nella nuova classe .NET Framework 4 System.Net.WebUtility. Se si tratta dell'unica funzionalità ASP.NET usata, modificare il codice dell'applicazione per usare invece la nuova classe WebUtility .

Di seguito è riportato un riepilogo generale delle modifiche apportate all'implementazione cas predefinita in ASP.NET 4:

  • ASP.NET domini dell'applicazione sono ora domini applicazione omogenei. In un dominio dell'applicazione sono disponibili solo set di concessioni di attendibilità parziale e di attendibilità completa.
  • ASP.NET set di concessioni di trust parziale sono indipendenti da qualsiasi criterio CAS a livello aziendale, a livello di computer o a livello di utente.
  • ASP.NET assembly forniti in 3.5 e 3.5 SP1 sono stati convertiti in modo da usare il modello di trasparenza di .NET Framework 4.
  • L'uso dell'attributo ASP.NET AspNetHostingPermission è stato notevolmente ridotto. La maggior parte delle istanze di questo attributo è stata rimossa dalle API pubbliche ASP.NET.
  • Gli assembly compilati dinamicamente creati dai provider di compilazione ASP.NET sono stati aggiornati per contrassegnare in modo esplicito gli assembly come trasparenti.
  • Tutti gli assembly ASP.NET sono ora contrassegnati in modo che l'attributo APTCA sia onorato solo negli ambienti di hosting Web. Gli ambienti di hosting non Web parzialmente attendibili come ClickOnce non potranno chiamare in assembly ASP.NET.

Per altre informazioni sul nuovo modello di sicurezza di accesso al codice ASP.NET 4, vedere Uso della sicurezza di accesso al codice nelle applicazioni ASP.NET nel sito Web MSDN.

AppartenenzaUtente e altri tipi nello spazio dei nomi System.Web.Security sono stati spostati

Alcuni tipi usati nell'appartenenza ASP.NET sono stati spostati dal System.Web.dll nuovo assembly System.Web.ApplicationServices.dll. I tipi sono stati spostati per risolvere dipendenze dei livelli di architettura tra i tipi nel client e negli SKU estesi di .NET Framework.

I progetti del sito Web non presentano problemi a causa dello spostamento di questi tipi, perché System.Web.ApplicationServices.dll è stato aggiunto all'elenco di assembly a cui si fa riferimento che viene usato per impostazione predefinita dal sistema di compilazione ASP.NET. Se si aggiorna un progetto di sito Web creato usando una versione precedente di ASP.NET a ASP.NET 4 aprendolo in Visual Studio 2010, il progetto verrà compilato senza errori.

Analogamente, se si aggiorna un progetto applicazione Web creato in una versione precedente di ASP.NET a ASP.NET 4 aprendolo in Visual Studio 2010, il processo di aggiornamento aggiunge un riferimento a System.Web.ApplicationServices.dll al progetto. Pertanto, i progetti dell'applicazione Web aggiornati verranno compilati senza errori.

I file compilati (binari) creati usando le versioni precedenti di ASP.NET verranno eseguiti anche senza errori in ASP.NET 4, anche se i tipi di appartenenza sono stati spostati in un assembly diverso. Le informazioni sull'inoltro dei tipi sono state aggiunte alla versione ASP.NET 4 di System.Web.dll che instrada automaticamente i riferimenti di runtime per questi tipi alla nuova posizione per i tipi.

Tuttavia, le librerie di classi che usano tipi di appartenenza specifici e che sono state aggiornate dalle versioni precedenti di ASP.NET non riusciranno a compilare quando viene usato in un progetto ASP.NET 4. Ad esempio, un progetto di libreria di classi potrebbe non riuscire a compilare e segnalare un errore, ad esempio quanto segue:

  • 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.

È possibile risolvere questo problema aggiungendo un riferimento nel progetto della libreria di classi a System.Web.ApplicationServices.dll.

L'elenco seguente mostra i tipi System.Web.Security spostati da System.Web.dll a 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

Modifiche alla memorizzazione nella cache di output in variano * Intestazione HTTP

In ASP.NET 1.0, un bug ha causato la memorizzazione nella cache delle pagine memorizzate Location="ServerAndClient" nella cache come impostazione della cache di output per generare un'intestazione Vary:* HTTP nella risposta. Questa intestazione comunicava ai browser client di non memorizzare mai la pagina nella cache in locale.

In ASP.NET 1.1 è stato aggiunto il metodo System.Web.HttpCachePolicy.SetOmitVaryStar , che è possibile chiamare per eliminare l'intestazione Vary:* . Questo metodo è stato scelto perché la modifica dell'intestazione HTTP generata è stata considerata una modifica potenzialmente irreversibile al momento. Tuttavia, gli sviluppatori sono stati confusi dal comportamento in ASP.NET e i report di bug suggeriscono che gli sviluppatori non sono a conoscenza del comportamento setOmitVaryStar esistente.

In ASP.NET 4, la decisione è stata presa per risolvere il problema radice. L'intestazione Vary:* HTTP non viene più generata dalle risposte che specificano la direttiva seguente:

<%@OutputCache Location="ServerAndClient" %>

Di conseguenza, SetOmitVaryStar non è più necessario per eliminare l'intestazione Vary:* .

Nelle applicazioni che specificano Location="ServerAndClient" nella direttiva @ OutputCache in una pagina, verrà ora visualizzato il comportamento implicito dal nome del valore dell'attributo Location , ovvero le pagine saranno memorizzate nella cache nel browser senza richiedere di chiamare il metodo SetOmitVaryStar .

Se le pagine dell'applicazione devono generare Vary:*, chiamare il metodo AppendHeader , come nell'esempio seguente:

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

In alternativa, è possibile modificare il valore dell'attributo Location della memorizzazione nella cache di output in "Server".

I tipi system.Web.security per Passport sono obsoleti

Il supporto Passport integrato in ASP.NET 2.0 è stato obsoleto e non supportato per alcuni anni a causa delle modifiche in Passport (ora LiveID). Di conseguenza, i cinque tipi correlati a Passport in System.Web.Security sono ora contrassegnati con l'attributo ObsoleteAttribute .

La proprietà MenuItem.PopOutImageUrl non riesce a eseguire il rendering di un'immagine in ASP.NET 4

In ASP.NET 3.5, la proprietà MenuItem.PopOutImageUrl consente di specificare l'URL per un'immagine visualizzata in una voce di menu per indicare che la voce di menu ha un sottomenu dinamico. Nell'esempio seguente viene illustrato come specificare questa proprietà nel markup in 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>

In seguito a una modifica di progettazione in ASP.NET 4, non viene eseguito il rendering di alcun output per PopOutImageUrl se la proprietà è impostata per la classe MenuItem . È invece necessario specificare un URL immagine direttamente nel controllo Menu usando la proprietà StaticPopOutImageUrl o la proprietà DynamicPopOutImageUrl. Quando si usa un menu statico, la proprietà Menu.StaticPopOutImageUrl specifica l'URL per un'immagine visualizzata per indicare che la voce di menu statica ha un sottomenu, come illustrato nell'esempio seguente:

<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>

Se si usa un menu dinamico, usare la proprietà Menu.DynamicPopOutImageUrl per specificare l'URL per un'immagine che indica che una voce di menu dinamica ha un sottomenu. L'esempio seguente è simile a quello precedente, ma mostra come impostare la proprietà DynamicPopOutImageUrl per un menu dinamico.

<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>

Se la proprietà Menu.DynamicPopOutImageUrl non è impostata e la proprietà Menu.DynamicEnableDefaultPopOutImage è impostata su false, non viene visualizzata alcuna immagine. Analogamente, se la proprietà StaticPopOutImageUrl non è impostata e la proprietà StaticEnableDefaultPopOutImage è impostata su false, non viene visualizzata alcuna immagine.

Quando si impostano i percorsi per queste proprietà, usare una barra (/) anziché una barra rovesciata (). Per altre informazioni, vedere Menu.StaticPopOutImageUrl e Menu.DynamicPopOutImageUrl non riescono a eseguire il rendering delle immagini quando i percorsi contengono barre rovesciate altrove in questo documento.

In ASP.NET 4, le immagini specificate usando le proprietà Menu.StaticPopOutImageUrl e Menu.DynamicPopOutImageUrl non verranno visualizzate se il percorso contiene barre rovesciate (). Si tratta di una modifica rispetto alle versioni precedenti di ASP.NET.

Nell'esempio seguente di markup del controllo Menu viene illustrata la proprietà StaticPopOutImageUrl impostata usando un percorso contenente una barra rovesciata. In ASP.NET 4, l'immagine specificata nella proprietà non verrà visualizzata.

<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>

Per risolvere questo problema, modificare i valori del percorso specificati nelle proprietà StaticPopOutImageUrl e DynamicPopOutImageUrl per usare le barre (/). L'esempio seguente mostra questa modifica:

<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>

Si noti che le applicazioni di cui è stata eseguita la migrazione da versioni precedenti di ASP.NET a ASP.NET 4 potrebbero essere interessate anche perché la proprietà MenuItem.PopOutImageUrl è stata modificata. Per altre informazioni, vedere La proprietà MenuItem.PopOutImageUrl non riesce a eseguire il rendering di un'immagine in ASP.NET 4 altrove in questo documento.

Dichiarazione di non responsabilità

Il presente documento è una versione preliminare e può essere modificato in modo sostanziale prima della versione finale commerciale del software qui descritto.

Le informazioni contenute in questo documento rappresentano la posizione attuale di Microsoft Corporation sulle problematiche trattate alla data di pubblicazione. Poiché Microsoft deve rispondere alle mutevoli condizioni del mercato, questo non deve essere interpretato come un impegno da parte di Microsoft, che non garantisce l'accuratezza delle informazioni presentate dopo la data di pubblicazione.

Il presente white paper è fornito solo a scopi informativi. MICROSOFT NON RILASCIA ALCUNA GARANZIA, ESPRESSA, IMPLICITA O LEGALE, IN MERITO ALLE INFORMAZIONI DEL PRESENTE DOCUMENTO.

Il rispetto di tutte le applicabili leggi in materia di copyright è esclusivamente a carico dell'utente. Fermi restando tutti i diritti coperti da copyright, nessuna parte di questa documentazione potrà comunque essere riprodotta o inserita in un sistema di riproduzione o trasmessa in qualsiasi forma e con qualsiasi mezzo (in formato elettronico, meccanico, fotocopia, tramite registrazione o altro) per qualsiasi scopo, senza il permesso scritto di Microsoft Corporation.

Microsoft può essere titolare di brevetti, domande di brevetto, marchi, copyright o altri diritti di proprietà intellettuale relativi all'oggetto della presente documentazione. Salvo quanto espressamente previsto in un contratto scritto di licenza Microsoft, la consegna della presente documentazione non implica la concessione di alcuna licenza su tali brevetti, marchi, copyright o altra proprietà intellettuale.

Se non diversamente specificato, le società di esempio, le organizzazioni, i prodotti, i nomi di dominio, gli indirizzi di posta elettronica, i logo, le persone, i luoghi e gli eventi illustrati nel presente documento sono fittizie e non è prevista alcuna associazione con alcuna società, organizzazione, prodotto, nome di dominio, indirizzo di posta elettronica, logo, persona, luogo o evento è previsto o deve essere dedotto.

© 2010 Microsoft Corporation. Tutti i diritti sono riservati.

Microsoft e Windows sono marchi registrati o marchi di Microsoft Corporation negli Stati Uniti e/o in altri paesi.

I nomi di società e prodotti reali citati nel presente documento possono essere marchi dei rispettivi proprietari.