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
Web.config
Memorizzazione nella cache dell'output estendibile
Avvio automatico delle applicazioni Web
Reindirizzamento permanente di una pagina
Riduzione dello stato della sessione
Espansione dell'intervallo di URL consentiti
Convalida delle richieste estendibili
Memorizzazione nella cache degli oggetti e estendibilità della memorizzazione nella cache degli oggetti
Codifica estendibile di HTML, URL e intestazione HTTP
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
Script espliciti di ScriptManager
Web Form
Impostazione dei meta tag con le proprietà Page.MetaKeywords e Page.MetaDescription
Abilitazione dello stato di visualizzazione per 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 con codifica HTML
Modifiche al modello di progetto
Miglioramenti css
Nascondere gli elementi div nei campi nascosti
Rendering di una tabella esterna per i controlli basato su modelli
Miglioramenti del controllo ListView
Miglioramenti del controllo CheckBoxList e RadioButtonList
Miglioramenti al controllo menu
Creazione guidata e controlli CreateUserWizard 56
MVC
Assistenza aree
Supporto per la convalida degli attributi Data-Annotation
Helper basato su modelli
Dati dinamici
Abilitazione di dati dinamici per progetti esistenti
Sintassi del controllo DynamicDataManager dichiarativo
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 le enumerazioni di visualizzazione e supporto
Supporto avanzato per i filtri
Miglioramenti dello 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
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 principali ASP.NET, ad esempio la memorizzazione nella cache di output e l'archiviazione dello stato della sessione.
Refactoring dei file Web.config
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>
Cache dell'output espandibile
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 più rapidamente il contenuto recuperando l'output generato dalla memoria anziché 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 estensione al caching 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 distribuita.
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.
È anche possibile selezionare provider di cache di output diversi per ogni 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 lavoro. 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 delle 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.
Annotazioni
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 le 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 a causa di cache non iniziali. 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 Getting Started with the IIS 7.5 Application Warm-Up Module (Introduzione a 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, è necessario 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 usa 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 restituisce il risultato, 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 eseguire l'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 il rilascio 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 così il round trip non necessario effettuato dal browser per i reindirizzamenti temporanei.
Riduzione 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 con 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, è necessario serializzare lo stato della sessione 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 dello stato della sessione out-of-process. Quando l'opzione di configurazione compressionEnabled illustrata nell'esempio seguente è impostata su true, ASP.NET comprime lo stato della sessione serializzata (e decompressa) usando la classe System.IO.Compression.GZipStream di .NET Framework.
<sessionState
mode="SqlServer"
sqlConnectionString="data source=dbserver;Initial Catalog=aspnetstate"
allowCustomSqlDatabase="true"
compressionEnabled="true"
/>
Con la semplice aggiunta del nuovo attributo al Web.config file, le applicazioni con cicli di CPU di riserva nei server Web possono realizzare riduzioni sostanziali delle dimensioni dei dati dello stato sessione serializzati.
Espansione dell'intervallo di URL consentiti
ASP.NET 4 introduce nuove opzioni per espandere le dimensioni degli URL dell'applicazione. Le versioni precedenti di ASP.NET vincolavano la lunghezza del percorso URL a 260 caratteri, basandosi sul limite del percorso file di 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.
Annotazioni
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 versioni successive, il driver di dispositivo del protocollo http.sys rifiuta automaticamente gli URL con questi caratteri.
Convalida delle richieste estendibili
La convalida delle richieste di ASP.NET cerca nei dati delle richieste HTTP in ingresso per individuare stringhe comunemente usate negli attacchi di Cross-Site Scripting (XSS). 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 causato 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, si crea una classe che deriva dal nuovo tipo System.Web.Util.RequestValidator e si configura l'applicazione (nella sezione httpRuntime del Web.config file) per usare il tipo personalizzato. L'esempio seguente illustra come configurare una classe di convalida della richiesta 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 cookie che intestazioni personalizzate) e il corpo dell'entità sono tutti disponibili per l'ispezione da parte di una classe di convalida della richiesta 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)
{...}
}
Per i casi in cui non si vuole esaminare una parte di dati HTTP in ingresso, la classe di convalida della richiesta può eseguire il fallback per consentire l'esecuzione della convalida della richiesta predefinita ASP.NET semplicemente chiamando base. IsValidRequestString.
Memorizzazione nella cache degli oggetti e Estendibilità della memorizzazione nella cache degli oggetti
Dalla prima versione, ASP.NET ha incluso una potente cache di oggetti in memoria (System.Web.Caching.Cache).Cache. L'implementazione della cache è stata così diffusa che è stata usata nelle applicazioni non Web. Tuttavia, è scomodo per un'applicazione Windows Forms o WPF includere un riferimento a System.Web.dll solo per 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 in modo stretto 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 cache ASP.NET, si troveranno concetti familiari nelle nuove API.
Una discussione approfondita della nuova classe MemoryCache e del supporto delle API di base richiederebbe un intero documento. Tuttavia, l'esempio seguente offre un'idea del funzionamento della nuova API della cache. L'esempio è stato scritto per un'applicazione Windows Form, 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 estendibile di HTML, URL e intestazione HTTP
In ASP.NET 4 è possibile creare routine di codifica personalizzate per le seguenti attività comuni di codifica del testo:
- Codifica HTML.
- Codifica URL.
- Codifica 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 . Ciò consente a una parte di un team di sviluppo Web di creare 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 dalle API di codifica ASP.NET pubbliche vengano instradate tramite 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>
Annotazioni
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 del dominio applicazione CLR per tenere traccia del tempo stimato della CPU 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 specificare come destinazione .NET Framework 4 e versioni successive. Se si usa in modo esplicito .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 usa in modo esplicito .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 sull'indirizzamento a 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 compilare 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 inferiore (ad esempio 4.0). Tuttavia, in fase di progettazione in Visual Studio 2010 o quando si usa il comando aspnet_compiler , l'uso delle funzionalità più recenti del framework causerà errori del compilatore.
Ajax
jQuery incluso in Web Forms e MVC
I modelli di Visual Studio per Web Form 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 dall'uomo e non minificata 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 non minificata di jQuery durante lo sviluppo di un'applicazione. Includere la versione minima di jQuery per le applicazioni di produzione.
Ad esempio, nella pagina Web Forms seguente viene illustrato come usare jQuery per modificare il colore di sfondo dei controlli TextBox ASP.NET a 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
La rete CDN (Content Delivery Network) Microsoft Ajax 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 simile al seguente:
<script src="https://ajax.aspnetcdn.com/ajax/jquery/jquery-1.4.2.js" type="text/javascript"></script>
Sfruttando la rete CDN 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. Inoltre, la rete CDN Microsoft Ajax consente ai browser di riutilizzare i file JavaScript memorizzati nella cache per siti Web che si trovano 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. Semplicemente impostando 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 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")]
Script espliciti di ScriptManager
In passato, se è stato usato il ASP.NET ScriptManger, è stato 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 si includeranno in modo esplicito riferimenti di script a singoli file di script di base del framework richiesti 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 del componente Ajax ASP.NET 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>
Moduli Web
Web Form è 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 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 dei filtri per i controlli delle origini 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à ,vale a dire 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 sono già presenti 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 che consente di impostare i tag in modo dinamico per descrivere la pagina specifica.
È anche possibile impostare le proprietà Keywords e Description nella direttiva @ Page nella parte superiore del markup della pagina Web Form, 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" %>
In questo modo verrà eseguito l'override del contenuto del meta tag (se presente) già dichiarato nella pagina.
Il contenuto del meta tag description viene usato per migliorare le anteprime delle presentazioni di ricerca in Google. Per informazioni dettagliate, vedere Migliorare i frammenti di codice con una ristrutturazione della meta description nel blog di Google Webmaster Central. Google e Windows Live Search non usano il contenuto delle parole chiave per nulla, ma altri motori di ricerca potrebbero.
Queste nuove proprietà sono una funzionalità semplice, ma consentono di evitare di aggiungerle manualmente o di scrivere codice personalizzato per creare i meta tag.
Abilitazione dello stato di visualizzazione per 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 pubblicarli nuovamente. L'archiviazione di uno stato di visualizzazione superiore a quello necessario può causare una riduzione significativa delle prestazioni. Nelle versioni precedenti di ASP.NET, gli sviluppatori potevano disabilitare lo stato di visualizzazione per i 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 ed Inherit. Abilitato abilita lo stato di visualizzazione per il controllo e per tutti i controlli figlio impostati su Eredita 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 pertanto 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 per la prima volta, nel browser viene visualizzato l'output seguente:
Disabilitato : [DynamicValue]
Abilitato:[DynamicValue]
Dopo un postback, tuttavia, viene visualizzato l'output seguente:
Disabilitato : [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 nella pagina. Il valore predefinito di ViewStateMode è Abilitato 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 di 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 di questa funzionalità è costituito dai controlli ContentPlaceHolder nelle pagine master, in cui è possibile impostare ViewStateMode su Disabilitato 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 sta usando 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 usare l'oggetto HttpBrowserCapabilities per determinare se il tipo e la versione del browser corrente supportano una versione specifica di JavaScript. In alternativa, è possibile usare 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 come Google Chrome, Research in Motion BlackBerry smartphones 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à personalizzate del browser. I file del browser sono difficili da aggiornare, il processo per l'aggiornamento è piuttosto complicato e la sintassi XML per .browser i file può essere complessa da usare e definire. Ciò che renderebbe questo processo molto più semplice sarebbe la presenza di una sintassi comune di definizione del browser, un database contenente definizioni aggiornate del browser, 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: estendere la funzionalità di definizione delle funzionalità del browser ASP.NET o sostituirla completamente. Le sezioni seguenti descrivono prima come sostituire la funzionalità e quindi come estenderla.
Sostituzione della 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. L'esempio seguente illustra 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. Qualsiasi modifica apportata alla classe BrowserCapabilitiesProvider deve essere eseguita 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 l'esecuzione del codice 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 operazioni significative per ottenere l'oggetto HttpBrowserCapabilities , ciò può influire sulle prestazioni. Per evitare che ciò accada, è possibile memorizzare nella cache l'oggetto HttpBrowserCapabilities . Segui questi passaggi:
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 personalizzato BuildCacheKey e ottiene il periodo di tempo in cui memorizzare nella cache chiamando un metodo personalizzato GetCacheTime. 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
Nella sezione precedente è stato descritto 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 definizioni del browser personalizzato e 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, seguire questa procedura.
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 di 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 .
Annotazioni
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 Form. Il routing consente di configurare un'applicazione per accettare gli URL delle richieste 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 (SEO) 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 che si usa quando si definiscono le route. La classe passa i dati alla pagina a cui viene indirizzata 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 offre un modo semplice per creare un URL corrispondente a un URL di route all'interno di un controllo server 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 le pagine Web Forms
Nell'esempio seguente viene illustrato come definire una route Web Form 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 mappa il percorso a una pagina fisica (nel primo percorso, 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 indirizzata (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 l'accesso viene negato 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 Form
Nel codice della pagina fisica di Web Form è 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. Si consideri 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 Web Form. È 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 nel blog di Phil Haack.
ASP.NET 4 include due nuovi generatori di espressioni per il routing di Web Form. Nell'esempio seguente viene illustrato come usarli.
<asp:HyperLink ID="HyperLink1" runat="server"
NavigateUrl="<%$RouteUrl:SearchTerm=scott%>">Search for Scott</asp:HyperLink>
Nell'esempio l'espressione RouteUrl viene usata per definire un URL basato su un parametro di route. In questo modo si evita di dover inserire in modo statico l'URL completo nel markup e si può 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.
Utilizzo dei dati di routing per i parametri del controllo della sorgente 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 analogo 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 script client che fanno 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 generare l'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. Anche se ciò garantisce sempre che gli ID dei controlli nella pagina siano univoci, l'algoritmo ha generato ID di controllo non prevedibili e pertanto è stato difficile fare riferimento allo script client.
La nuova proprietà ClientIDMode consente di specificare in modo più preciso il modo in cui viene generato l'ID client per i controlli. È possibile impostare la proprietà ClientIDMode per qualsiasi controllo, inclusa 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 quali valori ID saranno.
- Prevedibile — questa opzione è principalmente per l'uso nei controlli dei 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 del relativo elemento padre.
È possibile impostare la proprietà ClientIDMode a livello di pagina. Definisce il valore ClientIDMode predefinito per tutti i controlli nella pagina corrente.
Il valore ClientIDMode predefinito a livello di pagina è AutoID e il valore predefinito ClientIDMode a livello di controllo è Inherit. Di conseguenza, se questa proprietà non viene impostata in nessun punto 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 clientIDMode predefinita per tutti i controlli in tutte le pagine dell'applicazione. Se si imposta il valore a livello di computer, definisce l'impostazione ClientIDMode predefinita 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 è derivato dal contenitore di denominazione per l'elemento padre di un controllo. In alcuni scenari, ad esempio quando si usano pagine master, i controlli possono finire con ID come quelli nel codice HTML di cui è stato eseguito il 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 illustrato nel markup (da un controllo TextBox) è solo a due livelli di contenitori di denominazione nella pagina (nei controlli annidati ContentPlaceholder), a causa del modo in cui vengono elaborate le 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 comportano il markup seguente (si presuppone che il resto della pagina e la pagina master corrispondano a quello 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, quindi 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.
Annotazioni
Nota, è necessario assicurarsi che gli ID dei controlli che sono stati renderizzati siano univoci. In caso contrario, può interrompere qualsiasi funzionalità che richiede 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 realmente 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 relativo 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 di cui è stato eseguito il rendering avranno un formato simile al seguente:
rootPanel_ListView1_ProductNameLabel_1In questo caso, il 1 finale è derivato dall'ID del 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="Prevedibile" con un controllo Repeater, vengono generati ID client 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 .
Mantenimento 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 in tale pagina.
La selezione persistente è stata inizialmente supportata solo nei progetti Dynamic Data in .NET Framework 3.5 SP1. Quando questa funzionalità è abilitata, l'elemento corrente selezionato si basa sulla chiave dei 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 ASP.NET pagine con grafici intuitivi e visivamente accattivanti per analisi statistiche o finanziarie complesse. Il controllo Chart di ASP.NET è stato introdotto come componente aggiuntivo per la .NET Framework 3.5 SP1 ed è parte della .NET Framework 4.
Il controllo include le funzionalità seguenti:
- 35 tipi di grafico distinti.
- 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 separazione, interruzioni della scala e ridimensionamento logaritmico.
- Più di 50 formule finanziarie e statistiche per l'analisi e la trasformazione dei dati.
- Associazione e manipolazione semplici 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 del client utilizzando Ajax.
- Gestione dello stato.
- Streaming binario.
Le figure seguenti mostrano esempi di grafici finanziari prodotti dal controllo grafico ASP.NET.
Figura 2: esempi di controlli grafici di ASP.NET
Per altri esempi su come usare il controllo grafico ASP.NET, scaricare il codice di esempio nella pagina Samples Environment for Microsoft Chart Controls (Esempio di ambiente per i controlli grafico Microsoft ) nel sito Web MSDN. Puoi trovare altri esempi di contenuto della community al Forum di Controllo dei Grafici.
Aggiunta del controllo grafico a una pagina ASP.NET
Nell'esempio seguente viene illustrato come aggiungere un controllo Chart a una pagina ASP.NET tramite markup. Nell'esempio, il controllo Grafico produce un istogramma a colonne per 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 del grafico, utilizzare 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
Utilizzo di interruzioni di scala e scale logaritmiche
Le interruzioni di scala e le scale logaritmiche sono due modi aggiuntivi per aggiungere complessità al grafico. Queste caratteristiche 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, utilizzare le proprietà AxisY.IsLogarithmic e ScaleBreakStyle in un oggetto ChartArea . Il frammento di codice seguente illustra come usare le interruzioni di scala 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 le interruzioni di scala abilitate.
Figura 4: Interruzioni di scala
Filtro dei dati con il controllo QueryExtender
Un'attività molto comune per gli sviluppatori che creano pagine Web guidate dai dati consiste nel filtrare i dati. Questa operazione è stata tradizionalmente eseguita tramite la compilazione di clausole Where nei controlli origine dati. Questo approccio può essere complicato e in alcuni casi la sintassi Where non consente di sfruttare le funzionalità complete 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 che i dati vengano inviati alla pagina, con operazioni molto efficienti.
Il controllo QueryExtender supporta un'ampia gamma di opzioni di filtro. Le sezioni seguenti descrivono queste opzioni e forniscono esempi di come usarle.
Ricerca
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 range è simile all'opzione di ricerca, ma specifica una coppia di valori per definire l'intervallo. Nell'esempio seguente il controllo QueryExtender cerca nella UnitPrice colonna i 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 dell'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 con il 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 una sola espressione usata nel controllo QueryExtender alla volta. Tuttavia, è possibile includere più espressioni all'interno del controllo QueryExtender .
Espressioni di codice con codifica HTML
Alcuni siti ASP.NET (in particolare con ASP.NET MVC) si basano principalmente sull'uso <%= expression %> della sintassi (spesso denominata "nuggets di codice") per scrivere testo nella risposta. Quando si usano espressioni di codice, è facile dimenticare di codificare html il testo, se il testo proviene dall'input dell'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 nel modo seguente:
<%= HttpUtility.HtmlEncode(expression) %>
Ad esempio, <%: Request["UserInput"] %> esegue la codifica HTML sul valore request["UserInput"].
L'obiettivo di questa funzionalità è quello di rendere possibile sostituire tutte le istanze della sintassi precedente con la nuova sintassi in modo da evitare di dover scegliere quale utilizzare in ogni fase. Tuttavia, esistono casi in cui il testo di output deve 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 esaminato in altro modo) per la visualizzazione come HTML e che pertanto il valore non deve essere codificato nuovamente in HTML. Ad esempio, il codice HTML seguente non deve essere (e non è) HTML:
<%: new HtmlString("<strong>HTML that is not encoded</strong>") %>
Metodi helper di ASP.NET MVC 2 sono stati aggiornati per funzionare con questa nuova sintassi in modo che non siano doppiamente codificati, 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 tra virgolette può contenere input utente che è ancora vulnerabile. Si noti che l'output dei controlli ASP.NET e degli helper MVC ASP.NET include sempre valori di attributo tra 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 dell'utente.
Modifiche al modello di progetto
Nelle versioni precedenti di ASP.NET, quando si usa Visual Studio per creare un nuovo progetto di sito Web o 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 i principianti, esistono pochissime indicazioni 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 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 a dimensione intera)
Quando si crea un'applicazione Web ASP.NET vuota, Visual Studio crea il layout di cartella seguente:
È simile al layout sito Web vuoto 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à quando si aprono applicazioni meno recenti.
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. La figura seguente illustra il layout del progetto creato quando si crea un nuovo progetto applicazione Web. Il layout di 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 pagina predefinita (home) è 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 markup conforme a XHTML 1.0 rigoroso e con layout specificato con CSS, le pagine nei modelli rappresentano le procedure consigliate per la creazione di ASP.NET 4 applicazioni Web. 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, trovare dove è definito il testo My ASP.NET Application e sostituirlo con un elemento immagine 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 passare 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 css
Una delle principali aree di lavoro in ASP.NET 4 è stata quella di contribuire a rendere il codice HTML conforme agli standard HTML più recenti. Sono incluse le modifiche apportate 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 nuova 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 reso dai controlli è compatibile al 100% con le versioni precedenti 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 rendono il markup XHTML 1.0 Strict.
- La disabilitazione dei controlli non di input non applica più stili non validi.
- gli elementi div intorno ai campi nascosti sono ora stiliti in modo che non interferiscano con le regole CSS create dall'utente.
- I controlli menu effettuano il rendering del codice che è semanticamente corretto e conforme alle linee guida per l'accessibilità.
- I controlli di convalida non eseguono il rendering degli stili inline.
- I controlli che in precedenza eseguivano il rendering di border="0" (controlli che derivano dal controllo Tabella ASP.NET e dal controllo Immagine 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 eseguirà 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 input HTML eseguono invece il rendering di un attributo di classe che fa riferimento a una classe CSS che è possibile usare per definire l'aspetto disattivato del 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 DisabledCssClass statica della classe WebControl . Per gli sviluppatori di controlli, il comportamento da usare per un controllo specifico può essere definito anche tramite la proprietà SupportsDisabledAttribute .
Nascondere gli elementi div nei 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 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 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 usata per applicare stili inline:
- Formview
- Accedi
- Passwordrecovery
- Changepassword
- Mago
- 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 genera il seguente output 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 la gestione dello stile del contenuto del controllo con CSS, perché non viene eseguito il rendering di tag imprevisti dal controllo.
Annotazioni
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 di tabella in grado di ospitare attributi di stile generati dall'opzione di formato automatico.
Miglioramenti del 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 di elementi span per contenere il relativo contenuto.
- Tabella. Il controllo esegue il rendering di un elemento di tabella in modo che contenga 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 in modo 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 html, devono eseguire il rendering del contenuto usando elementi elenco HTML (li). In questo modo è più semplice per gli utenti che leggono 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 è reso come elementi li all'interno di un elemento ol.
- UnorderedList : il rendering del 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>
Annotazioni
Nota Se si imposta RepeatLayout su OrderedList o UnorderedList, la proprietà RepeatDirection non può più essere utilizzata e genererà un'eccezione in fase di esecuzione se la proprietà è stata impostata all'interno del markup o del codice. La proprietà non avrà alcun valore perché il layout visivo di questi controlli viene definito usando invece CSS.
Miglioramenti al controllo menu
Prima di ASP.NET 4, il controllo Menu ha eseguito il rendering di una serie di tabelle HTML. Ciò rendeva più difficile applicare gli stili CSS all'esterno dell'impostazione delle proprietà inline e non era conforme agli standard di accessibilità.
In ASP.NET 4, il controllo esegue ora il rendering HTML usando un markup semantico costituito da un elenco non ordinato e elementi di elenco. 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 maggiore 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 per il rendering, lo spostamento tramite tastiera del menu è stato migliorato usando la gestione dello stato attivo del focus. Quando il controllo Menu ottiene lo stato attivo, è possibile usare i tasti di direzione per spostarsi tra gli elementi. Il controllo Menu ora collega anche i ruoli e gli attributi ARIA (Accessible Rich Internet Applications) accessibili seguendoper 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 sottoposti a rendering. Se vuoi assumere il controllo completo sullo stile per il controllo, puoi 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 formattazione automatica nella finestra di progettazione di Visual Studio per impostare l'aspetto del menu. È quindi possibile eseguire la pagina, aprire l'origine della pagina e quindi copiare il blocco di stile sottoposto a rendering in un file CSS esterno. In Visual Studio annullare lo stile e impostare IncludeStyleBlock su false. Il risultato è che l'aspetto del menu viene definito utilizzando gli stili in un foglio di stile esterno.
Wizard e controlli CreateUserWizard
I controlli Wizard e CreateUserWizard di ASP.NET supportano modelli che consentono di definire il codice HTML che viene eseguito il rendering. CreateUserWizard deriva da Wizard. L'esempio seguente illustra il markup per un controllo CreateUserWizard completamente con modelli.
<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 del codice 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, si dispone comunque di un controllo limitato sull'output del controllo Procedura guidata . In ASP.NET 4 è possibile creare un modello LayoutTemplate e inserire i controlli PlaceHolder (usando nomi riservati) per specificare come si desidera che il Wizard control venga visualizzato. Nell'esempio riportato di seguito viene illustrata questa situazione:
<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, viene sostituito 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 i segnaposti genera il seguente codice HTML (senza il contenuto effettivamente definito nei template):
<span>
</span>
L'unico codice HTML non definito dall'utente è un elemento span . Si anticipa che nelle versioni future, anche il rendering dell'elemento span non sarà eseguito. Questo ora ti dà il pieno controllo su praticamente tutto il contenuto generato dal controllo Wizard.
ASP.NET MVC
ASP.NET MVC è stato introdotto come framework aggiuntivo per ASP.NET 3.5 SP1 nel marzo 2009. Visual Studio 2010 comprende ASP.NET MVC 2, che offre nuove funzionalità e capacità.
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 ASP.NET separato a cui può quindi fare riferimento l'applicazione principale. Ciò consente di gestire la complessità quando si crea un'applicazione di grandi dimensioni e semplifica l'interazione di più team in una singola applicazione.
Supporto per la convalida degli attributi di Annotazione Dati
Gli attributi DataAnnotations consentono di associare la logica di convalida a un modello usando gli attributi dei metadati. Gli attributi DataAnnotations sono stati introdotti in ASP.NET Dynamic Data in ASP.NET 3.5 SP1. Questi attributi sono stati integrati nel gestore di associazione di modelli predefinito e forniscono un mezzo basato sui metadati per convalidare l'input dell'utente.
Helper basato su modelli
Gli helper basato su modelli consentono di associare automaticamente i modelli di modifica e visualizzazione ai tipi di dati. Ad esempio, è possibile usare un helper di modelli per specificare che per un valore System.DateTime viene eseguito automaticamente il rendering di un elemento dell'interfaccia utente come un selettore di data. Questo è simile ai modelli di campo in ASP.NET Dati dinamici.
I metodi helper Html.EditorFor e Html.DisplayFor includono il supporto predefinito per il rendering di tipi di dati standard, nonché 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 ulteriormente l'output degli helper dell'interfaccia utente e avere il controllo completo su ciò che viene generato. I metodi helper 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 l'output sottoposto a rendering. Il rendering dei modelli può essere eseguito singolarmente per una classe.
Dati dinamici
Dynamic Data è stato introdotto nella versione di .NET Framework 3.5 SP1 a metà del 2008. Questa funzionalità offre numerosi miglioramenti per la creazione di applicazioni guidate dai dati, tra cui:
- Esperienza RAD per creare rapidamente un sito Web basato sui dati.
- Convalida automatica basata su vincoli definiti nel modello di dati.
- La possibilità di modificare facilmente il markup generato per i campi nei controlli GridView e DetailsView usando modelli di campo che fanno parte del progetto Dynamic Data.
Annotazioni
Nota Per altre informazioni, vedere la documentazione relativa ai dati dinamici in MSDN Library.
Per ASP.NET 4, Dynamic Data è stato migliorato per offrire agli sviluppatori ancora più potenza per la creazione rapida di siti Web basati sui dati.
Abilitazione di dati dinamici per progetti esistenti
Le funzionalità di Dynamic Data fornite in .NET Framework 3.5 SP1 hanno portato nuove funzionalità come le seguenti:
- Modelli di campo: forniscono modelli basati sui tipi di dati per i controlli associati a 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: Dynamic Data consente di usare attributi nelle classi di dati per specificare la convalida per scenari comuni, ad esempio campi obbligatori, controllo dell'intervallo, controllo dei tipi, corrispondenza dei criteri usando espressioni regolari e convalida personalizzata. La convalida viene applicata dai controlli sui dati.
Tuttavia, queste funzionalità hanno i requisiti seguenti:
- Il livello di accesso ai dati doveva 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 Entities per avere tutti i file necessari per supportare la funzionalità.
L'obiettivo principale del supporto di Dynamic Data in ASP.NET 4 consiste nell'abilitare la nuova funzionalità di Dynamic Data per qualsiasi applicazione ASP.NET. L'esempio seguente mostra 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 per la pagina è necessario aggiungere il codice seguente per abilitare il supporto di Dynamic Data per questi controlli:
GridView1.EnableDynamicData(typeof(Product));
Quando il controllo GridView è in modalità di modifica, Dynamic Data verifica 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 nell'oggetto, come illustrato in questo esempio:
DetailsView1.EnableDynamicData(typeof(Product), new { ProductName = "DefaultName" });
Sintassi del controllo dichiarativo DynamicDataManager
Il controllo DynamicDataManager è stato migliorato in modo da poterlo configurare in modo dichiarativo, come per 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 di Dynamic Data per il controllo GridView1 a cui viene fatto riferimento nella sezione DataControls del controllo DynamicDataManager .
Modelli di entità
I modelli di entità offrono un nuovo modo per personalizzare il layout dei dati senza che sia necessario 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à. Questo ti dà un maggiore controllo sul markup eseguito da Dynamic Data.
L'elenco seguente mostra il nuovo layout della directory del progetto che contiene i 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 la visualizzazione degli oggetti modello di dati. Per impostazione predefinita, il rendering degli oggetti viene eseguito usando il Default.ascx modello , che fornisce markup simile al markup creato dal controllo DetailsView usato da 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 dell'intero sito. Sono disponibili modelli per le operazioni di visualizzazione, modifica e inserimento. È possibile aggiungere nuovi modelli in base al nome dell'oggetto dati per modificare 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 di posta elettronica
ASP.NET 4 introduce due nuovi modelli di campo predefiniti, EmailAddress.ascx 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 tramite il protocollo mailto: . Quando gli utenti fanno clic sul collegamento, si apre il client di posta elettronica e viene creato un messaggio di base. Gli oggetti digitati come URL vengono visualizzati come collegamenti ipertestuali ordinari.
Nell'esempio seguente viene illustrato come contrassegnare i campi.
[DataType(DataType.EmailAddress)]
public object HomeEmail { get; set; }
[DataType(DataType.Url)]
public object Website { get; set; }
Creazione di collegamenti con il controllo DynamicHyperLink
Dynamic Data usa 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 creazione di collegamenti alle pagine in un sito Dynamic Data. L'esempio seguente illustra 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 Lista per la tabella Products basata sulle route definite nel file Global.asax. Il controllo usa automaticamente il nome di tabella predefinito su cui si basa la pagina Dynamic Data.
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 tabelle CarPolicy e HousePolicy che hanno gli stessi campi di InsurancePolicy e poi aggiungere altri campi. Dynamic Data è stato modificato per comprendere gli oggetti ereditati nel modello di dati e supportare lo scaffolding per le tabelle ereditate.
Supporto per le relazioni molti-a-molti (solo per Entity Framework)
Entity Framework offre un supporto avanzato per le relazioni molti-a-molti tra tabelle, implementate esponendo la relazione come raccolta in un oggetto Entity . Sono stati aggiunti nuovi modelli di campo ManyToMany.ascx e ManyToMany_Edit.ascx per fornire supporto nella visualizzazione e modifica dei dati coinvolti in relazioni molti-a-molti.
Nuovi attributi per controllare il display e supportare le enumerazioni
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 usato 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 sul nome usato per le etichette in un controllo GridView, il nome utilizzato in un controllo DetailsView, il testo guida per il campo e la filigrana utilizzata per il campo (se il campo accetta input di testo).
La classe EnumDataTypeAttribute è stata aggiunta per consentire di eseguire il mapping dei campi alle enumerazioni. Quando si applica questo attributo a un campo, si specifica un tipo di enumerazione. Dynamic Data usa il nuovo Enumeration.ascx modello di campo per creare l'interfaccia utente per visualizzare e modificare i valori di enumerazione. Il modello mappa i valori del database ai nomi nell'enumerazione.
Supporto avanzato per i filtri
Dynamic Data 1.0 fornito 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 consentendo di controllare se una colonna viene visualizzata come filtro e nell'ordine in cui verrà visualizzata.
Un ulteriore miglioramento consiste nel fatto che il supporto dei filtri è stato riscrittoper usare la nuova funzionalità di Web Form. In questo modo è possibile creare filtri senza richiedere la conoscenza del controllo origine dati con cui verranno usati i filtri. Oltre a queste estensioni, anche i filtri sono stati trasformati in controlli modello, che consentono di aggiungere nuovi. Infine, la classe DisplayAttribute indicata in precedenza consente di eseguire 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, aumentando la produttività tramite HTML e ASP.NET frammenti di markup e nuovi JavaScript in IntelliSense dinamici.
Compatibilità CSS migliorata
La finestra di progettazione di Visual Web Developer in Visual Studio 2010 è stata aggiornata per migliorare la conformità agli 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. Sono stati apportati miglioramenti dell'architettura che consentiranno di migliorare meglio i miglioramenti futuri nel rendering, nel layout e nella gestibilità.
Frammenti di codice HTML e JavaScript
Nell'editor HTML, IntelliSense completa automaticamente i nomi dei tag. La funzionalità Frammenti di Codice IntelliSense completa automaticamente 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 HTML e di ASP.NET comuni, 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 di codice aggiuntivi oppure scrivere frammenti 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 riprogettato 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 un ritardo di elaborazione minimo o nullo. 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 analizzati durante la digitazione 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 i 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 ed è necessario modificare le impostazioni di IIS, ad esempio la configurazione di una cartella di directory virtuale come applicazione.
- In un ambiente aziendale, oltre a distribuire i file dell'applicazione Web, gli amministratori devono spesso modificare ASP.NET file di configurazione e impostazioni IIS. Gli amministratori di database devono eseguire una serie di script SQL per ottenere l'esecuzione del database dell'applicazione. Tali installazioni sono a elevato utilizzo di manodopera, spesso richiedono ore per il completamento e devono essere documentate attentamente.
Visual Studio 2010 include tecnologie per 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 aree principali seguenti:
- Creazione di pacchetti Web
- trasformazione di 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, detto pacchetto Web. Il file del pacchetto contiene i metadati relativi all'applicazione e il contenuto seguente:
- Impostazioni iis, che includono le impostazioni del pool di applicazioni, le impostazioni della pagina di errore e così via.
- Il contenuto Web effettivo, che include pagine Web, controlli utente, contenuto statico (immagini e file HTML) e così via.
- Schemi e dati del database di SQL Server.
- 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 tramite Gestione IIS. In alternativa, per la distribuzione automatizzata, 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 MSBuild predefinite per creare pacchetti Web. Per ulteriori informazioni, vedere ASP.NET Web Application Project Deployment Overview sul sito Web MSDN e 10 + 20 motivi per cui dovresti creare un pacchetto Web sul 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 . È possibile specificare le modifiche usando una sintassi semplice.
L'esempio seguente mostra una parte di un file web.release.config che potrebbe essere prodotto per la distribuzione della configurazione di rilascio. 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 ulteriori informazioni, vedere Sintassi di trasformazione di Web.config per la distribuzione di progetti di applicazioni Web sul sito Web di MSDN e Distribuzione Web: Trasformazione di Web.Config nel blog di Vishal Joshi.
Distribuzione del database
Un pacchetto di distribuzione di Visual Studio 2010 può includere dipendenze nei database di SQL Server. Come parte della definizione del pacchetto, si specifica la 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 quindi 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 si specifica una stringa di connessione appropriata 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 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.
Pubblicazione con un clic per 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 Sul Web. Con Visual Studio 2010, è anche possibile pubblicare usando la riga di comando di MSBuild. In questo modo è possibile configurare l'ambiente di compilazione del team in modo da includere la pubblicazione in un modello di integrazione continua.
Per ulteriori informazioni, vedere Procedura: Distribuire un progetto di applicazione Web usando One-Click Publish e Web Deploy sul sito Web MSDN e Web 1-Click Publish 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 sul sito Web MSDN.
- https://www.asp.net/ — Il sito Web del team ASP.NET.
- https://www.asp.net/dynamicdata/ e ASP.NET Mappa dei contenuti dati dinamici - Risorse online sul sito del team 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 per sviluppatori Visual Web, che include informazioni sulle funzionalità in Visual Studio 2010.
- ASP.NET WebStack : risorsa Web principale per le versioni di anteprima di ASP.NET.
Dichiarazione di non responsabilità
Si tratta di un documento preliminare e può essere modificato sostanzialmente prima del rilascio commerciale finale del software descritto nel presente documento.
Le informazioni contenute in questo documento rappresentano la posizione attuale di Microsoft Corporation alla data della pubblicazione rispetto alle questioni trattate. Poiché Microsoft deve rispondere alle mutevoli condizioni di mercato, non deve essere interpretato come un impegno da parte di Microsoft e Microsoft non può garantire l'accuratezza delle informazioni presentate dopo la data di pubblicazione.
Questo white paper è solo a scopo informativo. MICROSOFT NON GARANTISCE IN ALCUN MODO, ESPRESSO, IMPLICITO O A TERMINI DI LEGGE, LE INFORMAZIONI CONTENUTE NEL PRESENTE DOCUMENTO.
La conformità a tutte le leggi sul copyright applicabili è responsabilità dell'utente. Senza limitare i diritti in materia di copyright, nessuna parte di questo documento può essere riprodotta, archiviata o introdotta in un sistema di recupero o trasmessa in qualsiasi forma o tramite qualsiasi mezzo (elettronico, meccanico, di registrazione o altro) o per qualsiasi scopo, senza l'autorizzazione scritta espressa di Microsoft Corporation.
Microsoft può disporre di brevetti, domande di brevetto, marchi, copyright o altri diritti di proprietà intellettuale relativi all'oggetto in questo documento. Salvo quanto espressamente previsto in qualsiasi contratto di licenza scritto di Microsoft, la fornitura di questo documento non concede alcuna licenza su questi brevetti, marchi, copyright o altre proprietà intellettuali.
Se non diversamente specificato, le aziende di esempio, le organizzazioni, i prodotti, i nomi di dominio, gli indirizzi di posta elettronica, i logo, le persone, i luoghi e gli eventi illustrati nel presente documento sono fittizi e non è prevista alcuna associazione con alcuna società reale, organizzazione, prodotto, nome di dominio, indirizzo di posta elettronica, logo, persona, luogo o evento previsto o deve essere dedotto.
© Microsoft Corporation 2009. Tutti i diritti riservati.
Microsoft e Windows sono marchi registrati o marchi di Microsoft Corporation negli Stati Uniti e/o in altri paesi.
I nomi delle società e dei prodotti effettivi indicati nel presente documento possono essere i marchi dei rispettivi proprietari.