Ansichten in ASP.NET Core MVC

Von Steve Smith und Dave Brock

In diesem Artikel werden die Ansichten erläutert, die in ASP.NET Core MVC-Anwendungen verwendet werden. Informationen zu Razor Pages finden Sie unter Einführung in Razor Pages in ASP.NET Core.

Im Muster Model-View-Controller (MVC) verarbeitet die Ansicht die Darstellung der App-Daten und der Benutzerinteraktion. Bei einer Ansicht handelt es sich um eine HTML-Vorlage mit eingebettetem Razor-Markup. Bei Razor-Markup handelt es sich um Code, der mit HTML-Markup interagiert, um eine Webseite zu generieren, die an den Client gesendet wird.

In ASP.NET Core MVC sind Ansichten .cshtml-Dateien, die die Programmiersprache C# in Razor-Markup verwenden. In der Regel werden Ansichtsdateien in Ordnern gruppiert, die für jeden Controller der App benannt werden. Die Ordner werden im Ordner Views im Stammverzeichnis der App gespeichert:

Der Home-Controller wird durch einen Home-Ordner innerhalb des Ordners Views dargestellt. Der Ordner Home enthält die Ansichten für die Webseiten About, Contact und Index (Homepage). Wenn ein*e Benutzer*in eine dieser drei Webseiten aufruft, legen Controlleraktionen im Home-Controller fest, welche der drei Ansichten verwendet werden, um Webseiten zu erstellen und diese an den oder die Benutzer*in zurückzugeben.

Verwenden Sie Layouts, damit die Abschnitte der Webseiten konsistent angezeigt werden und die Wiederholung von Code vermieden wird. Layouts bestehen in der Regel aus der Kopfzeile, der Navigation, Menüelementen und der Fußzeile. Die Kopf- und die Fußzeile enthalten in der Regel Markupbausteine für viele Metadatenelemente sowie Links zu Skripts und Stilelemente. Mithilfe von Layouts können Sie die Markupbausteine in Ihren Ansichten vermeiden.

Über Teilansichten wird weniger Code dupliziert, indem wiederverwendbare Bestandteile der Ansichten verwaltet werden. Sie sind z.B. nützlich für Autorenbiografien auf einem Blog, die in verschiedenen Ansichten angezeigt werden. Bei einer Autorenbiografie handelt es sich um gewöhnlichen Inhalt von Ansichten. Sie erfordern keinen Code, der ausgeführt werden muss, um den Inhalt für die Webseite herzustellen. Die Ansicht kann auf die Inhalte der Autorenbiografie über eine Modellbindung zugreifen. Daher sollten idealerweise Teilansichten für diese Art von Inhalt verwendet werden.

Über Ansichtskomponenten können Sie genauso wie über Teilansichten Wiederholungen von Code reduzieren. Sie sind besonders geeignet für Inhalt von Ansichten, für den Code auf dem Server ausgeführt werden muss, um die Webseite zu rendern. Ansichtskomponenten sind nützlich, wenn der gerenderte Inhalt Datenbankinformationen erfordert, z.B. bei einem Warenkorb auf einer Website. Ansichtskomponenten sind nicht auf Modellbindungen beschränkt, um Webseitenausgaben herzustellen.

Vorteile der Verwendung von Ansichten

Über Ansichten kann in einer MVC-App eine Trennung von Belangen erfolgen, indem das Markup der Benutzeroberfläche von anderen Bestandteilen der App getrennt wird. Das SoC-Design macht Ihre App modularer. Dies hat folgende Vorteile:

• Die App kann einfacher verwaltet werden, da sie besser organisiert ist. Ansichten werden in der Regel nach App-Features gruppiert. Dadurch können Sie zugehörige Ansichten leichter finden, wenn Sie an einem Feature arbeiten.
• Die Bestandteile der App sind lose miteinander verknüpft. Sie können die Ansichten der App getrennt von der Geschäftslogik und den Datenzugriffskomponenten erstellen und aktualisieren. Sie können die Ansichten der App verändern, müssen dafür aber nicht unbedingt andere Bestandteile der App aktualisieren.
• Sie können die Bestandteile der Benutzeroberfläche der App leichter testen, da es sich bei den Ansichten um voneinander getrennte Einheiten handelt.
• Durch die verbesserte Organisation sinkt die Wahrscheinlichkeit, dass Sie versehentlich Code für die Benutzeroberfläche wiederholt schreiben.

Erstellen einer Ansicht

