Übersicht über ASP.NET 4 und Visual Studio 2010 for Web Development

Dieses Dokument bietet eine Übersicht über viele der neuen Features für ASP.NET, die in the.NET Framework 4 und in Visual Studio 2010 enthalten sind.

Dieses Whitepaper herunterladen

Contents

Kerndienste
Web.config-Dateirestrukturierung
Erweiterbare Ausgabezwischenspeicherung
Webanwendungen automatisch starten
Dauerhaftes Umleiten einer Seite
Sitzungszustand verkleinern
Erweitern des Bereichs zulässiger URLs
Erweiterbare Anforderungsüberprüfung
Objektzwischenspeicherung und Erweiterbarkeit der Objektzwischenspeicherung
Erweiterbare HTML-, URL- und HTTP-Headercodierung
Leistungsüberwachung für einzelne Anwendungen in einem einzelnen Arbeitsprozess
Multi-Targeting

Ajax
jQuery in den Webformularen und im MVC enthalten
Unterstützung des Content Delivery Network
ScriptManager Explicit Scripts

Webformulare
Festlegen von Metatags mit den Eigenschaften Page.MetaKeywords und Page.MetaDescription
Aktivieren des Anzeigestatus für einzelne Steuerelemente
Änderungen an Browserfunktionen
Routing in ASP.NET 4
Festlegen von Client-IDs
Beibehalten der Zeilenauswahl in Datensteuerelementen
ASP.NET Diagrammsteuerelement
Filtern von Daten mit dem QueryExtender-Steuerelement
Html-codierte Codeausdrücke
Projektvorlagenänderungen
CSS-Verbesserungen
Ausblenden von div-Elementen um ausgeblendete Felder
Rendern einer äußeren Tabelle für Vorlagensteuerelemente
Verbesserungen des ListView-Steuerelements
Verbesserungen an den Steuerelementen CheckBoxList und RadioButtonList
Verbesserungen bei Menüsteuerelementen
Wizard und CreateUserWizard-Steuerelemente 56

ASP.NET MVC
Bereichsunterstützung
Unterstützung für die Überprüfung von Datenanmerkungsattributen
Vorlagenbasierte Hilfsfunktionen

Dynamische Daten
Aktivieren von dynamischen Daten für vorhandene Projekte
Syntax des Deklarativen DynamicDataManager-Steuerelements
Entitätsvorlagen
Neue Feldvorlagen für URLs und E-Mail-Adressen
Erstellen von Links mit dem DynamicHyperLink-Steuerelement
Unterstützung der Vererbung im Datenmodell
Unterstützung für Viele-zu-Viele-Beziehungen (ausschließlich Entity Framework)
Neue Attribute zum Steuern der Anzeige und Unterstützung von Enumerationen
Erweiterte Unterstützung für Filter

Verbesserungen bei der Webentwicklung in Visual Studio 2010
Verbesserte CSS-Kompatibilität
HTML- und JavaScript-Codeausschnitte
JavaScript IntelliSense-Verbesserungen

Webanwendungsbereitstellung mit Visual Studio 2010
Web Packaging
Web.config Transformation
Datenbankbereitstellung
Ein-Klick-Veröffentlichung für Webanwendungen
Ressourcen

Haftungsausschluss

Kerndienste

ASP.NET 4 führt eine Reihe von Features ein, die kernige ASP.NET Dienste wie Ausgabezwischenspeicherung und Sitzungszustandsspeicher verbessern.

Web.config Dateiumgestaltung

Die Web.config Datei, die die Konfiguration für eine Webanwendung enthält, ist in den letzten Versionen von .NET Framework erheblich gewachsen, da neue Features wie Ajax, Routing und Integration in IIS 7 hinzugefügt wurden. Dies hat es schwieriger gemacht, neue Webanwendungen ohne ein Tool wie Visual Studio zu konfigurieren oder zu starten. In .NET Framework 4 wurden die wichtigsten Konfigurationselemente in die machine.config Datei verschoben, und Anwendungen erben jetzt diese Einstellungen. Auf diese Weise kann die Web.config Datei in ASP.NET 4-Anwendungen entweder leer sein oder nur die folgenden Zeilen enthalten, die für Visual Studio angeben, auf welche Version des Frameworks die Anwendung ausgerichtet ist:

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

Erweiterbare Ausgabezwischenspeicherung

Seit der Veröffentlichung von ASP.NET 1.0 konnten Entwickler die generierte Ausgabe von Seiten, Steuerelementen und HTTP-Antworten im Arbeitsspeicher speichern. Bei nachfolgenden Webanforderungen kann ASP.NET Inhalte schneller bereitstellen, indem die generierte Ausgabe aus dem Speicher abgerufen wird, anstatt die Ausgabe von Grund auf neu zu generieren. Dieser Ansatz hat jedoch eine Einschränkung: Generierte Inhalte müssen immer im Arbeitsspeicher gespeichert werden, und auf Servern, auf denen ein hoher Datenverkehr auftritt, kann der von der Ausgabezwischenspeicherung verbrauchte Speicher mit den Speicheranforderungen anderer Teile einer Webanwendung konkurrieren.

ASP.NET 4 fügt einen Erweiterbarkeitspunkt zur Ausgabezwischenspeicherung hinzu, mit dem Sie einen oder mehrere benutzerdefinierte Ausgabecacheanbieter konfigurieren können. Ausgabecacheanbieter können einen beliebigen Speichermechanismus verwenden, um HTML-Inhalte beizubehalten. Dadurch können benutzerdefinierte Ausgabecacheanbieter für verschiedene Persistenzmechanismen erstellt werden, die lokale oder Remotedatenträger, Cloudspeicher und verteilte Cachemodule umfassen können.

Sie erstellen einen benutzerdefinierten Ausgabecacheanbieter als Klasse, die vom neuen Typ "System.Web.Caching.OutputCacheProvider " abgeleitet ist. Anschließend können Sie den Anbieter in der Web.config Datei mithilfe des neuen Anbieterunterabschnitts des outputCache-Elements konfigurieren, wie im folgenden Beispiel gezeigt:

<caching>
  <outputCache defaultProvider="AspNetInternalProvider">
    <providers>
      <add name="DiskCache"
          type="Test.OutputCacheEx.DiskOutputCacheProvider, DiskCacheProvider"/>
    </providers>
  </outputCache>

</caching>

Standardmäßig verwenden in ASP.NET 4 alle HTTP-Antworten, gerenderten Seiten und Steuerelemente den Speicherausgabecache, wie im vorherigen Beispiel gezeigt, wobei das defaultProvider-Attribut auf AspNetInternalProvider festgelegt ist. Sie können den für eine Webanwendung verwendeten Standardausgabecacheanbieter ändern, indem Sie einen anderen Anbieternamen für defaultProvider angeben.

Darüber hinaus können Sie unterschiedliche Ausgabecacheanbieter pro Steuerelement und pro Anforderung auswählen. Am einfachsten können Sie einen anderen Ausgabecacheanbieter für verschiedene Webbenutzersteuerelemente auswählen, indem Sie das neue providerName-Attribut in einer Steuerelementdirektive deklarativ verwenden, wie im folgenden Beispiel gezeigt:

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

Das Angeben eines anderen Ausgabecacheanbieters für eine HTTP-Anforderung erfordert etwas mehr Arbeit. Anstatt den Anbieter deklarativ anzugeben, überschreiben Sie die neue GetOuputCacheProviderName-Methode in der Global.asax Datei, um programmgesteuert anzugeben, welcher Anbieter für eine bestimmte Anforderung verwendet werden soll. Das folgende Beispiel zeigt, wie dies funktioniert.

public override string GetOutputCacheProviderName(HttpContext context)
{
    if (context.Request.Path.EndsWith("Advanced.aspx"))
       return "DiskCache";
    else
        return base.GetOutputCacheProviderName(context);
}

Mit der Erweiterbarkeit des Ausgabecache-Anbieters in ASP.NET 4 können Sie jetzt aggressivere und intelligentere Strategien zur Ausgabezwischenspeicherung für Ihre Websites verfolgen. Beispielsweise ist es jetzt möglich, die "Top 10"-Seiten einer Website im Arbeitsspeicher zwischenzuspeichern, während Seiten zwischengespeichert werden, die niedrigeren Datenverkehr auf dem Datenträger erhalten. Alternativ können Sie jede unterschiedliche Kombination für eine gerenderte Seite zwischenspeichern, aber einen verteilten Cache verwenden, damit der Speicherverbrauch von Front-End-Webservern entladen wird.

Webanwendungen automatisch starten

Einige Webanwendungen müssen große Datenmengen laden oder eine teure Initialisierungsverarbeitung durchführen, bevor die erste Anforderung verarbeitet wird. In früheren Versionen von ASP.NET mussten Sie für diese Situationen benutzerdefinierte Ansätze zum "Aufwachen" einer ASP.NET Anwendung entwickeln und dann initialisierungscode während der Application_Load-Methode in der Global.asax Datei ausführen.

Ein neues Skalierbarkeitsfeature namens "Automatischer Start", das dieses Szenario direkt adressiert, ist verfügbar, wenn ASP.NET 4 auf IIS 7.5 unter Windows Server 2008 R2 läuft. Das Feature für den automatischen Start bietet einen kontrollierten Ansatz zum Starten eines Anwendungspools, initialisieren einer ASP.NET Anwendung und akzeptiert dann HTTP-Anforderungen.

Hinweis

IIS-Anwendungsmodul Warm-Up für IIS 7.5

Das IIS-Team hat die erste Betatestversion des Application Warm-Up Module für IIS 7.5 veröffentlicht. Dies macht das Aufwärmen Ihrer Anwendungen noch einfacher als zuvor beschrieben. Anstatt benutzerdefinierten Code zu schreiben, geben Sie die URLs der auszuführenden Ressourcen an, bevor die Webanwendung Anforderungen aus dem Netzwerk akzeptiert. Diese Aufwärmung erfolgt beim Starten des IIS-Diensts (wenn Sie den IIS-Anwendungspool als AlwaysRunning konfiguriert haben) und wenn ein IIS-Arbeitsprozess wiederverwendet wird. Während des Wiederverwendungsvorgangs führt der alte IIS-Arbeitsprozess weiterhin Anforderungen aus, bis der neu erstellte Arbeitsprozess vollständig aufgewärmt ist, sodass Anwendungen aufgrund von nicht komprimierten Caches keine Unterbrechungen oder andere Probleme haben. Beachten Sie, dass dieses Modul mit jeder Version von ASP.NET funktioniert, beginnend mit Version 2.0.

Weitere Informationen finden Sie unter Anwendungsaufwärmung auf der IIS.net-Website. Eine exemplarische Vorgehensweise, die die Verwendung des Warmupfeatures veranschaulicht, finden Sie unter "Erste Schritte mit dem IIS 7.5 Application Warm-Up Module " auf der IIS.net-Website.

Um das Feature für den automatischen Start zu verwenden, legt ein IIS-Administrator einen Anwendungspool in IIS 7.5 so fest, dass er automatisch gestartet wird, indem die folgende Konfiguration in der applicationHost.config Datei verwendet wird:

<applicationpools>
  <add name="MyApplicationPool" startMode="AlwaysRunning" />
</applicationpools>

Da ein einzelner Anwendungspool mehrere Anwendungen enthalten kann, geben Sie an, dass einzelne Anwendungen automatisch gestartet werden sollen, indem Sie die folgende Konfiguration in der applicationHost.config Datei verwenden:

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

Wenn ein IIS 7.5-Server kalt gestartet wird oder ein einzelner Anwendungspool wiederverwendet wird, verwendet IIS 7.5 die Informationen in der applicationHost.config Datei, um zu ermitteln, welche Webanwendungen automatisch gestartet werden müssen. Für jede Anwendung, die für den automatischen Start markiert ist, sendet IIS7.5 eine Anforderung an ASP.NET 4, um die Anwendung in einem Zustand zu starten, in dem die Anwendung vorübergehend keine HTTP-Anforderungen akzeptiert. In diesem Zustand instanziiert ASP.NET den vom Attribut "serviceAutoStartProvider " definierten Typ (wie im vorherigen Beispiel gezeigt) und ruft den öffentlichen Einstiegspunkt auf.

Sie erstellen einen verwalteten Autostarttyp mit dem erforderlichen Einstiegspunkt, indem Sie die IProcessHostPreloadClient-Schnittstelle implementieren, wie im folgenden Beispiel gezeigt:

public class CustomInitialization : System.Web.Hosting.IProcessHostPreloadClient
{
    public void Preload(string[] parameters)
    {
        // Perform initialization. 
    }
}

Nachdem der Initialisierungscode in der Preload-Methode ausgeführt und die Methode zurückgegeben wird, kann die ASP.NET Anwendung Anforderungen verarbeiten.

Mit dem Hinzufügen des automatischen Starts zu IIS .5 und ASP.NET 4 haben Sie jetzt einen gut definierten Ansatz für die Durchführung einer kostspieligen Anwendungsinitialisierung vor der Verarbeitung der ersten HTTP-Anforderung. Sie können z. B. das neue Feature für den automatischen Start verwenden, um eine Anwendung zu initialisieren und dann ein Lastenausgleichsmodul zu signalisieren, dass die Anwendung initialisiert und bereit ist, HTTP-Datenverkehr zu akzeptieren.

Dauerhaftes Umleiten einer Seite

In Webanwendungen ist es üblich, Seiten und andere Inhalte im Laufe der Zeit zu verschieben, was zu einer Anhäufung veralteter Links in Suchmaschinen führen kann. In ASP.NET haben Entwickler herkömmliche Anforderungen an alte URLs mithilfe der Response.Redirect-Methode verarbeitet, um eine Anforderung an die neue URL weiterzuleiten. Die Redirect-Methode gibt jedoch eine HTTP 302 Found -Antwort (temporäre Umleitung ) aus, was zu einem zusätzlichen HTTP-Roundtrip führt, wenn Benutzer versuchen, auf die alten URLs zuzugreifen.

ASP.NET 4 fügt eine neue RedirectPermanent-Hilfsmethode hinzu, mit der HTTP 301 Moved Permanent-Antworten problemlos ausstellen können, wie im folgenden Beispiel gezeigt:

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

Suchmaschinen und andere User Agents, die permanente Umleitungen erkennen, speichern die neue URL, die dem Inhalt zugeordnet ist, wodurch die unnötigen Roundtrips, die der Browser bei temporären Umleitungen macht, vermieden werden.

Verkleinern des Sitzungszustands

ASP.NET bietet zwei Standardoptionen zum Speichern des Sitzungszustands in einer Webfarm: ein Sitzungsstatusanbieter, der einen Out-of-Process-Sitzungszustandsserver aufruft, und ein Sitzungsstatusanbieter, der Daten in einer Microsoft SQL Server-Datenbank speichert. Da beide Optionen das Speichern von Statusinformationen außerhalb des Arbeitsprozesses einer Webanwendung umfassen, muss der Sitzungszustand serialisiert werden, bevor er an den Remotespeicher gesendet wird. Je nachdem, wie viele Informationen ein Entwickler im Sitzungszustand speichert, kann die Größe der serialisierten Daten ziemlich groß werden.

ASP.NET 4 führt eine neue Komprimierungsoption für beide Arten von Out-of-Process-Sitzungszustandsanbietern ein. Wenn die im folgenden Beispiel gezeigte Konfigurationsoption compressionEnabled auf true festgelegt ist, wird der serialisierte Sitzungsstatus von ASP.NET mithilfe der .NET-Framework-System.IO.Compression.GZipStream-Klasse komprimiert und dekomprimiert.

<sessionState
  mode="SqlServer"
  sqlConnectionString="data source=dbserver;Initial Catalog=aspnetstate"
  allowCustomSqlDatabase="true"
  compressionEnabled="true"
/>

Mit dem einfachen Hinzufügen des neuen Attributs zu der Web.config Datei können Anwendungen mit ersatzbasierten CPU-Zyklen auf Webservern erhebliche Reduzierungen der Größe serialisierter Sitzungszustandsdaten erzielen.

Erweitern des Bereichs zulässiger URLs

ASP.NET 4 führt neue Optionen zum Erweitern der Größe von Anwendungs-URLs ein. Frühere Versionen von ASP.NET beschränkten die URL-Pfadlängen auf 260 Zeichen, basierend auf der NTFS-Dateipfadbeschränkung. In ASP.NET 4 haben Sie die Möglichkeit, diesen Grenzwert je nach Bedarf für Ihre Anwendungen mit zwei neuen httpRuntime-Konfigurationsattributen zu erhöhen (oder zu verringern). Das folgende Beispiel zeigt diese neuen Attribute.

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

Um längere oder kürzere Pfade zuzulassen (der Teil der URL, der nicht Protokoll, Servername und Abfragezeichenfolge enthält), ändern Sie das attribut "maxUrlLength ". Um längere oder kürzere Abfragezeichenfolgen zuzulassen, ändern Sie den Wert des maxQueryStringLength-Attributs .

