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

  • Artikel

von Microsoft

In diesem Dokument wird die Veröffentlichung von ASP.NET and Web Tools für Visual Studio 2013 beschrieben.

Inhalte

Neue Features in ASP.NET and Web Tools für Visual Studio 2013

Installationshinweise

ASP.NET and Web Tools für Visual Studio 2013 sind im Standard-Installationsprogramm gebündelt und können hier heruntergeladen werden.

Dokumentation

Tutorials und weitere Informationen zu ASP.NET and Web Tools für Visual Studio 2013 finden Sie auf der ASP.NET-Website.

Softwareanforderungen

ASP.NET and Web Tools erfordert Visual Studio 2013.

Neue Features in ASP.NET and Web Tools 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 auf dem Weg zur Vereinheitlichung der Erfahrung der Verwendung ASP.NET Technologien gemacht, sodass Sie die gewünschten Technologien problemlos kombinieren und abgleichen können. Beispielsweise können Sie ein Projekt mithilfe von MVC starten und dem Projekt später einfach Web Forms Seiten hinzufügen oder web-APIs in einem Web Forms-Projekt gerüstet. Eine ASP.NET besteht darin, es Ihnen als Entwickler zu erleichtern, die Dinge zu tun, die Sie in ASP.NET lieben. Unabhängig davon, für welche Technologie Sie sich entscheiden, können Sie darauf 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 (Web Forms, MVC, Web-API) konfigurieren, Authentifizierungsoptionen konfigurieren und ein Komponententestprojekt hinzufügen.

Neues ASP.NET-Projekt

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

  • Keine Authentifizierung
  • Individuelle Benutzerkonten (Anmeldung ASP.NET Mitgliedschaft oder Sozialer Anbieter)
  • Organisationskonten (Active Directory in einer Internetanwendung)
  • Windows-Authentifizierung (Active Directory in einer Intranetanwendung)

Authentifizierungsoptionen

Weitere Informationen zum neuen Prozess zum Erstellen von Webprojekten finden Sie unter Erstellen von ASP.NET Webprojekten in Visual Studio 2013. Weitere Informationen zu den neuen Authentifizierungsoptionen finden Sie weiter unten in diesem Dokument unter ASP.NET Identity .

ASP.NET Gerüstbau

ASP.NET Gerüstbau ist ein Codegenerierungsframework für ASP.NET Webanwendungen. Dadurch können Sie Ihrem Projekt ganz einfach Code hinzufügen, der mit einem Datenmodell interagiert.

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

Beim Verwenden des Gerüstbaus stellen wir sicher, dass alle erforderlichen Abhängigkeiten im Projekt installiert sind. Wenn Sie beispielsweise 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 ihrem Projekt hinzugefügt.

Um einem Web Forms Projekt MVC-Gerüste 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 zum Gerüstbau von MVC: Minimal und Vollständig. 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üstbau asynchroner Controller verwendet die neuen asynchronen Features von Entity Framework 6.

Weitere Informationen und Tutorials finden Sie unter übersicht über ASP.NET Gerüstbau.

Browserlink: SignalR-Kanal zwischen Browser und Visual Studio

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

Screenshot des Visual Studio-Menüs mit hervorgehobenem Symbol

Indem Entwickler die Vorteile der Browserlink-API nutzen können, wird es möglich, sehr fortgeschrittene Szenarien zu erstellen, die 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 bereit, das auf HTML5 basiert. Es verfügt über automatische Klammernabschluss, jQuery UI und AngularJS-Attribut IntelliSense, IntelliSense-Attribut, 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 enthält auch 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-Unterstützung in Visual Studio

In Visual Studio 2013 mit dem Azure SDK für .NET 2.2 können Sie 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. Bald nach der Veröffentlichung von SDK 2.2 können Sie remote in Azure im Debugmodus ausgeführt werden. Die meisten neuen Features für Azure App Service Web-Apps funktionieren auch in Visual Studio 2012, wenn Sie das aktuelle Release des Azure SDK für .NET installieren.

Weitere Informationen finden Sie in den folgenden Ressourcen:

Webveröffentlichungserweiterungen

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

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 entfällt auch die Notwendigkeit, explizite Zustimmung für das Paketwiederherstellungsfeature von NuGet zum Herunterladen von Paketen zu erteilen. Die Zustimmung (und das zugehörige Kontrollkästchen im Einstellungsdialogfeld von NuGet) wird jetzt erteilt, indem NuGet installiert wird. Jetzt funktioniert die Paketwiederherstellung einfach standardmäßig.

ASP.NET Web Forms

Ein ASP.NET

Die Web Forms Projektvorlagen sind nahtlos in die neue One ASP.NET-Benutzeroberfläche integriert. Sie können MVC- und Web-API-Unterstützung zu Ihrem Web Forms-Projekt hinzufügen und die Authentifizierung mithilfe des One ASP.NET Projekterstellungs-Assistenten konfigurieren. Weitere Informationen finden Sie unter Erstellen ASP.NET Webprojekte in Visual Studio 2013.

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. Weitere Informationen finden Sie unter Authentifizierungsmethoden unter Erstellen ASP.NET Webprojekte in Visual Studio 2013.

Bootstrap

Die Web Forms Vorlagen verwenden Bootstrap, um ein elegantes und reaktionsfähiges Erscheinungsbild zu bieten, das Sie einfach anpassen können. Weitere Informationen finden Sie unter Bootstrap in den Visual Studio 2013 Webprojektvorlagen.

ASP.NET MVC 5

Ein ASP.NET

Die Web-MVC-Projektvorlagen sind nahtlos in die neue One ASP.NET-Oberfläche integriert. Sie können Ihr MVC-Projekt anpassen und die Authentifizierung mit dem One ASP.NET-Projekterstellungs-Assistenten konfigurieren. Ein Einführungstutorial zum 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 Aktualisieren 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 Identity für die Authentifizierung und Identitätsverwaltung zu verwenden. Ein Tutorial zur Facebook- und Google-Authentifizierung und der neuen Mitgliedschafts-API finden Sie unter Erstellen einer ASP.NET MVC 5-App mit Facebook und Google OAuth2 und OpenID Anmelden und Erstellen einer ASP.NET MVC-App mit Authentifizierung und SQL-Datenbank und Bereitstellung in Azure App Service.

Bootstrap

Die MVC-Projektvorlage wurde aktualisiert, um Bootstrap zu verwenden, um ein elegantes und reaktionsfähiges Erscheinungsbild zu bieten, das Sie einfach anpassen können. Weitere Informationen finden Sie unter Bootstrap in den Visual Studio 2013 Webprojektvorlagen.

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 geben einen entsprechenden Prinzipal an. Authentifizierungsfilter können auch Authentifizierungsanforderungen 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 Überschreibungsfilter angeben. Überschreiben von Filtern geben eine Reihe von Filtertypen an, die für einen bestimmten Bereich (Aktion oder Controller) nicht 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 das Attributrouting, dank eines Beitrags von Tim McCall, dem Autor von http://attributerouting.net. Beim 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 das Attributrouting, dank eines Beitrags von Tim McCall, dem Autor von http://attributerouting.net. Beim 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) { } 
}

Attributrouting gibt 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) { } 
}

Attributrouting bietet auch eine praktische 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 Projektvorlagen Web-API und Einzelseitenanwendung 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 der neuen Sicherheits-Middleware, die von den Microsoft OWIN-Komponenten für die Bearerauthentifizierung und die Implementierung der Autorisierungsserverrolle bereitgestellt wird. Alternativ können Clients mithilfe eines Organisationsautorisierungsservers wie Azure Active Directory oder ADFS in Windows Server 2012 R2 autorisiert werden.

OData-Verbesserungen

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

ASP.NET-Web-API OData bietet jetzt volle Unterstützung für $select, $expand und $value. Sie können auch $batch für die Batchverarbeitung von Anforderungen und die 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, instance Anmerkungen 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 definieren zu müssen. Stattdessen können Ihre OData-Controller Instanzen von IEdmObject übernehmen oder zurückgeben, bei denen es sich um die OData-Formatierer serialisieren/deserialisieren handelt.

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 das EDM verwenden, das EF für Sie erstellt.

Anforderungsbatchierung