Ansichten, die nur für bestimmte Controller gelten, werden im Ordner Views/[ControllerName] erstellt. Ansichten, die von mehreren Controllern verwendet werden können, werden im Ordner Views/Shared gespeichert. Wenn Sie eine Ansicht erstellen möchten, fügen Sie eine neue Datei hinzu, und geben Sie ihr denselben Namen wie der zugehörigen Controlleraktion mit der Erweiterung .cshtml. Wenn Sie eine Ansicht erstellen möchten, die mit der Aktion About im Home-Controller übereinstimmt, erstellen Sie eine About.cshtml-Datei im Ordner Views/Home:

@{
    ViewData["Title"] = "About";
}
<h2>@ViewData["Title"].</h2>
<h3>@ViewData["Message"]</h3>

<p>Use this area to provide additional information.</p>

Das Razor-Markup beginnt mit dem Symbol @. Führen Sie C#-Anweisungen aus, indem Sie C#-Code in den Razor-Codeblöcken speichern, die von geschweiften Klammern ({ ... }) umgeben sind. Weitere Informationen finden Sie im obenstehenden Beispiel für die Zuweisung von „Hilfe“ zu ViewData["Title"]. Sie können Werte innerhalb von HTML-Code angeben, indem Sie auf den Wert mit dem Symbol @ verweisen. Weitere Informationen finden Sie in den Inhalten der obenstehenden Elemente <h2> und <h3>.

Der obenstehende Inhalt der Ansicht ist nur ein Teil der gesamten Webseite, die für den Benutzer gerendert wird. Der Rest des Seitenlayouts und andere häufig auftretende Aspekte werden in anderen Ansichtsdateien angegeben. Weitere Informationen dazu finden Sie im Artikel Layout.

Angeben von Ansichten durch Controller

Ansichten werden in der Regel von Aktionen als ViewResult zurückgegeben. Dabei handelt es sich um eine Art ActionResult. Über Ihre Aktionsmethode kann eine ViewResult-Klasse direkt erstellt und zurückgegeben werden. Diese Methode wird allerdings selten genutzt. Da die meisten Controller von Controller erben, können Sie einfach die View-Hilfsprogrammmethode verwenden, um ViewResult zurückzugeben:

HomeController.cs:

public IActionResult About()
{
    ViewData["Message"] = "Your application description page.";

    return View();
}

Wenn diese Aktion zurückgegeben wird, wird die im letzten Abschnitt angezeigte About.cshtml-Ansicht als folgende Webseite gerendert:

Für die View-Hilfsprogrammmethode gibt es einige Überladungen. Sie können bei Bedarf folgende Elemente angeben:

• Eine explizite Ansicht, die zurückgegeben werden soll:

  return View("Orders");
  

• Ein Modell, das an die Ansicht übergeben werden soll:

  return View(Orders);
  

• Sowohl eine Ansicht als auch ein Modell:

  return View("Orders", Orders);
  

Ansichtsermittlung

Wenn eine Aktion eine Ansicht zurückgibt, wird ein Prozess namens Ansichtsermittlung ausgelöst. Über diesen Prozess wird auf Grundlage des Ansichtsnamens festgelegt, welche Ansichtsdatei verwendet wird.

Standardmäßig gibt die View-Methode (return View();) eine Ansicht zurück, die denselben Namen wie die Aktionsmethode besitzt, über die diese aufgerufen wird. Der About ActionResult-Methodenname des Controllers wird verwendet, um nach einer Ansichtsdatei mit dem Namen About.cshtml zu suchen. Zuerst sucht die Runtime im Ordner Views/[ControllerName] nach der Ansicht. Wenn keine passende Ansicht gefunden wird, wird im Ordner Shared nach der Ansicht gesucht.

Es macht keinen Unterschied, ob Sie implizit ViewResult mit return View(); zurückgeben, oder den Ansichtsnamen mit return View("<ViewName>"); explizit an die View-Methode übergeben. In beiden Fällen sucht die Ansichtsermittlung nach einer passenden Ansichtsdatei in diesem Ordner:

1. Views/\[ControllerName]/\[ViewName].cshtml
2. Views/Shared/\[ViewName].cshtml

Anstelle eines Ansichtsnamens kann auch ein Pfad zu einer Ansichtsdatei verwendet werden. Wenn Sie einen absoluten Pfad im Stammverzeichnis der App verwenden (der mit „/“ oder „~/“ beginnt), muss die Erweiterung .cshtml angegeben sein:

