Condividi tramite

ASP.NET 4 modifiche di rilievo

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

Scarica questo white paper

Contenuto

ControlRenderingCompatibilityVersion Impostazione nel file Web.config
Modifiche di ClientIDMode
HtmlEncode e UrlEncode codificano ora virgolette singole
Parser delle pagine ASP.NET (.aspx) è più rigoroso
File di definizione del browser aggiornati
System.Web.Mobile.dll rimosso dal file radice di configurazione Web
Convalida delle richieste ASP.NET
L'algoritmo hash predefinito è ora HMACSHA256
Errori di configurazione correlati alla nuova configurazione radice di ASP.NET 4
Le applicazioni figlie ASP.NET 4 non si avviano quando si trovano sotto applicazioni ASP.NET 2.0 o ASP.NET 3.5
ASP.NET 4 siti Web non è possibile avviare nei computer in cui è installato SharePoint
La proprietà HttpRequest.FilePath non include più valori PathInfo
ASP.NET 2.0 Applicazioni potrebbero generare errori HttpException che fanno riferimento a eurl.axd
I gestori di eventi potrebbero non venire richiamati in un documento predefinito in modalità integrata di IIS 7 o IIS 7.5
Modifiche apportate all'implementazione della sicurezza dall'accesso al codice (CAS) ASP.NET
MembershipUser e altri tipi nello spazio dei nomi System.Web.Security sono stati spostati
Modifiche alla memorizzazione nella cache dell'output per Variare * 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 riescono a eseguire il rendering delle immagini quando i percorsi contengono barre rovesciate
Disclaimer

Impostazione di ControlRenderingCompatibilityVersion nel file 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 eseguono il rendering del markup. Nelle versioni precedenti di .NET Framework alcuni controlli emettono markup che non era possibile disabilitare. ASP.NET 4 non genera più questo tipo di markup per impostazione predefinita.

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 file che mantiene il Web.config rendering legacy. Tuttavia, se si aggiorna un'applicazione modificando il pool di applicazioni in IIS in modo che sia destinato a .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 dal nuovo comportamento sono le seguenti:

  • I controlli Image e ImageButton non eseguono più il rendering di un border="0" attributo.
  • La classe BaseValidator e i controlli di convalida che derivano da esso non eseguono più il rendering del testo rosso per impostazione predefinita.
  • 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 dell'utente (ad esempio, il controllo Etichetta ) 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 di 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. Tuttavia, se si aggiorna un'applicazione modificando il pool di applicazioni in IIS in modo che sia destinato a .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 adesso codificano anche le virgolette singole

