Novità di ASP.NET 4 e Visual Web Developer

.NET Framework versione 4 include miglioramenti per ASP.NET 4 in aree mirate. Anche Visual Studio 2010 e Microsoft Visual Web Developer Express includono miglioramenti e nuove funzionalità per ottimizzare lo sviluppo di risorse Web. In questo documento viene fornita una panoramica di numerose delle nuove funzionalità incluse nella versione imminente.

In questo argomento sono incluse le seguenti sezioni:

In ASP.NET 4 sono state introdotte numerose funzionalità che migliorano i servizi ASP.NET di base, come la memorizzazione dell'output nella cache e l'archiviazione dello stato sessione.

Refactoring del file Web.config

Il file Web.config che contiene informazioni di configurazione per un'applicazione Web è aumentato notevolmente rispetto alle versioni precedenti di .NET Framework, in quanto sono state aggiunte nuove funzionalità. In .NET Framework 4 gli elementi di configurazione principali sono stati spostati nel file machine.config e le applicazioni ora ereditano tali impostazioni. In questo modo il file Web.config nelle applicazioni ASP.NET 4 può essere vuoto o specificare solo a quale versione del framework è destinata l'applicazione, come illustrato nell'esempio seguente:

<?xml version="1.0"?> 
<configuration> 
  <system.web> 
    <compilation targetFramework="4.0" /> 
  </system.web> 
</configuration>

Memorizzazione estensibile dell'output nella cache

Dopo il rilascio di ASP.NET 1.0, la memorizzazione dell'output nella cache ha consentito agli sviluppatori di archiviare in memoria l'output generato di pagine, controlli e risposte HTTP. In risposta alle richieste Web successive, ASP.NET è in grado di restituire il contenuto più rapidamente, recuperando l'output generato dalla memoria anziché generandolo di nuovo da zero. Questo approccio ha tuttavia una limitazione, in quanto il contenuto generato deve essere sempre archiviato in memoria. Nei server con un traffico intenso, i requisiti di memoria per la memorizzazione dell'output nella cache possono competere con i requisiti di memoria per altre parti di un'applicazione Web.

Con ASP.NET 4 viene aggiunta estensibilità alla memorizzazione dell'output nella cache, che consente di configurare uno o più provider di cache di output personalizzati. I provider di cache di output possono utilizzare qualsiasi meccanismo di archiviazione per rendere persistente il contenuto HTML. Queste opzioni di archiviazione possono includere dischi locali o remoti, archiviazione di tipo cloud e motori di cache distribuiti.

L'estensibilità dei provider di cache di output in ASP.NET 4 consente di progettare strategie di memorizzazione dell'output nella cache più aggressive e più intelligenti per i siti Web. È ad esempio possibile creare un provider di cache di output per la memorizzazione nella cache delle "prime 10" pagine di un sito in memoria, mentre le pagine con un traffico minore vengono memorizzate su disco. In alternativa, è possibile memorizzare nella cache ogni diversa combinazione di una pagina di cui è stato eseguito il rendering, utilizzando tuttavia una cache distribuita, in modo che il consumo di memoria venga scaricato dai server Web front-end.

È possibile creare un provider di cache di output personalizzato come classe derivata dal tipo OutputCacheProvider. È quindi possibile configurare il provider nel file Web.config utilizzando la nuova sottosezione providers dell'elemento outputCache.

Per ulteriori informazioni ed esempi in cui viene illustrato come configurare la cache di output, vedere Elemento outputCache per caching (schema delle impostazioni ASP.NET). Per ulteriori informazioni sulle classi che supportano la memorizzazione nella cache, vedere la documentazione relativa alle classi OutputCache e OutputCacheProvider.

Per impostazione predefinita, in ASP.NET 4 per tutti i controlli, le pagine di cui è stato eseguito il rendering e le risposte HTTP viene utilizzata la cache di output in memoria. L'attributo defaultProvider per ASP.NET è AspNetInternalProvider. È possibile modificare il provider di cache di output predefinito utilizzato per un'applicazione Web, specificando un nome di provider diverso per l'attributo defaultProvider.

È inoltre possibile selezionare provider di cache di output diversi per singoli controlli e singole richieste e specificare a livello di codice quale provider utilizzare. Per ulteriori informazioni, vedere il metodo HttpApplication.GetOutputCacheProviderName(HttpContext). Il modo più semplice per scegliere un provider di cache di output diverso per controlli utente Web diversi consiste nell'eseguire questa operazione in modo dichiarativo utilizzando il nuovo attributo providerName in una direttiva Page o Control, come illustrato nell'esempio seguente:

<%@ OutputCache Duration="60" VaryByParam="None" 
    providerName="DiskCache" %>

Applicazioni Web ad avvio automatico

Alcune applicazioni Web devono caricare elevate quantità di dati o eseguire operazioni dispendiose di elaborazione dell'inizializzazione prima di soddisfare la prima richiesta. Nelle versioni precedenti di ASP.NET, per queste situazioni è necessario ideare approcci personalizzati per attivare un'applicazione ASP.NET ed eseguire quindi il codice di inizializzazione durante l'esecuzione del metodo Application_Load nel file Global.asax.

Per risolvere le problematiche di questo scenario, è disponibile una nuova funzionalità di avvio automatico quando ASP.NET 4 viene eseguito in IIS 7.5 su un computer nel quale è installato Windows Server 2008 R2. Questa funzionalità consente di utilizzare un approccio controllato per l'avvio di un pool di applicazioni, l'inizializzazione di un'applicazione ASP.NET e la successiva accettazione delle richieste HTTP. È possibile eseguire le attività dispendiose di inizializzazione dell'applicazione prima di elaborare la prima richiesta HTTP.

Per ulteriori informazioni sulla nuova funzionalità di avvio automatico, vedere il white paper relativo alle novità di ASP.NET 4.

Reindirizzamento permanente di una pagina

Il contenuto nelle applicazioni Web viene spesso spostato nel corso della durata dell'applicazione. I collegamenti, ad esempio quelli restituiti dai motori di ricerca, possono pertanto risultare non aggiornati.

In ASP.NET gli sviluppatori hanno tradizionalmente gestito le richieste di URL obsoleti utilizzando il metodo Redirect per inoltrare una richiesta al nuovo URL. Il metodo Redirect genera tuttavia una risposta HTTP 302 (contenuto trovato), utilizzata per un reindirizzamento temporaneo. Questo comporta un round trip HTTP aggiuntivo.

In ASP.NET 4 è disponibile un metodo di supporto RedirectPermanent aggiuntivo che semplifica la generazione di risposte HTTP 301 (contenuto spostato in modo permanente), come illustrato nell'esempio seguente:

RedirectPermanent("/newpath/foroldcontent.aspx");

Il nuovo URL associato al contenuto viene archiviato dai motori di ricerca e da altri agenti utente che riconoscono i reindirizzamenti permanenti, eliminando il round trip non necessario eseguito dal browser per i reindirizzamenti temporanei.

Compressione dello stato sessione

Per impostazione predefinita, in ASP.NET sono disponibili due opzioni per l'archiviazione dello stato sessione in una Web farm. La prima opzione è rappresentata da un provider dello stato sessione che richiama un server dello stato sessione out-of-process. La seconda opzione è rappresentata da un provider dello stato sessione che archivia i dati in un database di Microsoft SQL Server.

Poiché entrambe le opzioni prevedono l'archiviazione delle informazioni sullo stato al di fuori del processo di lavoro di un'applicazione Web, lo stato sessione deve essere serializzato prima di venire inviato all'archivio remoto. Se nello stato sessione viene salvata un'elevata quantità di dati, la dimensione dei dati serializzati può diventare molto grande.