return View("Views/Home/About.cshtml");

Sie können auch einen relativen Pfad verwenden, um Ansichten in verschiedenen Verzeichnissen ohne die Erweiterung .cshtml anzugeben. In der HomeController-Klasse können Sie die Ansicht Index in Ihrer Manage-Ansicht mit einem relativen Pfad angeben:

return View("../Manage/Index");

Genauso können Sie auch das aktuelle controllerspezifische Verzeichnis mit dem Präfix „./“ angeben:

return View("./About");

Teilansichten und Ansichtskomponenten verwenden ähnliche (aber nicht identische) Ermittlungsmechanismen.

Sie können die Standardkonvention zum Suchen von Ansichten in der App anpassen, indem Sie eine benutzerdefinierte IViewLocationExpander-Schnittstelle verwenden.

Die Ansichtsermittlung ist davon abhängig, ob Ansichtsdateien über Dateinamen gefunden werden. Wenn das zugrunde liegende Dateisystem die Groß-/Kleinschreibung beachtet, wird wahrscheinlich auch bei den Ansichtsnamen zwischen Groß- und Kleinschreibung unterschieden. Damit die Kompatibilität für alle Betriebssysteme eingehalten werden kann, müssen Sie Groß-/Kleinbuchstaben zwischen dem Controller und den Aktionsnamen sowie den zugeordneten Ansichtsordnern und Dateinamen aufeinander abstimmten. Wenn ein Fehler ausgelöst wird und eine Ansichtsdatei nicht gefunden werden kann, während Sie mit einem Dateisystem arbeiten, das zwischen Groß- und Kleinbuchstaben unterscheidet, bestätigen Sie, dass die Groß-/Kleinschreibung der gesuchten Ansichtsdatei mit dem tatsächlichen Dateinamen der Ansicht übereinstimmt.

Halten Sie sich an die bewährten Methoden zum Organisieren der Dateistruktur Ihrer Ansichten, um die Beziehungen zwischen Controllern, Aktionen und Ansichten auf die Verwaltbarkeit und Klarheit auszurichten.

Übergeben von Daten an Ansichten

Übergeben Sie Daten über verschiedene Ansätze an Ansichten:

• Stark typisierte Daten: viewmodel
• Schwach typisierte Daten
  • ViewData (ViewDataAttribute)
  • ViewBag

Stark typisierte Daten (viewmodel)

Wenn Sie Stabilität wünschen, sollten Sie einen Modell-Typen in der Ansicht angeben. Das Modell wird häufig als Ansichtsmodell bezeichnet. Übergeben Sie eine Instanz des Ansichtsmodelltyps an die Ansicht aus der Aktion.

Wenn Sie ein Ansichtsmodell verwenden, um eine Ansicht zu übergeben, kann die Ansicht die Vorteile der starken Typüberprüfung nutzen. Man spricht von starker Typisierung (oder stark typisiert als Adjektiv), wenn es für jede Variable und jede Konstante einen explizit definierten Typ gibt, z.B. string, int oder DateTime. Die Gültigkeit der in der Ansicht verwendeten Typen wird zur Kompilierzeit überprüft.

Visual Studio und Visual Studio Code erstellen Listen von stark typisierten Klassenmembern mithilfe des Features IntelliSense. Wenn Sie die Eigenschaften eines Ansichtsmodell anzeigen wollen, geben Sie den Namen der Variablen für dieses an, und setzen Sie einen Punkt (.). Dadurch können Sie Code schneller schreiben, und Sie machen weniger Fehler.

Geben Sie mithilfe der @model-Anweisung ein Modell an. Verwenden Sie das Modell mit @Model:

@model WebApplication1.ViewModels.Address

<h2>Contact</h2>
<address>
    @Model.Street<br>
    @Model.City, @Model.State @Model.PostalCode<br>
    <abbr title="Phone">P:</abbr> 425.555.0100
</address>

Der Controller übergibt das Modell als Parameter, um es für die Ansicht bereitzustellen:

public IActionResult Contact()
{
    ViewData["Message"] = "Your contact page.";

    var viewModel = new Address()
    {
        Name = "Microsoft",
        Street = "One Microsoft Way",
        City = "Redmond",
        State = "WA",
        PostalCode = "98052-6399"
    };

    return View(viewModel);
}