mit ASP.NET 4 können Sie auch die Zeichen konfigurieren, die von der URL-Zeichenprüfung verwendet werden. Wenn ASP.NET ein ungültiges Zeichen im Pfadteil einer URL findet, wird die Anforderung abgelehnt und ein HTTP 400-Fehler ausgegeben. In früheren Versionen von ASP.NET waren die URL-Zeichenprüfungen auf einen festen Satz von Zeichen beschränkt. In ASP.NET 4 können Sie den Satz gültiger Zeichen mithilfe des neuen requestPathInvalidCharacters-Attributs des httpRuntime-Konfigurationselements anpassen, wie im folgenden Beispiel gezeigt:

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

Standardmäßig definiert das requestPathInvalidCharacters-Attribut acht Zeichen als ungültig. (In der Zeichenfolge, die requestPathInvalidCharacters standardmäßig zugewiesen ist, werden die Zeichen kleiner Zeichen (<), größer Zeichen (>) und Et-Zeichen (&) codiert, da es sich bei der Web.config Datei um eine XML-Datei handelt.) Sie können den Satz ungültiger Zeichen nach Bedarf anpassen.

Hinweis

Hinweis: ASP.NET 4 lehnt immer URL-Pfade ab, die Zeichen im ASCII-Bereich von 0x00 bis 0x1F enthalten, da es sich um ungültige URL-Zeichen handelt, wie in RFC 2396 der IETF definiert (http://www.ietf.org/rfc/rfc2396.txt). In Versionen von Windows Server, die IIS 6 oder höher ausführen, lehnt der http.sys Protokollgerätetreiber URLs mit diesen Zeichen automatisch ab.

Erweiterbare Anforderungsüberprüfung

ASP.NET Anforderungsüberprüfung durchsucht eingehende HTTP-Anforderungsdaten nach Zeichenfolgen, die häufig in XSS-Angriffen (Cross-Site Scripting) verwendet werden. Wenn potenzielle XSS-Zeichenfolgen gefunden werden, kennzeichnet die Anforderungsüberprüfung die verdächtige Zeichenfolge und gibt einen Fehler zurück. Die integrierte Anforderungsüberprüfung gibt nur dann einen Fehler zurück, wenn sie die gängigsten Zeichenfolgen findet, die in XSS-Angriffen verwendet werden. Vorherige Versuche, die XSS-Validierung aggressiver zu machen, führte zu zu vielen falsch positiven Ergebnissen. Kunden möchten möglicherweise jedoch eine aggressivere Validierung von Anfragen oder andererseits die XSS-Prüfungen für bestimmte Seiten oder bestimmte Anfragetypen absichtlich lockern.

In ASP.NET 4 wurde das Anforderungsüberprüfungsfeature erweiterbar, sodass Sie benutzerdefinierte Anforderungsüberprüfungslogik verwenden können. Um die Anforderungsüberprüfung zu erweitern, erstellen Sie eine Klasse, die vom neuen System.Web.Util.RequestValidator-Typ abgeleitet wird, und Sie konfigurieren die Anwendung (im Abschnitt "httpRuntime " der Web.config Datei), um den benutzerdefinierten Typ zu verwenden. Das folgende Beispiel zeigt, wie Sie eine benutzerdefinierte Anforderungsüberprüfungsklasse konfigurieren:

<httpRuntime requestValidationType="Samples.MyValidator, Samples" />

Das neue requestValidationType-Attribut erfordert eine standardmäßige .NET Framework-Typbezeichnerzeichenfolge, die die Klasse angibt, die eine benutzerdefinierte Anforderungsüberprüfung bereitstellt. Für jede Anforderung ruft ASP.NET den benutzerdefinierten Typ auf, um jeden Teil eingehender HTTP-Anforderungsdaten zu verarbeiten. Die eingehende URL, alle HTTP-Header (sowohl Cookies als auch benutzerdefinierte Header) und der Entitätstext sind alle für die Überprüfung durch eine benutzerdefinierte Anforderungsüberprüfungsklasse verfügbar, wie im folgenden Beispiel gezeigt:

public class CustomRequestValidation : RequestValidator
{
    protected override bool IsValidRequestString(
      HttpContext context, string value, 
      RequestValidationSource requestValidationSource, 
      string collectionKey, 
      out int validationFailureIndex) 
    {...}
 }

In Fällen, in denen Sie keine eingehenden HTTP-Daten überprüfen möchten, kann die Anforderungsüberprüfungsklasse darauf zurückgreifen, dass die standardmäßige ASP.NET-Anforderungsvalidierung ausgeführt wird, indem Sie einfach die Basis.IsValidRequestString aufrufen.

Objektzwischenspeicherung und Erweiterbarkeit der Objektzwischenspeicherung

Seit der ersten Version enthält ASP.NET einen leistungsfähigen Cache für Speicherobjekte (System.Web.Caching.Cache). Die Cacheimplementierung wurde so beliebt, dass sie in Nicht-Webanwendungen verwendet wurde. Allerdings ist es für eine Windows Forms- oder WPF-Anwendung ungünstig, einen Verweis auf System.Web.dll einzuschließen, nur um den ASP.NET-Objektcache verwenden zu können.

Um die Zwischenspeicherung für alle Anwendungen verfügbar zu machen, führt .NET Framework 4 eine neue Assembly, einen neuen Namespace, einige Basistypen und eine konkrete Zwischenspeicherungsimplementierung ein. Die neue System.Runtime.Caching.dll Assembly enthält eine neue Cache-API im System.Runtime.Caching-Namespace . Der Namespace enthält zwei Kerngruppen von Klassen:

• Abstrakte Typen, die die Grundlage für die Erstellung eines beliebigen Typs benutzerdefinierter Cacheimplementierung bieten.
• Eine konkrete In-Memory-Objektcacheimplementierung (die System.Runtime.Caching.MemoryCache-Klasse ).

Die neue MemoryCache-Klasse wird eng auf den ASP.NET Cache modelliert und teilt einen Großteil der internen Cachemodullogik mit ASP.NET. Obwohl die öffentlichen Cache-APIs in System.Runtime.Caching aktualisiert wurden, um die Entwicklung von benutzerdefinierten Caches zu unterstützen, finden Sie bei Verwendung des ASP.NET Cache-Objekts vertraute Konzepte in den neuen APIs.

Eine ausführliche Erläuterung der neuen MemoryCache-Klasse und der unterstützenden Basis-APIs erfordern ein gesamtes Dokument. Im folgenden Beispiel erhalten Sie jedoch eine Vorstellung davon, wie die neue Cache-API funktioniert. Das Beispiel wurde für eine Windows Forms-Anwendung ohne Abhängigkeit System.Web.dllgeschrieben.

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); 
}

Erweiterbare HTML-, URL- und HTTP-Headercodierung

In ASP.NET 4 können Sie benutzerdefinierte Codierungsroutinen für die folgenden gängigen Textcodierungsaufgaben erstellen:

• HTML-Codierung.
• URL-Codierung.
• HTML-Attributcodierung.
• Codieren ausgehender HTTP-Header.

Sie können einen benutzerdefinierten Encoder erstellen, indem Sie den neuen System.Web.Util.HttpEncoder-Typ ableiten und dann ASP.NET konfigurieren, um den benutzerdefinierten Typ im Abschnitt "httpRuntime " der Web.config Datei zu verwenden, wie im folgenden Beispiel gezeigt:

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

Nachdem ein benutzerdefinierter Encoder konfiguriert wurde, ruft ASP.NET die benutzerdefinierte Codierungsimplementierung automatisch auf, wenn öffentliche Codierungsmethoden der Klassen System.Web.HttpUtility oder System.Web.HttpServerUtility aufgerufen werden. Auf diese Weise kann ein Teil eines Webentwicklungsteams einen benutzerdefinierten Encoder erstellen, der aggressive Zeichencodierung implementiert, während der Rest des Webentwicklungsteams weiterhin die öffentlichen ASP.NET Codierungs-APIs verwendet. Durch die zentrale Konfiguration eines benutzerdefinierten Encoders im httpRuntime-Element stellen Sie sicher, dass alle Textcodierungsaufrufe aus den öffentlichen ASP.NET-Codierungs-APIs über den benutzerdefinierten Encoder weitergeleitet werden.

Leistungsüberwachung für einzelne Anwendungen in einem einzelnen Arbeitsprozess

Um die Anzahl der Websites zu erhöhen, die auf einem einzelnen Server gehostet werden können, führen viele Hoster mehrere ASP.NET Anwendungen in einem einzigen Arbeitsprozess aus. Wenn jedoch mehrere Anwendungen einen einzelnen freigegebenen Arbeitsprozess verwenden, ist es für Serveradministratoren schwierig, eine einzelne Anwendung zu identifizieren, die Probleme hat.

ASP.NET 4 nutzt neue Funktionen zur Ressourcenüberwachung, die von der CLR eingeführt wurden. Um diese Funktionalität zu aktivieren, können Sie der aspnet.config Konfigurationsdatei den folgenden XML-Konfigurationsausschnitt hinzufügen.

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

</configuration>

Hinweis

Hinweis: Die aspnet.config Datei befindet sich im Verzeichnis, in dem .NET Framework installiert ist. Es handelt sich nicht um die Web.config Datei.

Wenn das Feature "appDomainResourceMonitoring " aktiviert wurde, stehen zwei neue Leistungsindikatoren in der Leistungskategorie "ASP.NET Anwendungen" zur Verfügung: % Verwaltete Prozessorzeit und verwendeter verwalteter Arbeitsspeicher. Beide Leistungsindikatoren verwenden das neue Feature für die Ressourcenverwaltung von CLR-Anwendungen, um die geschätzte CPU-Zeit und die verwaltete Speicherauslastung einzelner ASP.NET Anwendungen nachzuverfolgen. Daher haben Administratoren mit ASP.NET 4 nun einen genaueren Überblick über den Ressourcenverbrauch einzelner Anwendungen, die in einem einzigen Arbeitsprozess ausgeführt werden.

Multi-Targeting

Sie können eine Anwendung erstellen, die auf eine bestimmte Version von .NET Framework abzielt. In ASP.NET 4 können Sie mit einem neuen Attribut im Kompilierungselement der Web.config Datei auf .NET Framework 4 und höher abzielen. Wenn Sie explizit auf .NET Framework 4 abzielen und optionale Elemente in die Web.config Datei einschließen, z. B. die Einträge für system.codedom, müssen diese Elemente für .NET Framework 4 korrekt sein. (Wenn Sie nicht explizit auf .NET Framework 4 abzielen, wird das Zielframework aus dem Fehlenden eines Eintrags in der Web.config Datei abgeleitet.)

Das folgende Beispiel zeigt die Verwendung des targetFramework-Attributs im Kompilierungselement der Web.config Datei.

<compilation targetFramework="4.0"/>

Beachten Sie Folgendes zur Ausrichtung auf eine bestimmte Version des .NET Framework:

• In einem .NET Framework 4-Anwendungspool setzt das ASP.NET Buildsystem das .NET Framework 4 als Ziel voraus, wenn die Web.config Datei nicht das targetFramework-Attribut enthält oder die Web.config Datei fehlt. (Möglicherweise müssen Sie Codierungsänderungen an Ihrer Anwendung vornehmen, um sie unter .NET Framework 4 auszuführen.)
• Wenn Sie das targetFramework-Attribut einschließen und das System.codeDom-Element in der Web.config Datei definiert ist, muss diese Datei die richtigen Einträge für .NET Framework 4 enthalten.
• Wenn Sie den Befehl aspnet_compiler verwenden, um Ihre Anwendung (z. B. in einer Buildumgebung) vorkompilieren zu können, müssen Sie die richtige Version des Befehls aspnet_compiler für das Zielframework verwenden. Verwenden Sie den Compiler, der mit .NET Framework 2.0 ausgeliefert wurde (%WINDIR%\Microsoft.NET\Framework\v2.0.50727), um für .NET Framework 3.5 und frühere Versionen zu kompilieren. Verwenden Sie den Compiler, der im Lieferumfang von .NET Framework 4 enthalten ist, um Anwendungen zu kompilieren, die mit diesem Framework oder mit höheren Versionen erstellt wurden.
• Zur Laufzeit verwendet der Compiler die neuesten Frameworkassemblys, die auf dem Computer (und daher im GAC) installiert sind. Wenn später ein Update am Framework vorgenommen wird (z. B. wird eine hypothetische Version 4.1 installiert), können Sie Features in der neueren Version des Frameworks verwenden, obwohl das targetFramework-Attribut auf eine niedrigere Version (z. B. 4.0) abzielt. (Zur Entwurfszeit in Visual Studio 2010 oder wenn Sie den befehl aspnet_compiler verwenden, führt die Verwendung neuerer Features des Frameworks jedoch zu Compilerfehlern).

Ajax

jQuery enthalten in Webformularen und MVC

Die Visual Studio-Vorlagen für Webformulare und MVC enthalten die Open-Source-jQuery-Bibliothek. Wenn Sie eine neue Website oder ein neues Projekt erstellen, wird ein Skriptordner mit den folgenden 3 Dateien erstellt:

• jQuery-1.4.1.js – Die menschenlesbare, nicht-minifizierte Version der jQuery-Bibliothek.
• jQuery-14.1.min.js – Die minimierte Version der jQuery-Bibliothek.
• jQuery-1.4.1-vsdoc.js – Die IntelliSense-Dokumentationsdatei für die jQuery-Bibliothek.

Schließen Sie die nichtminifizierte Version von jQuery beim Entwickeln einer Anwendung ein. Schließen Sie die minimierte Version von jQuery für Produktionsanwendungen ein.

Die folgende Web forms-Seite veranschaulicht beispielsweise, wie Sie jQuery verwenden können, um die Hintergrundfarbe von ASP.NET TextBox-Steuerelementen gelb zu ändern, wenn sie den Fokus haben.

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

Unterstützung des Content Delivery Network

Mit dem Microsoft Ajax Content Delivery Network (CDN) können Sie Ihren Webanwendungen problemlos ASP.NET Ajax- und jQuery-Skripts hinzufügen. Sie können beispielsweise mit der Verwendung der jQuery-Bibliothek beginnen, indem Sie ihrer Seite einfach ein <script> Tag hinzufügen, das auf Ajax.microsoft.com wie folgt verweist:

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

Durch die Nutzung des Microsoft Ajax CDN können Sie die Leistung Ihrer Ajax-Anwendungen erheblich verbessern. Der Inhalt des Microsoft Ajax CDN wird auf Servern auf der ganzen Welt zwischengespeichert. Darüber hinaus ermöglicht das Microsoft Ajax CDN browsern, zwischengespeicherte JavaScript-Dateien für Websites wiederzuverwenden, die sich in verschiedenen Domänen befinden.

Das Microsoft Ajax Content Delivery Network unterstützt SSL (HTTPS), falls Sie eine Webseite mithilfe der Secure Sockets Layer bereitstellen müssen.

Implementieren Sie einen Fallback, wenn das CDN nicht verfügbar ist. Testen Sie den Fallback.

Weitere Informationen zum Microsoft Ajax CDN finden Sie auf der folgenden Website:

https://www.asp.net/ajaxlibrary/CDN.ashx

Der ASP.NET ScriptManager unterstützt das Microsoft Ajax CDN. Indem Sie einfach die EnableCdn-Eigenschaft festlegen, können Sie alle JavaScript-Dateien des ASP.NET-Frameworks vom CDN abrufen.

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

Nachdem Sie die EnableCdn-Eigenschaft auf den Wert "true" festgelegt haben, ruft das ASP.NET-Framework alle ASP.NET Framework-JavaScript-Dateien aus dem CDN ab, einschließlich aller JavaScript-Dateien, die für die Überprüfung und das UpdatePanel verwendet werden. Das Festlegen dieser eigenschaft kann eine dramatische Auswirkung auf die Leistung Ihrer Webanwendung haben.

Sie können den CDN-Pfad für Ihre eigenen JavaScript-Dateien mithilfe des WebResource-Attributs festlegen. Die neue CdnPath-Eigenschaft gibt den Pfad zum CDN an, der verwendet wird, wenn Sie die EnableCdn-Eigenschaft auf den Wert true festlegen:

[assembly: WebResource("Foo.js", "application/x-javascript", CdnPath = "http://foo.com/foo/bar/foo.js")]

ScriptManager Explizite Skripte

Wenn Sie in der Vergangenheit die ASP.NET ScriptManger verwendet haben, mussten Sie die gesamte monolithische ASP.NET Ajax Library laden. Durch die Nutzung der neuen ScriptManager.AjaxFrameworkMode-Eigenschaft können Sie genau steuern, welche Komponenten der ASP.NET Ajax-Bibliothek geladen und nur die Komponenten der benötigten ASP.NET Ajax-Bibliothek geladen werden.