In ASP.NET 4 è stata introdotta una nuova opzione di compressione per entrambi i tipi di provider dello stato sessione out-of-process. Utilizzando questa opzione, le applicazioni con cicli CPU liberi nei server Web possono ottenere riduzioni sostanziali nella dimensione dei dati dello stato sessione serializzati.

È possibile impostare questa opzione utilizzando il nuovo attributo compressionEnabled dell'elemento sessionState nel file di configurazione. Quando l'opzione di configurazione compressionEnabled viene impostata su true, in ASP.NET lo stato sessione serializzato viene compresso e decompresso utilizzando la classe GZipStream.NET Framework.

Espansione dell'intervallo di URL consentiti

In ASP.NET 4 vengono introdotte nuove opzioni per espandere le dimensioni degli URL dell'applicazione. Nelle versioni precedenti di ASP.NET le lunghezze dei percorsi degli URL erano vincolate a un massimo di 260 caratteri, in base al limite del percorso dei file NTFS. In ASP.NET 4 è possibile aumentare o diminuire tale limite, secondo le esigenze specifiche per le applicazioni in uso, tramite due nuovi attributi dell'elemento di configurazione httpRuntime. Nell'esempio seguente vengono illustrati questi due nuovi attributi:

<httpRuntime maxRequestPathLength="260" maxQueryStringLength="2048" />

ASP.NET 4 consente inoltre di configurare i caratteri utilizzati dal controllo dei caratteri degli URL. Quando ASP.NET trova un carattere non valido nella parte di percorso di un URL, rifiuta la richiesta e genera un codice di stato HTTP 400 (Richiesta non valida). Nelle versioni precedenti di ASP.NET i controlli dei caratteri degli URL sono limitati a un set di caratteri fisso. In ASP.NET 4 è possibile personalizzare il set di caratteri validi utilizzando il nuovo attributo requestPathInvalidChars dell'elemento di configurazione httpRuntime, come illustrato nell'esempio seguente:

<httpRuntime requestPathInvalidChars="&lt;,&gt;,*,%,&amp;,:,\,?" />

Nella stringa assegnata a requestPathInvalidChars per impostazione predefinita, i caratteri minore di (<), maggiore di (>) ed e commerciale (&) sono codificati, perché il file Web.config è un file XML. Per impostazione predefinita, l'attributo requestPathInvalidChars definisce otto caratteri come non validi.

NotaNota

ASP.NET 4 rifiuta sempre i percorsi URL contenenti caratteri compresi nell'intervallo ASCII da 0x00 a 0x1F, perché sono caratteri URL non validi, secondo quanto definito nella RFC 2396 di IETF (vedere http://www.ietf.org/rfc/rfc2396.txt sul sito Web IETF). Nelle versioni di Windows Server in cui è in esecuzione IIS 6 o versione successiva, il driver di dispositivo del protocollo http.sys rifiuta automaticamente gli URL che contengono questi caratteri.

La funzionalità di convalida delle richieste di ASP.NET effettua la ricerca di stringhe utilizzate in genere negli attacchi di tipo cross-site scripting (XSS) nei dati delle richieste HTTP in arrivo. Se vengono trovate stringhe potenzialmente di tipo XSS, la stringa sospetta viene contrassegnata dalla funzionalità di convalida delle richieste che genera un errore. La funzionalità di convalida delle richieste incorporata genera un errore solo quando trova le più comuni stringhe utilizzate negli attacchi XSS. Precedenti tentativi di rendere più incisiva la convalida XSS hanno comportato un numero eccessivo di falsi positivi. È tuttavia possibile utilizzare, se lo si desidera, un livello di convalida delle richieste più incisivo. Viceversa è possibile limitare intenzionalmente i controlli XSS per pagine specifiche o per tipi di richieste specifici.

In ASP.NET 4 la funzionalità di convalida delle richieste è estensibile, in modo da consentire l'utilizzo di logica di convalida delle richieste personalizzata. Per estendere la funzionalità di convalida delle richieste, è necessario creare una classe derivata dalla nuova classe System.Web.Util.RequestValidator e configurare l'applicazione affinché utilizzi il tipo personalizzato (nella sezione httpRuntime del file Web.config). Per ulteriori informazioni, vedere System.Web.Util.RequestValidator.

Memorizzazione di oggetti nella cache ed estensibilità della memorizzazione di oggetti nella cache

Fin dalla prima versione, in ASP.NET è inclusa una potente cache oggetti in memoria (System.Web.Caching.Cache). L'implementazione della cache è divenuta comune al punto da essere utilizzata nelle applicazioni non Web. È tuttavia difficile che in un'applicazione Windows Forms o WPF sia incluso un riferimento a System.Web.dll solo perché sia in grado di utilizzare la cache oggetti di ASP.NET. Per rendere disponibile la funzionalità di memorizzazione nella cache per tutte le applicazioni, in .NET Framework 4 vengono introdotti un nuovo assembly, un nuovo spazio dei nomi, alcuni tipi di base e una concreta implementazione della memorizzazione nella cache. Il nuovo assembly System.Runtime.Caching.dll include una nuova API di memorizzazione nella cache nello spazio dei nomi System.Runtime.Caching. Lo spazio dei nomi include due set di classi di base:

  • Tipi astratti che forniscono gli elementi fondamentali per la compilazione di qualsiasi tipo di implementazione della cache personalizzata.

  • Un'implementazione concreta della cache oggetti in memoria (la classe MemoryCache).

La nuova classe MemoryCache è strettamente modellata in base alla cache di ASP.NET e condivide con ASP.NET gran parte della logica del motore di cache interno. Anche se le API pubbliche di memorizzazione nella cache incluse nello spazio dei nomi System.Runtime.Caching sono state aggiornate in modo da supportare lo sviluppo di cache personalizzate, se è stato utilizzato l'oggetto ASP.NET Cache, si noterà che le nuove API presentano concetti familiari.

Extensible HTML, URL e codifica dell'intestazione HTTP

In ASP.NET 4 è possibile creare routine di codifica personalizzate per le seguenti attività comuni di codifica del testo:

  • Codifica HTML.

  • Codifica URL.

  • Codifica di attributi HTML.

  • Codifica di intestazioni HTTP in uscita.

È possibile creare un codificatore personalizzato derivandolo dal nuovo tipo System.Web.Util.HttpEncoder, quindi configurando ASP.NET per l'utilizzo del tipo personalizzato nella sezione httpRuntime del file Web.config, come illustrato nell'esempio seguente:

<httpRuntime encoderType="Samples.MyCustomEncoder, Samples" />

Dopo aver configurato un codificatore personalizzato, ogni volta che vengono chiamati metodi di codifica pubblici della classe HttpUtility o HttpServerUtility in ASP.NET viene chiamata automaticamente l'implementazione della codifica personalizzata. Questo consente a una parte di un team di sviluppo Web di creare un codificatore personalizzato che implementa un'incisiva codifica dei caratteri, mentre il resto del team di sviluppo Web continua a utilizzare le API di codifica pubbliche di ASP.NET. Configurando a livello centrale un codificatore personalizzato nell'elemento httpRuntime, si avrà la garanzia che tutte le chiamate di codifica del testo dalle API di codifica pubbliche di ASP.NET vengano indirizzate tramite il codificatore personalizzato.

Monitoraggio delle prestazioni per singole applicazioni in un solo processo di lavoro