Es gibt keine Einschränkungen der Modelltypen, die in einer Ansicht enthalten sein sollten. Es wird empfohlen, Plain Old CLR Object-Ansichtsmodelle (POCO) mit wenigen oder gar keinen definierten Methoden zu verwenden. In der Regel werden Ansichtsmodellklassen weder im Ordner Models noch in einem separaten ViewModels-Ordner im Stammverzeichnis der App gespeichert. Bei dem im zuvor genannten Beispiel verwendeten Address-Ansichtsmodell handelt es sich um ein POCO-Ansichtsmodell, das in einer Datei mit dem Namen Address.cs gespeichert ist:

namespace WebApplication1.ViewModels
{
    public class Address
    {
        public string Name { get; set; }
        public string Street { get; set; }
        public string City { get; set; }
        public string State { get; set; }
        public string PostalCode { get; set; }
    }
}

Es ist möglich, für die Ansichtsmodelltypen und Unternehmensmodelltypen dieselben Klassen zu verwenden. Wenn Sie allerdings unterschiedliche Modelle verwenden, können Ihre Ansichten unabhängig von der Geschäftslogik und den Bestandteilen zum Datenzugriff Ihrer App variieren. Wenn Sie Modelle und Ansichtsmodelle trennen, wird mehr Sicherheit geboten, wenn Modelle die Modellbindung und die Validierung von Daten verwenden, die vom Benutzer an die App gesendet werden.

Schwach typisierte Daten (ViewData, [ViewData]-Attribut und ViewBag)

ViewBag ist standardmäßig nicht für die Verwendung in Razor Pages-PageModel -Klassen verfügbar.

Ansichten haben nicht nur Zugriff auf stark typisierte Datensammlungen, sondern auch auf schwach typisierte (auch als lose typisiert bezeichnet). Im Gegensatz zu starken Typen werden bei schwachen Typen (oder losen Typen) nicht explizit die Datentypen deklariert, die Sie verwenden. Sie können die Sammlung schwach typisierter Daten verwenden, um kleinere Datenmengen an Controller und Ansichten zu übergeben oder sie ihnen zu entnehmen.

Auf diese Sammlung kann entweder über die Eigenschaft ViewData oder über die Eigenschaft ViewBag auf Controller und Ansichten verwiesen werden. Die ViewData-Eigenschaft ist ein Wörterbuch, das aus schwach typisierten Objekten besteht. Bei der ViewBag-Eigenschaft handelt es sich um einen Wrapper um ViewData, der dynamische Eigenschaften für die zugrunde liegende ViewData-Sammlung bereitstellt. Hinweis: Bei Lookupvorgängen für Schlüssel wird für ViewData und ViewBag die Groß-/Kleinschreibung nicht beachtet.

ViewData und ViewBag werden zur Laufzeit dynamisch aufgelöst. Da in diesen Elementen keine Typüberprüfung zur Kompilierzeit enthalten sind, sind beide in der Regel fehleranfälliger als Ansichtsmodelle. Aus diesem Grund verwenden Entwickler ViewData und ViewBag selten oder nie.

ViewData

ViewData ist ein ViewDataDictionary-Objekt, auf das über string-Schlüssel zugegriffen wird. Zeichenfolgendaten können gespeichert und ohne Umwandlung direkt verwendet werden. Trotzdem müssen Sie für die Extraktion andere ViewData-Objektwerte in bestimmte Typen umwandeln. Sie können ViewData verwenden, um Daten von Controllern an Ansichten und innerhalb von Ansichten zu übergeben, einschließlich Teilansichten und Layouts.

Im Folgenden finden Sie ein Beispiel, über das Werte für eine Begrüßung und eine Anrede mithilfe von ViewData in einer Aktion festgelegt werden:

public IActionResult SomeAction()
{
    ViewData["Greeting"] = "Hello";
    ViewData["Address"]  = new Address()
    {
        Name = "Steve",
        Street = "123 Main St",
        City = "Hudson",
        State = "OH",
        PostalCode = "44236"
    };

    return View();
}

Arbeiten Sie mit den Daten in einer Ansicht:

@{
    // Since Address isn't a string, it requires a cast.
    var address = ViewData["Address"] as Address;
}

@ViewData["Greeting"] World!

<address>
    @address.Name<br>
    @address.Street<br>
    @address.City, @address.State @address.PostalCode
</address>

[ViewData]-Attribut

Ein anderer Ansatz, der ViewDataDictionary verwendet, ist ViewDataAttribute. Die Werte der Eigenschaften in Controllern oder Razor Pages-Modellen, die mit dem [ViewData]-Attribut gekennzeichnet sind, werden im Wörterbuch gespeichert und daraus geladen.