Die ScriptManager.AjaxFrameworkMode-Eigenschaft kann auf die folgenden Werte festgelegt werden:

• Enabled -- Gibt an, dass das ScriptManager-Steuerelement automatisch die MicrosoftAjax.js Skriptdatei enthält, bei der es sich um eine kombinierte Skriptdatei jedes Core-Framework-Skripts (Legacyverhalten) handelt.
• Disabled -- Gibt an, dass alle Microsoft Ajax-Skriptfeatures deaktiviert sind und dass das ScriptManager-Steuerelement nicht automatisch auf Skripts verweist.
• Explicit -- Gibt an, dass Sie explizit Skriptverweise auf einzelne Framework-Kernskriptdatei einschließen, die Ihre Seite erfordert, und dass Sie Verweise auf die Abhängigkeiten einschließen, die für jede Skriptdatei erforderlich sind.

Wenn Sie beispielsweise die AjaxFrameworkMode-Eigenschaft auf den Wert Explicit festlegen, können Sie die speziellen ASP.NET Ajax-Komponentenskripts angeben, die Sie benötigen:

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

Webformulare

Web Forms ist seit der Veröffentlichung von ASP.NET 1.0 ein Kernfeature in ASP.NET. Es wurden viele Verbesserungen in diesem Bereich für ASP.NET 4 vorgenommen, unter anderem:

• Die Möglichkeit zum Festlegen von Metatags .
• Mehr Kontrolle über den Ansichtszustand.
• Einfachere Möglichkeiten zum Arbeiten mit Browserfunktionen.
• Unterstützung für die Verwendung von ASP.NET Routing mit WebFormularen.
• Mehr Kontrolle über generierte IDs.
• Die Möglichkeit, ausgewählte Zeilen in Datensteuerelementen beizubehalten.
• Mehr Kontrolle über gerenderte HTML in den FormView - und ListView-Steuerelementen .
• Filterunterstützung für Datenquellensteuerelemente.

Festlegen von Metatags mit den Eigenschaften Page.MetaKeywords und Page.MetaDescription

ASP.NET 4 fügt der Page-Klasse , MetaKeywords und MetaDescription zwei Eigenschaften hinzu. Diese beiden Eigenschaften stellen entsprechende Metatags auf Ihrer Seite dar, wie im folgenden Beispiel gezeigt:

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

Diese beiden Eigenschaften funktionieren auf die gleiche Weise wie die Title-Eigenschaft der Seite. Sie befolgen die folgenden Regeln:

1. Wenn im Head-Element keine Metatags vorhanden sind, die den Eigenschaftennamen entsprechen (d. h. name="keywords" für Page.MetaKeywords und name="description" für Page.MetaDescription, d. h., dass diese Eigenschaften nicht festgelegt wurden), werden die Metatags der Seite hinzugefügt, wenn sie gerendert wird.
2. Wenn bereits Metatags mit diesen Namen vorhanden sind, dienen diese Eigenschaften als Get- und Set-Methoden für den Inhalt der vorhandenen Tags.

Sie können diese Eigenschaften zur Laufzeit festlegen, wodurch Sie den Inhalt aus einer Datenbank oder einer anderen Quelle abrufen können und mit denen Sie die Tags dynamisch festlegen können, um zu beschreiben, wofür eine bestimmte Seite verwendet wird.

Sie können die Schlüsselwörter und Beschreibungseigenschaften auch in der @Page-Direktive oben im Web Forms-Seitenmarkup festlegen, wie im folgenden Beispiel gezeigt:

<%@ Page Language="C#" AutoEventWireup="true" 
  CodeFile="Default.aspx.cs" 
  Inherits="_Default" 
  Keywords="These, are, my, keywords" 
  Description="This is a description" %>

Dadurch wird der Inhalt des Meta-Tags, sofern vorhanden, der bereits auf der Seite deklariert ist, überschrieben.

Die Inhalte des Beschreibungsmetatags werden zur Verbesserung der Vorschau von Suchauflistungen in Google verwendet. (Ausführliche Informationen finden Sie unter Verbessern von Codeausschnitten mit einer Metabeschreibungs-Makeover im Google Webmaster Central-Blog.) Google und Windows Live Search verwenden nicht die Inhalte der Schlüsselwörter für alles, aber andere Suchmaschinen können.

Diese neuen Eigenschaften sind eine einfache Funktion, aber sie ersparen Ihnen die Notwendigkeit, diese manuell hinzuzufügen oder Ihren eigenen Code zum Erstellen der Metatags zu schreiben.

Aktivieren des Ansichtszustands für einzelne Steuerelemente

Standardmäßig ist der Ansichtszustand für die Seite aktiviert, mit dem Ergebnis, dass jedes Steuerelement auf der Seite den Ansichtszustand möglicherweise speichert, auch wenn es für die Anwendung nicht erforderlich ist. Ansichtsstatusdaten sind im Markup enthalten, das eine Seite generiert, und erhöhen die benötigte Zeit, um eine Seite an den Client zu senden und sie zurückzusenden. Das Speichern von mehr View-Zustand als notwendig kann zu einer erheblichen Leistungsbeeinträchtigung führen. In früheren Versionen von ASP.NET konnten Entwickler den Ansichtszustand für einzelne Steuerelemente deaktivieren, um die Seitengröße zu verringern, mussten dies jedoch explizit für einzelne Steuerelemente tun. In ASP.NET 4 enthalten Webserversteuerelemente eine ViewStateMode-Eigenschaft , mit der Sie den Ansichtszustand standardmäßig deaktivieren und dann nur für die Steuerelemente aktivieren können, die sie auf der Seite benötigen.

Die ViewStateMode-Eigenschaft verwendet eine Aufzählung mit drei Werten: Enabled, Disabled und Inherit. Aktiviert den Ansichtszustand für dieses Steuerelement und für alle untergeordneten Steuerelemente, die auf "Erben" festgelegt sind oder für die nichts festgelegt ist. Deaktiviert deaktiviert den Ansichtszustand, und Inherit gibt an, dass das Steuerelement die ViewStateMode-Einstellung aus dem übergeordneten Steuerelement verwendet.

Das folgende Beispiel zeigt, wie die ViewStateMode-Eigenschaft funktioniert. Das Markup und der Code für die Steuerelemente auf der folgenden Seite enthalten Werte für die ViewStateMode-Eigenschaft :

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

Wie Sie sehen können, deaktiviert der Code den Ansichtszustand für das PlaceHolder1-Steuerelement. Das untergeordnete Label1-Steuerelement erbt diesen Eigenschaftswert (Inherit ist der Standardwert für ViewStateMode für Steuerelemente.) und speichert daher keinen Ansichtszustand. Im PlaceHolder2-Steuerelement ist ViewStateMode auf Enabled gesetzt, sodass label2 diese Eigenschaft erbt und den View-Zustand speichert. Wenn die Seite zum ersten Mal geladen wird, wird die Text-Eigenschaft beider Label-Steuerelemente auf die Zeichenfolge "[DynamicValue]" festgelegt.

Die Auswirkung dieser Einstellungen besteht darin, dass beim ersten Laden der Seite die folgende Ausgabe im Browser angezeigt wird:

Deaktiviert : [DynamicValue]

Aktiviert:[DynamicValue]

Nach einem Postback wird jedoch die folgende Ausgabe angezeigt:

Deaktiviert : [DeclaredValue]

Aktiviert:[DynamicValue]

Das Label1-Steuerelement (dessen ViewStateMode-Wert auf "Disabled" festgelegt ist) hat den Wert, auf den es im Code festgelegt wurde, nicht beibehalten. Das Label2-Steuerelement (dessen ViewStateMode-Wert auf "Enabled" festgelegt ist) hat den Status jedoch beibehalten.

Sie können ViewStateMode auch in der @Page-Direktive festlegen, wie im folgenden Beispiel gezeigt:

<%@ Page Language="C#" AutoEventWireup="true" 
  CodeBehind="Default.aspx.cs" 
  Inherits="WebApplication1._Default" 
  ViewStateMode="Disabled" %>

Die Page-Klasse ist nur ein anderes Steuerelement; sie fungiert als übergeordnetes Steuerelement für alle anderen Steuerelemente auf der Seite. Der Standardwert von ViewStateMode ist für Instanzen von Pageaktiviert. Da Steuerelemente standardmäßig auf erben eingestellt sind, übernehmen sie den Wert der Enabled-Eigenschaft, es sei denn, Sie legen ViewStateMode auf Seiten- oder Steuerelementebene fest.

Der Wert der ViewStateMode-Eigenschaft bestimmt, ob der Ansichtszustand nur beibehalten wird, wenn die EnableViewState-Eigenschaft auf "true" festgelegt ist. Wenn die EnableViewState-Eigenschaft auf "false" festgelegt ist, wird der Ansichtszustand nicht beibehalten, auch wenn ViewStateMode auf "Enabled" festgelegt ist.

Eine gute Verwendung für dieses Feature ist mit ContentPlaceHolder-Steuerelementen in Masterseiten, in denen Sie ViewStateMode für die Masterseite auf Disabled festlegen und es dann einzeln für ContentPlaceHolder-Steuerelemente aktivieren können, die wiederum Steuerelemente enthalten, die den View State erfordern.

Änderungen an Browserfunktionen

ASP.NET bestimmt die Funktionen des Browsers, die ein Benutzer zum Durchsuchen Ihrer Website verwendet, indem ein Feature namens Browserfunktionen verwendet wird. Browserfunktionen werden durch das HttpBrowserCapabilities-Objekt dargestellt (verfügbar gemacht durch die Request.Browser-Eigenschaft ). Sie können z. B. das HttpBrowserCapabilities-Objekt verwenden, um zu bestimmen, ob der Typ und die Version des aktuellen Browsers eine bestimmte Version von JavaScript unterstützt. Sie können auch das HttpBrowserCapabilities-Objekt verwenden, um zu bestimmen, ob die Anforderung von einem mobilen Gerät stammt.

Das HttpBrowserCapabilities-Objekt wird durch eine Reihe von Browserdefinitionsdateien gesteuert. Diese Dateien enthalten Informationen zu den Funktionen bestimmter Browser. In ASP.NET 4 wurden diese Browserdefinitionsdateien aktualisiert, um Informationen über kürzlich eingeführte Browser und Geräte wie Google Chrome, Research in Motion BlackBerry Smartphones und Apple iPhone zu enthalten.

Die folgende Liste zeigt neue Browserdefinitionsdateien:

• blackberry.browser
• chrome.browser
• Default.browser
• firefox.browser
• gateway.browser
• generic.browser
• ie.browser
• iemobile.browser
• iphone.browser
• opera.browser
• safari.browser

Verwenden von Anbietern von Browserfähigkeiten

In ASP.NET Version 3.5 Service Pack 1 können Sie die Funktionen definieren, die ein Browser auf folgende Weise hat:

• Auf Computerebene erstellen oder aktualisieren Sie eine .browser XML-Datei im folgenden Ordner:

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

• Nachdem Sie die Browserfunktion definiert haben, führen Sie den folgenden Befehl über die Visual Studio-Eingabeaufforderung aus, um die Assembly der Browserfunktionen neu zu erstellen und sie dem GAC hinzuzufügen:

• aspnet_regbrowsers.exe -I c
  

• Für eine einzelne Anwendung erstellen Sie eine .browser Datei im Ordner der Anwendung App_Browsers .

Bei diesen Ansätzen müssen Sie XML-Dateien ändern, und für Änderungen auf Computerebene müssen Sie die Anwendung neu starten, nachdem Sie den aspnet_regbrowsers.exe Prozess ausgeführt haben.

ASP.NET 4 enthält ein Feature, das als Anbieter von Browserfunktionen bezeichnet wird. Wie der Name bereits sagt, können Sie einen Anbieter erstellen, mit dem Sie wiederum Ihren eigenen Code verwenden können, um Browserfunktionen zu ermitteln.

In der Praxis definieren Entwickler häufig keine benutzerdefinierten Browserfunktionen. Browserdateien sind schwer zu aktualisieren, der Prozess für die Aktualisierung ist ziemlich kompliziert, und die XML-Syntax für .browser Dateien kann komplex zu verwenden und zu definieren sein. Was diesen Prozess erheblich vereinfachen würde, ist, wenn es eine allgemeine Browserdefinitionssyntax oder eine Datenbank gab, die up-to-date Browserdefinitionen oder sogar einen Webdienst für eine solche Datenbank enthielt. Die neue Funktion für Anbieter von Browserfunktionen macht diese Szenarien möglich und praktisch für Drittentwickler.

Es gibt zwei Hauptansätze zur Verwendung der neuen Funktion für Browserfunktionen von ASP.NET 4: die Definition der Browserfunktionen von ASP.NET zu erweitern oder vollständig zu ersetzen. In den folgenden Abschnitten wird beschrieben, erstens wie Sie die Funktionalität ersetzen, und dann wie Sie sie erweitern.

Ersetzen der funktionalität der ASP.NET Browserfunktionen

Führen Sie die folgenden Schritte aus, um die Definition der ASP.NET Browserfunktionen vollständig zu ersetzen:

1. Erstellen Sie eine Anbieterklasse, die von HttpCapabilitiesProvider abgeleitet wird und die die GetBrowserCapabilities-Methode überschreibt, wie im folgenden Beispiel gezeigt:

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

   Der Code in diesem Beispiel erstellt ein neues HttpBrowserCapabilities-Objekt , das nur die Funktion namens Browser angibt und diese Funktion auf MyCustomBrowser festlegt.

2. Registrieren Sie den Anbieter bei der Anwendung.

   Um einen Anbieter mit einer Anwendung verwenden zu können, müssen Sie das Provider-Attribut dem Abschnitt browserCaps in den Web.config oder Machine.config Dateien hinzufügen. (Sie können auch die Anbieterattribute in einem Speicherortelement für bestimmte Verzeichnisse in der Anwendung definieren, z. B. in einem Ordner für ein bestimmtes mobiles Gerät.) Das folgende Beispiel zeigt, wie das Anbieter-Attribut in einer Konfigurationsdatei festgelegt wird:

   <system.web> 
   <browserCaps provider="ClassLibrary2.CustomProvider, ClassLibrary2, 
     Version=1.0.0.0, Culture=neutral" /> 
   </system.web>
   

   Eine weitere Möglichkeit zum Registrieren der neuen Browserfunktionsdefinition ist die Verwendung von Code, wie im folgenden Beispiel gezeigt:

   void Application_Start(object sender, EventArgs e) 
   { 
       HttpCapabilitiesBase.BrowserCapabilitiesProvider =
       new ClassLibrary2.CustomProvider();
       // ... 
    }
   

   Dieser Code muss im Application_Start Ereignis der Global.asax Datei ausgeführt werden. Alle Änderungen an der BrowserCapabilitiesProvider-Klasse müssen erfolgen, bevor code in der Anwendung ausgeführt wird, um sicherzustellen, dass der Cache in einem gültigen Zustand für das aufgelöste HttpCapabilitiesBase-Objekt verbleibt.

Zwischenspeichern des HttpBrowserCapabilities-Objekts

Im vorherigen Beispiel ist ein Problem aufgetreten, d. h., dass der Code jedes Mal ausgeführt wird, wenn der benutzerdefinierte Anbieter aufgerufen wird, um das HttpBrowserCapabilities-Objekt abzurufen. Dies kann während jeder Anforderung mehrmals geschehen. Im Beispiel bewirkt der Code für den Anbieter nicht viel. Wenn der Code in Ihrem benutzerdefinierten Anbieter jedoch erhebliche Arbeit ausführt, um das HttpBrowserCapabilities-Objekt abzurufen, kann sich dies auf die Leistung auswirken. Um dies zu verhindern, können Sie das HttpBrowserCapabilities-Objekt zwischenspeichern . führen Sie die folgenden Schritte aus:

1. Erstellen Sie eine Klasse, die von HttpCapabilitiesProvider abgeleitet ist, z. B. die klasse im folgenden Beispiel:

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

   Im Beispiel generiert der Code einen Cacheschlüssel durch Aufrufen einer benutzerdefinierten BuildCacheKey-Methode und ruft die Zeitdauer für den Cache ab, indem eine benutzerdefinierte GetCacheTime-Methode aufgerufen wird. Der Code fügt dann das aufgelöste HttpBrowserCapabilities-Objekt dem Cache hinzu. Das Objekt kann aus dem Cache abgerufen und in nachfolgenden Anforderungen wiederverwendet werden, die den benutzerdefinierten Anbieter verwenden.

2. Registrieren Sie den Anbieter mit der Anwendung, wie im vorherigen Verfahren beschrieben.

Erweiterung der ASP.NET-Browserfähigkeiten

Im vorherigen Abschnitt wurde das Erstellen eines neuen HttpBrowserCapabilities-Objekts in ASP.NET 4 beschrieben. Sie können auch die Funktionalität der ASP.NET Browserfunktionen erweitern, indem Sie neue Browserfunktionendefinitionen zu denen hinzufügen, die sich bereits in ASP.NET befinden. Sie können dies tun, ohne die XML-Browserdefinitionen zu verwenden. Das folgende Verfahren zeigt, wie das geht.