Das Anforderungsbatching kombiniert mehrere Vorgänge in einer einzelnen HTTP POST-Anforderung, um den Netzwerkdatenverkehr zu reduzieren und eine reibungslosere, weniger chatfreie Benutzeroberfläche zu bieten. 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 Batchformat.

Um die Anforderungsbatches zu aktivieren, fügen Sie einfach ihrer Web-API-Konfiguration eine Route mit einem Batchhandler 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.

Portabler ASP.NET-Web-API Client

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

Verbesserte Testbarkeit

Web-API 2 vereinfacht den 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 simulieren, die die Linkgenerierung durchfü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 Runtime ausgeführt, um die resultierende Antwortnachricht zu erzeugen. Ein IHttpActionResult kann von jeder Web-API-Aktion zurückgegeben werden, um das Komponententesten Ihrer Web-API-Implementierung zu vereinfachen. Zur Vereinfachung werden eine Reihe von IHttpActionResult-Implementierungen sofort bereitgestellt, einschließlich Ergebnissen für die Rückgabe bestimmter status Codes, formatierter Inhalte oder inhaltsverhandelter Antworten.

HttpRequestContext

Der neue HttpRequestContext verfolgt jeden Zustand nach, der an die Anforderung gebunden ist, aber nicht sofort über die Anforderung verfügbar ist. Beispielsweise können Sie httpRequestContext verwenden, um Routendaten, den der Anforderung zugeordneten Prinzipal, das Clientzertifikat, den UrlHelper und den virtuellen Pfadstamm abzurufen. Sie können auf einfache Weise einen HttpRequestContext für Komponententests erstellen.

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

CORS

Dank eines weiteren großartigen 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 desselben Ursprungs zu lockern. Mit CORS kann ein Server explizit einige ursprungsübergreifende Anforderungen zulassen und andere ablehnen.

Die 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. Die Authentifizierung filtert Anmeldeinformationen in der Anforderung, und geben Sie einen entsprechenden Prinzipal an. Authentifizierungsfilter können auch Authentifizierungsanforderungen 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 Überschreibungsfilter angeben. Außerkraftsetzungsfilter geben eine Reihe von Filtertypen an, die nicht für einen bestimmten Bereich (Aktion oder Controller) ausgeführt werden sollen. Dadurch können Sie globale Filter hinzufügen, dann aber einige von bestimmten Aktionen oder Controllern ausschließen.

OWIN-Integration

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

Mit der OWIN-Integration können Sie die Web-API in Ihrem eigenen Prozess zusammen mit anderen OWIN-Middleware wie 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 für das Upgrade eines vorhandenen 1.x-Projekts auf SignalR 2.0 finden Sie unter Aktualisieren eines SignalR 1.x-Projekts.

Basiert auf OWIN

SignalR 2.0 basiert vollständig auf OWIN (der Open Web Interface für .NET). Diese Änderung macht den Setupprozess für SignalR wesentlich konsistenter zwischen im Web gehosteten und selbstgehosteten SignalR-Anwendungen, erforderte 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 in MapSignalRumbenannt. MapSignalR ohne Parameter werden alle Hubs zugeordnet (wie MapHubs in Version 1.x). Geben Sie zum Zuordnen einzelner PersistentConnection-Objekte 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 Owin-Startklasse aus. Nennen Sie die neue Klasse Startup.cs.

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

In einer selbstgehosteten 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 selbstgehosteten 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übergreifende Unterstützung

In SignalR 1.x wurden domänenübergreifende Anforderungen durch ein einzelnes EnableCrossDomain-Flag gesteuert. Dieses Flag steuert sowohl JSONP- als auch CORS-Anforderungen. Um mehr Flexibilität zu erzielen, wurde die gesamte CORS-Unterstützung aus der Serverkomponente von SignalR entfernt (JavaScript-Clients verwenden CORS weiterhin normal, wenn erkannt wird, dass der Browser dies unterstützt), und neue OWIN-Middleware wurde zur Unterstützung dieser Szenarien zur Verfügung gestellt.

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

Um die neue CORS-Middleware in SignalR 2.0 hinzuzufügen, fügen Sie die Microsoft.Owin.Cors Bibliothek ihrem Projekt hinzu, und rufen Sie UseCors vor Ihrer SignalR-Middleware auf, wie im abschnitt unten gezeigt.