Im folgenden Beispiel enthält der Home-Controller eine Title-Eigenschaft, die mit [ViewData] gekennzeichnet ist. Die About-Methode legt den Titel der Infoansicht fest:

public class HomeController : Controller
{
    [ViewData]
    public string Title { get; set; }

    public IActionResult About()
    {
        Title = "About Us";
        ViewData["Message"] = "Your application description page.";

        return View();
    }
}

Im Layout wird der Titel aus dem ViewData-Wörterbuch gelesen:

<!DOCTYPE html>
<html lang="en">
<head>
    <title>@ViewData["Title"] - WebApplication</title>
    ...

ViewBag

ViewBag ist standardmäßig nicht für die Verwendung in Razor Pages-PageModel -Klassen verfügbar.

ViewBag ist ein Microsoft.AspNetCore.Mvc.ViewFeatures.Internal.DynamicViewData-Objekt, das den dynamischen Zugriff auf die in ViewData gespeicherten Objekte ermöglicht. Es ist angenehmer, mit ViewBag zu arbeiten, da keine Umwandlung erforderlich ist. Im Folgenden finden Sie ein Beispiel, in dem dargestellt wird, wie Sie mit ViewBag das gleiche Ergebnis wie mit ViewData erzielen:

public IActionResult SomeAction()
{
    ViewBag.Greeting = "Hello";
    ViewBag.Address  = new Address()
    {
        Name = "Steve",
        Street = "123 Main St",
        City = "Hudson",
        State = "OH",
        PostalCode = "44236"
    };

    return View();
}

@ViewBag.Greeting World!

<address>
    @ViewBag.Address.Name<br>
    @ViewBag.Address.Street<br>
    @ViewBag.Address.City, @ViewBag.Address.State @ViewBag.Address.PostalCode
</address>

Gleichzeitiges Verwenden von ViewData und ViewBag

ViewBag ist standardmäßig nicht für die Verwendung in Razor Pages-PageModel -Klassen verfügbar.

Da ViewData und ViewBag beide auf dieselbe zugrunde liegende ViewData-Sammlung verweisen, können Sie sowohl ViewData als auch ViewBag verwenden, und zwischen beiden Elementen wechseln, wenn Sie Werte schreiben und lesen.

Legen Sie oben in einer ViewBag-Ansicht mithilfe von ViewData den Titel und mithilfe von About.cshtml die Beschreibung fest:

@{
    Layout = "/Views/Shared/_Layout.cshtml";
    ViewBag.Title = "About Contoso";
    ViewData["Description"] = "Let us tell you about Contoso's philosophy and mission.";
}

Lesen Sie die Eigenschaften, aber verwenden Sie ViewData und ViewBag in umgekehrter Reihenfolge. Rufen Sie in der _Layout.cshtml-Datei mithilfe von ViewData den Titel und mithilfe von ViewBag die Beschreibung ab:

<!DOCTYPE html>
<html lang="en">
<head>
    <title>@ViewData["Title"]</title>
    <meta name="description" content="@ViewBag.Description">
    ...

Bedenken Sie, dass für Zeichenfolgen mit ViewData keine Umwandlung erforderlich ist. @ViewData["Title"] kann ohne Umwandlung verwendet werden.

Sie können ViewData und ViewBag gleichzeitig verwenden und zwischen dem Lesen und Schreiben der Eigenschaften abwechseln. Das folgende Markup wird gerendert:

<!DOCTYPE html>
<html lang="en">
<head>
    <title>About Contoso</title>
    <meta name="description" content="Let us tell you about Contoso's philosophy and mission.">
    ...

Zusammenfassung der Unterschiede zwischen ViewData und ViewBag

ViewBag ist standardmäßig nicht für die Verwendung in Razor Pages-PageModel -Klassen verfügbar.

• ViewData
  • Wird von ViewDataDictionary abgeleitet und verfügt daher über Wörterbucheigenschaften wie ContainsKey, Add, Remove und Clear, die nützlich sein können.
  • Schlüssel sind Zeichenfolgen im Wörterbuch. Daher sind Leerzeichen erlaubt. Beispiel: ViewData["Some Key With Whitespace"]
  • Jeder Typ, der von string abweicht, muss in der Ansicht umgewandelt werden, sodass ViewData verwendet werden kann.
