Uppgradera från ASP.NET Framework till ASP.NET Core
Varför uppgradera till den senaste .NET
ASP.NET Core är det moderna webbramverket för .NET. Även om ASP.NET Core har många likheter med ASP.NET i .NET Framework är det ett nytt ramverk som skrivs om helt. ASP.NET appar som uppdaterats till ASP.NET Core kan dra nytta av bättre prestanda och åtkomst till de senaste funktionerna och funktionerna för webbutveckling.
uppdateringsmetoder för ASP.NET Framework
De flesta icke-triviala ASP.NET Framework-appar bör överväga att använda den inkrementella uppgraderingsmetoden . Mer information finns i Inkrementell ASP.NET till ASP.NET Core-uppgradering.
För att uppgradera från ASP.NET MVC och Web API till ASP.NET Core MVC, se Lär dig uppgradera från ASP.NET MVC och Web API till ASP.NET Core MVC. För ASP.NET Framework Web Forms-appar, se Lär dig att uppgradera från ASP.NET Web Forms till ASP.NET Core.
Mönster för företagswebbappar
Vägledning om hur du skapar en tillförlitlig, säker, högpresterande, testbar och skalbar ASP.NET Core-app finns i Enterprise-webbappmönster. En komplett exempelwebbapp av produktionskvalitet som implementerar mönstren är tillgänglig.
URI-avkodningsskillnader mellan ASP.NET till ASP.NET Core
ASP.NET Core har följande URI-avkodningsskillnader med ASP.NET Framework:
ASCII | Kodade | ASP.NET Core | ASP.NET Framework |
---|---|---|---|
\ |
%5C |
\ |
/ |
/ |
%2F |
%2F |
/ |
Vid avkodning %2F
på ASP.NET Core:
- Hela sökvägen tas bort utom
%2F
eftersom konvertering till/
skulle ändra sökvägsstrukturen. Det kan inte avkodas förrän sökvägen är uppdelad i segment.
Om du vill generera värdet för HttpRequest.Url
använder du new Uri(this.AspNetCoreHttpRequest.GetEncodedUrl());
för att undvika Uri
feltolkning av värdena.
Migrera användarhemligheter från ASP.NET Framework till ASP.NET Core
Den här artikeln fungerar som referensguide för att migrera ASP.NET appar till ASP.NET Core.
Visual Studio har verktyg som hjälper dig att migrera ASP.NET appar till ASP.NET Core. Mer information finns i Migrera från ASP.NET till ASP.NET Core i Visual Studio.
.NET Upgrade Assistant är ett kommandoradsverktyg som kan hjälpa dig att migrera ASP.NET till ASP.NET Core. Mer information finns i Översikt över .NET Upgrade Assistant och Uppgradera en ASP.NET MVC-app till .NET 6 med .NET Upgrade Assistant.
Se e-boken Porting existing ASP.NET-appar till .NET Core för en omfattande portningsguide.
Förutsättningar
.NET Core SDK 2.2 eller senare
Målramverk
ASP.NET Core-projekt ger utvecklare flexibiliteten att rikta in sig på .NET Core, .NET Framework eller båda. Se Välja mellan .NET Core och .NET Framework för serverappar för att avgöra vilket målramverk som är lämpligast.
När du riktar in dig på .NET Framework måste projekt referera till enskilda NuGet-paket.
Med .NET Core kan du eliminera många explicita paketreferenser tack vare ASP.NET Core metapackage. Installera Microsoft.AspNetCore.App
metapackage i projektet:
<ItemGroup>
<PackageReference Include="Microsoft.AspNetCore.App" />
</ItemGroup>
När metapaketet används distribueras inga paket som refereras i metapaketet med appen. .NET Core Runtime Store innehåller dessa tillgångar och de är förkompilerade för att förbättra prestandan. Mer information finns i Microsoft.AspNetCore.App metapaket för ASP.NET Core.
Skillnader i projektstruktur
Filformatet .csproj
har förenklats i ASP.NET Core. Några viktiga ändringar är:
Det är inte nödvändigt att inkludera filer explicit för att de ska betraktas som en del av projektet. Detta minskar risken för XML-sammanslagningskonflikter när du arbetar med stora team.
Det finns inga GUID-baserade referenser till andra projekt, vilket förbättrar filläsbarheten.
Filen kan redigeras utan att ta bort den i Visual Studio:
]
Ersättning av Global.asax-fil
ASP.NET Core introducerade en ny mekanism för att starta en app. Startpunkten för ASP.NET program är filen Global.asax. Uppgifter som routningskonfiguration och filter- och områdesregistreringar hanteras i filen Global.asax.
public class MvcApplication : System.Web.HttpApplication
{
protected void Application_Start()
{
AreaRegistration.RegisterAllAreas();
FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);
RouteConfig.RegisterRoutes(RouteTable.Routes);
BundleConfig.RegisterBundles(BundleTable.Bundles);
}
}
Den här metoden kopplar ihop programmet och servern som det distribueras till på ett sätt som stör implementeringen. I ett försök att frikoppla introducerades OWIN- för att ge ett renare sätt att använda flera ramverk tillsammans. OWIN tillhandahåller en pipeline för att endast lägga till de moduler som behövs. Värdmiljön tar en startfunktion för att konfigurera tjänster och appens pipeline för begäranden.
Startup
registrerar en uppsättning mellanprogram med programmet. För varje begäran anropar programmet var och en av mellanprogramskomponenterna med huvudpekaren för en länkad lista till en befintlig uppsättning hanterare. Varje mellanprogramskomponent kan lägga till en eller flera hanterare i pipelinen för hantering av begäranden. Detta uppnås genom att returnera en referens till den hanterare som är den nya chefen för listan. Varje hanterare ansvarar för att komma ihåg och anropa nästa hanterare i listan. Med ASP.NET Core är startpunkten för ett program Startup
och du har inte längre något beroende av Global.asax. När du använder OWIN med .NET Framework använder du något som liknar följande som en pipeline:
using Owin;
using System.Web.Http;
namespace WebApi
{
// Note: By default all requests go through this OWIN pipeline. Alternatively you can turn this off by adding an appSetting owin:AutomaticAppStartup with value “false”.
// With this turned off you can still have OWIN apps listening on specific routes by adding routes in global.asax file using MapOwinPath or MapOwinRoute extensions on RouteTable.Routes
public class Startup
{
// Invoked once at startup to configure your application.
public void Configuration(IAppBuilder builder)
{
HttpConfiguration config = new HttpConfiguration();
config.Routes.MapHttpRoute("Default", "{controller}/{customerID}", new { controller = "Customer", customerID = RouteParameter.Optional });
config.Formatters.XmlFormatter.UseXmlSerializer = true;
config.Formatters.Remove(config.Formatters.JsonFormatter);
// config.Formatters.JsonFormatter.UseDataContractJsonSerializer = true;
builder.UseWebApi(config);
}
}
}
Detta konfigurerar dina standardrutter och använder som standard XmlSerialization istället för Json. Lägg till andra Mellanprogram i den här pipelinen efter behov (inläsning av tjänster, konfigurationsinställningar, statiska filer osv.).
ASP.NET Core använder en liknande metod, men förlitar sig inte på att OWIN hanterar posten. Det görs i stället via metoden Program.cs
Main
(liknar konsolprogram) och Startup
läses in där.
using Microsoft.AspNetCore;
using Microsoft.AspNetCore.Hosting;
namespace WebApplication2
{
public class Program
{
public static void Main(string[] args)
{
CreateWebHostBuilder(args).Build().Run();
}
public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>
WebHost.CreateDefaultBuilder(args)
.UseStartup<Startup>();
}
}
Startup
måste innehålla en Configure
-metod. I Configure
lägger du till nödvändiga mellanprogram i pipelinen. I följande exempel (från standardwebbplatsmallen) konfigurerar tilläggsmetoder pipelinen med stöd för:
- Felsidor
- HTTP Strikt transportsäkerhet
- HTTP-omdirigering till HTTPS
- ASP.NET Core MVC
public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
if (env.IsDevelopment())
{
app.UseDeveloperExceptionPage();
}
else
{
app.UseHsts();
}
app.UseHttpsRedirection();
app.UseMvc();
}
Värden och programmet har frikopplats, vilket ger flexibiliteten att flytta till en annan plattform i framtiden.
Obs
En mer ingående referens till ASP.NET Core Startup och Middleware finns i Startup i ASP.NET Core
Lagra konfigurationer
ASP.NET stöder lagring av inställningar. Den här inställningen används till exempel för att stödja miljön som programmen distribuerades till. En vanlig metod var att lagra alla anpassade nyckel/värde-par i avsnittet <appSettings>
i Web.config-filen:
<appSettings>
<add key="UserName" value="User" />
<add key="Password" value="Password" />
</appSettings>
Program läser de här inställningarna med hjälp av samlingen ConfigurationManager.AppSettings
i System.Configuration
namnområde:
string userName = System.Web.Configuration.ConfigurationManager.AppSettings["UserName"];
string password = System.Web.Configuration.ConfigurationManager.AppSettings["Password"];
ASP.NET Core kan lagra konfigurationsdata för programmet i valfri fil och läsa in dem som en del av mellanprogramsstarten. Standardfilen som används i projektmallarna är appsettings.json
:
{
"Logging": {
"IncludeScopes": false,
"LogLevel": {
"Default": "Debug",
"System": "Information",
"Microsoft": "Information"
}
},
"AppConfiguration": {
"UserName": "UserName",
"Password": "Password"
}
}
Den här filen läses in i en instans av IConfiguration
i ditt program i Startup.cs
:
public Startup(IConfiguration configuration)
{
Configuration = configuration;
}
public IConfiguration Configuration { get; }
Appen läser från Configuration
för att hämta inställningarna:
string userName = Configuration.GetSection("AppConfiguration")["UserName"];
string password = Configuration.GetSection("AppConfiguration")["Password"];
Det finns tillägg till den här metoden för att göra processen mer robust, till exempel att använda Dependency Injection (DI) för att läsa in en tjänst med dessa värden. DI-metoden ger en starkt typbaserad uppsättning konfigurationsobjekt.
// Assume AppConfiguration is a class representing a strongly-typed version of AppConfiguration section
services.Configure<AppConfiguration>(Configuration.GetSection("AppConfiguration"));
Not
En mer detaljerad referens till ASP.NET Core-konfiguration finns i Configuration i ASP.NET Core.
Inbyggd beroendeinjektion
Ett viktigt mål när du skapar stora, skalbara program är den lösa kopplingen mellan komponenter och tjänster. Dependency Injection är en populär teknik för att uppnå detta, och det är en inbyggd komponent i ASP.NET Core.
I ASP.NET appar förlitar sig utvecklare på ett bibliotek från tredje part för att implementera beroendeinmatning. Ett sådant bibliotek är Unity, som tillhandahålls av Microsoft Patterns & Practices.
Ett exempel på hur du konfigurerar beroendeinjektion med Unity är att implementera IDependencyResolver
som omsluter en UnityContainer
:
using Microsoft.Practices.Unity;
using System;
using System.Collections.Generic;
using System.Web.Http.Dependencies;
public class UnityResolver : IDependencyResolver
{
protected IUnityContainer container;
public UnityResolver(IUnityContainer container)
{
if (container == null)
{
throw new ArgumentNullException("container");
}
this.container = container;
}
public object GetService(Type serviceType)
{
try
{
return container.Resolve(serviceType);
}
catch (ResolutionFailedException)
{
return null;
}
}
public IEnumerable<object> GetServices(Type serviceType)
{
try
{
return container.ResolveAll(serviceType);
}
catch (ResolutionFailedException)
{
return new List<object>();
}
}
public IDependencyScope BeginScope()
{
var child = container.CreateChildContainer();
return new UnityResolver(child);
}
public void Dispose()
{
Dispose(true);
}
protected virtual void Dispose(bool disposing)
{
container.Dispose();
}
}
Skapa en instans av din UnityContainer
, registrera tjänsten och ange beroendelösaren för HttpConfiguration
till den nya instansen av UnityResolver
för containern:
public static void Register(HttpConfiguration config)
{
var container = new UnityContainer();
container.RegisterType<IProductRepository, ProductRepository>(new HierarchicalLifetimeManager());
config.DependencyResolver = new UnityResolver(container);
// Other Web API configuration not shown.
}
Mata in IProductRepository
där det behövs:
public class ProductsController : ApiController
{
private IProductRepository _repository;
public ProductsController(IProductRepository repository)
{
_repository = repository;
}
// Other controller methods not shown.
}
Eftersom beroendeinjektion är en del av ASP.NET Core kan du lägga till din tjänst i ConfigureServices
-metoden för Startup.cs
:
public void ConfigureServices(IServiceCollection services)
{
// Add application services.
services.AddTransient<IProductRepository, ProductRepository>();
}
Arkivet kan injiceras var som helst, som det var med Unity.
Not
Mer information om beroendeinmatning finns i Beroendeinmatning.
Hantera statiska filer
En viktig del av webbutvecklingen är möjligheten att hantera statiska tillgångar på klientsidan. De vanligaste exemplen på statiska filer är HTML, CSS, Javascript och bilder. Dessa filer måste sparas på den publicerade platsen för appen (eller CDN) och refereras till så att de kan läsas in vid en begäran. Den här processen har ändrats i ASP.NET Core.
I ASP.NET lagras statiska filer i olika kataloger och refereras i vyerna.
I ASP.NET Core lagras statiska filer i "webbroten" (<innehållsroten>/wwwroot), om inget annat har konfigurerats. Filerna läses in i förfrågningspipelinjen genom att anropa UseStaticFiles
-tilläggsmetoden från Startup.Configure
:
Obs
Om du riktar in dig på .NET Framework installerar du NuGet-paketet Microsoft.AspNetCore.StaticFiles
.
Till exempel är en bildtillgång i mappen wwwroot/images tillgänglig för webbläsaren på en plats som http://<app>/images/<imageFileName>
.
Anteckning
En mer detaljerad referens till hur du hanterar statiska filer i ASP.NET Core finns i Statiska filer.
Cookies med flera värden
cookies med flera värden stöds inte i ASP.NET Core. Skapa en cookie per värde.
Autentiseringscookies komprimeras inte i ASP.NET Core
Av säkerhetsskäl komprimeras inte autentiseringscookies i ASP.NET Core. När du använder cookies för autentisering bör utvecklare minimera antalet anspråk genom att inkludera endast den information om anspråk som är nödvändig för deras behov.
Partiell appöverföring
En metod för partiell appmigrering är att skapa ett IIS-underprogram och bara flytta vissa vägar från ASP.NET 4.x till ASP.NET Core samtidigt som appens URL-struktur bevaras. Tänk till exempel på appens URL-struktur från filen applicationHost.config:
<sites>
<site name="Default Web Site" id="1" serverAutoStart="true">
<application path="/">
<virtualDirectory path="/" physicalPath="D:\sites\MainSite\" />
</application>
<application path="/api" applicationPool="DefaultAppPool">
<virtualDirectory path="/" physicalPath="D:\sites\netcoreapi" />
</application>
<bindings>
<binding protocol="http" bindingInformation="*:80:" />
<binding protocol="https" bindingInformation="*:443:" sslFlags="0" />
</bindings>
</site>
...
</sites>
Katalogstruktur:
.
├── MainSite
│ ├── ...
│ └── Web.config
└── NetCoreApi
├── ...
└── web.config
[BIND] och indataformaterare
Tidigare versioner av ASP.NET använde attributet [Bind]
för att skydda mot överpubliceringsattacker.
Inmatningsformaterare fungerar annorlunda i ASP.NET Core. Attributet [Bind]
är inte längre utformat för att förhindra överpublicering när det används med indataformaterare för att parsa JSON eller XML. Dessa attribut påverkar modellbindningen när datakällan är formulärdata som publiceras med x-www-form-urlencoded
innehållstyp.
För appar som publicerar JSON-information till kontrollanter och använder JSON-indataformaterare för att parsa data rekommenderar vi att du ersätter attributet [Bind]
med en vymodell som matchar egenskaperna som definieras av attributet [Bind]
.
Ytterligare resurser
ASP.NET Core