Host ASP.NET Core w usłudze Windows Service

Aplikacja ASP.NET Core może być hostowana w usłudze Windows jako Windows Service bez korzystania z usług IIS. W przypadku hostowania Windows Service aplikacja jest uruchamiana automatycznie po ponownym uruchomieniu serwera.

Wyświetl lub pobierz przykładowy kod (jak pobrać)

Wymagania wstępne

Szablon usługi procesu roboczego

Szablon ASP.NET Core Worker Service stanowi punkt wyjścia do pisania długotrwałych aplikacji usługi. Aby użyć szablonu jako podstawy dla aplikacji usługi Windows Service:

  1. Utwórz aplikację usługi Procesu roboczego na podstawie szablonu .NET Core.
  2. Postępuj zgodnie ze wskazówkami w sekcji Konfiguracja aplikacji, aby zaktualizować aplikację usługi procesu roboczego, aby można ją było uruchomić jako Windows Service.
  1. Tworzenie nowego projektu.
  2. Wybierz pozycję Usługa procesu roboczego. Wybierz opcję Dalej.
  3. Podaj nazwę projektu w polu Nazwa projektu lub zaakceptuj domyślną nazwę projektu. Wybierz przycisk Utwórz.
  4. W oknie dialogowym Tworzenie nowej usługi procesu roboczego wybierz pozycję Utwórz.

Konfiguracja aplikacji

Aplikacja wymaga odwołania do pakietu Dla Microsoft.Extensions.Hosting.WindowsServices.

IHostBuilder.UseWindowsService jest wywoływana podczas budowania hosta. Jeśli aplikacja jest uruchomiona jako Windows Service, metoda :

  • Ustawia okres istnienia hosta na WindowsServiceLifetime .
  • Ustawia katalog główny zawartości na AppContext.BaseDirectory. Aby uzyskać więcej informacji, zobacz sekcję Bieżący katalog i katalog główny zawartości.
  • Włącza rejestrowanie w dzienniku zdarzeń:
    • Nazwa aplikacji jest używana jako domyślna nazwa źródła.
    • Domyślny poziom dziennika to Ostrzeżenie lub wyższy dla aplikacji na podstawie ASP.NET Core, który wywołuje w celu CreateDefaultBuilder skompilowania hosta.
    • Zastąp domyślny poziom dziennika Logging:EventLog:LogLevel:Default kluczem w appsettings.json / pliku appsettings.{ Środowisko}.json lub inny dostawca konfiguracji.
    • Tylko administratorzy mogą tworzyć nowe źródła zdarzeń. Jeśli nie można utworzyć źródła zdarzeń przy użyciu nazwy aplikacji, w źródle aplikacji jest rejestrowane ostrzeżenie, a dzienniki zdarzeń są wyłączone.

W CreateHostBuilder programie Program.cs:

Host.CreateDefaultBuilder(args)
    .UseWindowsService()
    ...

W tym temacie towarzyszą następujące przykładowe aplikacje:

  • Przykład usługi Procesu roboczego w tle: przykładowa aplikacja nie internetowa oparta na szablonie usługi procesu roboczego, który używa hostowanych usług do wykonywania zadań w tle.
  • Przykład App Service Web: przykład aplikacji internetowej Pages, która działa jako usługa Windows Service z Razor hostowanych usługami do zadań w tle.

Aby uzyskać wskazówki dotyczące wzorca MVC, zobacz artykuły w artykułach Omówienie platformy ASP.NET Core MVC i Migrowanie z ASP.NET Core 2.2 do 3.0 .

Typ wdrożenia

Aby uzyskać informacje i porady dotyczące scenariuszy wdrażania, zobacz Wdrażanie aplikacji .NET Core.

SDK

W przypadku usługi opartej na aplikacji internetowej, która używa platform Pages lub MVC, określ internetowy Razor zestaw SDK w pliku projektu:

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

Jeśli usługa wykonuje tylko zadania w tle (na przykład usługi hostowane),określ zestaw SDK procesu roboczego w pliku projektu:

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

Wdrożenie zależne od struktury (FDD)

Wdrożenie zależne od struktury (FDD, Framework-Dependent Deployment) opiera się na obecności w systemie docelowym udostępnionej wersji programu .NET Core dla całego systemu. Gdy scenariusz FDD zostanie przyjęty zgodnie ze wskazówkami w tym artykule, zestaw SDK tworzy plik wykonywalny (.exe), nazywany plikiem wykonywalnym zależnym od struktury.

W przypadku korzystania z zestawu SDKsieci Web plik web.config, który jest zwykle wytwarzanych podczas publikowania aplikacji ASP.NET Core, nie jest zbędny w przypadku aplikacji Windows Services. Aby wyłączyć tworzenie pliku web.config, dodaj <IsTransformWebConfigDisabled> właściwość ustawioną na true .

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

Wdrożenie samodzielne (SCD)

Wdrożenie samodzielne (SCD, Self-contained deployment) nie polega na obecności udostępnionej struktury w systemie hosta. Środowisko uruchomieniowe i zależności aplikacji są wdrażane razem z aplikacją.

W Windows znajduje się identyfikator środowiska uruchomieniowego (RID), <PropertyGroup> który zawiera platformę docelową:

<RuntimeIdentifier>win7-x64</RuntimeIdentifier>

Aby opublikować dla wielu identyfikatorów ID:

  • Podaj identyfikatory ID na liście rozdzielanej średnikami.
  • Użyj nazwy właściwości <RuntimeIdentifiers> (w liczbie mnogiej).

Aby uzyskać więcej informacji, zobacz Katalog rid .NET Core.

Konto użytkownika usługi

Aby utworzyć konto użytkownika dla usługi, użyj polecenia cmdlet New-LocalUser z administracyjnej powłoki poleceń programu PowerShell 6.

Na Aktualizacja systemu Windows 10 z października 2018 (wersja 1809/kompilacja 10.0.17763) lub nowsza:

New-LocalUser -Name {SERVICE NAME}

W Windows systemu operacyjnego starszego niż Aktualizacja systemu Windows 10 z października 2018 (wersja 1809/kompilacja 10.0.17763):

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

Po wyświetleniu monitu podaj silne hasło.

Jeśli parametr -AccountExpires nie zostanie podany do polecenia cmdlet New-LocalUser z wygaśnięciem , konto nie DateTime wygaśnie.

Aby uzyskać więcej informacji, zobacz Microsoft.PowerShell.LocalAccounts i Konta użytkowników usługi.

Alternatywnym podejściem do zarządzania użytkownikami w przypadku korzystania z usługi Active Directory jest użycie zarządzanych kont usług. Aby uzyskać więcej informacji, zobacz Omówienie kont usług zarządzanych przez grupę.

Logowanie jako prawa usługi

Aby ustanowić prawa logowania jako usługi dla konta użytkownika usługi:

  1. Otwórz edytor lokalnych zasad zabezpieczeń, uruchamiając program secpol.msc.
  2. Rozwiń węzeł Zasady lokalne i wybierz pozycję Przypisanie praw użytkownika.
  3. Otwórz zasady Logowanie jako usługa.
  4. Wybierz pozycję Dodaj użytkownika lub grupę.
  5. Podaj nazwę obiektu (konto użytkownika) przy użyciu jednej z następujących metod:
    1. Wpisz konto użytkownika ( {DOMAIN OR COMPUTER NAME\USER} ) w polu nazwy obiektu i wybierz przycisk OK, aby dodać użytkownika do zasad.
    2. Wybierz pozycję Zaawansowane. Wybierz pozycję Znajdź teraz. Wybierz konto użytkownika z listy. Wybierz przycisk OK. Wybierz ponownie przycisk OK, aby dodać użytkownika do zasad.
  6. Wybierz przycisk OK lub Zastosuj, aby zaakceptować zmiany.

