Como migrar projetos do ASP.NET MVC para ASP.NET Core

Fique por dentro

Este passo a passo foi escrito pelo time da nopCommerce que trabalha com projeto de c�digo aberto e pode ser aplicado a qualquer projeto ASP.NET MVC. Descreve por que voc� precisa migrar, e por que projetos que n�o acompanham essas tend�ncias deveriam consider�-las.

Antes de seguir para o passo a passo de como ir para do ASP.NET MVC para ASP.NET Core (usando o nopCommerce como exemplo), apresenta-se uma r�pida vis�o das vantagens desse framework.

Este � um guia pr�tico para migrar um projeto ASP.NET MVC framework para ASP.NET Core. Este passo a passo foi escrito pelo time da nopCommerce que trabalha com projeto de c�digo aberto e pode ser aplicado a qualquer projeto ASP.NET MVC. Descreve por que voc� precisa migrar, e por que projetos que n�o acompanham essas tend�ncias deveriam consider�-las.

Antes de seguir para o passo a passo de como ir para do ASP.NET MVC para ASP.NET Core (usando o nopCommerce como exemplo), apresenta-se uma r�pida vis�o das vantagens desse framework.

ASP.NET Core tornou-se muito conhecido e a estrutura desenvolvida possui v�rias atualizaç�es e melhorias, tornando-a bastante est�vel, tecnologicamente avançada e resistente a ataques XSRF/CSRF, como mostra a Figura 1.

Figura 1. Estrutura do ASP.NET Core

Cross-platform � uma das caracter�sticas que a distingui, fazendo-o mais e mais popular. De agora em diante sua aplicaç�o web pode rodar em Windows e Unix.

Sua arquitetura � modular, pois o ASP.NET Core vem totalmente na forma de pacotes NuGet. Isto permite a optimizaç�o da aplicaç�o, incluindo os pacotes necess�rios juntamente a aplicaç�o, melhorando a performance da soluç�o e reduzindo o tempo que leva para fazer o upgrade das partes separadas. Esta � a segunda caracter�stica importante, que permite ao desenvolvedor integrar novos recursos em suas soluç�es de maneira mais flex�vel.

O desempenho � um outro passo para a criaç�o de uma aplicaç�o de alta performance. ASP.NET Core processa 2.300% mais requisiç�es por segundo do que o ASP.NET 4.6, e 800% mais requisiç�es por segundo do que o Node.js, como vemos na Figura 2. Voc� pode checar esses detalhes de performance e testar voc� mesmo aqui ou ainda baixando o fonte atrav�s do link aqui no post.

Figura 2. Comparaç�o de desempenho

Middleware � um novo pipeline leve e r�pido para solicitaç�es na aplicaç�o, onde cada parte processa uma solicitaç�o HTTP e decide retornar o resultado ou passa para a pr�xima parte do middleware. Esta abordagem possibilita ao desenvolvedor controle total sobre o pipeline HTTP e contribui para o desenvolvimento de m�dulos simples para a aplicaç�o, o que � importante para um projeto de c�digo aberto crescente.

O ASP.NET Core MVC tamb�m fornece caracter�sticas que simplificam o desenvolvimento web. O nopCommerce j� utiliza algumas delas, tais como templates Modelo-Exibiç�es-Controles (MVC), sintaxe Razor, modelo de dados e validaç�es.

Entre as novas caracter�sticas est�o:

Auxiliares de Marca: c�digo do lado do servidor para participar da criaç�o e renderizaç�o HTML com os elementos em arquivos Razor.
View Components: uma nova ferramenta similar com as vis�es parciais, mas com o desempenho muito superior. nopCommerce utiliza view components ao reutilizar a l�gica de renderizaç�o e as tarefas que s�o muito complexas para vis�es parciais.
DI em vis�es: embora a maioria dos dados exibidos nas visualizaç�es venham dos controladores, nopCommerce tamb�m tem vis�es onde a depend�ncia de injeç�o � mais conveniente.

� claro que o ASP.NET Core possui muito mais caracter�sticas, mas destacamos algumas das mais interessantes.

Agora considere alguns pontos para lembrar quando transportar sua aplicaç�o para uma nova estrutura.

Migration

As seguintes descriç�es cont�m uma grande quantidade de links para a documentaç�o oficial do ASP.NET Core, que oferecem informaç�es mais detalhadas sobre os t�picos e guia os desenvolvedores que enfrentam estas tarefas pela primeira vez.

Passo 1. Preparando a ferramenta

A primeira coisa que voc� precisa � migrar o Visual Studio 2017 para vers�o 15.3 ou posterior e instalar a �ltima vers�o do .NET Core SDK.

Antes de transferir a aplicaç�o, indica-se usar o .NET Portability Analyzer. Isto pode ser um bom ponto de partida para entender como a transfer�ncia de m�o de obra intensiva de uma plataforma para outra pode ser. Mesmo assim, esta ferramenta n�o cobre todos os problemas, pois este processo tem muitas armadilhas a serem resolvidas � medida que surgem. Somente os passos principais e as soluç�es usadas no projeto nopCommerce s�o descritas aqui.

A primeira coisa e mais f�cil a fazer � atualizar os links para as bibliotecas usadas no projeto para que ele suporte .NET Standard.

Passo 2. An�lise de compatibilidade do pacote NuGet para suportar o padr�o .NET

Se voc� usa pacotes NuGet em seus projetos, verifique se eles s�o compat�veis com o .NET Core. Uma maneira de se fazer isso � usar a ferramenta NuGetPackageExplorer.

Passo 3. O novo formato do arquivo csproj em .NET Core

Uma nova abordagem para adicionar refer�ncias a pacotes de terceiros foi introduzida no .NET Core. Ao adicionar uma nova biblioteca de classes, precisamos abrir o arquivo principal do projeto e substituir seu conte�do da seguinte maneira apresentada na Listagem 1.

<Project Sdk="Microsoft.NET.Sdk">
    <PropertyGroup>
      <TargetFramework>netcoreapp2.2</TargetFramework>   
    </PropertyGroup>
    <ItemGroup>
      <PackageReference Include="Microsoft.AspNetCore.App" Version="2.2.6" />
      ...
    </ItemGroup>
    ...
  </Project>

Listagem 1. Conte�do do arquivo principal

As refer�ncias �s bibliotecas conectadas ser�o carregadas automaticamente. Para mais informaç�es de como comparar as propriedades do projeto project.json e CSPROJ, leia a documentaç�o oficial aqui e aqui.

Passo 4. Alteraç�o da Namespace

Delete todos os uses de System.Web e troque por Microsoft.AspNetCore.

Passo 5. Configure o arquivo Startup.cs em vez de usar global.asax

O ASP.NET Core tem uma nova maneira de carregar o aplicativo: o ponto de entrada do aplicativo � o Startup e n�o existe depend�ncia do arquivo Global.asax, pois a inicializaç�o registra os middlewares no aplicativo. No Startup deve-se incluir o m�todo Configure e o middleware necess�rio deve ser adicionado ao pipeline no Configure.

Problemas a serem resolvidos no Startup.cs:

Configurar o middleware para solicitaç�es MVC e WebAPI;
Configurando para:
- Exception handling: voc� inevitavelmente enfrentar� v�rias colis�es durante a transfer�ncia, portanto, esteja pronto e configure o tratamento de exceç�es no ambiente de desenvolvimento. Com UseDeveloperExceptionPage no NopCommerce inseriu-se middleware para capturar exceç�es.
- Roteamento MVC: o registro de novas rotas tamb�m foi alterado e o IRouteBuilder agora � usado ao inv�s de RouteCollection como uma nova maneira de registrar restriç�es (IActionConstraint).
- Filtros MVC/WebAPI: os filtros devem ser alterados de acordo com a nova implementaç�o do ASP.NET Core.
- MVC/WebAPI Formattadores: apresentado na Listagem 2.
- Model binding : apresentado na Listagem 3.
  
  //add basic MVC feature var mvcBuilder = services.AddMvc(); //add custom model binder provider (to the top of the provider list) mvcBuilder.AddMvcOptions(options => options.ModelBinderProviders.Insert(0, new NopModelBinderProvider()));
  Listagem 2. MVC/WebAPI Formattadores
  
  /// <summary> /// Represents model binder provider for the creating NopModelBinder /// </summary> public class NopModelBinderProvider : IModelBinderProvider { /// <summary> /// Creates a nop model binder based on passed context /// </summary> /// <param name="context">Model binder provider context</param> /// <returns>Model binder</returns> public IModelBinder GetBinder(ModelBinderProviderContext context) { { if (context == null) throw new ArgumentNullException(nameof(context)); var modelType = context.Metadata.ModelType; if (!typeof(BaseNopModel).IsAssignableFrom(modelType)) return null; //use NopModelBinder as a ComplexTypeModelBinder for BaseNopModel if (context.Metadata.IsComplexType && !context.Metadata.IsCollectionType) { { //create binders for all model properties var propertyBinders = context.Metadata.Properties .ToDictionary(modelProperty => modelProperty, modelProperty => context.CreateBinder(modelProperty)); .ToDictionary(modelProperty => modelProperty, modelProperty => context.CreateBinder(modelProperty)); return new NopModelBinder(propertyBinders, EngineContext.Current.Resolve<ILoggerFactory>()); } } //or return null to further search for a suitable binder return null; } } } }
  Listagem 3. Areas
- Areas: para incluir Area em uma aplicaç�o ASP.NET Core adicione uma rota regular ao arquivo Startup.cs. Desta maneira, ele procurar� configurar a �rea de Admin, como mostra a Listagem 4.
  app.UseMvc(routes => { routes.MapRoute("areaRoute", "{area:exists}/{controller=Admin}/ {action=Index}/{id?}"); routes.MapRoute( name: "default", template: {controller=Home}/{action=Index}/{id?}"); });
  Listagem 4. Configurando Area
  
  Ao fazer isso, uma pasta com o nome Area com outra pasta dentro denominada Admin dever� estar na raiz do aplicativo, como mostra a Figura 3. Agora, o atributo [Area("Admin")] [Route("admin")] dever� ser usado para conectar o controle com esta �rea.

Resta apenas criar visualizaç�es para todas as aç�es descritas no controlador, como vemos na Listagem 5.

Figura 3. Estrutura com a pasta Admin

 [Area("Admin")]
 [Route("admin")]
 public class AdminController : Controller
 {    
     public IActionResult Index()
     {
         return View();
     }    
 }

Listagem 5. Criando visualizaç�es

Validaç�o

O IformCollection n�o dever� ser passado para os controladores, pois neste caso, a validaç�o do servidor ASP.NET est� desabilitada. O MVC est� suprimindo a validaç�o adicional se o IFormCollection n�o for nulo. Para resolver esse problema, esta propriedade pode ser adicionada para o modelo, impedindo de passar diretamente para o m�todo controlador. Esta regra trabalha somente se o modelo est� dispon�vel, caso contr�rio, n�o existir�o validaç�es.

As propriedades filhas n�o s�o mais validadas automaticamente e devem ser especificadas manualmente.

Passo 6. Migrar manipuladores HTTP e HttpModules para Middleware

Manipuladores e m�dulos HTTP s�o de fato muito similares ao conceito de Middleware no ASP.NET Core. Contudo, diferentemente dos m�dulos, a ordem do middleware � baseada em que s�o inseridos no pipeline de solicitaç�o. A ordem dos m�dulos � principalmente baseada nos eventos do ciclo de vida do aplicativo. A ordem do middleware para respostas � oposta � ordem de solicitaç�es, enquanto a ordem dos m�dulos para solicitaç�es e respostas � a mesma.

Sabendo disso, voc� pode proceder com as seguintes atualizaç�es:

Migrar de m�dulos para Middleware (AuthenticationMiddleware, CultureMiddleware etc.);
Manipuladores para Middleware;
Uso de novo middleware.

A autenticaç�o no nopCommerce n�o usa um sistema de autenticaç�o interno. Para esse prop�sito � usado o AuthenticationMiddleware, desenvolvido de acordo com a nova estrutura do ASP.NET Core, como mostra a Listagem 6.


  public class AuthenticationMiddleware
 {
    private readonly RequestDelegate _next;
    public AuthenticationMiddleware(IAuthenticationSchemeProvider schemes, 
    RequestDelegate next)
    {
        Schemes = schemes ?? throw new ArgumentNullException(nameof(schemes));
        _next = next ?? throw new ArgumentNullException(nameof(next));
    }
 
    public IAuthenticationSchemeProvider Schemes { get; set; }
    
    public async Task Invoke(HttpContext context)
    {
        context.Features.Set<IAuthenticationFeature>
        (new AuthenticationFeature
        {
            OriginalPath = context.Request.Path,
            OriginalPathBase = context.Request.PathBase
        });
       
        var handlers = context.RequestServices.GetRequiredService<
          IAuthenticationHandlerProvider>();
        foreach (var scheme in await Schemes.GetRequestHandlerSchemesAsync())
        {
            try
            {
                if (await handlers.GetHandlerAsync(context, scheme.Name) is 
                  IAuthenticationRequestHandler handler && 
                  await handler.HandleRequestAsync())
                    return;
            }
            catch
            {
                // ignored
            }
        }
 
        var defaultAuthenticate = await Schemes.GetDefaultAuthenticateSchemeAsync();
        if (defaultAuthenticate != null)
        {
            var result = await context.AuthenticateAsync(defaultAuthenticate.Name);
            if (result?.Principal != null)
            {
                context.User = result.Principal;
            }
        }
        await _next(context);
    }
 }

Listagem 6. Uso do AuthenticationMiddleware

O ASP.NET fornece muitos middlewares que voc� pode usar em seu aplicativo, por�m o desenvolvedor pode criar o seu pr�prio middleware e adicion�-lo no pipeline de solicitaç�es HTTP. Para simplificar o processo, adicionou-se uma interface especial no nopCommerce e agora basta criar uma classe que a implemente, como mostra a Listagem 7.


  public interface INopStartup
  {
      /// <summary>
      /// Add and configure any of the middleware
      /// </summary>
      /// <param name="services">Collection of service descriptors</param>
      /// <param name="configuration">Configuration of the application</param>
      void ConfigureServices(IServiceCollection services, IConfiguration configuration);
   
      /// <summary>
      /// Configure the using of added middleware
      /// </summary>
      /// <param name="application">Builder for 
      /// configuring an application's request pipeline</param>
      void Configure(IApplicationBuilder application);
   
      /// <summary>
      /// Gets order of this startup configuration implementation
      /// </summary>
      int Order { get; }
  }

Listagem 7. Interface INopStartup

Na Listagem 8 voc� pode adicionar e configurar seu middleware.


  /// <summary>
  /// Represents object for the configuring authentication middleware on application startup
  /// </summary>
  public class AuthenticationStartup : INopStartup
  {
      /// <summary>
      /// Add and configure any of the middleware
      /// </summary>
      /// <param name="services">Collection of service descriptors</param>
      /// <param name="configuration">Configuration of the application</param>
      public void ConfigureServices(IServiceCollection services, IConfiguration configuration)
      {
          //add data protection
          services.AddNopDataProtection();
   
          //add authentication
          services.AddNopAuthentication();
      }
   
      /// <summary>
      /// Configure the using of added middleware
      /// </summary>
      /// <param name="application">Builder for configuring an
      /// application's request pipeline</param>
      public void Configure(IApplicationBuilder application)
      {
          //configure authentication
          application.UseNopAuthentication();
      }
   
      /// <summary>
      /// Gets order of this startup configuration implementation
      /// </summary>
      public int Order => 500; //authentication should be loaded before MVC
  }

Listagem 8. Configurando middleware

Passo 7. Usando DI incorporado

Injeç�o de depend�ncia � uma das caracter�sticas chaves ao projetar um aplicativo ASP.NET Core. Voc� pode desenvolver aplicativos fracamente acoplados e mais test�veis, modulares e como resultado mais flex�veis na manuseabilidade: isso foi poss�vel seguindo o princ�pio da invers�o de depend�ncia. Para injetar a depend�ncia usamos cont�ineres IoC (invers�o de controle) e em ASP.NET Core esses cont�ineres s�o representados pela interface IServiceProvider. Os serviços s�o instalados no aplicativo no m�todo Startup.ConfigureServices(), como vemos na Listagem 9.

Qualquer serviço registrado pode ser configurado com tr�s escopos:

transient
scoped
singleton

  
services.AddDbContext<ApplicationDbContext>
(options =>
  options.UseSqlServer(Configuration.GetConnectionString("DefaultConnection")));
  services.AddSingleton<Isingleton,MySingleton>();

Listagem 9. Escopo do serviço

Passo 8. Usando projetos WebAPI compat�veis com shells (Shim)

Para simplificar a migraç�o de um WebAPI existente, faça o uso do pacote NuGet (Listagem 10) Microsoft.AspNetCore.Mvc.WebApiCompatShim, pois ele suporta os seguintes recursos compat�veis:

Adiciona tipos ApiController;
Ativa WebAPI estilo model binding;
Estende o model binding para que as aç�es do controlador possam aceitar par�metros do tipo HttpRequestMessage;
Adiciona formatadores de mensagens que permitem aç�es para retornar resultados do tipo HttpResponseMessage.


  services.AddMvc().AddWebApiConventions();
   
  routes.MapWebApiRoute(name: "DefaultApi",
        template: "api//{id?}"
  );

Listagem 10. Uso do pacote NuGet

Passo 9. Convers�o das Configuraç�es da Aplicaç�o

Algumas configuraç�es foram salvas anteriormente no arquivo web.config. Agora existe uma nova abordagem, baseada nos pares de chave-valores definidos pelos provedores de configuraç�o. Este � o m�todo recomendado pelo ASP.NET Core, e o NopCommerce usa o arquivo appsettings.json.

Voc� tamb�m pode usar o pacote NuGet System.Configuration.ConfigurationManager, mas se por alguma raz�o quiser continuar usando o *.config a aplicaç�o n�o pode rodar na plataforma Unix, mas somente no IIS.

Se voc� quer usar o provedor de configuraç�es de armazenamento de chaves do Azure, ent�o precisar� referenciar a migraç�o de conte�do para o Azure de chaves-valores, mas o projeto n�o cont�m essa tarefa.

Passo 10. Convers�o conte�do est�tico para wwwroot

Para servir conte�do est�tico, especifique para o web host a raiz (root) como sendo o diret�rio corrente, conforme Figura 4. O default � wwwroot. Voc� pode configurar sua pasta para armazenamento de arquivos est�ticos atrav�s da configuraç�o do middleware.

Figura 4. Pasta raiz

Passo 11. Convers�o do Entity Framework para EF Core

Se o projeto usa algumas caracter�sticas do Entity Framework 6 que n�o s�o suportadas no EF Core, faz sentido rodar a aplicaç�o no .NET Framework. Nesse caso, rejeitaremos as caracter�sticas multiplataforma e o aplicativo ser� executado apenas no IIS.

A seguir est�o as principais alteraç�es a serem consideradas e apresentadas na Listagem 11:

Trocar o namespace System.Data.Entity por Microsoft.EntityFrameworkCore;
A assinatura do construtor DbContext foi alterada: agora deve-se injetar DbContextOptions;
O m�todo HasDatabaseGeneratedOption(DatabaseGeneratedOption.None) � trocado por ValueGeneratedNever();
O m�todo WillCascadeOnDelete(false) foi trocado por OnDelete (DeleteBehavior.Restrict);
O m�todo OnModelCreating(DbModelBuilder modelBuilder) � trocado por OnModelCreating(ModelBuilder modelBuilder);
O m�todo HasOptional n�o est� mais dispon�vel;
A configuraç�o do objeto foi alterada e agora o OnModelCreating est� sendo usado, pois o EntityTypeConfiguration n�o est� mais dispon�vel;
J� o atributo ComplexType n�o est� mais dispon�vel;
A interface IDbSet foi trocada por DbSet;
O suporte a tipos complexos ComplexType apareceu no EF Core 2 com o tipo Owned Entity, e tabelas sem chave prim�ria com o QueryType no EF Core 2.1;
As Chaves externas no EF Core geram Shadow Properties usando a template [Entity]Id, diferentemente do EF6, que usa a template [Entity]_Id. Portanto, adicione chaves externas como uma propriedade regular a entidade.
Para suporte a DI no DbContext, configure seu DbContex em ConfigureServices.


  /// <summary>
  /// Register base object context
  /// </summary>
  /// <param name="services">Collection of service descriptors</param>
  public static void AddNopObjectContext(this IServiceCollection services)
  {
      services.AddDbContextPool<NopObjectContext>(optionsBuilder =>
      {
          optionsBuilder.UseSqlServerWithLazyLoading(services);
      });
  }
   
  /// <summary>
  /// SQL Server specific extension method for 
  /// Microsoft.EntityFrameworkCore.DbContextOptionsBuilder
  /// </summary>
  /// <param name="optionsBuilder">Database context options builder</param>
  /// <param name="services">Collection of service descriptors</param>
  public static void UseSqlServerWithLazyLoading(this 
   DbContextOptionsBuilder optionsBuilder, IServiceCollection services)
  {
      var nopConfig = services.BuildServiceProvider().GetRequiredService<NopConfig>();
   
      var dataSettings = DataSettingsManager.LoadSettings();
      if (!dataSettings?.IsValid ?? true)
          return;
   
      var dbContextOptionsBuilder = optionsBuilder.UseLazyLoadingProxies();
   
      if (nopConfig.UseRowNumberForPaging)
          dbContextOptionsBuilder.UseSqlServer(dataSettings.DataConnectionString, 
          option => option.UseRowNumberForPaging());
      else
          dbContextOptionsBuilder.UseSqlServer(dataSettings.DataConnectionString);
  }

Listagem 11. Convers�o do Entity Framework para EF Core

Para verificar se o EF Core gera uma estrutura de banco de dados semelhante ao Entity Framework quando migrar, utilize a ferramenta SQL Compare.

Passo 12. Removendo todas as refer�ncias HttpContext, substituindo classes obsoletas e alterando o namespace

Durante o projeto de migraç�o voc� encontrar� muitas classes que dever�o ser renomeadas ou removidas e agora � necess�rio cumprir com os novos requisitos. Por isso, aqui est� uma lista das principais alteraç�es:

HttpPostedFileBase 🡪 FormFile
Acesso HttpContext pode ser acessado via IHttpContextAccessor
HtmlHelper 🡪 HtmlHelper
ActionResult 🡪 ActionResult
HttpUtility 🡪 WebUtility
ISession em vez de HttpSessionStateBase, acess�vel em HttpContext.Session de Microsoft.AspNetCore.Http
Request.Cookies retorna IRequestCookieCollection: IEnumerable <KeyValuePair<string, string> >;
Em vez de HttpCookie usamos KeyValuePair <string, string> de Microsoft.AspNetCore.Http.

Trocas no namespace:

SelectList 🡪 Microsoft.AspNetCore.Mvc.Rendering
UrlHelper 🡪 WebUtitlity
MimeMapping 🡪 FileExtensionContentTypeProvider
MvcHtmlString 🡪 IHtmlString and HtmlString
ModelState, ModelStateDictionary, ModelError 🡪 Microsoft.AspNetCore.Mvc.ModelBinding
FormCollection 🡪 IFormCollection
Request.Url.Scheme 🡪 this.Url.ActionContext.HttpContext.Request.Scheme

Outros:

MvcHtmlString.IsNullOrEmpty(IHtmlString) 🡪 String.IsNullOrEmpty(variable.ToHtmlString());
[ValidateInput (false)] � n�o existe mais e n�o � mais necess�rio;
HttpUnauthorizedResult 🡪 UnauthorizedResult;
[AllowHtml] � diretiva n�o existe mais e n�o � necess�ria;
TagBuilder.SetInnerText � um m�todo trocado por InnerHtml.AppendHtml;
JsonRequestBehavior.AllowGet quando retorna JSON n�o � mais necess�rio;
HttpUtility.JavaScriptStringEncode. JavaScriptEncoder.Default.Encode Request.RawUrl. Request.Path + Request.QueryString deve ser conectado separadamente;
AllowHtmlAttribute � uma classe que n�o existe mais;
XmlDownloadResult pode usar apenas return File(Encoding.UTF8.GetBytes (xml), "application / xml", "filename.xml");
A diretiva [ValidateInput(false)] n�o existe mais e n�o � necess�rio.

Passo 13. Atualizaç�o de autenticaç�o e autorizaç�o

Como j� foi mencionado acima, o projeto nopCommerce n�o tem o sistema de autenticaç�o embutido, pois � implementado em uma camada de middleware separado. No entanto, o ASP.NET Core possui seu pr�prio sistema para fornecer credenciais. Voc� pode ver a documentaç�o para saber mais detalhes.

Em relaç�o a proteç�o de dados, o nopCommerce n�o usa mais MachineKey. Em vez disso, usamos o recurso interno de proteç�o de dados. Por padr�o, as chaves s�o geradas quando o aplicativo � iniciado. O armazenamento de dados pode ser:

Sistema de arquivos � armazenamento de chaves baseado em arquivos;
Armazenamento Azure � chaves de proteç�o de dados no armazenamento de objetos BLOB Azure;
Redis � chaves de proteç�o de dados no cache Redis;
Registry � usado se a aplicaç�o n�o tem acesso ao sistema de arquivos;
EF Core � chaves s�o armazenadas no banco de dados.

Caso os provedores internos n�o sejam adequados pode-se especificar seu pr�prio provedor de armazenamento de chaves criando um IXmlRepository.

Passo 14. Atualizaç�o JS/CSS

A maneira de usar os recursos est�ticos mudou e agora todos eles devem ser armazenados na pasta da raiz do projeto wwwroot, a menos que outras configuraç�es sejam feitas.

Ao usar blocos internos de JavaScript, recomendamos mov�-los para o final da p�gina. Apenas use o atributo asp-location = "Footer" para suas tags <script>. As mesmas regras se aplicam aos arquivos .js.

Use a extens�o BundlerMinifier como substituto para a System.Web.Optimization, pois isso permitir� o empacotamento e a minificaç�o do JavaScript e CSS durante a criaç�o do projeto (conforme a documentaç�o).

Passo 15. Convers�o de exibiç�es

Primeiro, Child Actions n�o s�o mais usadas, j� que o ASP.NET Core sugere o uso de uma nova ferramenta de alto desempenho. Os ViewComponents s�o chamados de forma ass�ncrona.

Veja na Listagem 12 como obter uma string da ViewComponent.


  /// <summary>
 /// Render component to string
 /// </summary>
 /// <param name="componentName">Component name</param>
 /// <param name="arguments">Arguments</param>
 /// <returns>Result</returns>
 protected virtual string RenderViewComponentToString
 (string componentName, object arguments = null)
 {   
     if (string.IsNullOrEmpty(componentName))
         throw new ArgumentNullException(nameof(componentName));
 
     var actionContextAccessor = HttpContext.RequestServices.GetService(typeof
     (IActionContextAccessor)) as IActionContextAccessor;
     if (actionContextAccessor == null)
         throw new Exception("IActionContextAccessor cannot be resolved");
 
     var context = actionContextAccessor.ActionContext;
 
     var viewComponentResult = ViewComponent(componentName, arguments);
 
     var viewData = ViewData;
     if (viewData == null)
     {
         throw new NotImplementedException();       
     }
 
     var tempData = TempData;
     if (tempData == null)
     {
         throw new NotImplementedException();       
     }
 
     using (var writer = new StringWriter())
     {
         var viewContext = new ViewContext(
             context,
             NullView.Instance,
             viewData,
             tempData,
             writer,
             new HtmlHelperOptions());
 
         // IViewComponentHelper is stateful, we want to make sure to 
         // retrieve it every time we need it.
         var viewComponentHelper = 
         context.HttpContext.RequestServices.GetRequiredService<
         IViewComponentHelper>();
         (viewComponentHelper as IViewContextAware)?.Contextualize(viewContext);
 
         var result = viewComponentResult.ViewComponentType == null ? 
             viewComponentHelper.InvokeAsync(viewComponentResult.ViewComponentName,
             viewComponentResult.Arguments):
             viewComponentHelper.InvokeAsync(viewComponentResult.ViewComponentType, 
             viewComponentResult.Arguments);
 
         result.Result.WriteTo(writer, HtmlEncoder.Default);
         return writer.ToString();
     }
 }

Listagem 12. Obtendo uma string com a ViewComponent

Perceba que n�o � mais necess�rio usar o HtmlHelper, pois o ASP.NET Core inclui muito auxiliares que s�o as auxiliares de Tag. Quando o aplicativo est� em execuç�o, o mecanismo Razor as processa no servidor e converte-as em elementos HTML padr�o. Isso torna o desenvolvimento de aplicativos muito mais f�cil, mas � claro que voc� pode implementar seus pr�prios auxiliares de tags.

Inicializamos o uso de injeç�o de depend�ncia nas visualizaç�es ao inv�s de habilitar configuraç�es e serviços usando o EngineContext. Com isso, os principais pontos a serem considerados na convers�o s�o:

Converter Views/web.config para Views/_ViewImports.cshtml para importar namespaces e injetar depend�ncia. Este arquivo n�o suporta outros recursos do Razor, como definiç�es de funç�o e seç�o.
Converta namespaces.add to @using
Portar qualquer configuraç�o para a configuraç�o principal do aplicativo.
Scripts.Render e Styles.Render n�o existem, ent�o os substitua por links para dados de sa�da Libman ou BundlerMinifier.

Conclus�o

O processo de migraç�o de um grande aplicativo Web � uma tarefa muito demorada que, como regra, n�o pode ser realizada sem as �armadilhas�. Podemos planejar migrar para uma nova estrutura, mas quando a sua primeira vers�o est�vel ficou pronta n�o foi poss�vel lanç�-la imediatamente pois haviam alguns recursos cr�ticos que n�o tinham sido transferidos para o .NET Core. Em particular, os relacionados ao Entity Framework.

Portanto, foi necess�rio fazer o lançamento com uma abordagem mista, com a arquitetura do .NET Core e as depend�ncias do .NET Framework, que por si s� formam uma soluç�o exclusiva. Ser o primeiro n�o � f�cil e a certeza de que foi a escolha certa, com o apoio da nossa enorme comunidade.

O projeto foi totalmente adaptado ap�s o lançamento do .NET Core 2.1, tendo nessa �poca uma soluç�o est�vel j� trabalhando na nova arquitetura. Restou apenas substituir alguns pacotes e reescrever o trabalho com o EF Core. Assim, transcorreram v�rios meses e duas vers�es lançadas para migrar completamente para a nova estrutura.

Pode-se dizer com confiança que este � o primeiro grande projeto a realizar essa migraç�o. Neste guia foi mostrado todo o processo de migraç�o de forma estruturada e descrevemos v�rios gargalos para que outros desenvolvedores possam confiar nesse material e seguir o roteiro ao resolver a mesma tarefa.