In ASP.NET 4, i metodi HtmlEncode e UrlEncode delle classi HttpUtility e HttpServerUtility sono stati aggiornati per codificare la virgoletta singola (') come segue:

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

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

Il parser per le pagine ASP.NET (.aspx file) e i controlli utente (.ascx file) è più restrittivo in ASP.NET 4 e rifiuterà più frequenti di markup non valido. Ad esempio, i due frammenti di codice seguenti analizzano correttamente nelle versioni precedenti di ASP.NET, ma ora generano errori del 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 si prolunga 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 meno recenti, ad esempio Netscape Navigator, e sono stati aggiunti browser e dispositivi più recenti, ad esempio Google Chrome e Apple iPhone.

Se l'applicazione contiene definizioni di browser personalizzate che ereditano da una delle definizioni del browser rimosse, verrà 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 seguente messaggio di errore di configurazione:

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

Annotazioni

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 dalle 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 aver copiato i file, eseguire lo strumento da riga di comando Aspnet_regbrowsers.exe.

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

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 utilizzare tipi dell'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 desidera usare uno dei controlli per dispositivi mobili (deprecati) ASP.NET, è necessario aggiungere un riferimento all'assembly System.Web.Mobile.dll al Web.config file.

convalida della richiesta ASP.NET

La funzionalità di convalida delle richieste in ASP.NET fornisce un determinato livello di protezione predefinita da attacchi XSS (Cross-Site Scripting). Nelle versioni precedenti di ASP.NET, la convalida delle richieste è stata abilitata per impostazione predefinita. Tuttavia, si applica solo alle pagine ASP.NET (.aspx file e ai relativi file di classe) e solo quando tali pagine erano in esecuzione.

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

Di conseguenza, gli errori di convalida delle richieste potrebbero ora verificarsi per le richieste che in precedenza non attivavano errori. Per ripristinare il comportamento della funzionalità di convalida della richiesta 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 gestori, moduli o altri input HTTP personalizzati possono accedere a input HTTP potenzialmente non sicuri che potrebbero essere vettori di attacco XSS.

L'algoritmo hash predefinito è ora HMACSHA256

ASP.NET usa algoritmi di crittografia e hash per proteggere i dati, ad esempio i cookie di autenticazione basata su moduli e lo stato di visualizzazione. Per impostazione predefinita, ASP.NET 4 usa ora l'algoritmo HMACSHA256 per le operazioni hash sui cookie e sullo stato di visualizzazione. Nelle versioni precedenti di ASP.NET è stato usato l'algoritmo di HMACSHA1 precedente.

Le applicazioni potrebbero essere interessate se si eseguono ambienti misti ASP.NET 2.0/ASP.NET 4 in cui dati come i cookie di autenticazione con moduli devono funzionare attraverso le versioni del .NET Framework. Per configurare un'applicazione Web ASP.NET 4 per l'uso dell'algoritmo di HMACSHA1 precedente, aggiungere l'impostazione seguente nel Web.config file:

<machineKey validation="SHA1" />

I file di configurazione radice (il machine.config file e il 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 boilerplate trovate nei file dell'applicazione Web.config in ASP.NET 3.5. A causa della complessità dei sistemi di configurazione di 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 in modo da contenere le impostazioni appropriate per ASP.NET 4.

Tuttavia, è uno scenario supportato per eseguire ASP.NET 3.5 applicazioni usando .NET Framework 4 senza ricompilazione. In tal caso, potrebbe essere necessario modificare manualmente il file dell'applicazione prima di Web.config 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 diverse combinazioni di software.

Windows Vista SP1 o Windows Server 2008 SP1, in cui non sono installati né 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 versione successiva devono avere una definizione di sezione di configurazione system.web.extensions (l'elemento) per non causare un errore di convalida di 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 presenti 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 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 sezione di configurazione, le applicazioni generate in Visual Studio 2008 o Visual Studio 2008 SP1 non riescono sempre la 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 del gruppo di sezioni di configurazione dal file a livello di applicazione Web.config. Queste definizioni si trovano 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 figlie non possono essere avviate quando sono sotto le applicazioni di ASP.NET 2.0 o ASP.NET 3.5

Applicazioni ASP.NET 4 configurate come elementi figli di applicazioni che utilizzano versioni precedenti rispetto ad ASP.NET 4 potrebbero non essere avviate a causa di errori di configurazione o compilazione. 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 delle informazioni di configurazione che determinano le impostazioni di configurazione unite finali usate 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 effettivamente 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 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 applicazioni Web a 32 bit e 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.

Annotazioni

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 che esegue ASP.NET 2 o ASP.NET 3.5 aggiungere un tag di percorso che specifichi in modo esplicito (sia per IIS che per i sistemi di configurazione ASP.NET) 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 di posizione per eseguire il wrapping di tutte le sezioni di configurazione che iniziano con la sezione appSettings e terminando 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 possono essere avviati 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 cas (Code Access Security) di 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. Immagina, ad esempio, il seguente frammento di URL:

/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

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

Dopo aver abilitato ASP.NET 4 in IIS 6, ASP.NET applicazioni 2.0 eseguite in IIS 6 (in Windows Server 2003 o Windows Server 2003 R2) potrebbero generare errori come i seguenti:

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 inferiori a un sito Web di 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é tale file non esiste, 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 qualsiasi directory virtuale figlio di ASP.NET 2.0 in un sito Web diverso mappato su 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 esplicitamente l'elaborazione degli URL senza estensione in ASP.NET 4. A tale scopo, seguire questa procedura:

  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 fa sì che IIS legga il nuovo valore del Registro di sistema.

Annotazioni

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 di eventi potrebbero non essere attivati in un documento predefinito nella modalità integrata di 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 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 azione dell'elemento 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 verrà 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 risulta anche in una richiesta a Default.aspx. Tuttavia, ASP.NET ora esegue il rendering della tag form di apertura HTML come mostrato nell'esempio seguente:

<form action="" />

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

Tuttavia, una potenziale interazione tra codice gestito e IIS 7 o IIS 7.5 in modalità Integrata può causare l'interruzione del corretto funzionamento delle pagine .aspx gestite durante la richiesta figlia. 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'attributoaction dell'elemento modulo impostato su "".
  2. Il modulo viene pubblicato di nuovo in ASP.NET.
  3. Un modulo HTTP gestito legge parte del corpo dell'entità. Ad esempio, un modulo legge Request.Form o Request.Params. In questo modo il corpo dell'entità della richiesta POST viene letto nella memoria gestita. Di conseguenza, il corpo dell'entità non è più disponibile per i moduli di codice nativo in esecuzione in modalità integrata IIS 7 o IIS 7.5.
  4. L'oggetto IIS DefaultDocumentModule viene eseguito e crea una richiesta secondaria per il Default.aspx documento. Tuttavia, poiché il corpo della richiesta è già stato letto da una parte di codice gestito, non è disponibile alcun corpo della richiesta da inviare alla richiesta figlia.
  5. Quando la pipeline HTTP viene eseguita per la richiesta figlia, il gestore per i file .aspx viene eseguito durante la fase di esecuzione del gestore.
  6. Poiché non esiste alcun corpo dell'entità, non sono presenti variabili di modulo e non esiste alcuno stato di visualizzazione, pertanto non sono disponibili informazioni per il gestore di pagine .aspx per determinare quale evento (se presente) dovrebbe essere sollevato. Di conseguenza, nessuno dei gestori di eventi di postback viene eseguito per la pagina .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 richieste non gestite. Per le richieste di documenti predefinite, la prima richiesta è un URL senza estensione. Di conseguenza, 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 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 nell'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 dall'accesso al codice (CAS) ASP.NET

ASP.NET 2.0 e, per estensione, le funzionalità di ASP.NET aggiunte nella versione 3.5, usa il modello di Code Access Security (CAS) del .NET Framework 1.1 e 2.0. Tuttavia, l'implementazione del cas in ASP.NET 4 è stata sostanzialmente revisionata. Di conseguenza, le applicazioni con attendibilità parziale ASP.NET che si basano su codice attendibile in esecuzione nella Global Assembly Cache (GAC) potrebbero non riuscire con diverse eccezioni di sicurezza. Le applicazioni con attendibilità parziale che si basano su modifiche estese ai criteri CAS del computer potrebbero generare eccezioni di sicurezza.

È possibile ripristinare le applicazioni ASP.NET 4 a attendibilità parziale al comportamento di ASP.NET 1.1 e 2.0 usando il nuovo attributo legacyCasModel nell'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 precedenti di CAS seguenti:

  • I criteri CAS del computer vengono rispettati.
  • 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 richiamati 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 parzialmente attendibili non Web non possono più chiamare determinate API in System.Web.dll e System.Web.Extensions.dll. Nelle versioni precedenti di .NET Framework, è stato possibile concedere esplicitamente alle applicazioni non Web parzialmente attendibili le autorizzazioni AspNetHostingPermission . Queste applicazioni possono quindi usare System.Web.HttpUtility, i tipi negli spazi dei nomi System.Web.ClientServices.* e i tipi correlati all'appartenenza, ai ruoli e ai profili. La chiamata di questi tipi da applicazioni con attendibilità parziale non Web non è più supportata in .NET Framework 4.

Annotazioni

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

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

  • ASP.NET domini applicazione sono ora domini applicazione omogenei. In un dominio applicativo sono disponibili solo set di concessioni a bassa fiducia e a fiducia completa.
  • ASP.NET grant set a attendibilità parziale sono indipendenti da qualsiasi policy CAS aziendali, di macchina o di utente.
  • ASP.NET assembly forniti nella versione 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 ASP.NET pubbliche.
  • Gli assembly compilati dinamicamente creati dai provider di compilazione di ASP.NET sono stati aggiornati per contrassegnare esplicitamente gli assembly come trasparenti.
  • Tutti gli assembly ASP.NET sono ora contrassegnati in modo che l'attributo APTCA venga rispettato solo negli ambienti di hosting Web. Gli ambienti di hosting non Web parzialmente attendibili, come ClickOnce, non saranno in grado di chiamare gli assembly ASP.NET.

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

MembershipUser e altri tipi del namespace System.Web.Security sono stati spostati

Alcuni tipi utilizzati nella gestione degli utenti di ASP.NET sono stati spostati da System.Web.dll al nuovo assembly System.Web.ApplicationServices.dll. I tipi sono stati spostati per risolvere le dipendenze a livelli dell'architettura tra i tipi nel client e negli SKU di .NET Framework estesi.

I progetti di siti 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 utilizzato 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 di 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, anche i progetti di applicazioni Web aggiornati verranno compilati senza errori.

Anche i file compilati (binari) creati usando versioni precedenti di ASP.NET verranno eseguiti 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 in fase di esecuzione per questi tipi alla nuova posizione di questi tipi.

Tuttavia, le librerie di classi che usano tipi di appartenenza specifici e che sono state aggiornate da versioni precedenti di ASP.NET non riusciranno a compilare se usate in un progetto ASP.NET 4. Ad esempio, un progetto di libreria di classi potrebbe non riuscire a compilare e segnalare un errore simile al seguente:

  • 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 di 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 dell'output per variare l'intestazione HTTP

In ASP.NET 1.0, un bug ha causato alle pagine memorizzate nella cache, che specificavano Location="ServerAndClient" come impostazione della cache di output, di generare un'intestazione Vary:* HTTP nella risposta. Questo ha avuto l'effetto di indicare ai browser client di non memorizzare mai nella cache la pagina 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 di rilievo al momento. Tuttavia, gli sviluppatori sono stati confusi dal comportamento in ASP.NET e i report sui bug suggeriscono che gli sviluppatori non sono a conoscenza del comportamento esistente di SetOmitVaryStar .

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, si noterà ora il comportamento implicito dal nome del valore dell'attributo Location , ovvero le pagine saranno memorizzabili nella cache nel browser senza che sia necessario chiamare il metodo SetOmitVaryStar .

Se le pagine nell'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 di 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 di 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 della 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 di immagine direttamente nel controllo Menu usando la proprietà StaticPopOutImageUrl o la proprietà DynamicPopOutImageUrl . Quando si utilizza un menu statico, la proprietà Menu.StaticPopOutImageUrl specifica l'URL di 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 utilizza un menu dinamico, utilizzare la proprietà Menu.DynamicPopOutImageUrl per specificare l'URL di 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é un backslash (\). 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.

L'esempio seguente di markup del controllo Menu mostra la proprietà StaticPopOutImageUrl impostata usando un percorso che contiene 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 dei percorsi specificati nelle proprietà StaticPopOutImageUrl e DynamicPopOutImageUrl per usare barre oblique (/). 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à

Si tratta di un documento preliminare e può essere modificato sostanzialmente prima del rilascio commerciale finale del software descritto nel presente documento.

Le informazioni contenute in questo documento rappresentano la posizione attuale di Microsoft Corporation alla data della pubblicazione rispetto alle questioni trattate. Poiché Microsoft deve rispondere alle mutevoli condizioni di mercato, non deve essere interpretato come un impegno da parte di Microsoft e Microsoft non può garantire l'accuratezza delle informazioni presentate dopo la data di pubblicazione.

Questo white paper è solo a scopo informativo. MICROSOFT NON GARANTISCE IN ALCUN MODO, ESPRESSO, IMPLICITO O A TERMINI DI LEGGE, LE INFORMAZIONI CONTENUTE NEL PRESENTE DOCUMENTO.

La conformità a tutte le leggi sul copyright applicabili è responsabilità dell'utente. Senza limitare i diritti in materia di copyright, nessuna parte di questo documento può essere riprodotta, archiviata o introdotta in un sistema di recupero o trasmessa in qualsiasi forma o tramite qualsiasi mezzo (elettronico, meccanico, di registrazione o altro) o per qualsiasi scopo, senza l'autorizzazione scritta espressa di Microsoft Corporation.

Microsoft può disporre di brevetti, domande di brevetto, marchi, copyright o altri diritti di proprietà intellettuale relativi all'oggetto in questo documento. Salvo quanto espressamente previsto in qualsiasi contratto di licenza scritto di Microsoft, la fornitura di questo documento non concede alcuna licenza su questi brevetti, marchi, copyright o altre proprietà intellettuali.

Se non diversamente specificato, le aziende 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 fittizi e non è prevista alcuna associazione con alcuna società reale, organizzazione, prodotto, nome di dominio, indirizzo di posta elettronica, logo, persona, luogo o evento previsto o deve essere dedotto.

© Microsoft Corporation 2010. Tutti i diritti riservati.

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

I nomi delle società e dei prodotti effettivi indicati nel presente documento possono essere i marchi dei rispettivi proprietari.

  • Last updated on