Freigeben über

ASP.NET and Web Tools für Visual Studio 2013 – Anmerkungen zu dieser Version

  • Artikel

von Microsoft

In diesem Dokument wird die Version von ASP.NET und Webtools für Visual Studio 2013 beschrieben.

Contents

Neue Features in ASP.NET und Webtools für Visual Studio 2013

Installation Notes (SAP-Supporthinweis 1984787 – SUSE Linux Enterprise Server 12: Installationshinweise)

ASP.NET und Webtools für Visual Studio 2013 werden im Hauptinstallationsprogramm gebündelt und können hier heruntergeladen werden.

Dokumentation

Lernprogramme und weitere Informationen zu ASP.NET und Webtools für Visual Studio 2013 finden Sie auf der ASP.NET-Website.

Softwareanforderungen

ASP.NET und Webtools erfordert Visual Studio 2013.

Neue Features in ASP.NET und Webtools für Visual Studio 2013

In den folgenden Abschnitten werden die Features beschrieben, die in der Version eingeführt wurden.

Ein ASP.NET

Mit der Veröffentlichung von Visual Studio 2013 haben wir einen Schritt zur Vereinheitlichung der Erfahrung bei der Verwendung von ASP.NET Technologien unternommen, sodass Sie die gewünschten Technologien problemlos kombinieren und aufeinander abstimmen können. Sie können z. B. ein Projekt mit MVC starten und dem Projekt später Web Forms-Seiten hinzufügen oder Web-APIs in einem Web forms-Projekt erstellen. Eine ASP.NET ist es, Ihnen als Entwickler die Dinge zu erleichtern, die Sie in ASP.NET lieben. Unabhängig davon, welche Technologie Sie auswählen, können Sie vertrauen, dass Sie auf dem vertrauenswürdigen zugrunde liegenden Framework von One ASP.NET aufbauen.

Neue Webprojektoberfläche

Wir haben die Erfahrung beim Erstellen neuer Webprojekte in Visual Studio 2013 verbessert. Im Dialogfeld "Neues ASP.NET Webprojekt" können Sie den gewünschten Projekttyp auswählen, eine beliebige Kombination von Technologien konfigurieren (Webformulare, MVC, Web-API), Authentifizierungsoptionen konfigurieren und ein Komponententestprojekt hinzufügen.

Neues ASP.NET Projekt

Mit dem neuen Dialogfeld können Sie die Standardauthentifizierungsoptionen für viele der Vorlagen ändern. Wenn Sie beispielsweise ein ASP.NET Web Forms-Projekt erstellen, können Sie eine der folgenden Optionen auswählen:

  • Keine Authentifizierung
  • Einzelne Benutzerkonten (ASP.NET Mitgliedschafts- oder Social Provider-Anmeldung)
  • Organisationskonten (Active Directory in einer Internetanwendung)
  • Windows-Authentifizierung (Active Directory in einer Intranetanwendung)

Authentifizierungsoptionen

Weitere Informationen zu den neuen Authentifizierungsoptionen finden Sie unter ASP.NET Identität weiter unten in diesem Dokument.

ASP.NET Gerüst

ASP.NET Gerüst ist ein Codegenerierungsframework für ASP.NET Webanwendungen. Es erleichtert das Hinzufügen von Codebausteinen zu Ihrem Projekt, das mit einem Datenmodell interagiert.

In früheren Versionen von Visual Studio war das Gerüst auf ASP.NET MVC-Projekte beschränkt. Mit Visual Studio 2013 können Sie jetzt ein Gerüst für jedes ASP.NET Projekt verwenden, einschließlich Webformularen. Visual Studio 2013 unterstützt derzeit das Generieren von Seiten für ein Web Forms-Projekt nicht, Sie können jedoch trotzdem Gerüste mit Web Forms verwenden, indem Sie dem Projekt MVC-Abhängigkeiten hinzufügen. Unterstützung für das Generieren von Seiten für Webformulare wird in einem zukünftigen Update hinzugefügt.

Bei Verwendung des Gerüsts stellen wir sicher, dass alle erforderlichen Abhängigkeiten im Projekt installiert sind. Wenn Sie z. B. mit einem ASP.NET Web Forms-Projekt beginnen und dann ein Gerüst verwenden, um einen Web-API-Controller hinzuzufügen, werden die erforderlichen NuGet-Pakete und -Verweise automatisch zu Ihrem Projekt hinzugefügt.

Um einem Web Forms-Projekt MVC-Gerüst hinzuzufügen, fügen Sie ein neues Gerüstelement hinzu, und wählen Sie im Dialogfeld MVC 5-Abhängigkeiten aus. Es gibt zwei Optionen für die Gerüsterstellung von MVC; Minimal und voll. Wenn Sie "Minimal" auswählen, werden ihrem Projekt nur die NuGet-Pakete und Verweise für ASP.NET MVC hinzugefügt. Wenn Sie die Option "Vollständig" auswählen, werden die minimalen Abhängigkeiten sowie die erforderlichen Inhaltsdateien für ein MVC-Projekt hinzugefügt.

Unterstützung für das Gerüst für asynchrone Controller verwendet die neuen asynchronen Features von Entity Framework 6.

Weitere Informationen und Lernprogramme finden Sie unter ASP.NET Gerüstübersicht.

Browserlink – SignalR-Kanal zwischen Browser und Visual Studio

Mit dem neuen Feature "Browserlink " können Sie mehrere Browser mit Visual Studio verbinden und alle aktualisieren, indem Sie auf eine Schaltfläche auf der Symbolleiste klicken. Sie können mehrere Browser mit Ihrer Entwicklungswebsite verbinden, einschließlich mobiler Emulatoren, und klicken Sie auf "Aktualisieren", um alle Browser gleichzeitig zu aktualisieren. Der Browserlink macht außerdem eine API verfügbar, mit der Entwickler Browserlinkerweiterungen schreiben können.

Screenshot des Visual Studio-Menüs mit hervorgehobener Symbol

Indem Entwickler die Browserlink-API nutzen können, wird es möglich, sehr erweiterte Szenarien zu erstellen, die Grenzen zwischen Visual Studio und jedem verbundenen Browser überschreiten. Web Essentials nutzt die API, um eine integrierte Oberfläche zwischen Visual Studio und den Entwicklertools des Browsers zu erstellen, mobile Emulatoren remote zu steuern und vieles mehr.

Verbesserungen des Visual Studio-Web-Editors

Visual Studio 2013 enthält einen neuen HTML-Editor für Razor-Dateien und HTML-Dateien in Webanwendungen. Der neue HTML-Editor stellt ein einzelnes einheitliches Schema basierend auf HTML5 bereit. Es verfügt über die automatische Klammerabschluss, jQuery UI und AngularJS-Attribut IntelliSense, Attribut IntelliSense Grouping, ID und Klassenname IntelliSense und andere Verbesserungen, einschließlich besserer Leistung, Formatierung und SmartTags.

Der folgende Screenshot veranschaulicht die Verwendung des Bootstrap-Attributs IntelliSense im HTML-Editor.

IntelliSense im HTML-Editor

Visual Studio 2013 verfügt auch über integrierte CoffeeScript- und LESS-Editoren. Der LESS-Editor enthält alle coolen Features aus dem CSS-Editor und verfügt über spezifische IntelliSense für Variablen und Mixins in allen LESS-Dokumenten in der @import Kette.

Azure-App Service Web-Apps Support in Visual Studio

