I've been using the ServiceController class for some time now in an application of mine and I personally find that some features of the API could be improved. Here they are:
DoStopSvc in this official WinAPI example checks if a stop is already pending before sending the stop control to the service, and in any case it waits for the service to stop before returning. Could ServiceController.Stop do the same? Waiting for a service to become stopped after a stop request is such a common use case that would be very convenient if Stop did it (it already does it when stopping dependent services).If you decide it's ok to proceed with these changes, I can take care of implementing them (for the last one I'd need some guidance on how to change exception messages resources).
PS: I wasn't sure whether to split this issue in multiple ones at this time since it is meant as a discussion on the topic.
We would certainly be interested in a PR that makes the exception(s) more useful.
Ok, I'll look into it when I have some time. Can you point me in the right direction on how to change/add new exception message resources? (is some special operation needed?)
And what about the other two proposals?
No special process for the exceptions..just a PR.
@Anipik is owner of this area and could comment on the other two suggestions
@Fs00 I will take a look at the two proposals and update the issue.
@Anipik Any news on those two proposals?
Any news on those two proposals?
i will get back to u by tonight
and/or add an overload to Stop that accepts a TimeSpan that specifies the timeout.
You can write api proposal for it and we will happy to take it. Here is goo example of an proposal https://github.com/dotnet/runtime/issues/15725
Changing the default value of 30 secs would be an issue as it might break some body else.
Stop method could be more convenient to use.
Feel free to throw up a pr to improve this.
@Anipik After some thoughts, I've decided that it's better for consistency and compatibility to leave the Stop() method as-is. Instead, I've made a proposal for a new Stop overload with the improvements I'd like to see.
Most helpful comment
@Anipik After some thoughts, I've decided that it's better for consistency and compatibility to leave the Stop() method as-is. Instead, I've made a proposal for a new Stop overload with the improvements I'd like to see.