ASP.NET Core hostolása Windows-szolgáltatásban

A ASP.NET Core-alkalmazások windowsos Windows Service- IIS használata nélkül üzemeltethetők. Windows-szolgáltatásként üzemeltetve az alkalmazás automatikusan elindul a kiszolgáló újraindítása után.

Előfeltételek

• ASP.NET Core SDK 7.0-s vagy újabb verziója
• PowerShell 6.2 vagy újabb

Munkás szolgáltatás sablon

A ASP.NET Core Worker Service-sablon kiindulópontként szolgál a hosszú ideig futó szolgáltatásalkalmazások írásához. A sablon használata Windows Service-alkalmazás alapjaként:

1. Hozzon létre egy feldolgozószolgáltatás-alkalmazást a .NET Core-sablonból.
2. Telepítse a NuGet-csomagot Microsoft.Extensions.Hosting.WindowsServices.
3. Az alkalmazáskonfigurációs szakaszban található útmutatást követve frissítse a Worker Service alkalmazást, hogy windowsos szolgáltatásként fusson.

Visual Studio

1. Hozzon létre egy új projektet.
2. Válassza a Munkás szolgáltatáslehetőséget. Válassza a Következőt.
3. Adjon meg egy projektnevet a Projektnév mezőben, vagy fogadja el az alapértelmezett projektnevet. Válassza létrehozása lehetőséget.
4. Az Új feldolgozói szolgáltatás létrehozása párbeszédpanelen válassza a létrehozása lehetőséget.

.NET CLI

Használja a Worker Service (worker) sablont a dotnet new parancsával parancssori ablakból. Az alábbi példában egy Worker szolgáltatás alkalmazás jön létre ContosoWorkernéven. A parancs végrehajtásakor a ContosoWorker alkalmazás mappája automatikusan létrejön.

dotnet new worker -o ContosoWorker

Alkalmazáskonfiguráció

Frissítse a Program.cs fájlt úgy, hogy hívja meg a AddWindowsServicefüggvényt. Ha az alkalmazás Windows-szolgáltatásként fut, AddWindowsService:

• A gazdagép élettartamát WindowsServiceLifetimeértékre állítja.
• A tartalomgyökerét az AppContext.BaseDirectoryértékre állítja be. További információért lásd a Aktuális könyvtár és tartalomgyökér részt.
• Engedélyezi a naplózást az eseménynaplóba:
  • A rendszer az alkalmazásnevet használja az alapértelmezett forrásnévként.
  • Az alapértelmezett naplószint Figyelmeztetési vagy magasabb egy ASP.NET Core-sablonon alapuló alkalmazáshoz, amely meghívja CreateDefaultBuilder a gazdagép létrehozásához.
  • Felülbírálja az alapértelmezett naplószintet a Logging:EventLog:LogLevel:Default kulccsal a appsettings.json/appsettings.{Environment}.json vagy más konfigurációs szolgáltatóban.
  • Csak a rendszergazdák hozhatnak létre új eseményforrásokat. Ha egy eseményforrás nem hozható létre az alkalmazás nevével, a rendszer figyelmeztetést naplóz a alkalmazás forráshoz, és az eseménynaplók le vannak tiltva.

Vegye figyelembe a következő ServiceA osztályt:

namespace SampleApp.Services;

public class ServiceA : BackgroundService
{
    public ServiceA(ILoggerFactory loggerFactory)
    {
        Logger = loggerFactory.CreateLogger<ServiceA>();
    }

    public ILogger Logger { get; }

    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
    {
        Logger.LogInformation("ServiceA is starting.");

        stoppingToken.Register(() => Logger.LogInformation("ServiceA is stopping."));

        while (!stoppingToken.IsCancellationRequested)
        {
            Logger.LogInformation("ServiceA is doing background work.");

            await Task.Delay(TimeSpan.FromSeconds(5), stoppingToken);
        }

        Logger.LogInformation("ServiceA has stopped.");
    }
}

Az alábbi Program.cs meghívja AddHostedService, hogy regisztrálja ServiceA:

using SampleApp.Services;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

builder.Services.AddWindowsService();
builder.Services.AddHostedService<ServiceA>();

var app = builder.Build();

app.MapRazorPages();

app.Run();

A témakörhöz a következő mintaalkalmazások kapcsolódnak:

• Háttérmunkaszolgáltatás-minta: A Feldolgozói szolgáltatás sablonon alapuló, alapuló nem webalkalmazás-minta, amely üzemeltetett szolgáltatásokat használ háttérfeladatokhoz.
• Webalkalmazás-szolgáltatás minta: Razor Pages webalkalmazásminta, amely Windows-szolgáltatásként működik, üzemeltetett szolgáltatásokkal, háttérfeladatokhoz.

Az MVC-vel kapcsolatos útmutatásért tekintse meg ASP.NET Core MVC és Migrálás ASP.NET Core 2.2-ről 3.0-racímű cikkeket.

Üzembe helyezés típusa

Az üzembe helyezési forgatókönyvekkel kapcsolatos információkért és tanácsokért tekintse meg .NET Core-alkalmazások üzembe helyezési.

SDK

A Razor Pages vagy MVC keretrendszereket használó webalkalmazás-alapú szolgáltatások esetében adja meg a webes SDK-t a projektfájlban:

<Project Sdk="Microsoft.NET.Sdk.Web">

Ha a szolgáltatás csak háttérfeladatokat hajt végre (például üzemeltetett szolgáltatások), adja meg a Feldolgozó SDK-t a projektfájlban:

<Project Sdk="Microsoft.NET.Sdk.Worker">

Keretrendszerfüggő üzembe helyezés (FDD)

A keretrendszerfüggő üzembe helyezés (FDD) a .NET Core megosztott rendszerszintű verziójának jelenlétére támaszkodik a célrendszeren. Amikor az FDD-forgatókönyvet, azaz a keretrendszerfüggő végrehajtást, a jelen cikkben ismertetett útmutatást követve fogadják el, az SDK egy végrehajtható fájlt (.exe) hoz létre, amelyet keretrendszerfüggő végrehajthatóként neveznek.

A Web SDKhasználata esetén a Windows Services-alkalmazások esetében szükségtelen egy web.config fájl, amely általában az ASP.NET Core-alkalmazások közzétételekor jön létre. A web.config fájl létrehozásának letiltásához adja hozzá a <IsTransformWebConfigDisabled> tulajdonságot a trueértékre állítva.

<PropertyGroup>
  <TargetFramework>net7.0</TargetFramework>
  <IsTransformWebConfigDisabled>true</IsTransformWebConfigDisabled>
</PropertyGroup>

Önálló üzembe helyezés (SCD)

Az önálló üzembe helyezés (SCD) nem támaszkodik egy megosztott keretrendszer jelenlétére a gazdarendszeren. A futtatókörnyezet és az alkalmazás függőségei az alkalmazással együtt vannak üzembe helyezve.

A , amely tartalmazza a célkeretrendszert, tartalmaz egy Windows <PropertyGroup>.

<RuntimeIdentifier>win-x64</RuntimeIdentifier>

Több RID-hez való közzététel:

• Adja meg az RIDs-t pontosvesszővel elválasztott listában.
• Használja a <RuntimeIdentifiers> (többes szám) tulajdonságnevet.

További információ: .NET Core RID-katalógus.

Szolgáltatásfelhasználói fiók

Ha felhasználói fiókot szeretne létrehozni egy szolgáltatáshoz, használja a New-LocalUser parancsmagot egy rendszergazdai PowerShell 6-parancshéjból.

Windows 10 2018. októberi frissítés (1809-es verzió/10.0.17763-os build) vagy újabb verzió:

New-LocalUser -Name {SERVICE NAME}

Windows operációs rendszeren a 2018. október 10-i frissítésnél korábbi (1809-es verzió/10.0.17763-os build):

powershell -Command "New-LocalUser -Name {SERVICE NAME}"

Ha a rendszer kéri, adjon meg egy erős jelszót.

Ha a -AccountExpires paramétert nem adja meg a New-LocalUser parancsmagnak lejárati DateTime, a fiók nem jár le.

További információ: Microsoft.PowerShell.LocalAccounts és Szolgáltatás felhasználói fiókok.

Az Active Directory használatakor a felhasználók felügyeletének másik módszere a felügyelt szolgáltatásfiókok használata. További információ: csoport által felügyelt szolgáltatásfiókok áttekintése.

Szolgáltatásként való bejelentkezési jogok

A szolgáltatásként való bejelentkezéshez jogosultságok létrehozása egy szolgáltatásfelhasználói fiókhoz:

1. Nyissa meg a Helyi biztonsági házirend szerkesztőt secpol.mscfuttatásával.
2. Bontsa ki az Helyi házirendek csomópontot, és válassza meg a Felhasználói jogok hozzárendeléselehetőséget.
3. Nyissa meg a Szolgáltatásként bejelentkezés házirendet.
4. Válassza az Felhasználó vagy csoport hozzáadásalehetőséget.
5. Adja meg az objektum nevét (felhasználói fiókot) az alábbi módszerek valamelyikével:
   1. Írja be a felhasználói fiókot ({DOMAIN OR COMPUTER NAME\USER}) az objektumnév mezőbe, és válassza az OK lehetőséget a felhasználó szabályzathoz való hozzáadásához.
   2. Válassza Speciális. Válassza Keresés Most. Válassza ki a felhasználói fiókot a listából. Válassza OKlehetőséget. Válassza OK lehetőséget, ha a felhasználót hozzá szeretné adni a szabályzathoz.
6. A módosítások elfogadásához válassza OK vagy Alkalmaz lehetőséget.

A Windows szolgáltatás létrehozása és kezelése

Szolgáltatás létrehozása

Szolgáltatás regisztrálása PowerShell-parancsokkal. Egy felügyeleti PowerShell 6-parancshéjból hajtsa végre a következő parancsokat:

$acl = Get-Acl "{EXE PATH}"
$aclRuleArgs = "{DOMAIN OR COMPUTER NAME\USER}", "Read,Write,ReadAndExecute", "ContainerInherit,ObjectInherit", "None", "Allow"
$accessRule = New-Object System.Security.AccessControl.FileSystemAccessRule($aclRuleArgs)
$acl.SetAccessRule($accessRule)
$acl | Set-Acl "{EXE PATH}"

New-Service -Name {SERVICE NAME} -BinaryPathName "{EXE FILE PATH} --contentRoot {EXE FOLDER PATH}" -Credential "{DOMAIN OR COMPUTER NAME\USER}" -Description "{DESCRIPTION}" -DisplayName "{DISPLAY NAME}" -StartupType Automatic

• {EXE PATH}: Az alkalmazás futtatható útvonala a gazdagépen (például d:\myservice). Ne adja meg az alkalmazás végrehajtható fájlnevét az elérési úton. Nincs szükség záró perjelre.
• {DOMAIN OR COMPUTER NAME\USER}: Szolgáltatásfelhasználói fiók (például Contoso\ServiceUser).
• {SERVICE NAME}: Szolgáltatásnév (például MyService).
• {EXE FILE PATH}: Az alkalmazás teljes végrehajtható elérési útja (például d:\myservice\myservice.exe). Adja meg a végrehajtható fájl nevét a kiterjesztéssel.
• {EXE FOLDER PATH}: Az alkalmazás teljes végrehajtható mappa elérési útja (például d:\myservice).
• {DESCRIPTION}: Szolgáltatás leírása (például My sample service).
• {DISPLAY NAME}: Szolgáltatásmegjelenítés neve (például My Service).

Szolgáltatás indítása

Szolgáltatás indítása a következő PowerShell 6-paranccsal:

Start-Service -Name {SERVICE NAME}

A parancs néhány másodpercet vesz igénybe a szolgáltatás elindításához.

Szolgáltatás állapotának meghatározása

Egy szolgáltatás állapotának ellenőrzéséhez használja a következő PowerShell 6-parancsot:

Get-Service -Name {SERVICE NAME}

Az állapot a következő értékek egyikeként lesz jelentve:

• Starting
• Running
• Stopping
• Stopped

Szolgáltatás leállítása

Szolgáltatás leállítása a következő PowerShell 6 paranccsal:

Stop-Service -Name {SERVICE NAME}

Szolgáltatás eltávolítása

A szolgáltatás leállításának rövid késleltetése után távolítsa el a következő PowerShell 6-parancsot tartalmazó szolgáltatást:

Remove-Service -Name {SERVICE NAME}

Proxykiszolgáló és terheléselosztó forgatókönyvek

Az internetről vagy a vállalati hálózatról érkező kérésekkel kommunikáló, proxy vagy terheléselosztó mögött található szolgáltatások további konfigurációt igényelhetnek. További információ: A ASP.NET Core konfigurálása proxykiszolgálókkal és terheléselosztókkal.

Végpontok konfigurálása

Alapértelmezés szerint az ASP.NET Core a http://localhost:5000értékhez köt. Konfigurálja az URL-címet és a portot a ASPNETCORE_URLS környezeti változó beállításával.