In Visual Studio 2013 mit dem Azure SDK für .NET 2.2 können Sie den Server-Explorer verwenden, um direkt mit Ihren Remoteweb-Apps zu interagieren. Sie können sich bei Ihrem Azure-Konto anmelden, neue Web-Apps erstellen, Apps konfigurieren, Echtzeitprotokolle anzeigen und vieles mehr. In Kürze verfügbar, nachdem SDK 2.2 veröffentlicht wurde, können Sie remote im Debugmodus in Azure ausgeführt werden. Die meisten neuen Features für Azure-App Service Web-Apps funktionieren auch in Visual Studio 2012, wenn Sie die aktuelle Version des Azure SDK für .NET installieren.

Weitere Informationen finden Sie in den folgenden Ressourcen:

Verbesserungen beim Veröffentlichen von Webveröffentlichungen

Visual Studio 2013 enthält neue und erweiterte Webveröffentlichungsfeatures. Einige davon sind:

  • Automatisieren Sie einfach die Web.config-Dateiverschlüsselung. (Dieser Link und die folgenden beiden Hinweise auf die Dokumentation auf MSDN, die möglicherweise erst spät am 10.17. verfügbar sind.)
  • Automatisieren Sie die Offlineaufnahme einer Anwendung während der Bereitstellung ganz einfach.
  • Konfigurieren Sie Web Deploy so, dass die Dateiprüfsumme anstelle des Datums der letzten Änderung verwendet wird, um zu bestimmen, welche Dateien auf den Server kopiert werden sollen.
  • Veröffentlichen Sie schnell einzelne ausgewählte Dateien (einschließlich Web.config), wenn Sie die FTP- oder Dateisystem-Veröffentlichungsmethoden sowie web Deploy verwenden.

Weitere Informationen zur ASP.NET Webbereitstellung finden Sie auf der ASP.NET Website.

NuGet 2.7

NuGet 2.7 enthält eine vielzahl neuer Features, die in den Versionshinweisen zu NuGet 2.7 ausführlich beschrieben werden.

Diese Version von NuGet entfernt auch die Notwendigkeit, explizite Zustimmung für das Paketwiederherstellungsfeature von NuGet zum Herunterladen von Paketen bereitzustellen. Die Zustimmung (und das zugehörige Kontrollkästchen im Einstellungsdialogfeld von NuGet) wird jetzt durch Installieren von NuGet gewährt. Jetzt funktioniert die Paketwiederherstellung einfach standardmäßig.

ASP.NET Web Forms

Ein ASP.NET

Die Web Forms-Projektvorlagen werden nahtlos in die neue One ASP.NET-Oberfläche integriert. Sie können Ihrem Web Forms-Projekt MVC- und Web-API-Unterstützung hinzufügen und die Authentifizierung mithilfe des Assistenten zum Erstellen von Projekten in One ASP.NET konfigurieren.

ASP.NET Identity

Die Web Forms-Projektvorlagen unterstützen das neue ASP.NET Identity Framework. Darüber hinaus unterstützen die Vorlagen jetzt die Erstellung eines Web Forms-Intranetprojekts.

Bootstrap

Die Webformularvorlagen verwenden Bootstrap , um ein schlankes und reaktionsfähiges Aussehen und Verhalten bereitzustellen, das Sie einfach anpassen können.

ASP.NET MVC 5

Ein ASP.NET

Die Web MVC-Projektvorlagen werden nahtlos in die neue One ASP.NET-Oberfläche integriert. Sie können Ihr MVC-Projekt anpassen und die Authentifizierung mithilfe des Assistenten zum Erstellen von One ASP.NET-Projekten konfigurieren. Ein einführungslernprogramm für ASP.NET MVC 5 finden Sie unter "Erste Schritte mit ASP.NET MVC 5".

Informationen zum Upgrade von MVC 4-Projekten auf MVC 5 finden Sie unter Upgrade eines ASP.NET MVC 4- und Web-API-Projekts auf ASP.NET MVC 5 und Web API 2.

ASP.NET Identity

Die MVC-Projektvorlagen wurden aktualisiert, um ASP.NET Identität für die Authentifizierung und identitätsverwaltung zu verwenden. Ein Lernprogramm mit Facebook- und Google-Authentifizierung und der neuen Mitgliedschafts-API finden Sie unter Create an ASP.NET MVC 5 App with Facebook and Google OAuth2 and OpenID Sign-on and Create an ASP.NET MVC app with auth and SQL DB and deploy to Azure-App Service.

Bootstrap

Die MVC-Projektvorlage wurde aktualisiert, um Bootstrap zu verwenden, um ein schlankes und reaktionsfähiges Aussehen und Verhalten bereitzustellen, das Sie einfach anpassen können.

Authentifizierungsfilter

Authentifizierungsfilter sind eine neue Art von Filter in ASP.NET MVC, die vor Autorisierungsfiltern in der ASP.NET MVC-Pipeline ausgeführt werden und es Ihnen ermöglichen, Authentifizierungslogik pro Aktion, pro Controller oder global für alle Controller anzugeben. Authentifizierungsfilter verarbeiten Anmeldeinformationen in der Anforderung und stellen einen entsprechenden Prinzipal bereit. Authentifizierungsfilter können auch Authentifizierungsprobleme als Reaktion auf nicht autorisierte Anforderungen hinzufügen.

Filterüberschreibungen

Sie können jetzt überschreiben, welche Filter auf eine bestimmte Aktionsmethode oder einen Bestimmten Controller angewendet werden, indem Sie einen Außerkraftsetzungsfilter angeben. Überschreiben von Filtern geben einen Satz von Filtertypen an, die nicht für einen bestimmten Bereich (Aktion oder Controller) ausgeführt werden sollen. Auf diese Weise können Sie Filter konfigurieren, die global angewendet werden, aber dann bestimmte globale Filter von der Anwendung auf bestimmte Aktionen oder Controller ausschließen.

Attributrouting

ASP.NET MVC unterstützt jetzt attributweiterleitung dank eines Beitrags von Tim McCall, dem Autor von http://attributerouting.net. Mit Attributrouting können Sie Ihre Routen angeben, indem Sie Ihre Aktionen und Controller kommentieren.

ASP.NET-Web-API 2

Attributrouting

ASP.NET-Web-API unterstützt jetzt Attributrouting, dank eines Beitrags von Tim McCall, dem Autor von http://attributerouting.net. Mit Attributrouting können Sie Ihre Web-API-Routen angeben, indem Sie Ihre Aktionen und Controller wie folgt kommentieren:

[RoutePrefix("orders")] 
public class OrdersController : ApiController 
{ 
    [Route("{id}")] 
    public Order Get(int id) { } 
    [Route("{id}/approve")] 
    public Order Approve(int id) { } 
}

Das Attributrouting bietet Ihnen mehr Kontrolle über die URIs in Ihrer Web-API. Beispielsweise können Sie eine Ressourcenhierarchie ganz einfach mit einem einzelnen API-Controller definieren:

public class MoviesController : ApiController 
{ 
    [Route("movies")] 
    public IEnumerable<Movie> Get() { } 
    [Route("actors/{actorId}/movies")] 
    public IEnumerable<Movie> GetByActor(int actorId) { } 
    [Route("directors/{directorId}/movies")] 
    public IEnumerable<Movie> GetByDirector(int directorId) { } 
}

Das Attributrouting bietet außerdem eine bequeme Syntax zum Angeben optionaler Parameter, Standardwerte und Routeneinschränkungen:

// Optional parameter
[Route("people/{name?}")]
// Default value
[Route("people/{name=Dan}")]
// Constraint: Alphabetic characters only. 
[Route("people/{name:alpha}")]

Weitere Informationen zum Attributrouting finden Sie unter Attributrouting in Web API 2.

OAuth 2.0