Hinzufügen von Microsoft.Owin.Cors zu Ihrem Projekt: Führen Sie den folgenden Befehl in der Paket-Manager-Konsole aus, um diese Bibliothek zu installieren:

Install-Package Microsoft.Owin.Cors

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

Aufrufen von UseCors

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

Implementieren domänenübergreifender 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 domänenübergreifender 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 und RunSignalR anstelle von MapSignalRverwendetMap, 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, der in MapSignalRangegeben ist). Map Kann auch für jede andere Middleware verwendet werden, die für ein bestimmtes URL-Präfix und nicht für die gesamte Anwendung ausgeführt werden muss.

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 das SignalR RTW-Release verfügbar ist.

### Portabler .NET-Client

Um die plattformübergreifende Entwicklung besser zu vereinfachen, wurden die Silverlight-, WinRT- und Windows Phone-Clients durch einen einzelnen portablen .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, das den Einstieg in SignalR Self-Host erleichtert (SignalR-Anwendungen, die in einem Prozess oder einer anderen Anwendung gehostet werden, anstatt auf einem Webserver gehostet zu werden). Um ein Mit SignalR 1.x erstelltes Selbsthostprojekt zu aktualisieren, entfernen Sie das Paket Microsoft.AspNet.SignalR.Owin, und fügen Sie das Paket Microsoft.AspNet.SignalR.SelfHost hinzu. Weitere Informationen zu den ersten Schritten mit dem Selbsthostpaket finden Sie unter Tutorial: SignalR Self-Host.

Abwärtskompatible Serverunterstützung

In früheren Versionen von SignalR mussten die Versionen des SignalR-Pakets, die im Client und auf dem Server verwendet wurden, identisch sein. Um Thick-Client-Anwendungen zu unterstützen, die schwer 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.

Serverunterstützung für .NET 4.0 wurde entfernt

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

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 basierend auf einer IRequest über eine neue Schnittstelle IUserIdProvider ist:

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 über jeden 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, wo sie verwendet wird, um den Aufruf der Hubmethode abzulehnen bzw. fehlzuschlagen.

Die Einstellung detaillierte Hubausnahmen anzeigen hat keinen Einfluss darauf , dass HubException an den Client zurückgesendet wird oder nicht. es 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);
}

Einfacheres Komponententesten von Hubs

SignalR 2.0 enthält eine Schnittstelle namens IHubCallerConnectionContext auf Hubs, die das Erstellen von simulierten clientseitigen Aufrufen erleichtert. Die folgenden Codeausschnitte veranschaulichen die Verwendung dieser Schnittstelle mit beliebten Test-Harnesss xUnit.net und moq.

Komponententests von SignalR mit 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);
}

Komponententest signalR mit 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. Dadurch kann SignalR umfangreichere Informationen an Ihre Fehlerhandler übergeben. Sie können die innere Ausnahme von 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. mit ASP.NET Identity können Sie auch das Persistenzmodell für Benutzerprofile in Ihrer Anwendung auswä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 unter Erstellen von ASP.NET Webprojekten in Visual Studio 2013.

Anspruchbasierte Authentifizierung

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

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 unter Erstellen von ASP.NET Webprojekten 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-Komponenten .

Microsoft OWIN-Komponenten

Open Web Interface for .NET (OWIN) definiert eine Abstraktion zwischen .NET-Webservern und Webanwendungen. OWIN entkoppelt die Webanwendung vom Server, sodass Webanwendungen hostagnostisch sind. Beispielsweise können Sie 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 werden) eingeführt wurden, umfassen neue Server- und Hostkomponenten, neue Hilfsbibliotheken und Middleware sowie neue Authentifizierungsmiddleware.

Weitere Informationen zu OWIN und Katana finden Sie unter Neuerungen 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 diesem Release wurden neue Komponenten hinzugefügt, um Selbsthostszenarien 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 an die OWIN-Pipeline weiterzuleiten.
  • Microsoft.Owin.Hosting Stellt eine Bibliothek für Entwickler bereit, die eine OWIN-Pipeline in einem benutzerdefinierten Prozess selbst hosten möchten, z. B. in einer Konsolenanwendung oder einem Windows-Dienst.
  • OwinHost. Stellt eine eigenständige ausführbare Datei bereit, die umschließt Microsoft.Owin.Hosting und ihnen ermöglicht, eine OWIN-Pipeline selbst zu hosten, ohne eine benutzerdefinierte Hostanwendung schreiben zu müssen.