További URL- és portkonfigurációs megközelítésekért tekintse meg a kiszolgáló vonatkozó cikkét:

• Végpontok konfigurálása az ASP.NET Core Kestrel webkiszolgálóhoz
• HTTP.sys webszerver implementálása ASP.NET Core-ban

Az előző útmutató a HTTPS-végpontok támogatását ismerteti. Konfigurálja például az alkalmazást HTTPS-hez, amikor a hitelesítést Windows-szolgáltatással használják.

Jegyzet

Az ASP.NET Core HTTPS fejlesztési tanúsítvány használata szolgáltatásvégpont védelmére nem támogatott.

Aktuális könyvtár és tartalomgyökér

A Windows-szolgáltatás GetCurrentDirectory hívásával visszaadott aktuális munkakönyvtár a C:\WINDOWS\system32 mappa. A system32 mappa nem megfelelő hely a szolgáltatás fájljainak tárolására (például beállításfájlok). Az alábbi módszerek egyikével karbantarthatja és elérheti a szolgáltatás eszköz- és beállításfájljait.

A ContentRootPath vagy a ContentRootFileProvider használata

Az alkalmazás erőforrásainak megkereséséhez használja IHostEnvironment.ContentRootPath vagy ContentRootFileProvider.

Amikor az alkalmazás szolgáltatásként fut, a UseWindowsService beállítja a ContentRootPath-et az AppContext.BaseDirectory-ra.

Az alkalmazás alapértelmezett beállításfájljai (appsettings.json és appsettings.{Environment}.json) az alkalmazás tartalomgyökeréből töltődnek be úgy, hogy meghívják CreateDefaultBuildert a gazdagépépítési.

Az ConfigureAppConfigurationfejlesztői kódjával betöltött egyéb beállításfájlok esetében nincs szükség SetBasePathhívására. Az alábbi példában a custom_settings.json fájl az alkalmazás tartalomgyökerében található, és anélkül van betöltve, hogy explicit módon beállítanál egy alap elérési utat:

public class Program
{
    public static void Main(string[] args)
    {
        CreateHostBuilder(args).Build().Run();
    }

    public static IHostBuilder CreateHostBuilder(string[] args) =>
        Host.CreateDefaultBuilder(args)
            .UseWindowsService()
            .ConfigureAppConfiguration((hostingContext, config) =>
            {
                config.AddJsonFile("custom_settings.json");
            })
            .ConfigureServices((hostContext, services) =>
            {
                services.AddHostedService<Worker>();
            });
}

Ne próbálja meg GetCurrentDirectory erőforrás-elérési út beszerzését, mert egy Windows szolgáltatás alkalmazás a C:\WINDOWS\system32 mappát adja vissza aktuális könyvtárként.

A szolgáltatás fájljainak tárolása megfelelő helyen a lemezen

Adjon meg egy abszolút elérési utat SetBasePath a fájlokat tartalmazó mappához IConfigurationBuilder használatakor.

Hibaelhárítás

A Windows szolgáltatásalkalmazások hibaelhárításához lásd: ASP.NET Core projektek hibaelhárítása és hibakeresése.

Gyakori hibák

• A PowerShell egy régi vagy előzetes verziója van használatban.
• A regisztrált szolgáltatás nem használja az alkalmazás közzétett kimenetét a dotnet publish parancsból. A dotnet build parancs kimenete nem támogatott alkalmazások telepítéséhez. A közzétett eszközök az üzembe helyezés típusától függően az alábbi mappák egyikében találhatók:
  • bin/Release/{TARGET FRAMEWORK}/publish (FDD)
  • bin/Release/{TARGET FRAMEWORK}/{RUNTIME IDENTIFIER}/publish (SCD)
• A szolgáltatás nem futó állapotban van.
• Az alkalmazás által használt erőforrások elérési útjai (például tanúsítványok) helytelenek. A Windows-szolgáltatások alap elérési útja c:\Windows\System32.
• A felhasználó nem rendelkezik szolgáltatásként való bejelentkezéssel jogosultságokkal.
• A felhasználó jelszava lejárt vagy helytelenül lett átadva a New-Service PowerShell-parancs végrehajtásakor.
• Az alkalmazáshoz ASP.NET Core-hitelesítés szükséges, de nincs konfigurálva biztonságos kapcsolatokhoz (HTTPS).
• A kérelem URL-portja helytelen vagy nem megfelelően van konfigurálva az alkalmazásban.