Die Web-API- und Single Page Application-Projektvorlagen unterstützen jetzt die Autorisierung mit OAuth 2.0. OAuth 2.0 ist ein Framework zum Autorisieren des Clientzugriffs auf geschützte Ressourcen. Es funktioniert für eine Vielzahl von Clients, einschließlich Browsern und mobilen Geräten.

Die Unterstützung für OAuth 2.0 basiert auf neuer Sicherheits-Middleware, die von den Microsoft OWIN-Komponenten für die Bearerauthentifizierung und implementierung der Autorisierungsserverrolle bereitgestellt wird. Alternativ können Clients mithilfe eines Organisationsautorisierungsservers autorisiert werden, z. B. Azure Active Directory oder ADFS in Windows Server 2012 R2.

OData-Verbesserungen

Unterstützung für $select, $expand, $batch und $value

ASP.NET-Web-API OData verfügt jetzt über vollständige Unterstützung für $select, $expand und $value. Sie können auch $batch zum Anfordern von Batchverarbeitung und Verarbeitung von Änderungssätzen verwenden.

Mit den Optionen $select und $expand können Sie die Form der Daten ändern, die von einem OData-Endpunkt zurückgegeben werden. Weitere Informationen finden Sie unter Einführung in $select und $expand Unterstützung in Web-API-OData.

Verbesserte Erweiterbarkeit

Die OData-Formatierer sind jetzt erweiterbar. Sie können Atom-Eintragsmetadaten hinzufügen, benannte Stream- und Medienlinkeinträge unterstützen, Instanzanmerkungen hinzufügen und anpassen, wie Links generiert werden.

Unterstützung ohne Typ

Sie können jetzt OData-Dienste erstellen, ohne CLR-Typen für Ihre Entitätstypen zu definieren. Stattdessen können Ihre OData-Controller Instanzen von IEdmObject verwenden oder zurückgeben, die die OData-Formatierer serialisieren/deserialisieren.

Wiederverwenden eines vorhandenen Modells

Wenn Sie bereits über ein Vorhandenes Entitätsdatenmodell (Entity Data Model, EDM) verfügen, können Sie es jetzt direkt wiederverwenden, anstatt ein neues modellieren zu müssen. Wenn Sie beispielsweise Entity Framework verwenden, können Sie den EDM verwenden, den EF für Sie erstellt.

Batchverarbeitung anfordern

Die Anforderungsbatchierung kombiniert mehrere Vorgänge in einer einzigen HTTP POST-Anforderung, um den Netzwerkdatenverkehr zu reduzieren und eine reibungslosere, weniger chatzige Benutzeroberfläche bereitzustellen. ASP.NET-Web-API unterstützt jetzt mehrere Strategien für die Anforderungsbatchierung:

  • Verwenden Sie den $batch Endpunkt eines OData-Diensts.
  • Packen Sie mehrere Anforderungen in eine einzelne mehrteilige MIME-Anforderung.
  • Verwenden Sie ein benutzerdefiniertes Batchverarbeitungsformat.

Um die Anforderungsbatchierung zu aktivieren, fügen Sie einfach eine Route mit einem Batchverarbeitungshandler zur Web-API-Konfiguration hinzu:

public static class WebApiConfig 
{ 
    public static void Register(HttpConfiguration config) 
    { 
        config.Routes.MapHttpBatchRoute( 
            routeName: "WebApiBatch", 
            routeTemplate: "api/batch", 
            batchHandler: new DefaultHttpBatchHandler(GlobalConfiguration.DefaultServer)); 
    } 
}

Sie können auch steuern, ob Anforderungen sequenziell oder in beliebiger Reihenfolge ausgeführt werden.

Portierbarer ASP.NET-Web-API-Client

Sie können jetzt den ASP.NET-Web-API Client verwenden, um portable Klassenbibliotheken zu erstellen, die in Ihren Windows Store- und Windows Phone 8-Anwendungen funktionieren. Sie können auch portable Formatierer erstellen, die über client- und serverübergreifend freigegeben werden können.

Verbesserte Testbarkeit

Web-API 2 erleichtert das Komponententest ihrer API-Controller. Instanziieren Sie einfach Ihren API-Controller mit Ihrer Anforderungsnachricht und Konfiguration, und rufen Sie dann die Aktionsmethode auf, die Sie testen möchten. Es ist auch einfach, die UrlHelper-Klasse für Aktionsmethoden zu modellieren, die die Verknüpfungsgenerierung ausführen.

IHttpActionResult

Sie können jetzt IHttpActionResult implementieren, um das Ergebnis Ihrer Web-API-Aktionsmethoden zu kapseln. Ein von einer Web-API-Aktionsmethode zurückgegebenes IHttpActionResult wird von der ASP.NET-Web-API Laufzeit ausgeführt, um die resultierende Antwortnachricht zu erzeugen. Ein IHttpActionResult kann von jeder Web-API-Aktion zurückgegeben werden, um komponententests ihrer Web-API-Implementierung zu vereinfachen. Zur Vereinfachung werden eine Reihe von IHttpActionResult-Implementierungen sofort bereitgestellt, einschließlich der Ergebnisse für die Rückgabe bestimmter Statuscodes, formatierter Inhalte oder von Inhalten ausgehandelter Antworten.

HttpRequestContext

Der neue HttpRequestContext verfolgt jeden Zustand, der an die Anforderung gebunden ist, aber nicht sofort von der Anforderung verfügbar ist. Sie können z. B. den HttpRequestContext zum Abrufen von Routendaten, dem Prinzipal der Anforderung, dem Clientzertifikat, dem UrlHelper und dem Stammverzeichnis des virtuellen Pfads verwenden. Sie können problemlos einen HttpRequestContext für Komponententests erstellen.

Da der Prinzipal für die Anforderung mit der Anforderung fließt, anstatt auf Thread.CurrentPrincipal zu vertrauen, ist der Prinzipal jetzt während der Gesamten Lebensdauer der Anforderung verfügbar, während sie sich in der Web-API-Pipeline befindet.

CORS

Dank eines weiteren großen Beitrags von Brock Allen unterstützt ASP.NET jetzt vollständig Cross Origin Request Sharing (CORS).

Die Browsersicherheit verhindert, dass eine Webseite AJAX-Anforderungen an eine andere Domäne richtet. CORS ist ein W3C-Standard, der es einem Server ermöglicht, die Richtlinie für denselben Ursprung zu entspannen. Mit CORS kann ein Server explizit einige ursprungsübergreifende Anforderungen zulassen und andere ablehnen.

Web-API 2 unterstützt jetzt CORS, einschließlich der automatischen Behandlung von Preflight-Anforderungen. Weitere Informationen finden Sie unter Aktivieren von ursprungsübergreifenden Anforderungen in ASP.NET Web-API.

Authentifizierungsfilter

Authentifizierungsfilter sind eine neue Art von Filter in ASP.NET-Web-API, die vor Autorisierungsfiltern in der ASP.NET-Web-API Pipeline ausgeführt werden, und es Ihnen ermöglichen, Authentifizierungslogik pro Aktion, pro Controller oder global für alle Controller anzugeben. Authentifizierungsfilter verarbeiten Anmeldeinformationen in der Anforderung und stellen einen entsprechenden Prinzipal bereit. Authentifizierungsfilter können auch Authentifizierungsprobleme als Reaktion auf nicht autorisierte Anforderungen hinzufügen.

Filterüberschreibungen

Sie können jetzt überschreiben, welche Filter auf eine bestimmte Aktionsmethode oder einen Bestimmten Controller angewendet werden, indem Sie einen Außerkraftsetzungsfilter angeben. Überschreiben von Filtern geben einen Satz von Filtertypen an, die nicht für einen bestimmten Bereich (Aktion oder Controller) ausgeführt werden sollen. Auf diese Weise können Sie globale Filter hinzufügen, aber dann einige von bestimmten Aktionen oder Controllern ausschließen.

