Visualizações no ASP.NET Core MVC

Por Steve Smith e Dave Brock

Este documento explica os modos de exibição usados em aplicativos MVC ASP.NET Core. Para obter informações sobre Razor o Pages, consulte Razor Arquitetura e conceitos do Pages no ASP.NET Core.

No padrão Model-View-Controller (MVC), a exibição lida com a apresentação de dados do aplicativo e a interação do usuário. Um modo de exibição é um modelo HTML com marcação incorporadaRazor. Razor markup é um código que interage com a marcação HTML para produzir uma página da Web que é enviada ao cliente.

No ASP.NET Core MVC, as visualizações são .cshtml arquivos que usam a linguagem de programação C# na Razor marcação. Normalmente, os arquivos de exibição são agrupados em pastas nomeadas para cada um dos controladores do aplicativo. As pastas são armazenadas em uma Views pasta na raiz do aplicativo:

O Home controlador é representado por uma Home pasta dentro da Views pasta. A Home pasta contém os modos de exibição das Aboutpáginas da Web , Contacte Index (página inicial). Quando um usuário solicita uma dessas três páginas da Web, as Home ações do controlador no controlador determinam qual das três exibições é usada para criar e retornar uma página da Web para o usuário.

Use layouts para fornecer seções de páginas da Web consistentes e reduzir a repetição de código. Os layouts geralmente contêm os elementos de cabeçalho, navegação e menu e o rodapé. O cabeçalho e o rodapé geralmente contêm marcação clichê para muitos elementos de metadados e links para ativos de script e estilo. Os layouts ajudam a evitar essa marcação clichê em suas visualizações.

As vistas parciais reduzem a duplicação de código através da gestão de partes reutilizáveis das vistas. Por exemplo, uma visualização parcial é útil para uma biografia de autor em um site de blog que aparece em várias visualizações. Uma biografia do autor é um conteúdo de visualização comum e não requer código para ser executada para produzir o conteúdo para a página da Web. O conteúdo da biografia do autor está disponível para a visualização apenas por vinculação de modelo, portanto, usar uma visualização parcial para esse tipo de conteúdo é ideal.

Os componentes de exibição são semelhantes aos modos de exibição parciais, pois permitem reduzir o código repetitivo, mas são apropriados para exibir conteúdo que requer que o código seja executado no servidor para renderizar a página da Web. Os componentes de exibição são úteis quando o conteúdo renderizado requer interação com o banco de dados, como para um carrinho de compras de site. Os componentes de exibição não estão limitados à vinculação de modelo para produzir saída de página da Web.

Benefícios do uso de modos de exibição

As visualizações ajudam a estabelecer a separação de preocupações dentro de um aplicativo MVC, separando a marcação da interface do usuário de outras partes do aplicativo. Seguir o design do SoC torna seu aplicativo modular, o que oferece vários benefícios:

• O aplicativo é mais fácil de manter porque é mais organizado. As visualizações geralmente são agrupadas por recurso do aplicativo. Isso facilita a localização de modos de exibição relacionados ao trabalhar em um recurso.
• As partes do aplicativo são acopladas de forma flexível. Você pode criar e atualizar as exibições do aplicativo separadamente dos componentes de lógica de negócios e acesso a dados. Você pode modificar as visualizações do aplicativo sem necessariamente ter que atualizar outras partes do aplicativo.
• É mais fácil testar as partes da interface do usuário do aplicativo porque as exibições são unidades separadas.
• Devido à melhor organização, é menos provável que você repita acidentalmente seções da interface do usuário.

Criando um modo de exibição

Modos de exibição específicos de um controlador são criados na Views/[ControllerName] pasta. As exibições compartilhadas entre controladores são colocadas na Views/Shared pasta. Para criar uma vista, adicione um novo ficheiro e dê-lhe o mesmo nome que a ação do controlador associada à extensão do .cshtml ficheiro. Para criar uma exibição que corresponda à About ação no Home controlador, crie um About.cshtml arquivo na Views/Home pasta:

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

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