1. Erstellen Sie eine Klasse, die von HttpCapabilitiesEvaluator abgeleitet wird und die die GetBrowserCapabilities-Methode überschreibt, wie im folgenden Beispiel gezeigt:

   public class CustomProvider : HttpCapabilitiesEvaluator 
   { 
       public override HttpBrowserCapabilities 
       GetBrowserCapabilities(HttpRequest request) 
       { 
           HttpBrowserCapabilities browserCaps = 
           base.GetHttpBrowserCapabilities(request);
           if (browserCaps.Browser == "Unknown") 
           { 
               browserCaps = MyBrowserCapabilitiesEvaulator(request); 
           } 
           return browserCaps; 
       } 
   }
   

   Dieser Code verwendet zunächst die Funktionalität der ASP.NET Browserfunktionen, um zu versuchen, den Browser zu identifizieren. Wenn jedoch kein Browser basierend auf den in der Anforderung definierten Informationen identifiziert wird (d. h., wenn die Browser-Eigenschaft des HttpBrowserCapabilities-Objekts die Zeichenfolge "Unknown" ist), ruft der Code den benutzerdefinierten Anbieter (MyBrowserCapabilitiesEvaluator) auf, um den Browser zu identifizieren.

2. Registrieren Sie den Anbieter mit der Anwendung, wie im vorherigen Beispiel beschrieben.

Erweitern der Funktionalität von Browserfunktionen durch Hinzufügen neuer Funktionen zu vorhandenen Funktionendefinitionen

Zusätzlich zum Erstellen eines benutzerdefinierten Browserdefinitionsanbieters und zum dynamischen Erstellen neuer Browserdefinitionen können Sie vorhandene Browserdefinitionen mit zusätzlichen Funktionen erweitern. Auf diese Weise können Sie eine Definition verwenden, die sich in der Nähe des gewünschten Begriffs befindet, aber nur wenige Funktionen enthält. Führen Sie dazu die folgenden Schritte aus.

1. Erstellen Sie eine Klasse, die von HttpCapabilitiesEvaluator abgeleitet wird und die die GetBrowserCapabilities-Methode überschreibt, wie im folgenden Beispiel gezeigt:

   public class CustomProvider : HttpCapabilitiesEvaluator 
   { 
       public override HttpBrowserCapabilities 
       GetBrowserCapabilities(HttpRequest request) 
       { 
           HttpBrowserCapabilities browserCaps = 
             base.GetHttpBrowserCapabilities(request); 
           if (browserCaps.Browser == "Unknown") 
           { 
               browserCaps = MyBrowserCapabilitiesEvaulator(request); 
           } 
           return browserCaps; 
       }
   }
   

   Der Beispielcode erweitert die vorhandene ASP.NET HttpCapabilitiesEvaluator-Klasse und ruft das HttpBrowserCapabilities - Objekt ab, das der aktuellen Anforderungsdefinition entspricht, indem der folgende Code verwendet wird:

   HttpBrowserCapabilities browserCaps = 
       base.GetHttpBrowserCapabilities(request);
   

   Der Code kann dann eine Funktion für diesen Browser hinzufügen oder ändern. Es gibt zwei Möglichkeiten, eine neue Browserfunktion anzugeben:

   • Fügen Sie dem IDictionary-Objekt ein Schlüssel-Wert-Paar hinzu, das von der Capabilities-Eigenschaft des HttpCapabilitiesBase-Objekts verfügbar gemacht wird. Im vorherigen Beispiel fügt der Code eine Funktion mit dem Namen "MultiTouch" mit dem Wert "true" hinzu.

   • Legen Sie vorhandene Eigenschaften des HttpCapabilitiesBase-Objekts fest. Im vorherigen Beispiel legt der Code die Frames-Eigenschaft auf "true" fest. Diese Eigenschaft ist einfach ein Accessor für das IDictionary-Objekt , das von der Capabilities-Eigenschaft verfügbar gemacht wird.

     Hinweis

     Hinweis Dieses Modell gilt für jede Eigenschaft von HttpBrowserCapabilities, einschließlich Steuerelementadaptern.

2. Registrieren Sie den Anbieter bei der Anwendung, wie im vorherigen Verfahren beschrieben.

Routing in ASP.NET 4

ASP.NET 4 fügt integrierte Unterstützung für die Verwendung von Routing mit Web Forms hinzu. Mithilfe des Routings können Sie eine Anwendung so konfigurieren, dass Anforderungs-URLs akzeptiert werden, die nicht physischen Dateien zugeordnet sind. Stattdessen können Sie routing verwenden, um URLs zu definieren, die für Benutzer aussagekräftig sind und die bei der Suchmaschinenoptimierung (SEO) für Ihre Anwendung helfen können. Die URL für eine Seite, die Produktkategorien in einer vorhandenen Anwendung anzeigt, könnte z. B. wie im folgenden Beispiel aussehen:

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

Mithilfe des Routings können Sie die Anwendung so konfigurieren, dass die folgende URL akzeptiert wird, um dieselben Informationen zu rendern:

http://website/products/software

Das Routing ist ab ASP.NET 3.5 SP1 verfügbar. (Ein Beispiel für die Verwendung des Routings in ASP.NET 3.5 SP1 finden Sie im Verwenden von Routing mit WebForms im Blog von Phil Haack.) ASP.NET 4 enthält jedoch einige Features, die die Verwendung des Routings vereinfachen, einschließlich der folgenden:

• Die PageRouteHandler-Klasse , bei der es sich um einen einfachen HTTP-Handler handelt, den Sie beim Definieren von Routen verwenden. Die Klasse übergibt Daten an die Seite, an die die Anforderung weitergeleitet wird.
• Die neuen Eigenschaften HttpRequest.RequestContext und Page.RouteData (ein Proxy für das HttpRequest.RequestContext.RouteData-Objekt ). Diese Eigenschaften erleichtern den Zugriff auf Informationen, die von der Route übergeben werden.
• Die folgenden neuen Ausdrucks-Generatoren, die in System.Web.Compilation.RouteUrlExpressionBuilder und System.Web.Compilation.RouteValueExpressionBuilder definiert sind:
• RouteUrl, das eine einfache Möglichkeit zum Erstellen einer URL bietet, die einer Routen-URL innerhalb eines ASP.NET Serversteuerelements entspricht.
• RouteValue, das eine einfache Möglichkeit zum Extrahieren von Informationen aus dem RouteContext-Objekt bietet.
• Die RouteParameter-Klasse erleichtert das Übergeben von Daten, die in einem RouteContext-Objekt enthalten sind, an eine Abfrage für ein Datenquellensteuerelement (ähnlich wie FormParameter).

Routing für Web Forms-Seiten

Das folgende Beispiel zeigt, wie Sie eine Web Forms-Route mithilfe der neuen MapPageRoute-Methode der Route-Klasse definieren:

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 führt die MapPageRoute-Methode ein. Das folgende Beispiel entspricht der im vorherigen Beispiel gezeigten SearchRoute-Definition, verwendet jedoch die PageRouteHandler-Klasse .

RouteTable.Routes.Add("SearchRoute", new Route("search/{searchterm}", 
  new PageRouteHandler("~/search.aspx")));

Der Code im Beispiel weist die Route einer physischen Seite zu (in der ersten Route, mit ~/search.aspx). Die erste Routendefinition gibt außerdem an, dass der Parameter mit dem Namen "searchterm" aus der URL extrahiert und an die Seite übergeben werden soll.

Die MapPageRoute-Methode unterstützt die folgenden Methodenüberladungen:

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

Der Parameter checkPhysicalUrlAccess gibt an, ob die Route die Sicherheitsberechtigungen für die physische Seite überprüfen soll, an die (in diesem Fall search.aspx) und die Berechtigungen für die eingehende URL (in diesem Fall suche/{searchterm}) weitergeleitet werden soll. Wenn der Wert von checkPhysicalUrlAccessfalsch ist, werden nur die Berechtigungen der eingehenden URL überprüft. Diese Berechtigungen werden in der Web.config Datei mithilfe von Einstellungen wie den folgenden definiert:

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

In der Beispielkonfiguration wird der Zugriff auf die physische Seite search.aspx für alle Benutzer verweigert, mit Ausnahme derJenigen, die sich in der Administratorrolle befinden. Wenn der Parameter checkPhysicalUrlAccess auf "true " festgelegt ist (der Standardwert ist), dürfen nur Administratorbenutzer auf die URL /search/{searchterm} zugreifen, da die physische Seite search.aspx auf Benutzer in dieser Rolle beschränkt ist. Wenn "checkPhysicalUrlAccess " auf "false " festgelegt ist und die Website wie im vorherigen Beispiel dargestellt konfiguriert ist, dürfen alle authentifizierten Benutzer auf die URL /search/{searchterm} zugreifen.

Lesen von Routinginformationen auf einer Web Forms-Seite

Im Code der physischen Web Forms-Seite können Sie auf die Informationen zugreifen, die Routing aus der URL extrahiert hat (oder andere Informationen, die ein anderes Objekt dem RouteData-Objekt hinzugefügt hat) mithilfe von zwei neuen Eigenschaften: HttpRequest.RequestContext und Page.RouteData. (Page.RouteData umschließt HttpRequest.RequestContext.RouteData.) Das folgende Beispiel zeigt, wie Page.RouteData verwendet wird.

protected void Page_Load(object sender, EventArgs e) 
{ 
    string searchterm = Page.RouteData.Values["searchterm"] as string; 
    label1.Text = searchterm; 
}

Der Code extrahiert den Wert, der für den Searchterm-Parameter übergeben wurde, wie in der Beispielroute zuvor definiert. Betrachten Sie die folgende Anforderungs-URL:

http://localhost/search/scott/

Wenn diese Anforderung gestellt wird, wird das Wort "scott" auf der search.aspx Seite gerendert.

Zugriff auf Routinginformationen im Markup

Die im vorherigen Abschnitt beschriebene Methode zeigt, wie Routendaten in Code auf einer Web Forms-Seite abgerufen werden. Sie können Ausdrücke auch im Markup verwenden, mit denen Sie auf dieselben Informationen zugreifen können. Ausdrucks-Generatoren sind eine leistungsstarke und elegante Möglichkeit, mit deklarativem Code zu arbeiten. (Weitere Informationen finden Sie im Eintrag Express Yourself With Custom Expression Builders im Blog von Phil Haack.)

ASP.NET 4 enthält zwei neue Ausdrucks-Generatoren für das Web Forms-Routing. Das folgende Beispiel zeigt, wie sie verwendet werden.

<asp:HyperLink ID="HyperLink1" runat="server" 
  NavigateUrl="<%$RouteUrl:SearchTerm=scott%>">Search for Scott</asp:HyperLink>

Im Beispiel wird der RouteUrl-Ausdruck verwendet, um eine URL zu definieren, die auf einem Routenparameter basiert. Dies erspart Ihnen, die vollständige URL im Markup hart zu codieren, und ermöglicht es Ihnen, die URL-Struktur später zu ändern, ohne dass der Link geändert werden muss.

Basierend auf der zuvor definierten Route generiert dieses Markup die folgende URL:

http://localhost/search/scott

ASP.NET ermittelt automatisch die richtige Route (d. h. es generiert die korrekte URL) basierend auf den Eingabeparametern. Sie können auch einen Routennamen in den Ausdruck aufnehmen, mit dem Sie eine zu verwendende Route angeben können.

Das folgende Beispiel zeigt, wie der RouteValue-Ausdruck verwendet wird.

<asp:Label ID="Label1" runat="server" Text="<%$RouteValue:SearchTerm%>" />

Wenn die Seite, die dieses Steuerelement enthält, ausgeführt wird, wird der Wert "scott" in der Beschriftung angezeigt.

Der Ausdruck RouteValue vereinfacht die Verwendung von Routendaten im Markup und erspart es Ihnen, mit der komplizierteren Syntax Page.RouteData["x"] im Markup zu arbeiten.

Verwenden von Routendaten für Datenquellensteuerungsparameter

Mit der RouteParameter-Klasse können Sie Routendaten als Parameterwert für Abfragen in einem Datenquellensteuerelement angeben. Es funktioniert ähnlich wie die Klasse, wie im folgenden Beispiel gezeigt:

<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 diesem Fall wird der Wert des Routenparameters searchterm für den @companyname Parameter in der Select-Anweisung verwendet.

Festlegen von Client-IDs

Die neue ClientIDMode-Eigenschaft behebt ein langjähriges Problem in ASP.NET, nämlich wie Steuerelemente das ID-Attribut für Elemente erstellen, die sie rendern. Die Kenntnis des ID-Attributs für gerenderte Elemente ist wichtig, wenn Ihre Anwendung Clientskripts enthält, die auf diese Elemente verweisen.

Das ID-Attribut in HTML, das für Webserversteuerelemente gerendert wird, wird basierend auf der ClientID-Eigenschaft des Steuerelements generiert. Bis ASP.NET 4, besteht der Algorithmus zum Generieren des ID-Attributs aus der ClientID-Eigenschaft darin, den Benennungscontainer (falls vorhanden) mit der ID zu verketten, und bei wiederholten Steuerelementen (wie in Datensteuerelementen), um ein Präfix und eine sequenzielle Zahl hinzuzufügen. Dies hat zwar immer sichergestellt, dass die IDs von Steuerelementen auf der Seite eindeutig sind, aber der Algorithmus hat zu Steuerelement-IDs geführt, die nicht vorhersehbar waren und daher im Clientskript schwer zu referenzieren waren.

Mit der neuen ClientIDMode-Eigenschaft können Sie genauer angeben, wie die Client-ID für Steuerelemente generiert wird. Sie können die ClientIDMode-Eigenschaft für jedes Steuerelement festlegen, einschließlich für die Seite. Mögliche Einstellungen sind die folgenden:

• AutoID – Dies entspricht dem Algorithmus zum Generieren von ClientID-Eigenschaftswerten , die in früheren Versionen von ASP.NET verwendet wurden.
• Static – Dies gibt an, dass der ClientID-Wert mit der ID identisch ist, ohne die IDs von übergeordneten Benennungscontainern zu verketten. Dies kann in Webbenutzersteuerelementen nützlich sein. Da sich ein Webbenutzersteuerelement auf verschiedenen Seiten und in verschiedenen Containersteuerelementen befinden kann, kann es schwierig sein, Clientskript für Steuerelemente zu schreiben, die den AutoID-Algorithmus verwenden, da Sie nicht vorhersagen können, was die ID-Werte sein werden.
• Vorhersehbar – Diese Option dient in erster Linie zur Verwendung in Datensteuerelementen, die wiederholte Vorlagen verwenden. Es verkettet die ID-Eigenschaften der Benennungscontainer des Steuerelements, aber generierte ClientID-Werte enthalten keine Zeichenfolgen wie "ctlxxx". Diese Einstellung funktioniert in Verbindung mit der ClientIDRowSuffix-Eigenschaft des Steuerelements. Sie legen die ClientIDRowSuffix-Eigenschaft auf den Namen eines Datenfelds fest, und der Wert dieses Felds wird als Suffix für den generierten ClientID-Wert verwendet. In der Regel verwenden Sie den Primärschlüssel eines Datensatzes als ClientIDRowSuffix-Wert .
• Erben – Diese Einstellung ist das Standardverhalten für Steuerelemente; es gibt an, dass die ID-Generierung eines Steuerelements mit dem übergeordneten Element übereinstimmt.

Sie können die ClientIDMode-Eigenschaft auf Seitenebene festlegen. Dadurch wird der Standardmäßige ClientIDMode-Wert für alle Steuerelemente auf der aktuellen Seite definiert.

Der Standardmäßige ClientIDMode-Wert auf Seitenebene ist AutoID, und der Standardmäßige ClientIDMode-Wert auf der Steuerelementebene lautet "Inherit". Wenn Sie diese Eigenschaft daher nicht an einer beliebigen Stelle im Code festlegen, werden alle Steuerelemente standardmäßig auf den AutoID-Algorithmus festgelegt.

Sie legen den Wert auf Seitenebene in der @Page-Direktive fest, wie im folgenden Beispiel gezeigt:

<%@ Page Language="C#" AutoEventWireup="true" 
  CodeFile="Default.aspx.cs" 
  Inherits="_Default" 
  ClientIDMode="Predictable" %>

Sie können den ClientIDMode-Wert auch in der Konfigurationsdatei festlegen, entweder auf Computerebene oder auf Anwendungsebene. Dadurch wird die Standardmäßigeinstellung "ClientIDMode " für alle Steuerelemente auf allen Seiten der Anwendung definiert. Wenn Sie den Wert auf Computerebene festlegen, wird die Standardeinstellung "ClientIDMode " für alle Websites auf diesem Computer definiert. Das folgende Beispiel zeigt die ClientIDMode-Einstellung in der Konfigurationsdatei:

<system.web> 
  <pages clientIDMode="Predictable"></pages> 
</system.web>

Wie bereits erwähnt, wird der Wert der ClientID-Eigenschaft vom Benennungscontainer des übergeordneten Elements eines Steuerelements abgeleitet. In einigen Szenarien, z. B. wenn Sie Masterseiten verwenden, können Steuerelemente mit IDs enden, wie sie im folgenden gerenderten HTML-Code zu sehen sind.

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

Obwohl das im Markup angezeigte Eingabeelement (aus einem TextBox-Steuerelement) nur zwei Benennungscontainer tief in der Seite enthalten ist (nämlich die geschachtelten ContentPlaceholder-Steuerelemente), ergibt sich aufgrund der Verarbeitung von Masterseiten als Endergebnis eine Steuerelement-ID wie die folgende:

ctl00_ContentPlaceHolder1_ParentPanel_NamingPanel1_TextBox1

Diese ID ist garantiert eindeutig auf der Seite, ist aber für die meisten Zwecke unnötig lang. Stellen Sie sich vor, Sie möchten die Länge der gerenderten ID reduzieren und mehr Kontrolle darüber haben, wie die ID generiert wird. (Sie möchten z. B. "ctlxxx"-Präfixe entfernen.) Am einfachsten können Sie dies erreichen, indem Sie die ClientIDMode-Eigenschaft wie im folgenden Beispiel gezeigt festlegen:

<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 diesem Beispiel wird die Eigenschaft "ClientIDMode" für das äußerste NamingPanel-Element auf "Static" festgelegt und für das innere NamingControl-Element auf "Vorhersagbar" festgelegt. Diese Einstellungen führen zum folgenden Markup (die restliche Seite und die Masterseite werden als identisch mit dem vorherigen Beispiel angenommen):

<div id="ParentPanel"> 
  <div id="ParentPanel_NamingPanel1"> 
    <input name="ctl00$ContentPlaceHolder1$ParentPanel$NamingPanel1$TextBox1" 
        type="text" value="Hello!" id="ParentPanel_NamingPanel1_TextBox1" /> 
</div>

Die Statische Einstellung hat die Auswirkung, die Benennungshierarchie für alle Steuerelemente innerhalb des äußersten NamingPanel-Elements zurückzusetzen und die ContentPlaceHolder - und MasterPage-IDs aus der generierten ID zu entfernen. (Das Namensattribute von gerenderten Elementen ist nicht betroffen, sodass die normale ASP.NET Funktionalität für Ereignisse, Ansichtszustand usw. beibehalten wird.) Ein Nebeneffekt des Zurücksetzens der Benennungshierarchie besteht darin, dass auch dann, wenn Sie das Markup für die NamingPanel-Elemente in ein anderes ContentPlaceholder-Steuerelement verschieben, die gerenderten Client-IDs unverändert bleiben.

Hinweis

Beachten Sie, dass Sie dafür verantwortlich sind, dass die gerenderten Steuerelement-IDs eindeutig sind. Wenn dies nicht der Fall ist, kann jede Funktionalität, die eindeutige IDs für einzelne HTML-Elemente benötigt, z. B. die Clientdokument.getElementById-Funktion , unterbrechen.

Erstellen vorhersehbarer Client-IDs in datenbindenden Steuerelementen

Die ClientID-Werte , die für Steuerelemente in einem datengebundenen Listensteuerelement durch den Legacyalgorithmus generiert werden, können lang sein und sind nicht wirklich vorhersehbar. Die ClientIDMode-Funktionalität kann Ihnen helfen, mehr Kontrolle darüber zu haben, wie diese IDs generiert werden.

Das Markup im folgenden Beispiel enthält ein ListView-Steuerelement :

<asp:ListView ID="ListView1" runat="server" DataSourceID="SqlDataSource1" 
    OnSelectedIndexChanged="ListView1_SelectedIndexChanged" 
    ClientIDMode="Predictable" 
    RowClientIDRowSuffix="ProductID"> 
</asp:ListView>

Im vorherigen Beispiel werden die Eigenschaften ClientIDMode und RowClientIDRowSuffix im Markup festgelegt. Die ClientIDRowSuffix-Eigenschaft kann nur in datengebundenen Steuerelementen verwendet werden, und sein Verhalten unterscheidet sich je nach verwendetem Steuerelement. Die Unterschiede sind die folgenden:

• GridView-Steuerelement – Sie können den Namen einer oder mehrerer Spalten in der Datenquelle angeben, die zur Laufzeit kombiniert werden, um die Client-IDs zu erstellen. Wenn Sie beispielsweise RowClientIDRowSuffix auf "ProductName, ProductId" festlegen, weisen Steuerelement-IDs für gerenderte Elemente ein Format wie folgt auf:

• rootPanel_GridView1_ProductNameLabel_Chai_1
  

• ListView-Steuerelement – Sie können eine einzelne Spalte in der Datenquelle angeben, die an die Client-ID angefügt wird. Wenn Sie beispielsweise ClientIDRowSuffix auf "ProductName" festlegen, haben die gerenderten Steuerelement-IDs folgendes Format:

• rootPanel_ListView1_ProductNameLabel_1
  

• In diesem Fall wird die nachfolgende 1 von der Produkt-ID des aktuellen Datenelements abgeleitet.

• Repeater-Steuerelement – Dieses Steuerelement unterstützt die ClientIDRowSuffix-Eigenschaft nicht. In einem Repeater-Steuerelement wird der Index der aktuellen Zeile verwendet. Wenn Sie ClientIDMode="Vorhersagbar" mit einem Repeater-Steuerelement verwenden, werden Client-IDs generiert, die das folgende Format aufweisen:

• Repeater1_ProductNameLabel_0
  

• Der nachfolgende 0 ist der Index der aktuellen Zeile.

Die FormView- und DetailsView-Steuerelemente zeigen nicht mehrere Zeilen an, sodass sie die ClientIDRowSuffix-Eigenschaft nicht unterstützen.

Beibehalten der Reihenauswahl in Datenkontrollen

Mit den GridView- und ListView-Steuerelementen können Benutzer eine Zeile auswählen. In früheren Versionen von ASP.NET basiert die Auswahl auf dem Zeilenindex auf der Seite. Wenn Sie beispielsweise das dritte Element auf Seite 1 auswählen und dann zu Seite 2 wechseln, wird das dritte Element auf dieser Seite ausgewählt.

Die beibehaltene Auswahl wurde anfänglich nur in Dynamischen Datenprojekten in .NET Framework 3.5 SP1 unterstützt. Wenn dieses Feature aktiviert ist, basiert das aktuelle ausgewählte Element auf dem Datenschlüssel für das Element. Dies bedeutet: Wenn Sie die dritte Zeile auf Seite 1 auswählen und zu Seite 2 wechseln, wird auf Seite 2 nichts ausgewählt. Wenn Sie zurück zur Seite 1 wechseln, wird die dritte Zeile weiterhin ausgewählt. Die beibehaltene Auswahl wird jetzt für die GridView- und ListView-Steuerelemente in allen Projekten mithilfe der EnablePersistedSelection-Eigenschaft unterstützt, wie im folgenden Beispiel gezeigt:

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

ASP.NET Diagrammsteuerelement

Das ASP.NET Chart-Steuerelement erweitert die Datenvisualisierungsangebote in .NET Framework. Mithilfe des Diagrammsteuerelements können Sie ASP.NET Seiten erstellen, die intuitive und visuell ansprechende Diagramme für komplexe statistische oder finanztechnische Analysen aufweisen. Das ASP.NET-Diagrammsteuerelement wurde als Add-On zur .NET Framework-Version 3.5 SP1 eingeführt und ist Teil der .NET Framework 4-Version.

Das Steuerelement enthält die folgenden Features:

• 35 verschiedene Diagrammtypen.
• Eine unbegrenzte Anzahl von Diagrammbereichen, Titeln, Legenden und Anmerkungen.
• Eine Vielzahl von Darstellungseinstellungen für alle Diagrammelemente.
• 3D-Unterstützung für die meisten Diagrammtypen.
• Intelligente Datenbeschriftungen, die automatisch an Datenpunkte angepasst werden können.
• Streifenlinien, Skalenunterbrechungen und logarithmische Skalierung.
• Mehr als 50 finanz- und statistische Formeln für Datenanalyse und Transformation.
• Einfache Bindung und Manipulation von Diagrammdaten.
• Unterstützung für allgemeine Datenformate wie Datumsangaben, Uhrzeiten und Währungen.
• Unterstützung für Interaktivität und ereignisgesteuerte Anpassungen, einschließlich von Klickereignissen auf der Client-Seite unter Verwendung von Ajax.
• Zustandsverwaltung.
• Binäres Streaming.

Die folgenden Abbildungen zeigen Beispiele für Finanzdiagramme, die vom ASP.NET Chart-Steuerelement erstellt werden.

Abbildung 2: Beispiele für ASP.NET Diagrammsteuerelement

Weitere Beispiele für die Verwendung des ASP.NET Chart-Steuerelements finden Sie auf der MSDN-Website unter "Beispiele für die Umgebung für Microsoft Chart Controls". Weitere Beispiele für Communityinhalte finden Sie im Chart Control Forum.

Hinzufügen des Diagrammsteuerelements zu einer ASP.NET Seite

Das folgende Beispiel zeigt, wie Sie mithilfe von Markup ein Diagrammsteuerelement zu einer ASP.NET Seite hinzufügen. Im Beispiel erzeugt das Diagramm-Steuerelement ein Säulendiagramm für statische Datenpunkte.

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

Verwenden von 3D-Diagrammen

Das Chart-Steuerelement enthält eine ChartAreas-Auflistung , die ChartArea-Objekte enthalten kann, die Merkmale von Diagrammbereichen definieren. Wenn Sie z. B. 3D für eine Diagrammfläche verwenden möchten, verwenden Sie die Area3DStyle-Eigenschaft wie im folgenden Beispiel:

<asp:ChartArea Name="ChartArea1"> 
  <area3dstyle 
      Rotation="10" 
      Perspective="10" 
      Enable3D="True" 
      Inclination="15" 
      IsRightAngleAxes="False" 
      WallWidth="0" 
      IsClustered="False" /> 
      
  <%-- Additional markup here --%> 
</asp:ChartArea>

Die folgende Abbildung zeigt ein 3D-Diagramm mit vier Datenreihen des Balkendiagrammtyps .

Abbildung 3: 3D-Balkendiagramm

Verwenden von Skalierungsumbrüchen und logarithmischen Skalierungen

Skalierungsumbrüche und logarithmische Skalierungen stellen zwei zusätzliche Möglichkeiten dar, um dem Diagramm eine Raffinesse hinzuzufügen. Diese Features sind spezifisch für jede Achse in einem Diagrammbereich. Wenn Sie diese Features beispielsweise auf der primären Y-Achse eines Diagrammbereichs verwenden möchten, verwenden Sie die Eigenschaften AxisY.IsLogarithmic und ScaleBreakStyle in einem ChartArea-Objekt . Der folgende Codeausschnitt zeigt, wie Skalierungsumbrüche auf der primären Y-Achse verwendet werden.

<asp:ChartArea Name="ChartArea1">

  <axisy>

    <ScaleBreakStyle 
        BreakLineStyle="Wave" 
        CollapsibleSpaceThreshold="40" 
        Enabled="True" />
  </axisy>

<%-- Additional markup here --%>
</asp:ChartArea>

Die folgende Abbildung zeigt die Y-Achse mit aktivierten Skalierungsumbrüchen.

Abbildung 4: Skalierungsumbrüche

Filtern von Daten mit dem QueryExtender-Steuerelement

Eine sehr häufige Aufgabe für Entwickler, die datengesteuerte Webseiten erstellen, besteht darin, Daten zu filtern. Dies wurde traditionell durch Erstellen von Where-Klauseln in Datenquellensteuerelementen durchgeführt. Dieser Ansatz kann kompliziert sein, und in einigen Fällen lässt die Syntax "Where " nicht die volle Funktionalität der zugrunde liegenden Datenbank nutzen.

Um die Filterung zu vereinfachen, wurde in ASP.NET 4 ein neues QueryExtender-Steuerelement hinzugefügt. Dieses Steuerelement kann zu EntityDataSource - oder LinqDataSource-Steuerelementen hinzugefügt werden, um die von diesen Steuerelementen zurückgegebenen Daten zu filtern. Da das QueryExtender-Steuerelement LINQ verwendet, wird der Filter auf dem Datenbankserver angewendet, bevor die Daten an die Seite gesendet werden, was zu sehr effizienten Vorgängen führt.

Das QueryExtender-Steuerelement unterstützt eine Vielzahl von Filteroptionen. In den folgenden Abschnitten werden diese Optionen beschrieben und Beispiele für die Verwendung bereitgestellt.

Suchen

Für die Suchoption führt das QueryExtender-Steuerelement eine Suche in angegebenen Feldern aus. Im folgenden Beispiel verwendet das Steuerelement den Text, der in das TextBoxSearch-Steuerelement eingegeben wird, und sucht nach dessen Inhalt in den ProductName- und Supplier.CompanyName-Spalten der Daten, die vom LinqDataSource-Steuerelement zurückgegeben werden.

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

Bereich

Die Bereichsoption ähnelt der Suchoption, gibt jedoch ein Wertepaar an, um den Bereich zu definieren. Im folgenden Beispiel durchsucht das QueryExtender-Steuerelement die UnitPrice Spalte in den daten, die vom LinqDataSource-Steuerelement zurückgegeben werden. Der Bereich wird aus den TextBoxFrom- und TextBoxTo-Steuerelementen auf der Seite gelesen.

<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

Mit der Eigenschaftsausdrucksoption können Sie einen Vergleich mit einem Eigenschaftswert definieren. Wenn der Ausdruck zu true ausgewertet wird, werden die Daten, die überprüft werden, zurückgegeben. Im folgenden Beispiel filtert das QueryExtender-Steuerelement Daten, indem die Daten in der Discontinued Spalte mit dem Wert aus dem CheckBoxDiscontinued-Steuerelement auf der Seite verglichen werden.

<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

Schließlich können Sie einen benutzerdefinierten Ausdruck angeben, der mit dem QueryExtender-Steuerelement verwendet werden soll. Mit dieser Option können Sie eine Funktion auf der Seite aufrufen, die benutzerdefinierte Filterlogik definiert. Das folgende Beispiel zeigt, wie Sie einen benutzerdefinierten Ausdruck im QueryExtender-Steuerelement deklarativ angeben.

<asp:LinqDataSource ID="dataSource" runat="server" TableName="Products"> 
</asp:LinqDataSource> 
<asp:QueryExtender TargetControlID="dataSource" runat="server"> 
  <asp:CustomExpression OnQuerying="FilterProducts" /> 
</asp:QueryExtender>

Das folgende Beispiel zeigt die benutzerdefinierte Funktion, die vom QueryExtender-Steuerelement aufgerufen wird. In diesem Fall verwendet der Code anstelle einer Datenbankabfrage, die eine Where-Klausel enthält, eine LINQ-Abfrage, um die Daten zu filtern.

protected void FilterProducts(object sender, CustomExpressionEventArgs e) 
{ 
    e.Query = from p in e.Query.Cast() 
      where p.UnitPrice >= 10 
      select p; 
}

In diesen Beispielen wird jeweils nur ein Ausdruck im QueryExtender-Steuerelement verwendet. Sie können jedoch mehrere Ausdrücke innerhalb des QueryExtender-Steuerelements einschließen.

Html-codierte Codeausdrücke

Einige ASP.NET Websites (insbesondere mit ASP.NET MVC) basieren stark auf der Verwendung von <%= expression %> Syntax (häufig als "Code nuggets" bezeichnet), um Text in die Antwort zu schreiben. Wenn Sie Codeausdrücke verwenden, ist es leicht zu vergessen, den Text mit HTML zu codieren. Wenn der Text von der Benutzereingabe stammt, kann er Seiten offen lassen, um einen XSS-Angriff (Cross Site Scripting) zu ermöglichen.

ASP.NET 4 führt die folgende neue Syntax für Codeausdrücke ein:

<%: expression %>

Diese Syntax verwendet standardmäßig HTML-Codierung beim Schreiben in die Antwort. Dieser neue Ausdruck übersetzt sich effektiv in Folgendes:

<%= HttpUtility.HtmlEncode(expression) %>

Beispiel: <%: Request["UserInput"] %> führt eine HTML-Codierung auf den Wert von Request["UserInput"] durch.

Ziel dieses Features ist es, alle Instanzen der alten Syntax durch die neue Syntax zu ersetzen, sodass Sie nicht bei jedem Schritt entscheiden müssen, den sie verwenden sollen. Es gibt jedoch Fälle, in denen der ausgegebene Text HTML sein soll oder bereits codiert ist. In diesem Fall kann dies zu einer doppelten Codierung führen.