OWIN-Integration

ASP.NET-Web-API unterstützt jetzt OWIN vollständig und kann auf jedem OWIN-fähigen Host ausgeführt werden. Außerdem ist ein HostAuthenticationFilter enthalten, der die Integration mit dem OWIN-Authentifizierungssystem ermöglicht.

Mit der OWIN-Integration können Sie die Web-API in Ihrem eigenen Prozess zusammen mit anderen OWIN-Middleware, z. B. SignalR, selbst hosten. Weitere Informationen finden Sie unter Verwenden von OWIN zum Self-Host-ASP.NET-Web-API.

ASP.NET SignalR 2.0

In den folgenden Abschnitten werden die Features von SignalR 2.0 beschrieben.

Ein Beispiel zum Upgrade eines vorhandenen 1.x-Projekts auf SignalR 2.0 finden Sie unter Upgrade eines SignalR 1.x-Projekts.

Basiert auf OWIN

SignalR 2.0 basiert vollständig auf OWIN (open Web Interface for .NET). Diese Änderung macht den Einrichtungsprozess für SignalR wesentlich konsistenter zwischen webgehosteten und selbst gehosteten SignalR-Anwendungen, erfordert aber auch eine Reihe von API-Änderungen.

MapHubs und MapConnection sind jetzt MapSignalR

Aus Gründen der Kompatibilität mit OWIN-Standards wurden diese Methoden umbenannt MapSignalRin . MapSignalR ohne Parameter aufgerufen werden alle Hubs (wie MapHubs in Version 1.x), um einzelne PersistentConnection-Objekte zuzuordnen, geben Sie den Verbindungstyp als Typparameter und die URL-Erweiterung für die Verbindung als erstes Argument an.

Die MapSignalR Methode wird in einer Owin-Startklasse aufgerufen. Visual Studio 2013 enthält eine neue Vorlage für eine Owin-Startklasse; Gehen Sie wie folgt vor, um diese Vorlage zu verwenden:

  1. Klicken Sie mit der rechten Maustaste auf das Projekt.
  2. Wählen Sie "Hinzufügen", "Neues Element" aus...
  3. Wählen Sie die Owin-Startklasse aus. Benennen Sie die neue Klasse Startup.cs.

In einer Webanwendung wird die Owin-Startklasse, die die MapSignalR Methode enthält, dann dem Startprozess von Owin mithilfe eines Eintrags im Anwendungseinstellungsknoten der Datei "Web.Config" hinzugefügt, wie unten dargestellt.

In einer selbst gehosteten Anwendung wird die Startup-Klasse als Typparameter der WebApp.Start Methode übergeben.

Zuordnen von Hubs und Verbindungen in SignalR 1.x (aus der globalen Anwendungsdatei in einer Webanwendung):

protected void Application_Start(object sender, EventArgs e) 
{
    // Map all hubs to "/signalr"
    RouteTable.Routes.MapHubs();
    // Map the Echo PersistentConnection to "/echo"
    RouteTable.Routes.MapConnection<myconnection>("echo", "/echo");
}

Zuordnen von Hubs und Verbindungen in SignalR 2.0 (aus einer Owin Startup-Klassendatei):

using Microsoft.AspNet.SignalR;
using Microsoft.Owin;
using Owin;

[assembly: OwinStartup(typeof(MyWebApplication.Startup))]

namespace MyWebApplication
{
    public class Startup
    {
        public void Configuration(IAppBuilder app)
        {
            // Map all hubs to "/signalr"
            app.MapSignalR();
            // Map the Echo PersistentConnection to "/echo"
            app.MapSignalR<echoconnection>("/echo");
        }
    }
}

In einer selbst gehosteten Anwendung wird die Startup-Klasse wie unten dargestellt als Typparameter für die WebApp.Start Methode übergeben.

string url = "http://localhost:8080";
using (WebApp.Start<startup>(url))
{
    Console.WriteLine("Server running on {0}", url);
    Console.ReadLine();
}

Domänenübergreifender Support

In SignalR 1.x wurden domänenübergreifende Anforderungen durch ein einzelnes EnableCrossDomain-Flag gesteuert. Dieses Flag kontrolliert sowohl JSONP- als auch CORS-Anforderungen. Für eine größere Flexibilität wurde alle CORS-Unterstützung aus der Serverkomponente von SignalR entfernt (JavaScript-Clients verwenden corS weiterhin normal, wenn erkannt wird, dass der Browser sie unterstützt), und neue OWIN-Middleware wurde zur Unterstützung dieser Szenarien zur Verfügung gestellt.

Wenn JSONP in SignalR 2.0 auf dem Client erforderlich ist (um domänenübergreifende Anforderungen in älteren Browsern zu unterstützen), muss sie explizit aktiviert werden, indem EnableJSONP das HubConfiguration Objekt truewie unten dargestellt festgelegt wird. JSONP ist standardmäßig deaktiviert, da es weniger sicher ist als CORS.

Um die neue CORS-Middleware in SignalR 2.0 hinzuzufügen, fügen Sie die Microsoft.Owin.Cors Bibliothek zu Ihrem Projekt hinzu, und rufen Sie UseCors vor der SignalR-Middleware auf, wie im folgenden Abschnitt gezeigt.

Fügen Sie Microsoft.Owin.Cors zu Ihrem Projekt hinzu: Führen Sie zum Installieren dieser Bibliothek den folgenden Befehl in der Paket-Manager-Konsole aus:

Install-Package Microsoft.Owin.Cors

Mit diesem Befehl wird die Version 2.0.0 des Pakets zu Ihrem Projekt hinzugefügt.

Aufrufen von UseCors

Die folgenden Codeausschnitte veranschaulichen, wie domänenübergreifende Verbindungen in SignalR 1.x und 2.0 implementiert werden.

Implementieren von domänenübergreifenden Anforderungen in SignalR 1.x (aus der globalen Anwendungsdatei)

protected void Application_Start(object sender, EventArgs e) 
{
    var hubConfiguration = new HubConfiguration();
    hubConfiguration.EnableCrossDomain = true;
    RouteTable.Routes.MapHubs(hubConfiguration);
}