Razor A marcação começa com o @ símbolo. Execute instruções C# colocando o código C# dentro Razor de blocos de código definidos por chaves ({ ... }). Por exemplo, veja a atribuição de "Sobre" para ViewData["Title"] mostrado acima. Você pode exibir valores em HTML simplesmente referenciando o valor com o @ símbolo. Ver o conteúdo dos <h2> elementos e <h3> acima.

O conteúdo de exibição mostrado acima é apenas parte de toda a página da Web que é renderizada para o usuário. O restante do layout da página e outros aspetos comuns do modo de exibição são especificados em outros arquivos de exibição. Para saber mais, consulte o tópico Layout.

Como os controladores especificam modos de exibição

Normalmente, as exibições são retornadas de ações como um ViewResult, que é um tipo de ActionResult. Seu método de ação pode criar e retornar um ViewResult diretamente, mas isso não é feito normalmente. Como a maioria dos controladores herda do Controller, basta usar o View método auxiliar para retornar o ViewResult:

HomeController.cs:

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

    return View();
}

Quando essa ação retorna, o About.cshtml modo de exibição mostrado na última seção é processado como a seguinte página da Web:

O View método auxiliar tem várias sobrecargas. Opcionalmente, pode especificar:

• Uma visão explícita para retornar:

  return View("Orders");
  

• Um modelo para passar para a vista:

  return View(Orders);
  

• Uma vista e um modelo:

  return View("Orders", Orders);
  

Ver descoberta

Quando uma ação retorna um modo de exibição, ocorre um processo chamado descoberta de exibição . Esse processo determina qual arquivo de exibição é usado com base no nome do modo de exibição.

O comportamento padrão do View método (return View();) é retornar um modo de exibição com o mesmo nome do método de ação do qual ele é chamado. Por exemplo, o AboutActionResult nome do método do controlador é usado para procurar um arquivo de exibição chamado About.cshtml. Primeiro, o tempo de execução procura a Views/[ControllerName] exibição na pasta. Se não encontrar uma vista correspondente, procura Shared a vista na pasta.

Não importa se você retorna implicitamente o ViewResult com return View(); ou passa explicitamente o nome da exibição para o View método com return View("<ViewName>");. Em ambos os casos, a descoberta de exibição procura um arquivo de exibição correspondente nesta ordem:

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

Um caminho de arquivo de exibição pode ser fornecido em vez de um nome de exibição. Se estiver usando um caminho absoluto começando na raiz do aplicativo (opcionalmente começando com "/" ou "~/"), a .cshtml extensão deve ser especificada:

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

Você também pode usar um caminho relativo para especificar exibições em diretórios diferentes sem a .cshtml extensão. Dentro do HomeController, você pode retornar a Index exibição de suas Manage visualizações com um caminho relativo:

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

Da mesma forma, você pode indicar o diretório específico do controlador atual com o prefixo "./":

return View("./About");

Exibições parciais e componentes de exibição usam mecanismos de descoberta semelhantes (mas não idênticos).

Você pode personalizar a convenção padrão de como os modos de exibição estão localizados no aplicativo usando um arquivo IViewLocationExpander.

A descoberta de exibição depende da localização de arquivos de exibição por nome de arquivo. Se o sistema de arquivos subjacente diferenciar maiúsculas de minúsculas, os nomes de exibição provavelmente diferenciarão maiúsculas de minúsculas. Para compatibilidade entre sistemas operacionais, faça a correspondência entre nomes de controladores e ações e pastas de exibição e nomes de arquivos associados. Se você encontrar um erro informando que um arquivo de exibição não pode ser encontrado ao trabalhar com um sistema de arquivos que diferencia maiúsculas de minúsculas, confirme se o invólucro corresponde entre o arquivo de exibição solicitado e o nome real do arquivo de exibição.

Siga a prática recomendada de organizar a estrutura de arquivos para suas exibições para refletir as relações entre controladores, ações e exibições para manutenção e clareza.

Passar dados para visualizações

Passe dados para visualizações usando várias abordagens:

• Dados fortemente tipados: viewmodel
• Dados digitados fracamente
  • ViewData (ViewDataAttribute)
  • ViewBag

