Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
In diesem Dokument wird die Veröffentlichung von ASP.NET MVC 4 Beta für Visual Studio 2010 beschrieben.
Hinweis
Dies ist nicht die aktuellste Version. Die versionshinweise zu ASP.NET MVC 4 RC finden Sie hier.
Neue Features in ASP.NET MVC 4 Beta
- ASP.NET-Web-API
- ASP.NET Einzelseitenanwendung
- Verbesserungen an Standardprojektvorlagen
- Vorlage für mobile Projekte
- Anzeigemodi
- jQuery Mobile, der Ansichtsschalter und Browserüberschreibung
- Rezepte für die Codegenerierung in Visual Studio
- Aufgabenunterstützung für asynchrone Controller
- Azure SDK
- Bekannte Probleme und wichtige Änderungen
Installationshinweise
ASP.NET MVC 4 Beta für Visual Studio 2010 kann über die ASP.NET MVC 4-Startseite mithilfe des Webplattform-Installers installiert werden.
Sie müssen alle zuvor installierten Vorschauversionen von ASP.NET MVC 4 deinstallieren, bevor Sie ASP.NET MVC 4 Beta installieren.
Dieses Release ist nicht mit der .NET Framework 4.5 Developer Preview kompatibel. Sie müssen die .NET 4.5 Developer Preview deinstallieren, bevor Sie die ASP.NET MVC 4 Beta installieren.
ASP.NET MVC 4 kann installiert und parallel mit ASP.NET MVC 3 ausgeführt werden.
Dokumentation
Die Dokumentation für ASP.NET MVC ist auf der MSDN-Website unter der folgenden URL verfügbar:
https://go.microsoft.com/fwlink/?LinkID=243043
Tutorials und andere Informationen zu ASP.NET MVC finden Sie auf der MVC 4-Seite der ASP.NET Website (https://www.asp.net/mvc/mvc4).
Support
Dies ist eine Vorschauversion und wird nicht offiziell unterstützt. Wenn Sie Fragen zur Arbeit mit diesem Release haben, stellen Sie diese im ASP.NET MVC-Forum (https://forums.asp.net/1146.aspx) bereit, wo Mitglieder der ASP.NET Community häufig informelle Unterstützung leisten können.
Softwareanforderungen
Die ASP.NET MVC 4-Komponenten für Visual Studio erfordern PowerShell 2.0 und entweder Visual Studio 2010 mit Service Pack 1 oder Visual Web Developer Express 2010 mit Service Pack 1.
Upgrade eines ASP.NET MVC 3-Projekts auf ASP.NET MVC 4
ASP.NET MVC 4 kann parallel zu ASP.NET MVC 3 auf demselben Computer installiert werden, sodass Sie flexibel entscheiden können, wann eine ASP.NET MVC 3-Anwendung auf ASP.NET MVC 4 aktualisiert werden soll.
Die einfachste Möglichkeit zum Upgrade besteht darin, ein neues ASP.NET MVC 4-Projekt zu erstellen und alle Ansichten, Controller, Code und Inhaltsdateien aus dem vorhandenen MVC 3-Projekt in das neue Projekt zu kopieren und dann die Assemblyverweise im neuen Projekt so zu aktualisieren, dass sie dem alten Projekt entsprechen. Wenn Sie Änderungen an der Web.config-Datei im MVC 3-Projekt vorgenommen haben, müssen Sie diese Änderungen auch in der Web.config-Datei im MVC 4-Projekt zusammenführen.
Gehen Sie wie folgt vor, um eine vorhandene ASP.NET MVC 3-Anwendung manuell auf Version 4 zu aktualisieren:
Ersetzen Sie in allen Web.config Dateien im Projekt (eine im Stammverzeichnis des Projekts, eine im Ordner Ansichten und eine im Ordner Ansichten für jeden Bereich in Ihrem Projekt) jede instance des folgenden Texts:
System.Web.Mvc, Version=3.0.0.0 System.Web.WebPages, Version=1.0.0.0 System.Web.Helpers, Version=1.0.0.0 System.Web.WebPages.Razor, Version=1.0.0.0mit dem folgenden entsprechenden Text:
System.Web.Mvc, Version=4.0.0.0 System.Web.WebPages, Version=2.0.0.0 System.Web.Helpers, Version=2.0.0.0, System.Web.WebPages.Razor, Version=2.0.0.0,Aktualisieren Sie in der Stammdatei Web.config das webPages:Version-Element auf "2.0.0.0", und fügen Sie einen neuen PreserveLoginUrl-Schlüssel mit dem Wert "true" hinzu:
<appSettings> <add key="webpages:Version" value="2.0.0.0" /> <add key="PreserveLoginUrl" value="true" /> </appSettings>Löschen Sie in Projektmappen-Explorer den Verweis auf System.Web.Mvc (der auf die DLL der Version 3 verweist). Fügen Sie dann einen Verweis auf System.Web.Mvc (v4.0.0.0) hinzu. Nehmen Sie insbesondere die folgenden Änderungen vor, um die Assemblyverweise zu aktualisieren. Es folgen die Details:
Löschen Sie in Projektmappen-Explorer die Verweise auf die folgenden Assemblys:
- System.Web.Mvc(v3.0.0.0)
- System.Web.WebPages(v1.0.0.0)
- System.Web.Razor(v1.0.0.0)
- System.Web.WebPages.Deployment(v1.0.0.0)
- System.Web.WebPages.Razor(v1.0.0.0)
Fügen Sie verweise auf die folgenden Assemblys hinzu:
- System.Web.Mvc(v4.0.0.0)
- System.Web.WebPages(v2.0.0.0)
- System.Web.Razor(v2.0.0.0)
- System.Web.WebPages.Deployment(v2.0.0.0)
- System.Web.WebPages.Razor(v2.0.0.0)
Klicken Sie in Projektmappen-Explorer mit der rechten Maustaste auf den Projektnamen, und wählen Sie dann Projekt entladen aus. Klicken Sie dann erneut mit der rechten Maustaste auf den Namen, und wählen Sie ProjectName.csproj bearbeiten aus.
Suchen Sie das ProjectTypeGuids-Element , und ersetzen Sie {E53F8FEA-EAE0-44A6-8774-FFD645390401} durch {E3E379DF-F4C6-4180-9B81-6769533ABE47}.
Speichern Sie die Änderungen, schließen Sie die Projektdatei (CSPROJ), die Sie bearbeitet haben, klicken Sie mit der rechten Maustaste auf das Projekt, und wählen Sie dann Projekt neu laden aus.
Wenn das Projekt auf Bibliotheken von Drittanbietern verweist, die mit früheren Versionen von ASP.NET MVC kompiliert wurden, öffnen Sie die Stammdatei Web.config, und fügen Sie im Konfigurationsabschnitt die folgenden drei bindingRedirect-Elemente hinzu:
<configuration> <!--... elements deleted for clarity ...--> <runtime> <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> <dependentAssembly> <assemblyIdentity name="System.Web.Helpers" publicKeyToken="31bf3856ad364e35" /> <bindingRedirect oldVersion="1.0.0.0" newVersion="2.0.0.0"/> </dependentAssembly> <dependentAssembly> <assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35" /> <bindingRedirect oldVersion="1.0.0.0-3.0.0.0" newVersion="4.0.0.0"/> </dependentAssembly> <dependentAssembly> <assemblyIdentity name="System.Web.WebPages" publicKeyToken="31bf3856ad364e35" /> <bindingRedirect oldVersion="1.0.0.0" newVersion="2.0.0.0"/> </dependentAssembly> </assemblyBinding> </runtime> </configuration>
Neue Features in ASP.NET MVC 4 Beta
In diesem Abschnitt werden Features beschrieben, die in der ASP.NET MVC 4 Beta-Version eingeführt wurden.
ASP.NET-Web-API
ASP.NET MVC 4 umfasst jetzt ASP.NET-Web-API, ein neues Framework zum Erstellen von HTTP-Diensten, das eine vielzahl von Clients erreichen kann, einschließlich Browsern und mobilen Geräten. ASP.NET-Web-API ist auch eine ideale Plattform für die Erstellung von RESTful-Diensten.
ASP.NET-Web-API umfasst Unterstützung für die folgenden Features:
- Modernes HTTP-Programmiermodell: Greifen Sie mithilfe eines neuen, stark typisierten HTTP-Objektmodells direkt auf HTTP-Anforderungen und -Antworten in Ihren Web-APIs zu und bearbeiten Sie sie. Dasselbe Programmiermodell und dieselbe HTTP-Pipeline sind auf dem Client über den neuen HttpClient-Typ symmetrisch verfügbar.
- Vollständige Unterstützung für Routen: Web-APIs unterstützen jetzt den vollständigen Satz von Routenfunktionen, die schon immer Teil des Webstapels waren, einschließlich Routenparametern und Einschränkungen. Darüber hinaus bietet die Zuordnung zu Aktionen volle Unterstützung für Konventionen, sodass Sie keine Attribute wie [HttpPost] mehr auf Ihre Klassen und Methoden anwenden müssen.
- Inhaltsverhandlung: Client und Server können zusammenarbeiten, um das richtige Format für daten zu bestimmen, die von einer API zurückgegeben werden. Wir bieten Standardunterstützung für XML-, JSON- und Formular-URL-codierte Formate, und Sie können diese Unterstützung erweitern, indem Sie Ihre eigenen Formatierungsprogramme hinzufügen oder sogar die Standardstrategie für inhaltsverhandlung ersetzen.
- Modellbindung und -validierung: Modellbinder bieten eine einfache Möglichkeit, Daten aus verschiedenen Teilen einer HTTP-Anforderung zu extrahieren und diese Nachrichtenteile in .NET-Objekte zu konvertieren, die von den Web-API-Aktionen verwendet werden können.
- Filter: Web-APIs unterstützen jetzt Filter, einschließlich bekannter Filter wie das [Authorize]-Attribut. Sie können eigene Filter für Aktionen, Autorisierung und Ausnahmebehandlung erstellen und einbinden.
- Abfragekomposition: Durch die einfache Rückgabe von IQueryable<T> unterstützt Ihre Web-API Abfragen über die OData-URL-Konventionen.
- Verbesserte Testbarkeit von HTTP-Details: Anstatt HTTP-Details in statischen Kontextobjekten festzulegen, können Web-API-Aktionen jetzt mit Instanzen von HttpRequestMessage und HttpResponseMessage funktionieren. Es gibt auch generische Versionen dieser Objekte, damit Sie zusätzlich zu den HTTP-Typen mit Ihren benutzerdefinierten Typen arbeiten können.
- Verbesserte Inversion der Steuerung (IoC) über DependencyResolver: Die Web-API verwendet jetzt das vom MVC-Abhängigkeitslöser implementierte Dienstlocatormuster, um Instanzen für viele verschiedene Einrichtungen abzurufen.
- Codebasierte Konfiguration: Die Web-API-Konfiguration erfolgt ausschließlich über Code, sodass Ihre Konfigurationsdateien sauber.
- Selbsthost: Web-APIs können zusätzlich zu IIS in Ihrem eigenen Prozess gehostet werden und gleichzeitig die volle Leistungsfähigkeit von Routen und anderen Features der Web-API nutzen.
Weitere Informationen zu ASP.NET-Web-API finden Sie unter https://www.asp.net/web-api.
ASP.NET Einzelseitenanwendung
ASP.NET MVC 4 enthält jetzt eine frühe Vorschau der Benutzeroberfläche zum Erstellen von Einzelseitenanwendungen mit wichtigen clientseitigen Interaktionen mithilfe von JavaScript und Web-APIs. Diese Unterstützung umfasst Folgendes:
- Eine Reihe von JavaScript-Bibliotheken für umfangreichere lokale Interaktionen mit zwischengespeicherten Daten
- Zusätzliche Web-API-Komponenten für Arbeitseinheit und DAL-Unterstützung
- Eine MVC-Projektvorlage mit Gerüstbau, um schnell loszulegen
Weitere Informationen zur Einzelseitenanwendungsunterstützung in ASP.NET MVC 4 finden Sie unter https://www.asp.net/single-page-application.
Verbesserungen an Standardprojektvorlagen
Die Vorlage, die zum Erstellen neuer ASP.NET MVC 4-Projekte verwendet wird, wurde aktualisiert, um eine modernere Website zu erstellen:
Zusätzlich zu kosmetischen Verbesserungen gibt es verbesserte Funktionen in der neuen Vorlage. Die Vorlage verwendet eine Technik namens adaptives Rendering, um sowohl in Desktopbrowsern als auch in mobilen Browsern ohne Anpassungen gut auszusehen.
Um das adaptive Rendering in Aktion zu sehen, können Sie einen mobilen Emulator verwenden oder einfach versuchen, die Größe des Desktopbrowserfensters auf eine kleinere Größe zu ändern. Wenn das Browserfenster klein genug wird, ändert sich das Layout der Seite.
Eine weitere Erweiterung der Standardprojektvorlage ist die Verwendung von JavaScript, um eine umfangreichere Benutzeroberfläche bereitzustellen. Die In der Vorlage verwendeten Verknüpfungen "Anmelden" und "Registrieren" sind Beispiele für die Verwendung des Dialogfelds für die jQuery-Benutzeroberfläche, um einen umfassenden Anmeldebildschirm anzuzeigen:
Vorlage für mobile Projekte
Wenn Sie ein neues Projekt starten und eine Website speziell für mobile und Tablet-Browser erstellen möchten, können Sie die neue Projektvorlage Mobile Anwendung verwenden. Dies basiert auf jQuery Mobile, einer Open-Source-Bibliothek zum Erstellen einer touchoptimierten Benutzeroberfläche:
Diese Vorlage enthält die gleiche Anwendungsstruktur wie die Internetanwendungsvorlage (und der Controllercode ist praktisch identisch), aber sie wird mithilfe von jQuery Mobile so formatiert, dass sie auf touchbasierten mobilen Geräten gut aussieht und sich gut verhält. Weitere Informationen zum Strukturieren und Formatieren der mobilen Benutzeroberfläche finden Sie auf der jQuery Mobile-Projektwebsite.
Wenn Sie bereits über eine Desktop-orientierte Website verfügen, der Sie für Mobilgeräte optimierte Ansichten hinzufügen möchten, oder wenn Sie eine einzelne Website erstellen möchten, die anders formatierte Ansichten als Desktop- und mobile Browser bereitstellt, können Sie das neue Feature Anzeigemodi verwenden. (Siehe nächster Abschnitt.)
Anzeigemodi
Das neue Feature Anzeigemodi ermöglicht es einer Anwendung, Ansichten abhängig vom Browser auszuwählen, der die Anforderung stellt. Wenn beispielsweise ein Desktopbrowser die Startseite anfordert, verwendet die Anwendung möglicherweise die Vorlage Views\Home\Index.cshtml. Wenn ein mobiler Browser die Startseite anfordert, gibt die Anwendung möglicherweise die Vorlage Views\Home\Index.mobile.cshtml zurück.
Layouts und Partielle können auch für bestimmte Browsertypen überschrieben werden. Zum Beispiel:
- Wenn Ihr Ordner Views\Shared sowohl die Vorlagen _Layout.cshtml als auch _Layout.mobile.cshtml enthält, verwendet die Anwendung standardmäßig _Layout.mobile.cshtml bei Anforderungen von mobilen Browsern und _Layout.cshtml während anderer Anforderungen.
- Wenn ein Ordner sowohl _MyPartial.cshtml als auch _MyPartial.mobile.cshtml enthält, wird die Anweisung @Html.Partial("_MyPartial") bei Anforderungen von mobilen Browsern _MyPartial.mobile.cshtml und während anderer Anforderungen _MyPartial.cshtml gerendert.
Wenn Sie spezifischere Ansichten, Layouts oder Teilansichten für andere Geräte erstellen möchten, können Sie eine neue DefaultDisplayMode-instance registrieren, um anzugeben, nach welchem Namen gesucht werden soll, wenn eine Anforderung bestimmte Bedingungen erfüllt. Beispielsweise können Sie der Application_Start-Methode in der Datei Global.asax den folgenden Code hinzufügen, um die Zeichenfolge "iPhone" als Anzeigemodus zu registrieren, der gilt, wenn der Apple iPhone-Browser eine Anforderung sendet:
DisplayModeProvider.Instance.Modes.Insert(0, new
DefaultDisplayMode("iPhone")
{
ContextCondition = (context => context.GetOverriddenUserAgent().IndexOf
("iPhone", StringComparison.OrdinalIgnoreCase) >= 0)
});
Wenn dieser Code ausgeführt wird, verwendet Ihre Anwendung, wenn ein Apple iPhone-Browser eine Anforderung sendet, das Layout Views\Shared\_Layout.iPhone.cshtml (sofern vorhanden).
jQuery Mobile, die Ansichtsumschaltung und Browserüberschreibung
jQuery Mobile ist eine Open Source-Bibliothek zum Erstellen einer touchoptimierten Webbenutzeroberfläche. Wenn Sie jQuery Mobile mit einer ASP.NET MVC 4-Anwendung verwenden möchten, können Sie ein NuGet-Paket herunterladen und installieren, das Ihnen den Einstieg erleichtert. Geben Sie den folgenden Befehl ein, um sie über die Visual Studio-Paket-Manager-Konsole zu installieren:
Install-Package jQuery.Mobile.MVC
Dadurch werden jQuery Mobile und einige Hilfsdateien installiert, einschließlich der folgenden:
- Views/Shared/_Layout.Mobile.cshtml, ein jQuery Mobile-basiertes Layout.
- Eine Ansichtswechselkomponente, die aus der Teilansicht Views/Shared/_ViewSwitcher.cshtml und dem ViewSwitcherController.cs-Controller besteht.
Nachdem Sie das Paket installiert haben, führen Sie Ihre Anwendung mit einem mobilen Browser (oder einem entsprechenden Browser wie dem Add-On Firefox User Agent Switcher ) aus. Sie werden sehen, dass Ihre Seiten ganz anders aussehen, da jQuery Mobile Layout und Formatierung behandelt. Um dies zu nutzen, können Sie die folgenden Aktionen ausführen:
- Erstellen Sie für mobilgerätespezifische Ansichtsüberschreibungen, wie weiter oben unter Anzeigemodi beschrieben (erstellen Sie z. B. Views\Home\Index.mobile.cshtml, um Views\Home\Index.cshtml für mobile Browser außer Kraft zu setzen).
- Lesen Sie die jQuery Mobile-Dokumentation , um mehr darüber zu erfahren, wie Sie touchoptimierte UI-Elemente in mobilen Ansichten hinzufügen.
Eine Konvention für für mobilgeräteoptimierte Webseiten besteht darin, einen Link hinzuzufügen, dessen Text etwa Desktopansicht oder Vollständiger Websitemodus ist, mit dem Benutzer zu einer Desktopversion der Seite wechseln können. Das Paket jQuery.Mobile.MVC enthält eine Beispielkomponente für den Ansichtswechsel für diesen Zweck. Sie wird in der Standardansicht Views\Shared\_Layout.Mobile.cshtml verwendet und sieht beim Rendern der Seite wie folgt aus:
Wenn Besucher auf den Link klicken, werden sie zur Desktopversion derselben Seite gewechselt.
Da Ihr Desktoplayout standardmäßig keinen Ansichtswechsel enthält, haben Besucher keine Möglichkeit, in den mobilen Modus zu wechseln. Um dies zu aktivieren, fügen Sie den folgenden Verweis auf _ViewSwitcher Ihrem Desktoplayout direkt innerhalb des <Body-Elements> hinzu:
<body>
@Html.Partial("_ViewSwitcher")
...
Der Ansichtswechsel verwendet ein neues Feature namens Browserüberschreibung. Mit diesem Feature kann Ihre Anwendung Anforderungen so behandeln, als ob sie von einem anderen Browser (Benutzer-Agent) als dem, aus dem sie tatsächlich stammt, stammen. In der folgenden Tabelle sind die Methoden aufgeführt, die browserüberschreibend bereitgestellt werden.
HttpContext.SetOverriddenBrowser(userAgentString) |
Setzt den tatsächlichen Benutzer-Agent-Wert der Anforderung mithilfe des angegebenen Benutzer-Agents außer Kraft. |
|---|---|
HttpContext.GetOverriddenUserAgent() |
Gibt den Außerkraftsetzungswert des Benutzer-Agents der Anforderung oder die tatsächliche Benutzer-Agent-Zeichenfolge zurück, wenn keine Außerkraftsetzung angegeben wurde. |
HttpContext.GetOverriddenBrowser() |
Gibt einen HttpBrowserCapabilitiesBase-instance zurück, der dem Benutzer-Agent entspricht, der derzeit für die Anforderung festgelegt ist (tatsächlich oder überschrieben). Sie können diesen Wert verwenden, um Eigenschaften wie IsMobileDevice abzurufen. |
HttpContext.ClearOverriddenBrowser() |
Entfernt alle außer Kraft gesetzten Benutzer-Agents für die aktuelle Anforderung. |
Browserüberschreibung ist ein Kernfeature von ASP.NET MVC 4 und auch dann verfügbar, wenn Sie das Paket jQuery.Mobile.MVC nicht installieren. Es wirkt sich jedoch nur auf die Ansichts-, Layout- und Teilansichtsauswahl aus. Dies wirkt sich nicht auf andere ASP.NET Funktion aus, die vom Request.Browser-Objekt abhängt.
Standardmäßig wird die Benutzer-Agent-Außerkraftsetzung mithilfe eines Cookies gespeichert. Wenn Sie die Außerkraftsetzung an einer anderen Stelle (z. B. in einer Datenbank) speichern möchten, können Sie den Standardanbieter (BrowserOverrideStores.Current) ersetzen. Die Dokumentation für diesen Anbieter wird für eine spätere Version von ASP.NET MVC verfügbar sein.
Rezepte für die Codegenerierung in Visual Studio
Mit dem neuen Feature Rezepte kann Visual Studio projektmappenspezifischen Code basierend auf Paketen generieren, die Sie mithilfe von NuGet installieren können. Das Recipes-Framework erleichtert Entwicklern das Schreiben von Codegenerierungs-Plug-Ins, die Sie auch verwenden können, um die integrierten Codegeneratoren für "Bereich hinzufügen", "Controller hinzufügen" und "Ansicht hinzufügen" zu ersetzen. Da Rezepte als NuGet-Pakete bereitgestellt werden, können sie problemlos in die Quellcodeverwaltung eingecheckt und automatisch für alle Entwickler des Projekts freigegeben werden. Sie sind auch pro Lösung verfügbar.
Aufgabenunterstützung für asynchrone Controller
Sie können jetzt asynchrone Aktionsmethoden als einzelne Methoden schreiben, die ein Objekt vom Typ Task oder Task<ActionResult> zurückgeben.
Wenn Sie beispielsweise Visual C# 5 (oder Async CTP) verwenden, können Sie eine asynchrone Aktionsmethode erstellen, die wie folgt aussieht:
public async Task<ActionResult> Index(string city) {
var newsService = new NewsService();
var sportsService = new SportsService();
return View("Common",
new PortalViewModel {
NewsHeadlines = await newsService.GetHeadlinesAsync(),
SportsScores = await sportsService.GetScoresAsync()
});
}
In der vorherigen Aktionsmethode werden die Aufrufe von newsService.GetHeadlinesAsync und sportsService.GetScoresAsync asynchron aufgerufen und blockieren keinen Thread aus dem Threadpool.
Asynchrone Aktionsmethoden, die Taskinstanzen zurückgeben, können auch Timeouts unterstützen. Fügen Sie der Aktionsmethodensignatur einen Parameter vom Typ CancellationToken hinzu, damit Ihre Aktionsmethode abgebrochen werden kann. Das folgende Beispiel zeigt eine asynchrone Aktionsmethode, die ein Timeout von 2500 Millisekunden aufweist und dem Client eine TimedOut-Ansicht anzeigt, wenn ein Timeout auftritt.
[AsyncTimeout(2500)]
[HandleError(ExceptionType = typeof(TaskCanceledException), View = "TimedOut")]
public async Task<ActionResult> Index(string city,
CancellationToken cancellationToken) {
var newsService = new NewsService();
var sportsService = new SportsService();
return View("Common",
new PortalViewModel {
NewsHeadlines = await newsService.GetHeadlinesAsync(cancellationToken),
SportsScores = await sportsService.GetScoresAsync(cancellationToken)
});
}
Azure SDK
ASP.NET MVC 4 Beta unterstützt die Version 1.5 des Windows Azure SDK vom September 2011.
Bekannte Probleme und Breaking Changes
Nach der Installation ASP.NET MVC 4 Beta kann der CSHTML/VBHTML-Editor in Visual Studio 2010 Service Pack 1 CSHTML/VBHTML-Editor nach der Eingabe von Codeausschnitt oder JavaScript in cshtml- oder vbhtml-Dateien für längere Zeit angehalten werden. Dies tritt nur in ASP.NET MVC 4-Anwendungen auf, die gerade erstellt und noch nicht kompiliert wurden.
Die Problemumgehung besteht darin, das Projekt zu kompilieren, um die Assemblys im Ordner bin abzurufen. Beachten Sie: Wenn Sie das Projekt sauber, das die Assemblys aus dem Ordner bin entfernt, tritt das Editorproblem wieder auf.
Dies wird in der nächsten Version korrigiert.
C#-Projektvorlagen für Visual Studio 11 Beta enthalten eine falsche Verbindungszeichenfolge in "Global.asax.cs". Die in der Application_Start-Methode angegebene Standardverbindung für Projekte, die in Visual Studio 11 Beta erstellt wurden, enthält eine LocalDB-Verbindungszeichenfolge, die ein Nicht-Escapezeichen mit umgekehrtem Schrägstrich () enthält. Dies führt zu einem Verbindungsfehler, wenn versucht wird, auf einen Entity Framework DbContext zuzugreifen, der eine SqlException generiert.
Um dieses Problem zu beheben, escapen Sie den umgekehrten Schrägstrich in der App_Start-Methode von Global.asax.cs, sodass es wie folgt lautet:
Database.DefaultConnectionFactory = new SqlConnectionFactory( "Data Source=(localdb)\\v11.0; Integrated Security=True; MultipleActiveResultSets=True");ASP.NET MVC 4-Anwendungen, die .NET 4.5 als Ziel verwenden, wird bei der Ausführung unter .NET 4.0 eine FileLoadException ausgelöst, wenn versucht wird, auf die System.Net.Http.dll-Assembly zuzugreifen. ASP.NET MVC 4-Anwendungen, die unter .NET 4.5 erstellt wurden, enthalten eine Bindungsumleitung, die zu einer FileLoadException führt, die besagt, dass die Datei oder Assembly 'System.Net.Http' oder eine ihrer Abhängigkeiten nicht geladen werden konnte', wenn die Anwendung auf einem System ausgeführt wird, auf dem .NET 4.0 installiert ist. Um dieses Problem zu beheben, entfernen Sie die folgende Bindungsumleitung aus web.config:
<dependentAssembly> <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" /> <bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="4.0.0.0" /> </dependentAssembly>Das Assemblybindungselement im geänderten web.config sollte wie folgt aussehen:
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> <dependentAssembly> <assemblyIdentity name="System.Web.Helpers" publicKeyToken="31bf3856ad364e35" /> <bindingRedirect oldVersion="1.0.0.0-2.0.0.0" newVersion="2.0.0.0" /> </dependentAssembly> <dependentAssembly> <assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35" /> <bindingRedirect oldVersion="1.0.0.0-4.0.0.0" newVersion="4.0.0.0" /> </dependentAssembly> <dependentAssembly> <assemblyIdentity name="System.Web.WebPages" publicKeyToken="31bf3856ad364e35" /> <bindingRedirect oldVersion="1.0.0.0-2.0.0.0" newVersion="2.0.0.0" /> </dependentAssembly> </assemblyBinding>Die Elementvorlage "Controller hinzufügen" in Visual Basic-Projekten generiert einen falschen Namespace, wennsie aus einem Bereich aufgerufen wird. Wenn Sie einem Bereich in einem ASP.NET MVC-Projekt, das Visual Basic verwendet, einen Controller hinzufügen, fügt die Elementvorlage den falschen Namespace in den Controller ein. Das Ergebnis ist der Fehler "Datei nicht gefunden", wenn Sie zu einer Aktion im Controller navigieren.
Im generierten Namespace wird alles nach dem Stammnamespace weggelassen. Der generierte Namespace ist beispielsweise RootNamespace , sollte jedoch RootNamespace.Areas.AreaName.Controllers sein.
Breaking Changes in der Razor View Engine. Im Rahmen einer Neuschreibung des Razor-Parsers wurden die folgenden Typen aus System.Web.Mvc.Razor entfernt:
- ModelSpan
- MvcVBRazorCodeGenerator
- MvcCSharpRazorCodeGenerator
- MvcVBRazorCodeParser
Die folgenden Methoden wurden ebenfalls entfernt:
- MvcCSharpRazorCodeParser.ParseInheritsStatement(System.Web.Razor.Parser.CodeBlockInfo)
- MvcWebPageRazorHost.DecorateCodeGenerator(System.Web.Razor.Generator.RazorCodeGenerator)
- MvcVBRazorCodeParser.ParseInheritsStatement(System.Web.Razor.Parser.CodeBlockInfo)
Wenn WebMatrix.WebData.dll im Verzeichnis /bin einer ASP.NET MVC 4-Apps enthalten ist, übernimmt er die URL für die Formularauthentifizierung. Durch das Hinzufügen der WebMatrix.WebData.dll Assembly zu Ihrer Anwendung (z. B. durch Auswählen von "ASP.NET Web Pages mit Razor-Syntax" bei Verwendung des Dialogfelds "Deployable Dependencies hinzufügen") wird die Umleitung der Authentifizierungsanmeldung auf /account/logon überschrieben, anstatt wie standardmäßig ASP.NET MVC-Kontocontrollers erwartet/account/login. Um dieses Verhalten zu verhindern und die bereits im Authentifizierungsabschnitt von web.config angegebene URL zu verwenden, können Sie eine AppSetting namens PreserveLoginUrl hinzufügen und auf true festlegen:
<appSettings> <add key="PreserveLoginUrl" value="true"/> </appSettings>Der NuGet-Paket-Manager kann nicht installiert werden, wenn versucht wird, ASP.NET MVC 4 für parallele Installationen von Visual Studio 2010 und Visual Web Developer 2010 zu installieren. Um Visual Studio 2010 und Visual Web Developer 2010 parallel mit ASP.NET MVC 4 auszuführen, müssen Sie ASP.NET MVC 4 installieren, nachdem beide Versionen von Visual Studio bereits installiert wurden.
Die Deinstallation ASP.NET MVC 4 schlägt fehl, wenn die Voraussetzungen bereits deinstalliert wurden. Um ASP.NET MVC 4 sauber zu deinstallieren, müssen Sie ASP.NET MVC 4 vor der Deinstallation von Visual Studio deinstallieren.
Das Ausführen eines Standardweb-API-Projekts zeigt Anweisungen an, die den Benutzer fälschlicherweise anweisen, Routen mithilfe der RegisterApis-Methode hinzuzufügen, die nicht vorhanden ist. Routen sollten in der RegisterRoutes-Methode mithilfe der ASP.NET Routingtabelle hinzugefügt werden.
Die Installation ASP.NET MVC 4 Beta unterbricht ASP.NET MVC 3 RTM-Anwendungen. ASP.NET MVC 3-Anwendungen, die mit dem RTM-Release erstellt wurden (nicht mit der ASP.NET MVC 3 Tools Update Release), sind die folgenden Änderungen erforderlich, um parallel mit ASP.NET MVC 4 Beta zu arbeiten. Das Erstellen des Projekts ohne diese Updates führt zu Kompilierungsfehlern.
Erforderliche Updates
Fügen Sie in der Stammdatei Web.config einen neuen <appSettings-Eintrag> mit dem Schlüssel webPages:Version und dem Wert 1.0.0.0 hinzu.
<appSettings> <add key="webpages:Version" value="1.0.0.0"/> <add key="ClientValidationEnabled" value="true"/> <add key="UnobtrusiveJavaScriptEnabled" value="true"/> </appSettings>Klicken Sie in Projektmappen-Explorer mit der rechten Maustaste auf den Projektnamen, und wählen Sie dann Projekt entladen aus. Klicken Sie dann erneut mit der rechten Maustaste auf den Namen, und wählen Sie ProjectName.csproj bearbeiten aus.
Suchen Sie die folgenden Assemblyverweise:
<Reference Include="System.Web.WebPages"/> <Reference Include="System.Web.Helpers" />Ersetzen Sie sie durch Folgendes:
<Reference Include="System.Web.WebPages, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL "/> <Reference Include="System.Web.Helpers, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL" />Speichern Sie die Änderungen, schließen Sie die Projektdatei (CSPROJ), die Sie bearbeitet haben, und klicken Sie dann mit der rechten Maustaste auf das Projekt, und wählen Sie Neu laden aus.