Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Questo documento offre una panoramica di molte delle nuove funzionalità per ASP.NET incluse in the.NET Framework 4 e in Visual Studio 2010.
Contents
Servizi di base
refactoring dei file
Memorizzazione nella cache dell'output estendibile
Avvio automatico di applicazioni Web
Reindirizzamento permanente di una pagina
Compattazione dello stato della sessione
Espansione dell'intervallo di URL consentiti
Convalida delle richieste estendibili
Estendibilità memorizzazione nella cache degli oggetti e memorizzazione nella cache degli oggetti
Codifica dell'intestazione HTTP, URL e HTML estendibile
Monitoraggio delle prestazioni per singole applicazioni in un singolo processo di lavoro
Multitargeting
Ajax
jQuery incluso con Web Forms e MVC
Supporto della rete per la distribuzione di contenuti
ScriptManager espliciti
Web Forms
Impostazione dei meta tag con le proprietà Page.MetaKeywords e Page.MetaDescription
Abilitazione dello stato di visualizzazione per i singoli controlli
Modifiche alle funzionalità del browser
Routing in ASP.NET 4
Impostazione degli ID client
Salvataggio permanente della selezione di righe nei controlli dati
ASP.NET
Filtro dei dati con il controllo QueryExtender
Espressioni di codice codificato HTML
Modifiche al modello di progetto
Miglioramenti di CSS
Nascondere gli elementi div intorno ai campi nascosti
Rendering di una tabella esterna per i controlli basati su modelli
Miglioramenti al controllo ListView
Miglioramenti ai controlli CheckBoxList e RadioButtonList
Miglioramenti al controllo menu
Procedura guidata e controlli CreateUserWizard 56
MVC
Supporto aree
Supporto per la convalida degli attributi di annotazione dei dati
Helper basato su modelli
Dati dinamici
Abilitazione dei dati dinamici per i progetti esistenti
Sintassi del controllo DynamicDataManager dichiarativa
Modelli di entità
Nuovi modelli di campo per URL e indirizzi di posta elettronica
Creazione di collegamenti con il controllo DynamicHyperLink
Supporto per l'ereditarietà nel modello di dati
Supporto per relazioni molti-a-molti (solo Entity Framework)
Nuovi attributi per controllare la visualizzazione e il supporto delle enumerazioni
Supporto avanzato per i filtri
Miglioramenti allo sviluppo Web di Visual Studio 2010
Compatibilità CSS migliorata
Frammenti di codice HTML e JavaScript
Miglioramenti di JavaScript IntelliSense
Distribuzione di applicazioni Web con Visual Studio 2010
Creazione di pacchetti Web
Web.config
Distribuzione del database
Pubblicazione con un clic per le applicazioni Web
Risorse
Servizi di base
ASP.NET 4 introduce una serie di funzionalità che migliorano i servizi di base ASP.NET, ad esempio la memorizzazione nella cache dell'output e l'archiviazione dello stato della sessione.
Web.config refactoring dei file
Il Web.config file che contiene la configurazione per un'applicazione Web è cresciuto notevolmente nelle ultime versioni di .NET Framework, poiché sono state aggiunte nuove funzionalità, ad esempio Ajax, routing e integrazione con IIS 7. Ciò ha reso più difficile configurare o avviare nuove applicazioni Web senza uno strumento come Visual Studio. In .NET Framework 4 gli elementi di configurazione principali sono stati spostati nel machine.config file e le applicazioni ereditano ora queste impostazioni. In questo modo il Web.config file in ASP.NET 4 applicazioni può essere vuoto o contenere solo le righe seguenti, che specificano per Visual Studio la versione del framework di destinazione dell'applicazione:
<?xml version="1.0"?>
<configuration>
<system.web>
<compilation targetFramework="4.0" />
</system.web>
</configuration>
Memorizzazione nella cache dell'output estendibile
Dal momento in cui ASP.NET 1.0 è stata rilasciata, la memorizzazione nella cache dell'output ha consentito agli sviluppatori di archiviare l'output generato di pagine, controlli e risposte HTTP in memoria. Nelle richieste Web successive, ASP.NET può gestire il contenuto più rapidamente recuperando l'output generato dalla memoria invece di rigenerare l'output da zero. Tuttavia, questo approccio presenta una limitazione: il contenuto generato deve essere sempre archiviato in memoria e nei server che riscontrano traffico elevato, la memoria utilizzata dalla memorizzazione nella cache dell'output può competere con le richieste di memoria di altre parti di un'applicazione Web.
ASP.NET 4 aggiunge un punto di estendibilità alla memorizzazione nella cache di output che consente di configurare uno o più provider di cache di output personalizzati. I provider di cache di output possono usare qualsiasi meccanismo di archiviazione per rendere persistente il contenuto HTML. In questo modo è possibile creare provider di cache di output personalizzati per meccanismi di persistenza diversi, che possono includere dischi locali o remoti, archiviazione cloud e motori di cache distribuiti.
Si crea un provider di cache di output personalizzato come classe che deriva dal nuovo tipo System.Web.Caching.OutputCacheProvider . È quindi possibile configurare il provider nel Web.config file usando la sottosezione dei nuovi provider dell'elemento outputCache , come illustrato nell'esempio seguente:
<caching>
<outputCache defaultProvider="AspNetInternalProvider">
<providers>
<add name="DiskCache"
type="Test.OutputCacheEx.DiskOutputCacheProvider, DiskCacheProvider"/>
</providers>
</outputCache>
</caching>
Per impostazione predefinita in ASP.NET 4, tutte le risposte HTTP, le pagine di cui è stato eseguito il rendering e i controlli usano la cache di output in memoria, come illustrato nell'esempio precedente, in cui l'attributo defaultProvider è impostato su AspNetInternalProvider. È possibile modificare il provider di cache di output predefinito usato per un'applicazione Web specificando un nome di provider diverso per defaultProvider.
Inoltre, è possibile selezionare diversi provider di cache di output per controllo e per richiesta. Il modo più semplice per scegliere un provider di cache di output diverso per diversi controlli utente Web consiste nell'usare in modo dichiarativo il nuovo attributo providerName in una direttiva di controllo, come illustrato nell'esempio seguente:
<%@ OutputCache Duration="60" VaryByParam="None" providerName="DiskCache" %>
La specifica di un provider di cache di output diverso per una richiesta HTTP richiede un po' di più. Anziché specificare in modo dichiarativo il provider, eseguire l'override del nuovo metodo GetOuputCacheProviderName nel Global.asax file per specificare a livello di codice il provider da usare per una richiesta specifica. L'esempio seguente illustra come farlo.
public override string GetOutputCacheProviderName(HttpContext context)
{
if (context.Request.Path.EndsWith("Advanced.aspx"))
return "DiskCache";
else
return base.GetOutputCacheProviderName(context);
}
Con l'aggiunta dell'estendibilità del provider di cache di output a ASP.NET 4, è ora possibile perseguire strategie di memorizzazione nella cache di output più aggressive e intelligenti per i siti Web. Ad esempio, è ora possibile memorizzare nella cache le pagine "Prime 10" di un sito in memoria, memorizzando nella cache le pagine che ottengono un traffico inferiore su disco. In alternativa, è possibile memorizzare nella cache ogni combinazione di variabili per una pagina sottoposta a rendering, ma usare una cache distribuita in modo che l'utilizzo della memoria venga scaricato dai server Web front-end.
Avvio automatico di applicazioni Web
Alcune applicazioni Web devono caricare grandi quantità di dati o eseguire un'elaborazione di inizializzazione costosa prima di gestire la prima richiesta. Nelle versioni precedenti di ASP.NET, per queste situazioni è stato necessario definire approcci personalizzati per "riattivare" un'applicazione ASP.NET e quindi eseguire il codice di inizializzazione durante il metodo Application_Load nel Global.asax file.
Una nuova funzionalità di scalabilità denominata avvio automatico che risolve direttamente questo scenario è disponibile quando ASP.NET 4 viene eseguito in IIS 7.5 in Windows Server 2008 R2. La funzionalità di avvio automatico offre un approccio controllato per avviare un pool di applicazioni, inizializzare un'applicazione ASP.NET e quindi accettare richieste HTTP.
Nota
Modulo di Warm-Up dell'applicazione IIS per IIS 7.5
Il team iis ha rilasciato la prima versione di test beta del modulo Application Warm-Up per IIS 7.5. In questo modo il riscaldamento delle applicazioni risulta ancora più semplice di quanto descritto in precedenza. Anziché scrivere codice personalizzato, specificare gli URL delle risorse da eseguire prima che l'applicazione Web accetti le richieste dalla rete. Questo riscaldamento si verifica durante l'avvio del servizio IIS (se il pool di applicazioni IIS è stato configurato come AlwaysRunning) e quando un processo di lavoro IIS viene riciclato. Durante il riciclo, il processo di lavoro IIS precedente continua a eseguire richieste fino a quando il processo di lavoro appena generato non viene completamente riscaldato, in modo che le applicazioni non verifichino interruzioni o altri problemi dovuti a cache nonprime. Si noti che questo modulo funziona con qualsiasi versione di ASP.NET, a partire dalla versione 2.0.
Per altre informazioni, vedere Riscaldamento dell'applicazione nel sito Web IIS.net. Per una procedura dettagliata che illustra come usare la funzionalità di riscaldamento, vedere Introduzione con iis 7.5 Application Warm-Up Module nel sito Web IIS.net.
Per usare la funzionalità di avvio automatico, un amministratore IIS imposta un pool di applicazioni in IIS 7.5 da avviare automaticamente usando la configurazione seguente nel applicationHost.config file:
<applicationpools>
<add name="MyApplicationPool" startMode="AlwaysRunning" />
</applicationpools>
Poiché un singolo pool di applicazioni può contenere più applicazioni, è possibile specificare singole applicazioni da avviare automaticamente usando la configurazione seguente nel applicationHost.config file:
<sites>
<site name="MySite" id="1">
<application path="/"
serviceAutoStartEnabled="true"
serviceAutoStartProvider="PrewarmMyCache" >
<!-- Additional content -->
</application>
</site>
</sites>
<!-- Additional content -->
<serviceautostartproviders>
<add name="PrewarmMyCache"
type="MyNamespace.CustomInitialization, MyLibrary" />
</serviceautostartproviders>
Quando un server IIS 7.5 viene avviato a freddo o quando un singolo pool di applicazioni viene riciclato, IIS 7.5 utilizza le informazioni nel applicationHost.config file per determinare quali applicazioni Web devono essere avviate automaticamente. Per ogni applicazione contrassegnata per l'avvio automatico, IIS7.5 invia una richiesta a ASP.NET 4 per avviare l'applicazione in uno stato durante il quale l'applicazione temporaneamente non accetta richieste HTTP. Quando si trova in questo stato, ASP.NET crea un'istanza del tipo definito dall'attributo serviceAutoStartProvider (come illustrato nell'esempio precedente) e chiama il relativo punto di ingresso pubblico.
Si crea un tipo di avvio automatico gestito con il punto di ingresso necessario implementando l'interfaccia IProcessHostPreloadClient , come illustrato nell'esempio seguente:
public class CustomInitialization : System.Web.Hosting.IProcessHostPreloadClient
{
public void Preload(string[] parameters)
{
// Perform initialization.
}
}
Dopo l'esecuzione del codice di inizializzazione nel metodo Preload e il metodo viene restituito, l'applicazione ASP.NET è pronta per elaborare le richieste.
Con l'aggiunta dell'avvio automatico a IIS .5 e ASP.NET 4, è ora disponibile un approccio ben definito per l'esecuzione di un'inizializzazione costosa dell'applicazione prima di elaborare la prima richiesta HTTP. Ad esempio, è possibile usare la nuova funzionalità di avvio automatico per inizializzare un'applicazione e quindi segnalare a un servizio di bilanciamento del carico che l'applicazione è stata inizializzata e pronta ad accettare il traffico HTTP.
Reindirizzamento permanente di una pagina
È pratica comune nelle applicazioni Web spostare pagine e altri contenuti nel tempo, che possono causare un accumulo di collegamenti non aggiornati nei motori di ricerca. In ASP.NET gli sviluppatori hanno tradizionalmente gestito le richieste agli URL precedenti usando il metodo Response.Redirect per inoltrare una richiesta al nuovo URL. Tuttavia, il metodo Redirect genera una risposta HTTP 302 Found (reindirizzamento temporaneo), che comporta un round trip HTTP aggiuntivo quando gli utenti tentano di accedere agli URL precedenti.
ASP.NET 4 aggiunge un nuovo metodo helper RedirectPermanent che semplifica l'emissione di risposte HTTP 301 spostate in modo permanente, come nell'esempio seguente:
RedirectPermanent("/newpath/foroldcontent.aspx");
I motori di ricerca e altri agenti utente che riconoscono i reindirizzamenti permanenti archivieranno il nuovo URL associato al contenuto, eliminando il round trip non necessario effettuato dal browser per i reindirizzamenti temporanei.
Compattazione dello stato della sessione
ASP.NET offre due opzioni predefinite per l'archiviazione dello stato della sessione in una Web farm: un provider di stato sessione che richiama un server di stato sessione out-of-process e un provider di stato sessione che archivia i dati in un database di Microsoft SQL Server. Poiché entrambe le opzioni comportano l'archiviazione delle informazioni sullo stato all'esterno del processo di lavoro di un'applicazione Web, lo stato della sessione deve essere serializzato prima che venga inviato all'archiviazione remota. A seconda della quantità di informazioni che uno sviluppatore salva nello stato della sessione, le dimensioni dei dati serializzati possono aumentare notevolmente.
ASP.NET 4 introduce una nuova opzione di compressione per entrambi i tipi di provider di stato sessione out-of-process. Quando l'opzione di configurazione compressionEnabled illustrata nell'esempio seguente è impostata su true, ASP.NET comprimerà (e decomprime) lo stato della sessione serializzata usando la classe .NET Framework System.IO.Compression.GZipStream .
<sessionState
mode="SqlServer"
sqlConnectionString="data source=dbserver;Initial Catalog=aspnetstate"
allowCustomSqlDatabase="true"
compressionEnabled="true"
/>
Con l'aggiunta semplice del nuovo attributo al Web.config file, le applicazioni con cicli di CPU risparmiati nei server Web possono realizzare riduzioni sostanziali delle dimensioni dei dati dello stato della sessione serializzati.
Espansione dell'intervallo di URL consentiti
ASP.NET 4 introduce nuove opzioni per espandere le dimensioni degli URL dell'applicazione. Versioni precedenti di ASP.NET lunghezza del percorso URL vincolato a 260 caratteri, in base al limite di percorso del file NTFS. In ASP.NET 4 è possibile aumentare (o diminuire) questo limite in base alle esigenze delle applicazioni, usando due nuovi attributi di configurazione httpRuntime . Nell'esempio seguente vengono illustrati questi nuovi attributi.
<httpRuntime maxUrlLength="260" maxQueryStringLength="2048" />
Per consentire percorsi più lunghi o più brevi (la parte dell'URL che non include protocollo, nome server e stringa di query), modificare l'attributo maxUrlLength . Per consentire stringhe di query più lunghe o più brevi, modificare il valore dell'attributo maxQueryStringLength .
ASP.NET 4 consente anche di configurare i caratteri usati dal controllo dei caratteri URL. Quando ASP.NET trova un carattere non valido nella parte del percorso di un URL, rifiuta la richiesta e genera un errore HTTP 400. Nelle versioni precedenti di ASP.NET, i controlli dei caratteri URL erano limitati a un set fisso di caratteri. In ASP.NET 4 è possibile personalizzare il set di caratteri validi usando il nuovo attributo requestPathInvalidCharacters dell'elemento di configurazione httpRuntime , come illustrato nell'esempio seguente:
<httpRuntime requestPathInvalidCharacters="<,>,*,%,&,:,\,?" />
Per impostazione predefinita, l'attributo requestPathInvalidCharacters definisce otto caratteri come non validi. Nella stringa assegnata a requestPathInvalidCharacters per impostazione predefinita, i caratteri minore di (<), maggiore di (>) e e commerciale (&) vengono codificati, perché il Web.config file è un file XML. È possibile personalizzare il set di caratteri non validi in base alle esigenze.
Nota
Nota ASP.NET 4 rifiuta sempre i percorsi URL che contengono caratteri nell'intervallo ASCII di 0x00 da 0x1F, perché questi sono caratteri URL non validi come definito in RFC 2396 di IETF (http://www.ietf.org/rfc/rfc2396.txt). Nelle versioni di Windows Server che eseguono IIS 6 o versione successiva, il driver di dispositivo del protocollo http.sys rifiuta automaticamente gli URL con questi caratteri.
Convalida delle richieste estendibili
ASP.NET la convalida delle richieste cerca i dati delle richieste HTTP in ingresso per le stringhe comunemente usate negli attacchi XSS (Cross-Site Scripting). Se vengono trovate potenziali stringhe XSS, la convalida della richiesta contrassegna la stringa sospetta e restituisce un errore. La convalida della richiesta predefinita restituisce un errore solo quando rileva le stringhe più comuni usate negli attacchi XSS. I tentativi precedenti di rendere la convalida XSS più aggressiva hanno comportato troppi falsi positivi. Tuttavia, i clienti potrebbero voler richiedere la convalida più aggressiva o, al contrario, potrebbe voler ridurre intenzionalmente i controlli XSS per pagine specifiche o per tipi specifici di richieste.
In ASP.NET 4, la funzionalità di convalida delle richieste è stata resa estendibile in modo da poter usare la logica di convalida delle richieste personalizzata. Per estendere la convalida delle richieste, creare una classe che deriva dal nuovo tipo System.Web.Util.RequestValidator e configurare l'applicazione (nella sezione httpRuntime del Web.config file) per usare il tipo personalizzato. L'esempio seguente illustra come configurare una classe di convalida delle richieste personalizzata:
<httpRuntime requestValidationType="Samples.MyValidator, Samples" />
Il nuovo attributo requestValidationType richiede una stringa di identificatore di tipo .NET Framework standard che specifica la classe che fornisce la convalida della richiesta personalizzata. Per ogni richiesta, ASP.NET richiama il tipo personalizzato per elaborare ogni parte dei dati delle richieste HTTP in ingresso. L'URL in ingresso, tutte le intestazioni HTTP (sia i cookie che le intestazioni personalizzate) e il corpo dell'entità sono tutti disponibili per l'ispezione da parte di una classe di convalida delle richieste personalizzata, come illustrato nell'esempio seguente:
public class CustomRequestValidation : RequestValidator
{
protected override bool IsValidRequestString(
HttpContext context, string value,
RequestValidationSource requestValidationSource,
string collectionKey,
out int validationFailureIndex)
{...}
}
Nei casi in cui non si vuole esaminare una parte di dati HTTP in ingresso, la classe di convalida delle richieste può eseguire il fallback per consentire l'esecuzione della convalida della richiesta predefinita ASP.NET semplicemente chiamando base. IsValidRequestString.
Estendibilità memorizzazione nella cache degli oggetti e memorizzazione nella cache degli oggetti
Sin dalla prima versione, ASP.NET ha incluso una potente cache di oggetti in memoria (System.Web.Caching.Cache). L'implementazione della cache è stata così diffusa che è stata usata nelle applicazioni non Web. Tuttavia, è difficile per un'applicazione Windows Forms o WPF includere un riferimento solo per System.Web.dll poter usare la cache degli oggetti ASP.NET.
Per rendere disponibile la memorizzazione nella cache per tutte le applicazioni, .NET Framework 4 introduce un nuovo assembly, un nuovo spazio dei nomi, alcuni tipi di base e un'implementazione di memorizzazione nella cache concreta. Il nuovo System.Runtime.Caching.dll assembly contiene una nuova API di memorizzazione nella cache nello spazio dei nomi System.Runtime.Caching . Lo spazio dei nomi contiene due set di base di classi:
- Tipi astratti che forniscono le basi per la creazione di qualsiasi tipo di implementazione della cache personalizzata.
- Implementazione concreta della cache degli oggetti in memoria (classe System.Runtime.Caching.MemoryCache ).
La nuova classe MemoryCache è modellata attentamente sulla cache ASP.NET e condivide gran parte della logica del motore della cache interna con ASP.NET. Anche se le API di memorizzazione nella cache pubblica in System.Runtime.Caching sono state aggiornate per supportare lo sviluppo di cache personalizzate, se è stato usato l'oggetto ASP.NET Cache , sono disponibili concetti noti nelle nuove API.
Una discussione approfondita della nuova classe MemoryCache e del supporto delle API di base richiederebbe un intero documento. L'esempio seguente offre tuttavia un'idea del funzionamento della nuova API della cache. L'esempio è stato scritto per un'applicazione Windows Forms, senza alcuna dipendenza da System.Web.dll.
private void btnGet_Click(object sender, EventArgs e)
{
//Obtain a reference to the default MemoryCache instance.
//Note that you can create multiple MemoryCache(s) inside
//of a single application.
ObjectCache cache = MemoryCache.Default;
//In this example the cache is storing the contents of a file string
fileContents = cache["filecontents"] as string;
//If the file contents are not currently in the cache, then
//the contents are read from disk and placed in the cache.
if (fileContents == null)
{
//A CacheItemPolicy object holds all the pieces of cache
//dependency and cache expiration metadata related to a single
//cache entry.
CacheItemPolicy policy = new CacheItemPolicy();
//Build up the information necessary to create a file dependency.
//In this case we just need the file path of the file on disk.
List filePaths = new List();
filePaths.Add("c:\\data.txt");
//In the new cache API, dependencies are called "change monitors".
//For this example we want the cache entry to be automatically expired
//if the contents on disk change. A HostFileChangeMonitor provides
//this functionality.
policy.ChangeMonitors.Add(new HostFileChangeMonitor(filePaths));
//Fetch the file's contents
fileContents = File.ReadAllText("c:\\data.txt");
//And then store the file's contents in the cache
cache.Set("filecontents", fileContents, policy);
}
MessageBox.Show(fileContents);
}
Codifica dell'intestazione HTTP, URL e HTML estendibile
In ASP.NET 4 è possibile creare routine di codifica personalizzate per le seguenti attività comuni di codifica testuale:
- Codifica HTML.
- Codifica URL.
- Codifica degli attributi HTML.
- Codifica delle intestazioni HTTP in uscita.
È possibile creare un codificatore personalizzato derivando dal nuovo tipo System.Web.Util.HttpEncoder e quindi configurando ASP.NET per usare il tipo personalizzato nella sezione httpRuntime del Web.config file, come illustrato nell'esempio seguente:
<httpRuntime encoderType="Samples.MyCustomEncoder, Samples" />
Dopo aver configurato un codificatore personalizzato, ASP.NET chiama automaticamente l'implementazione della codifica personalizzata ogni volta che vengono chiamati i metodi di codifica pubblica delle classi System.Web.HttpUtility o System.Web.HttpServerUtility . In questo modo, una parte di un team di sviluppo Web crea un codificatore personalizzato che implementa la codifica dei caratteri aggressiva, mentre il resto del team di sviluppo Web continua a usare le API di codifica ASP.NET pubbliche. Configurando centralmente un codificatore personalizzato nell'elemento httpRuntime , si garantisce che tutte le chiamate di codifica del testo provenienti dalle API di codifica ASP.NET pubbliche vengano instradate attraverso il codificatore personalizzato.
Monitoraggio delle prestazioni per singole applicazioni in un singolo processo di lavoro
Per aumentare il numero di siti Web che possono essere ospitati in un singolo server, molti host eseguono più applicazioni ASP.NET in un singolo processo di lavoro. Tuttavia, se più applicazioni usano un singolo processo di lavoro condiviso, è difficile per gli amministratori del server identificare una singola applicazione che riscontra problemi.
ASP.NET 4 sfrutta le nuove funzionalità di monitoraggio delle risorse introdotte da CLR. Per abilitare questa funzionalità, è possibile aggiungere il frammento di configurazione XML seguente al aspnet.config file di configurazione.
<?xml version="1.0" encoding="UTF-8" ?>
<configuration>
<runtime>
<appDomainResourceMonitoring enabled="true"/>
</runtime>
</configuration>
Nota
Nota Il aspnet.config file si trova nella directory in cui è installato .NET Framework. Non è il Web.config file.
Quando la funzionalità appDomainResourceMonitoring è stata abilitata, nella categoria di prestazioni "ASP.NET Applications" sono disponibili due nuovi contatori delle prestazioni: % Tempo processore gestito e Memoria gestita usata. Entrambi questi contatori delle prestazioni usano la nuova funzionalità di gestione delle risorse CLR del dominio applicazione per tenere traccia del tempo di CPU stimato e dell'utilizzo della memoria gestita delle singole applicazioni ASP.NET. Di conseguenza, con ASP.NET 4, gli amministratori hanno ora una visualizzazione più granulare dell'utilizzo delle risorse delle singole applicazioni in esecuzione in un singolo processo di lavoro.
Multitargeting
È possibile creare un'applicazione destinata a una versione specifica di .NET Framework. In ASP.NET 4, un nuovo attributo nell'elemento di compilazione del Web.config file consente di usare .NET Framework 4 e versioni successive. Se si specifica in modo esplicito come destinazione .NET Framework 4 e se si includono elementi facoltativi nel Web.config file, ad esempio le voci per system.codedom, questi elementi devono essere corretti per .NET Framework 4. Se non si specifica in modo esplicito come destinazione .NET Framework 4, il framework di destinazione viene dedotto dalla mancanza di una voce nel Web.config file.
Nell'esempio seguente viene illustrato l'uso dell'attributo targetFramework nell'elemento di compilazione del Web.config file.
<compilation targetFramework="4.0"/>
Si noti quanto segue sulla destinazione di una versione specifica di .NET Framework:
- In un pool di applicazioni .NET Framework 4, il sistema di compilazione ASP.NET presuppone .NET Framework 4 come destinazione se il
Web.configfile non include l'attributo targetFramework o se ilWeb.configfile non è presente. Potrebbe essere necessario apportare modifiche di codifica all'applicazione per eseguirla in .NET Framework 4. - Se si include l'attributo targetFramework e se l'elemento system.codeDom è definito nel
Web.configfile, questo file deve contenere le voci corrette per .NET Framework 4. - Se si usa il comando aspnet_compiler per precompilare l'applicazione , ad esempio in un ambiente di compilazione, è necessario usare la versione corretta del comando aspnet_compiler per il framework di destinazione. Usare il compilatore fornito con .NET Framework 2.0 (%WINDIR%\Microsoft.NET\Framework\v2.0.50727) per la compilazione per .NET Framework 3.5 e versioni precedenti. Usare il compilatore fornito con .NET Framework 4 per compilare le applicazioni create con tale framework o usando versioni successive.
- In fase di esecuzione, il compilatore usa gli assembly framework più recenti installati nel computer e pertanto nella GAC. Se un aggiornamento viene eseguito in un secondo momento nel framework (ad esempio, è installata una versione ipotetica 4.1), sarà possibile usare le funzionalità nella versione più recente del framework anche se l'attributo targetFramework è destinato a una versione precedente ,ad esempio 4.0. Tuttavia, in fase di progettazione in Visual Studio 2010 o quando si usa il comando aspnet_compiler , l'uso di funzionalità più recenti del framework causerà errori del compilatore.
Ajax
jQuery incluso con Web Forms e MVC
I modelli di Visual Studio per Web Forms e MVC includono la libreria jQuery open source. Quando si crea un nuovo sito Web o progetto, viene creata una cartella Scripts contenente i 3 file seguenti:
- jQuery-1.4.1.js: versione leggibile e non modificata della libreria jQuery.
- jQuery-14.1.min.js: versione minimizzata della libreria jQuery.
- jQuery-1.4.1-vsdoc.js: file di documentazione di IntelliSense per la libreria jQuery.
Includere la versione unificata di jQuery durante lo sviluppo di un'applicazione. Includere la versione minimizzata di jQuery per le applicazioni di produzione.
Ad esempio, la pagina di Web Forms seguente illustra come è possibile usare jQuery per modificare il colore di sfondo dei controlli TextBox ASP.NET in giallo quando hanno lo stato attivo.
<%@ Page Language="C#" AutoEventWireup="true" CodeFile="ShowjQuery.aspx.cs" Inherits="ShowjQuery" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
<title>Show jQuery</title>
</head>
<body>
<form id="form1" runat="server">
<div>
<asp:TextBox ID="txtFirstName" runat="server" />
<br />
<asp:TextBox ID="txtLastName" runat="server" />
</div>
</form>
<script src="Scripts/jquery-1.4.1.js" type="text/javascript"></script>
<script type="text/javascript">
$("input").focus( function() { $(this).css("background-color", "yellow"); });
</script>
</body>
</html>
Supporto della rete per la distribuzione di contenuti
Microsoft Ajax Content Delivery Network (CDN) consente di aggiungere facilmente ASP.NET script Ajax e jQuery alle applicazioni Web. Ad esempio, è possibile iniziare a usare la libreria jQuery semplicemente aggiungendo un <script> tag alla pagina che punta a Ajax.microsoft.com come segue:
<script src="https://ajax.aspnetcdn.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. Il contenuto della rete CDN Microsoft Ajax viene memorizzato nella cache nei server che si trovano 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 per la distribuzione di contenuti Microsoft Ajax supporta SSL (HTTPS) nel caso in cui sia necessario gestire una pagina Web usando Secure Sockets Layer.
Implementare un fallback quando la rete CDN non è disponibile. Testare il fallback.
Per altre informazioni sulla rete CDN Microsoft Ajax, visitare il sito Web seguente:
https://www.asp.net/ajaxlibrary/CDN.ashx
ScriptManager ASP.NET supporta la rete CDN Microsoft Ajax. Impostando semplicemente una proprietà, la proprietà EnableCdn, è possibile recuperare tutti i file JavaScript del framework ASP.NET dalla rete CDN:
<asp:ScriptManager ID="sm1" EnableCdn="true" runat="server" />
Dopo aver impostato la proprietà EnableCdn sul valore true, il framework di ASP.NET recupererà tutti i file JavaScript del framework ASP.NET dalla rete CDN, inclusi tutti i file JavaScript usati per la convalida e UpdatePanel. L'impostazione di questa proprietà può avere un impatto significativo sulle prestazioni dell'applicazione Web.
È possibile impostare il percorso della rete CDN per i propri file JavaScript usando l'attributo WebResource. La nuova proprietà CdnPath specifica il percorso della rete CDN usata quando si imposta la proprietà EnableCdn sul valore true:
[assembly: WebResource("Foo.js", "application/x-javascript", CdnPath = "http://foo.com/foo/bar/foo.js")]
ScriptManager espliciti
In passato, se si usava il ASP.NET ScriptManger, era necessario caricare l'intera libreria monolitica ASP.NET Ajax. Sfruttando la nuova proprietà ScriptManager.AjaxFrameworkMode, è possibile controllare esattamente quali componenti della libreria ASP.NET Ajax vengono caricati e caricati solo i componenti della libreria ASP.NET Ajax necessari.
La proprietà ScriptManager.AjaxFrameworkMode può essere impostata sui valori seguenti:
- Abilitato: specifica che il controllo ScriptManager include automaticamente il file di script MicrosoftAjax.js, ovvero un file di script combinato di ogni script del framework principale (comportamento legacy).
- Disabilitato: specifica che tutte le funzionalità di script Microsoft Ajax sono disabilitate e che il controllo ScriptManager non fa riferimento automaticamente ad alcun script.
- Esplicito: specifica che verranno inclusi in modo esplicito i riferimenti di script a un singolo file di script core del framework richiesto dalla pagina e che verranno inclusi riferimenti alle dipendenze richieste da ogni file di script.
Ad esempio, se si imposta la proprietà AjaxFrameworkMode sul valore Explicit, è possibile specificare gli script specifici ASP.NET componente Ajax necessari:
<asp:ScriptManager ID="sm1" AjaxFrameworkMode="Explicit" runat="server">
<Scripts>
<asp:ScriptReference Name="MicrosoftAjaxCore.js" />
<asp:ScriptReference Name="MicrosoftAjaxComponentModel.js" />
<asp:ScriptReference Name="MicrosoftAjaxSerialization.js" />
<asp:ScriptReference Name="MicrosoftAjaxNetwork.js" />
</Scripts>
</asp:ScriptManager>
Web Form
Web Forms è stata una funzionalità di base in ASP.NET dal rilascio di ASP.NET 1.0. Molti miglioramenti sono stati in questo settore per ASP.NET 4, tra cui i seguenti:
- Possibilità di impostare i meta tag.
- Maggiore controllo sullo stato di visualizzazione.
- Modi più semplici per usare le funzionalità del browser.
- Supporto per l'uso del routing di ASP.NET con Web Forms.
- Maggiore controllo sugli ID generati.
- Possibilità di rendere persistenti le righe selezionate nei controlli dati.
- Maggiore controllo sul rendering del codice HTML nei controlli FormView e ListView .
- Supporto del filtro per i controlli origine dati.
Impostazione dei meta tag con le proprietà Page.MetaKeywords e Page.MetaDescription
ASP.NET 4 aggiunge due proprietà alla classe Page , MetaKeywords e MetaDescription. Queste due proprietà rappresentano i meta tag corrispondenti nella pagina, come illustrato nell'esempio seguente:
<head id="Head1" runat="server">
<title>Untitled Page</title>
<meta name="keywords" content="These, are, my, keywords" />
<meta name="description" content="This is the description of my page" />
</head>
Queste due proprietà funzionano allo stesso modo in cui viene usata la proprietà Title della pagina. Seguono queste regole:
- Se nell'elemento head non sono presenti meta tag che corrispondono ai nomi delle proprietà , ovvero name="keywords" per Page.MetaKeywords e name="description" per Page.MetaDescription, ovvero che queste proprietà non sono state impostate, i meta tag verranno aggiunti alla pagina quando ne viene eseguito il rendering.
- Se esistono già meta tag con questi nomi, queste proprietà fungono da metodi get e set per il contenuto dei tag esistenti.
È possibile impostare queste proprietà in fase di esecuzione, che consente di ottenere il contenuto da un database o da un'altra origine e di impostare i tag in modo dinamico per descrivere il tipo di pagina specifico.
È anche possibile impostare le proprietà Keywords e Description nella direttiva @ Page nella parte superiore del markup di pagina Web Forms, come nell'esempio seguente:
<%@ Page Language="C#" AutoEventWireup="true"
CodeFile="Default.aspx.cs"
Inherits="_Default"
Keywords="These, are, my, keywords"
Description="This is a description" %>
Verrà eseguito l'override del contenuto del meta tag (se presente) già dichiarato nella pagina.
Il contenuto del meta tag di descrizione viene usato per migliorare le anteprime delle voci di ricerca in Google. Per informazioni dettagliate, vedere Migliorare i frammenti di codice con una meta description makeover sul blog di Google Webmaster Central. Google e Windows Live Search non usano il contenuto delle parole chiave per qualsiasi cosa, ma altri motori di ricerca potrebbero.
Queste nuove proprietà sono una funzionalità semplice, ma consentono di risparmiare dal requisito di aggiungerle manualmente o dalla scrittura di codice personalizzato per creare i meta tag.
Abilitazione dello stato di visualizzazione per i singoli controlli
Per impostazione predefinita, lo stato di visualizzazione è abilitato per la pagina, con il risultato che ogni controllo nella pagina archivia potenzialmente lo stato di visualizzazione anche se non è necessario per l'applicazione. I dati sullo stato di visualizzazione sono inclusi nel markup generato da una pagina e aumentano il tempo necessario per inviare una pagina al client e pubblicarla nuovamente. L'archiviazione di più stato di visualizzazione di quanto sia necessario può causare una riduzione significativa delle prestazioni. Nelle versioni precedenti di ASP.NET, gli sviluppatori potevano disabilitare lo stato di visualizzazione per singoli controlli per ridurre le dimensioni della pagina, ma dovevano farlo in modo esplicito per i singoli controlli. In ASP.NET 4 i controlli server Web includono una proprietà ViewStateMode che consente di disabilitare lo stato di visualizzazione per impostazione predefinita e quindi abilitarla solo per i controlli che lo richiedono nella pagina.
La proprietà ViewStateMode accetta un'enumerazione con tre valori: Enabled, Disabled e Inherit. Abilitato abilita lo stato di visualizzazione per tale controllo e per tutti i controlli figlio impostati su Inherit o che non hanno alcun valore impostato. Disabilitato disabilita lo stato di visualizzazione e Inherit specifica che il controllo utilizza l'impostazione ViewStateMode dal controllo padre.
Nell'esempio seguente viene illustrato il funzionamento della proprietà ViewStateMode . Il markup e il codice per i controlli nella pagina seguente includono i valori per la proprietà ViewStateMode :
<form id="form1" runat="server">
<script runat="server">
protected override void OnLoad(EventArgs e) {
if (!IsPostBack) {
label1.Text = label2.Text = "[DynamicValue]";
}
base.OnLoad(e);
}
</script>
<asp:PlaceHolder ID="PlaceHolder1" runat="server" ViewStateMode="Disabled">
Disabled: <asp:Label ID="label1" runat="server" Text="[DeclaredValue]" /><br />
<asp:PlaceHolder ID="PlaceHolder2" runat="server" ViewStateMode="Enabled">
Enabled: <asp:Label ID="label2" runat="server" Text="[DeclaredValue]" />
</asp:PlaceHolder>
</asp:PlaceHolder>
<hr />
<asp:button ID="Button1" runat="server" Text="Postback" />
<%-- Further markup here --%>
Come si può notare, il codice disabilita lo stato di visualizzazione per il controllo PlaceHolder1. Il controllo child label1 eredita questo valore della proprietà (Inherit è il valore predefinito per ViewStateMode per i controlli) e quindi non salva alcuno stato di visualizzazione. Nel controllo PlaceHolder2 ViewStateMode è impostato su Enabled, quindi label2 eredita questa proprietà e salva lo stato di visualizzazione. Quando la pagina viene caricata per la prima volta, la proprietà Text di entrambi i controlli Label viene impostata sulla stringa "[DynamicValue]".
L'effetto di queste impostazioni è che quando la pagina viene caricata la prima volta, nel browser viene visualizzato l'output seguente:
Disabili : [DynamicValue]
Abilitato:[DynamicValue]
Dopo un postback, tuttavia, viene visualizzato l'output seguente:
Disabili : [DeclaredValue]
Abilitato:[DynamicValue]
Il controllo label1 (il cui valore ViewStateMode è impostato su Disabled) non ha mantenuto il valore impostato su nel codice. Tuttavia, il controllo label2 (il cui valore ViewStateMode è impostato su Enabled) ha mantenuto lo stato.
È anche possibile impostare ViewStateMode nella direttiva @ Page , come nell'esempio seguente:
<%@ Page Language="C#" AutoEventWireup="true"
CodeBehind="Default.aspx.cs"
Inherits="WebApplication1._Default"
ViewStateMode="Disabled" %>
La classe Page è solo un altro controllo; funge da controllo padre per tutti gli altri controlli della pagina. Il valore predefinito di ViewStateMode è Enabled per le istanze di Page. Poiché per impostazione predefinita i controlli ereditano il valore della proprietà Enabled , a meno che non si imposti ViewStateMode a livello di pagina o controllo.
Il valore della proprietà ViewStateMode determina se lo stato di visualizzazione viene mantenuto solo se la proprietà EnableViewState è impostata su true. Se la proprietà EnableViewState è impostata su false, lo stato di visualizzazione non verrà mantenuto anche se ViewStateMode è impostato su Enabled.
Un buon uso per questa funzionalità è costituito dai controlli ContentPlaceHolder nelle pagine master, in cui è possibile impostare ViewStateMode su Disabled per la pagina master e quindi abilitarlo singolarmente per i controlli ContentPlaceHolder che a loro volta contengono controlli che richiedono lo stato di visualizzazione.
Modifiche alle funzionalità del browser
ASP.NET determina le funzionalità del browser che un utente usa per esplorare il sito usando una funzionalità denominata funzionalità del browser. Le funzionalità del browser sono rappresentate dall'oggetto HttpBrowserCapabilities (esposto dalla proprietà Request.Browser ). Ad esempio, è possibile utilizzare l'oggetto HttpBrowserCapabilities per determinare se il tipo e la versione del browser corrente supportano una versione specifica di JavaScript. In alternativa, è possibile utilizzare l'oggetto HttpBrowserCapabilities per determinare se la richiesta ha avuto origine da un dispositivo mobile.
L'oggetto HttpBrowserCapabilities è basato su un set di file di definizione del browser. Questi file contengono informazioni sulle funzionalità di browser specifici. In ASP.NET 4, questi file di definizione del browser sono stati aggiornati per contenere informazioni sui browser e i dispositivi introdotti di recente, ad esempio Google Chrome, Research in Motion BlackBerry smartphone e Apple iPhone.
L'elenco seguente mostra i nuovi file di definizione del browser:
- blackberry.browser
- chrome.browser
- Default.browser
- firefox.browser
- gateway.browser
- generic.browser
- ie.browser
- iemobile.browser
- iphone.browser
- opera.browser
- safari.browser
Uso dei provider di funzionalità del browser
In ASP.NET versione 3.5 Service Pack 1 è possibile definire le funzionalità disponibili in un browser nei modi seguenti:
A livello di computer, si crea o si aggiorna un
.browserfile XML nella cartella seguente:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\BrowsersDopo aver definito la funzionalità del browser, eseguire il comando seguente dal prompt dei comandi di Visual Studio per ricompilare l'assembly delle funzionalità del browser e aggiungerlo alla GAC:
aspnet_regbrowsers.exe -I cPer una singola applicazione, si crea un
.browserfile nella cartella dell'applicazioneApp_Browsers.
Questi approcci richiedono la modifica dei file XML e, per le modifiche a livello di computer, è necessario riavviare l'applicazione dopo aver eseguito il processo di aspnet_regbrowsers.exe.
ASP.NET 4 include una funzionalità denominata provider di funzionalità del browser. Come suggerisce il nome, questo consente di creare un provider che a sua volta consente di usare il proprio codice per determinare le funzionalità del browser.
In pratica, gli sviluppatori spesso non definiscono funzionalità del browser personalizzate. I file del browser sono difficili da aggiornare, il processo per l'aggiornamento è piuttosto complesso e la sintassi XML per .browser i file può essere complessa da usare e definire. Ciò che renderebbe molto più semplice questo processo è se esistesse una sintassi di definizione del browser comune o un database che contiene definizioni di browser aggiornate o anche un servizio Web per tale database. La nuova funzionalità dei provider di funzionalità del browser rende questi scenari possibili e pratici per gli sviluppatori di terze parti.
Esistono due approcci principali per l'uso della nuova funzionalità del browser ASP.NET 4: l'estensione della funzionalità di definizione delle funzionalità del browser ASP.NET o la sua sostituzione completa. Le sezioni seguenti descrivono prima come sostituire la funzionalità e quindi come estenderla.
Sostituzione delle funzionalità del browser ASP.NET
Per sostituire completamente la funzionalità di definizione delle funzionalità del browser ASP.NET, seguire questa procedura:
Creare una classe provider che deriva da HttpCapabilitiesProvider e che esegue l'override del metodo GetBrowserCapabilities , come nell'esempio seguente:
public class CustomProvider : HttpCapabilitiesProvider { public override HttpBrowserCapabilities GetBrowserCapabilities(HttpRequest request) { HttpBrowserCapabilities browserCaps = new HttpBrowserCapabilities(); Hashtable values = new Hashtable(180, StringComparer.OrdinalIgnoreCase); values[String.Empty] = request.UserAgent; values["browser"] = "MyCustomBrowser"; browserCaps.Capabilities = values; return browserCaps; } }Il codice in questo esempio crea un nuovo oggetto HttpBrowserCapabilities , specificando solo la funzionalità denominata browser e impostando tale funzionalità su MyCustomBrowser.
Registrare il provider con l'applicazione.
Per usare un provider con un'applicazione, è necessario aggiungere l'attributo del provider alla sezione browserCaps nei
Web.configfile oMachine.config. È anche possibile definire gli attributi del provider in un elemento location per directory specifiche nell'applicazione, ad esempio in una cartella per un dispositivo mobile specifico. Nell'esempio seguente viene illustrato come impostare l'attributo del provider in un file di configurazione:<system.web> <browserCaps provider="ClassLibrary2.CustomProvider, ClassLibrary2, Version=1.0.0.0, Culture=neutral" /> </system.web>Un altro modo per registrare la nuova definizione di funzionalità del browser consiste nell'usare il codice, come illustrato nell'esempio seguente:
void Application_Start(object sender, EventArgs e) { HttpCapabilitiesBase.BrowserCapabilitiesProvider = new ClassLibrary2.CustomProvider(); // ... }Questo codice deve essere eseguito nell'evento Application_Start del
Global.asaxfile. Tutte le modifiche apportate alla classe BrowserCapabilitiesProvider devono verificarsi prima dell'esecuzione di qualsiasi codice nell'applicazione, per assicurarsi che la cache rimanga in uno stato valido per l'oggetto HttpCapabilitiesBase risolto.
Memorizzazione nella cache dell'oggetto HttpBrowserCapabilities
L'esempio precedente presenta un problema, ovvero che il codice verrebbe eseguito ogni volta che viene richiamato il provider personalizzato per ottenere l'oggetto HttpBrowserCapabilities . Questa situazione può verificarsi più volte durante ogni richiesta. Nell'esempio il codice per il provider non esegue molte operazioni. Tuttavia, se il codice nel provider personalizzato esegue un lavoro significativo per ottenere l'oggetto HttpBrowserCapabilities , ciò può influire sulle prestazioni. Per evitare che ciò accada, è possibile memorizzare nella cache l'oggetto HttpBrowserCapabilities . Seguire questa procedura:
Creare una classe che deriva da HttpCapabilitiesProvider, come quella nell'esempio seguente:
public class CustomProvider : HttpCapabilitiesProvider { public override HttpBrowserCapabilities GetBrowserCapabilities(HttpRequest request) { string cacheKey = BuildCacheKey(); int cacheTime = GetCacheTime(); HttpBrowserCapabilities browserCaps = HttpContext.Current.Cache[cacheKey] as HttpBrowserCapabilities; if (browserCaps == null) { HttpBrowserCapabilities browserCaps = new HttpBrowserCapabilities(); Hashtable values = new Hashtable(180, StringComparer.OrdinalIgnoreCase); values[String.Empty] = request.UserAgent; values["browser"] = "MyCustomBrowser"; browserCaps.Capabilities = values; HttpContext.Current.Cache.Insert(cacheKey, browserCaps, null, DateTime.MaxValue, TimeSpan.FromSeconds(cacheTime)); } return browserCaps; } }Nell'esempio, il codice genera una chiave della cache chiamando un metodo BuildCacheKey personalizzato e ottiene il tempo di memorizzazione nella cache chiamando un metodo GetCacheTime personalizzato. Il codice aggiunge quindi l'oggetto HttpBrowserCapabilities risolto alla cache. L'oggetto può essere recuperato dalla cache e riutilizzato nelle richieste successive che usano il provider personalizzato.
Registrare il provider con l'applicazione come descritto nella procedura precedente.
Estensione delle funzionalità del browser ASP.NET
La sezione precedente descrive come creare un nuovo oggetto HttpBrowserCapabilities in ASP.NET 4. È anche possibile estendere le funzionalità del browser ASP.NET aggiungendo nuove definizioni di funzionalità del browser a quelle già presenti in ASP.NET. È possibile eseguire questa operazione senza usare le definizioni del browser XML. La procedura seguente illustra come.
Creare una classe che deriva da HttpCapabilitiesEvaluator e che esegue l'override del metodo GetBrowserCapabilities , come illustrato nell'esempio seguente:
public class CustomProvider : HttpCapabilitiesEvaluator { public override HttpBrowserCapabilities GetBrowserCapabilities(HttpRequest request) { HttpBrowserCapabilities browserCaps = base.GetHttpBrowserCapabilities(request); if (browserCaps.Browser == "Unknown") { browserCaps = MyBrowserCapabilitiesEvaulator(request); } return browserCaps; } }Questo codice usa innanzitutto la funzionalità del browser ASP.NET per provare a identificare il browser. Tuttavia, se nessun browser viene identificato in base alle informazioni definite nella richiesta , ovvero se la proprietà Browser dell'oggetto HttpBrowserCapabilities è la stringa "Unknown", il codice chiama il provider personalizzato (MyBrowserCapabilitiesEvaluator) per identificare il browser.
Registrare il provider con l'applicazione come descritto nell'esempio precedente.
Estensione delle funzionalità del browser aggiungendo nuove funzionalità alle definizioni di funzionalità esistenti
Oltre a creare un provider di definizione del browser personalizzato e a creare dinamicamente nuove definizioni del browser, è possibile estendere le definizioni del browser esistenti con funzionalità aggiuntive. In questo modo è possibile usare una definizione vicina a ciò che si vuole, ma mancano solo alcune funzionalità. A tale scopo, attenersi alla procedura seguente.
Creare una classe che deriva da HttpCapabilitiesEvaluator e che esegue l'override del metodo GetBrowserCapabilities , come illustrato nell'esempio seguente:
public class CustomProvider : HttpCapabilitiesEvaluator { public override HttpBrowserCapabilities GetBrowserCapabilities(HttpRequest request) { HttpBrowserCapabilities browserCaps = base.GetHttpBrowserCapabilities(request); if (browserCaps.Browser == "Unknown") { browserCaps = MyBrowserCapabilitiesEvaulator(request); } return browserCaps; } }Il codice di esempio estende la classe ASP.NET HttpCapabilitiesEvaluator esistente e ottiene l'oggetto HttpBrowserCapabilities che corrisponde alla definizione della richiesta corrente usando il codice seguente:
HttpBrowserCapabilities browserCaps = base.GetHttpBrowserCapabilities(request);Il codice può quindi aggiungere o modificare una funzionalità per questo browser. Esistono due modi per specificare una nuova funzionalità del browser:
Aggiungere una coppia chiave/valore all'oggetto IDictionary esposto dalla proprietà Capabilities dell'oggetto HttpCapabilitiesBase . Nell'esempio precedente il codice aggiunge una funzionalità denominata MultiTouch con un valore true.
Impostare le proprietà esistenti dell'oggetto HttpCapabilitiesBase . Nell'esempio precedente il codice imposta la proprietà Frames su true. Questa proprietà è semplicemente una funzione di accesso per l'oggetto IDictionary esposto dalla proprietà Capabilities .
Nota
Nota Questo modello si applica a qualsiasi proprietà di HttpBrowserCapabilities, inclusi gli adattatori di controllo.
Registrare il provider con l'applicazione come descritto nella procedura precedente.
Routing in ASP.NET 4
ASP.NET 4 aggiunge il supporto predefinito per l'uso del routing con Web Forms. Il routing consente di configurare un'applicazione per accettare GLI URL di richiesta che non eseguono il mapping ai file fisici. È invece possibile usare il routing per definire gli URL significativi per gli utenti e che possono essere utili per l'ottimizzazione del motore di ricerca per l'applicazione. Ad esempio, l'URL di una pagina che visualizza le categorie di prodotti in un'applicazione esistente potrebbe essere simile all'esempio seguente:
http://website/products.aspx?categoryid=12
Usando il routing, è possibile configurare l'applicazione in modo da accettare l'URL seguente per eseguire il rendering delle stesse informazioni:
http://website/products/software
Il routing è disponibile a partire da ASP.NET 3.5 SP1. Per un esempio di come usare il routing in ASP.NET 3.5 SP1, vedere la voce Uso del routing con WebForms nel blog di Phil Haack. Tuttavia, ASP.NET 4 include alcune funzionalità che semplificano l'uso del routing, tra cui:
- Classe PageRouteHandler , che è un semplice gestore HTTP usato quando si definiscono le route. La classe passa i dati alla pagina a cui viene instradata la richiesta.
- Le nuove proprietà HttpRequest.RequestContext e Page.RouteData , ovvero un proxy per l'oggetto HttpRequest.RequestContext.RouteData . Queste proprietà semplificano l'accesso alle informazioni passate dalla route.
- I nuovi generatori di espressioni seguenti, definiti in System.Web.Compilation.RouteUrlExpressionBuilder e System.Web.Compilation.RouteValueExpressionBuilder:
- RouteUrl, che consente di creare un URL che corrisponde a un URL di route all'interno di un controllo server di ASP.NET.
- RouteValue, che offre un modo semplice per estrarre informazioni dall'oggetto RouteContext .
- La classe RouteParameter , che semplifica il passaggio di dati contenuti in un oggetto RouteContext a una query per un controllo origine dati (simile a FormParameter).
Routing per pagine Web Forms
Nell'esempio seguente viene illustrato come definire una route Web Forms usando il nuovo metodo MapPageRoute della classe Route:
public class Global : System.Web.HttpApplication
{
void Application_Start(object sender, EventArgs e)
{
RouteTable.Routes.MapPageRoute("SearchRoute",
"search/{searchterm}", "~/search.aspx");
RouteTable.Routes.MapPageRoute("UserRoute",
"users/{username}", "~/users.aspx");
}
}
ASP.NET 4 introduce il metodo MapPageRoute . L'esempio seguente equivale alla definizione searchRoute illustrata nell'esempio precedente, ma usa la classe PageRouteHandler .
RouteTable.Routes.Add("SearchRoute", new Route("search/{searchterm}",
new PageRouteHandler("~/search.aspx")));
Il codice nell'esempio esegue il mapping della route a una pagina fisica (nella prima route, a ~/search.aspx). La prima definizione di route specifica anche che il parametro denominato searchterm deve essere estratto dall'URL e passato alla pagina.
Il metodo MapPageRoute supporta gli overload del metodo seguenti:
- MapPageRoute(string routeName, string routeUrl, string physicalFile, bool checkPhysicalUrlAccess)
- MapPageRoute(string routeName, string routeUrl, string physicalFile, bool checkPhysicalUrlAccess, RouteValueDictionary defaults)
- MapPageRoute(string routeName, string routeUrl, string physicalFile, bool checkPhysicalUrlAccess, RouteValueDictionary defaults, RouteValueDictionary constraints)
Il parametro checkPhysicalUrlAccess specifica se la route deve controllare le autorizzazioni di sicurezza per la pagina fisica a cui viene instradata (in questo caso search.aspx) e le autorizzazioni per l'URL in ingresso (in questo caso, search/{searchterm}). Se il valore di checkPhysicalUrlAccess è false, verranno controllate solo le autorizzazioni dell'URL in ingresso. Queste autorizzazioni vengono definite nel Web.config file usando impostazioni come le seguenti:
<configuration>
<location path="search.aspx">
<system.web>
<authorization>
<allow roles="admin"/>
<deny users="*"/>
</authorization>
</system.web>
</location>
<location path="search">
<system.web>
<authorization>
<allow users="*"/>
</authorization>
</system.web>
</location>
</configuration>
Nella configurazione di esempio viene negato l'accesso alla pagina search.aspx fisica per tutti gli utenti, ad eccezione di quelli che si trovano nel ruolo di amministratore. Quando il parametro checkPhysicalUrlAccess è impostato su true (ovvero il valore predefinito), solo gli utenti amministratori possono accedere all'URL /search/{searchterm}, perché la pagina fisica search.aspx è limitata agli utenti di tale ruolo. Se checkPhysicalUrlAccess è impostato su false e il sito è configurato come illustrato nell'esempio precedente, tutti gli utenti autenticati possono accedere all'URL /search/{searchterm}.
Lettura delle informazioni di routing in una pagina Web Forms
Nel codice della pagina fisica Web Forms è possibile accedere alle informazioni estratte dal routing dall'URL (o altre informazioni aggiunte da un altro oggetto all'oggetto RouteData) usando due nuove proprietà: HttpRequest.RequestContext e Page.RouteData. Page.RouteData esegue il wrapping di HttpRequest.RequestContext.RouteData. Nell'esempio seguente viene illustrato come usare Page.RouteData.
protected void Page_Load(object sender, EventArgs e)
{
string searchterm = Page.RouteData.Values["searchterm"] as string;
label1.Text = searchterm;
}
Il codice estrae il valore passato per il parametro searchterm, come definito nella route di esempio precedente. Prendere in considerazione l'URL della richiesta seguente:
http://localhost/search/scott/
Quando viene effettuata questa richiesta, viene eseguito il rendering della parola "scott" nella search.aspx pagina.
Accesso alle informazioni di routing nel markup
Il metodo descritto nella sezione precedente illustra come ottenere i dati di route nel codice in una pagina di Web Forms. È anche possibile usare espressioni nel markup che consentono di accedere alle stesse informazioni. I generatori di espressioni sono un modo potente ed elegante per lavorare con codice dichiarativo. Per altre informazioni, vedere la voce Express Yourself With Custom Expression Builders (Express Yourself With Custom Expression Builders ) nel blog di Phil Haack.
ASP.NET 4 include due nuovi generatori di espressioni per il routing di Web Forms. Nell'esempio seguente viene illustrato come usarli.
<asp:HyperLink ID="HyperLink1" runat="server"
NavigateUrl="<%$RouteUrl:SearchTerm=scott%>">Search for Scott</asp:HyperLink>
Nell'esempio viene usata l'espressione RouteUrl per definire un URL basato su un parametro di route. In questo modo si evita di dover impostare come hardcoded l'URL completo nel markup e di modificare la struttura dell'URL in un secondo momento senza richiedere alcuna modifica a questo collegamento.
In base alla route definita in precedenza, questo markup genera l'URL seguente:
http://localhost/search/scott
ASP.NET funziona automaticamente la route corretta , ovvero genera l'URL corretto, in base ai parametri di input. È anche possibile includere un nome di route nell'espressione, che consente di specificare una route da usare.
Nell'esempio seguente viene illustrato come usare l'espressione RouteValue .
<asp:Label ID="Label1" runat="server" Text="<%$RouteValue:SearchTerm%>" />
Quando viene eseguita la pagina contenente questo controllo, il valore "scott" viene visualizzato nell'etichetta.
L'espressione RouteValue semplifica l'uso dei dati di route nel markup ed evita di dover usare la sintassi Page.RouteData["x"] più complessa nel markup.
Uso dei dati di route per i parametri del controllo origine dati
La classe RouteParameter consente di specificare i dati di route come valore di parametro per le query in un controllo origine dati. Funziona in modo molto simile alla classe , come illustrato nell'esempio seguente:
<asp:sqldatasource id="SqlDataSource1" runat="server"
connectionstring="<%$ ConnectionStrings:MyNorthwind %>"
selectcommand="SELECT CompanyName,ShipperID FROM Shippers where
CompanyName=@companyname"
<selectparameters>
<asp:routeparameter name="companyname" RouteKey="searchterm" />
</selectparameters>
</asp:sqldatasource>
In questo caso, il valore del parametro di route searchterm verrà usato per il @companyname parametro nell'istruzione Select .
Impostazione degli ID client
La nuova proprietà ClientIDMode risolve un problema di lunga durata in ASP.NET, ovvero il modo in cui i controlli creano l'attributo ID per gli elementi di cui eseguono il rendering. Conoscere l'attributo ID per gli elementi di cui è stato eseguito il rendering è importante se l'applicazione include uno script client che fa riferimento a questi elementi.
L'attributo ID in HTML di cui viene eseguito il rendering per i controlli server Web viene generato in base alla proprietà ClientID del controllo. Fino a ASP.NET 4, l'algoritmo per la generazione dell'attributo ID dalla proprietà ClientID è stato per concatenare il contenitore di denominazione (se presente) con l'ID e nel caso di controlli ripetuti (come nei controlli dati), per aggiungere un prefisso e un numero sequenziale. Sebbene ciò abbia sempre garantito che gli ID dei controlli nella pagina siano univoci, l'algoritmo ha generato ID di controllo che non erano prevedibili e pertanto erano difficili da fare riferimento nello script client.
La nuova proprietà ClientIDMode consente di specificare più precisamente la modalità di generazione dell'ID client per i controlli. È possibile impostare la proprietà ClientIDMode per qualsiasi controllo, incluso per la pagina. Le impostazioni possibili sono le seguenti:
- AutoID : equivale all'algoritmo per la generazione di valori di proprietà ClientID usati nelle versioni precedenti di ASP.NET.
- Statico : specifica che il valore ClientID sarà uguale all'ID senza concatenare gli ID dei contenitori di denominazione padre. Ciò può essere utile nei controlli utente Web. Poiché un controllo utente Web può trovarsi in pagine diverse e in controlli contenitore diversi, può essere difficile scrivere script client per i controlli che usano l'algoritmo AutoID perché non è possibile stimare i valori ID.
- Stimabile : questa opzione viene usata principalmente nei controlli dati che usano modelli ripetuti. Concatena le proprietà ID dei contenitori di denominazione del controllo, ma i valori ClientID generati non contengono stringhe come "ctlxxx". Questa impostazione funziona insieme alla proprietà ClientIDRowSuffix del controllo. Impostare la proprietà ClientIDRowSuffix sul nome di un campo dati e il valore di tale campo viene usato come suffisso per il valore ClientID generato. In genere si usa la chiave primaria di un record di dati come valore ClientIDRowSuffix .
- Eredita : questa impostazione è il comportamento predefinito per i controlli; specifica che la generazione dell'ID di un controllo è uguale a quella dell'elemento padre.
È possibile impostare la proprietà ClientIDMode a livello di pagina. In questo modo viene definito il valore predefinito ClientIDMode per tutti i controlli nella pagina corrente.
Il valore predefinito ClientIDMode a livello di pagina è AutoID e il valore predefinito ClientIDMode a livello di controllo è Inherit. Di conseguenza, se non si imposta questa proprietà in un punto qualsiasi del codice, per impostazione predefinita tutti i controlli verranno impostati sull'algoritmo AutoID .
Impostare il valore a livello di pagina nella direttiva @ Page , come illustrato nell'esempio seguente:
<%@ Page Language="C#" AutoEventWireup="true"
CodeFile="Default.aspx.cs"
Inherits="_Default"
ClientIDMode="Predictable" %>
È anche possibile impostare il valore ClientIDMode nel file di configurazione, a livello di computer (computer) o a livello di applicazione. In questo modo viene definita l'impostazione Predefinita ClientIDMode per tutti i controlli in tutte le pagine dell'applicazione. Se si imposta il valore a livello di computer, viene definita l'impostazione Predefinita ClientIDMode per tutti i siti Web in tale computer. L'esempio seguente mostra l'impostazione ClientIDMode nel file di configurazione:
<system.web>
<pages clientIDMode="Predictable"></pages>
</system.web>
Come indicato in precedenza, il valore della proprietà ClientID deriva dal contenitore di denominazione per l'elemento padre di un controllo. In alcuni scenari, ad esempio quando si usano pagine master, i controlli possono terminare con ID come quelli nel codice HTML sottoposto a rendering seguente:
<div id="ctl00_ContentPlaceHolder1_ParentPanel">
<div id="ctl00_ContentPlaceHolder1_ParentPanel_NamingPanel1">
<input name="ctl00$ContentPlaceHolder1$ParentPanel$NamingPanel1$TextBox1"
type="text" value="Hello!"
id="ctl00_ContentPlaceHolder1_ParentPanel_NamingPanel1_TextBox1" />
</div>
Anche se l'elemento di input visualizzato nel markup (da un controllo TextBox ) è solo due contenitori di denominazione profondi nella pagina (i controlli ContentPlaceholder annidati), a causa della modalità di elaborazione delle pagine master, il risultato finale è un ID di controllo simile al seguente:
ctl00_ContentPlaceHolder1_ParentPanel_NamingPanel1_TextBox1
Questo ID è sicuramente univoco nella pagina, ma è inutilmente lungo per la maggior parte degli scopi. Si supponga di voler ridurre la lunghezza dell'ID di cui è stato eseguito il rendering e di avere un maggiore controllo sulla modalità di generazione dell'ID. Ad esempio, si vogliono eliminare i prefissi "ctlxxx". Il modo più semplice per ottenere questo risultato consiste nell'impostare la proprietà ClientIDMode , come illustrato nell'esempio seguente:
<tc:NamingPanel runat="server" ID="ParentPanel" ClientIDMode="Static">
<tc:NamingPanel runat="server" ID="NamingPanel1" ClientIDMode="Predictable">
<asp:TextBox ID="TextBox1" runat="server" Text="Hello!"></asp:TextBox>
</tc:NamingPanel>
</tc:NamingPanel>
In questo esempio, la proprietà ClientIDMode è impostata su Static per l'elemento NamingPanel più esterno e impostata su Stima per l'elemento NamingControl interno. Queste impostazioni generano il markup seguente (si presuppone che la parte restante della pagina e la pagina master siano uguali a quelle dell'esempio precedente):
<div id="ParentPanel">
<div id="ParentPanel_NamingPanel1">
<input name="ctl00$ContentPlaceHolder1$ParentPanel$NamingPanel1$TextBox1"
type="text" value="Hello!" id="ParentPanel_NamingPanel1_TextBox1" />
</div>
L'impostazione Statica ha l'effetto di reimpostare la gerarchia di denominazione per tutti i controlli all'interno dell'elemento NamingPanel più esterno e di eliminare gli ID ContentPlaceHolder e MasterPage dall'ID generato. L'attributo name degli elementi di cui è stato eseguito il rendering non è interessato, pertanto la normale funzionalità di ASP.NET viene mantenuta per eventi, stato di visualizzazione e così via. Un effetto collaterale della reimpostazione della gerarchia di denominazione è che, anche se si sposta il markup per gli elementi NamingPanel in un controllo ContentPlaceholder diverso, gli ID client sottoposti a rendering rimangono invariati.
Nota
Nota È necessario assicurarsi che gli ID dei controlli di cui è stato eseguito il rendering siano univoci. In caso contrario, può interrompere tutte le funzionalità che richiedono ID univoci per singoli elementi HTML, ad esempio la funzione client document.getElementById .
Creazione di ID client prevedibili nei controlli Data-Bound
I valori ClientID generati per i controlli in un controllo elenco associato a dati dall'algoritmo legacy possono essere lunghi e non sono davvero prevedibili. La funzionalità ClientIDMode consente di avere maggiore controllo sulla modalità di generazione di questi ID.
Il markup nell'esempio seguente include un controllo ListView :
<asp:ListView ID="ListView1" runat="server" DataSourceID="SqlDataSource1"
OnSelectedIndexChanged="ListView1_SelectedIndexChanged"
ClientIDMode="Predictable"
RowClientIDRowSuffix="ProductID">
</asp:ListView>
Nell'esempio precedente le proprietà ClientIDMode e RowClientIDRowSuffix vengono impostate nel markup. La proprietà ClientIDRowSuffix può essere utilizzata solo nei controlli associati a dati e il comportamento varia a seconda del controllo in uso. Le differenze sono le seguenti:
Controllo GridView: è possibile specificare il nome di una o più colonne nell'origine dati, combinate in fase di esecuzione per creare gli ID client. Ad esempio, se si imposta RowClientIDRowSuffix su "ProductName, ProductId", gli ID di controllo per gli elementi sottoposti a rendering avranno un formato simile al seguente:
rootPanel_GridView1_ProductNameLabel_Chai_1Controllo ListView : è possibile specificare una singola colonna nell'origine dati aggiunta all'ID client. Ad esempio, se si imposta ClientIDRowSuffix su "ProductName", gli ID dei controlli sottoposti a rendering avranno un formato simile al seguente:
rootPanel_ListView1_ProductNameLabel_1In questo caso, l'elemento finale 1 deriva dall'ID prodotto dell'elemento dati corrente.
Controllo Repeater : questo controllo non supporta la proprietà ClientIDRowSuffix . In un controllo Repeater viene utilizzato l'indice della riga corrente. Quando si usa ClientIDMode="Stimabile" con un controllo Repeater , gli ID client vengono generati con il formato seguente:
Repeater1_ProductNameLabel_0Il valore 0 finale è l'indice della riga corrente.
I controlli FormView e DetailsView non visualizzano più righe, pertanto non supportano la proprietà ClientIDRowSuffix .
Salvataggio permanente della selezione di righe nei controlli dati
I controlli GridView e ListView possono consentire agli utenti di selezionare una riga. Nelle versioni precedenti di ASP.NET, la selezione è basata sull'indice di riga nella pagina. Ad esempio, se si seleziona il terzo elemento nella pagina 1 e quindi si passa alla pagina 2, viene selezionato il terzo elemento nella pagina.
La selezione persistente è stata inizialmente supportata solo nei progetti Dynamic Data in .NET Framework 3.5 SP1. Quando questa funzionalità è abilitata, l'elemento selezionato corrente si basa sulla chiave dati per l'elemento. Ciò significa che se si seleziona la terza riga nella pagina 1 e si passa alla pagina 2, non viene selezionato nulla nella pagina 2. Quando si torna alla pagina 1, la terza riga è ancora selezionata. La selezione persistente è ora supportata per i controlli GridView e ListView in tutti i progetti usando la proprietà EnablePersistedSelection , come illustrato nell'esempio seguente:
<asp:GridView id="GridView2" runat="server" EnablePersistedSelection="true">
</asp:GridView>
controllo grafico ASP.NET
Il controllo grafico ASP.NET espande le offerte di visualizzazione dei dati in .NET Framework. Usando il controllo Grafico , è possibile creare pagine ASP.NET con grafici intuitivi e visivamente accattivanti per analisi statistiche o finanziarie complesse. Il controllo grafico ASP.NET è stato introdotto come componente aggiuntivo alla versione 3.5 SP1 di .NET Framework e fa parte della versione .NET Framework 4.
Il controllo include le funzionalità seguenti:
- 35 tipi diversi di grafici.
- Numero illimitato di aree del grafico, titoli, legende e annotazioni.
- Un'ampia gamma di impostazioni di aspetto per tutti gli elementi del grafico.
- Supporto 3D per la maggior parte dei tipi di grafico.
- Etichette dati intelligenti che possono adattarsi automaticamente ai punti dati.
- Linee di striscia, interruzioni di scalabilità e ridimensionamento logaritmico.
- Oltre 50 formule statistiche e finanziarie per analisi e trasformazione dei dati.
- Associazione semplice e manipolazione dei dati del grafico.
- Supporto per formati di dati comuni, ad esempio date, ore e valuta.
- Supporto per l'interattività e la personalizzazione basata su eventi, inclusi gli eventi di clic client tramite Ajax.
- Gestione dello stato.
- Flusso binario.
Le figure seguenti mostrano esempi di grafici finanziari prodotti dal controllo grafico ASP.NET.
Figura 2: esempi di controllo grafico ASP.NET
Per altri esempi di come usare il controllo grafico ASP.NET, scaricare il codice di esempio nella pagina Samples Environment for Microsoft Chart Controls nel sito Web MSDN. È possibile trovare altri esempi di contenuto della community nel Forum di controllo grafico.
Aggiunta del controllo grafico a una pagina ASP.NET
Nell'esempio seguente viene illustrato come aggiungere un controllo Grafico a una pagina ASP.NET usando il markup. Nell'esempio, il controllo Grafico produce un grafico a colonne per i punti dati statici.
<asp:Chart ID="Chart1" runat="server">
<Series>
<asp:Series Name="Series1" ChartType="Column">
<Points>
<asp:DataPoint AxisLabel="Product A" YValues="345"/>
<asp:DataPoint AxisLabel="Product B" YValues="456"/>
<asp:DataPoint AxisLabel="Product C" YValues="125"/>
<asp:DataPoint AxisLabel="Product D" YValues="957"/> &
lt;/Points>
</asp:Series>
</Series>
<ChartAreas>
<asp:ChartArea Name="ChartArea1">
<AxisY IsLogarithmic="True" />
</asp:ChartArea>
</ChartAreas>
<Legends>
<asp:Legend Name="Legend1" Title="Product Sales" />
</Legends>
</asp:Chart>
Uso di grafici 3D
Il controllo Chart contiene un insieme ChartAreas, che può contenere oggetti ChartArea che definiscono le caratteristiche delle aree del grafico. Ad esempio, per usare 3D per un'area grafico, usare la proprietà Area3DStyle come nell'esempio seguente:
<asp:ChartArea Name="ChartArea1">
<area3dstyle
Rotation="10"
Perspective="10"
Enable3D="True"
Inclination="15"
IsRightAngleAxes="False"
WallWidth="0"
IsClustered="False" />
<%-- Additional markup here --%>
</asp:ChartArea>
La figura seguente mostra un grafico 3D con quattro serie del tipo di grafico a barre .
Figura 3: Grafico a barre 3D
Uso di interruzioni di scalabilità e scalabilità logaritmica
Le interruzioni di scala e le scale logaritmiche sono due modi aggiuntivi per aggiungere sofisticatezza al grafico. Queste funzionalità sono specifiche di ogni asse in un'area del grafico. Ad esempio, per usare queste funzionalità sull'asse Y primario di un'area del grafico, usare le proprietà AxisY.IsLogarithmic e ScaleBreakStyle in un oggetto ChartArea . Il frammento di codice seguente illustra come usare le interruzioni di scalabilità sull'asse Y primario.
<asp:ChartArea Name="ChartArea1">
<axisy>
<ScaleBreakStyle
BreakLineStyle="Wave"
CollapsibleSpaceThreshold="40"
Enabled="True" />
</axisy>
<%-- Additional markup here --%>
</asp:ChartArea>
La figura seguente mostra l'asse Y con interruzioni di scala abilitate.
Figura 4: Interruzioni di scalabilità
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 creando clausole Where nei controlli origine dati. Questo approccio può essere complicato e in alcuni casi la sintassi Where non consente di sfruttare la funzionalità completa del database sottostante.
Per semplificare il filtro, è stato aggiunto un nuovo controllo QueryExtender in ASP.NET 4. Questo controllo può essere aggiunto ai controlli EntityDataSource o LinqDataSource per filtrare i dati restituiti da questi controlli. Poiché il controllo QueryExtender si basa su LINQ, il filtro viene applicato al server di database prima dell'invio dei dati alla pagina, che comporta operazioni molto efficienti.
Il controllo QueryExtender supporta diverse opzioni di filtro. Le sezioni seguenti descrivono queste opzioni e forniscono esempi di come usarli.
Cerca
Per l'opzione di ricerca, il controllo QueryExtender esegue una ricerca nei campi specificati. Nell'esempio seguente il controllo usa il testo immesso nel controllo TextBoxSearch e cerca il relativo contenuto nelle ProductName colonne e Supplier.CompanyName nei dati restituiti dal controllo LinqDataSource .
<asp:LinqDataSource ID="dataSource" runat="server"> TableName="Products">
</asp:LinqDataSource>
<asp:QueryExtender TargetControlID="dataSource" runat="server">
<asp:SearchExpression DataFields="ProductName, Supplier.CompanyName"
SearchType="StartsWith">
<asp:ControlParameter ControlID="TextBoxSearch" />
</asp:SearchExpression>
</asp:QueryExtender>
Intervallo
L'opzione intervallo è simile all'opzione di ricerca, ma specifica una coppia di valori per definire l'intervallo. Nell'esempio seguente il controllo QueryExtender cerca la UnitPrice colonna nei dati restituiti dal controllo LinqDataSource . L'intervallo viene letto dai controlli TextBoxFrom e TextBoxTo nella pagina.
<asp:LinqDataSource ID="dataSource" runat="server"> TableName="Products">
</asp:LinqDataSource>
<asp:QueryExtender TargetControlID="dataSource" runat="server">
<asp:RangeExpression DataField="UnitPrice" MinType="Inclusive"
MaxType="Inclusive">
<asp:ControlParameter ControlID="TextBoxFrom" />
<asp:ControlParameter ControlID="TexBoxTo" />
</asp:RangeExpression>
</asp:QueryExtender>
Propertyexpression
L'opzione espressione di proprietà consente di definire un confronto con un valore della proprietà. Se l'espressione restituisce true, vengono restituiti i dati esaminati. Nell'esempio seguente il controllo QueryExtender filtra i dati confrontando i dati nella Discontinued colonna al valore del controllo CheckBoxDiscontinued nella pagina.
<asp:LinqDataSource ID="dataSource" runat="server" TableName="Products">
</asp:LinqDataSource>
<asp:QueryExtender TargetControlID="dataSource" runat="server">
<asp:PropertyExpression>
<asp:ControlParameter ControlID="CheckBoxDiscontinued" Name="Discontinued" />
</asp:PropertyExpression>
</asp:QueryExtender>
CustomExpression
Infine, è possibile specificare un'espressione personalizzata da usare con il controllo QueryExtender . Questa opzione consente di chiamare una funzione nella pagina che definisce la logica di filtro personalizzata. Nell'esempio seguente viene illustrato come specificare in modo dichiarativo un'espressione personalizzata nel controllo QueryExtender .
<asp:LinqDataSource ID="dataSource" runat="server" TableName="Products">
</asp:LinqDataSource>
<asp:QueryExtender TargetControlID="dataSource" runat="server">
<asp:CustomExpression OnQuerying="FilterProducts" />
</asp:QueryExtender>
Nell'esempio seguente viene illustrata la funzione personalizzata richiamata dal controllo QueryExtender . In questo caso, anziché usare una query di database che include una clausola Where , il codice usa una query LINQ per filtrare i dati.
protected void FilterProducts(object sender, CustomExpressionEventArgs e)
{
e.Query = from p in e.Query.Cast()
where p.UnitPrice >= 10
select p;
}
Questi esempi mostrano solo un'espressione usata nel controllo QueryExtender alla volta. È tuttavia possibile includere più espressioni all'interno del controllo QueryExtender .
Espressioni di codice codificate html
Alcuni siti ASP.NET (soprattutto con ASP.NET MVC) si basano pesantemente sull'uso <%= expression %> della sintassi (spesso denominata "nuggets di codice") per scrivere un testo alla risposta. Quando si usano espressioni di codice, è facile dimenticare di codificare il testo, se il testo proviene dall'input utente, può lasciare le pagine aperte a un attacco XSS (Cross Site Scripting).
ASP.NET 4 introduce la nuova sintassi seguente per le espressioni di codice:
<%: expression %>
Questa sintassi usa la codifica HTML per impostazione predefinita durante la scrittura nella risposta. Questa nuova espressione si traduce in modo efficace in quanto segue:
<%= HttpUtility.HtmlEncode(expression) %>
Ad esempio, <%: Request["UserInput"] %> esegue la codifica HTML sul valore request["UserInput"].
L'obiettivo di questa funzionalità consiste nel rendere possibile sostituire tutte le istanze della sintassi precedente con la nuova sintassi in modo da non essere costretti a decidere in ogni passaggio da usare. Tuttavia, esistono casi in cui l'output del testo è destinato a essere HTML o è già codificato, nel qual caso questo potrebbe causare la doppia codifica.
Per questi casi, ASP.NET 4 introduce una nuova interfaccia, IHtmlString, insieme a un'implementazione concreta, HtmlString. Le istanze di questi tipi consentono di indicare che il valore restituito è già codificato correttamente (o altrimenti esaminato) per la visualizzazione come HTML e che pertanto il valore non deve essere codificato di nuovo in HTML. Ad esempio, il codice HTML seguente non deve essere (e non è) codificato html:
<%: new HtmlString("<strong>HTML that is not encoded</strong>") %>
ASP.NET metodi helper MVC 2 sono stati aggiornati per usare questa nuova sintassi in modo che non siano con codifica doppia, ma solo quando si esegue ASP.NET 4. Questa nuova sintassi non funziona quando si esegue un'applicazione usando ASP.NET 3.5 SP1.
Tenere presente che questo non garantisce la protezione dagli attacchi XSS. Ad esempio, HTML che usa valori di attributo che non sono presenti tra virgolette può contenere input utente che è ancora soggetto. Si noti che l'output dei controlli ASP.NET e ASP.NET helper MVC include sempre i valori degli attributi nelle virgolette, ovvero l'approccio consigliato.
Analogamente, questa sintassi non esegue la codifica JavaScript, ad esempio quando si crea una stringa JavaScript in base all'input utente.
Modifiche al modello di progetto
Nelle versioni precedenti di ASP.NET, quando si usa Visual Studio per creare un nuovo progetto sito Web o un progetto applicazione Web, i progetti risultanti contengono solo una pagina Default.aspx, un file predefinito Web.config e la App_Data cartella, come illustrato nella figura seguente:
Visual Studio supporta anche un tipo di progetto Sito Web vuoto, che non contiene alcun file, come illustrato nella figura seguente:
Il risultato è che per il principiante, c'è molto poco materiale sussidiario su come creare un'applicazione Web di produzione. Pertanto, ASP.NET 4 introduce tre nuovi modelli, uno per un progetto di applicazione Web vuoto e uno per un progetto applicazione Web e sito Web.
Modello di applicazione Web vuoto
Come suggerisce il nome, il modello Di applicazione Web vuota è un progetto applicazione Web rimosso. Selezionare questo modello di progetto dalla finestra di dialogo Nuovo progetto di Visual Studio, come illustrato nella figura seguente:
(Fare clic per visualizzare l'immagine full-size)
Quando si crea un'applicazione Web ASP.NET vuota, Visual Studio crea il layout di cartella seguente:
Questo comportamento è simile al layout vuoto del sito Web delle versioni precedenti di ASP.NET, con un'eccezione. In Visual Studio 2010, i progetti Applicazione Web vuota e Sito Web vuoto contengono il file minimo Web.config seguente che contiene informazioni usate da Visual Studio per identificare il framework di destinazione del progetto:
Senza questa proprietà targetFramework , Per impostazione predefinita, Visual Studio ha come destinazione .NET Framework 2.0 per mantenere la compatibilità all'apertura di applicazioni precedenti.
Modelli di progetto dell'applicazione Web e del sito Web
Gli altri due nuovi modelli di progetto forniti con Visual Studio 2010 contengono modifiche importanti. Nella figura seguente viene illustrato il layout del progetto creato quando si crea un nuovo progetto applicazione Web. Il layout per un progetto sito Web è praticamente identico.
Il progetto include diversi file che non sono stati creati nelle versioni precedenti. Inoltre, il nuovo progetto applicazione Web è configurato con la funzionalità di appartenenza di base, che consente di iniziare rapidamente a proteggere l'accesso alla nuova applicazione. A causa di questa inclusione, il Web.config file per il nuovo progetto include voci usate per configurare l'appartenenza, i ruoli e i profili. Nell'esempio seguente viene illustrato il Web.config file per un nuovo progetto applicazione Web. In questo caso roleManager è disabilitato.
(Fare clic per visualizzare l'immagine a dimensione intera)
Il progetto contiene anche un secondo Web.config file nella Account directory . Il secondo file di configurazione consente di proteggere l'accesso alla pagina ChangePassword.aspx per gli utenti non connessi. Nell'esempio seguente viene illustrato il contenuto del secondo Web.config file.
Le pagine create per impostazione predefinita nei nuovi modelli di progetto contengono anche più contenuto rispetto alle versioni precedenti. Il progetto contiene una pagina master predefinita e un file CSS e la pagina predefinita (Default.aspx) è configurata per l'uso della pagina master per impostazione predefinita. Il risultato è che quando si esegue l'applicazione Web o il sito Web per la prima volta, la home page predefinita è già funzionante. Infatti, è simile alla pagina predefinita visualizzata all'avvio di una nuova applicazione MVC.
(Fare clic per visualizzare l'immagine a dimensione intera)
L'intenzione di queste modifiche ai modelli di progetto è fornire indicazioni su come iniziare a creare una nuova applicazione Web. Con la semanticamente corretta, il markup XHTML 1.0 conforme e con il layout specificato usando CSS, le pagine nei modelli rappresentano le procedure consigliate per la compilazione di applicazioni Web ASP.NET 4. Le pagine predefinite hanno anche un layout a due colonne che è possibile personalizzare facilmente.
Si supponga, ad esempio, che per una nuova applicazione Web si voglia modificare alcuni colori e inserire il logo aziendale al posto del logo My ASP.NET Application. A tale scopo, creare una nuova directory in Content per archiviare l'immagine del logo:
Per aggiungere l'immagine alla pagina, aprire il Site.Master file, individuare dove è definito il testo My ASP.NET Application e sostituirlo con un elemento image il cui attributo src è impostato sulla nuova immagine del logo, come nell'esempio seguente:
(Fare clic per visualizzare l'immagine a dimensione intera)
È quindi possibile accedere al file Site.css e modificare le definizioni di classe CSS per modificare il colore di sfondo della pagina e quello dell'intestazione.
Il risultato di queste modifiche è che è possibile visualizzare una home page personalizzata con pochissimo sforzo:
(Fare clic per visualizzare l'immagine a dimensione intera)
Miglioramenti di CSS
Una delle principali aree di lavoro in ASP.NET 4 è stata quella di rendere il codice HTML conforme agli standard HTML più recenti. Sono incluse le modifiche al modo in cui ASP.NET i controlli server Web usano gli stili CSS.
Impostazione di compatibilità per il rendering
Per impostazione predefinita, quando un'applicazione Web o un sito Web è destinato a .NET Framework 4, l'attributo controlRenderingCompatibilityVersion dell'elemento pages è impostato su "4.0". Questo elemento è definito nel file a livello Web.config di computer e per impostazione predefinita si applica a tutte le ASP.NET 4 applicazioni:
<system.web>
<pages controlRenderingCompatibilityVersion="3.5|4.0"/>
</system.web>
Il valore per controlRenderingCompatibility è una stringa che consente potenziali definizioni di versione nelle versioni future. Nella versione corrente sono supportati i valori seguenti per questa proprietà:
- "3.5". Questa impostazione indica il rendering e il markup legacy. Il markup sottoposto a rendering dai controlli è compatibile con le versioni precedenti del 100% e l'impostazione della proprietà xhtmlConformance viene rispettata.
- "4.0". Se la proprietà ha questa impostazione, ASP.NET i controlli server Web eseguono le operazioni seguenti:
- La proprietà xhtmlConformance viene sempre considerata come "Strict". Di conseguenza, i controlli eseguono il rendering del markup Strict XHTML 1.0.
- La disabilitazione dei controlli non di input non esegue più il rendering di stili non validi.
- Gli elementi div intorno ai campi nascosti sono ora in stile in modo che non interferiscano con le regole CSS create dall'utente.
- I controlli menu eseguono il rendering del markup semanticamente corretto e conforme alle linee guida per l'accessibilità.
- I controlli di convalida non eseguono il rendering degli stili inline.
- I controlli di cui è stato eseguito il rendering in precedenza border="0" (controlli che derivano dal controllo tabella ASP.NET e il controllo immagine di ASP.NET) non eseguono più il rendering di questo attributo.
Disabilitazione dei controlli
In ASP.NET 3.5 SP1 e versioni precedenti, il framework esegue il rendering dell'attributo disabilitato nel markup HTML per qualsiasi controllo la cui proprietà Enabled è impostata su false. Tuttavia, in base alla specifica HTML 4.01, solo gli elementi di input devono avere questo attributo.
In ASP.NET 4 è possibile impostare la proprietà controlRenderingCompatibilityVersion su "3.5", come nell'esempio seguente:
<system.web>
<pages controlRenderingCompatibilityVersion="3.5"/>
</system.web>
È possibile creare markup per un controllo Label simile al seguente, che disabilita il controllo :
<asp:Label id="Label" runat="server" Text="Test" Enabled="false">
Il controllo Label esegue il rendering del codice HTML seguente:
<span id="Label1" disabled="disabled">Test</span>
In ASP.NET 4 è possibile impostare controlRenderingCompatibilityVersion su "4.0". In tal caso, solo i controlli che eseguono il rendering degli elementi di input eseguiranno il rendering di un attributo disabilitato quando la proprietà Enabled del controllo è impostata su false. I controlli che non eseguono il rendering degli elementi di input HTML eseguono invece il rendering di un attributo di classe che fa riferimento a una classe CSS che è possibile usare per definire una ricerca disabilitata per il controllo. Ad esempio, il controllo Label illustrato nell'esempio precedente genera il markup seguente:
<span id="Span1" class="aspnetdisabled">Test</span>
Il valore predefinito per la classe specificata per questo controllo è "aspNetDisabled". È tuttavia possibile modificare questo valore predefinito impostando la proprietà statica Static DisabledCssClass della classe WebControl . Per gli sviluppatori di controlli, è anche possibile definire il comportamento da usare per un controllo specifico usando la proprietà SupportsDisabledAttribute .
Nascondere gli elementi div intorno ai campi nascosti
ASP.NET 2.0 e versioni successive eseguono il rendering di campi nascosti specifici del sistema (ad esempio l'elemento nascosto usato per archiviare le informazioni sullo stato di visualizzazione) all'interno dell'elemento div per garantire la conformità allo standard XHTML. Tuttavia, questo può causare un problema quando una regola CSS influisce sugli elementi div in una pagina. Ad esempio, può comportare la visualizzazione di una linea di un pixel nella pagina intorno agli elementi div nascosti. In ASP.NET 4, gli elementi div che racchiudono i campi nascosti generati da ASP.NET aggiungere un riferimento a una classe CSS come nell'esempio seguente:
<div class="aspNetHidden">...</div>
È quindi possibile definire una classe CSS che si applica solo agli elementi nascosti generati da ASP.NET, come nell'esempio seguente:
<style type="text/css">
DIV# aspNetHidden {border:0;}
</style>
Rendering di una tabella esterna per i controlli basati su modelli
Per impostazione predefinita, i controlli server Web seguenti ASP.NET che supportano i modelli vengono inseriti automaticamente in una tabella esterna utilizzata per applicare stili inline:
- Formview
- Accesso
- Passwordrecovery
- ChangePassword
- Procedura guidata
- Createuserwizard
A questi controlli è stata aggiunta una nuova proprietà denominata RenderOuterTable che consente di rimuovere la tabella esterna dal markup. Si consideri ad esempio l'esempio seguente di un controllo FormView :
<asp:FormView ID="FormView1" runat="server">
<ItemTemplate>
Content
</ItemTemplate>
</asp:FormView>
Questo markup esegue il rendering dell'output seguente nella pagina, che include una tabella HTML:
<table cellspacing="0" border="0" id="Table1" style="border-collapse:collapse;">
<tr>
<td colspan="2">
Content
</td>
</tr>
</table>
Per impedire il rendering della tabella, è possibile impostare la proprietà RenderOuterTable del controllo FormView, come nell'esempio seguente:
<asp:FormView ID="FormView1" runat="server" RenderOuterTable="false">
Nell'esempio precedente viene eseguito il rendering dell'output seguente, senza gli elementi table, tr e td :
Content
Questo miglioramento può semplificare lo stile del contenuto del controllo con CSS, perché il controllo non esegue il rendering di tag imprevisti.
Nota
Nota Questa modifica disabilita il supporto per la funzione di formato automatico nella finestra di progettazione di Visual Studio 2010, perché non esiste più un elemento della tabella in grado di ospitare attributi di stile generati dall'opzione di formato automatico.
Miglioramenti al controllo ListView
Il controllo ListView è stato reso più semplice da usare in ASP.NET 4. La versione precedente del controllo richiedeva di specificare un modello di layout contenente un controllo server con un ID noto. Il markup seguente illustra un esempio tipico di come usare 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 illustrato nell'esempio precedente può essere sostituito con il markup seguente:
<asp:ListView ID="ListView1" runat="server">
<ItemTemplate>
<% Eval("LastName")%>
</ItemTemplate>
</asp:ListView>
Miglioramenti del controllo CheckBoxList e RadioButtonList
In ASP.NET 3.5 è possibile specificare il layout per CheckBoxList e RadioButtonList usando le due impostazioni seguenti:
- Flusso. Il controllo esegue il rendering degli elementi per contenere il contenuto.
- Tabella. Il controllo esegue il rendering di un elemento di tabella per contenere il relativo contenuto.
Nell'esempio seguente viene illustrato il markup per ognuno di questi controlli.
<asp:CheckBoxList ID="CheckBoxList1" runat="server" RepeatLayout="Flow">
<asp:ListItem Text="CheckBoxList" Value="cbl" />
</asp:CheckBoxList>
<asp:RadioButtonList runat="server" RepeatLayout="Table">
<asp:ListItem Text="RadioButtonList" Value="rbl" />
</asp:RadioButtonList>
Per impostazione predefinita, i controlli eseguono il rendering html simile al seguente:
<span id="Span2"><input id="CheckBoxList1_0" type="checkbox"
name="CheckBoxList1$0" /><label for="CheckBoxList1_0">CheckBoxList</label></span>
<table id="RadioButtonList1" border="0">
<tr>
<td><input id="RadioButtonList1_0" type="radio" name="RadioButtonList1" value="rbl" /><label for="RadioButtonList1_0">RadioButtonList</label></td>
</tr>
</table>
Poiché questi controlli contengono elenchi di elementi, per eseguire il rendering semanticamente corretto di HTML, devono eseguire il rendering del contenuto usando gli elementi dell'elenco HTML (li). In questo modo è più facile per gli utenti che leggeno pagine Web usando la tecnologia assistive e semplificano lo stile dei controlli usando CSS.
In ASP.NET 4 i controlli CheckBoxList e RadioButtonList supportano i nuovi valori seguenti per la proprietà RepeatLayout :
- OrderedList : il contenuto viene eseguito come elementi li all'interno di un elemento ol .
- UnorderedList : il contenuto viene eseguito come elementi li all'interno di un elemento ul .
Nell'esempio seguente viene illustrato come usare questi nuovi valori.
<asp:CheckBoxList ID="CheckBoxList1" runat="server"
RepeatLayout="OrderedList">
<asp:ListItem Text="CheckBoxList" Value="cbl" />
</asp:CheckBoxList>
<asp:RadioButtonList ID="RadioButtonList1" runat="server"
RepeatLayout="UnorderedList">
<asp:ListItem Text="RadioButtonList" Value="rbl" />
</asp:RadioButtonList>
Il markup precedente genera il codice HTML seguente:
<ol id="CheckBoxList1">
<li><input id="CheckBoxList1_0" type="checkbox" name="CheckBoxList1$0" value="cbl" /><label for="CheckBoxList1_0">CheckBoxList</label></li>
</ol>
<ul id="RadioButtonList1">
<li><input id="RadioButtonList1_0" type="radio" name="RadioButtonList1" value="rbl" /><label for="RadioButtonList1_0">RadioButtonList</label></li>
</ul>
Nota
Nota Se si imposta RepeatLayout su OrderList o UnorderedList, la proprietà RepeatDirection non può più essere usata e genererà un'eccezione in fase di esecuzione se la proprietà è stata impostata all'interno del markup o del codice. La proprietà non ha alcun valore perché il layout visivo di questi controlli viene definito usando invece CSS.
Miglioramenti del controllo menu
Prima di ASP.NET 4, il controllo Menu ha eseguito il rendering di una serie di tabelle HTML. Ciò ha reso più difficile applicare stili CSS all'esterno dell'impostazione delle proprietà inline e non è stato conforme agli standard di accessibilità.
In ASP.NET 4 il controllo esegue ora il rendering di HTML usando il markup semantico costituito da un elenco e elementi elenco non ordinati. Nell'esempio seguente viene illustrato il markup in una pagina ASP.NET per il controllo Menu .
<asp:Menu ID="Menu1" runat="server">
<Items> <asp:MenuItem Text="Home" Value="Home" />
<asp:MenuItem Text="About" Value="About" />
</Items>
</asp:Menu>
Quando viene eseguito il rendering della pagina, il controllo produce il codice HTML seguente (il codice onclick è stato omesso per chiarezza):
<div id="Menu1">
<ul>
<li><a href="#" onclick="...">Home</a></li>
<li><a href="#" onclick="...">About</a></li>
</ul>
</div>
<script type="text/javascript">
new Sys.WebForms.Menu('Menu1');
</script>
Oltre ai miglioramenti del rendering, lo spostamento della tastiera del menu è stato migliorato usando la gestione dello stato attivo. Quando il controllo Menu ottiene lo stato attivo, è possibile usare i tasti di direzione per spostarsi negli elementi. Il controllo Menu collega ora anche ruoli e attributi a Internet avanzati (ARIA) accessibili e attributi folloalaper migliorare l'accessibilità.
Gli stili per il controllo menu vengono visualizzati in un blocco di stile nella parte superiore della pagina, anziché in linea con gli elementi HTML di cui è stato eseguito il rendering. Se si vuole assumere il controllo completo sullo stile per il controllo, è possibile impostare la nuova proprietà IncludeStyleBlock su false, nel qual caso il blocco di stile non viene generato. Un modo per usare questa proprietà consiste nell'usare la funzionalità di formato automatico nella finestra di progettazione di Visual Studio per impostare l'aspetto del menu. È quindi possibile eseguire la pagina, aprire l'origine pagina e quindi copiare il blocco di stile di rendering in un file CSS esterno. In Visual Studio annullare lo stile e impostare IncludeStyleBlock su false. Il risultato è che l'aspetto del menu è definito usando gli stili in un foglio di stile esterno.
Procedura guidata e controlli CreateUserWizard
I controlli ASP.NET Creazione guidata e CreateUserWizard supportano i modelli che consentono di definire il codice HTML eseguito il rendering. (CreateUserWizard deriva dalla procedura guidata). Nell'esempio seguente viene illustrato il markup per un controllo CreateUserWizard completamente modello:
<asp:CreateUserWizard ID="CreateUserWizard1" runat="server" ActiveStepIndex="0">
<HeaderTemplate>
</HeaderTemplate>
<SideBarTemplate>
</SideBarTemplate>
<StepNavigationTemplate>
</StepNavigationTemplate>
<StartNavigationTemplate>
</StartNavigationTemplate>
<FinishNavigationTemplate>
</FinishNavigationTemplate>
<WizardSteps>
<asp:CreateUserWizardStep ID="CreateUserWizardStep1" runat="server">
<ContentTemplate>
</ContentTemplate>
<CustomNavigationTemplate>
</CustomNavigationTemplate>
</asp:CreateUserWizardStep>
<asp:CompleteWizardStep ID="CompleteWizardStep1" runat="server">
<ContentTemplate>
</ContentTemplate>
</asp:CompleteWizardStep>
</WizardSteps>
</asp:CreateUserWizard>
Il controllo esegue il rendering di HTML simile al seguente:
<table cellspacing="0" cellpadding="0" border="0" id="CreateUserWizard1" style="border-collapse:collapse;">
<tr>
<td>Header</td>
</tr>
<tr style="height:100%;">
<td>
<table cellspacing="0" cellpadding="0" border="0" style="height:100%;width:100%;border-collapse:collapse;">
<tr>
<td style="height:100%;width:100%;"></td>
</tr>
</table>
</td>
</tr>
<tr>
<td align="right"></td>
</tr>
</table>
In ASP.NET 3.5 SP1, anche se è possibile modificare il contenuto del modello, è ancora disponibile un controllo limitato sull'output del controllo Procedura guidata . In ASP.NET 4 è possibile creare un modello LayoutTemplate e inserire i controlli Segnaposto (usando nomi riservati) per specificare come eseguire il rendering del controllo Procedura guidata . Nell'esempio seguente viene illustrato quanto segue:
<asp:CreateUserWizard ID="CreateUserWizard1" runat="server" ActiveStepIndex="1">
<LayoutTemplate>
<asp:PlaceHolder ID="headerPlaceholder" runat="server" />
<asp:PlaceHolder ID="sideBarPlaceholder" runat="server" />
<asp:PlaceHolder id="wizardStepPlaceholder" runat="server" />
<asp:PlaceHolder id="navigationPlaceholder" runat="server" />
</LayoutTemplate>
<HeaderTemplate>
Header
</HeaderTemplate>
<WizardSteps>
<asp:CreateUserWizardStep runat="server">
<ContentTemplate>
</ContentTemplate>
</asp:CreateUserWizardStep>
<asp:CompleteWizardStep runat="server">
<ContentTemplate>
</ContentTemplate>
</asp:CreateUserWizardStep>
</WizardSteps>
</asp:CreateUserWizard>
L'esempio contiene i segnaposto denominati seguenti nell'elemento LayoutTemplate :
- headerPlaceholder : in fase di esecuzione, questa operazione viene sostituita dal contenuto dell'elemento HeaderTemplate .
- sideBarPlaceholder : in fase di esecuzione, questa operazione viene sostituita dal contenuto dell'elemento SideBarTemplate .
- wizardStepPlaceHolder : in fase di esecuzione, questa operazione viene sostituita dal contenuto dell'elemento WizardStepTemplate .
- navigationPlaceholder : in fase di esecuzione, questa operazione viene sostituita da tutti i modelli di spostamento definiti.
Il markup nell'esempio che usa segnaposto esegue il rendering del codice HTML seguente (senza il contenuto effettivamente definito nei modelli):
<span>
</span>
L'unico codice HTML che non è ora definito dall'utente è un elemento span . Si prevede che nelle versioni future, anche l'elemento span non verrà eseguito il rendering. Questo consente ora di controllare completamente tutto il contenuto generato dal controllo Procedura guidata .
ASP.NET MVC
ASP.NET MVC è stato introdotto come framework aggiuntivo per ASP.NET 3.5 SP1 nel marzo 2009. Visual Studio 2010 include ASP.NET MVC 2, che include nuove funzionalità e funzionalità.
Aree di supporto
Le aree consentono di raggruppare controller e visualizzazioni in sezioni di un'applicazione di grandi dimensioni in isolamento relativo da altre sezioni. Ogni area può essere implementata come progetto MVC separato ASP.NET che può quindi essere fatto riferimento all'applicazione principale. Ciò consente di gestire la complessità quando si compila un'applicazione di grandi dimensioni e semplifica il lavoro di più team in una singola applicazione.
Supporto della convalida degli attributi Data-Annotation
Gli attributi dataAnnotations consentono di collegare la logica di convalida a un modello usando gli attributi dei metadati. Gli attributi dataAnnotations sono stati introdotti in ASP.NET Dati dinamici in ASP.NET 3.5 SP1. Questi attributi sono stati integrati nel binding del modello predefinito e forniscono un mezzo basato sui metadati per convalidare l'input utente.
Helper modelli
I helper modelli consentono di associare automaticamente i modelli di modifica e visualizzazione ai tipi di dati. Ad esempio, è possibile usare un helper modello per specificare che un elemento dell'interfaccia utente di selezione date viene eseguito automaticamente per un valore System.DateTime . Si tratta di modelli di campo simili a ASP.NET dati dinamici.
I metodi helper Html.EditorFor e Html.DisplayFor dispongono del supporto predefinito per il rendering di tipi di dati standard e oggetti complessi con più proprietà. Personalizzano anche il rendering consentendo di applicare attributi di annotazione dati come DisplayName e ScaffoldColumn all'oggetto ViewModel .
Spesso si vuole personalizzare l'output dagli helper dell'interfaccia utente ancora più avanti e avere il controllo completo su ciò che viene generato. I metodi html.EditorFor e Html.DisplayFor supportano questa operazione usando un meccanismo di creazione modelli che consente di definire modelli esterni che possono eseguire l'override e controllare il rendering dell'output. I modelli possono essere sottoposti a rendering singolarmente per una classe.
Dynamic Data
I dati dinamici sono stati introdotti nella versione di .NET Framework 3.5 SP1 a metà del 2008. Questa funzionalità offre molti miglioramenti per la creazione di applicazioni basate sui dati, tra cui quanto segue:
- Esperienza RAD per creare rapidamente un sito Web basato sui dati.
- Convalida automatica basata sui vincoli definiti nel modello di dati.
- La possibilità di modificare facilmente il markup generato per i campi nei controlli GridView e DetailsView usando i modelli di campo che fanno parte del progetto Dynamic Data.
Nota
Nota Per altre informazioni, vedere la documentazione di Dynamic Data in MSDN Library.
Per ASP.NET 4, i dati dinamici sono stati migliorati per offrire agli sviluppatori una maggiore potenza per creare rapidamente siti Web basati sui dati.
Abilitazione dei dati dinamici per i progetti esistenti
Funzionalità di dati dinamiche fornite in .NET Framework 3.5 SP1 hanno portato nuove funzionalità, ad esempio le seguenti:
- Modelli di campo: forniscono modelli basati sui tipi di dati per i controlli associati ai dati. I modelli di campo offrono un modo più semplice per personalizzare l'aspetto dei controlli dati rispetto all'uso dei campi modello per ogni campo.
- Convalida: i dati dinamici consentono di usare gli attributi nelle classi di dati per specificare la convalida per scenari comuni, ad esempio campi obbligatori, controllo degli intervalli, controllo dei tipi, corrispondenza dei modelli usando espressioni regolari e convalida personalizzata. La convalida viene applicata dai controlli dati.
Queste funzionalità, tuttavia, hanno i requisiti seguenti:
- Il livello di accesso ai dati deve essere basato su Entity Framework o LINQ to SQL.
- Gli unici controlli origine dati supportati per queste funzionalità sono i controlli EntityDataSource o LinqDataSource .
- Le funzionalità richiedono un progetto Web creato usando i modelli Dynamic Data o Dynamic Data Entityes per avere tutti i file necessari per supportare la funzionalità.
Un obiettivo principale del supporto di Dynamic Data in ASP.NET 4 consiste nell'abilitare le nuove funzionalità di Dynamic Data per qualsiasi applicazione ASP.NET. Nell'esempio seguente viene illustrato il markup per i controlli che possono sfruttare la funzionalità Dynamic Data in una pagina esistente.
<asp:GridView ID="GridView1" runat="server" AutoGenerateColumns="True"
DataKeyNames="ProductID" DataSourceID="LinqDataSource1">
</asp:GridView>
<asp:LinqDataSource ID="LinqDataSource1" runat="server"
ContextTypeName="DataClassesDataContext" EnableDelete="True" EnableInsert="True"
EnableUpdate="True" TableName="Products">
</asp:LinqDataSource>
Nel codice della pagina è necessario aggiungere il codice seguente per abilitare il supporto dei dati dinamici per questi controlli:
GridView1.EnableDynamicData(typeof(Product));
Quando il controllo GridView è in modalità di modifica, i dati dinamici convalidano automaticamente che i dati immessi siano nel formato corretto. In caso contrario, viene visualizzato un messaggio di errore.
Questa funzionalità offre anche altri vantaggi, ad esempio la possibilità di specificare i valori predefiniti per la modalità di inserimento. Senza Dynamic Data, per implementare un valore predefinito per un campo, è necessario collegarsi a un evento, individuare il controllo (usando FindControl) e impostarne il valore. In ASP.NET 4, la chiamata EnableDynamicData supporta un secondo parametro che consente di passare i valori predefiniti per qualsiasi campo dell'oggetto, come illustrato in questo esempio:
DetailsView1.EnableDynamicData(typeof(Product), new { ProductName = "DefaultName" });
Sintassi del controllo DynamicDataManager dichiarativa
Il controllo DynamicDataManager è stato migliorato in modo che sia possibile configurarlo in modo dichiarativo, come con la maggior parte dei controlli in ASP.NET, anziché solo nel codice. Il markup per il 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 dei dati dinamici per il controllo GridView1 a cui viene fatto riferimento nella sezione DataControls del controllo DynamicDataManager .
Modelli di entità
I modelli di entità offrono un nuovo modo per personalizzare il layout dei dati senza richiedere di creare una pagina personalizzata. I modelli di pagina usano il controllo FormView (anziché il controllo DetailsView , come usato nei modelli di pagina nelle versioni precedenti di Dynamic Data) e il controllo DynamicEntity per eseguire il rendering dei modelli di entità. In questo modo viene fornito un maggiore controllo sul markup sottoposto a rendering da Dynamic Data.
L'elenco seguente mostra il nuovo layout della directory del progetto che contiene modelli di entità:
\DynamicData\EntityTemplates
\DynamicData\EntityTemplates\Default.ascx
\DynamicData\EntityTemplates\Default_Edit.ascx
\DynamicData\EntityTemplates\Default_Insert.ascx
La EntityTemplate directory contiene modelli per visualizzare gli oggetti modello di dati. Per impostazione predefinita, gli oggetti vengono sottoposti a rendering usando il Default.ascx modello, che fornisce il markup simile al markup creato dal controllo DetailsView usato dal controllo Dynamic Data in ASP.NET 3.5 SP1. Nell'esempio seguente viene illustrato il markup per il Default.ascx controllo:
<asp:EntityTemplate runat="server" ID="TemplateContainer1">
<ItemTemplate>
<tr
<td>
<asp:Label ID="Label1" runat="server" OnInit="Label_Init" />
</td>
<td>
<asp:DynamicControl runat="server" OnInit="DynamicControl_Init" />
</td>
</tr>
</ItemTemplate>
</asp:EntityTemplate>
I modelli predefiniti possono essere modificati per modificare l'aspetto e l'aspetto per l'intero sito. Esistono modelli per le operazioni di visualizzazione, modifica e inserimento. È possibile aggiungere nuovi modelli in base al nome dell'oggetto dati per modificare l'aspetto e l'aspetto di un solo tipo di oggetto. Ad esempio, è possibile aggiungere il modello seguente:
\DynamicData\EntityTemplates\Products.aspx
Il modello potrebbe contenere il markup seguente:
<tr>
<td>Name</td>
<td><asp:DynamicControl runat="server" DataField="ProductName" /></td>
<td>Category</td>
<td><asp:DynamicControl runat="server" DataField="Category" /></td>
</tr>
I nuovi modelli di entità vengono visualizzati in una pagina usando il nuovo controllo DynamicEntity . In fase di esecuzione, questo controllo viene sostituito con il contenuto del modello di entità. Il markup seguente mostra il controllo FormView nel Detail.aspx modello di pagina che usa il modello di entità. Si noti l'elemento DynamicEntity nel markup.
<asp:FormView runat="server" ID="FormView1"
DataSourceID="DetailsDataSource"
OnItemDeleted="FormView1_ItemDeleted">
<ItemTemplate>
<table class="DDDetailsTable" cellpadding="6">
<asp:DynamicEntity runat="server" />
<tr class="td">
<td colspan="2">
<asp:DynamicHyperLink ID="EditHyperLink" runat="server"
Action="Edit" Text="Edit" />
<asp:LinkButton ID="DeleteLinkButton" runat="server"
CommandName="Delete"
CausesValidation="false"
OnClientClick='return confirm("Are you sure you want to delete this item?");'
Text="Delete" />
</td>
</tr>
</table>
</ItemTemplate>
</asp:FormView>
Nuovi modelli di campo per URL e indirizzi Email
ASP.NET 4 introduce due nuovi modelli EmailAddress.ascx di campo predefiniti e Url.ascx. Questi modelli vengono usati per i campi contrassegnati come EmailAddress o Url con l'attributo DataType . Per gli oggetti EmailAddress , il campo viene visualizzato come collegamento ipertestuale creato usando il protocollo mailto: . Quando gli utenti fai clic sul collegamento, apre il client di posta elettronica dell'utente e crea un messaggio di scheletro. Gli oggetti digitati come URL vengono visualizzati come collegamenti ipertestuali normali.
Nell'esempio seguente viene illustrato il modo in cui i campi verranno contrassegnati.
[DataType(DataType.EmailAddress)]
public object HomeEmail { get; set; }
[DataType(DataType.Url)]
public object Website { get; set; }
Creazione di collegamenti con il controllo DynamicHyperLink
I dati dinamici usano la nuova funzionalità di routing aggiunta in .NET Framework 3.5 SP1 per controllare gli URL visualizzati dagli utenti finali quando accedono al sito Web. Il nuovo controllo DynamicHyperLink semplifica la compilazione di collegamenti alle pagine in un sito Dinamico dati. Nell'esempio seguente viene illustrato come usare il controllo DynamicHyperLink :
<asp:DynamicHyperLink ID="ListHyperLink" runat="server"
Action="List" TableName="Products">
Show all products
</asp:DynamicHyperLink>
Questo markup crea un collegamento che punta alla pagina Elenco per la Products tabella in base alle route definite nel Global.asax file. Il controllo usa automaticamente il nome della tabella predefinito basato sulla pagina Dati dinamici.
Supporto per l'ereditarietà nel modello di dati
Entity Framework e LINQ to SQL supportano l'ereditarietà nei modelli di dati. Un esempio di questo potrebbe essere un database con una InsurancePolicy tabella. Può anche contenere CarPolicy e HousePolicy tabelle con gli stessi campi e InsurancePolicy quindi aggiungere altri campi. I dati dinamici sono stati modificati per comprendere gli oggetti ereditati nel modello di dati e supportare l'scaffolding per le tabelle ereditate.
Supporto per relazioni molti-a-molti (solo Entity Framework)
Entity Framework offre un supporto avanzato per relazioni molti-a-molti tra tabelle, implementate esponendo la relazione come raccolta in un oggetto Entity . Sono stati aggiunti modelli di nuovi ManyToMany.ascx e campi per fornire supporto per la visualizzazione e ManyToMany_Edit.ascx la modifica dei dati coinvolti nelle relazioni molti-a-molti.
Nuovi attributi per controllare le enumerazioni di visualizzazione e supporto
DisplayAttribute è stato aggiunto per fornire un controllo aggiuntivo sulla modalità di visualizzazione dei campi. L'attributo DisplayName nelle versioni precedenti di Dynamic Data consente di modificare il nome utilizzato come didascalia per un campo. La nuova classe DisplayAttribute consente di specificare altre opzioni per la visualizzazione di un campo, ad esempio l'ordine in cui viene visualizzato un campo e se un campo verrà usato come filtro. L'attributo fornisce anche un controllo indipendente del nome utilizzato per le etichette in un controllo GridView , il nome utilizzato in un controllo DetailsView , il testo della Guida per il campo e la filigrana utilizzata per il campo (se il campo accetta l'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. I dati dinamici usano il nuovo Enumeration.ascx modello di campo per creare l'interfaccia utente per visualizzare e modificare i valori di enumerazione. Il modello esegue il mapping dei valori dal database ai nomi nell'enumerazione.
Supporto avanzato per i filtri
Dati dinamici 1.0 forniti con filtri predefiniti per colonne booleane e colonne chiave esterna. I filtri non consentono di specificare se sono stati visualizzati o nell'ordine in cui sono stati visualizzati. Il nuovo attributo DisplayAttribute risolve entrambi questi problemi fornendo il controllo su se una colonna viene visualizzata come filtro e nell'ordine in cui verrà visualizzata.
Un ulteriore miglioramento è che il supporto di filtro è stato rescritto per usare la nuova funzionalità di Web Forms. In questo modo è possibile creare filtri senza richiedere conoscenza del controllo origine dati con cui verranno usati i filtri. Oltre a queste estensioni, i filtri sono stati trasformati anche in controlli modello, che consentono di aggiungere nuovi. Infine, la classe DisplayAttribute menzionata in precedenza consente l'override del filtro predefinito, nello stesso modo in cui UIHint consente l'override del modello di campo predefinito per una colonna.
Miglioramenti dello sviluppo Web di Visual Studio 2010
Lo sviluppo Web in Visual Studio 2010 è stato migliorato per una maggiore compatibilità CSS, maggiore produttività tramite HTML e ASP.NET frammenti di markup e nuovi javaScript IntelliSense dinamici.
Compatibilità CSS migliorata
Visual Web Developer Designer in Visual Studio 2010 è stato aggiornato per migliorare la conformità degli standard CSS 2.1. La finestra di progettazione mantiene meglio l'integrità dell'origine HTML ed è più affidabile rispetto alle versioni precedenti di Visual Studio. Sotto il cofano sono stati apportati miglioramenti dell'architettura che consentiranno migliori miglioramenti futuri nel rendering, nel layout e nella manutenzione.
Frammenti di codice HTML e JavaScript
Nell'editor HTML, IntelliSense completa automaticamente i nomi dei tag. La funzionalità Frammenti di codice IntelliSense completa automaticamente gli interi tag e altro ancora. In Visual Studio 2010 i frammenti di codice IntelliSense sono supportati per JavaScript, insieme a C# e Visual Basic, supportati nelle versioni precedenti di Visual Studio.
Visual Studio 2010 include oltre 200 frammenti di codice che consentono di completare automaticamente i tag comuni ASP.NET e HTML, inclusi gli attributi obbligatori (ad esempio runat="server") e gli attributi comuni specifici di un tag (ad esempio ID, DataSourceID, ControlToValidate e Text).
È possibile scaricare frammenti aggiuntivi oppure scrivere frammenti di codice personalizzati che incapsulano i blocchi di markup usati dall'utente o dal team per le attività comuni.
Miglioramenti di JavaScript IntelliSense
In Visual 2010 JavaScript IntelliSense è stato riprogettata per offrire un'esperienza di modifica ancora più completa. IntelliSense ora riconosce gli oggetti generati dinamicamente da metodi come registerNamespace e da tecniche simili usate da altri framework JavaScript. Le prestazioni sono state migliorate per analizzare librerie di script di grandi dimensioni e per visualizzare IntelliSense con poco o nessun ritardo di elaborazione. La compatibilità è stata notevolmente aumentata per supportare quasi tutte le librerie di terze parti e supportare stili di codifica diversi. I commenti della documentazione vengono ora analizzato come si digita e vengono immediatamente sfruttati da IntelliSense.
Distribuzione di applicazioni Web con Visual Studio 2010
Quando ASP.NET sviluppatori distribuiscono un'applicazione Web, spesso riscontrano problemi come quelli seguenti:
- La distribuzione in un sito di hosting condiviso richiede tecnologie come FTP, che possono essere lente. È inoltre necessario eseguire manualmente attività come l'esecuzione di script SQL per configurare un database e è necessario modificare le impostazioni iis, ad esempio la configurazione di una cartella di directory virtuale come applicazione.
- In un ambiente aziendale, oltre alla distribuzione dei file dell'applicazione Web, gli amministratori devono spesso modificare ASP.NET file di configurazione e impostazioni IIS. Gli amministratori del database devono eseguire una serie di script SQL per ottenere l'esecuzione del database dell'applicazione. Tali installazioni sono intensivo di lavoro, spesso richiedono ore per completare e devono essere documentate attentamente.
Visual Studio 2010 include tecnologie che consentono di risolvere questi problemi e che consentono di distribuire facilmente applicazioni Web. Una di queste tecnologie è lo strumento di distribuzione Web IIS (MsDeploy.exe).
Le funzionalità di distribuzione Web in Visual Studio 2010 includono le seguenti aree principali:
- Creazione di pacchetti Web
- trasformazione Web.config
- Distribuzione di database
- Pubblicazione con un clic per le applicazioni Web
Le sezioni seguenti forniscono informazioni dettagliate su queste funzionalità.
Creazione di pacchetti Web
Visual Studio 2010 usa lo strumento MSDeploy per creare un file compresso (.zip) per l'applicazione, denominato pacchetto Web. Il file di pacchetto contiene metadati sull'applicazione e sul contenuto seguente:
- Impostazioni IIS, che includono le impostazioni del pool di applicazioni, le impostazioni della pagina degli errori e così via.
- Il contenuto Web effettivo, che include pagine Web, controlli utente, contenuto statico (immagini e file HTML) e così via.
- SQL Server schemi e dati del database.
- Certificati di sicurezza, componenti da installare nella gaC, nelle impostazioni del Registro di sistema e così via.
Un pacchetto Web può essere copiato in qualsiasi server e quindi installato manualmente usando Gestione IIS. In alternativa, per la distribuzione automatica, il pacchetto può essere installato usando i comandi della riga di comando o usando le API di distribuzione.
Visual Studio 2010 offre attività e destinazioni di MSBuild predefinite per creare pacchetti Web. Per altre informazioni, vedere ASP.NET Web Application Project Deployment Overview (Panoramica della distribuzione di progetti di applicazione Web) nel sito Web MSDN e 10 + 20 motivi per cui è consigliabile creare un pacchetto Web nel blog di Vishal Joshi.
Trasformazione Web.config
Per la distribuzione di applicazioni Web, Visual Studio 2010 introduce la trasformazione documento XML (XDT), una funzionalità che consente di trasformare un Web.config file dalle impostazioni di sviluppo alle impostazioni di produzione. Le impostazioni di trasformazione vengono specificate nei file di trasformazione denominati web.debug.config, web.release.confige così via. I nomi di questi file corrispondono alle configurazioni di MSBuild. Un file di trasformazione include solo le modifiche che è necessario apportare a un file distribuito Web.config . Specificare le modifiche usando la sintassi semplice.
L'esempio seguente mostra una parte di un web.release.config file che potrebbe essere prodotto per la distribuzione della configurazione di versione. La parola chiave Replace nell'esempio specifica che durante la distribuzione il nodo connectionString nel Web.config file verrà sostituito con i valori elencati nell'esempio.
<connectionStrings xdt:Transform="Replace">
<add name="BlogDB" connectionString="connection string detail]" />
</connectionStrings>
Per altre informazioni, vedere Web.config Transformation Syntax for Web Application Project Deployment (Sintassi di trasformazione per la distribuzione di progetti di applicazione Web) nel sito Web MSDN e nelladistribuzione Web: Web.Config Transformation nel blog di Vishal Joshi.
Distribuzione del database
Un pacchetto di distribuzione di Visual Studio 2010 può includere dipendenze da SQL Server database. Come parte della definizione del pacchetto, specificare il stringa di connessione per il database di origine. Quando si crea il pacchetto Web, Visual Studio 2010 crea script SQL per lo schema del database e facoltativamente per i dati e li aggiunge al pacchetto. È anche possibile fornire script SQL personalizzati e specificare la sequenza in cui devono essere eseguiti nel server. In fase di distribuzione viene fornito un stringa di connessione appropriato per il server di destinazione. Il processo di distribuzione usa quindi questa stringa di connessione per eseguire gli script che creano lo schema del database e aggiungono i dati.
Inoltre, usando la pubblicazione con un solo clic, è possibile configurare la distribuzione per pubblicare il database direttamente quando l'applicazione viene pubblicata in un sito di hosting condiviso remoto. Per altre informazioni, vedere Procedura: Distribuire un database con un progetto di applicazione Web nel sito Web MSDN e distribuzione di database con VS 2010 nel blog di Vishal Joshi.
One-Click Pubblicare per le applicazioni Web
Visual Studio 2010 consente anche di usare il servizio di gestione remota IIS per pubblicare un'applicazione Web in un server remoto. È possibile creare un profilo di pubblicazione per l'account di hosting o per i server di test o i server di gestione temporanea. Ogni profilo può salvare le credenziali appropriate in modo sicuro. È quindi possibile eseguire la distribuzione in uno dei server di destinazione con un solo clic usando la barra degli strumenti Pubblica con un clic Web. Con Visual Studio 2010 è anche possibile eseguire la pubblicazione tramite la riga di comando di MSBuild. In questo modo è possibile configurare l'ambiente di compilazione del team per includere la pubblicazione in un modello di integrazione continua.
Per altre informazioni, vedere Procedura: Distribuire un progetto di applicazione Web usando One-Click pubblicazione e distribuzione Web nel sito Web MSDN e web 1-Click Publish with VS 2010 (Pubblica con VS 2010 ) nel blog di Vishal Joshi. Per visualizzare presentazioni video sulla distribuzione di applicazioni Web in Visual Studio 2010, vedere VS 2010 for Web Developer Previews nel blog di Vishal Joshi.
Risorse
I siti Web seguenti forniscono informazioni aggiuntive su ASP.NET 4 e Visual Studio 2010.
- ASP.NET 4 : documentazione ufficiale per ASP.NET 4 nel sito Web MSDN.
- https://www.asp.net/ — Sito Web del team di ASP.NET.
- https://www.asp.net/dynamicdata/ e ASP.NET Mappa contenuto dinamico dei dati : risorse online nel sito del team di ASP.NET e nella documentazione ufficiale per ASP.NET Dynamic Data.
- https://www.asp.net/ajax/ — La risorsa Web principale per lo sviluppo ASP.NET Ajax.
- https://devblogs.microsoft.com/dotnet/category/aspnet/ - Blog del team di sviluppatori Visual Web, che include informazioni sulle funzionalità in Visual Studio 2010.
- ASP.NET WebStack : la risorsa Web principale per le versioni di anteprima di ASP.NET.
Dichiarazione di non responsabilità
Il presente documento è una versione preliminare e può essere modificato in modo sostanziale prima della versione finale commerciale del software qui descritto.
Le informazioni contenute in questo documento rappresentano la posizione attuale di Microsoft Corporation sulle problematiche trattate alla data di pubblicazione. Poiché Microsoft deve rispondere alle mutevoli condizioni del mercato, questo non deve essere interpretato come un impegno da parte di Microsoft, che non garantisce l'accuratezza delle informazioni presentate dopo la data di pubblicazione.
Il presente white paper è fornito solo a scopi informativi. MICROSOFT NON RILASCIA ALCUNA GARANZIA, ESPRESSA, IMPLICITA O LEGALE, IN MERITO ALLE INFORMAZIONI DEL PRESENTE DOCUMENTO.
Il rispetto di tutte le applicabili leggi in materia di copyright è esclusivamente a carico dell'utente. Fermi restando tutti i diritti coperti da copyright, nessuna parte di questa documentazione potrà comunque essere riprodotta o inserita in un sistema di riproduzione o trasmessa in qualsiasi forma e con qualsiasi mezzo (in formato elettronico, meccanico, fotocopia, tramite registrazione o altro) per qualsiasi scopo, senza il permesso scritto di Microsoft Corporation.
Microsoft può essere titolare di brevetti, domande di brevetto, marchi, copyright o altri diritti di proprietà intellettuale relativi all'oggetto della presente documentazione. Salvo quanto espressamente previsto in un contratto scritto di licenza Microsoft, la consegna della presente documentazione non implica la concessione di alcuna licenza su tali brevetti, marchi, copyright o altra proprietà intellettuale.
Se non diversamente specificato, le società di esempio, le organizzazioni, i prodotti, i nomi di dominio, gli indirizzi di posta elettronica, i logo, le persone, i luoghi e gli eventi illustrati nel presente documento sono fittizie e non è prevista alcuna associazione con alcuna società, organizzazione, prodotto, nome di dominio, indirizzo di posta elettronica, logo, persona, luogo o evento è previsto o deve essere dedotto.
© Microsoft Corporation 2009. Tutti i diritti sono riservati.
Microsoft e Windows sono marchi registrati o marchi di Microsoft Corporation negli Stati Uniti e/o in altri paesi.
I nomi di società e prodotti reali citati nel presente documento possono essere marchi dei rispettivi proprietari.