Megosztás a következőn keresztül:


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

.NET Core SDK 2.2 vagy újabb

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ő:

    CSPROJ fájl szerkesztési lehetősége a helyi menüben a Visual Studio 2017-ben ]

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.csMain 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 Configureadja 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.cssegí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 UnityContainerkö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 UnityContaineregy 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.csConfigureServices 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.ConfigureUseStaticFiles 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.

További erőforrások