Tworzenie usługi Windows Service i zarządzanie nimi

Tworzenie usługi

Użyj poleceń programu PowerShell, aby zarejestrować usługę. Z administracyjnej powłoki poleceń programu PowerShell 6 wykonaj następujące polecenia:

$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}" -Credential "{DOMAIN OR COMPUTER NAME\USER}" -Description "{DESCRIPTION}" -DisplayName "{DISPLAY NAME}" -StartupType Automatic
  • {EXE PATH}: ścieżka do folderu aplikacji na hoście (na przykład d:\myservice ). Nie dołączaj pliku wykonywalnego aplikacji do ścieżki. Ukośnik na końcowej stronie nie jest wymagany.
  • {DOMAIN OR COMPUTER NAME\USER}: konto użytkownika usługi (na przykład Contoso\ServiceUser ).
  • {SERVICE NAME}: nazwa usługi (na przykład MyService ).
  • {EXE FILE PATH}: ścieżka pliku wykonywalnego aplikacji (na przykład d:\myservice\myservice.exe ). Dołącz nazwę pliku wykonywalnego z rozszerzeniem .
  • {DESCRIPTION}: opis usługi (na przykład My sample service ).
  • {DISPLAY NAME}: nazwa wyświetlana usługi (na przykład My Service ).

Uruchamianie usługi

Uruchom usługę za pomocą następującego polecenia programu PowerShell 6:

Start-Service -Name {SERVICE NAME}

Uruchomienie usługi trwa kilka sekund.

Określanie stanu usługi

Aby sprawdzić stan usługi, użyj następującego polecenia programu PowerShell 6:

Get-Service -Name {SERVICE NAME}

Stan jest zgłaszany jako jedna z następujących wartości:

  • Starting
  • Running
  • Stopping
  • Stopped

Zatrzymywanie usługi

Zatrzymaj usługę za pomocą następującego polecenia programu PowerShell 6:

Stop-Service -Name {SERVICE NAME}

Usuwanie usługi

Po krótkiej przerwie w zatrzymaniu usługi usuń usługę za pomocą następującego polecenia programu PowerShell 6:

Remove-Service -Name {SERVICE NAME}

Scenariusze serwera proxy i usługi równoważenia obciążenia

Usługi, które wchodzą w interakcje z żądaniami z Internetu lub sieci firmowej i znajdują się za serwerem proxy lub usługą równoważenia obciążenia, mogą wymagać dodatkowej konfiguracji. Aby uzyskać więcej informacji, zobacz Konfigurowanie ASP.NET Core do pracy z serwerami proxy i usługami równoważenia obciążenia.

Konfigurowanie punktów końcowych

Domyślnie program ASP.NET Core z http://localhost:5000 . Skonfiguruj adres URL i port, ustawiając ASPNETCORE_URLS zmienną środowiskową.

Aby uzyskać dodatkowe metody konfiguracji adresów URL i portów, zobacz odpowiedni artykuł na temat serwera:

Powyższe wskazówki obejmują obsługę punktów końcowych HTTPS. Na przykład skonfiguruj aplikację dla protokołu HTTPS, gdy uwierzytelnianie jest używane z usługą Windows Service.

Uwaga

Używanie certyfikatu ASP.NET Core HTTPS do zabezpieczania punktu końcowego usługi nie jest obsługiwane.

Bieżący katalog i katalog główny zawartości

Bieżący katalog roboczy zwracany przez wywołanie dla usługi Windows to folder GetCurrentDirectory C: \ windows \ system32. Folder system32 nie jest odpowiednią lokalizacją do przechowywania plików usługi (na przykład plików ustawień). Użyj jednej z następujących metod, aby zachować zasoby i pliki ustawień usługi oraz uzyskać do nich dostęp.

Używanie contentRootPath lub ContentRootFileProvider

Użyj IHostEnvironment.ContentRootPath lub ContentRootFileProvider znajdź zasoby aplikacji.

Gdy aplikacja działa jako usługa, ustawia dla klasy UseWindowsService ContentRootPath wartość AppContext.BaseDirectory.

Domyślne pliki ustawień aplikacji i appsettings.json ustawienia appsettings.{ Środowisko}.json, są ładowane z katalogu głównego zawartości aplikacji przez wywołanie createDefaultBuilder podczas tworzenia hosta.

W przypadku innych plików ustawień załadowanych przez kod dewelopera w pliku nie ConfigureAppConfiguration ma potrzeby wywołania . SetBasePath W poniższym przykładzie plik custom_settings.json istnieje w katalogu głównym zawartości aplikacji i jest ładowany bez jawnego ustawiania ścieżki podstawowej:

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>();
            });
}

Nie należy próbować użyć metody w celu uzyskania ścieżki zasobu, ponieważ aplikacja Windows Service zwraca GetCurrentDirectory folder C: \ WINDOWS \ system32 jako bieżący katalog.

Przechowywanie plików usługi w odpowiedniej lokalizacji na dysku

Określ ścieżkę bezwzględną z SetBasePath podczas IConfigurationBuilder używania do folderu zawierającego pliki.

Rozwiązywanie problemów

Aby rozwiązać problemy z Windows Service, zobacz Rozwiązywanie problemów z projektami ASP.NET Core debugowania .

Typowe błędy

  • Jest w użyciu stara lub wstępna wersja programu PowerShell.
  • Zarejestrowana usługa nie używa opublikowanych danych wyjściowych aplikacji z dotnet publish polecenia. Dane wyjściowe polecenia dotnet build nie są obsługiwane w przypadku wdrażania aplikacji. Opublikowane zasoby znajdują się w jednym z następujących folderów w zależności od typu wdrożenia:
    • bin/Release/{TARGET FRAMEWORK}/publish (FDD)
    • bin/Release/{TARGET FRAMEWORK}/{IDENTYFIKATOR ŚRODOWISKA URUCHOMIENIOWEGO}/publish (SCD)
  • Usługa nie jest w stanie RUNNING.
  • Ścieżki do zasobów, których używa aplikacja (na przykład certyfikaty), są nieprawidłowe. Podstawowa ścieżka usługi Windows to c: \ Windows \ System32.
  • Użytkownik nie ma uprawnień do logowania się jako usługa.
  • Hasło użytkownika wygasło lub zostało niepoprawnie przekazane podczas wykonywania New-Service polecenia programu PowerShell.
  • Aplikacja wymaga uwierzytelniania ASP.NET Core, ale nie jest skonfigurowana do bezpiecznego połączenia (HTTPS).
  • Port adresu URL żądania jest niepoprawny lub nie został poprawnie skonfigurowany w aplikacji.

Dzienniki zdarzeń systemu i aplikacji

Uzyskaj dostęp do dzienników zdarzeń systemu i aplikacji:

  1. Otwórz menu Start, wyszukaj pozycję Podgląd zdarzeń, a następnie wybierz Podgląd zdarzeń aplikację.
  2. W Podgląd zdarzeń otwórz węzeł Windows Dzienniki.
  3. Wybierz pozycję System, aby otworzyć dziennik zdarzeń systemu. Wybierz pozycję Aplikacja, aby otworzyć dziennik zdarzeń aplikacji.
  4. Wyszukaj błędy skojarzone z aplikacją, która się nie pomyliła.