Per aumentare il numero di siti Web che è possibile ospitare su un singolo server, molti hoster eseguono più applicazioni ASP.NET in un solo processo di lavoro. Se tuttavia più applicazioni utilizzano un solo processo di lavoro condiviso, è difficile per gli amministratori del server identificare la singola applicazione nella quale si verificano problemi.

ASP.NET 4 sfrutta la nuova funzionalità di monitoraggio delle risorse introdotta da CLR. Per abilitare questa funzionalità, è possibile aggiungere il frammento di codice di configurazione XML seguente al file di configurazione aspnet.config.

<?xml version="1.0" encoding="UTF-8" ?> 
<configuration> 
  <runtime> 
    <appDomainResourceMonitoring enabled="true"/> 
  </runtime> 
</configuration> 

Il file aspnet.config si trova nella directory in cui è installato .NET Framework, non è il file web.config dell'applicazione. Una volta abilitata la funzionalità appDomainResourceMonitoring, diventano disponibili due nuovi contatori delle prestazioni nella categoria di prestazioni "Applicazioni ASP.NET": % Tempo processore gestito e Utilizzo memoria gestita. Entrambi questi contatori delle prestazioni utilizzano la nuova funzionalità di gestione delle risorse del dominio dell'applicazione CLR per tenere traccia del tempo CPU stimato e dell'utilizzo della memoria gestita delle singole applicazioni ASP.NET. Di conseguenza, con ASP.NET 4 gli amministratori dispongono ora di una visualizzazione più granulare dell'utilizzo delle risorse delle singole applicazioni in esecuzione in un solo processo di lavoro.

jQuery inclusa in Web Form e MVC

I modelli di Visual Studio per Web Form e per MVC includono la libreria open source jQuery. Quando si crea un nuovo sito Web o un progetto, viene creata una cartella Script contenente i seguenti file:

  • jQuery-1.4.1.js - Versione leggibile non minimizzata della libreria jQuery. La minimizzazione è la procedura mediante la quale vengono rimossi dal codice i caratteri non necessari per ridurne le dimensioni e migliorare i tempi di caricamento ed esecuzione.

  • jQuery-14.1.min.jss - Versione minimizzata della libreria jQuery.

  • jQuery-1.4.1-vsdoc.js. - File di documentazione di IntelliSense per la libreria jQuery.

Includere la versione non minimizzata di jQuery mentre si sviluppa un'applicazione. Includere la versione minimizzata di jQuery per le applicazioni di produzione.

Supporto della rete per la distribuzione di contenuti

La rete per la distribuzione di contenuti (CDN) di Microsoft Ajax consente di aggiungere facilmente script jQuery e AJAX ASP.NET alle applicazioni Web. È possibile, ad esempio, iniziare a utilizzare la libreria jQuery aggiungendo semplicemente un elemento script alla pagina che punta a Ajax.microsoft.com, come illustrato nell'esempio seguente:

<script src="http://ajax.microsoft.com/ajax/jquery/jquery-1.4.2.js" type="text/javascript"></script>