Dados fortemente tipados (viewmodel)

A abordagem mais robusta é especificar um tipo de modelo na exibição. Esse modelo é comumente chamado de viewmodel. Você passa uma instância do tipo viewmodel para o modo de exibição da ação.

Usar um viewmodel para passar dados para um modo de exibição permite que o modo de exibição aproveite a verificação de tipo forte . Digitação forte (ou fortemente tipada) significa que cada variável e constante tem um tipo explicitamente definido (por exemplo, string, int, ou DateTime). A validade dos tipos usados em uma exibição é verificada em tempo de compilação.

Visual Studio e Visual Studio Code listam membros de classe fortemente tipados usando um recurso chamado IntelliSense. Quando quiser ver as propriedades de um viewmodel, digite o nome da variável para o viewmodel seguido de um ponto (.). Isso ajuda você a escrever código mais rapidamente com menos erros.

Especifique um modelo usando a @model diretiva. Use o modelo com @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>

Para fornecer o modelo para a exibição, o controlador passa-o como um parâmetro:

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);
}

Não há restrições sobre os tipos de modelo que você pode fornecer a uma exibição. Recomendamos o uso de modelos de exibição POCO (Plain Old CLR Object) com pouco ou nenhum comportamento (métodos) definido. Normalmente, as Models classes viewmodel são armazenadas na pasta ou em uma pasta separada ViewModels na raiz do aplicativo. O Address viewmodel usado no exemplo acima é um viewmodel POCO armazenado em um arquivo chamado Address.cs:

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

Nada impede que você use as mesmas classes para os tipos de modelo de exibição e os tipos de modelo de negócios. No entanto, o uso de modelos separados permite que suas exibições variem independentemente da lógica de negócios e das partes de acesso a dados do seu aplicativo. A separação de modelos e viewmodels também oferece benefícios de segurança quando os modelos usam vinculação e validação de modelo para dados enviados ao aplicativo pelo usuário.

Dados digitados fracamente (ViewData, [ViewData] atributo e ViewBag)

ViewBag não está disponível por predefinição para utilização em Razor Classes de páginasPageModel.

Além das visualizações fortemente tipadas, as visualizações têm acesso a uma coleção de dados fracamente tipada (também chamada de vagamente tipada). Ao contrário dos tipos fortes, os tipos fracos (ou tipos soltos) significam que você não declara explicitamente o tipo de dados que está usando. Você pode usar a coleção de dados digitados fracamente para passar pequenas quantidades de dados para dentro e para fora de controladores e exibições.

Passando dados entre um ...	Example
Controlador e uma visão	Preencher uma lista suspensa com dados.
Vista e uma vista de esquema	Definir o conteúdo do <title> elemento no modo de exibição de layout a partir de um arquivo de exibição.
Vista parcial e vista	Um widget que exibe dados com base na página da Web que o usuário solicitou.

Essa coleção pode ser referenciada por meio das ViewData propriedades ou ViewBag em controladores e exibições. A ViewData propriedade é um dicionário de objetos digitados fracamente. A ViewBag propriedade é um wrapper que ViewData fornece propriedades dinâmicas para a coleção subjacente ViewData . Nota: As pesquisas de teclas não diferenciam maiúsculas de minúsculas para ViewDataambos e ViewBag .

ViewData e ViewBag são resolvidos dinamicamente em tempo de execução. Como eles não oferecem verificação de tipo em tempo de compilação, ambos geralmente são mais propensos a erros do que usar um viewmodel. Por esse motivo, alguns desenvolvedores preferem minimamente ou nunca usar ViewData e ViewBag.

ViewData

ViewData é um ViewDataDictionary objeto acessado através string de chaves. Os dados de cadeia de caracteres podem ser armazenados e usados diretamente sem a necessidade de uma conversão, mas você deve converter outros ViewData valores de objeto para tipos específicos ao extraí-los. Você pode usar ViewData para passar dados de controladores para modos de exibição e dentro de modos de exibição, incluindo modos de exibição parciais e layouts.

A seguir está um exemplo que define valores para uma saudação e um endereço usando ViewData em uma ação:

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

    return View();
}

