tag net asp c# asp.net .net asp.net-core

net - tag c#



.Net Core 2.0 Servicio de Windows (7)

Ahora es posible escribir un Servicio de Windows en .NET Core 2.0 sin bibliotecas de terceros, gracias al lanzamiento del Paquete de compatibilidad de Windows (en el momento de la escritura, aún en versión preliminar). Como la propia página advierte:

Pero antes de comenzar a migrar, debe comprender qué desea lograr con la migración. Solo portar a .NET Core porque es una nueva implementación de .NET no es una razón suficiente (a menos que sea un verdadero fan).

En particular, ahora es posible escribir un Servicio de Windows en .NET Core, pero no obtendrá la compatibilidad multiplataforma de la caja, ya que los ensamblajes para plataformas distintas de Windows solo emitirán una excepción PlatformNotSupportedException si intenta usar el código de servicio . RuntimeInformation.IsOSPlatform esto es posible (utilizando RuntimeInformation.IsOSPlatform , por ejemplo), pero esa es otra pregunta.

Además, las bibliotecas de terceros pueden seguir ofreciendo una interfaz más agradable con respecto a la instalación del servicio: en el momento de la escritura, la versión actual del paquete de compatibilidad ( 2.0.0-preview1-26216-02 ) no es compatible con System.Configuration.Install espacio de nombres, por lo que el enfoque predeterminado con una clase ServiceProcessInstaller e installutil no funcionará. Más sobre eso más adelante.

Con todo lo dicho, supongamos que ha creado un nuevo servicio de Windows ( Service1 ) a partir de la plantilla del proyecto (no es estrictamente necesario ya que no contiene nada interesante, aparte de una clase heredada de ServiceBase ). Todo lo que necesita hacer para construir en .NET Core 2.0 es editar y reemplazar el .csproj con el nuevo 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>

Y luego elimine properties/AssemblyInfo.cs ya que ya no es necesario y entrará en conflicto con la información de la versión en el propio proyecto.

Si ya tiene un servicio y tiene dependencias, la conversión puede ser más complicada. Ver here

Ahora debería poder ejecutar la dotnet publish y obtener un ejecutable. Como se mencionó, no puede usar la clase ServiceProcessInstaller para instalar el servicio, por lo que tendrá que hacerlo manualmente.

  • registrar la fuente de eventos que utiliza el servicio;
  • crear el servicio real.

Esto se puede hacer con algunos PowerShell. Desde un indicador elevado en la ubicación que contiene su ejecutable publicado:

$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)

Esto no es ideal de varias maneras: esto codifica la ruta del archivo de recursos de mensajes (realmente deberíamos determinar dónde está desde el ejecutable y las rutas de tiempo de ejecución en el registro), y codifica el nombre del servicio y el ejecutable nombre. Si lo desea, puede darle a su proyecto sus propias capacidades de instalación haciendo un análisis de línea de Program.cs en Program.cs , o usar una de las bibliotecas mencionadas en la respuesta de Cocowalla .

Estoy tratando de construir un servicio de Windows en .Net Core 2.0, pero me he estado golpeando la cabeza en la pared durante todo un día y no he progresado en absoluto. Todo parece estar usando Core 1.0 / 1.1, incluso la documentación de Microsoft:

Alojar una aplicación Core ASP.NET en un servicio de Windows

TopShelf no soporta 2.0 también, por lo que he visto.

He visto algunas soluciones extrañas que ponen todo el código en una biblioteca de clase estándar .Net y luego usan una aplicación .Net Framework para alojar el servicio de Windows, pero esto no parece elegante a mis ojos y estoy tratando de obtener deshacerse de .Net Framework en conjunto.

¿Es lo que quiero hacer incluso posible en este momento? ¿Me falta algo realmente básico?

Como Microsoft lanzó Microsoft.Windows.Compatibility, lo usaría, ya que parece ser lo mejor para un uso futuro.

El ejemplo simple del servicio de autoinstalación está aquí https://github.com/janantos/service_core

En .NET Core 2.1, puede utilizar el Host y HostBuilder para obtener una aplicación de consola que se ejecute como un servicio. Si almacena en contenedores su aplicación de consola, puede implementar el contenedor en cualquier lugar y es lo mismo que ejecutar como un servicio. Puede utilizar el Host y el HostBuilder para administrar DI, el registro, el apagado correcto, etc. en su aplicación de consola. Mira esto:

Servicios de alojamiento en consola .NET Core.

Para alojar .NET Core 2.0 Web API como servicio de Windows. Seguí esta guía Host ASP.NET Core en un servicio de Windows . La parte de requisitos previos no está clara para mí. Después de algunos errores, esto es lo que hice: Código fuente

  1. Crear una aplicación web principal de ASP.NET
  2. Elija API
  3. Edite el archivo .csproj, debe cambiar el marco de destino de netcoreapp2.0 a net461 , enumere explícitamente todas las referencias de paquetes en lugar de usar Microsoft.AspNetCore.All , como se indica a continuación

<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 [solución-carpeta] publicación de dotnet -o "[publicación-carpeta]"
  2. power shell [solution-folder] sc.exe create CoreApi binpath = "[publish-folder] / CoreApiHostedAsWindowsService.exe"
  3. power shell [solution-folder] sc.exe start CoreApi
  4. visite el api power shell predeterminado [solución-carpeta] Invoke-WebRequest http://localhost:5000/api/values

Tal vez esto sea una completa anulación, pero recuerde que con un mayor soporte de la ventana acoplable, puede construir un servicio que se ejecute dentro de un contenedor. En ese momento, aún sería .net core (2.0) pero ejecutándose en su caja de Windows. Además, podría implementarse en cualquier lugar en el futuro.

A medida que el núcleo de dotnet madura, esta es una solución mejor y mejor, asumiendo que su servicio no requiere recursos locales para el host.

Una forma fácil de crear un servicio .NET Core para Windows es utilizando la DotNetCore.WindowsService Peter Kottas.

El paquete NuGet es PeterKottas.DotNetCore.WindowsService . Para instalarlo usando la consola de Visual Studio Package Manager, simplemente ejecute

Install-Package PeterKottas.DotNetCore.WindowsService

También hay buenas notas sobre cómo empezar .

Voy a resumir algunas opciones:

  1. Mueva su código a una biblioteca estándar de .NET y hospédelo en una aplicación de .NET Framework, para que pueda usar ServiceBase . Por supuesto, esto necesitará el .NET Framework para instalarse en la máquina de destino.
  2. Use nssm (el administrador de servicios de no succión) para administrar una aplicación de consola .NET Core (tiene una licencia de dominio público)
  3. Utilice las llamadas a la API de Windows para conectarse a los métodos de servicio de Windows. Este es el enfoque adoptado por DotNetCore.WindowsService y DotNetCore.WindowsService github.com/dasMulli/dotnet-win32-service (ambos tienen licencia MIT)

Creo que el comentario de @ JeroenMostert es un poco duro: puedo ver el atractivo de no depender de que una versión particular de .NET Framework esté disponible en las máquinas de destino. Muchos otros obviamente sienten lo mismo, ya que los 2 repos a los que estoy vinculado son bastante populares.