• ViewBag
  • Wird von Microsoft.AspNetCore.Mvc.ViewFeatures.Internal.DynamicViewData abgeleitet und ermöglicht daher die Erstellung von dynamischen Eigenschaften über die Punktnotation (@ViewBag.SomeKey = <value or object>), und es ist keine Umwandlung erforderlich. Über die Syntax von ViewBag können Controller und Ansichten schneller hinzugefügt werden.
  • Es ist einfacher, nach NULL-Werten zu suchen. Beispiel: @ViewBag.Person?.Name

Verwendung von ViewData oder ViewBag

ViewData und ViewBag sind beides gültige Ansätze, wenn Sie kleinere Datenmengen zwischen Controllern und Ansichten übergeben möchten. Sie können beliebig entscheiden, welche Methode Sie verwenden möchten. Sie können zwar ViewData- und ViewBag-Objekte miteinander vermischen, jedoch ist es einfacher, den Code zu lesen und zu verwalten, wenn nur ein Ansatz verwendet wird. Beide Ansätze werden zur Laufzeit dynamisch aufgelöst, wodurch häufig Laufzeitfehler entstehen. Einige Entwicklerteams vermeiden diese Ansätze daher.

Dynamische Ansichten

Ansichten, die einen Modelltyp nicht mit @model deklarieren, an die aber eine Modellinstanz übergeben wird (z.B. return View(Address);), können dynamisch auf die Eigenschaften der Instanz verweisen:

<address>
    @Model.Street<br>
    @Model.City, @Model.State @Model.PostalCode<br>
    <abbr title="Phone">P:</abbr> 425.555.0100
</address>

Dieses Feature bietet zwar Flexibilität, jedoch weder Kompilierungsschutz noch IntelliSense. Wenn die Eigenschaft nicht vorhanden ist, löst die Webseitengenerierung zur Laufzeit einen Fehler aus.

Weitere Ansichtsfeatures

Mithilfe von Taghilfsprogrammen können Sie einfach serverseitiges Verhalten zu vorhandenen HTML-Tags hinzufügen. Wenn Sie Taghilfsprogramme verwenden, müssen Sie keinen benutzerdefinierten Code oder Hilfsprogramme in Ihren Ansichten schreiben. Taghilfsprogramme werden als Attribute für HTML-Elemente angewendet und werden von Editors ignoriert, da sie diese nicht verarbeiten können. Dadurch können Sie Ansichtsmarkups in verschiedenen Tools bearbeiten und rendern.

Sie können benutzerdefinierte HTML-Markups über verschiedene integrierte HTML-Hilfsprogramme generieren. Eine komplexere Logik von Benutzeroberflächen kann über Ansichtskomponenten verarbeitet werden. Ansichtskomponenten stellen dieselben SoC-Designs bereit, die Controller und Ansichten bereitstellen. Wenn diese verwendet werden, werden keine Aktionen und Ansichten benötigt, die Daten verarbeiten, die von häufig verwendeten Benutzeroberflächenelementen verwendet werden.

Wie viele andere Aspekte von ASP.NET Core unterstützen Ansichten Dependency Injection und lassen zu, dass Dienste in Ansichten eingefügt werden.

h1 {
    color: red;
}

<link rel="stylesheet" href="~/{APP ASSEMBLY}.styles.css" />

<link rel="stylesheet" href="WebApp.styles.css" />

/* /Pages/Index.cshtml.rz.scp.css */
h1[b-3xxtam6d07] {
    color: red;
}

<h1 b-3xxtam6d07>

<ItemGroup>
  <None Update="{Pages|Views}/Index.cshtml.css" CssScope="custom-scope-identifier" />
</ItemGroup>

<ItemGroup>
  <None Update="{Pages|Views}/BaseView.cshtml.css" CssScope="custom-scope-identifier" />
  <None Update="{Pages|Views}/DerivedView.cshtml.css" CssScope="custom-scope-identifier" />
</ItemGroup>

<ItemGroup>
  <None Update="{Pages|Views}/*.cshtml.css" CssScope="custom-scope-identifier" />
</ItemGroup>

<PropertyGroup>
  <StaticWebAssetBasePath>_content/$(PackageId)</StaticWebAssetBasePath>
</PropertyGroup>

<PropertyGroup>
  <DisableScopedCssBundling>true</DisableScopedCssBundling>
</PropertyGroup>

<link href="_content/ClassLib/ClassLib.bundle.scp.css" rel="stylesheet">