Domanda .Net Core 2.0 Servizio Windows


Sto cercando di creare un servizio Windows in .Net Core 2.0 ma ho sbattuto la testa contro il muro per un giorno intero e senza alcun progresso. Tutto sembra utilizzare Core 1.0 / 1.1 anche la documentazione di Microsoft:

Ospita un'app di ASP.NET Core in un servizio di Windows

Ripiano superiore non supporta anche 2.0, per quello che ho visto.

Ho visto alcune strane soluzioni che inseriscono tutto il codice in una libreria di classi standard .Net e poi usano un'applicazione .Net Framework per ospitare il servizio di Windows, ma questo non sembra elegante ai miei occhi e sto cercando di ottenere liberarsi completamente di .NET Framework.

È quello che voglio fare anche in questo momento? Mi manca qualcosa di veramente semplice?


23
2017-10-04 09:39


origine


risposte:


È ora possibile scrivere un servizio Windows in .NET Core 2.0 senza librerie di terze parti, grazie al rilascio di Windows Compatibility Pack (al momento della scrittura, ancora in prerelease). Come avverte la pagina stessa:

Ma prima di iniziare il porting, dovresti capire cosa vuoi fare   compire con la migrazione. Basta effettuare il porting su .NET Core perché è così   una nuova implementazione .NET non è una buona ragione (a meno che tu non sia un   Vero fan).

In particolare, è possibile che sia possibile creare un servizio Windows in .NET Core, ma non si otterrà la compatibilità multipiattaforma, poiché gli assembly per piattaforme diverse da Windows generano solo un PlatformNotSupportedException se si tenta di utilizzare il codice di servizio. È possibile aggirare questo problema (usando RuntimeInformation.IsOSPlatformper esempio), ma questa è un'altra domanda.

Inoltre, le librerie di terze parti possono ancora offrire un'interfaccia migliore per quanto riguarda l'installazione del servizio: al momento della scrittura, la versione corrente del pacchetto di compatibilità (2.0.0-preview1-26216-02) non supporta il System.Configuration.Install namespace, quindi l'approccio predefinito con a ServiceProcessInstaller classe e installutil non funzionerà. Maggiori informazioni in seguito.

Con tutto ciò che detto, supponiamo che tu abbia creato un nuovissimo servizio Windows (Service1) dal modello del progetto (non strettamente necessario poiché non contiene nulla di interessante, diverso da una classe che eredita da) ServiceBase). Tutto ciò che devi fare per farlo costruire su .NET Core 2.0 è quello di modificare e sostituire il .csproj con il nuovo formato:

<Project Sdk="Microsoft.NET.Sdk" ToolsVersion="15.0">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp20</TargetFramework>
    <RuntimeIdentifier>win-x64</RuntimeIdentifier>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.Windows.Compatibility" Version="2.0.0-*" />
  </ItemGroup>
</Project>

E poi cancella properties\AssemblyInfo.cs poiché non è più necessario e sarà in conflitto con le informazioni sulla versione nel progetto stesso.

Se hai già un servizio e ha dipendenze, la conversione potrebbe essere più complicata. Vedere Qui.

Ora dovresti essere in grado di correre dotnet publish e ottieni un eseguibile Come accennato, non è possibile utilizzare il ServiceProcessInstaller classe per installare il servizio, quindi dovrai manualmente

  • registrare la fonte di eventi utilizzata dal servizio;
  • creare il servizio effettivo.

Questo può essere fatto con alcuni PowerShell. Da un prompt con privilegi elevati nel percorso che contiene il file eseguibile pubblicato:

$messageResourceFile = "C:\Windows\Microsoft.NET\Framework64\v4.0.30319\EventLogMessages.dll"
New-EventLog -LogName Application -Source Service1 -MessageResourceFile $messageResourceFile
sc.exe create Service1 binPath= (Resolve-Path .\WindowsService1.exe)

Questo non è l'ideale in diversi modi: questo hardcodifica il percorso del file di risorse del messaggio (dovremmo davvero determinare dove si trova dal file eseguibile e dai percorsi di runtime nel registro) e codifica il nome del servizio e l'eseguibile nome. Potresti voler dare al tuo progetto le proprie capacità di installazione eseguendo l'analisi della riga di comando Program.cs, o usare una delle librerie menzionate in La risposta di Cocowalla.


14
2018-02-27 14:30