Uruchamianie aplikacji w wierszu polecenia

Wiele błędów uruchamiania nie zawiera przydatnych informacji w dziennikach zdarzeń. Przyczynę niektórych błędów można znaleźć, uruchamiając aplikację w wierszu polecenia w systemie hostingu. Aby rejestrować dodatkowe szczegóły z aplikacji, obniż poziom dziennika lub uruchom aplikację w środowisku dewelopera.

Wyczyść pamięci podręczne pakietów

Działające aplikacje mogą ulec awarii natychmiast po uaktualnieniu zestaw .NET Core SDK na maszynie dewelopera lub zmianie wersji pakietu w aplikacji. W niektórych przypadkach niespójne pakiety mogą przerwać aplikację podczas przeprowadzania głównych uaktualnień. Większość z tych problemów można rozwiązać, korzystając z następujących instrukcji:

  1. Usuń foldery bin i obj.

  2. Wyczyść pamięć podręczną pakietów, wykonując polecenia dotnet nuget locals — wyczyść je z powłoki poleceń.

    Czyszczenie pamięci podręcznych pakietów można również wykonać za pomocą nuget.exe i wykonać polecenie nuget locals all -clear . nuget.exe nie jest instalowana w pakiecie z systemem operacyjnym Windows Desktop i należy ją uzyskać oddzielnie z witryny NuGet sieci Web.

  3. Przywracanie i ponowne kompilowanie projektu.

  4. Przed ponowne wdrożeniem aplikacji usuń wszystkie pliki z folderu wdrożenia na serwerze.

Aplikacja, która działa wolno lub nie odpowiada

Zrzut awaryjne jest migawką pamięci systemu i może pomóc w ustaleniu przyczyny awarii aplikacji, niepowodzenia uruchamiania lub powolnej aplikacji.

Aplikacja ulega awarii lub napotyka wyjątek

Uzyskiwanie i analizowanie zrzutu z Raportowanie błędów systemu Windows (WER):

  1. Utwórz folder do przechowywania plików zrzutu awaryjnego w folderze c:\dumps .

  2. Uruchom skrypt EnableDumps programu PowerShell z nazwą pliku wykonywalnego aplikacji:

    .\EnableDumps {APPLICATION EXE} c:\dumps
    
  3. Uruchom aplikację w warunkach, które powodują awarię.

  4. Po zakończeniu awarii uruchom skrypt programu PowerShell DisableDumps:

    .\DisableDumps {APPLICATION EXE}
    

Po awarii aplikacji i zakończeniu zbierania zrzutów aplikacja może zakończyć się normalnie. Skrypt programu PowerShell konfiguruje usługę WER do zbierania maksymalnie pięciu zrzutów na aplikację.

Ostrzeżenie

Zrzuty awaryjne mogą zająć dużą ilość miejsca na dysku (każdy z nich może mieć do kilku gigabajtów).

Aplikacja nie odpowiada, kończy się niepowodzeniem podczas uruchamiania lub działa normalnie

Gdy aplikacja zawiesza się (przestaje odpowiadać, ale nie ulega awarii), kończy się niepowodzeniem podczas uruchamiania lub działa normalnie, zobacz Pliki zrzutu w trybie użytkownika: wybieranie najlepszego narzędzia w celu wybrania odpowiedniego narzędzia do tworzenia zrzutu.

Analizowanie zrzutu

Zrzut można przeanalizować przy użyciu kilku metod. Aby uzyskać więcej informacji, zobacz Analyzing a User-Mode Dump File (Analizowanie pliku zrzutu User-Mode zrzutu).

Dodatkowe zasoby

Aplikacja ASP.NET Core może być hostowana w usłudze Windows jako Windows Service bez korzystania z usług IIS. W przypadku hostowania Windows Service aplikacja jest uruchamiana automatycznie po ponownym uruchomieniu serwera.

Wyświetl lub pobierz przykładowy kod (jak pobrać)

Wymagania wstępne

Konfiguracja aplikacji

Aplikacja wymaga odwołań do pakietów Dla Microsoft.AspNetCore.Hosting.WindowsServices i Microsoft.Extensions.Logging.EventLog.

Aby przetestować i debugować w przypadku uruchamiania poza usługą, dodaj kod, aby określić, czy aplikacja jest uruchomiona jako usługa, czy jako aplikacja konsolowa. Sprawdź, czy debuger jest dołączony lub --console czy jest obecny przełącznik. Jeśli którykolwiek z warunków ma wartość true (aplikacja nie jest uruchamiana jako usługa), wywołaj . Run Jeśli warunki są fałszywe (aplikacja jest uruchamiana jako usługa):

Ponieważ dostawca konfiguracji wiersza polecenia wymaga par nazwa-wartość dla argumentów wiersza polecenia, przełącznik jest usuwany z argumentów przed --console CreateDefaultBuilder otrzymaniem argumentów.

Aby zapisać w Windows zdarzeń, dodaj dostawcę dziennika zdarzeń do usługi ConfigureLogging . Ustaw poziom rejestrowania za Logging:LogLevel:Default pomocą klucza w ustawieniach appsettings. Plik Production.json.

W poniższym przykładzie z przykładowej aplikacji jest wywoływana zamiast w celu obsługi zdarzeń okresu RunAsCustomService RunAsService istnienia w aplikacji. Aby uzyskać więcej informacji, zobacz sekcję Handle starting and stopping events (Obsługa uruchamiania i zatrzymywania zdarzeń).

public class Program
{
    public static void Main(string[] args)
    {
        var isService = !(Debugger.IsAttached || args.Contains("--console"));
        
        if (isService)
        {
            var pathToExe = Process.GetCurrentProcess().MainModule.FileName;
            var pathToContentRoot = Path.GetDirectoryName(pathToExe);
            Directory.SetCurrentDirectory(pathToContentRoot);
        }

        var builder = CreateWebHostBuilder(
            args.Where(arg => arg != "--console").ToArray());

        var host = builder.Build();

        if (isService)
        {
            // To run the app without the CustomWebHostService change the
            // next line to host.RunAsService();
            host.RunAsCustomService();
        }
        else
        {
            host.Run();
        }
    }

    public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>
        WebHost.CreateDefaultBuilder(args)
            .ConfigureLogging((hostingContext, logging) =>
            {
                logging.AddEventLog();
            })
            .ConfigureAppConfiguration((context, config) =>
            {
                // Configure the app here.
            })
            .UseStartup<Startup>();
}

Typ wdrożenia

Aby uzyskać informacje i porady dotyczące scenariuszy wdrażania, zobacz Wdrażanie aplikacji .NET Core.

SDK

W przypadku usługi opartej na aplikacji internetowej, która używa platform Pages lub MVC, określ internetowy zestaw Razor SDK w pliku projektu:

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

Jeśli usługa wykonuje tylko zadania w tle (na przykład usługi hostowane),określ zestaw SDK procesu roboczego w pliku projektu:

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

Wdrożenie zależne od struktury (FDD)