Darüber hinaus ermöglicht das Microsoft.Owin.Host.SystemWeb Paket der Middleware jetzt die Bereitstellung von Hinweisen für 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 die Authentifizierungsmiddleware, die zu einem frühen Zeitpunkt in der ASP.NET-Pipeline ausgeführt werden sollte.

Hilfsbibliotheken und Middleware

Obwohl Sie OWIN-Komponenten nur mithilfe der Funktions- und Typdefinitionen aus der OWIN-Spezifikation schreiben können, bietet das neue Microsoft.Owin Paket eine benutzerfreundlichere Gruppe von Abstraktionen. Dieses Paket kombiniert mehrere frühere Pakete (z. B. Owin.Extensions, Owin.Types) in einem einzelnen, gut strukturierten Objektmodell, das dann problemlos von anderen OWIN-Komponenten verwendet werden kann. Tatsächlich verwenden die meisten Microsoft OWIN-Komponenten dieses Paket jetzt.

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.

Dieses Release enthält auch das Microsoft.Owin.Diagnostics-Paket, das Middleware zum Überprüfen einer ausgeführten OWIN-Anwendung sowie Fehlerseitenmiddleware enthält, um Fehler zu untersuchen.

Authentifizierungskomponenten

Die folgenden Authentifizierungskomponenten sind verfügbar.

  • Microsoft.Owin.Security.ActiveDirectory. Ermöglicht die Authentifizierung mit lokalen oder cloudbasierten Verzeichnisdiensten.
  • Microsoft.Owin.Security.Cookies Ermöglicht die Authentifizierung mithilfe von Cookies. Dieses Paket hatte zuvor den Namen Microsoft.Owin.Security.Forms.
  • Microsoft.Owin.Security.Facebook Ermöglicht die Authentifizierung mit dem OAuth-basierten Dienst von Facebook.
  • Microsoft.Owin.Security.Google Ermöglicht 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 Ermöglicht die Authentifizierung mit dem OAuth-basierten Dienst von Twitter.

Dieses Release 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 anderen Änderungen in Entity Framework 6 finden Sie unter Entity Framework-Versionsverlauf.

ASP.NET Razor 3

ASP.NET Razor 3 enthält die folgenden neuen Features:

  • Unterstützung für die Registerkartenbearbeitung. Bisher funktionierten der Befehl Dokument formatieren , der automatische Einzug und die automatische Formatierung in Visual Studio nicht ordnungsgemäß, wenn die Option Registerkarten beibehalten verwendet wurde . Durch diese Änderung wird die Visual Studio-Formatierung für Razor-Code für die Registerkartenformatierung korrigiert.
  • Unterstützung für URL-Rewrite-Regeln beim Generieren von Links.
  • Entfernen des sicherheitstransparenten Attributs.

    Hinweis

    Dies ist ein Breaking Change und macht Razor 3 mit MVC4 und früher inkompatibel, während Razor 2 nicht mit MVC5 oder mit MVC5 kompilierten Assemblys kompatibel ist.

=======

ASP.NET App anhalten

ASP.NET App Suspend ist ein bahnbrechendes Feature im .NET Framework 4.5.1, das die Benutzererfahrung und das Wirtschaftsmodell für das Hosten einer großen Anzahl von ASP.NET Websites auf einem einzelnen Computer radikal verändert. Weitere Informationen finden Sie unter ASP.NET App Suspend – reaktionsfähiges freigegebenes .NET-Webhosting.

Bekannte Probleme und Breaking Changes

In diesem Abschnitt werden bekannte Probleme und Breaking Changes im ASP.NET and Web Tools für Visual Studio 2013 beschrieben.