Riassumerò alcune opzioni:

  1. Spostare il codice in una libreria .NET Standard e ospitarla in un'app .NET Framework, quindi è possibile utilizzarla ServiceBase. Ciò richiederà ovviamente l'installazione di .NET Framework sul computer di destinazione
  2. Uso NSSM (il gestore di servizi non sucking) per gestire un'app di console di .NET Core (ha una licenza di dominio pubblico)
  3. Utilizzare le chiamate API di Windows per connettersi ai metodi di servizio di Windows. Questo è l'approccio adottato da DotNetCore.WindowsService e dotnet-win32-service (entrambi sono autorizzati dal MIT)

Penso che il commento di @ JeroenMostert sia un po 'duro: vedo l'attrattiva di non dipendere da una particolare versione di .NET Framework disponibile sui computer di destinazione. Molti altri ovviamente si sentono allo stesso modo, poiché i 2 repository a cui mi sono collegato sono piuttosto popolari.


9
2017-12-30 21:06



Per ospitare API Web .NET Core 2.0 come servizio Windows. Ho seguito questa guida Host ASP.NET Core in un servizio di Windows. Il Prerequisiti parte non è chiara per me. Dopo alcuni errori, ecco cosa ho fatto: Codice sorgente

  1. Creare un'applicazione Web principale ASP.NET enter image description here
  2. Scegli API enter image description here
  3. Modifica il file .csproj, è necessario modificare il framework di destinazione da netcoreapp2.0 a net461, elenca esplicitamente tutti i riferimenti del pacchetto piuttosto che l'utilizzo Microsoft.AspNetCore.All, come segue

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

  <PropertyGroup>
    <TargetFramework>net461</TargetFramework>
    <RuntimeIdentifier>win7-x64</RuntimeIdentifier>
    <!--<TargetFramework>netcoreapp2.0</TargetFramework>-->
  </PropertyGroup>

  <ItemGroup>
    <Folder Include="wwwroot\" />
  </ItemGroup>

  <ItemGroup>
    <!--<PackageReference Include="Microsoft.AspNetCore.All" Version="2.0.6" />-->
    <PackageReference Include="Microsoft.AspNetCore" Version="2.0.2" />
    <PackageReference Include="Microsoft.AspNetCore.Hosting.WindowsServices" Version="2.0.2" />
    <PackageReference Include="Microsoft.AspNetCore.Mvc" Version="2.0.3" />
    <PackageReference Include="Microsoft.AspNetCore.StaticFiles" Version="2.0.2" />
    <PackageReference Include="Microsoft.Extensions.Logging.Debug" Version="2.0.1" />
    <PackageReference Include="Microsoft.VisualStudio.Web.BrowserLink" Version="2.0.2" />
  </ItemGroup>

  <ItemGroup>
    <DotNetCliToolReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Tools" Version="2.0.3" />
  </ItemGroup>

</Project>

  1. power shell [soluzione-cartella] dotnet publish -o "[publish-folder]"
  2. power shell [soluzione-cartella] sc.exe crea CoreApi binpath = "[publish-folder] \ CoreApiHostedAsWindowsService.exe"
  3. power shell [soluzione-cartella] sc.exe avvia CoreApi
  4. visita l'API predefinita power shell [soluzione-cartella] Invoke-WebRequest http: // localhost: 5000 / api / valori

9
2018-03-26 20:52



Forse si tratta di una completa esclusione, ma ricorda che con un supporto docker maggiore, potresti essere in grado di creare un servizio che viene eseguito all'interno di un contenitore. A quel punto, sarebbe ancora .net core (2.0), ma in esecuzione sulla tua finestra di Windows. Inoltre, è possibile distribuire praticamente ovunque in futuro.

Con la maturazione del core dotnet, questa è una soluzione migliore e migliore, presupponendo che il servizio non richieda risorse locali per l'host.


2
2018-01-20 19:58



In .NET Core 2.1 è possibile utilizzare Host e HostBuilder per ottenere un'applicazione per console che viene eseguita come servizio. Se si containerizza l'applicazione della console, è possibile distribuire il contenitore ovunque ed è come eseguire un servizio. È possibile utilizzare Host e HostBuilder per gestire DI, Logging, Graceful shutdown, ecc. Nell'app della console. Dai un'occhiata a:

Servizi di hosting nell'applicazione console Core .NET 


1
2017-08-06 06:39