Implementieren von domänenübergreifenden Anforderungen in SignalR 2.0 (aus einer C#-Codedatei)

Der folgende Code veranschaulicht, wie CORS oder JSONP in einem SignalR 2.0-Projekt aktiviert wird. In diesem Codebeispiel wird Map die CORS-Middleware verwendet und RunSignalR nicht MapSignalR, sodass die CORS-Middleware nur für die SignalR-Anforderungen ausgeführt wird, die CORS-Unterstützung erfordern (und nicht für den gesamten Datenverkehr auf dem in MapSignalR.) Map angegebenen Pfad auch für jede andere Middleware verwendet werden kann, die für ein bestimmtes URL-Präfix ausgeführt werden muss, anstatt für die gesamte Anwendung.

using Microsoft.AspNet.SignalR;
using Microsoft.Owin.Cors;
using Owin;

[assembly: OwinStartup(typeof(MyWebApplication.Startup))]

namespace MyWebApplication
{
    public class Startup
    {
        public void Configuration(IAppBuilder app)
        {
            // Branch the pipeline here for requests that start with "/signalr"
            app.Map("/signalr", map =>
            {
                // Setup the CORS middleware to run before SignalR.
                // By default this will allow all origins. You can 
                // configure the set of origins and/or http verbs by
                // providing a cors options with a different policy.
                map.UseCors(CorsOptions.AllowAll);
                var hubConfiguration = new HubConfiguration 
                {
                    // You can enable JSONP by uncommenting line below.
                    // JSONP requests are insecure but some older browsers (and some
                    // versions of IE) require JSONP to work cross domain
                    // EnableJSONP = true
                };
                // Run the SignalR pipeline. We're not using MapSignalR
                // since this branch already runs under the "/signalr"
                // path.
                map.RunSignalR(hubConfiguration);
            });
        }
    }
}

iOS- und Android-Unterstützung über MonoTouch und MonoDroid

Unterstützung für iOS- und Android-Clients mit MonoTouch- und MonoDroid-Komponenten aus der Xamarin-Bibliothek wurde hinzugefügt. Weitere Informationen zur Verwendung finden Sie unter Verwenden von Xamarin-Komponenten. Diese Komponenten sind im Xamarin Store verfügbar, wenn die SignalR RTW-Version verfügbar ist.

### Portable .NET-Client

Um die plattformübergreifende Entwicklung zu erleichtern, wurden die Silverlight-, WinRT- und Windows Phone-Clients durch einen einzigen tragbaren .NET-Client ersetzt, der die folgenden Plattformen unterstützt:

  • NET 4.5
  • Silverlight 5
  • WinRT (.NET für Windows Store-Apps)
  • Windows Phone 8

Neues Self-Host-Paket

Es gibt jetzt ein NuGet-Paket, um die ersten Schritte mit SignalR Self-Host (SignalR-Anwendungen, die in einem Prozess oder einer anderen Anwendung gehostet werden, anstatt in einem Webserver gehostet zu werden). Um ein selbsthostbasiertes Projekt zu aktualisieren, das mit SignalR 1.x erstellt wurde, entfernen Sie das Microsoft.AspNet.SignalR.Owin-Paket, und fügen Sie das Microsoft.AspNet.SignalR.SelfHost-Paket hinzu. Weitere Informationen zu den ersten Schritten mit dem Self-Host-Paket finden Sie im Lernprogramm: SignalR Self-Host.

Abwärtskompatible Serverunterstützung

In früheren Versionen von SignalR mussten die im Client verwendeten SignalR-Pakete und der Server identisch sein. Um Dick-Client-Anwendungen zu unterstützen, die schwierig zu aktualisieren wären, unterstützt SignalR 2.0 jetzt die Verwendung einer neueren Serverversion mit einem älteren Client. Hinweis: SignalR 2.0 unterstützt keine Server, die mit älteren Versionen mit neueren Clients erstellt wurden.

Entfernte Serverunterstützung für .NET 4.0

SignalR 2.0 hat die Unterstützung für die Serverinteroperabilität mit .NET 4.0 eingestellt. .NET 4.5 muss mit SignalR 2.0-Servern verwendet werden. Es gibt noch einen .NET 4.0-Client für SignalR 2.0.

Senden einer Nachricht an eine Liste von Clients und Gruppen

In SignalR 2.0 ist es möglich, eine Nachricht mithilfe einer Liste von Client- und Gruppen-IDs zu senden. Die folgenden Codeausschnitte veranschaulichen, wie dies funktioniert.

Senden einer Nachricht an eine Liste von Clients und Gruppen mithilfe von PersistentConnection

using Microsoft.AspNet.SignalR;
using System.Collections.Generic;
public class ChatConnection : PersistentConnection
{
    static List<string> ConnectionIds = new List<string>();
    static List<string> groups = new List<string>{"chatGroup", "chatGroup2"};
    protected override System.Threading.Tasks.Task OnReceived(IRequest request, string connectionId, string data)
    {
        Connection.Send(ConnectionIds, data);
        Groups.Send(groups, data);
        return base.OnReceived(request, connectionId, data);
    }
    protected override System.Threading.Tasks.Task OnConnected(IRequest request, string connectionId)
    {
        ConnectionIds.Add(connectionId);
        Groups.Add(connectionId, "chatGroup");
        return base.OnConnected(request, connectionId);
    }
    protected override System.Threading.Tasks.Task OnDisconnected(IRequest request, string connectionId)
    {
        ConnectionIds.Remove(connectionId);
        return base.OnDisconnected(request, connectionId);
    }
}

Senden einer Nachricht an eine Liste von Clients und Gruppen mithilfe von Hubs

using Microsoft.AspNet.SignalR;
using System.Collections.Generic;
public class ChatHub : Hub
{
    static List<string> ConnectionIds = new List<string>();
    static List<string> groups = new List<string> { "chatGroup", "chatGroup2" };
    public void Send(string name, string message)
    {
        // Call the broadcastMessage method to update clients.
        Clients.Clients(ConnectionIds).broadcastMessage(name, message);
        Clients.Groups(groups).broadcastMessage(name, message);
    }
    public override System.Threading.Tasks.Task OnConnected()
    {
        ConnectionIds.Add(Context.ConnectionId);
        Groups.Add(Context.ConnectionId, "chatGroup");
        return base.OnConnected();
    }
    public override System.Threading.Tasks.Task OnDisconnected()
    {
        ConnectionIds.Remove(Context.ConnectionId);
        return base.OnDisconnected();
    }
}

Senden einer Nachricht an einen bestimmten Benutzer

Mit diesem Feature können Benutzer angeben, was die UserId auf einer IRequest über eine neue Schnittstelle IUserIdProvider basiert:

Die IUserIdProvider-Schnittstelle

public interface IUserIdProvider
{
    string GetUserId(IRequest request);
}

Standardmäßig gibt es eine Implementierung, die die IPrincipal.Identity.Name des Benutzers als Benutzernamen verwendet.

In Hubs können Sie Nachrichten über eine neue API an diese Benutzer senden:

Verwenden der Clients.User-API

public class MyHub : Hub
{
    public void Send(string userId, string message)
    {
        Clients.User(userId).send(message);
    }
}

Bessere Unterstützung für die Fehlerbehandlung

Benutzer können hubException jetzt von jedem Hubaufruf auslösen. Der Konstruktor der HubException kann eine Zeichenfolgenmeldung und zusätzliche Fehlerdaten eines Objekts annehmen. SignalR serialisiert die Ausnahme automatisch und sendet sie an den Client, in dem sie zum Ablehnen/Fehlschlagen des Aufrufs der Hubmethode verwendet wird.

Die Einstellung für detaillierte Hubausnahmen hat keine Auswirkungen darauf , dass HubException an den Client zurückgesendet wird oder nicht. Sie wird immer gesendet.

Serverseitiger Code, der das Senden einer HubException an den Client veranschaulicht

public class MyHub : Hub
{
    public void Send(string message)
    {
        if(message.Contains("<script>"))
        {
            throw new HubException("This message will flow to the client", new { user = Context.User.Identity.Name, message = message });
        }

        Clients.All.send(message);
    }
}

JavaScript-Clientcode, der die Reaktion auf eine vom Server gesendete HubException veranschaulicht

myHub.server.send("<script>")
            .fail(function (e) {
                if (e.source === 'HubException') {
                    console.log(e.message + ' : ' + e.data.user);
                }
            });

.NET-Clientcode, der die Reaktion auf eine vom Server gesendete HubException veranschaulicht

try
{
    await myHub.Invoke("Send", "<script>");
}
catch(HubException ex)
{
    Conosle.WriteLine(ex.Message);
}

Einfachere Komponententests von Hubs

SignalR 2.0 enthält eine Schnittstelle, die auf Hubs aufgerufen IHubCallerConnectionContext wird, die es einfacher macht, simulierte clientseitige Aufrufe zu erstellen. Die folgenden Codeausschnitte veranschaulichen die Verwendung dieser Schnittstelle mit beliebten Testgurten xUnit.net und Moq.

Unit testing SignalR with xUnit.net

[Fact]
public void HubsAreMockableViaDynamic()
{
    bool sendCalled = false;
    var hub = new MyHub();
    var mockClients = new Mock<IHubCallerConnectionContext>();
    hub.Clients = mockClients.Object;
    dynamic all = new ExpandoObject();
    all.send = new Action<string>(message =>
    {
        sendCalled = true;
    });
    mockClients.Setup(m => m.All).Returns((ExpandoObject)all);
    hub.Send("foo");
    Assert.True(sendCalled);
}

Unit testing SignalR with moq

[Fact]
public interface IClientContract
{
    void send(string message);
}
public void HubsAreMockableViaType()
{
    var hub = new MyHub();
    var mockClients = new Mock<IHubCallerConnectionContext>();
    var all = new Mock<IClientContract>();
    hub.Clients = mockClients.Object;
    all.Setup(m => m.send(It.IsAny<string>())).Verifiable();
    mockClients.Setup(m => m.All).Returns(all.Object);
    hub.Send("foo");
    all.VerifyAll();

JavaScript-Fehlerbehandlung

In SignalR 2.0 geben alle JavaScript-Fehlerbehandlungsrückrufe JavaScript-Fehlerobjekte anstelle von unformatierten Zeichenfolgen zurück. Auf diese Weise kann SignalR umfassendere Informationen an Ihre Fehlerhandler fließen. Sie können die innere Ausnahme aus der source Eigenschaft des Fehlers abrufen.

JavaScript-Clientcode, der die Start.Fail-Ausnahme behandelt

connection.start().fail(function(e) {
    console.log('The error is: ' + e.message);
});

ASP.NET Identity

Neues ASP.NET Mitgliedschaftssystem

ASP.NET Identity ist das neue Mitgliedschaftssystem für ASP.NET Anwendungen. ASP.NET Identity erleichtert die Integration von benutzerspezifischen Profildaten in Anwendungsdaten. ASP.NET Identity ermöglicht es Ihnen auch, das Persistenzmodell für Benutzerprofile in Ihrer Anwendung auszuwählen. Sie können die Daten in einer SQL Server-Datenbank oder einem anderen Datenspeicher speichern, darunter auch NoSQL -Datenspeicher wie Azure Storage-Tabellen. Weitere Informationen finden Sie unter "Einzelne Benutzerkonten" beim Erstellen ASP.NET Webprojekte in Visual Studio 2013.

Anspruchsbasierte Authentifizierung

ASP.NET unterstützt jetzt die anspruchsbasierte Authentifizierung, bei der die Identität des Benutzers als Eine Gruppe von Ansprüchen von einem vertrauenswürdigen Aussteller dargestellt wird. Benutzer können mithilfe eines Benutzernamens und eines Kennworts authentifiziert werden, das in einer Anwendungsdatenbank verwaltet wird, oder soziale Identitätsanbieter verwenden (z. B. Microsoft-Konten, Facebook, Google, Twitter) oder Organisationskonten über Azure Active Directory oder Active Directory-Verbunddienste (AD FS) (ADFS).

Integration in Azure Active Directory und Windows Server Active Directory

Sie können jetzt ASP.NET Projekte erstellen, die Azure Active Directory oder Windows Server Active Directory (AD) für die Authentifizierung verwenden. Weitere Informationen finden Sie unter Organisationskonten beim Erstellen ASP.NET Webprojekte in Visual Studio 2013.

OWIN-Integration

ASP.NET Authentifizierung basiert jetzt auf OWIN-Middleware, die auf jedem OWIN-basierten Host verwendet werden kann. Weitere Informationen zu OWIN finden Sie im folgenden Abschnitt zu Microsoft OWIN Components .

Microsoft OWIN-Komponenten

Open Web Interface for .NET (OWIN) definiert eine Abstraktion zwischen .NET-Webservern und Webanwendungen. OWIN entkoppelt die Webanwendung vom Server, wodurch Webanwendungen hostagnostisch werden. Sie können z. B. eine OWIN-basierte Webanwendung in IIS hosten oder in einem benutzerdefinierten Prozess selbst hosten.

Änderungen, die in den Microsoft OWIN-Komponenten (auch als Katana-Projekt bezeichnet) eingeführt wurden, umfassen neue Server- und Hostkomponenten, neue Hilfsbibliotheken und Middleware sowie neue Authentifizierungs-Middleware.

Weitere Informationen zu OWIN und Katana finden Sie unter Neuigkeiten in OWIN und Katana.

Hinweis: OWIN-Anwendungen können nicht im klassischen IIS-Modus ausgeführt werden. Sie müssen im integrierten Modus ausgeführt werden.

Hinweis: OWIN-Anwendungen müssen voll vertrauenswürdig ausgeführt werden.

Neue Server und Hosts

Mit dieser Version wurden neue Komponenten hinzugefügt, um Self-Host-Szenarien zu ermöglichen. Zu diesen Komponenten gehören die folgenden NuGet-Pakete:

  • Microsoft.Owin.Host.HttpListener. Stellt einen OWIN-Server bereit, der httpListener verwendet, um auf HTTP-Anforderungen zu lauschen und sie in die OWIN-Pipeline zu leiten.
  • Microsoft.Owin.Hosting stellt eine Bibliothek für Entwickler bereit, die eine OWIN-Pipeline in einem benutzerdefinierten Prozess wie einer Konsolenanwendung oder einem Windows-Dienst selbst hosten möchten.
  • OwinHost. Stellt eine eigenständige ausführbare Datei bereit, mit der Sie eine OWIN-Pipeline selbst hosten Microsoft.Owin.Hosting können, ohne eine benutzerdefinierte Hostanwendung schreiben zu müssen.

Darüber hinaus ermöglicht das Microsoft.Owin.Host.SystemWeb Paket Middleware jetzt die Bereitstellung von Hinweisen auf den SystemWeb-Server , was angibt, dass die Middleware während einer bestimmten ASP.NET Pipelinephase aufgerufen werden soll. Dieses Feature ist besonders nützlich für Authentifizierungs-Middleware, die frühzeitig in der ASP.NET Pipeline ausgeführt werden sollte.

Hilfsbibliotheken und Middleware

Obwohl Sie OWIN-Komponenten nur mit den Funktions- und Typdefinitionen aus der OWIN-Spezifikation schreiben können, bietet das neue Microsoft.Owin Paket einen benutzerfreundlicheren Satz von Abstraktionen. Dieses Paket kombiniert mehrere frühere Pakete (z. B. Owin.Extensions, Owin.Types) in einem einzigen, gut strukturierten Objektmodell, das dann problemlos von anderen OWIN-Komponenten verwendet werden kann. In der Tat verwenden die meisten Microsoft OWIN-Komponenten jetzt dieses Paket.

Hinweis

OWIN-Anwendungen können nicht im klassischen IIS-Modus ausgeführt werden. Sie müssen im integrierten Modus ausgeführt werden.

Hinweis

OWIN-Anwendungen müssen voll vertrauenswürdig ausgeführt werden.

Diese Version enthält auch das Microsoft.Owin.Diagnostics-Paket, das Middleware enthält, um eine ausgeführte OWIN-Anwendung zu überprüfen, sowie die Fehler-Page-Middleware, um Fehler zu untersuchen.

Authentifizierungskomponenten

Die folgenden Authentifizierungskomponenten sind verfügbar.

  • Microsoft.Owin.Security.ActiveDirectory. Aktiviert die Authentifizierung mithilfe von lokalen oder cloudbasierten Verzeichnisdiensten.
  • Microsoft.Owin.Security.Cookies Ermöglicht die Authentifizierung mithilfe von Cookies. Dieses Paket wurde zuvor benannt Microsoft.Owin.Security.Forms.
  • Microsoft.Owin.Security.Facebook aktiviert die Authentifizierung mit dem OAuth-basierten Dienst von Facebook.
  • Microsoft.Owin.Security.Google Aktiviert die Authentifizierung mit dem OpenID-basierten Dienst von Google.
  • Microsoft.Owin.Security.Jwt Aktiviert die Authentifizierung mithilfe von JWT-Token.
  • Microsoft.Owin.Security.MicrosoftAccount Aktiviert die Authentifizierung mithilfe von Microsoft-Konten.
  • Microsoft.Owin.Security.OAuth. Stellt einen OAuth-Autorisierungsserver sowie Middleware für die Authentifizierung von Bearertoken bereit.
  • Microsoft.Owin.Security.Twitter aktiviert die Authentifizierung mithilfe des OAuth-basierten Diensts von Twitter.

Diese Version enthält auch das Microsoft.Owin.Cors Paket, das Middleware für die Verarbeitung ursprungsübergreifender HTTP-Anforderungen enthält.

Hinweis

Die Unterstützung für die JWT-Signatur wurde in der endgültigen Version von Visual Studio 2013 entfernt.

Entity Framework 6

Eine Liste der neuen Features und anderer Änderungen in Entity Framework 6 finden Sie im Versionsverlauf von Entity Framework.

ASP.NET Razor 3

ASP.NET Razor 3 umfasst die folgenden neuen Features:

  • Unterstützung für die Registerkartenbearbeitung. Zuvor funktionierte der Befehl "Dokument formatieren", "Automatisches Einrücken" und "Automatische Formatierung" in Visual Studio bei Verwendung der Option "Tabstopps beibehalten" nicht ordnungsgemäß. Diese Änderung korrigiert die Visual Studio-Formatierung für Razor-Code für die Tabstoppformatierung.
  • Unterstützung für URL-Neuschreibregeln beim Generieren von Links.
  • Entfernen des transparenten Sicherheitsattributes.

    Hinweis

    Dies ist eine bahnbrechende Änderung und macht Razor 3 mit MVC4 und früher inkompatibel, während Razor 2 mit MVC5 oder Assemblys kompatibel ist, die mit MVC5 kompiliert wurden.

=======

ASP.NET App anhalten

ASP.NET App Suspend ist ein spielveränderndes Feature in .NET Framework 4.5.1, das die Benutzererfahrung und das Wirtschaftliche Modell zum Hosten großer Anzahl von ASP.NET Websites auf einem einzelnen Computer radikal ändert. Weitere Informationen finden Sie unter ASP.NET App Suspend – reaktionsfähiges freigegebenes .NET-Webhosting.

Bekannte Probleme und wichtige Änderungen

In diesem Abschnitt werden bekannte Probleme und wichtige Änderungen in den ASP.NET und Webtools für Visual Studio 2013 beschrieben.

NuGet

  • Neue Paketwiederherstellung funktioniert bei Verwendung der SLN-Datei nicht bei Mono – wird in einem bevorstehenden nuget.exe Download- und NuGet.CommandLine-Paketupdate behoben.
  • Neue Paketwiederherstellung funktioniert nicht mit Wix-Projekten – wird in einem bevorstehenden nuget.exe Download- und NuGet.CommandLine-Paketupdate behoben.

ASP.NET-Web-API

  1. ODataQueryOptions<T>.ApplyTo(IQueryable) gibt nicht immer zurück IQueryable<T> , da wir Unterstützung für $select und $expand.

    Unsere früheren Beispiele für ODataQueryOptions<T> immer den Rückgabewert von ApplyTo zu IQueryable<T>. Dies funktionierte früher, da die zuvor unterstützten Abfrageoptionen ($filter, $orderby, $skip, $top) die Form der Abfrage nicht ändern. Da wir nun unterstützen $select und $expand der Rückgabewert nicht ApplyTo immer ist IQueryable<T> .

    // Sample ODataQueryOptions<T> usage from earlier
public IQueryable<Customer> Get(ODataQueryOptions<Customer> query)
{
    IQueryable<customer> result="query.ApplyTo(_customers)" as iqueryable<customer>; return result;
}

    Wenn Sie den Beispielcode aus früheren Versionen verwenden, funktioniert er weiterhin, wenn der Client nicht sendet $select und $expand. Wenn Sie diesen Code jedoch unterstützen $select möchten und $expand diesen Code ändern müssen.

    public IHttpActionResult Get(ODataQueryOptions<Customer> query)
{
    IQueryable result = query.ApplyTo(_customers);
    return Ok(result, result.GetType());
}
 
private IHttpActionResult Ok(object content, Type type)
{
    Type resultType = typeof(OkNegotiatedContentResult<>).MakeGenericType(type);
    return Activator.CreateInstance(resultType, content, this) as IHttpActionResult;
}

  2. Request.Url oder RequestContext.Url ist während einer Batchanforderung null.

    In einem Batchszenario ist UrlHelper null, wenn auf "Request.Url" oder "RequestContext.Url" zugegriffen wird.

    Die Problemumgehung für dieses Problem besteht darin, eine neue Instanz von UrlHelper zu erstellen, wie im folgenden Beispiel gezeigt:

    Erstellen einer neuen Instanz von UrlHelper

    if (RequestContext.Url == null)
{
    RequestContext.Url = new UrlHelper(Request);
}

ASP.NET MVC

  1. Wenn Sie MVC5 und OrgAuth verwenden, wenn Sie Ansichten haben, die die Überprüfung von AntiForgerToken ausführen, tritt möglicherweise der folgende Fehler auf, wenn Sie Daten in der Ansicht veröffentlichen:

    Fehler:

    Serverfehler in '/'-Anwendung

    Ein Anspruch vom Typ http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier oder https://schemas.microsoft.com/accesscontrolservice/2010/07/claims/identityprovider war für die bereitgestellte ClaimsIdentity nicht vorhanden. Um die Unterstützung von Anti-Forgery-Token mit anspruchsbasierter Authentifizierung zu aktivieren, stellen Sie sicher, dass der konfigurierte Anspruchsanbieter beide Ansprüche für die generierten ClaimsIdentity-Instanzen bereitstellt. Wenn der konfigurierte Anspruchsanbieter stattdessen einen anderen Anspruchstyp als eindeutigen Bezeichner verwendet, kann er durch Festlegen der statischen Eigenschaft AntiForgeryConfig.UniqueClaimTypeIdentifier konfiguriert werden.

    Problemumgehung:

    Fügen Sie die folgende Zeile in "Global.asax" hinzu, um sie zu beheben:

    AntiForgeryConfig.UniqueClaimTypeIdentifier = ClaimTypes.Name;

    Dies wird für die nächste Version behoben.

  2. Nachdem Sie eine MVC4-App auf MVC5 aktualisiert haben, erstellen Sie die Lösung, und starten Sie sie. Sie sollten folgenden Fehler erhalten:

    [A]System.Web.WebPages.Razor.Configuration.HostSection kann nicht in [B]System.Web.WebPages.Razor.Configuration.HostSection umgestellt werden. Typ A stammt aus 'System.Web.WebPages.Razor, Version=2.0.0.0,0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" im Kontext "Standard" am Speicherort "C:\windows\Microsoft.Net\assembly\GAC_MSIL\System.Web.WebPages.Razor\v4.0_2.0.0.0.0__31bf3856ad364e35\System.Web.WebPages.Razor.dll". Typ B stammt aus 'System.Web.WebPages.Razor, Version=3.0.0.0,0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" im Kontext "Standard" am Speicherort "C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\root\6d05bbd0\e8b5908e\assembly\dl3\c9cbca63\f8910382_6273ce01\System.Web.WebPages.Razor.dll'.

    Um den obigen Fehler zu beheben, öffnen Sie alle Web.config-Dateien (einschließlich der Dateien im Ordner "Ansichten") in Ihrem Projekt, und gehen Sie wie folgt vor:

    1. Aktualisieren Sie alle Vorkommen der Version "4.0.0.0" von "System.Web.Mvc" auf "5.0.0.0".

    2. Alle Vorkommen der Version "2.0.0.0" von "System.Web.Helpers", "System.Web.WebPages" und "System.Web.WebPages.Razor" auf "3.0.0.0.0" aktualisieren

      Nachdem Sie beispielsweise die oben genannten Änderungen vorgenommen haben, sollten die Assemblybindungen wie folgt aussehen:

      <dependentAssembly>
  <assemblyIdentity name="System.Web.Helpers" publicKeyToken="31bf3856ad364e35" />
  <bindingRedirect oldVersion="1.0.0.0-2.0.0.0" newVersion="3.0.0.0" />
  </dependentAssembly>
  <dependentAssembly>
  <assemblyIdentity name="System.Web.WebPages" publicKeyToken="31bf3856ad364e35" />
  <bindingRedirect oldVersion="1.0.0.0-2.0.0.0" newVersion="3.0.0.0" />
  </dependentAssembly>
  <dependentAssembly>
  <assemblyIdentity name="System.Web.WebPages.Razor" publicKeyToken="31bf3856ad364e35" />
  <bindingRedirect oldVersion="1.0.0.0-3.0.0.0" newVersion="3.0.0.0" />
  </dependentAssembly>
  <dependentAssembly>
  <assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35" />
  <bindingRedirect oldVersion="1.0.0.0-4.0.0.0" newVersion="5.0.0.0" />
</dependentAssembly>

      Informationen zum Upgrade von MVC 4-Projekten auf MVC 5 finden Sie unter Upgrade eines ASP.NET MVC 4- und Web-API-Projekts auf ASP.NET MVC 5 und Web API 2.

  3. Bei verwendung der clientseitigen Überprüfung mit jQuery Unobtrusive Validation ist die Überprüfungsmeldung für ein HTML-Eingabeelement mit type='number' manchmal falsch. Der Überprüfungsfehler für einen erforderlichen Wert ("Das Feld "Alter ist erforderlich") wird angezeigt, wenn eine ungültige Zahl anstelle der richtigen Meldung eingegeben wird, dass eine gültige Zahl erforderlich ist.

    Dieses Problem wird häufig mit Gerüstcode für ein Modell mit einer ganzzahligen Eigenschaft in den Ansichten "Erstellen" und "Bearbeiten" gefunden.

    Um dieses Problem zu umgehen, ändern Sie die Editor-Hilfsprogramm von:

    @Html.EditorFor(person => person.Age)

    In:

    @Html.TextBoxFor(person => person.Age)

  4. ASP.NET MVC 5 unterstützt keine teilweise Vertrauensstellung mehr. Projekte, die mit den MVC- oder WebAPI-Binärdateien verknüpfen, sollten das SecurityTransparent-Attribut und das AllowPartiallyTrustedCallers-Attribut entfernen. Durch das Entfernen dieser Attribute werden Compilerfehler wie die folgenden beseitigt.

    Attempt by security transparent method ‘MyComponent' to access security critical type 'System.Web.Mvc.MvcHtmlString' failed. Assembly 'PagedList.Mvc, Version=4.3.0.0, Culture=neutral, PublicKeyToken=abbb863e9397c5e1' is marked with the AllowPartiallyTrustedCallersAttribute, and uses the level 2 security transparency model. Level 2 transparency causes all methods in AllowPartiallyTrustedCallers assemblies to become security transparent by default, which may be the cause of this exception.

    Beachten Sie, dass Sie als Nebeneffekt nicht 4.0- und 5.0-Assemblys in derselben Anwendung verwenden können. Sie müssen alle auf 5.0 aktualisieren.

SPA-Vorlage mit Facebook-Autorisierung kann zu Instabilität in IE führen, während die Website in der Intranetzone gehostet wird

Die SPA-Vorlage stellt ein externes Anmelden mit Facebook bereit. Wenn das mit der Vorlage erstellte Projekt lokal ausgeführt wird, kann die Anmeldung dazu führen, dass IE abstürzt.

Lösung:

  1. Hosten Sie die Website in der Internetzone; oder

  2. Testen Sie das Szenario in einem anderen Browser als IE.

Web Forms-Gerüst

Web Forms Scaffolding wurde aus VS2013 entfernt und wird in einem zukünftigen Update für Visual Studio verfügbar sein. Sie können das Gerüst in einem Web Forms-Projekt jedoch weiterhin verwenden, indem Sie MVC-Abhängigkeiten hinzufügen und Gerüste für MVC generieren. Ihr Projekt enthält eine Kombination aus Webformularen und MVC.

Um Ihrem Web Forms-Projekt MVC hinzuzufügen, fügen Sie ein neues Gerüstelement hinzu, und wählen Sie MVC 5-Abhängigkeiten aus. Wählen Sie entweder "Minimal" oder "Vollständig" aus, je nachdem, ob Sie alle Inhaltsdateien benötigen, z. B. Skripts. Fügen Sie dann ein Gerüstelement für MVC hinzu, das Ansichten und einen Controller in Ihrem Projekt erstellt.

MVC- und Web-API-Gerüst – HTTP 404, Fehler "Nicht gefunden"

Wenn beim Hinzufügen eines Gerüstelements zu einem Projekt ein Fehler auftritt, ist es möglich, dass Ihr Projekt in einem inkonsistenten Zustand verbleibt. Einige der vorgenommenen Änderungen werden Gerüste zurückgesetzt, andere Änderungen, z. B. die installierten NuGet-Pakete, werden jedoch nicht zurückgesetzt. Wenn die Routingkonfigurationsänderungen rückgängig gemacht werden, erhalten Benutzer beim Navigieren zu Gerüstelementen einen HTTP 404-Fehler.

Problemumgehung:

  • Um diesen Fehler für MVC zu beheben, fügen Sie ein neues Gerüstelement hinzu, und wählen Sie MVC 5-Abhängigkeiten (entweder minimal oder vollständig) aus. Dieser Vorgang fügt alle erforderlichen Änderungen zu Ihrem Projekt hinzu.

  • So beheben Sie diesen Fehler für die Web-API:

    1. Fügen Sie dem Projekt die WebApiConfig-Klasse hinzu.

      public static class WebApiConfig
{
    public static void Register(HttpConfiguration config)
    {
        config.MapHttpAttributeRoutes();
        config.Routes.MapHttpRoute(
            name: "DefaultApi",
            routeTemplate: "api/{controller}/{id}",
            defaults: new { id = RouteParameter.Optional }
        );
    }
}

      Public Module WebApiConfig
    Public Sub Register(ByVal config As HttpConfiguration)
        config.MapHttpAttributeRoutes()
        config.Routes.MapHttpRoute(
          name:="DefaultApi",
          routeTemplate:="api/{controller}/{id}",
          defaults:=New With {.id = RouteParameter.Optional}
        )
    End Sub
End Module

    2. Konfigurieren Sie WebApiConfig.Register in der Application_Start-Methode in "Global.asax" wie folgt:

      public class WebApiApplication : System.Web.HttpApplication
{
    protected void Application_Start()
    {
        GlobalConfiguration.Configure(WebApiConfig.Register);    
    }
}

      Public Class WebApiApplication
     Inherits System.Web.HttpApplication
 
     Sub Application_Start()     
       GlobalConfiguration.Configure(AddressOf WebApiConfig.Register)       
     End Sub
End Class