Trabalhar com os dados numa vista:

@{
    // 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>

Atributo [ViewData]

Outra abordagem que usa o ViewDataDictionary é ViewDataAttribute. Propriedades em controladores ou Razor modelos de página marcados com o [ViewData] atributo têm seus valores armazenados e carregados do dicionário.

No exemplo a seguir, o Home controlador contém uma Title propriedade marcada com [ViewData]. O About método define o título para o modo de exibição Sobre:

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

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

        return View();
    }
}

No layout, o título é lido do dicionário ViewData:

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

ViewBag

ViewBag não está disponível por predefinição para utilização em Razor Classes de páginasPageModel.

ViewBag é um Microsoft.AspNetCore.Mvc.ViewFeatures.Internal.DynamicViewData objeto que fornece acesso dinâmico aos objetos armazenados no ViewData. ViewBag pode ser mais conveniente para trabalhar, uma vez que não requer fundição. O exemplo a seguir mostra como usar ViewBag com o mesmo resultado ViewData acima:

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>

Utilização ViewData e ViewBag utilização simultânea

ViewBag não está disponível por predefinição para utilização em Razor Classes de páginasPageModel.

Uma vez ViewData que e ViewBag referem-se à mesma coleção subjacente ViewData , você pode usar ambos e ViewDataViewBag e misturar e combinar entre eles ao ler e escrever valores.

Defina o título usando ViewBag e a descrição usando ViewData na parte superior de uma About.cshtml exibição:

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

Leia as propriedades, mas inverta o uso de ViewData e ViewBag. _Layout.cshtml No arquivo, obtenha o título usando ViewData e obtenha a descrição usando ViewBag:

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

Lembre-se de que as cadeias de caracteres não exigem um elenco para ViewData. Você pode usar @ViewData["Title"] sem casting.

Usar ambos ViewData e ViewBag ao mesmo tempo funciona, assim como misturar e combinar a leitura e a escrita das propriedades. A seguinte marcação é renderizada:

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

Resumo das diferenças entre ViewData e ViewBag

ViewBag não está disponível por predefinição para utilização em Razor Classes de páginasPageModel.

• ViewData
  • Deriva de , por isso tem propriedades de ViewDataDictionarydicionário que podem ser úteis, como ContainsKey, Add, Removee Clear.
  • As teclas no dicionário são strings, portanto, o espaço em branco é permitido. Exemplo: ViewData["Some Key With Whitespace"]
  • Qualquer tipo diferente de um string deve ser lançado no modo de exibição para usar ViewData.
• ViewBag
  • Deriva de Microsoft.AspNetCore.Mvc.ViewFeatures.Internal.DynamicViewData, por isso permite a criação de propriedades dinâmicas usando notação de pontos (@ViewBag.SomeKey = <value or object>), e nenhuma transmissão é necessária. A sintaxe de ViewBag torna mais rápido adicionar a controladores e visualizações.
  • Mais simples de verificar valores nulos. Exemplo: @ViewBag.Person?.Name

Quando utilizar ViewData ou ViewBag

Ambas ViewData e ViewBag são abordagens igualmente válidas para a passagem de pequenas quantidades de dados entre controladores e visualizações. A escolha de qual usar é baseada na preferência. Você pode misturar e combinar ViewData e ViewBag objetos, no entanto, o código é mais fácil de ler e manter com uma abordagem usada consistentemente. Ambas as abordagens são resolvidas dinamicamente em tempo de execução e, portanto, propensas a causar erros de tempo de execução. Algumas equipas de desenvolvimento evitam-nos.

Vistas dinâmicas

As exibições que não declaram um tipo de modelo usando @model , mas que têm uma instância de modelo passada para elas (por exemplo, return View(Address);) podem fazer referência às propriedades da instância dinamicamente:

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

Este recurso oferece flexibilidade, mas não oferece proteção de compilação ou IntelliSense. Se a propriedade não existir, a geração da página da Web falhará no tempo de execução.

Mais recursos de visualização

