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:
- Timeout for stopping dependent services in Stop() is extremely long (30 secs).
Which service takes even half of that time to stop itself? In my experience, when a stop request timed out instead of taking a couple of seconds to complete, it was because the dependent service somehow ignored it and refused to stop, causing my application to wait 30 seconds uselessly without having the ability to prevent it.
I would suggest to reduce the timeout to something around 10 secs and/or add an overload to Stop that accepts a TimeSpan that specifies the timeout. - Stop method could be more convenient to use.
The function DoStopSvcin 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). - System.ServiceProcess.TimeoutException message lacks the name of the service.
The Stop method can raise a TimeoutException when a dependent service can't be stopped in time. The problem is that the exception doesn't tell which is the service that caused the timeout. Could this information be added in the message?
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.
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:
Which service takes even half of that time to stop itself? In my experience, when a stop request timed out instead of taking a couple of seconds to complete, it was because the dependent service somehow ignored it and refused to stop, causing my application to wait 30 seconds uselessly without having the ability to prevent it.
I would suggest to reduce the timeout to something around 10 secs and/or add an overload to Stop that accepts a TimeSpan that specifies the timeout.
The function
DoStopSvcin 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).The Stop method can raise a TimeoutException when a dependent service can't be stopped in time. The problem is that the exception doesn't tell which is the service that caused the timeout. Could this information be added in the message?
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.