Get running on `dotnet` cli / .NET Core
TravisTheTechie opened this issue · comments
dotnet cli will likely be the best bet for building cross platform executables moving forward. Once the API surface has settles down we can take a look at porting everything to do that, likely in additional to the existing supported platform versions.
I took a quick stab at this. Current issues...
- Service installer isn't exposed at part of core
- All our reflection bits have to be rewritten or shimmed
- Diagnostics packages appear to have changed (unclear by how much yet)
System.ServiceProcessis missingServiceAccount- AppDomains are bye-bye -- how do we handle unhandled exceptions?
- No serializable (might just be able to remove, hold over from 2.0 days?)
- Microsoft.Win32.Registry wasn't updated in last release, will it be missing from the core surface area?
- Win32 interop stuff (e.g.
SafeTokenHandle,NativeMethods) will likely need a rewrite
So I expect this will happen some day, but as of right now there wouldn't be feature parity between a .NET 4.5 and a .NET Core version. Some of these things might be resolved as the .NET team gets Core closer to release.
Rock on, great work Travis. I suspected that the bridge might be difficult to cross.
@jeremymeng Would you have any insight on the current outstanding issues?
I had some conversations with @terrajobst on this, and the ServiceBase will likely not be exposed. We would need to rebuild the service installer on Core to allow post hooks, or rework things totally. WiX was the suggested alternative, which doesn't really solve the same problem (but does allow installation of services).
@artganify sadly, Microsoft.AspNetCore.Hosting.WindowsService does not target .NET Core ~ see https://github.com/aspnet/Hosting/blob/dev/src/Microsoft.AspNetCore.Hosting.WindowsServices/project.json#L18
But if that changes, I'm happy to take another stab at this. We might be able to do it with a ".NET Core" which is just the .NET Core supported Console apps, then you have to import "Topshelf.WindowsService" or "Topshelf.Inetd" (or whatever) to support the platform you need. And Topshelf.WindowsService would only support .NET 4.5.2+, not the .NET Core platform. With netstandard coming, I hope we can do that 100% without retargeting any code for platforms. As it stands right now, it would require different assemblies for different platforms since the API surface area isn't 100% shared.
Hi Travis.. so judging by your comment on the 30th "we would need to rebuild the service installer ... rework things totally .." a .NET Core version is a very long way away ?
Am tempted to take a stab at investigating the effort BUT if you've already done the research ill probably look elsewhere for a .NET Core service wrapper (that works xplat too) ..
I think we'll wait until .NET Core is not in flux any more. There's still a lot of movement on the APIs. So... if you want something before then, you're best looking elsewhere. It will happen, but when it happens depends on other stuff happening first.
I hope it's not "very long way away" but I can't make any promises at this point.
Are we ready for this now?
There's still no service installer, etc
See https://gist.github.com/davidfowl/8939f305567e1755412d6dc0b8baf1b7 for a great overview of the different netstandard levels and what's generally available.
INetStandard15 (in that document's context) would be the minimum as it supports assembly loading (mentioned as important earlier in this thread). But there's still no concept of Windows-only things like the registry and services. They'd need to be in a separate package. So that would require some TopShelf refactoring to have a netstandard-based app to do running as a console application or embedded as a service, and then the service hosting stuff would need to be in a separate desktop-level .NET package.
(just thinking out loud - sounds like a fair bit of work and definitely some breaking changes)
It is a major effort. So it's not likely to happen soon.
We can maybe shuffle how we do things to get there sooner, but it has limited value without ServiceBase since at the root it's just a console runner. I accept that it would enable us to offer other service platforms -- but that's not a priority of any of the maintainers at the moment.
TopShelf is one of our cornerstone support packages and it would be great if it supported .Net Core. We are planning on moving our code base to the new framework, the last packages missing are TopShelf, RabbitMQ.Net and Google.ProtocolBuffers (although this has been merged into google/protobuf which is close to supporting .Net Core).
Also I believe that .Net Core has already hit 1.0.0 so I would expect the API to much more settled, though who knows with Microsoft!
This is definitely highly requested feature.
@TravisTheTechie I recently needed to deal with missing ServiceBase support myself, so i cerated an alternative that directly uses the necessary interop calls. Also made a CreateService(...) and DeleteService(...) on the way. https://github.com/dasMulli/dotnet-win32-service
Maybe that helps..
Also runs nicely on nano server.
The direction I understand is that more of the surface area is appearing in .NET Standard 2.0 and this will likely wait until that's delivered so we don't have to rewrite much, possibly breaking existing/working functionality.
@TravisTheTechie Just waiting for that. Some of my projects are still not dared to do a porting into .NET Core because of this reason.
I'm closing this issue to show we're taking no action on it at this time. Can reopen or create a new one once things are settled.
Well, should we reopen this finally?
What about this? https://github.com/dasMulli/dotnet-win32-service
Personally I really like TopShelf, but they seem to have a Windows Service for .Net Core.
.NET Core 2.0 is adding in the apis to make this work as part of the library I believe. I am using https://github.com/PeterKottas/DotNetCore.WindowsService currently for one of my services.
Yes, we should open this and get it working with .NET Core, as we update the entire MT stack to support CORE.
.NET Core 2.0 is adding in the apis to make this work
Doesn't look like it, https://github.com/dotnet/corefx/issues/6024 is still in "Future". Or am i missing something obvious @andymac4182 ?
The lib i've written (https://github.com/dasMulli/dotnet-win32-service) makes the necessary interop calls directly via PInvokes (ServiceBase doesn't do anything different..) and has a very simple state handling model (you can write a custom state machine if you need additional commands like pause/resume or special fancy events like power / network changes). It also doesn't work with InstallUtil.exe but exposes APIs to register/unregister (update coming soon) windows service registrations.
Since this really is only a basic API layer (like ServiceBase is), @PeterKottas wrote a layer on top of it to get an API that more resembles TopShelf.
Given the current .NET Core 2.0 API shape, TopShelf could either implement the interop calls itself or take a dependency on DasMulli.Win32.ServiceUtils (or copy the necessary files, they are just MIT licensed) to replace dependencies on ServiceBase (it's not a drop-in replacement though).
Happy to provide help and guidance if necessary.
Now that .NET Core 2 is out, is there any plan to porting topshelf on .NET core in the near future?
@alkampfergit I'm not a contributor so take this with a grain of salt, but a proper solution is likely blocked by the following, which is slated for .NET Core 2.1 (Q4 2017 according to https://github.com/dotnet/core/blob/master/roadmap.md):
I am curious if this is required due to the new IHostedService coming to dotnet core. https://www.stevejgordon.co.uk/asp-net-core-2-ihostedservice
Haven't spent enough time on it yet to see if it can do all the same things as TopShelf.
Are there any alternative libraries that I can use for this?
@kiranshub what's your need? there's my https://github.com/dasMulli/dotnet-win32-service for minimum support to get a windows service running with core.
@kiranshub also if you prefer Topshelf-like api feel free to check out https://github.com/PeterKottas/DotNetCore.WindowsService it uses @dasMulli s lib in the background and exposes an interface that I found slightly easier to use. Especially if you have experience with topshelf.
@TravisTheTechie ServiceBase was merged. What is missing to follow this port?