Giờ đây bạn có thể viết Dịch vụ Windows trong .NET Core 2.0 mà không có thư viện của bên thứ ba, nhờ vào việc phát hành Windows Compatibility Pack (tại thời điểm viết thư, vẫn còn trong quá trình phát hành trước).Khi trang tự cảnh báo:
Nhưng trước khi bạn bắt đầu chuyển, bạn nên hiểu những gì bạn muốn thực hiện với việc di chuyển. Chỉ cần chuyển sang .NET Core vì nó là triển khai .NET mới không phải là một lý do đủ tốt (trừ khi bạn là True Fan).
Cụ thể, viết Dịch vụ Windows trong .NET Core hiện có thể thực hiện được, nhưng bạn sẽ không nhận được tính tương thích đa nền tảng, vì hội đồng dành cho nền tảng không phải Windows sẽ chỉ ném PlatformNotSupportedException nếu bạn cố gắng sử dụng mã dịch vụ. Làm việc xung quanh điều này là có thể (ví dụ như sử dụng RuntimeInformation.IsOSPlatform), nhưng đó là một câu hỏi khác hoàn toàn.
Ngoài ra, thư viện của bên thứ ba vẫn có thể cung cấp giao diện đẹp hơn liên quan đến cài đặt dịch vụ: bằng văn bản, phiên bản hiện tại của gói tương thích (2.0.0-preview1-26216-02) không hỗ trợ không gian tên System.Configuration.Install. ServiceProcessInstaller lớp học và installutil sẽ không hoạt động. Thêm về điều đó sau. Với tất cả những gì đã nói, hãy giả sử bạn đã tạo một dịch vụ Windows hoàn toàn mới (Service1) từ mẫu dự án (không bắt buộc vì nó không chứa gì thú vị, ngoài một lớp kế thừa từ ServiceBase). Tất cả bạn cần làm gì để làm cho nó xây dựng trên .NET Lõi 2.0 là để chỉnh sửa và thay thế các .csproj với định dạng mới:
<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>
Và sau đó xóa properties\AssemblyInfo.cs kể từ khi nó không còn cần thiết và sẽ mâu thuẫn với thông tin phiên bản trong dự án.
Nếu bạn đã có dịch vụ và dịch vụ có phụ thuộc, việc chuyển đổi có thể phức tạp hơn. Xem here.
Bây giờ, bạn có thể chạy dotnet publish và nhận tệp thực thi. Như đã đề cập, bạn không thể sử dụng lớp ServiceProcessInstaller để cài đặt dịch vụ, vì vậy bạn sẽ phải tự
- đăng ký nguồn sự kiện mà dịch vụ sử dụng;
- tạo dịch vụ thực tế.
Điều này có thể được thực hiện với một số PowerShell. Từ một nâng lên nhanh chóng ở vị trí có chứa thực thi được công bố của bạn:
$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)
Đây không phải là lý tưởng bằng nhiều cách: này cứng mã đường dẫn của tập tin tài nguyên thông điệp (chúng tôi thực sự cần được xác định nó ở đâu từ đường dẫn thực thi và đường dẫn thời gian chạy trong sổ đăng ký) và mã hóa cứng tên dịch vụ và tên thực thi. Bạn có thể muốn cung cấp cho dự án khả năng cài đặt của riêng mình bằng cách thực hiện một số phân tích cú pháp dòng lệnh trong Program.cs hoặc sử dụng một trong các thư viện được đề cập trong Cocowalla's answer.
Bản sao có thể có của [Dịch vụ Windows với .NET Core] (https://stackoverflow.com/questions/41014513/windows-service-with-net-core) –
'cố gắng loại bỏ toàn bộ Khung.Net' trong khi cố gắng xây dựng dịch vụ _Windows_ có thể là một trận chiến khó khăn .. – thisextendsthat