In diesen Fällen führt ASP.NET 4 eine neue Schnittstelle , IHtmlString, zusammen mit einer konkreten Implementierung, HtmlString ein. Mit Instanzen dieser Typen können Sie angeben, dass der Rückgabewert bereits ordnungsgemäß codiert (oder anderweitig untersucht) für die Anzeige als HTML ist und daher der Wert nicht erneut HTML-codiert werden sollte. Beispielsweise sollte folgendes nicht (und nicht) HTML-codiert sein:

<%: new HtmlString("<strong>HTML that is not encoded</strong>") %>

ASP.NET MVC 2-Hilfsmethoden wurden aktualisiert, um mit dieser neuen Syntax zu arbeiten, sodass sie nicht doppelt codiert sind, sondern nur, wenn Sie ASP.NET 4 ausführen. Diese neue Syntax funktioniert nicht, wenn Sie eine Anwendung mit ASP.NET 3.5 SP1 ausführen.

Beachten Sie, dass dies keinen Schutz vor XSS-Angriffen garantiert. Beispielsweise können HTML-Code, der Attributwerte verwendet, die sich nicht in Anführungszeichen befinden, benutzereingaben enthalten, die noch anfällig sind. Beachten Sie, dass die Ausgabe von ASP.NET-Steuerelementen und ASP.NET MVC-Hilfsprogramme immer Attributwerte in Anführungszeichen enthält, was der empfohlene Ansatz ist.

Ebenso führt diese Syntax keine JavaScript-Codierung durch, z. B. wenn Sie eine JavaScript-Zeichenfolge basierend auf der Benutzereingabe erstellen.

Projektvorlagenänderungen

Wenn Sie in früheren Versionen von ASP.NET Visual Studio zum Erstellen eines neuen Websiteprojekts oder Webanwendungsprojekts verwenden, enthalten die resultierenden Projekte nur eine Default.aspx Seite, eine Standarddatei Web.config und den App_Data Ordner, wie in der folgenden Abbildung gezeigt:

Visual Studio unterstützt auch einen Projekttyp "Leere Website", der überhaupt keine Dateien enthält, wie in der folgenden Abbildung dargestellt:

Das Ergebnis ist, dass es für den Anfänger sehr wenig Anleitungen zum Erstellen einer Produktionswebanwendung gibt. Daher führt ASP.NET 4 drei neue Vorlagen ein, eines für ein leeres Webanwendungsprojekt und eines für ein Webanwendungs- und Websiteprojekt.

Leere Webanwendungsvorlage

Wie der Name sagt, ist die Vorlage "Leere Webanwendung" ein vereinfachtes Webanwendungsprojekt. Sie wählen diese Projektvorlage aus dem Visual Studio-Dialogfeld "Neues Projekt" aus, wie in der folgenden Abbildung dargestellt:

(Klicken Sie hier, um das Bild in voller Größe anzuzeigen)

Wenn Sie eine leere ASP.NET Webanwendung erstellen, erstellt Visual Studio das folgende Ordnerlayout:

Dies ähnelt dem Layout "Leere Website" aus früheren Versionen von ASP.NET mit einer Ausnahme. In Visual Studio 2010 enthalten leere Webanwendungs- und leere Websiteprojekte die folgende minimale Web.config Datei, die Informationen enthält, die von Visual Studio verwendet werden, um das Framework zu identifizieren, auf das das Projekt ausgerichtet ist:

Ohne diese targetFramework-Eigenschaft wird Visual Studio standardmäßig auf .NET Framework 2.0 ausgerichtet, um die Kompatibilität beim Öffnen älterer Anwendungen beizubehalten.

Webanwendungs- und Websiteprojektvorlagen

Die anderen beiden neuen Projektvorlagen, die mit Visual Studio 2010 ausgeliefert werden, enthalten wichtige Änderungen. Die folgende Abbildung zeigt das Projektlayout, das beim Erstellen eines neuen Webanwendungsprojekts erstellt wird. (Das Layout für ein Websiteprojekt ist nahezu identisch.)

• 

Das Projekt enthält eine Reihe von Dateien, die in früheren Versionen nicht erstellt wurden. Darüber hinaus ist das neue Webanwendungsprojekt mit grundlegenden Mitgliedschaftsfunktionen konfiguriert, mit denen Sie schnell mit dem Sichern des Zugriffs auf die neue Anwendung beginnen können. Aufgrund dieser Einbeziehung enthält die Web.config Datei für das neue Projekt Einträge, die zum Konfigurieren von Mitgliedschaft, Rollen und Profilen verwendet werden. Das folgende Beispiel zeigt die Web.config Datei für ein neues Webanwendungsprojekt. (In diesem Fall ist roleManager deaktiviert.)

(Klicken Sie hier, um das Bild in voller Größe anzuzeigen)

Das Projekt enthält auch eine zweite Web.config Datei im Account Verzeichnis. Die zweite Konfigurationsdatei bietet eine Möglichkeit, den Zugriff auf die ChangePassword.aspx Seite für nicht angemeldete Benutzer zu sichern. Das folgende Beispiel zeigt den Inhalt der zweiten Web.config Datei.

Die standardmäßig in den neuen Projektvorlagen erstellten Seiten enthalten auch mehr Inhalt als in früheren Versionen. Das Projekt enthält eine Standardgestaltungsvorlage und CSS-Datei, und die Standardseite (Default.aspx) ist standardmäßig für die Verwendung der Gestaltungsvorlage konfiguriert. Das Ergebnis ist, dass die Standardseite (Homepage) bereits funktionsfähig ist, wenn Sie die Webanwendung oder Website zum ersten Mal ausführen. Tatsächlich ähnelt sie der Standardseite, die Beim Starten einer neuen MVC-Anwendung angezeigt wird.

(Klicken Sie hier, um das Bild in voller Größe anzuzeigen)

Die Absicht dieser Änderungen an den Projektvorlagen besteht darin, Anleitungen zum Erstellen einer neuen Webanwendung bereitzustellen. Mit semantisch korrekten, strengen XHTML 1.0-konformen Markups und mit layout, das mit CSS angegeben wird, stellen die Seiten in den Vorlagen bewährte Methoden zum Erstellen ASP.NET 4 Webanwendungen dar. Die Standardseiten verfügen auch über ein zweispaltiges Layout, das Sie ganz einfach anpassen können.

Stellen Sie sich beispielsweise vor, dass Sie für eine neue Webanwendung einige der Farben ändern und ihr Firmenlogo anstelle des Logos "Meine ASP.NET Anwendung" einfügen möchten. Dazu erstellen Sie ein neues Verzeichnis, unter Content dem Ihr Logobild gespeichert wird:

Um das Bild zur Seite hinzuzufügen, öffnen Sie dann die Site.Master Datei, suchen, wo der Text "Meine ASP.NET Anwendung" definiert ist, und ersetzen Sie es durch ein Bildelement , dessen src-Attribut auf das neue Logobild festgelegt ist, wie im folgenden Beispiel gezeigt:

(Klicken Sie hier, um das Bild in voller Größe anzuzeigen)

Sie können dann in die Site.css Datei wechseln und CSS-Klassendefinitionen ändern, um die Hintergrundfarbe der Seite sowie die der Kopfzeile zu ändern.

Das Ergebnis dieser Änderungen ist, dass Sie eine angepasste Startseite mit nur geringem Aufwand anzeigen können:

(Klicken Sie hier, um das Bild in voller Größe anzuzeigen)

CSS-Verbesserungen

Einer der wichtigsten Arbeitsbereiche in ASP.NET 4 war das Rendern von HTML, das mit den neuesten HTML-Standards kompatibel ist. Dies umfasst Änderungen, wie ASP.NET Webserversteuerelemente CSS-Formatvorlagen verwenden.

Kompatibilitätseinstellung für Rendering

Wenn eine Webanwendung oder Website auf .NET Framework 4 ausgerichtet ist, wird standardmäßig das controlRenderingCompatibilityVersion-Attribut des Seitenelements auf "4.0" festgelegt. Dieses Element ist in der Datei auf Computerebene Web.config definiert und gilt standardmäßig für alle ASP.NET 4-Anwendungen:

<system.web> 
  <pages controlRenderingCompatibilityVersion="3.5|4.0"/> 
</system.web>

Der Wert für controlRenderingCompatibility ist eine Zeichenfolge, die potenzielle neue Versionsdefinitionen in zukünftigen Versionen zulässt. In der aktuellen Version werden die folgenden Werte für diese Eigenschaft unterstützt:

• 3.5 Diese Einstellung gibt das ältere Rendering und Markup an. Markup, das von Steuerelementen gerendert wird, ist 100% abwärtskompatibel, und die Einstellung der xhtmlConformance-Eigenschaft wird berücksichtigt.
• "4.0". Wenn die Eigenschaft über diese Einstellung verfügt, gehen ASP.NET Webserversteuerelemente wie folgt vor:
• Die xhtmlConformance-Eigenschaft wird immer als "Strict" behandelt. Daher rendern Steuerelemente XHTML 1.0 Strict-Markup.
• Durch das Deaktivieren von Steuerelementen ohne Eingabe werden keine ungültigen Formatvorlagen mehr gerendert.
• div-Elemente um ausgeblendete Felder werden jetzt formatiert, sodass sie keine Probleme mit vom Benutzer erstellten CSS-Regeln verursachen.
• Menüsteuerelemente rendern Markup, das semantisch korrekt ist und den Richtlinien für die Barrierefreiheit entspricht.
• Validierungssteuerelemente rendern keine Inline-Stile.
• Steuerelemente, die zuvor border="0" gerendert haben (Steuerelemente, die vom ASP.NET Table-Steuerelement abgeleitet wurden, und das ASP.NET Bildsteuerelement ) rendern dieses Attribut nicht mehr.

Deaktivieren von Steuerelementen

In ASP.NET 3.5 SP1 und früheren Versionen rendert das Framework das deaktivierte Attribut im HTML-Markup für jedes Steuerelement, dessen Enabled-Eigenschaft auf "false" festgelegt ist. Gemäß der HTML 4.01-Spezifikation sollten jedoch nur Eingabeelemente dieses Attribut aufweisen.

In ASP.NET 4 können Sie die controlRenderingCompatibilityVersion-Eigenschaft wie im folgenden Beispiel auf "3.5" festlegen:

<system.web> 
  <pages controlRenderingCompatibilityVersion="3.5"/> 
</system.web>

Möglicherweise erstellen Sie Markup für ein Label-Steuerelement wie das folgende, wodurch das Steuerelement deaktiviert wird:

<asp:Label id="Label" runat="server" Text="Test" Enabled="false">

Das Bezeichnungssteuerelement rendert den folgenden HTML-Code:

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

In ASP.NET 4 können Sie die controlRenderingCompatibilityVersion auf "4.0" festlegen. In diesem Fall werden nur Steuerelemente, die Eingabeelemente rendern, ein deaktiviertes Attribut rendern, wenn die Enabled-Eigenschaft des Steuerelements auf "false" festgelegt ist. Steuerelemente, die keine HTML-Eingabeelemente rendern, rendern stattdessen ein Klassenattribut, das auf eine CSS-Klasse verweist, die Sie verwenden können, um ein deaktiviertes Aussehen für das Steuerelement zu definieren. Beispielsweise würde das im vorherigen Beispiel gezeigte Label-Steuerelement das folgende Markup generieren:

<span id="Span1" class="aspnetdisabled">Test</span>

Der Standardwert für die Klasse, die für dieses Steuerelement angegeben wurde, ist "aspNetDisabled". Sie können diesen Standardwert jedoch ändern, indem Sie die statische DisabledCssClass-Eigenschaft der WebControl-Klasse festlegen. Für Steuerelemententwickler kann das Verhalten für ein bestimmtes Steuerelement auch mithilfe der SupportsDisabledAttribute-Eigenschaft definiert werden.

Ausblenden von div-Elementen um ausgeblendete Felder

ASP.NET 2.0 und höher rendern systemspezifische ausgeblendete Felder (z. B. das ausgeblendete Element zum Speichern von Ansichtsstatusinformationen) innerhalb des div-Elements , um den XHTML-Standard einzuhalten. Dies kann jedoch zu einem Problem führen, wenn sich eine CSS-Regel auf div-Elemente auf einer Seite auswirkt. Beispielsweise kann dies dazu führen, dass eine einpixelige Linie auf der Seite um die ausgeblendeten div-Elemente herum angezeigt wird. In ASP.NET 4 fügen die div-Elemente, die die von ASP.NET generierten ausgeblendeten Felder umschließen, einen CSS-Klassenverweis hinzu, wie im folgenden Beispiel:

<div class="aspNetHidden">...</div>

Anschließend können Sie eine CSS-Klasse definieren, die nur für die ausgeblendeten Elemente gilt, die von ASP.NET generiert werden, wie im folgenden Beispiel gezeigt:

<style type="text/css"> 
  DIV# aspNetHidden {border:0;} 

</style>

Darstellen einer externen Tabelle für Vorlagensteuerelemente

Standardmäßig werden die folgenden ASP.NET Webserversteuerelemente, die Vorlagen unterstützen, automatisch in eine äußere Tabelle eingeschlossen, die zum Anwenden von Inlineformatvorlagen verwendet wird:

• Formview
• Anmeldung
• Passwordrecovery
• ChangePassword
• Assistent
• Createuserwizard

Diesen Steuerelementen wurde eine neue Eigenschaft namens RenderOuterTable hinzugefügt, die es ermöglicht, die äußere Tabelle aus dem Markup zu entfernen. Betrachten Sie beispielsweise das folgende Beispiel eines FormView-Steuerelements :

<asp:FormView ID="FormView1" runat="server"> 
  <ItemTemplate> 
      Content 
  </ItemTemplate> 

</asp:FormView>

Dieses Markup gibt die folgende Ausgabe auf der Seite aus, die eine HTML-Tabelle enthält:

<table cellspacing="0" border="0" id="Table1" style="border-collapse:collapse;"> 
  <tr> 
    <td colspan="2"> 
      Content 
    </td> 
  </tr> 

</table>

Um zu verhindern, dass die Tabelle gerendert wird, können Sie wie im folgenden Beispiel die RenderOuterTable-Eigenschaft des FormView-Steuerelements festlegen:

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

Im vorherigen Beispiel wird die folgende Ausgabe ohne die Elemente "Tabelle", "tr" und "td " gerendert:

Content

Diese Erweiterung kann das Formatieren des Inhalts des Steuerelements mit CSS vereinfachen, da keine unerwarteten Tags vom Steuerelement gerendert werden.

Hinweis

Beachten Sie, dass diese Änderung die Unterstützung für die Funktion für das automatische Format im Visual Studio 2010-Designer deaktiviert, da es kein Tabellenelement mehr gibt, das Formatattribute hosten kann, die von der Option für das automatische Format generiert werden.

Verbesserungen des ListView-Steuerelements

Das ListView-Steuerelement wurde in ASP.NET 4 einfacher verwendet. Die frühere Version des Steuerelements erfordert, dass Sie eine Layoutvorlage angeben, die ein Serversteuerelement mit einer bekannten ID enthielt. Das folgende Markup zeigt ein typisches Beispiel für die Verwendung des ListView-Steuerelements 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 erfordert das ListView-Steuerelement keine Layoutvorlage. Das im vorherigen Beispiel gezeigte Markup kann durch das folgende Markup ersetzt werden:

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

</asp:ListView>

Verbesserungen der Steuerelemente CheckBoxList und RadioButtonList

In ASP.NET 3.5 können Sie das Layout für checkBoxList und RadioButtonList mithilfe der folgenden beiden Einstellungen angeben:

• Fluss. Das Steuerelement rendert span-Elemente, die seinen Inhalt enthalten.
• Tabelle. Das Steuerelement rendert ein Tabellenelement , das seinen Inhalt enthält.

Das folgende Beispiel zeigt Markup für jedes dieser Steuerelemente.

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

Standardmäßig rendern die Steuerelemente HTML ähnlich wie folgt:

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

Da diese Steuerelemente Listen von Elementen enthalten, sollten sie ihre Inhalte mit HTML-Listenelementen (li) darstellen, um semantisch korrektes HTML zu erzeugen. Dies erleichtert Benutzern, die Webseiten mithilfe von Hilfstechnologien lesen, und erleichtert das Formatieren der Steuerelemente mithilfe von CSS.

In ASP.NET 4 unterstützen die CheckBoxList - und RadioButtonList-Steuerelemente die folgenden neuen Werte für die RepeatLayout-Eigenschaft :

• OrderedList – Der Inhalt wird als li-Elemente innerhalb eines Ol-Elements gerendert.
• UnorderedList – Der Inhalt wird als li-Elemente innerhalb eines ul-Elements gerendert.

Das folgende Beispiel zeigt, wie diese neuen Werte verwendet werden.

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

Das oben gezeigte Markup generiert den folgenden HTML-Code:

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