Rendszer- és alkalmazásesemény-naplók

Hozzáférés a rendszer- és alkalmazásesemény-naplókhoz:

1. Nyissa meg a Start menüt, keresse meg Eseménynapló, és válassza ki az Eseménynapló alkalmazást.
2. Az Eseménynaplónézetben nyissa meg a Windows-naplók csomópontot.
3. Válassza Rendszer lehetőséget a Rendszeresemény-napló megnyitásához. Válassza Alkalmazás lehetőséget az alkalmazásesemény-napló megnyitásához.
4. Keresse meg a hibás alkalmazáshoz társított hibákat.

Az alkalmazás futtatása parancssorban

Számos indítási hiba nem hoz létre hasznos információkat az eseménynaplókban. A hibák okának megtalálásához futtassa az alkalmazást egy parancssorban az üzemeltetési rendszeren. Ha további részleteket szeretne naplózni az alkalmazásból, csökkentse a naplószintet, vagy futtassa az alkalmazást a fejlesztői környezetben.

Csomagcache-k törlése

A működő alkalmazások azonnal meghiúsulhatnak, miután frissítették a .NET Core SDK-t a fejlesztői gépen, vagy módosították az alkalmazás csomagverzióit. Bizonyos esetekben az inkognitó csomagok megszakíthatják az alkalmazásokat a nagyobb frissítések végrehajtásakor. A legtöbb ilyen probléma az alábbi utasítások követésével javítható:

1. Törölje a tároló, a és a obj, valamint a mappákat.

2. Törölje a csomaggyorsítótárakat a parancshéjban a dotnet nuget locals all --clear parancs végrehajtásával.

   A csomaggyorsítótárak törlése az nuget.exe eszközzel és a parancs nuget locals all -clearvégrehajtásával is elvégezhető. nuget.exe nincs csomagban a Windows asztali operációs rendszerrel, és külön kell beszerezni a NuGet webhelyről.

3. Állítsa vissza és építse újra a projektet.

4. Az alkalmazás ismételt üzembe helyezése előtt törölje a kiszolgáló üzembehelyezési mappájában lévő összes fájlt.

Lassú vagy nem válaszoló alkalmazás

Az memóriamásolat a rendszer memóriájának pillanatképe, amely segít meghatározni az alkalmazás összeomlásának, indítási hibájának, vagy az alkalmazás lassúságának okát.

Az alkalmazás összeomlik vagy kivételt tapasztal

Memóriakép beszerzése és elemzése a Windows hibajelentési (WER) rendszerből :

1. Hozzon létre egy mappát, amely az összeomlási memóriaképfájlokat tartalmazza a c:\dumpshelyen.

2. Futtassa az EnableDumps PowerShell-szkriptet az alkalmazás futtatható fájljának nevével:

   .\EnableDumps {APPLICATION EXE} c:\dumps
   

3. Futtassa az alkalmazást az összeomlást okozó feltételek között.

4. Az összeomlás után futtassa a DisableDumps PowerShell-szkriptet:

   .\DisableDumps {APPLICATION EXE}
   

Az alkalmazás összeomlása és a hibajegy-gyűjtés befejezése után az alkalmazás normál módon leállítható. A PowerShell-szkript úgy konfigurálja a WER-t, hogy alkalmazásonként legfeljebb öt hibakilépést gyűjtsön.

Figyelmeztetés

Az összeomlási memóriaképek jelentős lemezterületet foglalhatnak el (akár több gigabájtot is egyenként).

Az alkalmazás nem válaszol, indításkor meghiúsul, vagy normál módon fut

Ha egy alkalmazás nem válaszol, de nem omlik össze, indítás közben meghiúsul, vagy normál módon fut, olvassa el a User-Mode Memóriaképfájlok: A legjobb eszköz kiválasztása című részt a memóriakép létrehozására megfelelő eszköz kiválasztásához.

A dump elemzése

Egy dump többféle megközelítéssel is elemezhető. További információért lásd a(z) User-Mode memóriaképfájl-elemzését.

További erőforrások

• Mintakód megtekintése vagy letöltése (hogyan lehet letölteni)
• Kestrel végpontkonfigurációs (beleértve a HTTPS-konfigurációt és az SNI-támogatást)
• .NET Generic Host az ASP.NET Core-ban
• Alapvető projektek ASP.NET hibaelhárítása és hibakeresése