Wdrożenie zależne od struktury (FDD, framework-dependent deployment) opiera się na obecności udostępnionej dla całego systemu wersji programu .NET Core w systemie docelowym. Gdy scenariusz FDD zostanie przyjęty zgodnie ze wskazówkami w tym artykule, zestaw SDK tworzy plik wykonywalny (.exe) nazywany plikiem wykonywalnym zależnym od struktury.

Identyfikator Windows uruchomieniowego (RID) ( <RuntimeIdentifier> ) zawiera platformę docelową. W poniższym przykładzie rid jest ustawiony na win7-x64 . Właściwość <SelfContained> ma ustawioną wartość false. Te właściwości instruuje zestaw SDK, aby wygenerował plik wykonywalny (.exe) dla aplikacji Windows aplikacji, która zależy od udostępnionej platformy .NET Core.

Plik web.config, który jest zwykle wytwarzanych podczas publikowania aplikacji ASP.NET Core, nie jest zbędny w przypadku aplikacji Windows Services. Aby wyłączyć tworzenie pliku web.config, dodaj <IsTransformWebConfigDisabled> właściwość ustawioną na true wartość .

<PropertyGroup>
  <TargetFramework>netcoreapp2.2</TargetFramework>
  <RuntimeIdentifier>win7-x64</RuntimeIdentifier>
  <SelfContained>false</SelfContained>
  <IsTransformWebConfigDisabled>true</IsTransformWebConfigDisabled>
</PropertyGroup>

Wdrożenie samodzielne (SCD)

Wdrożenie samodzielne (SCD) nie polega na obecności udostępnionej struktury w systemie hosta. Środowisko uruchomieniowe i zależności aplikacji są wdrażane razem z aplikacją.

Identyfikator Windows uruchomieniowego (RID) znajduje się w pliku <PropertyGroup> , który zawiera platformę docelową:

<RuntimeIdentifier>win7-x64</RuntimeIdentifier>

Aby opublikować dla wielu identyfikatorów RID:

  • Podaj identyfikatory ID na liście rozdzielonych średnikami.
  • Użyj nazwy właściwości <RuntimeIdentifiers> (w liczbie mnogiej).

Aby uzyskać więcej informacji, zobacz Katalog rid .NET Core.

Właściwość <SelfContained> jest ustawiona na true wartość :

<SelfContained>true</SelfContained>

Konto użytkownika usługi

Aby utworzyć konto użytkownika dla usługi, użyj polecenia cmdlet New-LocalUser z administracyjnej powłoki poleceń programu PowerShell 6.

W Aktualizacja systemu Windows 10 z października 2018 (wersja 1809/kompilacja 10.0.17763) lub nowsza:

New-LocalUser -Name {SERVICE NAME}

W Windows systemu operacyjnego starszej niż Aktualizacja systemu Windows 10 z października 2018 (wersja 1809/kompilacja 10.0.17763):

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

Po wyświetleniu monitu podaj silne hasło.

Jeśli parametr nie zostanie podany do polecenia -AccountExpires cmdlet New-LocalUser z wygaśnięciem DateTime , konto nie wygaśnie.

Aby uzyskać więcej informacji, zobacz Microsoft.PowerShell.LocalAccounts i Konta użytkowników usługi.

Alternatywnym podejściem do zarządzania użytkownikami w przypadku korzystania z usługi Active Directory jest użycie zarządzanych kont usług. Aby uzyskać więcej informacji, zobacz Omówienie kont usług zarządzanych przez grupę.

Logowanie jako prawa usługi

Aby ustanowić prawa logowania jako usługi dla konta użytkownika usługi:

  1. Otwórz edytor lokalnych zasad zabezpieczeń, uruchamiając program secpol.msc.
  2. Rozwiń węzeł Zasady lokalne i wybierz pozycję Przypisywanie praw użytkownika.
  3. Otwórz zasady Logowanie jako usługa.
  4. Wybierz pozycję Dodaj użytkownika lub grupę.
  5. Podaj nazwę obiektu (konto użytkownika) przy użyciu jednej z następujących metod:
    1. Wpisz konto użytkownika ( {DOMAIN OR COMPUTER NAME\USER} ) w polu nazwy obiektu i wybierz przycisk OK, aby dodać użytkownika do zasad.
    2. Wybierz pozycję Zaawansowane. Wybierz pozycję Znajdź teraz. Wybierz konto użytkownika z listy. Wybierz przycisk OK. Wybierz ponownie przycisk OK, aby dodać użytkownika do zasad.
  6. Wybierz przycisk OK lub Zastosuj, aby zaakceptować zmiany.

Tworzenie usługi Windows Service i zarządzanie nimi

Tworzenie usługi

Użyj poleceń programu PowerShell, aby zarejestrować usługę. Z administracyjnej powłoki poleceń programu PowerShell 6 wykonaj następujące polecenia:

$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} -Credential {DOMAIN OR COMPUTER NAME\USER} -Description "{DESCRIPTION}" -DisplayName "{DISPLAY NAME}" -StartupType Automatic
  • {EXE PATH}: ścieżka do folderu aplikacji na hoście (na przykład d:\myservice ). Nie dołączaj pliku wykonywalnego aplikacji do ścieżki. Ukośnik na końcowej trasie nie jest wymagany.
  • {DOMAIN OR COMPUTER NAME\USER}: konto użytkownika usługi (na przykład Contoso\ServiceUser ).
  • {SERVICE NAME}: nazwa usługi (na przykład MyService ).
  • {EXE FILE PATH}: ścieżka pliku wykonywalnego aplikacji (na przykład d:\myservice\myservice.exe ). Dołącz nazwę pliku wykonywalnego z rozszerzeniem .
  • {DESCRIPTION}: opis usługi (na przykład My sample service ).
  • {DISPLAY NAME}: nazwa wyświetlana usługi (na przykład My Service ).

Uruchamianie usługi

Uruchom usługę za pomocą następującego polecenia programu PowerShell 6:

Start-Service -Name {SERVICE NAME}

Uruchomienie usługi trwa kilka sekund.

Określanie stanu usługi

Aby sprawdzić stan usługi, użyj następującego polecenia programu PowerShell 6:

Get-Service -Name {SERVICE NAME}

Stan jest zgłaszany jako jedna z następujących wartości:

  • Starting
  • Running
  • Stopping
  • Stopped

Zatrzymywanie usługi

Zatrzymaj usługę za pomocą następującego polecenia programu PowerShell 6:

Stop-Service -Name {SERVICE NAME}

Usuwanie usługi

Po krótkiej przerwie w zatrzymaniu usługi usuń usługę za pomocą następującego polecenia programu PowerShell 6:

Remove-Service -Name {SERVICE NAME}

Obsługa zdarzeń uruchamiania i zatrzymywania