Hinweis

Hinweis: Wenn Sie "RepeatLayout " auf "OrderedList " oder " UnorderedList" festlegen, kann die RepeatDirection-Eigenschaft nicht mehr verwendet werden und löst zur Laufzeit eine Ausnahme aus, wenn die Eigenschaft im Markup oder Code festgelegt wurde. Die Eigenschaft hätte keinen Wert, da das visuelle Layout dieser Steuerelemente stattdessen mithilfe von CSS definiert wird.

Verbesserungen der Menüsteuerung

Vor ASP.NET 4 hat das Menüsteuerelement eine Reihe von HTML-Tabellen gerendert. Dadurch wurde es schwieriger, CSS-Stile außerhalb der Einstellung von Inlineeigenschaften anzuwenden und entsprach nicht den Barrierefreiheitsstandards.

In ASP.NET 4 rendert das Steuerelement jetzt HTML mithilfe des semantischen Markups, das aus einer nicht sortierten Liste und Listenelementen besteht. Das folgende Beispiel zeigt Markup auf einer ASP.NET Seite für das Menüsteuerelement .

<asp:Menu ID="Menu1" runat="server"> 
  <Items> <asp:MenuItem Text="Home" Value="Home" /> 
    <asp:MenuItem Text="About" Value="About" /> 
  </Items> 

</asp:Menu>

Wenn die Seite gerendert wird, erzeugt das Steuerelement den folgenden HTML-Code (der Onclick-Code wurde aus Gründen der Übersichtlichkeit weggelassen):

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

Zusätzlich zu Renderingverbesserungen wurde die Tastaturnavigation des Menüs mithilfe der Fokusverwaltung verbessert. Wenn das Menüsteuerelement den Fokus erhält, können Sie mithilfe der Pfeiltasten zu Elementen navigieren. Das Menüsteuerelement fügt nun auch ARIA-Rollen und -Attribute entsprechend den Menü-ARIA-Richtlinien hinzu, um die Barrierefreiheit zu verbessern.

Formatvorlagen für das Menüsteuerelement werden in einem Formatvorlagenblock oben auf der Seite gerendert, anstatt in Übereinstimmung mit den gerenderten HTML-Elementen. Wenn Sie die vollständige Kontrolle über die Formatierung für das Steuerelement übernehmen möchten, können Sie die neue IncludeStyleBlock-Eigenschaft auf "false" festlegen. In diesem Fall wird der Formatvorlagenblock nicht ausgegeben. Eine Möglichkeit, diese Eigenschaft zu verwenden, besteht darin, das Autoformat-Feature im Visual Studio-Designer zu verwenden, um die Darstellung des Menüs festzulegen. Anschließend können Sie die Seite ausführen, die Seitenquelle öffnen und dann den gerenderten Formatvorlagenblock in eine externe CSS-Datei kopieren. Machen Sie in Visual Studio das Format rückgängig, und legen Sie IncludeStyleBlock auf "false" fest. Das Ergebnis ist, dass die Menüdarstellung mithilfe von Formatvorlagen in einem externen Stylesheet definiert wird.

Assistent und CreateUserWizard-Steuerelemente

Der ASP.NET-Assistent und die CreateUserWizard-Steuerelemente unterstützen Vorlagen, mit denen Sie den html-Code definieren können, den sie rendern. (CreateUserWizard wird von Wizard abgeleitet.) Das folgende Beispiel zeigt das Markup für ein vollständig vorlagenbasiertes CreateUserWizard-Steuerelement :

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

Das Steuerelement rendert HTML ähnlich wie folgt:

<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 können Sie zwar den Inhalt der Vorlage ändern, aber Sie haben weiterhin eingeschränkte Kontrolle über die Ausgabe des Wizard-Steuerelements. In ASP.NET 4 können Sie eine LayoutTemplate-Vorlage erstellen und Platzhalter-Steuerelemente mit reservierten Namen einfügen, um festzulegen, wie das Wizard-Steuerelement gerendert werden soll. Dies wird im folgenden Beispiel veranschaulicht:

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

Das Beispiel enthält die folgenden benannten Platzhalter im LayoutTemplate-Element :

• headerPlaceholder – Zur Laufzeit wird dies durch den Inhalt des HeaderTemplate-Elements ersetzt.
• sideBarPlaceholder – Zur Laufzeit wird dies durch den Inhalt des SideBarTemplate-Elements ersetzt.
• wizardStepPlaceHolder – Zur Laufzeit wird dies durch den Inhalt des WizardStepTemplate-Elements ersetzt.
• navigationPlaceholder – Zur Laufzeit wird dies durch alle navigationsvorlagen ersetzt, die Sie definiert haben.

Das Markup im Beispiel, in dem Platzhalter verwendet werden, rendert den folgenden HTML-Code (ohne dass der Inhalt tatsächlich in den Vorlagen definiert ist):

<span>
</span>

Der einzige HTML-Code, der jetzt nicht benutzerdefinierte ist, ist ein Span-Element . (Wir gehen davon aus, dass in zukünftigen Versionen auch das Span-Element nicht gerendert wird.) Dadurch erhalten Sie jetzt die vollständige Kontrolle über nahezu alle Inhalte, die vom Assistenten-Steuerelement generiert werden.

ASP.NET MVC

ASP.NET MVC wurde im März 2009 als Add-On-Framework für ASP.NET 3.5 SP1 eingeführt. Visual Studio 2010 enthält ASP.NET MVC 2, das neue Features und Funktionen enthält.

Bereichsunterstützung

Mithilfe von Bereichen können Sie Controller und Ansichten in Abschnitte einer großen Anwendung in relativer Isolation von anderen Abschnitten gruppieren. Jeder Bereich kann als separates ASP.NET MVC-Projekt implementiert werden, auf das dann von der Hauptanwendung verwiesen werden kann. Dadurch können Sie die Komplexität verwalten, wenn Sie eine große Anwendung erstellen und es für mehrere Teams einfacher machen, an einer einzelnen Anwendung zusammenzuarbeiten.

Data-Annotation Unterstützung der Attributüberprüfung

Mit DataAnnotations-Attributen können Sie mithilfe von Metadatenattributen Eine Validierungslogik an ein Modell anfügen. DataAnnotations-Attribute wurden in ASP.NET Dynamic Data in ASP.NET 3.5 SP1 eingeführt. Diese Attribute wurden in den Standardmodellordner integriert und stellen eine metadatengesteuerte Möglichkeit zur Überprüfung der Benutzereingabe bereit.

Vorlagenbasierte Hilfsprogramme

Vorlagenbasierte Hilfsprogramme ermöglichen es Ihnen, Automatisch Bearbeitungs- und Anzeigevorlagen mit Datentypen zu verknüpfen. Sie können z. B. eine Vorlagenhilfe verwenden, um anzugeben, dass ein Datumsauswahl-UI-Element automatisch für einen System.DateTime-Wert gerendert wird. Dies ähnelt Feldvorlagen in ASP.NET dynamischen Daten.

Die Html.EditorFor - und Html.DisplayFor-Hilfsmethoden verfügen über integrierte Unterstützung für das Rendern von Standarddatentypen sowie komplexe Objekte mit mehreren Eigenschaften. Sie passen auch das Rendering an, indem Sie Datenanmerkungsattribute wie DisplayName und ScaffoldColumn auf das ViewModel-Objekt anwenden können.

Häufig möchten Sie die Ausgabe von Ui-Helfern noch weiter anpassen und die vollständige Kontrolle über das generierte Ergebnis haben. Die Html.EditorFor - und Html.DisplayFor-Hilfsmethoden unterstützen dies mithilfe eines Vorlagenmechanismus, mit dem Sie externe Vorlagen definieren können, die die gerenderte Ausgabe außer Kraft setzen und steuern können. Die Vorlagen können einzeln für eine Klasse gerendert werden.

Dynamische Daten

Dynamische Daten wurden mitte 2008 in der .NET Framework 3.5 SP1-Version eingeführt. Dieses Feature bietet viele Verbesserungen beim Erstellen von datengesteuerten Anwendungen, einschließlich der folgenden:

• Eine RAD-Erfahrung zum schnellen Erstellen einer datengesteuerten Website.
• Automatische Überprüfung, die auf im Datenmodell definierten Einschränkungen basiert.
• Die Möglichkeit zum einfachen Ändern des Markups, das für Felder in den GridView- und DetailsView-Steuerelementen generiert wird, mithilfe von Feldvorlagen, die Teil Ihres Dynamic Data-Projekts sind.

Hinweis

Weitere Informationen finden Sie in der Dokumentation zu dynamischen Daten in der MSDN Library.

Für ASP.NET 4 wurde Dynamische Daten verbessert, um Entwicklern noch mehr Energie für das schnelle Erstellen von datengesteuerten Websites zu bieten.

Aktivieren von dynamischen Daten für vorhandene Projekte

Dynamische Datenfeatures, die in .NET Framework 3.5 SP1 ausgeliefert wurden, haben neue Features wie die folgenden bereitgestellt:

• Feldvorlagen – Diese stellen datentypbasierte Vorlagen für datengebundene Steuerelemente bereit. Feldvorlagen bieten eine einfachere Möglichkeit, das Aussehen von Datensteuerelementen anzupassen, als Vorlagenfelder für jedes Feld zu verwenden.
• Überprüfung – Mit dynamischen Daten können Sie Attribute für Datenklassen verwenden, um die Überprüfung für allgemeine Szenarien wie Erforderliche Felder, Bereichsprüfung, Typüberprüfung, Musterabgleich mit regulären Ausdrücken und benutzerdefinierte Überprüfung anzugeben. Die Validierung wird durch die Datensteuerungselemente erzwungen.

Diese Features weisen jedoch die folgenden Anforderungen auf:

• Die Datenzugriffsebene musste auf Entity Framework oder LINQ to SQL basieren.
• Die einzigen Datenquellensteuerelemente, die für diese Features unterstützt werden, waren die Steuerelemente "EntityDataSource " oder "LinqDataSource" .
• Die Features erfordern ein Webprojekt, das mithilfe der Vorlagen "Dynamic Data" oder "Dynamic Data Entities" erstellt wurde, damit alle Dateien vorhanden sind, die für die Unterstützung des Features erforderlich waren.

Ein wichtiges Ziel der Unterstützung dynamischer Daten in ASP.NET 4 besteht darin, die neue Funktionalität dynamischer Daten für jede ASP.NET Anwendung zu ermöglichen. Das folgende Beispiel zeigt Markup für Steuerelemente, die dynamische Datenfunktionen auf einer vorhandenen Seite nutzen können.

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

Im Code für die Seite muss der folgende Code hinzugefügt werden, um die Unterstützung dynamischer Daten für diese Steuerelemente zu aktivieren:

GridView1.EnableDynamicData(typeof(Product));

Wenn sich das GridView-Steuerelement im Bearbeitungsmodus befindet, überprüft Dynamic Data automatisch, dass die eingegebenen Daten im richtigen Format vorliegen. Wenn dies nicht der Fehler ist, wird eine Fehlermeldung angezeigt.

Diese Funktionalität bietet auch andere Vorteile, z. B. die Möglichkeit, Standardwerte für den Einfügemodus anzugeben. Ohne dynamische Daten müssen Sie, um einen Vorgabewert für ein Feld zu implementieren, sich an ein Ereignis binden, das Steuerelement (mithilfe von FindControl) suchen und dessen Wert festlegen. In ASP.NET 4 unterstützt der EnableDynamicData-Aufruf einen zweiten Parameter, mit dem Sie Standardwerte für jedes Feld des Objekts übergeben können, wie in diesem Beispiel gezeigt:

DetailsView1.EnableDynamicData(typeof(Product), new { ProductName = "DefaultName" });

Deklarative Syntax des DynamicDataManager-Steuerelements

Das DynamicDataManager-Steuerelement wurde verbessert, sodass Sie es deklarativ konfigurieren können, wie bei den meisten Steuerelementen in ASP.NET, anstatt nur im Code. Das Markup für das DynamicDataManager-Steuerelement sieht wie im folgenden Beispiel aus:

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

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

Dieses Markup ermöglicht das Dynamische Datenverhalten für das GridView1-Steuerelement, auf das im Abschnitt "DataControls " des DynamicDataManager-Steuerelements verwiesen wird.

Entitätsvorlagen

Entitätsvorlagen bieten eine neue Möglichkeit zum Anpassen des Layouts von Daten, ohne dass Sie eine benutzerdefinierte Seite erstellen müssen. Seitenvorlagen verwenden das FormView-Steuerelement (anstelle des DetailsView-Steuerelements , wie in Seitenvorlagen in früheren Versionen von Dynamischen Daten verwendet) und das DynamicEntity-Steuerelement zum Rendern von Entitätsvorlagen. Dadurch erhalten Sie mehr Kontrolle über das Markup, das von Dynamic Data gerendert wird.

Die folgende Liste zeigt das neue Projektverzeichnislayout, das Entitätsvorlagen enthält:

\DynamicData\EntityTemplates
\DynamicData\EntityTemplates\Default.ascx
\DynamicData\EntityTemplates\Default_Edit.ascx
\DynamicData\EntityTemplates\Default_Insert.ascx

Das EntityTemplate Verzeichnis enthält Vorlagen zum Anzeigen von Datenmodellobjekten. Standardmäßig werden Objekte mithilfe der Default.ascx Vorlage gerendert, die Markup bereitstellt, das genau wie das markup aussieht, das vom DetailsView-Steuerelement erstellt wurde, das von Dynamic Data in ASP.NET 3.5 SP1 verwendet wird. Das folgende Beispiel zeigt das Markup für das Default.ascx Steuerelement:

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

Die Standardvorlagen können bearbeitet werden, um das Aussehen und Verhalten für die gesamte Website zu ändern. Es gibt Vorlagen für Anzeige-, Bearbeitungs- und Einfügevorgänge. Neue Vorlagen können basierend auf dem Namen des Datenobjekts hinzugefügt werden, um das Aussehen und Verhalten von nur einem Objekttyp zu ändern. Sie können beispielsweise die folgende Vorlage hinzufügen:

\DynamicData\EntityTemplates\Products.aspx

Die Vorlage kann das folgende Markup enthalten:

<tr> 
  <td>Name</td> 
  <td><asp:DynamicControl runat="server" DataField="ProductName" /></td> 
  <td>Category</td> 
  <td><asp:DynamicControl runat="server" DataField="Category" /></td> 

</tr>

Die neuen Entitätsvorlagen werden auf einer Seite mithilfe des neuen DynamicEntity-Steuerelements angezeigt. Zur Laufzeit wird dieses Steuerelement durch den Inhalt der Entitätsvorlage ersetzt. Das folgende Markup zeigt das FormView-Steuerelement in der Detail.aspx Seitenvorlage, die die Entitätsvorlage verwendet. Beachten Sie das DynamicEntity-Element im 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>

Neue Feldvorlagen für URLs und E-Mail-Adressen

** ASP.NET 4 führt zwei neue integrierte Feldvorlagen ein, EmailAddress.ascx und Url.ascx. Diese Vorlagen werden für Felder verwendet, die mit dem DataType-Attribut als "EmailAddress" oder "URL" gekennzeichnet sind. Bei EmailAddress-Objekten wird das Feld als Link angezeigt, der mithilfe des mailto: -Protokolls erstellt wird. Wenn Benutzer auf den Link klicken, wird der E-Mail-Client des Benutzers geöffnet und eine Skelettnachricht erstellt. Als URL eingegebene Objekte werden als normale Hyperlinks angezeigt.

Das folgende Beispiel zeigt, wie Felder markiert werden.

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

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

Erstellen von Links mit dem DynamicHyperLink-Steuerelement

Dynamische Daten verwenden das neue Routingfeature, das im .NET Framework 3.5 SP1 hinzugefügt wurde, um die URLs zu steuern, die Endbenutzer sehen, wenn sie auf die Website zugreifen. Das neue DynamicHyperLink-Steuerelement erleichtert das Erstellen von Links zu Seiten auf einer Dynamischen Datenwebsite. Das folgende Beispiel zeigt die Verwendung des DynamicHyperLink-Steuerelements :

<asp:DynamicHyperLink ID="ListHyperLink" runat="server" 
    Action="List" TableName="Products"> 
    Show all products 
</asp:DynamicHyperLink>

Dieses Markup erstellt einen Link, der auf die Listenseite für die Products Tabelle verweist, basierend auf Routen, die in der Global.asax Datei definiert sind. Das Steuerelement verwendet automatisch den Standardtabellennamen, auf dem die Seite "Dynamische Daten" basiert.

Unterstützung der Vererbung im Datenmodell

Sowohl das Entity Framework als auch LINQ to SQL unterstützen die Vererbung in ihren Datenmodellen. Ein Beispiel hierfür ist eine Datenbank mit einer InsurancePolicy Tabelle. Sie kann auch CarPolicy und HousePolicy Tabellen enthalten, die dieselben Felder wie InsurancePolicy haben und dann weitere Felder hinzufügen. Dynamische Daten wurden geändert, um geerbte Objekte im Datenmodell zu verstehen und das Gerüst für die geerbten Tabellen zu unterstützen.