Os Ajudantes de Tags facilitam a adição de comportamento do lado do servidor a tags HTML existentes. Usar Tag Helpers evita a necessidade de escrever código personalizado ou auxiliares em suas visualizações. Os auxiliares de tags são aplicados como atributos a elementos HTML e são ignorados pelos editores que não podem processá-los. Isso permite que você edite e renderize a marcação de exibição em uma variedade de ferramentas.

A geração de marcação HTML personalizada pode ser alcançada com muitos Auxiliares HTML integrados. A lógica mais complexa da interface do usuário pode ser manipulada pelo View Components. Os componentes de visualização fornecem o mesmo SoC que os controladores e visualizações oferecem. Eles podem eliminar a necessidade de ações e exibições que lidam com dados usados por elementos comuns da interface do usuário.

Como muitos outros aspetos do ASP.NET Core, os modos de exibição suportam a injeção de dependência, permitindo que os serviços sejam injetados nos modos de exibição.

Isolamento CSS

Isolar estilos CSS em páginas, exibições e componentes individuais para reduzir ou evitar:

• Dependências de estilos globais que podem ser difíceis de manter.
• Conflitos de estilo em conteúdo aninhado.

Para adicionar um arquivo CSS com escopo para uma página ou exibição, coloque os estilos CSS em um arquivo complementar .cshtml.css correspondente ao nome do .cshtml arquivo. No exemplo a seguir, um Index.cshtml.css arquivo fornece estilos CSS que são aplicados apenas à Index.cshtml página ou exibição.

Pages/Index.cshtml.css (Razor Páginas) ou Views/Index.cshtml.css (MVC):

h1 {
    color: red;
}

O isolamento CSS ocorre no momento da compilação. A estrutura reescreve os seletores CSS para corresponder à marcação renderizada pelas páginas ou exibições do aplicativo. Os estilos CSS reescritos são agrupados e produzidos como um ativo estático, {APP ASSEMBLY}.styles.css. O espaço reservado {APP ASSEMBLY} é o nome do assembly do projeto. Um link para os estilos CSS incluídos é colocado no layout do aplicativo.

<head> No conteúdo do aplicativo Pages/Shared/_Layout.cshtml (Razor Pages) ou Views/Shared/_Layout.cshtml (MVC), adicione ou confirme a presença do link para os estilos CSS incluídos:

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

No exemplo a seguir, o nome do assembly do aplicativo é WebApp:

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

Os estilos definidos em um arquivo CSS com escopo são aplicados apenas à saída renderizada do arquivo correspondente. No exemplo anterior, quaisquer h1 declarações CSS definidas em outro lugar do aplicativo não entram em conflito com o Indexestilo de título do . As regras de herança e cascata no estilo CSS permanecem em vigor para arquivos CSS com escopo. Por exemplo, os estilos aplicados diretamente a um <h1> elemento no arquivo substituem Index.cshtml os estilos do arquivo CSS com escopo no Index.cshtml.css.

Observação

Para garantir o isolamento do estilo CSS quando ocorre agregação, não há suporte para a importação de CSS em Razor blocos de código.

O isolamento CSS só se aplica a elementos HTML. O isolamento CSS não é suportado para Tag Helpers.

Dentro do arquivo CSS incluído, cada página, exibição ou Razor componente é associado a um identificador de escopo no formato b-{STRING}, onde o espaço reservado {STRING} é uma cadeia de caracteres de dez caracteres gerada pela estrutura. O exemplo a seguir fornece o estilo para o elemento anterior <h1> na Index página de um Razor aplicativo Pages:

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

Na página onde o Index estilo CSS é aplicado a partir do arquivo incluído, o identificador de escopo é acrescentado como um atributo HTML:

<h1 b-3xxtam6d07>

O identificador é exclusivo de um aplicativo. No momento da compilação, um pacote de projeto é criado com a convenção {STATIC WEB ASSETS BASE PATH}/Project.lib.scp.css, onde o espaço reservado {STATIC WEB ASSETS BASE PATH} é o caminho base de ativos da Web estáticos.

Se outros projetos forem utilizados, como pacotes NuGet ou Razor bibliotecas de classes, o arquivo incluído:

• Faz referência aos estilos usando importações CSS.
• Não é publicado como um ativo da Web estático do aplicativo que consome os estilos.

Suporte ao pré-processador CSS

Os pré-processadores CSS são úteis para melhorar o desenvolvimento CSS utilizando recursos como variáveis, aninhamento, módulos, mixins e herança. Embora o isolamento CSS não suporte nativamente pré-processadores CSS, como Sass ou Less, a integração de pré-processadores CSS é perfeita, desde que a compilação do pré-processador ocorra antes que a estrutura reescreva os seletores CSS durante o processo de compilação. Usando o Visual Studio, por exemplo, configure a compilação de pré-processador existente como uma tarefa Antes da compilação no Visual Studio Task Runner Explorer.

Muitos pacotes NuGet de terceiros, como AspNetCore.SassCompilero , podem compilar arquivos SASS/SCSS no início do processo de compilação antes que o isolamento CSS ocorra e nenhuma configuração adicional seja necessária.

Configuração de isolamento CSS

O isolamento CSS permite a configuração para alguns cenários avançados, como quando há dependências em ferramentas ou fluxos de trabalho existentes.

Personalizar o formato do identificador de escopo

Nesta seção, o espaço reservado {Pages|Views} é Pages para Razor aplicativos Pages ou Views MVC.

Por padrão, os identificadores de escopo usam o formato b-{STRING}, onde o espaço reservado {STRING} é uma cadeia de dez caracteres gerada pela estrutura. Para personalizar o formato do identificador de escopo, atualize o arquivo de projeto para um padrão desejado:

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

No exemplo anterior, o CSS gerado para Index.cshtml.css altera seu identificador de escopo de b-{STRING} para custom-scope-identifier.

Use identificadores de escopo para obter herança com arquivos CSS com escopo. No exemplo de arquivo de projeto a seguir, um BaseView.cshtml.css arquivo contém estilos comuns entre modos de exibição. Um DerivedView.cshtml.css arquivo herda esses estilos.

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

Use o operador curinga (*) para compartilhar identificadores de escopo em vários arquivos:

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

Alterar o caminho base para ativos da Web estáticos

O arquivo CSS com escopo é gerado na raiz do aplicativo. No arquivo de projeto, use a StaticWebAssetBasePath propriedade para alterar o caminho padrão. O exemplo a seguir coloca o arquivo CSS com escopo e o restante dos ativos do aplicativo no _content caminho:

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

Desativar agregação automática

Para desativar como o framework publica e carrega arquivos com escopo em tempo de execução, use a DisableScopedCssBundling propriedade. Ao usar essa propriedade, outras ferramentas ou processos são responsáveis por retirar os arquivos CSS isolados do obj diretório e publicá-los e carregá-los em tempo de execução:

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

Razor suporte de biblioteca de classes (RCL)

Quando uma Razor biblioteca de classes (RCL) fornece estilos isolados, o <link> atributo da href tag aponta para {STATIC WEB ASSET BASE PATH}/{PACKAGE ID}.bundle.scp.css, onde os espaços reservados são:

• {STATIC WEB ASSET BASE PATH}: O caminho de base do ativo da Web estático.
• {PACKAGE ID}: O identificador de pacote da biblioteca. O identificador de pacote assume como padrão o nome do assembly do projeto se o identificador do pacote não for especificado no arquivo do projeto.

No exemplo a seguir:

• O caminho de base do ativo da Web estático é _content/ClassLib.
• O nome do assembly da biblioteca de classes é ClassLib.

Pages/Shared/_Layout.cshtml (Razor Páginas) ou Views/Shared/_Layout.cshtml (MVC):

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

Para obter mais informações sobre RCLs, consulte os seguintes artigos:

• Interface do usuário reutilizável Razor em bibliotecas de classe com ASP.NET Core
• Consumir componentes do ASP.NET Core Razor a partir de uma biblioteca de classes (RCL) Razor

Para obter informações sobre Blazor o isolamento CSS, consulte ASP.NET Isolamento CSS principalBlazor.