I have developed a C# program, although when I try and create a service from it e.g.
sc create "servicetest" binPath=
"C:\Users\Admin\Desktop\test\test.exe" start= auto error= ignore
I get the following message:
[SC] StartService FAILED 1053:
The service did not respond to the start or control request in a timely fashion.
You need to create it as a service through the Visual Studio interface, which will provide you with the correct classes and methods you need to implement.
You need to base your application on the Windows Service template available in Visual Studio (not available in the Standard Edition.) See here:
How to: Create Windows Services
There is also another way of implementing windows service using TopShelf. You can actually run a console application as windows service using topshelf. Advantage of it is easy to debug. As far As I know when you want to debug windows service, you have start the service in service console. Stop the service if you are compiling and service installed from build output directly. It is extra painful step.
If you are using topshelf, you can start the service like how you start windows forms application to debug. There are other benefits too. Please refer the web site.
Related
I need to have a windows service that is configured with simple UI. I understand, that I need to create an API for windows service and use it in separate desktop application. But whatever I google I just got "you can't create UI to windows service" or info about webservice. I found this https://www.codeproject.com/Articles/1159908/Yes-I-Know-But-I-Still-Want-a-GUI-for-my-Windows-S but this seems to be a pretty bad workaround, because I can't use already started service in my GUI using it. What I need is some code, explaining how to create a connection between these two applications
I have a WCF CRUD REST API up and running in a Windows Service. All is well.
I'd like to offer the user the ability to run that inprocess as well; so, instead of running a service (which would require admin) I'd like to have a static library version as well.
With .NET (C#) how would I go about this? Right now I have:
ServiceLib (interesting code)
ConsoleHost
GUI
I'd like the GUI to selectively be able to run the ServiceLib code as a full-fledged Windows Service -OR- just as in-process code. The service way already works, which I assume is harder.
If you run it now in a Windows service it's already self-hosting, I assume? If GUI app will be the only one using the service in the "in process" mode you can split your "WCF CRUD REST API" ServiceLib into two - one implementing CRUD part and second implementing WCF REST API on top of it. In GUI you'll need only the CRUD part, so no need to bother with self-hosting of REST API in the same (and only) application that's going to call it.
Running a GUI app as a Windows service is usually a pretty bad idea anyway from the sysadmin's point of view. I often run console apps that can be either WCF hosting Windows services or just WCF hosts, but their only GUI is ablility to react to Ctrl-C.
I've created a Windows Form Application in C# and I added a Window Service on it. The problem is every time I started the Service after installing it, I always get the Error 1053 the service did not respond to the start or control request. But after creating a new project and Select Windows Service and Installed and Run it there's no error and the Service is Starting correctly.
So do I have to create a Separate project for Windows Service or I am just missing something?
My target Framework is 4.5.2 and I am planning to have UDP and TCP function inside my Windows Service.
Calling ServiceBase.Run() from Main() is what makes an application a service rather than a normal application. If you created a project using the Windows Service template, but took away the call to ServiceBase.Run(), the result would be a normal application rather than a service. (Probably a broken application, but an application nonetheless.)
Under the hood, ServiceBase.Run() calls StartServiceCtrlDispatcher(), which calls the internal ServiceBase.ServiceMainCallback() function, which calls your OnStart() function. So if you don't call Run() there will be no call to OnStart() and your service won't do anything.
The StartServiceCtrlDispatcher() function is also indirectly responsible for calling OnStop() and all the other related methods. Basically, it's the core of the service, and without it nothing will work. Also, of course, if you don't call it Windows will eventually notice that the control dispatcher hasn't started, assume that the process has hung, and kill it. That's what error 1053 means.
While it is possible to incorporate both a service and an application in a single executable, it isn't trivial to get it working properly. It is also an unusual approach, not often used. Unless you have a compelling reason to avoid doing so, I'd recommend that you use a separate project for your service.
I have a workflow application hosted (for now) in a Console Application, using WorkflowServiceHost to host an activity. This was based on a MS example, and works fine.
I'd like to add another 'WebMethod' to this application. This method has nothing to do with the workflow being hosted - it will simply be a 'ping' service so that clients can tell that the application is alive and running.
Is this even possible? If so, how would I go about adding this new method?
Thanks
Don't create a new method inside the Console Application as that would be poor practise (1 thing should do 1 job)
Instead create a new WCF project inside your solution.
Reference this project in your Console app and start the WCF host when the Console app initializes.
The WCF project can then be written to respond to 'ping' requests.
This is a handy primer in WCF
http://www.codeproject.com/Articles/406096/A-beginners-tutorial-for-understanding-Windows
Richard,
Thanks for your answer. I was able to add a new endpoint to the Console App but defining the service interface, and adding another host and starting it.
This is fine for the proof-of-concept code, but wouldn't be acceptable for release.
Dave
As in title I would like to ask what is difference between using these possibilities of hosting my code on Windows Service. As far as I can see, all three allow me to create exe which will be installed as a service.
Topshelf is my preference because it allows you to get the best of both worlds a service and a console application. Using sc.exe allows you to execute any console application as a service, but the exe doesn't interact as a service itself. Developing a Windows Services directly let's you have a service and interact as one with Windows, but it isn't easy to debug or run as a normal console application. Topshelf allows you to ge the best of both running as a Service and running as a normal console application.
Windows Services are special application types that respond to service control messages like Start, Stop, Pause, Continue etc.
While it is true that you can use something like sc.exe to turn any kind of process into a service, those processes will not handle the previously mentioned control messages. What you will commonly find is you'll be able to start a process but not stop it etc.
What I tend to do is abstract my services out (I think Topshelf does this), have a service library that can be loaded by a native Windows Service application or a console application so that I can have the best of both worlds (usually debugging under console).