Übersicht über ASP.NET 4 und Visual Studio 2010 für die Webentwicklung

2023-07-13

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-Dateien
Erweiterbare Ausgabezwischenspeicherung
Webanwendungen für den automatischen Start
Dauerhaftes Umleiten einer Seite
Verkleinern des Sitzungszustands
Erweitern des Bereichs zulässiger URLs
Erweiterbare Anforderungsüberprüfung
Erweiterbarkeit zwischen Objektzwischenspeicherung und Objektzwischenspeicherung
Erweiterbare HTML-, URL- und HTTP-Headercodierung
Leistungsüberwachung für einzelne Anwendungen in einem einzelnen Arbeitsprozess
Multi-Targeting

Ajax
jQuery in Web Forms und MVC enthalten
Content Delivery Network-Unterstützung
Explizite ScriptManager-Skripts

Web Forms
Festlegen von Metatags mit den Eigenschaften Page.MetaKeywords und Page.MetaDescription
Aktivieren des Ansichtszustands 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 Steuerelemente mit Vorlagen
Verbesserungen des ListView-Steuerelements
Verbesserungen des CheckBoxList- und RadioButtonList-Steuerelements
Verbesserungen bei Menüsteuerelementen
Assistenten und CreateUserWizard-Steuerelemente 56

ASP.NET MVC
Bereichsunterstützung
Unterstützung für die Validierung von Datenanmerkungen-Attributen
Vorlagenhilfsprogramme

Dynamische Daten
Aktivieren von dynamischen Daten für vorhandene Projekte
Deklarative DynamicDataManager-Steuerelementsyntax
Entitätsvorlagen
Neue Feldvorlagen für URLs und E-Mail-Adressen
Erstellen von Links mit dem DynamicHyperLink-Steuerelement
Unterstützung für vererbung im Datenmodell
Unterstützung für m:n-Beziehungen (nur Entity Framework)
Neue Attribute zum Steuern der Anzeige und Unterstützung von Enumerationen
Erweiterte Unterstützung für Filter

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

Webanwendungsbereitstellung mit Visual Studio 2010
Webverpackung
Web.config Transformation
Datenbankbereitstellung
1-Klick veröffentlichen für Webanwendungen
Ressourcen

Haftungsausschluss

Kerndienste

ASP.NET 4 führt eine Reihe von Features ein, die kernige ASP.NET Dienste wie ausgabebasierte Zwischenspeicherung und Sitzungszustandsspeicherung verbessern.

refactoring von Web.config-Dateien

Die Web.config Datei, die die Konfiguration für eine Webanwendung enthält, ist in den letzten Releases des .NET Framework erheblich gewachsen, da neue Features hinzugefügt wurden, z. B. Ajax, Routing und Integration in IIS 7. Dadurch wurde es schwieriger, neue Webanwendungen ohne ein Tool wie Visual Studio zu konfigurieren oder zu starten. In .the NET Framework 4 wurden die hauptkonfigurationselemente in die machine.config Datei verschoben, und Anwendungen erben jetzt diese Einstellungen. Dadurch 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 abzielt:

<?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 ermöglichte die Ausgabezwischenspeicherung Entwicklern, die generierte Ausgabe von Seiten, Steuerelementen und HTTP-Antworten im Arbeitsspeicher zu speichern. Bei nachfolgenden Webanforderungen können ASP.NET Inhalte schneller bereitstellen, indem sie die generierte Ausgabe aus dem Arbeitsspeicher abrufen, 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 mit hohem Datenverkehr kann der durch die Ausgabezwischenspeicherung belegte Arbeitsspeicher mit Speicheranforderungen aus anderen Teilen einer Webanwendung konkurrieren.

ASP.NET 4 fügt der Ausgabezwischenspeicherung einen Erweiterbarkeitspunkt hinzu, mit dem Sie einen oder mehrere benutzerdefinierte Ausgabecacheanbieter konfigurieren können. Ausgabecacheanbieter können einen beliebigen Speichermechanismus verwenden, um HTML-Inhalte beizubehalten. Dies ermöglicht es, benutzerdefinierte Ausgabecacheanbieter für verschiedene Persistenzmechanismen zu erstellen, die lokale oder Remotedatenträger, Cloudspeicher und verteilte Cache-Engines 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 In-Memory-Ausgabecache, 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 verschiedene Ausgabecacheanbieter pro Steuerelement und pro Anforderung auswählen. Die einfachste Möglichkeit, einen anderen Ausgabecacheanbieter für verschiedene Webbenutzersteuerelemente auszuwählen, ist die deklarative Verwendung des neuen providerName-Attributs in einer Steuerelementdirektive, 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 Aufwand. 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 die erforderliche Vorgehensweise.

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

Mit der Erweiterung des Ausgabecacheanbieters auf ASP.NET 4 können Sie jetzt aggressivere und intelligentere Output-Caching-Strategien 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 weniger Datenverkehr auf dem Datenträger erhalten. Alternativ können Sie jede kombinationsbasierte Kombination für eine gerenderte Seite zwischenspeichern, aber einen verteilten Cache verwenden, damit der Arbeitsspeicherverbrauch von Front-End-Webservern ausgelagert wird.

Webanwendungen für den automatischen Start

Einige Webanwendungen müssen große Datenmengen laden oder eine aufwendige 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 "Reaktivieren" einer ASP.NET-Anwendung entwickeln und dann den Initialisierungscode während der Application_Load-Methode in der Global.asax Datei ausführen.

Wenn ASP.NET 4 unter IIS 7.5 unter Windows Server 2008 R2 ausgeführt wird, steht ein neues Skalierbarkeitsfeature namens Autostart zur Verfügung, das dieses Szenario direkt adressiert. Das Feature für den automatischen Start bietet einen kontrollierten Ansatz für das Starten eines Anwendungspools, das Initialisieren einer ASP.NET Anwendung und das anschließende Akzeptieren von HTTP-Anforderungen.

Hinweis

IIS Application Warm-Up Module für IIS 7.5

Das IIS-Team hat die erste Beta-Testversion 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 Ressourcen an, die ausgeführt werden sollen, 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-Workerprozess wiederverwendet wird. Während des Recycelns führt der alte IIS-Workerprozess weiterhin Anforderungen aus, bis der neu erzeugte Workerprozess vollständig aufgewärmt ist, sodass bei Anwendungen keine Unterbrechungen oder andere Probleme aufgrund nicht konfigurierter Caches auftreten. Beachten Sie, dass dieses Modul mit jeder Version von ASP.NET ab Version 2.0 funktioniert.

Weitere Informationen finden Sie unter Anwendungs-Warm-Up auf der IIS.net-Website. Eine exemplarische Vorgehensweise zur Verwendung des Aufwärmfeatures 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 er die folgende Konfiguration in der applicationHost.config Datei verwendet:

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

Da ein einzelner Anwendungspool mehrere Anwendungen enthalten kann, geben Sie einzelne Anwendungen an, die 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 bestimmen, 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. Wenn es sich in diesem Zustand befindet, instanziiert ASP.NET den typ, der durch das Attribut serviceAutoStartProvider definiert ist (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, ist die ASP.NET Anwendung bereit, Anforderungen zu verarbeiten.

Mit dem Hinzufügen von Autostart zu IIS .5 und ASP.NET 4 haben Sie jetzt einen klar definierten Ansatz für die Durchführung einer teuren Anwendungsinitialisierung vor der Verarbeitung der ersten HTTP-Anforderung. Sie können beispielsweise das neue Feature für den automatischen Start verwenden, um eine Anwendung zu initialisieren und dann einem Lastenausgleich 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 traditionell Anforderungen an alte URLs verarbeitet, indem sie die Response.Redirect-Methode verwenden, 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, die das Ausgeben von HTTP 301 Permanent-Antworten vereinfacht, wie im folgenden Beispiel gezeigt:

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

Suchmaschinen und andere Benutzer-Agents, die permanente Umleitungen erkennen, speichern die neue URL, die dem Inhalt zugeordnet ist, wodurch der unnötige Roundtrip des Browsers für temporäre Umleitungen beseitigt wird.

Sitzungsstatus verkleinern

ASP.NET bietet zwei Standardoptionen zum Speichern des Sitzungsstatus in einer Webfarm: einen Sitzungsstatusanbieter, der einen Out-of-Process-Sitzungsstatusserver aufruft, und einen Sitzungsstatusanbieter, der Daten in einer Microsoft SQL Server-Datenbank speichert. Da beide Optionen das Speichern von Zustandsinformationen außerhalb des Workerprozesses 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 recht groß werden.

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

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

Durch das einfache Hinzufügen des neuen Attributs zur Web.config Datei können Anwendungen mit freien CPU-Zyklen auf Webservern eine erhebliche Verringerung der Größe serialisierter Sitzungsstatusdaten 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 eingeschränkte URL-Pfadlängen auf 260 Zeichen, basierend auf dem NTFS-Dateipfadlimit. In ASP.NET 4 haben Sie die Möglichkeit, diesen Grenzwert entsprechend Ihren Anwendungen mithilfe von 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 ohne Protokoll, Servername und Abfragezeichenfolge), ändern Sie das maxUrlLength-Attribut . 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 als (<), größer als (>) und ampersand (&) 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