Aby obsługiwać OnStarting zdarzenia OnStarted , i OnStopping :

  1. Utwórz klasę, która pochodzi od WebHostService klasy za pomocą metod , i OnStarting OnStarted OnStopping :

    [DesignerCategory("Code")]
    internal class CustomWebHostService : WebHostService
    {
        private ILogger _logger;
    
        public CustomWebHostService(IWebHost host) : base(host)
        {
            _logger = host.Services
                .GetRequiredService<ILogger<CustomWebHostService>>();
        }
    
        protected override void OnStarting(string[] args)
        {
            _logger.LogInformation("OnStarting method called.");
            base.OnStarting(args);
        }
    
        protected override void OnStarted()
        {
            _logger.LogInformation("OnStarted method called.");
            base.OnStarted();
        }
    
        protected override void OnStopping()
        {
            _logger.LogInformation("OnStopping method called.");
            base.OnStopping();
        }
    }
    
  2. Utwórz metodę rozszerzenia dla metody IWebHost , która przekazuje do CustomWebHostService Run :

    public static class WebHostServiceExtensions
    {
        public static void RunAsCustomService(this IWebHost host)
        {
            var webHostService = new CustomWebHostService(host);
            ServiceBase.Run(webHostService);
        }
    }
    
  3. W Program.Main pliku wywołaj RunAsCustomService metodę rozszerzenia zamiast RunAsService :

    host.RunAsCustomService();
    

    Aby wyświetlić lokalizację w RunAsService pliku , zapoznaj się z Program.Main przykładowym kodem widocznym w sekcji Typ wdrożenia.

Scenariusze serwera proxy i usługi równoważenia obciążenia

Usługi, które wchodzą w interakcje z żądaniami z Internetu lub sieci firmowej i znajdują się za serwerem proxy lub usługą równoważenia obciążenia, mogą wymagać dodatkowej konfiguracji. Aby uzyskać więcej informacji, zobacz Konfigurowanie ASP.NET Core do pracy z serwerami proxy i usługami równoważenia obciążenia.

Konfigurowanie punktów końcowych

Domyślnie program ASP.NET Core z http://localhost:5000 . Skonfiguruj adres URL i port, ustawiając ASPNETCORE_URLS zmienną środowiskową.

Dodatkowe metody konfiguracji adresów URL i portów można znaleźć w odpowiednim artykule na temat serwera:

Powyższe wskazówki obejmują obsługę punktów końcowych HTTPS. Na przykład skonfiguruj aplikację do obsługi protokołu HTTPS, gdy uwierzytelnianie jest używane z usługą Windows Service.

Uwaga

Używanie certyfikatu ASP.NET Core HTTPS do zabezpieczania punktu końcowego usługi nie jest obsługiwane.

Bieżący katalog i katalog główny zawartości

Bieżący katalog roboczy zwracany przez wywołanie dla usługi GetCurrentDirectory Windows to folder C: windows \ \ system32. Folder system32 nie jest odpowiednią lokalizacją do przechowywania plików usługi (na przykład plików ustawień). Użyj jednej z następujących metod, aby zachować zasoby i pliki ustawień usługi oraz uzyskać do nich dostęp.

Ustaw ścieżkę katalogu głównego zawartości na folder aplikacji

Jest ContentRootPath taka sama ścieżka do binPath argumentu podczas tworzenia usługi. Zamiast wywoływania funkcji w celu utworzenia ścieżek do plików ustawień, wywołaj wywołanie ze ścieżką do katalogu GetCurrentDirectory SetCurrentDirectory głównego zawartości aplikacji.

W pliku określ ścieżkę do folderu pliku wykonywalnego usługi i użyj ścieżki do ustanowienia katalogu Program.Main głównego zawartości aplikacji:

var pathToExe = Process.GetCurrentProcess().MainModule.FileName;
var pathToContentRoot = Path.GetDirectoryName(pathToExe);
Directory.SetCurrentDirectory(pathToContentRoot);

CreateWebHostBuilder(args)
    .Build()
    .RunAsService();

Przechowywanie plików usługi w odpowiedniej lokalizacji na dysku

Określ ścieżkę bezwzględną z SetBasePath w przypadku IConfigurationBuilder używania do folderu zawierającego pliki.

Rozwiązywanie problemów

Aby rozwiązać problemy z Windows Service, zobacz Rozwiązywanie problemów z projektami ASP.NET Core debugowania .

Typowe błędy

  • Jest w użyciu stara lub wstępna wersja programu PowerShell.
  • Zarejestrowana usługa nie używa opublikowanych danych wyjściowych aplikacji z dotnet publish polecenia. Dane wyjściowe polecenia dotnet build nie są obsługiwane w przypadku wdrażania aplikacji. Opublikowane zasoby znajdują się w jednym z następujących folderów w zależności od typu wdrożenia:
    • bin/Release/{TARGET FRAMEWORK}/publish (FDD)
    • bin/Release/{TARGET FRAMEWORK}/{IDENTYFIKATOR ŚRODOWISKA URUCHOMIENIOWEGO}/publikowanie (SCD)
  • Usługa nie jest w stanie RUNNING.
  • Ścieżki do zasobów, których używa aplikacja (na przykład certyfikaty), są nieprawidłowe. Ścieżka podstawowa usługi Windows to c: \ Windows \ System32.
  • Użytkownik nie ma uprawnień Do logowania się jako usługa.
  • Hasło użytkownika wygasło lub zostało niepoprawnie przekazane podczas wykonywania New-Service polecenia programu PowerShell.
  • Aplikacja wymaga uwierzytelniania ASP.NET Core, ale nie jest skonfigurowana do bezpiecznego połączenia (HTTPS).
  • Port adresu URL żądania jest niepoprawny lub nie został poprawnie skonfigurowany w aplikacji.

Dzienniki zdarzeń systemu i aplikacji

Uzyskaj dostęp do dzienników zdarzeń systemu i aplikacji:

  1. Otwórz menu Start, wyszukaj pozycję Podgląd zdarzeń, a następnie wybierz Podgląd zdarzeń aplikację.
  2. W Podgląd zdarzeń otwórz węzeł Windows Dzienniki.
  3. Wybierz pozycję System, aby otworzyć dziennik zdarzeń systemu. Wybierz pozycję Aplikacja, aby otworzyć dziennik zdarzeń aplikacji.
  4. Wyszukaj błędy skojarzone z aplikacją, która się nie pomyliła.

Uruchamianie aplikacji w wierszu polecenia

Wiele błędów uruchamiania nie zawiera przydatnych informacji w dziennikach zdarzeń. Przyczynę niektórych błędów można znaleźć, uruchamiając aplikację w wierszu polecenia w systemie hostingu. Aby rejestrować dodatkowe szczegóły z aplikacji, obniż poziom dziennika lub uruchom aplikację w środowisku dewelopera.

Wyczyść pamięci podręczne pakietów

Działające aplikacje mogą ulec awarii natychmiast po uaktualnieniu zestaw .NET Core SDK na maszynie dewelopera lub zmianie wersji pakietu w aplikacji. W niektórych przypadkach niespójne pakiety mogą przerwać aplikację podczas przeprowadzania głównych uaktualnień. Większość z tych problemów można rozwiązać, korzystając z następujących instrukcji:

  1. Usuń foldery bin i obj.

  2. Wyczyść pamięć podręczną pakietów, wykonując polecenia dotnet nuget locals — wyczyść je z powłoki poleceń.

    Czyszczenie pamięci podręcznych pakietów można również wykonać za pomocą nuget.exe i wykonać polecenie nuget locals all -clear . nuget.exe nie jest instalowana w pakiecie z systemem operacyjnym Windows Desktop i należy ją uzyskać niezależnie od witryny NuGet internetowej.

  3. Przywracanie i ponowne kompilowanie projektu.

  4. Przed ponowne wdrożeniem aplikacji usuń wszystkie pliki z folderu wdrożenia na serwerze.

Aplikacja, która działa wolno lub nie odpowiada

Zrzut awaryjne jest migawką pamięci systemu i może pomóc w ustaleniu przyczyny awarii aplikacji, niepowodzenia uruchamiania lub powolnej aplikacji.

