Frissítés ASP.NET-keretrendszerről ASP.NET Core-ra
Miért érdemes frissíteni a legújabb .NET-re?
ASP.NET Core a .NET modern webes keretrendszere. Bár az ASP.NET Core sok hasonlóságot mutat az ASP.NET-tel a .NET-keretrendszerben, ez egy teljesen új keretrendszer, amelyet teljesen újraírtak. ASP.NET ASP.NET Core-ra frissített alkalmazások jobb teljesítményt és a legújabb webfejlesztési funkciókhoz és képességekhez való hozzáférést élvezhetik.
ASP.NET keretrendszer frissítési megközelítései
A legtöbb nem triviális ASP.NET-keretrendszeralkalmazásnak érdemes megfontolnia a növekményes frissítési megközelítést. További információkért lásd: ASP.NET fokozatos frissítése ASP.NET Core-ra.
ASP.NET MVC és a Web API alkalmazások esetén lásd: Tanulja meg, hogyan frissíthet az ASP.NET MVC-ről és a Web API-ról ASP.NET Core MVC-re. Az ASP.NET Framework Web Forms alkalmazásokról a ismeretekért, frissítése az ASP.NET Web Forms-ról az ASP.NET Core-ra aoldalon található.
Vállalati webalkalmazás-minták
A megbízható, biztonságos, teljesíthető, tesztelhető és méretezhető ASP.NET Core-alkalmazás létrehozásával kapcsolatos útmutatásért tekintse meg Vállalati webalkalmazás-mintákcímű témakört. Elérhető egy gyártási minőségű, példaként szolgáló webalkalmazás, amely megvalósítja a mintákat.
URI-dekódolási különbségek a ASP.NET és ASP.NET Core között
ASP.NET Core az alábbi URI-dekódolási különbségeket tartalmazza a ASP.NET-keretrendszerben:
ASCII | Kódolt | ASP.NET Core | ASP.NET keretrendszer |
---|---|---|---|
\ |
%5C |
\ |
/ |
/ |
%2F |
%2F |
/ |
A ASP.NET Core %2F
dekódolásakor:
- A teljes elérési út le lesz választva, kivéve
%2F
, mert a/
konvertálása megváltoztatná az elérési út szerkezetét. Nem dekódolható, amíg az elérési út szegmensekre nem oszlik.
A HttpRequest.Url
értékének létrehozásához használja a new Uri(this.AspNetCoreHttpRequest.GetEncodedUrl());
, hogy elkerülje Uri
az értékek félreértelmezését.
Felhasználói titkos kódok migrálása ASP.NET-keretrendszerből ASP.NET Core-ba
Lásd ezt a GitHub-hibajegyet.
Ez a cikk referencia-útmutatóként szolgál ASP.NET alkalmazások ASP.NET Core-ba való migrálásához.
A Visual Studio olyan eszközkészletekkel rendelkezik, amelyekkel ASP.NET alkalmazásokat migrálhat ASP.NET Core-ba. További információért lásd a "Áttelepítés ASP.NET-ről ASP.NET Core-ra a Visual Studio"-ban.
A .NET frissítési segéd egy parancssori eszköz, amely segíthet a ASP.NET ASP.NET Core-ba való migrálásában. További információ: .NET Frissítési segéd áttekintése, és Az ASP.NET MVC-alkalmazás frissítése .NET 6-ra a .NET Frissítési segéd.
Tekintse meg az ebookot, a "Meglévő ASP.NET-alkalmazások portolása a .NET Core-ra" című átfogó portolási útmutatóért.
Előfeltételek
Cél-keretrendszerek
ASP.NET Core-projektek rugalmasan célozzák meg a .NET Core-t, a .NET-keretrendszert vagy mindkettőt. Lásd A .NET Core és a .NET-keretrendszer közötti választás kiszolgálóalkalmazásokhoz annak meghatározásához, hogy melyik cél keretrendszer a legmegfelelőbb.
A .NET-keretrendszer megcélzásakor a projekteknek egyedi NuGet-csomagokra kell hivatkoznia.
A .NET Core célzása lehetővé teszi számos explicit csomaghivatkozás eltávolítását a ASP.NET Core metapackageköszönhetően. Telepítse a Microsoft.AspNetCore.App
metacsomagot a projektben:
<ItemGroup>
<PackageReference Include="Microsoft.AspNetCore.App" />
</ItemGroup>
A metacsomag használata esetén a metacsomagban hivatkozott csomagok nem lesznek üzembe helyezve az alkalmazással. A .NET Core Runtime Store tartalmazza ezeket az eszközöket, és előre összeállítottak a teljesítmény javítása érdekében. További részletekért lásd Microsoft.AspNetCore.App ASP.NET Core metapackage-ját.
Projektstruktúra eltérései
A .csproj
fájlformátum egyszerűbb lett ASP.NET Core-ban. Néhány figyelemre méltó változás:
A fájlok explicit felvétele nem szükséges ahhoz, hogy a projekt részét képezzék. Ez csökkenti az XML-egyesítési ütközések kockázatát, ha nagy csapatokon dolgozik.
Nincsenek GUID-alapú hivatkozások más projektekre, ami javítja a fájlok olvashatóságát.
A fájl a Visual Studióban betöltés nélkül szerkeszthető:
]
Global.asax fájl cseréje
ASP.NET Core új mechanizmust vezetett be az alkalmazások rendszerindításához. Az ASP.NET alkalmazások belépési pontja a Global.asax fájl. Az olyan feladatokat, mint az útvonalkonfiguráció, a szűrés és a területregisztráció a Global.asax fájlban kezeli.
public class MvcApplication : System.Web.HttpApplication
{
protected void Application_Start()
{
AreaRegistration.RegisterAllAreas();
FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);
RouteConfig.RegisterRoutes(RouteTable.Routes);
BundleConfig.RegisterBundles(BundleTable.Bundles);
}
}
Ez a megközelítés összekapcsolja az alkalmazást és a kiszolgálót, amelyre üzembe van helyezve, ami zavarja a megvalósítást. A szétválasztás érdekében bevezették OWIN, hogy tisztább módot biztosítsanak több keretrendszer együttes használatára. Az OWIN egy folyamatot biztosít, amely csak a szükséges modulokat adja hozzá. Az üzemeltetési környezet egy Indítási függvényt használ a szolgáltatások és az alkalmazás kérési folyamatának konfigurálásához.
Startup
regisztrál egy köztes szoftverkészletet az alkalmazással. Minden kéréshez az alkalmazás meghívja a köztes szoftver összetevőit egy csatolt lista fejmutatójával egy meglévő kezelőkészlethez. Minden köztes szoftverösszetevő hozzáadhat egy vagy több kezelőt a kérelemkezelési folyamathoz. Ezt úgy érheti el, hogy visszatér egy hivatkozással arra a kezelőre, amely most a lista új vezetője. Minden kezelő felelős a lista következő kezelőjének megjegyzéséért és meghívásáért. Az ASP.NET Core esetén az alkalmazás belépési pontja Startup
, és már nem függ a Global.asaxfájltól. Ha az OWIN-t .NET-keretrendszerrel használja, használja az alábbihoz hasonlót folyamatként:
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);
}
}
}
Ez konfigurálja az alapértelmezett útvonalakat, és alapértelmezésként az XmlSerialization-t részesíti előnyben a Jsonnal szemben. Szükség szerint adjon hozzá más Middleware-eket ehhez a folyamathoz (szolgáltatások betöltése, konfigurációs beállítások, statikus fájlok stb.).
ASP.NET Core hasonló megközelítést használ, de nem támaszkodik az OWIN-ra a bejegyzés kezeléséhez. Ehelyett ez a Program.cs
Main
metóduson keresztül történik (hasonlóan a konzolalkalmazásokhoz), és a Startup
ott töltődik be.
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
tartalmaznia kell egy Configure
metódust. A Configure
adja hozzá a szükséges köztes szoftvereket a folyamathoz. Az alábbi példában (az alapértelmezett webhelysablonból) a bővítménymetelyek konfigurálják a folyamatot a következő támogatással:
- Hibalapok
- HTTP szigorú átviteli biztonság
- HTTP-átirányítás HTTPS-hez
- ASP.NET Core MVC
public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
if (env.IsDevelopment())
{
app.UseDeveloperExceptionPage();
}
else
{
app.UseHsts();
}
app.UseHttpsRedirection();
app.UseMvc();
}
A gazdagépet és az alkalmazást leválasztották egymásról, ami rugalmasságot biztosít, hogy a jövőben egy másik platformra lehessen költözni.
Jegyzet
Az ASP.NET Core indítással és a Middleware-rel kapcsolatos részletesebb leírást a kezdése az ASP.NET Core-ban részben találja.
Tárolókonfigurációk
ASP.NET támogatja a beállítások tárolását. Ezeket a beállításokat használják például annak a környezetnek a támogatására, amelyre az alkalmazásokat üzembe helyezték. Gyakori eljárás volt az összes egyéni kulcs-érték pár tárolása a Web.config fájl <appSettings>
szakaszában:
<appSettings>
<add key="UserName" value="User" />
<add key="Password" value="Password" />
</appSettings>
Az alkalmazások ezeknek a beállításoknak a beolvasásához a System.Configuration
névtér ConfigurationManager.AppSettings
gyűjteményét használják.
string userName = System.Web.Configuration.ConfigurationManager.AppSettings["UserName"];
string password = System.Web.Configuration.ConfigurationManager.AppSettings["Password"];
ASP.NET Core bármilyen fájlban tárolhatja az alkalmazás konfigurációs adatait, és betöltheti őket a köztes szoftver rendszerindításának részeként. A projektsablonokban használt alapértelmezett fájl a appsettings.json
:
{
"Logging": {
"IncludeScopes": false,
"LogLevel": {
"Default": "Debug",
"System": "Information",
"Microsoft": "Information"
}
},
"AppConfiguration": {
"UserName": "UserName",
"Password": "Password"
}
}
A fájl betöltése az alkalmazásban lévő IConfiguration
egy példányába a Startup.cs
segítségével történik.
public Startup(IConfiguration configuration)
{
Configuration = configuration;
}
public IConfiguration Configuration { get; }
Az alkalmazás a Configuration
-ból olvas a beállítások beolvasásához.
string userName = Configuration.GetSection("AppConfiguration")["UserName"];
string password = Configuration.GetSection("AppConfiguration")["Password"];
Ennek a megközelítésnek a kiterjesztései lehetővé teszik, hogy a folyamat robusztusabbá váljon, például függőséginjektálás (DI) használatával betöltsön egy szolgáltatást ezekkel az értékekkel. A DI-módszer a konfigurációs objektumok erősen gépelt készletét biztosítja.
// Assume AppConfiguration is a class representing a strongly-typed version of AppConfiguration section
services.Configure<AppConfiguration>(Configuration.GetSection("AppConfiguration"));
Jegyzet
Az ASP.NET Core konfiguráció részletesebb áttekintéséhez lásd: ASP.NET Core konfiguráció.
Natív függőséginjektálás
Nagy, méretezhető alkalmazások létrehozásakor fontos cél az összetevők és szolgáltatások laza összekapcsolása. A függőség injektálás egy népszerű technika ennek eléréséhez, és az ASP.NET Core natív összetevője.
ASP.NET alkalmazásokban a fejlesztők egy külső kódtárra támaszkodnak a Függőséginjektálás implementálásához. Az egyik ilyen kódtár a Microsoft Patterns & Practices által biztosított Unity .
A Dependency Injection Unity segítségével történő beállítására egy példa a IDependencyResolver
megvalósítása, amely egy UnityContainer
köré épít:
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();
}
}
Hozza létre a UnityContainer
egy példányát, regisztrálja a szolgáltatást, és állítsa a HttpConfiguration
függőségfeloldóját a tároló új UnityResolver
-példányára:
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.
}
Injektálja a IProductRepository
-t, ahol szükséges.
public class ProductsController : ApiController
{
private IProductRepository _repository;
public ProductsController(IProductRepository repository)
{
_repository = repository;
}
// Other controller methods not shown.
}
Mivel a függőséginjektálás a ASP.NET Core része, a szolgáltatást a Startup.cs
ConfigureServices
metódusában is hozzáadhatja:
public void ConfigureServices(IServiceCollection services)
{
// Add application services.
services.AddTransient<IProductRepository, ProductRepository>();
}
Az adattár bárhol beszúrható, ahogy a Unityben is igaz volt.
Jegyzet
További információ a függőséginjektálásról: Függőséginjektálás.
Statikus fájlok kiszolgálása
A webfejlesztés fontos része a statikus, ügyféloldali eszközök kiszolgálásának képessége. A statikus fájlok leggyakoribb példái a HTML, a CSS, a Javascript és a képek. Ezeket a fájlokat az alkalmazás (vagy CDN) közzétett helyére kell menteni, és hivatkozni kell rájuk, hogy egy kérés betölthesse őket. Ez a folyamat ASP.NET Core-ban megváltozott.
Az ASP.NET-ben a statikus fájlokat különböző könyvtárakban tárolják, és a nézetekben hivatkoznak rájuk.
A ASP.NET Core-ban a statikus fájlok a "webes gyökérben" (<tartalomgyökerű>/wwwroot) vannak tárolva, hacsak nincs más konfigurálva. A fájlok a Startup.Configure
UseStaticFiles
bővítménymetódusának meghívásával töltődnek be a kérelem folyamatába:
Jegyzet
Ha a .NET-keretrendszert célozza, telepítse a NuGet-csomagot Microsoft.AspNetCore.StaticFiles
.
Például a wwwroot/images mappában lévő képegység egy olyan helyen érhető el a böngésző számára, mint például a http://<app>/images/<imageFileName>
.
Jegyzet
A statikus fájlok ASP.NET Core-ban való kiszolgálására vonatkozó részletesebb információkért lásd Statikus fájlokcímű témakört.
Többértékű cookie-k
Többértékű cookie-k nem támogatottak a ASP.NET Core-ban. Hozzon létre egy cookie értékenként.
A hitelesítési cookie-k nincsenek tömörítve a ASP.NET Core-ban
Biztonsági okokból a hitelesítési cookie-k nem tömöríthetők ASP.NET Core-ban. Hitelesítési cookie-k használata esetén a fejlesztőknek minimálisra kell csökkenteniük az igényeiknek megfelelő jogcíminformációk számát.
Részleges alkalmazásmigrálás
A részleges alkalmazásmigrálás egyik módszere egy IIS-alalkalmazás létrehozása, és csak bizonyos útvonalak áthelyezése ASP.NET 4.x-ről ASP.NET Core-ba az alkalmazás URL-struktúrájának megőrzése mellett. Vegyük például az alkalmazás URL-struktúráját a applicationHost.config fájlból:
<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>
Címtárstruktúra:
.
├── MainSite
│ ├── ...
│ └── Web.config
└── NetCoreApi
├── ...
└── web.config
[BIND] és bemeneti formázók
Az ASP.NET korábbi verzióiban a [Bind]
attribútumot használták a túltolásos támadások elleni védelem érdekében.
bemeneti formázók eltérően működnek ASP.NET Core-ban. A [Bind]
attribútum már nem úgy lett kialakítva, hogy megakadályozza a túlpostázást a JSON- vagy XML-elemzéshez használt bemeneti formázókkal. Ezek az attribútumok akkor befolyásolják a modellkötést, ha az adatok forrása a x-www-form-urlencoded
tartalomtípussal közzétett űrlapadatok.
Az olyan alkalmazások esetében, amelyek JSON-információkat adnak a vezérlőknek, és JSON bemeneti formátumolókkal elemzik az adatokat, javasoljuk, hogy cserélje le a [Bind]
attribútumot egy olyan nézetmodellre, amely megfelel a [Bind]
attribútum által meghatározott tulajdonságoknak.