Beachten Sie ASP.NET 4 URL-Pfade, die Zeichen im ASCII-Bereich von 0x00 bis 0x1F enthalten, immer ablehnt, da es sich um ungültige URL-Zeichen handelt, wie in RFC 2396 der IETF (http://www.ietf.org/rfc/rfc2396.txt) definiert. 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 Überprüfung der Anforderung durchsucht eingehende HTTP-Anforderungsdaten nach Zeichenfolgen, die häufig bei 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 die gängigsten Zeichenfolgen gefunden werden, die bei XSS-Angriffen verwendet werden. Frühere Versuche, die XSS-Überprüfung aggressiver zu gestalten, führten zu zu vielen falsch positiven Ergebnissen. Kunden möchten jedoch möglicherweise eine aggressivere Anforderungsüberprüfung oder möchten die XSS-Überprüfungen für bestimmte Seiten oder bestimmte Arten von Anforderungen absichtlich lockern.

In ASP.NET 4 wurde die Anforderungsüberprüfungsfunktion erweiterbar gemacht, sodass Sie benutzerdefinierte Anforderungsvalidierungslogik verwenden können. Um die Anforderungsüberprüfung zu erweitern, erstellen Sie eine Klasse, die vom neuen System.Web.Util.RequestValidator-Typ abgeleitet ist, und konfigurieren die Anwendung (im Abschnitt httpRuntime der Web.config Datei) für die Verwendung des benutzerdefinierten Typs. Das folgende Beispiel zeigt, wie eine benutzerdefinierte Anforderungsüberprüfungsklasse konfiguriert wird:

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

Das neue requestValidationType-Attribut erfordert eine Standardmäßige .NET Framework Typbezeichnerzeichenfolge, die die Klasse angibt, die 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 stehen für die Überprüfung durch eine benutzerdefinierte Anforderungsüberprüfungsklasse zur Verfügung, 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 einen Teil eingehender HTTP-Daten nicht überprüfen möchten, kann die Anforderungsüberprüfungsklasse zurückfallen, um die ASP.NET Standardüberprüfung der Anforderung ausführen zu lassen, indem sie einfach base aufruft . IsValidRequestString.

Erweiterbarkeit für Objektzwischenspeicherung und Objektzwischenspeicherung

Seit der ersten Version enthält ASP.NET einen leistungsstarken In-Memory-Objektcache (System.Web.Caching.Cache). Die Cacheimplementierung ist so beliebt, dass sie in Nicht-Webanwendungen verwendet wurde. Es ist jedoch umständlich, wenn eine Windows Forms- oder WPF-Anwendung einen Verweis auf System.Web.dll enthält, nur um den ASP.NET Objektcache verwenden zu können.

Um die Zwischenspeicherung für alle Anwendungen verfügbar zu machen, führt die .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 Zwischenspeicherungs-API im System.Runtime.Caching-Namespace . Der Namespace enthält zwei Kernsätze von Klassen:

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

Die neue MemoryCache-Klasse ist eng mit dem ASP.NET Cache modelliert und teilt einen Großteil der internen Cache-Engine-Logik mit ASP.NET. Obwohl die öffentlichen Cache-APIs in System.Runtime.Caching aktualisiert wurden, um die Entwicklung benutzerdefinierter 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 erfordert 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 von 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 vom 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 automatisch die benutzerdefinierte Codierungsimplementierung auf, wenn öffentliche Codierungsmethoden der System.Web.HttpUtility - oder System.Web.HttpServerUtility-Klasse aufgerufen werden. Dadurch 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 wird sichergestellt, dass alle Aufrufe der Textcodierung von der öffentlichen ASP.NET-Codierungs-APIs über den benutzerdefinierten Encoder weitergeleitet werden.

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

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 einzelnen Workerprozess aus. Wenn jedoch mehrere Anwendungen einen einzelnen freigegebenen Workerprozess verwenden, ist es für Serveradministratoren schwierig, eine einzelne Anwendung zu identifizieren, bei der Probleme auftreten.

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

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

</configuration>

Hinweis

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

Wenn das Feature appDomainResourceMonitoring aktiviert wurde, sind zwei neue Leistungsindikatoren in der Leistungskategorie "ASP.NET Anwendungen" verfügbar: % Verwaltete Prozessorzeit und verwendeter verwalteter Arbeitsspeicher. Beide Leistungsindikatoren verwenden das neue ClR-Feature für die Ressourcenverwaltung von Anwendungen und Domänen, um die geschätzte CPU-Zeit und die verwaltete Arbeitsspeicherauslastung einzelner ASP.NET Anwendungen nachzuverfolgen. Daher haben Administratoren mit ASP.NET 4 jetzt einen detaillierteren Überblick über den Ressourcenverbrauch einzelner Anwendungen, die in einem einzelnen Workerprozess ausgeführt werden.

Festlegung von Zielversionen

Sie können eine Anwendung erstellen, die auf eine bestimmte Version des .NET Framework ausgerichtet ist. In ASP.NET 4 können Sie mit einem neuen Attribut im Kompilierungselement der Web.config Datei auf die .NET Framework 4 und höher abzielen. Wenn Sie explizit auf die .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 die .NET Framework 4 korrekt sein. (Wenn Sie nicht explizit auf die .NET Framework 4 abzielen, wird das Zielframework aus dem Fehlen 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 zum Ziel einer bestimmten Version der .NET Framework:

In einem .NET Framework 4-Anwendungspool geht das ASP.NET Buildsystem von der .NET Framework 4 als Ziel aus, wenn die Web.config Datei das targetFramework-Attribut nicht enthält oder die Web.config Datei fehlt. (Möglicherweise müssen Sie Codeänderungen an Ihrer Anwendung vornehmen, damit sie unter dem .NET Framework 4 ausgeführt wird.)
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 die .NET Framework 4 enthalten.
Wenn Sie den Befehl aspnet_compiler verwenden, um Ihre Anwendung vorzukompilieren (z. B. in einer Buildumgebung), müssen Sie die richtige Version des befehls aspnet_compiler für das Zielframework verwenden. Verwenden Sie den Compiler, der mit dem .NET Framework 2.0 (%WINDIR%\Microsoft.NET\Framework\v2.0.50727) ausgeliefert wurde, um für die .NET Framework 3.5 und frühere Versionen zu kompilieren. Verwenden Sie den Compiler, der im Lieferumfang des .NET Framework 4 enthalten ist, um Anwendungen zu kompilieren, die mit diesem Framework oder höheren Versionen erstellt wurden.
Zur Laufzeit verwendet der Compiler die neuesten Frameworkassemblys, die auf dem Computer (und damit im GAC) installiert sind. Wenn später ein Update für das Framework vorgenommen wird (z. B. eine hypothetische Version 4.1 installiert ist), können Sie Features in der neueren Version des Frameworks verwenden, auch wenn 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 in Web Forms und MVC enthalten

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

jQuery-1.4.1.js: Die für Menschen lesbare, nicht eingeschränkte 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 nicht minimierte Version von jQuery beim Entwickeln einer Anwendung ein. Schließen Sie die minimierte Version von jQuery für Produktionsanwendungen ein.

Auf der folgenden seite Web Forms wird beispielsweise veranschaulicht, wie Sie jQuery verwenden können, um die Hintergrundfarbe von ASP.NET TextBox-Steuerelementen in 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>

Content Delivery Network-Unterstützung

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>

Sie können die Leistung der AJAX-Anwendungen bedeutend verbessern, indem Sie das Microsoft AJAX-CDN nutzen. Die Inhalte des Microsoft Ajax CDN werden auf Servern auf der ganzen Welt zwischengespeichert. Außerdem ermöglicht das Microsoft AJAX-CDN Browsern die erneute Verwendung von zwischengespeicherten JavaScript-Dateien für Websites, die sich in verschiedenen Domänen befinden.

Das Microsoft AJAX Content Delivery Network unterstützt SSL (HTTPS), falls Sie eine Webseite mit 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 eine Eigenschaft festlegen, die EnableCdn-Eigenschaft, können Sie alle ASP.NET Framework-JavaScript-Dateien aus dem 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 Validierung verwendet werden, und das UpdatePanel. Das Festlegen dieser Eigenschaft kann dramatische Auswirkungen auf die Leistung Ihrer Webanwendung haben.

Sie können den CDN-Pfad für Ihre eigenen JavaScript-Dateien festlegen, indem Sie das WebResource-Attribut verwenden. 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")]

Explizite ScriptManager-Skripts

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

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

Aktiviert: Gibt an, dass das ScriptManager-Steuerelement automatisch die MicrosoftAjax.js Skriptdatei enthält, bei der es sich um eine kombinierte Skriptdatei jedes Kernframeworkskripts (Legacyverhalten) handelt.
Deaktiviert: Gibt an, dass alle Microsoft AJAX-Skriptfeatures deaktiviert sind und dass das ScriptManager-Steuerelement nicht automatisch auf Skripts verweist.
Explizit: Gibt an, dass Sie explizit Skriptverweise auf einzelne Framework-Kernskriptdatei einschließen, die für Ihre Seite erforderlich ist, 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 spezifischen 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>

Web Forms

Web Forms ist seit der Veröffentlichung von ASP.NET 1.0 ein Kernfeature in ASP.NET. Für ASP.NET 4 wurden in diesem Bereich zahlreiche Verbesserungen vorgenommen, darunter die folgenden:

Die Möglichkeit, Metatags festzulegen.
Mehr Kontrolle über den Ansichtszustand.
Einfachere Möglichkeiten zum Arbeiten mit Browserfunktionen.
Unterstützung für ASP.NET Routing mit Web Forms.
Mehr Kontrolle über generierte IDs.
Die Möglichkeit, ausgewählte Zeilen in Datensteuerelementen beizubehalten.
Mehr Kontrolle über gerenderten HTML-Code in den Steuerelementen FormView und ListView .
Filterunterstützung für Datenquellensteuerelemente.

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

ASP.NET 4 fügt der Page-Klasse zwei Eigenschaften hinzu: MetaKeywords und MetaDescription. Diese beiden Eigenschaften stellen die entsprechenden 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 genauso wie die Title-Eigenschaft der Seite. Sie befolgen die folgenden Regeln:

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

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

Sie können auch die Eigenschaften Keywords und Description 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 Metatags (sofern vorhanden) überschrieben, der bereits auf der Seite deklariert ist.

Der Inhalt des Beschreibungsmetatags wird zur Verbesserung der Suchlistungsvorschau in Google verwendet. (Weitere Informationen finden Sie unter Verbessern von Codeausschnitten mit einer Metabeschreibung im Google Webmaster Central-Blog.) Google und Windows Live Search verwenden den Inhalt der Schlüsselwörter für nichts, aber andere Suchmaschinen könnten.

Diese neuen Eigenschaften sind ein einfaches Feature, 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, sodass jedes Steuerelement auf der Seite möglicherweise den Ansichtszustand speichert, auch wenn er für die Anwendung nicht erforderlich ist. Ansichtsstatusdaten sind im Markup enthalten, das eine Seite generiert, und erhöht die Zeit, die benötigt wird, um eine Seite an den Client zu senden und zurückzusenden. Das Speichern eines größeren Ansichtszustands als erforderlich 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 reduzieren, 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 ihn dann nur für die Steuerelemente aktivieren können, die ihn auf der Seite benötigen.

Die ViewStateMode-Eigenschaft verwendet eine Enumeration mit drei Werten: Enabled, Disabled und Inherit. Aktiviert 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 des übergeordneten Steuerelements verwendet.

Im folgenden Beispiel wird die Funktionsweise der ViewStateMode-Eigenschaft veranschaulicht. 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 festgelegt, sodass label2 diese Eigenschaft erbt und den Ansichtszustand speichert. Wenn die Seite zum ersten Mal geladen wird, wird die Text-Eigenschaft beider Label-Steuerelemente auf die Zeichenfolge "[DynamicValue]" festgelegt.

Diese Einstellungen haben zur Folge, 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 seinen Zustand 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 weiteres Steuerelement. Sie fungiert als übergeordnetes Steuerelement für alle anderen Steuerelemente auf der Seite. Der Standardwert von ViewStateMode ist Enabled für Instanzen von Page. Da Steuerelemente standardmäßig auf Inherit festgelegt sind, erben Steuerelemente den Enabled-Eigenschaftswert , 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 die Verwendung von ContentPlaceHolder-Steuerelementen in master Seiten, bei denen Sie ViewStateMode für die master Seite auf Deaktiviert festlegen und dann einzeln für ContentPlaceHolder-Steuerelemente aktivieren können, die wiederum Steuerelemente enthalten, die ansichtszustand erfordern.

Änderungen an Browserfunktionen

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

Das HttpBrowserCapabilities-Objekt wird von einer Reihe von Browserdefinitionsdateien gesteuert. Diese Dateien enthalten Informationen über die Funktionen bestimmter Browser. In ASP.NET 4 wurden diese Browserdefinitionsdateien aktualisiert, um Informationen zu kürzlich eingeführten Browsern und Geräten 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 Browserfunktionenanbietern

In ASP.NET Version 3.5 Service Pack 1 können Sie die Funktionen eines Browsers wie folgt definieren:

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 an der Visual Studio-Eingabeaufforderung den folgenden Befehl aus, um die Browserfunktionenassembly 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 bei Ä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 Browserfunktionsanbieter bezeichnet wird. Wie der Name schon sagt, können Sie auf diese Weise einen Anbieter erstellen, mit dem Sie wiederum Ihren eigenen Code verwenden können, um Browserfunktionen zu bestimmen.

In der Praxis definieren Entwickler häufig keine benutzerdefinierten Browserfunktionen. Browserdateien sind schwer zu aktualisieren, der Prozess für deren Aktualisierung ist ziemlich kompliziert, und die XML-Syntax für .browser Dateien kann komplex zu verwenden und zu definieren sein. Was diesen Prozess viel einfacher machen würde, ist, wenn es eine gängige Browserdefinitionssyntax oder eine Datenbank mit aktuellen Browserdefinitionen oder sogar einen Webdienst für eine solche Datenbank gäbe. Das neue Feature für Browserfunktionsanbieter macht diese Szenarien für Entwickler von Drittanbietern möglich und praktisch.

Es gibt zwei Standard Ansätze für die Verwendung des neuen ASP.NET 4-Browserfunktionenanbieterfeatures: die Erweiterung der ASP.NET-Browserfunktionen-Definitionsfunktion oder deren vollständiger Ersatz. In den folgenden Abschnitten wird zunächst beschrieben, wie die Funktionalität ersetzt und dann erweitert wird.

Ersetzen der ASP.NET-Browserfunktionen

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

Erstellen Sie wie im folgenden Beispiel eine Anbieterklasse, die von HttpCapabilitiesProvider abgeleitet ist und die GetBrowserCapabilities-Methode außer Kraft setzt:

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 browser angibt und diese Funktion auf MyCustomBrowser festlegt.

Registrieren Sie den Anbieter bei der Anwendung.

Um einen Anbieter mit einer Anwendung zu verwenden, müssen Sie das anbieter-Attribut dem Abschnitt browserCaps in den Web.config -Dateien oder Machine.config hinzufügen. (Sie können die Anbieterattribute auch in einem Standortelement 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 Anbieterattribute 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. Jede Änderung an der BrowserCapabilitiesProvider-Klasse muss 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 gibt es ein Problem, nämlich, 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 vorkommen. Im Beispiel macht der Code für den Anbieter nicht viel. Wenn der Code in Ihrem benutzerdefinierten Anbieter jedoch erhebliche Aufgaben 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 . Folgen Sie diesen Schritten:

Erstellen Sie eine Klasse, die von HttpCapabilitiesProvider abgeleitet ist, wie 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 Dauer des Caches ab, indem eine benutzerdefinierte GetCacheTime-Methode aufgerufen wird. Der Code fügt dann dem Cache das aufgelöste HttpBrowserCapabilities-Objekt hinzu. Das Objekt kann aus dem Cache abgerufen und bei nachfolgenden Anforderungen wiederverwendet werden, die den benutzerdefinierten Anbieter verwenden.

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

Erweitern ASP.NET Browserfunktionen

Im vorherigen Abschnitt wurde beschrieben, wie Sie ein neues HttpBrowserCapabilities-Objekt in ASP.NET 4 erstellen. Sie können auch die ASP.NET Browserfunktionen erweitern, indem Sie neue Browserfunktionendefinitionen hinzufügen, die sich bereits in ASP.NET befinden. Sie können dies tun, ohne die XML-Browserdefinitionen zu verwenden. Das folgende Verfahren veranschaulicht dies.

Erstellen Sie eine Klasse, die von HttpCapabilitiesEvaluator abgeleitet ist und die getBrowserCapabilities-Methode außer Kraft setzt, 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 ASP.NET Browserfunktionen, um zu versuchen, den Browser zu identifizieren. Wenn jedoch kein Browser anhand der 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.
Registrieren Sie den Anbieter bei der Anwendung, wie im vorherigen Beispiel beschrieben.

Erweitern 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 um zusätzliche Funktionen erweitern. Auf diese Weise können Sie eine Definition verwenden, die dem gewünschten Wert entspricht, aber nur wenige Funktionen aufweist. Gehen Sie dazu folgendermaßen vor.

Erstellen Sie eine Klasse, die von HttpCapabilitiesEvaluator abgeleitet ist und die getBrowserCapabilities-Methode außer Kraft setzt, 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.
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. Mit dem Routing können Sie eine Anwendung so konfigurieren, dass Anforderungs-URLs akzeptiert werden, die keine physischen Dateien zugeordnet sind. Stattdessen können Sie das Routing verwenden, um URLs zu definieren, die für Benutzer von Bedeutung sind und die bei der Suchmaschinenoptimierung (SEO) für Ihre Anwendung hilfreich sein können. Die URL für eine Seite, auf der Produktkategorien in einer vorhandenen Anwendung angezeigt werden, könnte beispielsweise wie im folgenden Beispiel aussehen:

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

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

http://website/products/software

Routing ist ab ASP.NET 3.5 SP1 verfügbar. (Ein Beispiel für die Verwendung von Routing in ASP.NET 3.5 SP1 finden Sie im Eintrag Verwenden des Routings 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 , die ein einfacher HTTP-Handler ist, 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 bietet eine einfache Möglichkeit zum Erstellen einer URL, die einer Routen-URL innerhalb eines ASP.NET Serversteuerelements entspricht.
RouteValue bietet eine einfache Möglichkeit, Informationen aus dem RouteContext-Objekt zu extrahieren.
Die RouteParameter-Klasse , die das Übergeben von Daten in einem RouteContext-Objekt an eine Abfrage für ein Datenquellensteuerelement erleichtert (ä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 SearchRoute-Definition, die im vorherigen Beispiel gezeigt wurde, verwendet jedoch die PageRouteHandler-Klasse .

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

Der Code im Beispiel ordnet die Route einer physischen Seite zu (in der ersten Route zu ~/search.aspx). Die erste Routendefinition gibt außerdem an, dass der Parameter 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 weitergeleitet wird (in diesem Fall search.aspx) und die Berechtigungen für die eingehende URL (in diesem Fall search/{searchterm}). Wenn der Wert von checkPhysicalUrlAccessfalse ist, werden nur die Berechtigungen der eingehenden URL überprüft. Diese Berechtigungen werden in der Datei mithilfe von Web.config 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 allen Benutzern mit Ausnahme der Benutzer in der Administratorrolle der Zugriff auf die physische Seite search.aspx verweigert. Wenn der parameter checkPhysicalUrlAccess auf true (der Standardwert) festgelegt 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 gezeigt konfiguriert ist, können alle authentifizierten Benutzer auf die URL /search/{searchterm} zugreifen.

Lesen von Routinginformationen auf einer Web Forms Seite

Im Code der Web Forms physischen Seite können Sie mithilfe von zwei neuen Eigenschaften auf die Informationen zugreifen, die das Routing aus der URL extrahiert hat (oder auf andere Informationen, die ein anderes Objekt dem RouteData-Objekt hinzugefügt hat): 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. Beachten Sie die folgende Anforderungs-URL:

http://localhost/search/scott/

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

Zugreifen auf Routinginformationen im Markup

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

ASP.NET 4 enthält zwei neue Ausdrucks-Generatoren für 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 Es Ihnen, die vollständige URL im Markup hartcodieren zu müssen, und sie können die URL-Struktur später ändern, ohne dass dieser Link geändert werden muss.

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

http://localhost/search/scott

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

Das folgende Beispiel zeigt die Verwendung des RouteValue-Ausdrucks .

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

Wenn die Seite mit diesem Steuerelement ausgeführt wird, wird der Wert "scott" in der Bezeichnung angezeigt.

Der RouteValue-Ausdruck vereinfacht die Verwendung von Routendaten im Markup und vermeidet die Arbeit mit der komplexeren Page.RouteData["x"]-Syntax im Markup.

Verwenden von Routendaten für Datenquellensteuerungsparameter

Mit der RouteParameter-Klasse können Sie Routendaten als Parameterwert für Abfragen in einem Datenquellensteuerelement angeben. Sie 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 seit langem bestehendes Problem in ASP.NET, nämlich, wie Steuerelemente das id-Attribut für elemente erstellen, die sie rendern. Das Id-Attribut für gerenderte Elemente zu kennen ist wichtig, wenn Ihre Anwendung clientskripts enthält, das auf diese Elemente verweist.

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 (sofern vorhanden) mit der ID zu verketten und bei wiederholten Steuerelementen (wie in Datensteuerelementen) ein Präfix und eine sequenzielle Zahl hinzuzufügen. Dies hat zwar immer garantiert, dass die IDs von Steuerelementen auf der Seite eindeutig sind, aber der Algorithmus hat zu Steuerelement-IDs geführt, die nicht vorhersagbar waren und daher schwer im Clientskript 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, auch für die Seite. Folgende Einstellungen sind möglich:

AutoID : Dies entspricht dem Algorithmus zum Generieren von ClientID-Eigenschaftswerten , der in früheren Versionen von ASP.NET verwendet wurde.
Statisch : Dies gibt an, dass der ClientID-Wert mit der ID identisch ist, ohne die IDs übergeordneter Benennungscontainer zu verketten. Dies kann bei Webbenutzersteuerelementen hilfreich sein. Da sich ein Webbenutzersteuerelement auf verschiedenen Seiten und in unterschiedlichen Containersteuerelementen befinden kann, kann es schwierig sein, Clientskripts für Steuerelemente zu schreiben, die den AutoID-Algorithmus verwenden, da Sie die ID-Werte nicht vorhersagen können.
Vorhersagbar : Diese Option dient in erster Linie zur Verwendung in Datensteuerelementen, die sich wiederholende 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 Steuerelement identisch ist.

Sie können die ClientIDMode-Eigenschaft auf Seitenebene festlegen. Dadurch wird der Standardwert ClientIDMode für alle Steuerelemente auf der aktuellen Seite definiert.

Der ClientIDMode-Standardwert auf Seitenebene ist AutoID, und der Standardwert ClientIDMode auf Steuerungsebene ist Inherit. Wenn Sie diese Eigenschaft 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 Standardeinstellung 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 Einstellung ClientIDMode in der Konfigurationsdatei:

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

Wie bereits erwähnt, wird der Wert der ClientID-Eigenschaft vom Benennungscontainer für das übergeordnete Element eines Steuerelements abgeleitet. In einigen Szenarien, z. B. wenn Sie master Seiten verwenden, können Steuerelemente mit IDs wie im folgenden gerenderten HTML enden:

<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 (aus einem TextBox-Steuerelement) angezeigte Eingabeelement nur zwei Namenscontainer enthält, die tief auf der Seite liegen (die geschachtelten ContentPlaceholder-Steuerelemente), ist das Endergebnis aufgrund der Verarbeitung master Seiten eine Steuerelement-ID wie folgt:

ctl00_ContentPlaceHolder1_ParentPanel_NamingPanel1_TextBox1

Diese ID ist auf der Seite garantiert eindeutig, ist aber für die meisten Zwecke unnötig lang. Stellen Sie sich vor, Sie möchten die Länge der gerenderten ID verringern und mehr Kontrolle darüber haben, wie die ID generiert wird. (Beispielsweise möchten Sie "ctlxxx"-Präfixe entfernen.) Dies kann am einfachsten erreicht werden, indem Sie die Eigenschaft ClientIDMode festlegen, wie im folgenden Beispiel gezeigt:

<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 ist die ClientIDMode-Eigenschaft 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 (der Rest der Seite und die master Seite wird als identisch mit dem im 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 den Effekt, 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 Name-Attribut gerenderter Elemente ist nicht betroffen, sodass die normale ASP.NET Funktionalität für Ereignisse, Ansichtsstatus usw. beibehalten wird.) Ein Nebeneffekt des Zurücksetzens der Benennungshierarchie ist, dass selbst wenn Sie das Markup für die NamingPanel-Elemente in ein anderes ContentPlaceholder-Steuerelement verschieben, die gerenderten Client-IDs gleich bleiben.

Hinweis

Hinweis Es liegt an Ihnen, sicherzustellen, dass die gerenderten Steuerelement-IDs eindeutig sind. Andernfalls kann jede Funktionalität unterbrochen werden, die eindeutige IDs für einzelne HTML-Elemente erfordert, z. B. die Clientfunktion document.getElementById .

Erstellen vorhersagbarer Client-IDs in Data-Bound-Steuerelementen

Die ClientID-Werte , die für Steuerelemente in einem datengebundenen Listensteuerelement vom Legacyalgorithmus generiert werden, können lang sein und sind nicht wirklich vorhersagbar. 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 ihr Verhalten unterscheidet sich je nachdem, welches Steuerelement Sie verwenden. 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, haben Steuerelement-IDs für gerenderte Elemente ein Format wie das folgende:

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 ein Format wie das folgende:
```
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="Vorhersagbare" mit einem Repeater-Steuerelement verwenden, werden Client-IDs mit dem folgenden Format generiert:
```
Repeater1_ProductNameLabel_0
```
Die nachfolgende 0 ist der Index der aktuellen Zeile.

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

Beibehalten der Zeilenauswahl in Datensteuerelementen

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 persistente Auswahl wurde anfänglich nur in Dynamic Data-Projekten im .NET Framework 3.5 SP1 unterstützt. Wenn dieses Feature aktiviert ist, basiert das aktuell ausgewählte Element auf dem Datenschlüssel für das Element. Das bedeutet, dass auf Seite 2 nichts ausgewählt wird, wenn Sie die dritte Zeile auf Seite 1 auswählen und zu Seite 2 wechseln. Wenn Sie zu Seite 1 zurückkehren, ist die dritte Zeile weiterhin ausgewählt. Die persistierte 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 Diagrammsteuerelement erweitert die Datenvisualisierungsangebote im .NET Framework. Mit dem Diagrammsteuerelement können Sie ASP.NET Seiten erstellen, die über intuitive und visuell ansprechende Diagramme für komplexe statistische oder finanzielle Analysen verfügen. Das ASP.NET Chart-Steuerelement wurde als Add-On für die .NET Framework Version 3.5 SP1 eingeführt und ist Teil des .NET Framework 4-Release.

Das Steuerelement umfasst 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.
Smart Data-Bezeichnungen, die automatisch um Datenpunkte herum passen können.
Streifen von Linien, Skalierungsunterbrechungen und logarithmischer Skalierung.
Mehr als 50 Formeln für finanzielle und statistische Berechnungen zur Datenanalyse und -transformation
Einfaches Binden und Bearbeiten von Diagrammdaten.
Unterstützung für gängige Datenformate wie Datumsangaben, Uhrzeiten und Währungen.
Unterstützung für Interaktivität und ereignisgesteuerte Anpassung, einschließlich Clientklickereignissen mithilfe von Ajax.
Zustandsverwaltung
Binäres Streaming

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

Vier Beispielfinanzdiagramme, die vom ASP.NET Diagrammsteuerelements erstellt werden.

Abbildung 2: Beispiele für ASP.NET Diagrammsteuerelemente

Weitere Beispiele für die Verwendung des ASP.NET Chart-Steuerelements finden Sie auf der MSDN-Website auf der Seite Beispielumgebung für Microsoft-Diagrammsteuerelemente . Weitere Beispiele für Communityinhalte finden Sie im Chart Control Forum.

Hinzufügen des Diagrammsteuerelements zu einer ASP.NET Seite

Im folgenden Beispiel wird gezeigt, wie Sie mithilfe von Markup einer ASP.NET Seite ein Diagrammsteuerelement hinzufügen. Im Beispiel erzeugt das Diagrammsteuerelement 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. Um beispielsweise 3D für einen Diagrammbereich zu verwenden, 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 Reihen des Balkendiagrammtyps .

3-dimensionales Balkendiagramm mit vier Reihen des Balkendiagrammtyps.

Abbildung 3: 3D-Balkendiagramm

Verwenden von Skalierungsunterbrechungen und logarithmischen Skalen

Skalierungsunterbrechungen und logarithmische Skalierungen sind zwei zusätzliche Möglichkeiten, dem Diagramm Raffinesse hinzuzufügen. Diese Features sind für jede Achse in einem Diagrammbereich spezifisch. 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 Skalierungsunterbrechungen 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.

Ein Balkendiagramm, das die Y-Achse mit aktivierten Skalierungsumbrüchen zeigt.

Abbildung 4: Skalierungsunterbrechungen

Filtern von Daten mit dem QueryExtender-Steuerelement

Eine sehr häufige Aufgabe für Entwickler, die datengesteuerte Webseiten erstellen, ist das Filtern von Daten. Dies wurde traditionell durch das Erstellen von Where-Klauseln in Datenquellensteuerelementen durchgeführt. Dieser Ansatz kann kompliziert sein, und in einigen Fällen ermöglicht die Where-Syntax es Ihnen nicht, die volle Funktionalität der zugrunde liegenden Datenbank zu nutzen.

Um die Filterung zu vereinfachen, wurde in ASP.NET 4 ein neues QueryExtender-Steuerelement hinzugefügt. Dieses Steuerelement kann zum EntityDataSource - oder LinqDataSource-Steuerelement hinzugefügt werden, um die von diesen Steuerelementen zurückgegebenen Daten zu filtern. Da das QueryExtender-Steuerelement auf LINQ basiert, wird der Filter auf den 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 deren Verwendung bereitgestellt.

Suche

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 seinem Inhalt in den ProductName Spalten und Supplier.CompanyName in den 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>

Range

Die Bereichsoption ähnelt der Suchoption, gibt jedoch ein Wertepaar an, um den Bereich zu definieren. Im folgenden Beispiel durchsucht das QueryExtender-Steuerelement die Spalte in den UnitPrice Vom LinqDataSource-Steuerelement zurückgegebenen Daten. Der Bereich wird aus den Steuerelementen TextBoxFrom und TextBoxTo 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 Option Eigenschaftenausdruck können Sie einen Vergleich mit einem Eigenschaftswert definieren. Wenn der Ausdruck als true ausgewertet wird, werden die zu untersuchenden Daten zurückgegeben. Im folgenden Beispiel filtert das QueryExtender-Steuerelement Daten, indem es die Daten in der Discontinued Spalte mit dem Wert aus dem CheckBoxDiscontinued-Steuerelement auf der Seite vergleicht.

<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 deklarativ im QueryExtender-Steuerelement 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 eine LINQ-Abfrage, um die Daten zu filtern, anstatt eine Datenbankabfrage zu verwenden, die eine Where-Klausel enthält.

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 in das QueryExtender-Steuerelement einschließen.

HTML-codierte Codeausdrücke

Einige ASP.NET Websites (insbesondere mit ASP.NET MVC) sind stark von der Verwendung von <%= expression %> Syntax (oft als "Codenupgets" bezeichnet) abhängig, um Text in die Antwort zu schreiben. Wenn Sie Codeausdrücke verwenden, können Sie leicht vergessen, den Text in HTML zu codieren. Wenn der Text von einer Benutzereingabe stammt, können Seiten für einen XSS-Angriff (Cross Site Scripting) geöffnet bleiben.

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 effektiv folgendes:

<%= HttpUtility.HtmlEncode(expression) %>

Beispielsweise <führt %: Request["UserInput"] %> eine HTML-Codierung für den Wert von Request["UserInput"]aus.

Das Ziel dieses Features besteht darin, alle Instanzen der alten Syntax durch die neue Syntax zu ersetzen, damit Sie nicht bei jedem Schritt entscheiden müssen, welche Syntax verwendet werden soll. 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.

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

<%: 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 dadurch kein Schutz vor XSS-Angriffen garantiert wird. Beispielsweise kann HTML, der Attributwerte verwendet, die sich nicht in Anführungszeichen befinden, Benutzereingaben enthalten, die weiterhin anfällig sind. Beachten Sie, dass die Ausgabe von ASP.NET Steuerelementen und ASP.NET MVC-Hilfsprogrammen immer Attributwerte in Anführungszeichen enthält, was der empfohlene Ansatz ist.

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

Projektvorlagenänderungen

Wenn Sie in früheren Versionen von ASP.NET visual Studio zum Erstellen eines neuen Website- 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:

Screenshot des Visual Studio-Dateimenüs Ein neues Beispielprojekt ist hervorgehoben, das die Standarddatei und den Standardordner anzeigt.

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

Screenshot des Visual Studio-Dateimenüs Ein Beispielprojektverzeichnis enthält keine Dateien oder Ordner.

Das Ergebnis ist, dass es für anfänger nur sehr wenige Anleitungen zum Erstellen einer Produktionswebanwendung gibt. Daher führt ASP.NET 4 drei neue Vorlagen ein, eine für ein leeres Webanwendungsprojekt und jeweils eine für ein Webanwendungs- und Websiteprojekt.

Leere Webanwendungsvorlage

Wie der Name schon sagt, ist die Vorlage leere Webanwendung ein abgespecktes Webanwendungsprojekt. Sie wählen diese Projektvorlage im Dialogfeld Neues Visual Studio-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:

Screenshot: Menü

Dies ähnelt dem Layout "Leere Website" aus früheren Versionen von ASP.NET, mit einer Ausnahme. In Visual Studio 2010 enthalten Die Projekte "Leere Webanwendung" und "Leere Website" 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 abzielt:

! <?xml version =

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

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 praktisch identisch.)

Das Projekt enthält eine Reihe von Dateien, die in früheren Versionen nicht erstellt wurden. Darüber hinaus wird das neue Webanwendungsprojekt mit grundlegenden Mitgliedschaftsfunktionen konfiguriert, mit der Sie schnell mit dem Sichern des Zugriffs auf die neue Anwendung beginnen können. Aufgrund dieser Aufnahme enthält die Web.config Datei für das neue Projekt Einträge, die zum Konfigurieren von Mitgliedschaften, 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 Seite ChangePassword.aspx für nicht angemeldete Benutzer zu sichern. Das folgende Beispiel zeigt den Inhalt der zweiten Web.config Datei.

<?xml version=

Die standardmäßig in den neuen Projektvorlagen erstellten Seiten enthalten auch mehr Inhalt als in früheren Versionen. Das Projekt enthält eine Standardmäßige master Seite und CSS-Datei, und die Standardseite (Default.aspx) ist so konfiguriert, dass die master Seite standardmäßig verwendet wird. Wenn Sie die Webanwendung oder Website zum ersten Mal ausführen, ist die Standardseite (Startseite) bereits funktionsfähig. 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)

Mit diesen Änderungen an den Projektvorlagen sollen Anleitungen zum Erstellen einer neuen Webanwendung bereitgestellt werden. Mit semantisch korrektem, striktem XHTML 1.0-konformem Markup und mit layout, das mithilfe von CSS angegeben wird, stellen die Seiten in den Vorlagen bewährte Methoden zum Erstellen von ASP.NET 4-Webanwendungen dar. Die Standardseiten verfügen außerdem über ein zweispaltiges Layout, das Sie einfach anpassen können.

Stellen Sie sich beispielsweise vor, dass Sie bei einer neuen Webanwendung einige der Farben ändern und Ihr Unternehmenslogo anstelle des Logos "Meine ASP.NET Anwendung" einfügen möchten. Erstellen Sie dazu ein neues Verzeichnis unter Content , um Ihr Logobild zu speichern:

Screenshot: Dateiverzeichnis mit einem Bildordner, der eine Logodatei enthält

Um das Bild zur Seite hinzuzufügen, öffnen Sie dann die Site.Master Datei, ermitteln, wo der Text My ASP.NET Application definiert ist, und ersetzen sie durch ein image-Element , 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 Datei Site.css 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 sehr wenig Aufwand anzeigen können:

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

CSS-Verbesserungen

Einer der Hauptarbeitsfelder in ASP.NET 4 war es, HTML zu rendern, der mit den neuesten HTML-Standards kompatibel ist. Dies umfasst Änderungen an der Verwendung von CSS-Formatvorlagen für ASP.NET Webserversteuerelemente.

Kompatibilitätseinstellung für Rendering

Wenn eine Webanwendung oder Website auf die .NET Framework 4 ausgerichtet ist, wird das controlRenderingCompatibilityVersion-Attribut des pages-Elements standardmäßig 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 Legacyrendering und Markup an. Markup, das von Steuerelementen gerendert wird, ist zu 100 % abwärtskompatibel, und die Einstellung der xhtmlConformance-Eigenschaft wird berücksichtigt.
"4.0". Wenn die -Eigenschaft diese Einstellung aufweist, ASP.NET Webserversteuerelemente die folgenden Aktionen ausführen:
Die xhtmlConformance-Eigenschaft wird immer als "Strict" behandelt. Daher rendern Steuerelemente XHTML 1.0 Strict-Markup.
Wenn Sie Steuerelemente ohne Eingabe deaktivieren, werden keine ungültigen Formatvorlagen mehr gerendert.
div-Elemente um ausgeblendete Felder werden jetzt so formatiert, dass sie keine vom Benutzer erstellten CSS-Regeln beeinträchtigen.
Menüsteuerelemente rendern Markup, das semantisch korrekt ist und den Richtlinien für die Barrierefreiheit entspricht.
Validierungssteuerelemente rendern keine Inlinestile.
Steuerelemente, die zuvor border="0" gerendert haben (Steuerelemente, die vom ASP.NET Table-Steuerelement und dem ASP.NET Image-Steuerelement abgeleitet sind), rendern dieses Attribut nicht mehr.

Deaktivieren von Steuerelementen

In ASP.NET 3.5 SP1 und früheren Versionen rendert das Framework das disabled-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>

Sie können markup für ein Label-Steuerelement wie folgt erstellen, wodurch das Steuerelement deaktiviert wird:

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

Das Label-Steuerelement würde den folgenden HTML-Code rendern:

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

In ASP.NET 4 können Sie controlRenderingCompatibilityVersion auf "4.0" festlegen. In diesem Fall rendern nur Steuerelemente, die Eingabeelemente rendern, ein deaktiviertes Attribut, wenn die Enabled-Eigenschaft des Steuerelements auf false festgelegt ist. Steuerelemente, die keine HTML-Eingabeelemente rendern, rendern stattdessen ein Klassenattribute , das auf eine CSS-Klasse verweist, mit der Sie eine deaktivierte Suche für das Steuerelement definieren können. 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 Entwickler von Steuerelementen kann das Verhalten, das für ein bestimmtes Steuerelement verwendet werden soll, auch mithilfe der SupportsDisabledAttribute-Eigenschaft definiert werden.

Ausblenden von div-Elementen um ausgeblendete Felder

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

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

Rendern einer äußeren Tabelle für Steuerelemente mit Vorlagen

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

Formview
Anmeldung
Passwordrecovery
ChangePassword
Zauberer
Createuserwizard

Diesen Steuerelementen wurde eine neue Eigenschaft namens RenderOuterTable hinzugefügt, mit der die äußere Tabelle aus dem Markup entfernt werden kann. Sehen Sie sich beispielsweise das folgende Beispiel für ein FormView-Steuerelement an :

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

</asp:FormView>

Dieses Markup rendert die folgende Ausgabe auf der Seite, 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 die RenderOuterTable-Eigenschaft des FormView-Steuerelements festlegen, wie im folgenden Beispiel gezeigt:

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

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

Inhalt

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

Hinweis

Hinweis Durch diese Änderung wird die Unterstützung für die Funktion für das automatische Format im Visual Studio 2010-Designer deaktiviert, da kein Tabellenelement mehr vorhanden ist, 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 zu verwenden. In der früheren Version des Steuerelements mussten 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 des CheckBoxList- und RadioButtonList-Steuerelements

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

Flow. Das Steuerelement rendert span-Elemente , um ihren Inhalt zu 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 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 mithilfe von HTML-Listenelementen (li) rendern, um semantisch korrekten HTML-Code zu rendern. 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 Steuerelemente CheckBoxList und RadioButtonList die folgenden neuen Werte für die RepeatLayout-Eigenschaft :

OrderedList: Der Inhalt wird in einem ol-Element als li-Elemente gerendert.
UnorderedList : Der Inhalt wird als li-Elemente innerhalb eines ul-Elements gerendert.

Im folgenden Beispiel wird gezeigt, 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 in Ihrem Markup oder Code festgelegt wurde. Die -Eigenschaft hätte keinen Wert, da das visuelle Layout dieser Steuerelemente stattdessen mithilfe von CSS definiert wird.

Vor ASP.NET 4 hat das Menü-Steuerelement eine Reihe von HTML-Tabellen gerendert. Dies erschwerte die Anwendung von CSS-Formatvorlagen außerhalb des Festlegens von Inlineeigenschaften und war auch nicht konform mit Barrierefreiheitsstandards.

In ASP.NET 4 rendert das Steuerelement jetzt HTML mithilfe von semantischem Markup, das aus einer ungeordneten Liste und Listenelementen besteht. Das folgende Beispiel zeigt Markup in einer ASP.NET Seite für das Menu-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 die Pfeiltasten verwenden, um durch Elemente zu navigieren. Das Menü-Steuerelement fügt jetzt auch ARIA-Rollen (Rich Internet Applications) und Attribute hinzu, die follofür verbesserte Barrierefreiheit bieten.

Formatvorlagen für das Menüsteuerelement werden in einem Formatvorlagenblock am oberen Rand der Seite gerendert und nicht in Übereinstimmung mit den gerenderten HTML-Elementen. Wenn Sie die vollständige Kontrolle über die Formatierung des Steuerelements übernehmen möchten, können Sie die neue IncludeStyleBlock-Eigenschaft auf false festlegen. In diesem Fall wird der Stilblock nicht ausgegeben. Eine Möglichkeit, diese Eigenschaft zu verwenden, besteht darin, das Feature für das automatische Formatieren 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 Stilblock in eine externe CSS-Datei kopieren. Heben Sie in Visual Studio die Formatierung auf, und legen Sie IncludeStyleBlock auf false fest. Das Ergebnis ist, dass die Menüdarstellung mithilfe von Formatvorlagen in einem externen Stylesheet definiert wird.

Assistenten und CreateUserWizard-Steuerelemente

Der ASP.NET-Assistent und die Steuerelemente CreateUserWizard unterstützen Vorlagen, mit denen Sie den html-Code definieren können, den sie rendern. (CreateUserWizard wird vom Assistenten abgeleitet.) Das folgende Beispiel zeigt das Markup für ein vollständig auf Vorlagen basierendes 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 dem folgenden:

<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 Vorlageninhalt ändern, haben jedoch weiterhin eingeschränkte Kontrolle über die Ausgabe des Assistentensteuerelements . In ASP.NET 4 können Sie eine LayoutTemplate-Vorlage erstellen und Platzhaltersteuerelemente einfügen (mit reservierten Namen), um anzugeben, wie das Assistentensteuerelement 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 dieser durch den Inhalt des HeaderTemplate-Elements ersetzt.
sideBarPlaceholder : Zur Laufzeit wird dieser durch den Inhalt des SideBarTemplate-Elements ersetzt.
wizardStepPlaceHolder : Zur Laufzeit wird dieser durch den Inhalt des WizardStepTemplate-Elements ersetzt.
navigationPlaceholder : Zur Laufzeit wird dieser durch alle navigationsvorlagen ersetzt, die Sie definiert haben.

Das Markup im Beispiel, das Platzhalter verwendet, rendert den folgenden HTML-Code (ohne den tatsächlich in den Vorlagen definierten Inhalt):

<span>
</span>

Der einzige HTML-Code, der jetzt nicht mehr benutzerdefinierte ist, ist ein span-Element . (Wir gehen davon aus, dass in zukünftigen Releases auch das span-Element nicht gerendert wird.) Dadurch haben Sie jetzt die volle Kontrolle über praktisch 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

Mit Bereichen können Sie Controller und Ansichten in Abschnitten 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 Standard-Anwendung verwiesen werden kann. Dies trägt zur Verwaltung der Komplexität bei, wenn Sie eine große Anwendung erstellen, und erleichtert es mehreren Teams, an einer einzigen Anwendung zusammenzuarbeiten.

Unterstützung der Data-Annotation-Attributvalidierung

Mithilfe von DataAnnotations-Attributen können Sie Validierungslogik mithilfe von Metadatenattributen 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 die Standardmodellbindung integriert und bieten eine metadatengesteuerte Möglichkeit zum Überprüfen von Benutzereingaben.

Vorlagenhilfsprogramme

Mithilfe von Vorlagenhilfsprogrammen können Sie Bearbeitungs- und Anzeigevorlagen automatisch Datentypen zuordnen. Sie können beispielsweise ein Vorlagenhilfsprogramm verwenden, um anzugeben, dass ein Datumsauswahl-UI-Element automatisch für einen System.DateTime-Wert gerendert wird. Dies ähnelt Feldvorlagen in ASP.NET Dynamic Data.

Die Html.EditorFor - und Html.DisplayFor-Hilfsmethoden verfügen über integrierte Unterstützung für das Rendern von Standarddatentypen sowie für 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 Benutzeroberflächenhilfsprogrammen noch weiter anpassen und die vollständige Kontrolle darüber haben, was generiert wird. Die Hilfsmethoden Html.EditorFor und Html.DisplayFor unterstützen dies mithilfe eines Vorlagenmechanismus, mit dem Sie externe Vorlagen definieren können, die die gerenderte Ausgabe überschreiben und steuern können. Die Vorlagen können einzeln für eine Klasse gerendert werden.

Dynamic Data

Dynamic Data wurde Mitte 2008 im Release .NET Framework 3.5 SP1 eingeführt. Dieses Feature bietet viele Verbesserungen für das Erstellen von datengesteuerten Anwendungen, einschließlich der folgenden:

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

Hinweis

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

Für ASP.NET 4 wurde Dynamic Data verbessert, um Entwicklern noch mehr Leistung für die schnelle Erstellung von datengesteuerten Websites zu bieten.

Aktivieren von dynamischen Daten für vorhandene Projekte

Dynamic Data-Features, die in der .NET Framework 3.5 SP1 ausgeliefert wurden, brachten neue Features wie die folgenden:

Feldvorlagen: Diese stellen datentypbasierte Vorlagen für datengebundene Steuerelemente bereit. Feldvorlagen bieten eine einfachere Möglichkeit zum Anpassen des Erscheinungsbilds von Datensteuerelementen als die Verwendung von Vorlagenfeldern für jedes Feld.
Validierung: Mit dynamischen Daten können Sie Attribute für Datenklassen verwenden, um die Validierung für gängige Szenarien wie erforderliche Felder, Bereichsüberprüfung, Typüberprüfung, Musterabgleich mithilfe regulärer Ausdrücke und benutzerdefinierter Validierung anzugeben. Die Validierung wird von den Datensteuerelementen erzwungen.

Für diese Features gelten jedoch die folgenden Anforderungen:

Die Datenzugriffsebene musste auf Entity Framework oder LINQ to SQL basieren.
Die einzigen Datenquellensteuerelemente, die für diese Features unterstützt wurden, waren die EntityDataSource - oder LinqDataSource-Steuerelemente .
Die Features erforderten ein Webprojekt, das mithilfe der Vorlagen dynamische Daten oder dynamische Datenentitäten erstellt wurde, um alle Dateien zu erhalten, die zur Unterstützung des Features erforderlich waren.

Ein hauptziel der Dynamic Data-Unterstützung in ASP.NET 4 ist die Aktivierung der neuen Funktionalität von Dynamic Data für jede ASP.NET Anwendung. Das folgende Beispiel zeigt Markup für Steuerelemente, die die Dynamic Data-Funktionalität 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 Dynamic Data-Unterstützung für diese Steuerelemente zu aktivieren:

GridView1.EnableDynamicData(typeof(Product));

Wenn sich das GridView-Steuerelement im Bearbeitungsmodus befindet, überprüft Dynamic Data automatisch, ob die eingegebenen Daten das richtige Format aufweisen. Andernfalls wird eine Fehlermeldung angezeigt.

Diese Funktionalität bietet auch weitere Vorteile, z. B. die Möglichkeit, Standardwerte für den Einfügemodus anzugeben. Ohne dynamische Daten müssen Sie zum Implementieren eines Standardwerts für ein Feld ein Ereignis anfügen, das Steuerelement suchen (mithilfe von FindControl) und dessen Wert festlegen. In ASP.NET 4 unterstützt der EnableDynamicData-Aufruf einen zweiten Parameter, mit dem Sie Standardwerte für jedes Feld im Objekt übergeben können, wie in diesem Beispiel gezeigt:

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

Deklarative DynamicDataManager-Steuerelementsyntax

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 aktiviert 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, das Layout von Daten anzupassen, ohne dass Sie eine benutzerdefinierte Seite erstellen müssen. Seitenvorlagen verwenden das FormView-Steuerelement (anstelle des DetailsView-Steuerelements , wie es in früheren Versionen von Dynamic Data in Seitenvorlagen verwendet wurde) und das DynamicEntity-Steuerelement , um Entitätsvorlagen zu rendern. 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 Erscheinungsbild der gesamten 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 mithilfe des neuen DynamicEntity-Steuerelements auf einer Seite 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 Email 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. Für EmailAddress-Objekte wird das Feld als Link angezeigt, der mit dem mailto: -Protokoll erstellt wird. Wenn Benutzer auf den Link klicken, wird der E-Mail-Client des Benutzers geöffnet und eine Skelettnachricht erstellt. Objekte, die als URL eingegeben werden, 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

Dynamic Data verwendet das neue Routingfeature, das im .NET Framework 3.5 SP1 hinzugefügt wurde, um die URLs zu steuern, die Endbenutzern beim Zugriff auf die Website angezeigt werden. Das neue DynamicHyperLink-Steuerelement erleichtert das Erstellen von Links zu Seiten in einer Dynamic Data-Website. Im folgenden Beispiel wird die Verwendung des DynamicHyperLink-Steuerelements veranschaulicht:

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

Dieses Markup erstellt einen Link, der auf die Seite Liste 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 Dynamic Data basiert.

Unterstützung für vererbung im Datenmodell

Sowohl Entity Framework als auch LINQ to SQL unterstützen die Vererbung in ihren Datenmodellen. Ein Beispiel hierfür kann eine Datenbank mit einer InsurancePolicy Tabelle sein. Es kann auch Tabellen und HousePolicy enthaltenCarPolicy, die über die gleichen Felder wie InsurancePolicy verfügen, und dann werden weitere Felder hinzugefügt. Dynamic Data wurde geändert, um geerbte Objekte im Datenmodell zu verstehen und das Gerüstbau für die geerbten Tabellen zu unterstützen.

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

Das Entity Framework bietet umfassende Unterstützung für m:n-Beziehungen zwischen Tabellen, die implementiert wird, indem die Beziehung als Auflistung für ein Entity-Objekt verfügbar ist. Neue ManyToMany.ascx Feldvorlagen und ManyToMany_Edit.ascx wurden hinzugefügt, um die Anzeige und Bearbeitung von Daten zu unterstützen, die an m:n-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 konnten Sie den Namen ändern, der als Untertitel 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 eine unabhängige Steuerung des Namens, der für die Bezeichnungen in einem GridView-Steuerelement verwendet wird, des in einem DetailsView-Steuerelement verwendeten Namens, des Hilfetexts für das Feld und des Wasserzeichens, das für das Feld verwendet wird (wenn 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. Dynamic Data verwendet die neue Enumeration.ascx Feldvorlage, um eine Benutzeroberfläche zum Anzeigen und Bearbeiten von Enumerationswerten zu erstellen. Die Vorlage ordnet die Werte aus der Datenbank den Namen in der Enumeration zu.

Erweiterte Unterstützung für Filter

Dynamic Data 1.0 wird 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. Mit dem neuen DisplayAttribute-Attribut werden beide Probleme behoben, indem Sie steuern, ob eine Spalte als Filter angezeigt wird und in welcher Reihenfolge sie angezeigt wird.

Eine weitere Erweiterung besteht darin, dass die Filterunterstützung neu um das neue Feature von Web Forms zu verwenden. Auf diese Weise können Sie Filter erstellen, ohne wissen zu müssen, mit dem die Filter verwendet werden. Zusammen mit diesen Erweiterungen wurden Filter auch in Vorlagensteuerelemente umgewandelt, mit denen Sie neue hinzufügen können. Schließlich ermöglicht die zuvor erwähnte DisplayAttribute-Klasse das Überschreiben des Standardfilters auf die gleiche Weise, wie UIHint das Überschreiben der Standardfeldvorlage für eine Spalte zulässt.

Verbesserungen der Visual Studio 2010-Webentwicklung

Die Webentwicklung in Visual Studio 2010 wurde verbessert, um die CSS-Kompatibilität zu verbessern, die Produktivität durch HTML- und ASP.NET Markupausschnitte und neues dynamisches IntelliSense-JavaScript zu erhöhen.

Verbesserte CSS-Kompatibilität

Der Visual Web Developer-Designer in Visual Studio 2010 wurde aktualisiert, um die Einhaltung von CSS 2.1-Standards 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 architektonische Verbesserungen vorgenommen, die zukünftige Verbesserungen bei Rendering, Layout und Serviceability besser ermöglichen.

HTML- und JavaScript-Codeausschnitte

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

Visual Studio 2010 enthält mehr als 200 Codeausschnitte, mit denen Sie allgemeine ASP.NET- und HTML-Tags automatisch vervollständigen können, 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 Markupblöcke kapseln, die Sie oder Ihr Team für allgemeine Aufgaben verwenden.

JavaScript-IntelliSense-Erweiterungen

In Visual 2010 wurde JavaScript IntelliSense neu gestaltet, um eine noch umfangreichere Bearbeitungserfahrung zu bieten. IntelliSense erkennt nun 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 geringer oder keiner Verarbeitungsverzögerung anzuzeigen. Die Kompatibilität wurde erheblich erhöht, um fast alle Bibliotheken von Drittanbietern zu unterstützen und verschiedene Programmierstile 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 wie die folgenden auftreten:

Die Bereitstellung auf einer freigegebenen Hostingwebsite 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, damit die Anwendungsdatenbank ausgeführt wird. 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-Webbereitstellungstool (MsDeploy.exe).

Webbereitstellungsfeatures in Visual Studio 2010 umfassen die folgenden Hauptbereiche:

Webverpackung
Web.config Transformation
Datenbankbereitstellung
Veröffentlichung mit einem Klick für Webanwendungen

Die folgenden Abschnitte enthalten Details zu diesen Features.

Webverpackung

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, einschließlich Anwendungspooleinstellungen, Fehlerseiteneinstellungen usw.
Der eigentliche Webinhalt, der Webseiten, Benutzersteuerelemente, statische Inhalte (Bilder und HTML-Dateien) usw. umfasst.
SQL Server Datenbankschemas und -daten.
Sicherheitszertifikate, im GAC zu installierende Komponenten, Registrierungseinstellungen usw.

Ein Webpaket kann auf einen beliebigen Server kopiert und dann mithilfe des IIS-Managers manuell 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 Web Application Project Deployment Overview on the MSDN-Website und 10 + 20 Gründe, warum Sie ein Webpaket erstellen sollten , im Blog von Vishal Joshi.

Web.config Transformation

Für die Bereitstellung von Webanwendungen führt Visual Studio 2010 die XML-Dokumenttransformation (XML Document Transform, XDT) ein. Dies ist ein Feature, mit dem Sie eine Web.config Datei von den Entwicklungseinstellungen in die Produktionseinstellungen transformieren können. Transformationseinstellungen werden in Transformationsdateien mit dem Namen 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. Der Replace Schlüsselwort (keyword) 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 Webanwendungsprojektbereitstellung auf der MSDN-Website undWebbereitstellung: Web.Config Transformation im Blog von Vishal Joshi.

Datenbankbereitstellung

Ein Visual Studio 2010-Bereitstellungspaket kann Abhängigkeiten von SQL Server Datenbanken enthalten. Im Rahmen der Paketdefinition geben Sie die Verbindungszeichenfolge für Ihre Quelldatenbank an. 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. Zum Zeitpunkt der Bereitstellung geben Sie eine Verbindungszeichenfolge an, die für den Zielserver geeignet ist. Der Bereitstellungsprozess verwendet dann diese Verbindungszeichenfolge, um die Skripts auszuführen, die das Datenbankschema erstellen, und die Daten hinzuzufügen.

Darüber hinaus können Sie mithilfe der Veröffentlichung mit einem Klick die Bereitstellung so konfigurieren, dass Ihre Datenbank direkt veröffentlicht wird, wenn die Anwendung auf einer Freigegebenen Remotehostingwebsite veröffentlicht wird. Weitere Informationen finden Sie unter Vorgehensweise: Bereitstellen einer Datenbank mit einem Webanwendungsprojekt auf der MSDN-Website und Datenbankbereitstellung mit VS 2010 im Blog von Vishal Joshi.

One-Click Veröffentlichen für Webanwendungen

Mit 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 zum Testen von Servern oder Stagingservern erstellen. Jedes Profil kann die entsprechenden Anmeldeinformationen sicher speichern. Anschließend können Sie die Bereitstellung auf jedem der Zielserver mit einem Klick durchführen, indem Sie die 1-Klick-Veröffentlichungssymbolleiste im Web verwenden. Mit Visual Studio 2010 können Sie auch über die MSBuild-Befehlszeile veröffentlichen. Auf diese Weise können Sie Ihre Teambuildumgebung so konfigurieren, dass die Veröffentlichung in ein Continuous Integration-Modell einbezogen wird.

Weitere Informationen finden Sie unter How to: Deploy a Web Application Project Using One-Click Publish and Web Deploy on the MSDN-Website und Web 1-Click Publish with VS 2010 im Vishal Joshi Blog. Videopräsentationen zur Bereitstellung von Webanwendungen in Visual Studio 2010 finden Sie unter 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 ASP.NET eigenen Website des Teams.
https://www.asp.net/dynamicdata/ und ASP.NET Dynamische Dateninhaltszuordnung – Onlineressourcen auf der ASP.NET Teamwebsite und in der offiziellen Dokumentation für ASP.NET Dynamic Data.
https://www.asp.net/ajax/– Die Standard-Webressource für ASP.NET Ajax-Entwicklung.
https://devblogs.microsoft.com/dotnet/category/aspnet/ – Der Visual Web Developer Team-Blog, der Informationen zu Features in Visual Studio 2010 enthält.
ASP.NET WebStack– Die Standard Webressource für Vorschauversionen von ASP.NET.

Haftungsausschluss

Dies ist ein vorläufiges Dokument, das vor der kommerziellen Veröffentlichung der beschriebenen Software ggf. erheblich geändert wird.

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 wechselnde Marktbedingungen reagieren muss, sollten sie nicht als Verpflichtung seitens Microsoft interpretiert werden, und Microsoft kann die Genauigkeit der dargelegten Informationen nach dem Zeitpunkt der Veröffentlichung nicht garantieren.

Dieses Whitepaper dient ausschließlich Informationszwecken. MICROSOFT ÜBERNIMMT KEINE AUSDRÜCKLICHE, STILLSCHWEIGENDE ODER AUS GESETZ ERWACHSENDE GARANTIE IN BEZUG AUF DIE INFORMATIONEN IN DIESEM DOKUMENT.

Die Benutzer/innen sind verpflichtet, sich an alle anwendbaren Urheberrechtsgesetze zu halten. Unabhängig von der Anwendbarkeit der entsprechenden Urheberrechtsgesetze darf kein Teil dieses Dokuments ohne ausdrückliche schriftliche Erlaubnis der Microsoft Corporation für irgendwelche Zwecke vervielfältigt oder in einem Datenempfangssystem gespeichert oder darin eingelesen werden, unabhängig davon, auf welche Art und Weise oder mit welchen Mitteln (elektronisch, mechanisch, durch Fotokopieren, Aufzeichnen usw.) dies geschieht.

Es ist möglich, dass Microsoft Rechte an Patenten bzw. an angemeldeten Patenten, an Marken, Urheberrechten oder sonstigem geistigen Eigentum besitzt, die sich auf den fachlichen Inhalt dieses Dokuments beziehen. Die Bereitstellung dieses Dokuments gewährt Ihnen jedoch keinerlei Lizenzrechte an diesen Patenten, Marken, Urheberrechten oder anderem geistigen Eigentum, es sei denn, dies wurde ausdrücklich durch einen schriftlichen Lizenzvertrag mit der Microsoft Corporation vereinbart.

Sofern nicht anders angegeben, sind die hier dargestellten Beispielunternehmen, Organisationen, Produkte, Domänennamen, E-Mail-Adressen, Logos, Personen, Orte und Ereignisse fiktiv, und es ist keine Verbindung mit einem echten Unternehmen, organization, Produkt, Domänennamen, E-Mail-Adresse, Logo, Person, Ort oder Ereignis beabsichtigt oder sollte abgeleitet werden.

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

Die in diesem Dokument erwähnten Namen von Unternehmen und Produkten können Marken der jeweiligen Eigentümer sein.

Freigeben über

Übersicht über ASP.NET 4 und Visual Studio 2010 für die Webentwicklung

Kerndienste

refactoring von Web.config-Dateien

Erweiterbare Ausgabezwischenspeicherung

Webanwendungen für den automatischen Start

Dauerhaftes Umleiten einer Seite

Sitzungsstatus verkleinern

Erweitern des Bereichs zulässiger URLs

Erweiterbare Anforderungsüberprüfung

Erweiterbarkeit für Objektzwischenspeicherung und Objektzwischenspeicherung

Erweiterbare HTML-, URL- und HTTP-Headercodierung

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

Festlegung von Zielversionen

Ajax

jQuery in Web Forms und MVC enthalten

Content Delivery Network-Unterstützung

Explizite ScriptManager-Skripts

Web Forms

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

Aktivieren des Ansichtszustands für einzelne Steuerelemente

Änderungen an Browserfunktionen

Verwenden von Browserfunktionenanbietern

Ersetzen der ASP.NET-Browserfunktionen

Zwischenspeichern des HttpBrowserCapabilities-Objekts

Erweitern ASP.NET Browserfunktionen

Erweitern von Browserfunktionen durch Hinzufügen neuer Funktionen zu vorhandenen Funktionendefinitionen

Routing in ASP.NET 4

Routing für Web Forms Seiten

Lesen von Routinginformationen auf einer Web Forms Seite

Zugreifen auf Routinginformationen im Markup

Verwenden von Routendaten für Datenquellensteuerungsparameter

Festlegen von Client-IDs

Erstellen vorhersagbarer Client-IDs in Data-Bound-Steuerelementen

Beibehalten der Zeilenauswahl in Datensteuerelementen

ASP.NET Diagrammsteuerelement

Hinzufügen des Diagrammsteuerelements zu einer ASP.NET Seite

Verwenden von 3D-Diagrammen

Verwenden von Skalierungsunterbrechungen und logarithmischen Skalen

Filtern von Daten mit dem QueryExtender-Steuerelement

Suche

Range

Propertyexpression

CustomExpression

HTML-codierte Codeausdrücke

Projektvorlagenänderungen

Leere Webanwendungsvorlage

Webanwendungs- und Websiteprojektvorlagen

CSS-Verbesserungen

Kompatibilitätseinstellung für Rendering

Deaktivieren von Steuerelementen

Ausblenden von div-Elementen um ausgeblendete Felder

Rendern einer äußeren Tabelle für Steuerelemente mit Vorlagen

Verbesserungen des ListView-Steuerelements

Verbesserungen des CheckBoxList- und RadioButtonList-Steuerelements

Verbesserungen bei Menüsteuerelementen

Assistenten und CreateUserWizard-Steuerelemente

ASP.NET MVC

Bereichsunterstützung

Unterstützung der Data-Annotation-Attributvalidierung

Vorlagenhilfsprogramme

Dynamic Data

Aktivieren von dynamischen Daten für vorhandene Projekte

Deklarative DynamicDataManager-Steuerelementsyntax

Entitätsvorlagen

Neue Feldvorlagen für URLs und Email Adressen

Erstellen von Links mit dem DynamicHyperLink-Steuerelement

Unterstützung für vererbung im Datenmodell

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

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

Erweiterte Unterstützung für Filter

Verbesserungen der Visual Studio 2010-Webentwicklung

Verbesserte CSS-Kompatibilität

HTML- und JavaScript-Codeausschnitte

JavaScript-IntelliSense-Erweiterungen

Webanwendungsbereitstellung mit Visual Studio 2010

Webverpackung

Web.config Transformation

Datenbankbereitstellung

One-Click Veröffentlichen für Webanwendungen