I am working on a client server project. Client is built in WPF using mvvm pattern and service is built using WCF. I have to perform some action on a specific event which I am able to do by calling some service functions. I will have to do call the same function on a regular basis at a specific time as configured in database. Can somebody suggest a better approach to achieve this. I am thinking of creating a windows service specifically to do such things. Is that a good choice ? Thanks a lot.
Create a console app that calls the service, and add a scheduled task in Windows to run the console app at a specified interval. It is a lot easier and cleaner than creating a service for such a simple application.
I think the best approach is to use an already created (and properly tested) scheduling system or library instead of developing your own. For a Java project I worked on, I used the Quartz library, which handled the job quite nicely and it integrated easily into said project. It has a .NET port here, never used it but I suppose it works similarly.
Related
I need a good and easy way to "Talk" to a windows service in C#
I have been able to create a windows service and start, stop, pause and continue it using a windows forms application.
My question is
Which is better and/or easier to accomplish this? WCF or Named Pipes? Or is it easier to do it using a file and make the service check it after some interval continuously?
I am very unfamiliar with both concepts(wcf and named pipes). So basically what i am asking is:
Which is worth my time? WCF or Named Pipes?
Thank you in advance :)
Ok, just provide a simple interface in c# with the following codes for doing what you wanted start,stop,restart etc
http://www.csharp-examples.net/restart-windows-service/
additionally, you may want to look into
SC commands which are specifically a way to interact with windows services..
http://msdn.microsoft.com/en-us/library/windows/desktop/ms682107(v=vs.85).aspx
or even WMIC for remote access
http://msdn.microsoft.com/en-us/library/ms186146%28v=VS.80%29.aspx
This is my first time dabbling in windows services.
I have a service I would like to manage, I would like to be able to connect to this service via a command line / REPL of sorts to avoid the development time of working on a user interface. I was thinking we could communicate much like attaching to an Asterisk daemon or somewhat like connecting to a MySQL server which to me seems like nothing more than a simple custom shell spawned to handle requests. However, I am always concerned about how efficient my code is and would like to keep to common practices. This will be connecting on the same local machine.
My proposed solution:
I believe I can make simple network stream, to create a simple Read - Eval - Print - Loop.
Another option is to use WCF, however my question would then be, how efficient is this as opposed to packet handling?
My question:
What are some standard practices for communicating with or managing services on the local machine?
I'm trying to learn more about service-oriented design, any resources that could help explain common practice models would be much appreciated.
Of course there are so many ways to do this. The way I would recommend is to make sure you use log4net (or some other logging framework) and log the important info. Create the solution with 3 projects, the first will be the "service logic" or the business service, with the second being the windows service wrapper that starts that service, and the third being a console app that does much the same as the windows service only giving you the ability to interact as you wish. The advantage of the console logging appender is that you still get the console output without actually writing to the console... it give good separation.
I will give another option that I have used in the past, but would give with caution. You can selfhost a WCF service inside a windows service. It gives a nice interface that gets away form the messy self rolled TCP server approach. The caution is that if done wrong it can eat up lots of memory and CPU cycles.
I am working on windows service application that is suppose to perform some tasks. Apart from these tasks, I want to make some of the service functionality available on call. Means, totally separated application should be able to create an object of type specified on windows service and can call some of the functions, decalred public, ofcourse.
Let me know if is there any way to expose the functionality through API or something. if yes, kindly guide me to any tutorial or example of that.
Thanks in advance.....
I think what you are looking for is a windows service using WCF to communicate with other applications.
Here's a pretty neat tutorial you can work through:
http://tech.pro/tutorial/855/wcf-tutorial-basic-interprocess-communication
I have some VBA code that needs to talk to a running c# application.
For what it's worth, the c# application runs as a service, and exposes an interface via .net remoting.
I posted a question regarding a specific problem I'm having already (From VB6 to .net via COM and Remoting...What a mess!) but I think I may have my structure all wrong...
So I'm taking a step back - what's the best way to go about doing this?
One thing that's worth taking into account is that I want to call into the running application - not just call a precompiled DLL...
In the past, one way I accomplished something similar was with Microsoft Message Queueing. Both languages/platforms can read/write to a queue.
In my scenario, we had a legacy Access database that we had to maintain. We wanted to migrate away from it and replace it with a more robust .NET solution. To get real time data out of the current system into the new system, we added VBA code to write data to a message queue. Then we wrote a C# windows service to process that data in the new system.
I'm not entirely sure of what you're doing, so this may not be a fit, but I thought I'd mention it.
I've come up with a solution using my original structure...
That is, the VBA application calls a COM wrapper application that translates all of the types from .Net to COM safe types. This wrapper then calls the main service using .net remoting.
The problem I was having was that the common dlls between the wrapper and the service needed to be in the C:\Program Files\Microsoft Office\Office12 folder (along side msaccess.exe).
While I was using the AssemblyResolve method to provide the dlls at runtime, this wasn't working...So for now I'll just have to have the dlls copied to the folder - a far from elegant solution, but at least the communication is working for now.
I've written a console app that sends MS Reports to emails.. (the reason was that i could check it easily if it works)
I want this to run daily at 6 am.
My idea was to write a service (so nooone will need to be logged in and the service will run).
So I'd like to call the static Method directly in a WebService.
I've a solution with 1 project file that is my console application (with settings, many references.. etc). I'd like to add another project - Windows Service.
My question is.. how to do that easily, so I wouldn't have to copy all classes etc to the Windows Service project?
Or am I totaly off the way? :)
Thank you!
Sounds like overkill to use a Windows Service to send an email once a day. Why not just schedule a task in Task Scheduler?
You're going to have to refactor your app. I'd recommend three projects -
Console App - instantiates and performs any neccessary set up on your business logic object then routes all output to the console. Use this for debugging and testing
Business logic - Extract all the logic of your application into this class.
Service - Basically the same as the console app except that I would recommend sending any errors to the global event logger. That way if your service bombs you can find out why.
You can use this pattern for any other services you develop.
Create a class library and put the shared classes in that library.