Aplikacja ulega awarii lub napotyka wyjątek

Uzyskiwanie i analizowanie zrzutu z Raportowanie błędów systemu Windows (WER):

  1. Utwórz folder do przechowywania plików zrzutu awaryjnego w folderze c:\dumps .

  2. Uruchom skrypt EnableDumps programu PowerShell z nazwą pliku wykonywalnego aplikacji:

    .\EnableDumps {APPLICATION EXE} c:\dumps
    
  3. Uruchom aplikację w warunkach, które powodują awarię.

  4. Po zakończeniu awarii uruchom skrypt programu PowerShell DisableDumps:

    .\DisableDumps {APPLICATION EXE}
    

Po awarii aplikacji i zakończeniu zbierania zrzutów aplikacja może zakończyć się normalnie. Skrypt programu PowerShell konfiguruje usługę WER do zbierania maksymalnie pięciu zrzutów na aplikację.

Ostrzeżenie

Zrzuty awaryjne mogą zająć dużą ilość miejsca na dysku (każdy z nich może mieć do kilku gigabajtów).

Aplikacja nie odpowiada, kończy się niepowodzeniem podczas uruchamiania lub działa normalnie

Gdy aplikacja zawiesza się (przestaje odpowiadać, ale nie ulega awarii), kończy się niepowodzeniem podczas uruchamiania lub działa normalnie, zobacz Pliki zrzutu w trybie użytkownika: wybieranie najlepszego narzędzia w celu wybrania odpowiedniego narzędzia do tworzenia zrzutu.

Analizowanie zrzutu

Zrzut można przeanalizować przy użyciu kilku metod. Aby uzyskać więcej informacji, zobacz Analyzing a User-Mode Dump File (Analizowanie pliku zrzutu User-Mode zrzutu).

Dodatkowe zasoby

Aplikacja ASP.NET Core może być hostowana w usłudze Windows jako Windows Service bez korzystania z usług IIS. W przypadku hostowania Windows Service aplikacja jest uruchamiana automatycznie po ponownym uruchomieniu serwera.

Wyświetl lub pobierz przykładowy kod (jak pobrać)

Wymagania wstępne

Konfiguracja aplikacji

Aplikacja wymaga odwołań do pakietów Dla Microsoft.AspNetCore.Hosting.WindowsServices i Microsoft.Extensions.Logging.EventLog.

Aby przetestować i debugować w przypadku uruchamiania poza usługą, dodaj kod, aby określić, czy aplikacja jest uruchomiona jako usługa, czy jako aplikacja konsolowa. Sprawdź, czy debuger jest dołączony lub --console czy jest obecny przełącznik. Jeśli którykolwiek z warunków ma wartość true (aplikacja nie jest uruchamiana jako usługa), wywołaj . Run Jeśli warunki są fałszywe (aplikacja jest uruchamiana jako usługa):

Ponieważ dostawca konfiguracji wiersza polecenia wymaga par nazwa-wartość dla argumentów wiersza polecenia, przełącznik jest usuwany z argumentów przed --console CreateDefaultBuilder otrzymaniem argumentów.

Aby zapisać w dzienniku Windows zdarzeń, dodaj dostawcę dziennika zdarzeń do usługi ConfigureLogging . Ustaw poziom rejestrowania za Logging:LogLevel:Default pomocą klucza w ustawieniach appsettings. Plik Production.json.

W poniższym przykładzie z przykładowej aplikacji jest wywoływana zamiast w celu obsługi zdarzeń okresu RunAsCustomService RunAsService istnienia w aplikacji. Aby uzyskać więcej informacji, zobacz sekcję Handle starting and stopping events (Obsługa uruchamiania i zatrzymywania zdarzeń).

public class Program
{
    public static void Main(string[] args)
    {
        var isService = !(Debugger.IsAttached || args.Contains("--console"));
        
        if (isService)
        {
            var pathToExe = Process.GetCurrentProcess().MainModule.FileName;
            var pathToContentRoot = Path.GetDirectoryName(pathToExe);
            Directory.SetCurrentDirectory(pathToContentRoot);
        }

        var builder = CreateWebHostBuilder(
            args.Where(arg => arg != "--console").ToArray());

        var host = builder.Build();

        if (isService)
        {
            // To run the app without the CustomWebHostService change the
            // next line to host.RunAsService();
            host.RunAsCustomService();
        }
        else
        {
            host.Run();
        }
    }

    public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>
        WebHost.CreateDefaultBuilder(args)
            .ConfigureLogging((hostingContext, logging) =>
            {
                logging.AddEventLog();
            })
            .ConfigureAppConfiguration((context, config) =>
            {
                // Configure the app here.
            })
            .UseStartup<Startup>();
}

Typ wdrożenia

Aby uzyskać informacje i porady dotyczące scenariuszy wdrażania, zobacz Wdrażanie aplikacji .NET Core.

SDK

W przypadku usługi opartej na aplikacji internetowej, która używa platform Pages lub MVC, określ internetowy Razor zestaw SDK w pliku projektu:

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

Jeśli usługa wykonuje tylko zadania w tle (na przykład usługi hostowane),określ zestaw SDK procesu roboczego w pliku projektu:

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

Wdrożenie zależne od struktury (FDD)

Wdrożenie zależne od struktury (FDD, Framework-Dependent Deployment) opiera się na obecności w systemie docelowym udostępnionej wersji programu .NET Core dla całego systemu. Gdy scenariusz FDD zostanie przyjęty zgodnie ze wskazówkami w tym artykule, zestaw SDK tworzy plik wykonywalny (.exe), nazywany plikiem wykonywalnym zależnym od struktury.

Identyfikator Windows uruchomieniowego (RID) ( <RuntimeIdentifier> ) zawiera platformę docelową. W poniższym przykładzie rid jest ustawiony na win7-x64 . Właściwość <SelfContained> ma ustawioną wartość false. Te właściwości instruuje zestaw SDK, aby wygenerował plik wykonywalny (.exe) dla Windows i aplikacji, która zależy od udostępnionej platformy .NET Core.

Właściwość <UseAppHost> ma ustawioną wartość true. Ta właściwość zapewnia usłudze ścieżkę aktywacji (plik wykonywalny, .exe) dla FDD.

Plik web.config, który jest zwykle wytwarzanych podczas publikowania aplikacji ASP.NET Core, nie jest zbędny w przypadku aplikacji Windows Services. Aby wyłączyć tworzenie pliku web.config, dodaj <IsTransformWebConfigDisabled> właściwość ustawioną na true .

<PropertyGroup>
  <TargetFramework>netcoreapp2.2</TargetFramework>
  <RuntimeIdentifier>win7-x64</RuntimeIdentifier>
  <UseAppHost>true</UseAppHost>
  <SelfContained>false</SelfContained>
  <IsTransformWebConfigDisabled>true</IsTransformWebConfigDisabled>
</PropertyGroup>

Wdrożenie samodzielne (SCD)

Wdrożenie samodzielne (SCD, Self-contained deployment) nie polega na obecności udostępnionej struktury w systemie hosta. Środowisko uruchomieniowe i zależności aplikacji są wdrażane z aplikacją.

W Windows znajduje się identyfikator środowiska uruchomieniowego (RID), <PropertyGroup> który zawiera platformę docelową:

<RuntimeIdentifier>win7-x64</RuntimeIdentifier>

Aby opublikować dla wielu identyfikatorów ID:

  • Podaj identyfikatory ID na liście rozdzielanej średnikami.
  • Użyj nazwy właściwości <RuntimeIdentifiers> (w liczbie mnogiej).

Aby uzyskać więcej informacji, zobacz Katalog rid .NET Core.

Właściwość <SelfContained> jest ustawiona na true wartość :

<SelfContained>true</SelfContained>

Konto użytkownika usługi

Aby utworzyć konto użytkownika dla usługi, użyj polecenia cmdlet New-LocalUser z administracyjnej powłoki poleceń programu PowerShell 6.

Na Aktualizacja systemu Windows 10 z października 2018 (wersja 1809/kompilacja 10.0.17763) lub nowsza:

New-LocalUser -Name {SERVICE NAME}

W Windows systemu operacyjnego starszego niż Aktualizacja systemu Windows 10 z października 2018 (wersja 1809/kompilacja 10.0.17763):

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

Po wyświetleniu monitu podaj silne hasło.

Jeśli parametr -AccountExpires nie zostanie podany do polecenia cmdlet New-LocalUser z wygaśnięciem , konto nie DateTime wygaśnie.

Aby uzyskać więcej informacji, zobacz Microsoft.PowerShell.LocalAccounts i Konta użytkowników usługi.

Alternatywnym podejściem do zarządzania użytkownikami w przypadku korzystania z usługi Active Directory jest użycie zarządzanych kont usług. Aby uzyskać więcej informacji, zobacz Omówienie kont usług zarządzanych przez grupę.

Logowanie jako prawa usługi

Aby ustanowić prawa logowania jako usługi dla konta użytkownika usługi:

  1. Otwórz edytor lokalnych zasad zabezpieczeń, uruchamiając program secpol.msc.
  2. Rozwiń węzeł Zasady lokalne i wybierz pozycję Przypisywanie praw użytkownika.
  3. Otwórz zasady Logowanie jako usługa.
  4. Wybierz pozycję Dodaj użytkownika lub grupę.
  5. Podaj nazwę obiektu (konto użytkownika) przy użyciu jednej z następujących metod:
    1. Wpisz konto użytkownika ( {DOMAIN OR COMPUTER NAME\USER} ) w polu nazwy obiektu i wybierz przycisk OK, aby dodać użytkownika do zasad.
    2. Wybierz pozycję Zaawansowane. Wybierz pozycję Znajdź teraz. Wybierz konto użytkownika z listy. Wybierz przycisk OK. Wybierz ponownie przycisk OK, aby dodać użytkownika do zasad.
  6. Wybierz przycisk OK lub Zastosuj, aby zaakceptować zmiany.

Tworzenie usługi Windows Service i zarządzanie nimi

Tworzenie usługi

Użyj poleceń programu PowerShell, aby zarejestrować usługę. Z administracyjnej powłoki poleceń programu PowerShell 6 wykonaj następujące polecenia:

$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} -Credential {DOMAIN OR COMPUTER NAME\USER} -Description "{DESCRIPTION}" -DisplayName "{DISPLAY NAME}" -StartupType Automatic
  • {EXE PATH}: ścieżka do folderu aplikacji na hoście (na przykład d:\myservice ). Nie dołączaj pliku wykonywalnego aplikacji do ścieżki. Ukośnik na końcowej trasie nie jest wymagany.
  • {DOMAIN OR COMPUTER NAME\USER}: konto użytkownika usługi (na przykład Contoso\ServiceUser ).
  • {SERVICE NAME}: nazwa usługi (na przykład MyService ).
  • {EXE FILE PATH}: ścieżka pliku wykonywalnego aplikacji (na przykład d:\myservice\myservice.exe ). Dołącz nazwę pliku wykonywalnego z rozszerzeniem .
  • {DESCRIPTION}: opis usługi (na przykład My sample service ).
  • {DISPLAY NAME}: nazwa wyświetlana usługi (na przykład My Service ).

Uruchamianie usługi

Uruchom usługę za pomocą następującego polecenia programu PowerShell 6:

Start-Service -Name {SERVICE NAME}

Uruchomienie usługi trwa kilka sekund.

Określanie stanu usługi

Aby sprawdzić stan usługi, użyj następującego polecenia programu PowerShell 6:

Get-Service -Name {SERVICE NAME}

Stan jest zgłaszany jako jedna z następujących wartości:

  • Starting
  • Running
  • Stopping
  • Stopped

Zatrzymywanie usługi

Zatrzymaj usługę za pomocą następującego polecenia programu PowerShell 6:

Stop-Service -Name {SERVICE NAME}

Usuwanie usługi

Po krótkiej przerwie w zatrzymaniu usługi usuń usługę za pomocą następującego polecenia programu PowerShell 6:

Remove-Service -Name {SERVICE NAME}

Obsługa zdarzeń uruchamiania i zatrzymywania

Aby obsługiwać OnStarting zdarzenia OnStarted , i OnStopping :

  1. Utwórz klasę, która pochodzi od WebHostService klasy za pomocą metod , i OnStarting OnStarted OnStopping :

    [DesignerCategory("Code")]
    internal class CustomWebHostService : WebHostService
    {
        private ILogger _logger;
    
        public CustomWebHostService(IWebHost host) : base(host)
        {
            _logger = host.Services
                .GetRequiredService<ILogger<CustomWebHostService>>();
        }
    
        protected override void OnStarting(string[] args)
        {
            _logger.LogInformation("OnStarting method called.");
            base.OnStarting(args);
        }
    
        protected override void OnStarted()
        {
            _logger.LogInformation("OnStarted method called.");
            base.OnStarted();
        }
    
        protected override void OnStopping()
        {
            _logger.LogInformation("OnStopping method called.");
            base.OnStopping();
        }
    }
    
  2. Utwórz metodę rozszerzenia dla metody IWebHost , która przekazuje do CustomWebHostService Run :

    public static class WebHostServiceExtensions
    {
        public static void RunAsCustomService(this IWebHost host)
        {
            var webHostService = new CustomWebHostService(host);
            ServiceBase.Run(webHostService);
        }
    }
    
  3. W Program.Main pliku wywołaj RunAsCustomService metodę rozszerzenia zamiast RunAsService :

    host.RunAsCustomService();
    

    Aby wyświetlić lokalizację w RunAsService pliku , zapoznaj się z Program.Main przykładowym kodem widocznym w sekcji Typ wdrożenia.

Scenariusze serwera proxy i usługi równoważenia obciążenia

Usługi, które wchodzą w interakcje z żądaniami z Internetu lub sieci firmowej i znajdują się za serwerem proxy lub usługą równoważenia obciążenia, mogą wymagać dodatkowej konfiguracji. Aby uzyskać więcej informacji, zobacz Konfigurowanie ASP.NET Core do pracy z serwerami proxy i usługami równoważenia obciążenia.

Konfigurowanie punktów końcowych

Domyślnie program ASP.NET Core z http://localhost:5000 . Skonfiguruj adres URL i port, ustawiając ASPNETCORE_URLS zmienną środowiskową.

Dodatkowe metody konfiguracji adresów URL i portów można znaleźć w odpowiednim artykule na temat serwera:

Powyższe wskazówki obejmują obsługę punktów końcowych HTTPS. Na przykład skonfiguruj aplikację do obsługi protokołu HTTPS, gdy uwierzytelnianie jest używane z usługą Windows Service.

Uwaga

Używanie certyfikatu ASP.NET Core HTTPS do zabezpieczania punktu końcowego usługi nie jest obsługiwane.

Bieżący katalog i katalog główny zawartości

Bieżący katalog roboczy zwracany przez wywołanie dla usługi GetCurrentDirectory Windows to folder C: windows \ \ system32. Folder system32 nie jest odpowiednią lokalizacją do przechowywania plików usługi (na przykład plików ustawień). Użyj jednej z następujących metod, aby zachować zasoby i pliki ustawień usługi oraz uzyskać do nich dostęp.

Ustaw ścieżkę katalogu głównego zawartości na folder aplikacji

Jest ContentRootPath taka sama ścieżka do binPath argumentu podczas tworzenia usługi. Zamiast wywoływania funkcji w celu utworzenia ścieżek do plików ustawień, wywołaj wywołanie ze ścieżką do katalogu GetCurrentDirectory SetCurrentDirectory głównego zawartości aplikacji.

W pliku określ ścieżkę do folderu pliku wykonywalnego usługi i użyj ścieżki do ustanowienia katalogu Program.Main głównego zawartości aplikacji:

var pathToExe = Process.GetCurrentProcess().MainModule.FileName;
var pathToContentRoot = Path.GetDirectoryName(pathToExe);
Directory.SetCurrentDirectory(pathToContentRoot);

CreateWebHostBuilder(args)
    .Build()
    .RunAsService();

Przechowywanie plików usługi w odpowiedniej lokalizacji na dysku

Określ ścieżkę bezwzględną z SetBasePath w przypadku IConfigurationBuilder używania do folderu zawierającego pliki.

Rozwiązywanie problemów

Aby rozwiązać problemy z Windows Service, zobacz Rozwiązywanie problemów z projektami ASP.NET Core debugowania .

Typowe błędy

  • Jest w użyciu stara lub wstępna wersja programu PowerShell.
  • Zarejestrowana usługa nie używa opublikowanych danych wyjściowych aplikacji z dotnet publish polecenia. Dane wyjściowe polecenia dotnet build nie są obsługiwane w przypadku wdrażania aplikacji. Opublikowane zasoby znajdują się w jednym z następujących folderów w zależności od typu wdrożenia:
    • bin/Release/{TARGET FRAMEWORK}/publish (FDD)
    • bin/Release/{TARGET FRAMEWORK}/{IDENTYFIKATOR ŚRODOWISKA URUCHOMIENIOWEGO}/publikowanie (SCD)
  • Usługa nie jest w stanie URUCHOMIONYm.
  • Ścieżki do zasobów, których aplikacja używa (na przykład certyfikatów), są nieprawidłowe. Podstawowa ścieżka usługi Windows to c: \ Windows \ System32.
  • Użytkownik nie ma uprawnień do logowania się jako usługa.
  • Hasło użytkownika wygasło lub zostało niepoprawnie przekazane podczas wykonywania New-Service polecenia programu PowerShell.
  • Aplikacja wymaga uwierzytelniania ASP.NET Core, ale nie jest skonfigurowana do bezpiecznego połączenia (HTTPS).
  • Port adresu URL żądania jest niepoprawny lub nie jest poprawnie skonfigurowany w aplikacji.

Dzienniki zdarzeń systemu i aplikacji

Uzyskaj dostęp do dzienników zdarzeń systemu i aplikacji:

  1. Otwórz menu Start, wyszukaj Podgląd zdarzeń, a następnie wybierz Podgląd zdarzeń aplikację.
  2. W Podgląd zdarzeń otwórz węzeł Windows Dzienniki.
  3. Wybierz pozycję System, aby otworzyć dziennik zdarzeń systemu. Wybierz pozycję Aplikacja, aby otworzyć dziennik zdarzeń aplikacji.
  4. Wyszukaj błędy związane z aplikacją, która się nie pomyliła.

Uruchamianie aplikacji w wierszu polecenia

Wiele błędów uruchamiania nie zawiera przydatnych informacji w dziennikach zdarzeń. Przyczynę niektórych błędów można znaleźć, uruchamiając aplikację w wierszu polecenia w systemie hostingu. Aby rejestrować dodatkowe szczegóły z aplikacji, obniż poziom dziennika lub uruchom aplikację w środowisku dewelopera.

Wyczyść pamięci podręczne pakietów

Działanie aplikacji może się nie powieść natychmiast po uaktualnieniu zestaw .NET Core SDK na komputerze dewelopera lub zmianie wersji pakietu w aplikacji. W niektórych przypadkach niespójne pakiety mogą przerwać aplikację podczas przeprowadzania głównych uaktualnień. Większość z tych problemów można rozwiązać, korzystając z następujących instrukcji:

  1. Usuń foldery bin i obj.

  2. Wyczyść pamięci podręczne pakietów, wykonując polecenie dotnet nuget locals — wyczyść je z powłoki poleceń.

    Czyszczenie pamięci podręcznych pakietów można również wykonać za pomocą nuget.exe i wykonania polecenia nuget locals all -clear . nuget.exe nie jest instalowana w pakiecie z systemem operacyjnym Windows Desktop i należy ją uzyskać oddzielnie z witryny NuGet sieci Web.

  3. Przywracanie i ponowne kompilowanie projektu.

  4. Przed ponowne wdrożeniem aplikacji usuń wszystkie pliki z folderu wdrożenia na serwerze.

Aplikacja, która działa wolno lub nie odpowiada

Zrzut awaryjne jest migawką pamięci systemu i może pomóc w ustaleniu przyczyny awarii aplikacji, niepowodzenia uruchamiania lub powolnej aplikacji.

Aplikacja ulega awarii lub napotyka wyjątek

Uzyskiwanie i analizowanie zrzutu z Raportowanie błędów systemu Windows (WER):

  1. Utwórz folder do przechowywania plików zrzutu awaryjnego w folderze c:\dumps .

  2. Uruchom skrypt EnableDumps programu PowerShell z nazwą pliku wykonywalnego aplikacji:

    .\EnableDumps {APPLICATION EXE} c:\dumps
    
  3. Uruchom aplikację w warunkach, które powodują awarię.

  4. Po zakończeniu awarii uruchom skrypt programu PowerShell DisableDumps:

    .\DisableDumps {APPLICATION EXE}
    

Po awarii aplikacji i zakończeniu zbierania zrzutów aplikacja może zakończyć się normalnie. Skrypt programu PowerShell konfiguruje usługę WER do zbierania maksymalnie pięciu zrzutów na aplikację.

Ostrzeżenie

Zrzuty awaryjne mogą zająć dużą ilość miejsca na dysku (każdy z nich może mieć do kilku gigabajtów).

Aplikacja nie odpowiada, kończy się niepowodzeniem podczas uruchamiania lub działa normalnie

Gdy aplikacja zawiesza się (przestaje odpowiadać, ale nie ulega awarii), kończy się niepowodzeniem podczas uruchamiania lub działa normalnie, zobacz Pliki zrzutu w trybie użytkownika: wybieranie najlepszego narzędzia w celu wybrania odpowiedniego narzędzia do tworzenia zrzutu.

Analizowanie zrzutu

Zrzut można przeanalizować przy użyciu kilku metod. Aby uzyskać więcej informacji, zobacz Analyzing a User-Mode Dump File (Analizowanie pliku zrzutu User-Mode zrzutu).

Dodatkowe zasoby