NuGet

  • Die Wiederherstellung eines neuen Pakets funktioniert bei Verwendung der SLN-Datei nicht auf Mono. Dies wird in einem bevorstehenden nuget.exe Download und NuGet.CommandLine-Paketupdate behoben.
  • Die Wiederherstellung eines neuen Pakets 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 $expandhinzugefügt haben.

    In unseren früheren Beispielen für ODataQueryOptions<T> wurde der Rückgabewert immer von in ApplyTo umgewandelt IQueryable<T>. Dies funktionierte früher, da die zuvor unterstützten Abfrageoptionen ($filter, $orderby, $skip, $top) die Form der Abfrage nicht ändern. Jetzt, da wir unterstützen $select , und $expand der Rückgabewert von ApplyTo wird nicht immer sein 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 von früher verwenden, funktioniert er weiterhin, wenn der Client und nicht sendet $select$expand. Wenn Sie jedoch unterstützen $select möchten, müssen $expand Sie diesen Code in diesen ändern.

    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 null während einer Batchanforderung.

    In einem Batchverarbeitungsszenario ist UrlHelper NULL, wenn über Request.Url oder RequestContext.Url darauf zugegriffen wird.

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

    Erstellen einer neuen instance von UrlHelper

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

ASP.NET MVC

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

    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 Antifälschungstoken bei der anspruchsbasierten Authentifizierung zu aktivieren, überprüfen Sie, ob der konfigurierte Anspruchsanbieter beide Ansprüche für die von ihr generierten ClaimsIdentity-Instanzen bereitstellt. Wenn der konfigurierte Anspruchsanbieter stattdessen einen anderen Anspruchstyp als eindeutigen Bezeichner verwendet, kann dieser konfiguriert werden, indem die statische Eigenschaft AntiForgeryConfig.UniqueClaimTypeIdentifier festgelegt wird.

    Problemumgehung:

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

    AntiForgeryConfig.UniqueClaimTypeIdentifier = ClaimTypes.Name;

    Dies wird für das nächste Release behoben.

  2. Erstellen Sie nach dem Upgrade einer MVC4-App auf MVC5 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 umgewandelt werden. Typ A stammt von "System.Web.WebPages.Razor, Version=2.0.0.0,0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" im Kontext "Default" am Speicherort "C:\windows\Microsoft.Net\assembly\GAC_MSIL\System.Web.WebPages.Razor\v4.0_2.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 "Default" 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 führen Sie die folgenden Schritte aus:

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

    2. Aktualisieren Sie 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".

      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 Upgraden von MVC 4-Projekten auf MVC 5 finden Sie unter Aktualisieren eines ASP.NET MVC 4 und Web-API-Projekts auf ASP.NET MVC 5 und Web-API 2.

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

    Dieses Problem tritt häufig bei Gerüstcode für ein Modell mit einer ganzzahligen Eigenschaft in den Ansichten Erstellen und Bearbeiten auf.

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

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

    Nach:

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

  4. ASP.NET MVC 5 unterstützt keine teilweise Vertrauenswürdigkeiten mehr. Projekte, die mit den MVC- oder WebAPI-Binärdateien verknüpfen, sollten das SecurityTransparent-Attribut und das AllowPartiallyTrustedCallers-Attribut entfernen. Wenn Sie diese Attribute entfernen, werden Compilerfehler wie die folgenden vermieden.

    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 bietet eine externe Anmeldung bei Facebook. 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 Gerüstbau wurde aus VS2013 entfernt und wird in einem zukünftigen Update für Visual Studio verfügbar sein. Sie können jedoch weiterhin das Gerüstbau innerhalb eines Web Forms-Projekts verwenden, indem Sie MVC-Abhängigkeiten hinzufügen und Gerüste für MVC erstellen. Ihr Projekt enthält eine Kombination aus Web Forms und MVC.

Um MVC zu Ihrem Web Forms-Projekt 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üstbau – 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. Für einige der Änderungen, die als Gerüstbau vorgenommen wurden, wird ein Rollback ausgeführt, aber für andere Änderungen, z. B. die installierten NuGet-Pakete, wird kein Rollback ausgeführt. Wenn für die Routingkonfigurationsänderungen ein Rollback ausgeführt wird, erhalten Benutzer beim Navigieren zu gerüsteten Elementen 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 Prozess fügt ihrem Projekt alle erforderlichen Änderungen hinzu.

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

    1. Fügen Sie ihrem 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