Unterstützung für n:n-Beziehungen (nur Entity Framework)

Das Entity Framework bietet umfassende Unterstützung für m:n-Beziehungen zwischen Tabellen, die implementiert werden, indem die Beziehung als Auflistung an einem Entity-Objekt bereitgestellt wird. Neue ManyToMany.ascx und ManyToMany_Edit.ascx Feldvorlagen wurden hinzugefügt, um Unterstützung für das Anzeigen und Bearbeiten von Daten bereitzustellen, die an Viele-zu-Viele-Beziehungen beteiligt sind.

Neue Attribute zum Steuern der Anzeige und Unterstützung von Enumerationen

Das DisplayAttribute wurde hinzugefügt, um Ihnen zusätzliche Kontrolle darüber zu geben, wie Felder angezeigt werden. Mit dem DisplayName-Attribut in früheren Versionen von Dynamic Data können Sie den Namen ändern, der als Beschriftung für ein Feld verwendet wird. Mit der neuen DisplayAttribute-Klasse können Sie weitere Optionen zum Anzeigen eines Felds angeben, z. B. die Reihenfolge, in der ein Feld angezeigt wird und ob ein Feld als Filter verwendet wird. Das Attribut bietet auch unabhängige Kontrolle über den Namen, der in einem GridView-Steuerelement verwendet wird, den Namen in einem DetailsView-Steuerelement, den Hilfetext für das Feld sowie das Wasserzeichen, das für das Feld verwendet wird (sofern das Feld Texteingaben akzeptiert).

Die EnumDataTypeAttribute-Klasse wurde hinzugefügt, damit Sie Felder Enumerationen zuordnen können. Wenn Sie dieses Attribut auf ein Feld anwenden, geben Sie einen Enumerationstyp an. Dynamische Daten verwenden die neue Enumeration.ascx Feldvorlage zum Erstellen der Benutzeroberfläche zum Anzeigen und Bearbeiten von Enumerationswerten. Die Vorlage ordnet die Werte aus der Datenbank den Namen in der Enumeration zu.

Erweiterte Unterstützung für Filter

Dynamic Data 1.0 wurde mit integrierten Filtern für boolesche Spalten und Fremdschlüsselspalten ausgeliefert. Mit den Filtern konnten Sie nicht angeben, ob sie angezeigt wurden oder in welcher Reihenfolge sie angezeigt wurden. Das neue DisplayAttribute-Attribut behebt beide Probleme, indem Sie steuern, ob eine Spalte als Filter angezeigt wird und in welcher Reihenfolge sie angezeigt wird.

Eine weitere Verbesserung besteht darin, dass die Filterunterstützung neugeschrieben wurde, um das neue Feature von Web Forms zu verwenden. Auf diese Weise können Sie Filter erstellen, ohne Kenntnisse über die Datenquellensteuerung zu benötigen, mit der die Filter verwendet werden sollen. Zusammen mit diesen Erweiterungen wurden auch Filter in Vorlagensteuerelemente umgewandelt, mit denen Sie neue hinzufügen können. Schließlich ermöglicht die zuvor erwähnte DisplayAttribute-Klasse , dass der Standardfilter überschrieben wird, auf die gleiche Weise wie UIHint die Standardfeldvorlage für eine Spalte außer Kraft setzen kann.

Verbesserungen bei der Webentwicklung in Visual Studio 2010

Die Webentwicklung in Visual Studio 2010 wurde für eine höhere CSS-Kompatibilität, eine höhere Produktivität durch HTML und ASP.NET Markupausschnitte und neues dynamisches IntelliSense-JavaScript verbessert.

Verbesserte CSS-Kompatibilität

Der Visual Web Developer-Designer in Visual Studio 2010 wurde aktualisiert, um die Css 2.1-Standardskonformität zu verbessern. Der Designer behält die Integrität der HTML-Quelle besser bei und ist robuster als in früheren Versionen von Visual Studio. Unter der Haube wurden auch Architekturverbesserungen vorgenommen, die zukünftige Verbesserungen beim Rendern, Layout und der Wartungsfreundlichkeit erleichtern.

HTML- und JavaScript-Codeausschnitte

Im HTML-Editor vervollständigt IntelliSense die Tagnamen automatisch. Die Funktion „IntelliSense-Snippets“ vervollständigt automatisch ganze Tags und mehr. In Visual Studio 2010 werden IntelliSense-Codeausschnitte für JavaScript zusammen mit C# und Visual Basic unterstützt, die in früheren Versionen von Visual Studio unterstützt wurden.

Visual Studio 2010 enthält über 200 Codeausschnitte, die Ihnen helfen, allgemeine ASP.NET und HTML-Tags automatisch abzuschließen, einschließlich der erforderlichen Attribute (z. B. runat="server") und allgemeinen Attributen, die für ein Tag spezifisch sind (z. B. ID, DataSourceID, ControlToValidate und Text).

Sie können zusätzliche Codeausschnitte herunterladen oder eigene Codeausschnitte schreiben, die die Blöcke des Markups kapseln, die Sie oder Ihr Team für allgemeine Aufgaben verwenden.

JavaScript IntelliSense-Verbesserungen

In Visual 2010 wurde JavaScript IntelliSense neu gestaltet, um eine noch umfangreichere Bearbeitung zu ermöglichen. IntelliSense erkennt jetzt Objekte, die dynamisch von Methoden wie registerNamespace und ähnlichen Techniken generiert wurden, die von anderen JavaScript-Frameworks verwendet werden. Die Leistung wurde verbessert, um große Skriptbibliotheken zu analysieren und IntelliSense mit wenig oder ohne Verarbeitungsverzögerung anzuzeigen. Die Kompatibilität wurde erheblich erhöht, um nahezu alle Drittanbieterbibliotheken zu unterstützen und verschiedene Codierungsstile zu unterstützen. Dokumentationskommentare werden jetzt während der Eingabe analysiert und sofort von IntelliSense genutzt.

Webanwendungsbereitstellung mit Visual Studio 2010

Wenn ASP.NET Entwickler eine Webanwendung bereitstellen, stellen sie häufig fest, dass probleme auftreten, z. B. die folgenden:

• Die Bereitstellung auf einer geteilten Hosting-Site erfordert Technologien wie FTP, was langsam sein kann. Darüber hinaus müssen Sie Aufgaben wie das Ausführen von SQL-Skripts manuell ausführen, um eine Datenbank zu konfigurieren, und Sie müssen IIS-Einstellungen ändern, z. B. das Konfigurieren eines virtuellen Verzeichnisordners als Anwendung.
• In einer Unternehmensumgebung müssen Administratoren neben der Bereitstellung der Webanwendungsdateien häufig ASP.NET Konfigurationsdateien und IIS-Einstellungen ändern. Datenbankadministratoren müssen eine Reihe von SQL-Skripts ausführen, um die Anwendungsdatenbank auszuführen. Solche Installationen sind arbeitsintensiv, dauern oft Stunden und müssen sorgfältig dokumentiert werden.

Visual Studio 2010 enthält Technologien, mit denen diese Probleme behoben werden, und mit denen Sie Webanwendungen nahtlos bereitstellen können. Eine dieser Technologien ist das IIS Web Deployment Tool (MsDeploy.exe).

Webbereitstellungsfeatures in Visual Studio 2010 umfassen die folgenden Hauptbereiche:

• Webpaketierung
• Web.config-Transformation
• Datenbankbereitstellung
• Veröffentlichung mit nur einem Klick für Webanwendungen

Die folgenden Abschnitte enthalten Details zu diesen Features.

Webverpackungen

Visual Studio 2010 verwendet das MSDeploy-Tool, um eine komprimierte (.zip) Datei für Ihre Anwendung zu erstellen, die als Webpaket bezeichnet wird. Die Paketdatei enthält Metadaten zu Ihrer Anwendung sowie den folgenden Inhalt:

• IIS-Einstellungen, die Anwendungspooleinstellungen, Fehlerseiteneinstellungen usw. umfassen.
• Der tatsächliche Webinhalt, der Webseiten, Benutzersteuerelemente, statische Inhalte (Bilder und HTML-Dateien) enthält usw.
• SQL Server-Datenbankschemas und -Daten.
• Sicherheitszertifikate, Komponenten, die im GAC installiert werden sollen, Registrierungseinstellungen usw.

Ein Webpaket kann auf einen beliebigen Server kopiert und dann manuell mithilfe des IIS-Managers installiert werden. Alternativ kann das Paket für die automatisierte Bereitstellung mithilfe von Befehlszeilenbefehlen oder mithilfe von Bereitstellungs-APIs installiert werden.

Visual Studio 2010 bietet integrierte MSBuild-Aufgaben und -Ziele zum Erstellen von Webpaketen. Weitere Informationen finden Sie unter ASP.NET Übersicht über die Webanwendungsprojektbereitstellung auf der MSDN-Website und 10 + 20 Gründe, warum Sie ein Webpaket auf Vishal Joshis Blog erstellen sollten.

Web.config Transformation

Für die Webanwendungsbereitstellung führt Visual Studio 2010 DIE XML-Dokumenttransformation (XDT) ein, mit der Sie eine Web.config Datei von Entwicklungseinstellungen in Produktionseinstellungen transformieren können. Transformationseinstellungen werden in Transformationsdateien namens web.debug.config, web.release.configusw. angegeben. (Die Namen dieser Dateien stimmen mit MSBuild-Konfigurationen überein.) Eine Transformationsdatei enthält nur die Änderungen, die Sie an einer bereitgestellten Web.config Datei vornehmen müssen. Sie geben die Änderungen mithilfe einer einfachen Syntax an.

Das folgende Beispiel zeigt einen Teil einer web.release.config Datei, die für die Bereitstellung Ihrer Releasekonfiguration erstellt werden kann. Das Schlüsselwort Replace im Beispiel gibt an, dass während der Bereitstellung der ConnectionString-Knoten in der Web.config Datei durch die Werte ersetzt wird, die im Beispiel aufgeführt sind.

<connectionStrings xdt:Transform="Replace"> 
  <add name="BlogDB" connectionString="connection string detail]" /> 

</connectionStrings>

Weitere Informationen finden Sie unter Web.config-Transformationssyntax für die Bereitstellung von Webanwendungsprojekten auf der MSDN-Website und Webbereitstellung: Web.config-Transformation auf Vishal Joshis Blog.

Datenbankbereitstellung

Ein Visual Studio 2010-Bereitstellungspaket kann Abhängigkeiten von SQL Server-Datenbanken enthalten. Als Teil der Paketdefinition stellen Sie die Verbindungszeichenfolge für Ihre Quelldatenbank bereit. Wenn Sie das Webpaket erstellen, erstellt Visual Studio 2010 SQL-Skripts für das Datenbankschema und optional für die Daten und fügt diese dann dem Paket hinzu. Sie können auch benutzerdefinierte SQL-Skripts bereitstellen und die Reihenfolge angeben, in der sie auf dem Server ausgeführt werden sollen. Zur Bereitstellungszeit stellen Sie eine Verbindungszeichenfolge bereit, die für den Zielserver geeignet ist; anschließend verwendet der Bereitstellungsprozess diese Verbindungszeichenfolge, um die Skripts auszuführen, die das Datenbankschema erstellen und die Daten hinzufügen.

Darüber hinaus können Sie mithilfe der Veröffentlichung mit einem Klick die Bereitstellung so konfigurieren, dass die Datenbank direkt veröffentlicht wird, wenn die Anwendung auf einer gemeinsam genutzten, remote gehosteten Website veröffentlicht wird. Weitere Informationen finden Sie unter How to: Deploy a Database With a Web Application Project auf der MSDN-Website und Database Deployment with VS 2010 auf Vishal Joshis Blog.

Ein-Klick-Veröffentlichung für Webanwendungen

In Visual Studio 2010 können Sie auch den IIS-Remoteverwaltungsdienst verwenden, um eine Webanwendung auf einem Remoteserver zu veröffentlichen. Sie können ein Veröffentlichungsprofil für Ihr Hostingkonto oder für Testserver oder Stagingserver erstellen. Jedes Profil kann geeignete Anmeldeinformationen sicher speichern. Sie können dann mit nur einem Klick auf jeden der Zielserver veröffentlichen, indem Sie die Web-Ein-Klick-Veröffentlichungsleiste verwenden. Mit Visual Studio 2010 können Sie auch mithilfe der MSBuild-Befehlszeile veröffentlichen. Auf diese Weise können Sie Ihre Teambuildumgebung so konfigurieren, dass sie die Veröffentlichung in ein fortlaufendes Integrationsmodell einschließt.

Weitere Informationen finden Sie unter How to: Deploy a Web Application Project Using One-Click Publish and Web Deploy auf der MSDN-Website und Web 1-Click Publish with VS 2010 auf Vishal Joshis Blog. Um Videopräsentationen zur Webanwendungsbereitstellung in Visual Studio 2010 anzuzeigen, finden Sie 'VS 2010 for Web Developer Previews' im Blog von Vishal Joshi.

Ressourcen

Die folgenden Websites enthalten zusätzliche Informationen zu ASP.NET 4 und Visual Studio 2010.

• ASP.NET 4 – Die offizielle Dokumentation für ASP.NET 4 auf der MSDN-Website.
• https://www.asp.net/ — Die eigene Website des ASP.NET Teams.
• https://www.asp.net/dynamicdata/ und ASP.NET Dynamische Dateninhaltsübersicht – Onlineressourcen auf der ASP.NET Teamwebsite und in der offiziellen Dokumentation für ASP.NET Dynamische Daten.
• https://www.asp.net/ajax/ — Die Hauptwebressource für ASP.NET Ajax-Entwicklung.
• https://devblogs.microsoft.com/dotnet/category/aspnet/ – Der Blog des Visual Web Developer Teams, der Informationen zu Features in Visual Studio 2010 enthält.
• ASP.NET WebStack – Die Hauptwebressource für Vorschauversionen von ASP.NET.

Haftungsausschluss

Dies ist ein vorläufiges Dokument und kann erheblich vor der endgültigen kommerziellen Veröffentlichung der hier beschriebenen Software geändert werden.

Die in diesem Dokument enthaltenen Informationen stellen die Sicht der Microsoft Corporation der hier diskutierten Themen zum Zeitpunkt der Veröffentlichung dar. Da Microsoft auf sich ändernde Marktbedingungen reagieren muss, sollte dies nicht als Verpflichtung von Microsoft interpretiert werden, und Microsoft kann nicht für die Richtigkeit der nach dem Datum der Veröffentlichung vorgelegten Informationen garantieren.

Dieses Weißbuch dient nur zu Informationszwecken. MICROSOFT ÜBERNIMMT BEZÜGLICH DER INFORMATIONEN IN DIESEM DOKUMENT KEINE GEWÄHRLEISTUNGEN, SEI SIE AUSDRÜCKLICH, KONKLUDENT ODER GESETZLICH GEREGELT.

Die Einhaltung aller anwendbaren Urheberrechtsgesetze liegt in der Verantwortung des Nutzers. Ohne Einschränkung der Rechte des Urheberrechts kann kein Teil dieses Dokuments in einem Abrufsystem vervielfältigt, in einem Abrufsystem gespeichert oder in irgendeiner Form oder auf irgendeine Weise übertragen werden (elektronische, mechanische, Fotokopie, Aufzeichnung oder anderweitig), oder zu irgendeinem Zweck, ohne die ausdrückliche schriftliche Erlaubnis der Microsoft Corporation.

Microsoft verfügt möglicherweise über Patente, Patentanmeldungen, Marken, Urheberrechte oder andere Rechte des geistigen Eigentums, die Gegenstand dieses Dokuments abdecken. Sofern nicht ausdrücklich in einem schriftlichen Lizenzvertrag von Microsoft vorgesehen, erhalten Sie durch die Bereitstellung dieses Dokuments keine Lizenz für diese Patente, Marken, Urheberrechte oder andere geistiges Eigentum.

Sofern nicht anders angegeben, sind die Hierin dargestellten Beispielunternehmen, Organisationen, Produkte, Domänennamen, E-Mail-Adressen, Logos, Personen, Orte und Ereignisse fikttiv, und keine Zuordnung zu einem echten Unternehmen, Unternehmen, Produkt, Domänennamen, E-Mail-Adresse, Logo, Person, Ort oder Ereignis ist vorgesehen oder sollte abgeleitet werden.

© 2009 Microsoft Corporation. Alle Rechte vorbehalten.

Microsoft und Windows sind entweder eingetragene Marken oder Marken der Microsoft Corporation in den USA und/oder anderen Ländern.

Die Namen der tatsächlichen Unternehmen und Produkte, die hier erwähnt werden, können die Marken ihrer jeweiligen Eigentümer sein.