Sfruttando la rete CDN di Microsoft Ajax, è possibile migliorare significativamente le prestazioni delle applicazioni AJAX. I contenuti della rete CDN di Microsoft Ajax vengono memorizzati nella cache di server distribuiti in tutto il mondo. La rete CDN di Microsoft Ajax consente inoltre ai browser di riutilizzare i file JavaScript memorizzati nella cache per i siti Web presenti in domini diversi. La rete CDN di Microsoft Ajax supporta SSL (http://), in caso sia necessario presentare una pagina Web utilizzando Secure Sockets Layer.

Il controllo ASP.NET ScriptManager supporta la rete CDN di Microsoft Ajax. Impostare la proprietà EnableCdn come illustrato nell'esempio seguente per recuperare tutti i file JavaScript di ASP.NET Framework dalla rete CDN:

<asp:ScriptManager ID="sm1" EnableCdn="true" runat="server" />

Quando la proprietà EnableCdn è impostata su true, ASP.NET Framework recupera tutti i file JavaScript di ASP.NET Framework dalla rete CDN, inclusi tutti i file JavaScript utilizzati per la convalida e per il controllo UpdatePanel. Ciò può avere un impatto significativo sulle prestazioni dell'applicazione Web.

È possibile impostare il percorso della rete CDN per i file JavaScript tramite l'attributo WebResourceAttribute. La nuova proprietà CdnPath specifica il percorso della rete CDN utilizzata quando si imposta la proprietà EnableCdn su true, come illustrato nell'esempio seguente:

[assembly: WebResource("Example.js", "application/x-javascript", CdnPath ="http://contoso.com/app/site/Example.js")]

Per ulteriori informazioni sulla rete CDN di Microsoft Ajax, vedere l'argomento relativo alla rete CDN di Microsoft Ajax sul sito Web ASP.NET.

Script espliciti di ScriptManager

Se si è utilizzato ASP.NET ScriptManager nelle versioni precedenti di ASP.NET, l'applicazione Web doveva caricare l'intera libreria ASP.NET AJAX. Sfruttando la nuova proprietà AjaxFrameworkMode, è possibile controllare esattamente quali componenti della libreria ASP.NET AJAX vengono caricati. Per ulteriori informazioni, vedere la proprietà AjaxFrameworkMode.

La funzionalità Web Form ha avuto un ruolo centrale in ASP.NET fin dalla versione di ASP.NET 1.0. In quest'area sono stati apportati numerosi miglioramenti per ASP.NET 4, come i seguenti:

  • Possibilità di impostare i tag meta.

  • Maggiore controllo sullo stato di visualizzazione.

  • Supporto per browser e dispositivi introdotti di recente.

  • Modalità più semplici di utilizzo delle funzionalità del browser.

  • Supporto per l'utilizzo del routing ASP.NET con Web Form.

  • Maggiore controllo sugli ID generati.

  • Possibilità di rendere persistenti le righe selezionate nei controlli dati.

  • Maggiore controllo sul codice HTML di cui viene eseguito il rendering nei controlli FormView e ListView.

  • Supporto del filtro per i controlli origine dati.

  • Supporto migliorato per standard Web e accessibilità.

  • Modifiche dei modelli di progetto.

Impostazione di tag META con le proprietà Page.MetaKeywords e Page.MetaDescription

Alla classe Page sono state aggiunte due proprietà: MetaKeywords e MetaDescription. Queste due proprietà rappresentano i tag meta corrispondenti nel codice HTML di cui è stato eseguito il rendering per una pagina, come illustrato nell'esempio seguente:

<head id="Head1" runat="server">
  <title>Untitled Page</title>
  <meta name="keywords" content="keyword1, keyword2' />
  <meta name="description" content="Description of my page" />
</head>

Queste due proprietà funzionano come la proprietà Title e possono essere impostate nella direttiva @ Page. Per ulteriori informazioni, vedere Page.MetaKeywords e Page.MetaDescription.

Abilitazione dello stato di visualizzazione per singoli controlli

Alla classe Control è stata aggiunta una nuova proprietà: ViewStateMode. È possibile utilizzare questa proprietà per disabilitare lo stato di visualizzazione per tutti i controlli in una pagina ad eccezione di quelli per cui lo stato di visualizzazione viene abilitato in modo esplicito.

I dati relativi allo stato di visualizzazione sono inclusi nel codice HTML di una pagina e comportano un aumento del tempo necessario per inviare una pagina al client ed eseguirne il postback. L'archiviazione di una quantità di informazioni relative allo stato di visualizzazione maggiore del necessario può provocare una diminuzione significativa delle prestazioni. Nelle versioni precedenti di ASP.NET è possibile ridurre l'impatto dello stato di visualizzazione sulle prestazioni di una pagina disabilitando lo stato di visualizzazione per controlli specifici. Talvolta è tuttavia più semplice abilitare lo stato di visualizzazione per alcuni controlli per i quali è necessario anziché disabilitarlo per numerosi controlli per i quali non lo è.

Per ulteriori informazioni, vedere Control.ViewStateMode.

Supporto per browser e dispositivi introdotti di recente

In ASP.NET è inclusa una funzionalità denominata funzionalità browser che consente di determinare le funzionalità del browser dell'utente. Le funzionalità browser sono rappresentate dall'oggetto HttpBrowserCapabilities, archiviato nella proprietà HttpRequest.Browser. Le informazioni sulle funzionalità di un browser specifico sono definite da un file di definizione del browser. In ASP.NET 4 questi file di definizione del browser sono stati aggiornati per contenere informazioni sui browser e sui dispositivi introdotti di recente, come Google Chrome, smartphone BlackBerry Research in Motion ed Apple iPhone. Anche i file di definizione del browser esistenti sono stati aggiornati. Per ulteriori informazioni, vedere Procedura: eseguire l'aggiornamento di un'applicazione Web ASP.NET ad ASP.NET 4 e Controlli server Web ASP.NET e funzionalità del browser.

I file di definizione del browser inclusi in ASP.NET 4 sono indicati nell'elenco seguente:

•blackberry.browser

•chrome.browser

•Default.browser

•firefox.browser

•gateway.browser

•generic.browser

•ie.browser

•iemobile.browser

•iphone.browser

•opera.browser

•safari.browser

Nuova modalità di definizione delle funzionalità browser

ASP.NET 4 include una nuova funzionalità denominata provider di funzionalità browser. Come indicato dal nome, questa funzionalità consente di compilare un provider che, a sua volta, consente di scrivere codice personalizzato per determinare le funzionalità browser.

In ASP.NET versione 3.5 Service Pack 1 è possibile definire le funzionalità browser in un file XML. Questo file si trova in una cartella a livello di computer o a livello di applicazione. Per la maggior parte degli sviluppatori non è necessario personalizzare questi file, ma, per coloro che eseguono questa operazione, l'approccio basato sul provider può essere più semplice rispetto all'utilizzo di sintassi XML complessa. L'approccio basato sul provider consente di semplificare il processo implementando una sintassi di definizione del browser comune o un database che contiene definizioni del browser aggiornate oppure un servizio Web per tale database.

Per ulteriori informazioni sul nuovo provider di funzionalità browser, vedere il white paper relativo alle novità di ASP.NET 4 (la pagina potrebbe essere in inglese).

Routing in ASP.NET 4

In ASP.NET 4 viene aggiunto il supporto predefinito per il routing con i Web Form. Il routing è una funzionalità introdotta in ASP.NET 3.5 SP1 che consente di configurare un'applicazione per l'utilizzo di URL significativi per gli utenti e i motori di ricerca, in quanto non è necessario che vengano specificati nomi di file fisici. In questo modo il sito risulta più semplice da usare e il suo contenuto può essere individuato più facilmente dai motori di ricerca.

L'URL per una pagina in cui sono visualizzate categorie di prodotto nell'applicazione potrebbe, ad esempio, essere simile al seguente:

http://website/products.aspx?categoryid=12

Utilizzando il routing, è possibile utilizzare l'URL seguente per eseguire il rendering delle stesse informazioni:

http://website/products/software

Il secondo URL consente all'utente di sapere cosa aspettarsi e permette classificazioni significativamente migliori nei risultati dei motori di ricerca.

Tra le nuove funzionalità sono incluse le seguenti:

  • La classe PageRouteHandler è un gestore HTTP semplice che è possibile utilizzare per la definizione di route. Non è più necessario scrivere un gestore di route personalizzato.

  • Le proprietà HttpRequest.RequestContext e Page.RouteData semplificano l'accesso alle informazioni passate nei parametri URL.

    • L'espressione RouteUrl consente di creare in modo semplice un URL instradato nel markup.

    • L'espressione The RouteValue consente di estrarre in modo semplice i valori dei parametri URL nel markup.

  • La classe RouteParameter semplifica il passaggio dei valori dei parametri URL a una query per un controllo origine dati (in modo analogo a FormParameter).

  • Non è più necessario modificare il file Web.config per abilitare il routing.

Per ulteriori informazioni sul routing, vedere gli argomenti seguenti:

Impostazione degli ID client

La nuova proprietà ClientIDMode semplifica la scrittura di script client che fanno riferimento agli elementi HTML di cui viene eseguito il rendering per i controlli server. Il continuo aumento nell'utilizzo di Microsoft Ajax rende più comune questa esigenza. Si potrebbe, ad esempio, disporre di un controllo dati che esegue il rendering di un lungo elenco di prodotti con i prezzi e desiderare di utilizzare uno script client per eseguire una chiamata a un servizio Web e aggiornare singoli prezzi dell'elenco man mano che questi cambiano, senza aggiornare l'intera pagina.

In genere si ottiene un riferimento a un elemento HTML nello script client utilizzando il metodo document.GetElementById. A questo metodo viene passato il valore dell'attributo id dell'elemento HTML a cui si desidera fare riferimento. Nel caso di elementi di cui viene eseguito il rendering per i controlli server ASP.NET, con le versioni precedenti di ASP.NET questa operazione risulta difficile o impossibile. Non sempre è possibile stimare i valori ID che sarebbero stati generati da ASP.NET oppure ASP.NET può generare valori ID molto lunghi. Il problema era particolarmente complesso per i controlli dati che generavano più righe per una singola istanza del controllo nel markup.

In ASP.NET 4 sono stati aggiunti due nuovi algoritmi per la generazione di attributi id. Questi algoritmi possono generare attributi id più semplici da utilizzare negli script client in quanto più stimabili e più immediati. Per ulteriori informazioni su come utilizzare i nuovi algoritmi, vedere gli argomenti seguenti:

Persistenza della selezione di riga nei controlli dati

I controlli GridView e ListView consentono agli utenti di selezionare una riga. Nelle versioni precedenti di ASP.NET la selezione della riga è basata sull'indice della riga nella pagina. Se, ad esempio, si seleziona il terzo elemento di pagina 1, quindi si passa a pagina 2, viene selezionato il terzo elemento di pagina 2. Nella maggior parte dei casi, è preferibile che non venga selezionata alcuna riga a pagina 2. ASP.NET 4 supporta la selezione persistente, una nuova funzionalità supportata inizialmente solo nei progetti Dynamic Data in .NET Framework 3.5 SP1. Quando questa funzionalità è abilitata, l'elemento selezionato è basato sulla chiave di dati della riga. Questo significa che se si seleziona la terza riga di pagina 1, quindi si passa a pagina 2, in questa pagina non viene selezionato niente. Quando si torna di nuovo a pagina 1, la terza riga è ancora selezionata. Si tratta di un comportamento molto più naturale rispetto a quello delle versioni precedenti di ASP.NET. La selezione persistente è ora supportata per i controlli GridView e ListView in tutti i progetti. È possibile abilitare questa funzionalità nel controllo GridView, ad esempio, impostando la proprietà EnablePersistedSelection come illustrato nell'esempio seguente:

<asp:GridView id="GridView2" runat="server" PersistedSelection="true">
</asp:GridView>

Miglioramenti al controllo FormView

Il controllo FormView è stato migliorato per semplificare l'applicazione dello stile al contenuto del controllo con CSS. Nelle versioni precedenti di ASP.NET, il controllo FormView esegue il rendering del relativo contenuto utilizzando un modello di elemento. L'applicazione dello stile risulta pertanto più complessa nel markup in quanto nel controllo viene eseguito il rendering di tag imprevisti di celle e di righe di tabella. Il controllo FormView supporta RenderOuterTable, una proprietà di ASP.NET 4. Quando questa proprietà viene impostata su false, come illustrato nell'esempio seguente, non viene eseguito il rendering dei tag di tabella. In questo modo, viene semplificata l'applicazione dello stile CSS al contenuto del controllo.

<asp:FormView ID="FormView1" runat="server" RenderTable="false">

Per ulteriori informazioni, vedere Cenni preliminari sul controllo server Web FormView.

Miglioramenti al controllo ListView

Il controllo ListView, introdotto in ASP.NET 3.5, offre tutte le funzionalità del controllo GridView e fornisce controllo completo sull'output. L'utilizzo di questo controllo è stato semplificato in ASP.NET 4. La versione precedente del controllo richiedeva di specificare un modello di layout contenente un controllo server con un ID noto. Nel markup seguente viene illustrato un esempio tipico di come utilizzare il controllo ListView in ASP.NET 3.5.

<asp:ListView ID="ListView1" runat="server">
    <LayoutTemplate>
        <asp:PlaceHolder ID="ItemPlaceHolder" runat="server"></asp:PlaceHolder>
    </LayoutTemplate>
    <ItemTemplate>
        <% Eval("LastName")%>
    </ItemTemplate>
</asp:ListView>

In ASP.NET 4 il controllo ListView non richiede un modello di layout. Il markup dell'esempio precedente può essere sostituito con il seguente:

<asp:ListView ID="ListView1" runat="server">
    <ItemTemplate>
        <% Eval("LastName")%>
    </ItemTemplate>
</asp:ListView>

Per ulteriori informazioni, vedere Cenni preliminari sul controllo server Web ListView.

Filtro dei dati con il controllo QueryExtender

Un'attività molto comune per gli sviluppatori che creano pagine Web basate sui dati consiste nel filtrare i dati. Questa operazione è stata tradizionalmente eseguita compilando clausole Where nei controlli origine dati. Questo approccio può essere complicato e, in alcuni casi, la sintassi Where non consente di sfruttare tutte le funzionalità del database sottostante.

Per semplificare le operazioni di filtro, in ASP.NET 4 è stato aggiunto un nuovo controllo QueryExtender. Questo controllo può essere aggiunto al controllo EntityDataSource o LinqDataSource per filtrare i dati restituiti da uno di questi controlli. Il controllo QueryExtender si basa su LINQ, ma non è necessario essere in grado di scrivere query LINQ per utilizzare l'estensione di query.

Il controllo QueryExtender supporta numerose opzioni di filtro. Di seguito sono elencate le opzioni di filtro di QueryExtender.

Argomento

Definizione

SearchExpression

Consente di cercare valori stringa in un campo o in diversi campi e li confronta con un valore stringa specificato.

RangeExpression

Consente di cercare in un campo o in diversi campi valori inclusi in un intervallo specificato da una coppia di valori.

PropertyExpression

Consente di confrontare un valore specificato con un valore di proprietà in un campo. Se l'espressione restituisce true, vengono restituiti i dati esaminati.

OrderByExpression

Consente di ordinare i dati in base a una colonna e a un tipo di ordinamento specificati.

CustomExpression

Consente di chiamare una funzione che definisce un filtro personalizzato nella pagina.

Per ulteriori informazioni, vedere QueryExtenderCenni preliminari sul controllo server Web QueryExtender.

Supporto migliorato per standard Web e accessibilità

Con le versioni precedenti dei controlli ASP.NET, talvolta viene eseguito il rendering del markup in modo non conforme agli standard HTML, XHTML o di accessibilità. ASP.NET 4 consente di eliminare la maggior parte di queste eccezioni.

Per informazioni dettagliate su come il codice HTML di cui viene eseguito il rendering da ogni controllo soddisfa gli standard di accessibilità, vedere Controlli ASP.NET e accessibilità.

Possibilità di disabilitare CSS per i controlli

In ASP.NET 3.5 quando un controllo viene disabilitato (vedere WebControl.Enabled), viene aggiunto un attributo disabled all'elemento HTML di cui è stato eseguito il rendering. Il markup seguente consente, ad esempio, di creare un controllo Label disabilitato:

<asp:Label id="Label1" runat="server"

  Text="Test" Enabled="false" />

In ASP.NET 3.5 le impostazioni del controllo precedenti generano il codice HTML seguente:

<span id="Label1" disabled="disabled">Test</span>

In HTML 4.01 l'attributo disabled non è considerato valido negli elementi span. Esso è valido solo negli elementi input, in quanto specifica che l'accesso non è consentito. Negli elementi di sola visualizzazione, ad esempio gli elementi span, i browser supportano in genere il rendering per un aspetto disabilitato, ma una pagina Web basata su questo comportamento non standard non è considerata affidabile in base agli standard di accessibilità.

Per gli elementi di sola visualizzazione, è necessario utilizzare CSS per indicare un aspetto visivo disabilitato. Per impostazione predefinita, ASP.NET 4 genera pertanto il codice HTML seguente per le impostazioni del controllo illustrate in precedenza:

<span id="Label1" class="aspNetDisabled">Test</span>

È possibile modificare il valore dell'attributo class di cui viene eseguito il rendering per impostazione predefinita quando un controllo è disabilitato impostando la proprietà DisabledCssClass.

CSS per i controlli di convalida

In ASP.NET 3.5 per i controlli di convalida viene eseguito il rendering di un colore red predefinito come stile in linea. Il markup seguente consente, ad esempio, di creare un controllo RequiredFieldValidator:

<asp:RequiredFieldValidator ID="RequiredFieldValidator1" runat="server"

  ErrorMessage="Required Field" ControlToValidate="RadioButtonList1" />

In ASP.NET 3.5 viene eseguito il rendering del codice HTML seguente per il controllo validator:

<span id="RequiredFieldValidator1"

  style="color:Red;visibility:hidden;">RequiredFieldValidator</span>

Per impostazione predefinita, in ASP.NET 4 non viene eseguito il rendering di uno stile in linea per impostare il colore su rosso. Uno stile in linea viene utilizzato solo per mostrare o nascondere il validator, come illustrato nell'esempio seguente:

<span id="RequiredFieldValidator1"

  style"visibility:hidden;">RequiredFieldValidator</span>

In ASP.NET 4, pertanto, i messaggi di errore non vengono visualizzati automaticamente in rosso. Per informazioni sull'utilizzo di CSS per specificare uno stile di visualizzazione per un controllo di convalida, vedere Convalida dell'input utente nelle pagine Web ASP.NET.

CSS per elementi div dei campi nascosti

In ASP.NET vengono utilizzati campi nascosti per archiviare informazioni sullo stato, come lo stato di visualizzazione e lo stato del controllo. Questi campi nascosti sono inclusi nell'elemento div. In ASP.NET 3.5 l'elemento div non dispone di un attributo class o di un attributo id. Eventuali regole CSS che influiscono su tutti gli elementi div potrebbero pertanto rendere inavvertitamente visibile questo elemento div. Per evitare questo problema, in ASP.NET 4 viene eseguito il rendering dell'elemento div per i campi nascosti con una classe CSS che è possibile utilizzare per differenziare i campi nascosti div dagli altri. Il valore della nuova classeè illustrato nell'esempio seguente:

<div class="aspNetHidden">

CSS per controlli Table, Image e ImageButton

Per impostazione predefinita, in ASP.NET 3.5 per alcuni controlli l'attributo border del codice HTML di cui è stato eseguito il rendering viene impostato su zero (0). Nell'esempio seguente è illustrato il codice HTML generato dal controllo Table in ASP.NET 3.5:

<table id="Table2" border="0">

Questo comportamento avviene anche con i controlli Image e ImageButton. Poiché questo comportamento non è necessario e fornisce informazioni sulla formattazione visiva che dovrebbero venire fornite tramite CSS, l'attributo non viene generato in ASP.NET 4.

CSS per i controlli UpdatePanel e UpdateProgress

In ASP.NET 3.5 i controlli UpdatePanel e UpdateProgress non supportano gli attributi Expando. Di conseguenza, non è possibile impostare una classe CSS negli elementiHTML di cui viene eseguito il rendering. In ASP.NET 4 questi controlli sono stati modificati per accettare gli attributi Expando, come illustrato nell'esempio seguente:

<asp:UpdatePanel runat="server" class="myStyle">

</asp:UpdatePanel>

Per questo markup viene eseguito il rendering del codice HTML seguente:

<div id="ctl00_MainContent_UpdatePanel1" class="expandoclass">

</div>

Eliminazione di tabelle esterne non necessarie

In ASP.NET 3.5, per il codice HTML di cui viene eseguito il rendering per i controlli seguenti viene eseguito il wrapping in un elemento table finalizzato all'applicazione di stili in linea all'intero controllo:

Se si utilizzano modelli per personalizzare l'aspetto di questi controlli, è possibile specificare stili CSS nel markup fornito nei modelli. In tal caso, non è richiesta alcuna tabella esterna aggiuntiva. In ASP.NET 4 è possibile impedire che venga eseguito il rendering della tabella impostando la nuova proprietà RenderOuterTable su false.

Modelli del layout per i controlli della procedura guidata

In ASP.NET 3.5 i controlli Wizard e CreateUserWizard generano un elemento table HTML utilizzato per la formattazione visiva. In ASP.NET 4 è possibile utilizzare un elemento LayoutTemplate per specificare il layout. In tal caso, l'elemento table HTML non viene generato. Nel modello vengono creati controlli segnaposto per indicare dove devono essere inseriti dinamicamente gli elementi nel controllo. (Il funzionamento è analogo a quello del modello per il controllo ListView). Per ulteriori informazioni, vedere la proprietà Wizard.LayoutTemplate.

Nuove opzioni di formattazione HTML per i controlli CheckBoxList e RadioButtonList

In ASP.NET 3.5 vengono utilizzati elementi tabella HTML per formattare l'output per i controlli CheckBoxList e RadioButtonList. Per offrire un'alternativa che non preveda l'utilizzo di tabelle per la formattazione visiva, in ASP.NET 4 sono state aggiunte due nuove opzioni all'enumerazione RepeatLayout:

  • UnorderedList . Questa opzione comporta la formattazione dell'output HTML tramite gli elementi ul e li anziché una tabella.

  • OrderedList . Questa opzione comporta la formattazione dell'output HTML tramite gli elementi ol e li anziché una tabella.

Per esempi di rendering di HTML per le nuove opzioni, vedere l'enumerazione RepeatLayout.

Elementi di intestazione e piè di pagina per il controllo Table

In ASP.NET 3.5 è possibile configurare il controllo Table per eseguire il rendering degli elementi thead e tfoot impostando la proprietà TableSection della classe TableHeaderRow e della classe TableFooterRow. In ASP.NET 4 queste proprietà vengono impostate sui valori appropriati per impostazione predefinita.

Supporto CSS e ARIA per il controllo Menu

In ASP.NET 3.5 il controllo Menu utilizza elementi table HTML per la formattazione visiva e, in alcune configurazioni, non è accessibile da tastiera. In ASP.NET 4 vengono affrontati questi problemi e l'accessibilità viene migliorata nei modi seguenti:

  • Il codice HTML generato è strutturato come elenco non ordinato (elementi ul e li).

  • Per la formattazione visiva viene utilizzato CSS.

  • Il menu si comporta conformemente agli standard ARIA per l'accesso da tastiera. È possibile utilizzare i tasti di direzione per esplorare le voci di menu. Per informazioni su ARIA, vedere Accessibilità in Visual Studio e ASP.NET.

  • Al codice HTML generato vengono aggiunti gli attributi dei ruoli e delle proprietà ARIA. Gli attributi vengono aggiunti utilizzando JavaScript anziché inclusi nel codice HTML, per evitare di generare codice HTML che provocherebbe errori di convalida del markup.

Il rendering degli stili per il controllo Menu viene eseguito in un blocco style all'inizio della pagina, anziché in linea con gli elementi HTML di cui è stato eseguito il rendering. Se si desidera utilizzare un file CSS separato per poter modificare gli stili dei menu, è possibile impostare la nuova proprietà IncludeStyleBlock del controllo Menu su false, in modo che il blocco style non venga generato.

Codice XHTML valido per il controllo HtmlForm

In ASP.NET 3.5 il rendering del controllo HtmlForm (creato in modo implicito dal tag <form runat="server">) viene eseguito come elemento form HTML con entrambi gli attributi name e id. L'attributo name è deprecato in XHTML 1.1. Questo controllo non esegue pertanto il rendering dell'attributo name in ASP.NET 4.

Mantenimento della compatibilità con le versioni precedenti nel rendering dei controlli

Un sito Web ASP.NET esistente potrebbe includere codice che presuppone che i controlli eseguano il rendering del codice HTML in modo analogo a quanto avviene in ASP.NET 3.5. Per evitare problemi di compatibilità con le versioni precedenti quando si aggiorna il sito ad ASP.NET 4, è possibile fare in modo che ASP.NET continui a generare il codice HTML in modo analogo a quanto avviene in ASP.NET 3.5 dopo l'aggiornamento del sito. A tale scopo, è possibile impostare l'attributo controlRenderingCompatibilityVersion dell'elemento pages su "3.5" nel file Web.config di un sito Web ASP.NET 4, come illustrato nell'esempio seguente:

<system.web>

  <pages controlRenderingCompatibilityVersion="3.5"/>

</system.web>

Se questa impostazione viene omessa, il valore predefinito corrisponde alla versione di ASP.NET alla quale è destinato il sito Web. Per informazioni sul multitargeting in ASP.NET, vedere Multitargeting di .NET Framework per progetti Web ASP.NET.

Nelle versioni precedenti di ASP.NET, quando si utilizza Visual Studio per creare un nuovo progetto di sito Web o un progetto di applicazione Web, i progetti risultanti contengono solo una pagina Default.aspx, un file Web.config predefinito e la cartella App_Data. Visual Studio supporta inoltre un tipo di progetto di sito Web vuoto che non contiene file. Di conseguenza, per chi non ha esperienza di programmazione, le linee guida disponibili per la compilazione di un'applicazione Web di produzione sono estremamente limitate. In ASP.NET 4 vengono pertanto introdotti tre nuovi modelli, uno per un progetto di applicazione Web vuoto e uno rispettivamente per un progetto di applicazione Web e per un progetto di sito Web:

  • Modelli di progetto di applicazione Web e di sito Web vuoti. Sono simili al layout di Sito Web vuoto delle versioni precedenti di ASP.NET, ad eccezione del fatto che contengono un file Web.config che specifica la versione di destinazione di .NET Framework.

  • Modelli di progetto di applicazione Web e di sito Web. Questi modelli includono alcuni file che non vengono creati nelle versioni precedenti. I file aggiuntivi forniscono funzionalità di appartenenza di base, un pagina master e pagine contenuto che la utilizzano, file AJAX e CSS. Lo scopo di tali modifiche dei modelli di progetto è di fornire linee guida su come iniziare a compilare una nuova applicazione Web.

Per ulteriori informazioni, vedere Modelli di Visual Studio per progetti Web.

ASP.NET MVC consente agli sviluppatori Web di compilare accattivanti siti Web basati su standard. Tali siti risultano semplici da gestire in quanto l'utilizzo del modello MVC (Model View Controller) consente di ridurre la dipendenza tra i livelli dell'applicazione. MVC offre controllo completo sul markup della pagina. Migliora inoltre la testabilità grazie al supporto inerente dello sviluppo basato su test (TDD, Test Driven Development).

I siti Web creati utilizzando ASP.NET MVC dispongono di un'architettura modulare. In questo modo, i membri di un team possono lavorare indipendentemente sui diversi moduli, migliorando la collaborazione. Gli sviluppatori possono, ad esempio, operare sui livelli di modello e controller (dati e logica), mentre il progettista lavora sulla visualizzazione (presentazione).

Per esercitazioni, procedure dettagliate, contenuto concettuale, esempi di codice e un riferimento completo alle API, vedere MVC ASP.NET 2.

Dynamic Data è stato introdotto nella versione di .NET Framework 3.5 SP1 rilasciata a metà del 2008. Questa funzionalità offre numerosi miglioramenti per la creazione di applicazioni basate sui dati, tra cui i seguenti:

  • Esperienza di sviluppo rapido di applicazioni per compilare in modo rapido un sito Web basato sui dati.

  • Convalida automatica basata su vincoli definiti nel modello di dati.

  • Possibilità di modificare facilmente il markup generato per i campi nei controlli GridView e DetailsView tramite modelli di campo che fanno parte del progetto Dynamic Data.

Per ASP.NET 4, Dynamic Data è stato migliorato per offrire agli sviluppatori una potenza ancora maggiore per la compilazione rapida di siti Web basati sui dati. Per ulteriori informazioni, vedere Mappa del contenuto per ASP.NET Dynamic Data.

Abilitazione di Dynamic Data per singoli controlli associati a dati nelle applicazioni Web esistenti

È possibile utilizzare le funzionalità di Dynamic Data nelle applicazioni Web ASP.NET esistenti che non impiegano lo scaffolding abilitando Dynamic Data per singoli controlli con associazione a dati. Dynamic Data fornisce supporto a livello di dati e presentazione per il rendering di questi controlli. Abilitando Dynamic Data per i controlli con associazione a dati, è possibile ottenere i vantaggi seguenti:

  • Impostazione di valori predefiniti per i campi dati. Dynamic Data consente di fornire valori predefiniti in fase di esecuzione per i campi di un controllo dati.

  • Interazione con il database senza creare e registrare un modello di dati.

  • Convalida automatica dei dati immessi dall'utente senza scrivere codice.

Per ulteriori informazioni, vedere Procedura dettagliata: abilitazione di Dynamic Data nei controlli con associazione a dati ASP.NET.

Sintassi dichiarativa per il controllo DynamicDataManager

Il controllo DynamicDataManager è stato migliorato in modo che sia possibile configurarlo in modo dichiarativo, come avviene con la maggior parte dei controlli in ASP.NET, anziché solo nel codice. Il markup del controllo DynamicDataManager è simile all'esempio seguente:

<asp:DynamicDataManager ID="DynamicDataManager1" runat="server"  
    AutoLoadForeignKeys="true"> 
  <DataControls> 
    <asp:DataControlReference ControlID="GridView1" /> 
  </DataControls> 
</asp:DynamicDataManager> 

<asp:GridView id="GridView1" runat="server" 
</asp:GridView> 

Questo markup abilita il comportamento di Dynamic Data per il controllo GridView1 a cui viene fatto riferimento nella sezione DataControls del controllo DynamicDataManager.

Modelli di entità

I modelli di entità offrono una nuova modalità per la personalizzazione del layout dei dati, senza richiedere la creazione di una pagina personalizzata. Nei modelli di pagina viene utilizzato il controllo FormView anziché il controllo DetailsView, utilizzato nei modelli di pagina delle versioni precedenti di Dynamic Data. Nei modelli di pagina viene inoltre utilizzato il controllo DynamicEntity per eseguire il rendering dei modelli di entità. In tal modo è possibile avere un maggiore controllo sul markup di cui viene eseguito il rendering in Dynamic Data.

Per ulteriori informazioni sui modelli di entità, vedere Cenni preliminari sullo sviluppo Web in ASP.NET 4 e Visual Studio 2010 (formato pdf) sul sito Web ASP.NET.

Nuovi modelli di campo per URL e indirizzi di posta elettronica

In ASP.NET 4 vengono introdotti due nuovi modelli di campo predefiniti, EmailAddress.ascx e Url.ascx. Questi modelli vengono utilizzati per i campi contrassegnati come EmailAddress o Url utilizzando l'attributo DataTypeAttribute. Per gli oggetti EmailAddress, il campo viene visualizzato come collegamento ipertestuale creato tramite il protocollo mailto:. Quando gli utenti fanno clic sul collegamento, viene aperto il client di posta elettronica dell'utente e viene creata la struttura di un messaggio. Gli oggetti digitati come Url vengono visualizzati come collegamenti ipertestuali comuni.

Nell'esempio seguente viene illustrato come contrassegnare i campi.

[DataType(DataType.EmailAddress)]
public object HomeEmail { get; set; }

[DataType(DataType.Url)]
public object Website { get; set; }

Creazione di collegamenti con il controllo DynamicHyperLink

In Dynamic Data viene utilizzata la nuova funzionalità di routing aggiunta in .NET Framework 3.5 SP1 per controllare gli URL che gli utenti visualizzano quando accedono al sito Web. Il nuovo controllo DynamicHyperLink semplifica la compilazione di collegamenti alle pagine in un sito Dynamic Data.

Per informazioni, vedere Procedura: creare collegamenti alle azioni di tabella in Dynamic Data.

Supporto per l'ereditarietà nel modello di dati

Sia ADO.NET Entity Framework che LINQ to SQL supportano l'ereditarietà nei propri modelli di dati. Un esempio è costituito da un database con una tabella InsurancePolicy. Il database potrebbe contenere anche le tabelle CarPolicy e HousePolicy, con gli stessi campi di InsurancePolicy, nonché campi aggiuntivi. Dynamic Data è stato modificato per comprendere gli oggetti ereditati nel modello di dati e supportare lo scaffolding per le tabelle ereditate.

Per ulteriori informazioni, vedere Procedura dettagliata: mapping dell'ereditarietà della tabella per gerarchia in Dynamic Data.

Supporto di relazioni molti-a-molti (solo Entity Framework)

Entity Framework offre supporto completo per le relazioni molti-a-molti tra tabelle, implementato esponendo la relazione come insieme in un oggetto Entity. Sono stati aggiunti nuovi modelli di campo (ManyToMany.ascx e ManyToMany_Edit.ascx) per fornire supporto per la visualizzazione e la modifica di dati coinvolti in relazioni molti-a-molti.

Per ulteriori informazioni, vedere Utilizzo di relazioni di dati molti-a-molti in Dynamic Data.

Nuovi attributi per il controllo della visualizzazione e il supporto delle enumerazioni

L'oggetto DisplayAttribute è stato aggiunto per offrire controllo aggiuntivo sulla visualizzazione dei campi. L'attributo DisplayNameAttribute nelle versioni precedenti di Dynamic Data consente di modificare il nome utilizzato come didascalia per un campo. La nuova classe DisplayAttribute consente di specificare più opzioni per la visualizzazione di un campo, come l'ordine di visualizzazione di un campo o l'eventuale utilizzo di un campo come filtro. L'attributo fornisce anche controllo indipendente sul nome utilizzato per le etichette in un controllo GridView, sul nome utilizzato in un controllo DetailsView, sul testo della Guida per il campo e sulla filigrana utilizzata per il campo (se il campo accetta input di testo).

La classe EnumDataTypeAttribute è stata aggiunta per consentire di eseguire il mapping dei campi alle enumerazioni. Quando si applica questo attributo a un campo, si specifica un tipo di enumerazione. In Dynamic Data viene utilizzato il nuovo modello di campo Enumeration.ascx per creare l'interfaccia utente per la visualizzazione e la modifica di valori di enumerazione. Il modello esegue il mapping dei valori del database ai nomi dell'enumerazione.

Supporto migliorato per i filtri

In Dynamic Data 1.0 erano disponibili filtri predefiniti per colonne booleane e colonne di chiave esterna. I filtri non consentivano di specificare l'ordine di visualizzazione. Il nuovo attributo DisplayAttribute risolve questo problema consentendo di stabilire se una colonna viene visualizzata come un filtro, nonché l'ordine con cui verrà visualizzata.

Per offrire un ulteriore miglioramento, il supporto del filtro è stato inoltre riscritto per utilizzare la nuova funzionalità QueryExtender di Web Form. È pertanto possibile creare filtri senza conoscere il controllo origine dati con cui i filtri verranno utilizzati. Insieme a queste estensioni, i filtri sono inoltre stati trasformati in controlli modello, per consentire l'aggiunta di nuovi filtri. La classe DisplayAttribute descritta in precedenza consente, infine, di eseguire l'override del filtro predefinito nello stesso modo in cui UIHint consente di eseguire l'override di un modello di campo predefinito per una colonna.

Per ulteriori informazioni, vedere Procedura dettagliata: filtro di righe nelle tabelle con una relazione padre-figlio e QueryableFilterRepeater.

Il controllo server Chart ASP.NET consente di creare applicazioni con pagine ASP.NET in cui sono presenti semplici e intuitivi grafici relativi ad analisi statistiche o finanziarie complesse. Il controllo Chart supporta le funzionalità seguenti:

  • Serie di dati, aree grafico, assi, legende, etichette, titoli e così via.

  • Associazione dati.

  • Modifica dei dati, ad esempio copia, suddivisione, unione, allineamento, raggruppamento, ordinamento, ricerca e filtro.

  • Formule statistiche e formule finanziarie.

  • Aspetti avanzati del grafico, come 3D, anti-aliasing, illuminazione e prospettiva.

  • Eventi e personalizzazioni.

  • Interattività e Microsoft Ajax.

  • Supporto per la rete per la distribuzione di contenuti (CDN, Content Delivery Network) AJAX, che fornisce una modalità ottimizzata per l'aggiunta di script Microsoft Ajax Library e jQuery alle applicazioni Web.

Per ulteriori informazioni, vedere Panoramica sul controllo server Web Chart.

Nelle seguenti sezioni vengono fornite informazioni sui miglioramenti e le nuove funzionalità di Visual Studio 2010 e Visual Web Developer Express.

La finestra di progettazione delle pagine Web in Visual Studio 2010 è stata migliorata per offrire una maggiore compatibilità con CSS, include supporto aggiuntivo per frammenti markup HTML e ASP.NET e offre una versione riprogettata di IntelliSense per JScript.

Compatibilità con CSS migliorata

La finestra di progettazione di Visual Web Developer in Visual Studio 2010 è stata aggiornata per migliorare la conformità con gli standard CSS 2.1. La finestra di progettazione consente di mantenere meglio il codice sorgente HTML ed è più affidabile rispetto alle versioni precedenti di Visual Studio.

Frammenti di codice HTML e JavaScript

Nell'editor HTML IntelliSense consente il completamento automatico dei nomi di tag. La funzionalità relativa ai frammenti IntelliSense consente il completamento automatico di interi tag e molto altro. In Visual Studio 2010 i frammenti IntelliSense sono supportati per JScript, insieme a C# e Visual Basic, che erano supportati nelle versioni precedenti di Visual Studio.

Visual Studio 2010 include più di 200 frammenti che consentono di completare automaticamente i tag ASP.NET e HTML comuni, inclusi attributi obbligatori (come runat="server") e attributi comuni specifici di un tag (come ID, DataSourceID, ControlToValidate e Text).

È possibile scaricare frammenti aggiuntivi oppure scrivere frammenti personalizzati che incapsulano i blocchi di markup utilizzati dal team per le attività comuni. Per ulteriori informazioni sui frammenti HTML, vedere Procedura dettagliata: utilizzo di frammenti HTML.

Miglioramenti di IntelliSense in JavaScript

In Visual Studio 2010 JScript IntelliSense è stato riprogettato per offrire un'esperienza di modifica ancora più ricca. IntelliSense riconosce ora gli oggetti generati dinamicamente da metodi come registerNamespace e da tecniche analoghe utilizzate da altri framework JavaScript. Le prestazioni sono state migliorate per l'analisi di librerie di script di grandi dimensioni e la visualizzazione di IntelliSense con un ritardo di elaborazione minimo o nullo. La compatibilità è stata aumentata significativamente per supportare pressoché tutte le librerie di terze parti e stili di codifica diversi. I commenti relativi alla documentazione vengono ora analizzati mentre si digita e vengono utilizzati immediatamente da IntelliSense.

Distribuzione delle applicazioni Web con Visual Studio 2010

Per i progetti di applicazione Web, Visual Studio offre ora strumenti che funzionano con IIS Strumento di distribuzione Web (Distribuzione Web) per automatizzare numerosi processi che devono essere eseguiti manualmente nelle versioni precedenti di ASP.NET. È ora possibile automatizzare, ad esempio, le attività seguenti:

  • Creazione di un'applicazione IIS nel computer di destinazione e configurazione delle impostazioni di IIS.

  • Copia di file nel computer di destinazione.

  • Modifica delle impostazioni di Web.config che devono essere diverse nell'ambiente di destinazione.

  • Propagazione delle modifiche ai dati o alle strutture di dati in database di SQL Server utilizzati dall'applicazione Web.

Per ulteriori informazioni sulla distribuzione di applicazioni Web, vedere Mappa del contenuto per la distribuzione di ASP.NET.

In ASP.NET 4 sono state aggiunte nuove funzionalità alla funzionalità di multitargeting, per semplificare l'utilizzo di progetti destinati a versioni precedenti di .NET Framework.

Il multitargeting è stato introdotto in ASP.NET 3.5 per consentire di utilizzare la versione più recente di Visual Studio senza dovere aggiornare i siti Web o i servizi Web esistenti alla versione più recente di .NET Framework. 

In Visual Studio 2008 quando si utilizza un progetto destinato a una versione precedente di .NET Framework, la maggior parte delle funzionalità dell'ambiente di sviluppo si adatta alla versione di destinazione. In IntelliSense vengono tuttavia visualizzate le funzionalità relative al linguaggio disponibili nella versione corrente e nelle finestre delle proprietà vengono visualizzate le proprietà disponibili nella versione corrente. In Visual Studio 2010 vengono visualizzate solo le funzionalità relative al linguaggio e le proprietà disponibili nella versione di destinazione di .NET Framework.

Per ulteriori informazioni sul multitargeting, vedere gli argomenti seguenti:

Aggiunte alla community

AGGIUNGI
Mostra: