I am building an app that allows users to execute some commands on a computer by sending them through email. The server will monitor (pull) one or more email accounts and start a communication session. Some authentication is also involved. I am using the latest and greatest .net technologies.
I am thinking to expose the server as a service but then I cannot have a GUI to allow the user to configure things like passwords and email accounts. How can I separate these?
And second, the commands will be pluginable and should provide their own GUI. How can I incorporate this? The server process should be able to use the command functionality and the GUI process should allow for customization.
I have used WCF, which is Microsoft's current technology for implementing web services and/or SOA. You would create a desktop client or webpage that makes calls to the WCF service. The WCF service(s) would be your server component, and the desktop client or webpage would be your user frontend.
It's mainly not a question of how to make service itself. And communication protocol is not the main issue -- with WCF you can expose your application methods via spectre of protocols. It's merely a question of application configuration.
Main question here is how do you like to implement GUI. If your application is normal windows service, then it can't have built-in GUI. Just because service should not have it. So you'll need separate GUI application. Options:
GUI is standalone .NET application that somehow communicates with your service. Let's say via WCF. In this case plugins should also be implemented in two parts: plugin for service and plugin for GUI. I think, it would be too complex to support.
Modification of 1st variant. Both service and GUI are packed in one executable. It looks in what mode it's started (service or standalone) and either monitors mail or shows GUI. Since this is one application, the configuration is also the same. So you will have single registry for plugins. I assume, that in GUI mode application will search for started service and configure it. Drawback - GUI could be run only locally.
You make a sort of "transferrable" GUI - service sends GUI to simple client, which shows it. In this case you have one place for all app code (service and GUI), but it's executed in part in service, in part in client software. But you also need such universal client software.
Thinking a little more about variant 3 we see that solution already exists - it is web technologies. It would be simplest to implement your service as part a web site. And GUI would be another part. If you are unfamiliar with HTML and Javascript you can implement GUI using Silverlight.
In fact, you can host ASP.NET right in your service. Here is the good explanation. But I afraid it adds unnecessary complexity
Related
I'm trying to get started with an application that definitely requires some GUI for configuration management and the application has to poll a web service about every hour (to check for updates/messages) or so. Also, the application is expected to run constantly in the background/system tray.
I'm looking for some guidance on the overall architecture for this application design. Can this be a straight up WPF app or would it be better it is a windows service because of the polling and because it is expected for the application to be running all the time? Do you guys have any suggestions?
Firstly, services tend not to have a GUI. They can, but it's not advised.
What I would do, is have two applications. The service itself which performs the monitoring in question, and a user-interface application (that runs on startup), and provides an interface to the service. Communication between the two can be handled in a variety of ways.
The advantage to this is, your service will run even if there isn't a user logged on, and the UI part is present only when a user is on.
To allow for your GUI to communicate with the Windows Service you can expose WCF services on the Windows Service to provide the operations you need (e.g. Start, Stop, GetStatus, etc.).
See this article on MSDN for a starting point: http://msdn.microsoft.com/en-us/library/ms733069.aspx
I have a window desktop application, developed in C#.NET (.NET framework 4.0), but now I want to convert it into window services. There is one Window Form in desktop application. How is it possible? Any code or helping link is welcomed.
Thanks
It entirely depends upon what the application does. The main thing you have to remember is that when an app is running as a service it cannot have any user interaction, as it runs unattended.
Take a look at this for more background:
Introduction to Windows Service Applications
Or look at using SrvStart (a freeware utility) to run an existing app as a service:
Using SrvStart to Run Any Application as a Windows Service
There are also commercial tools that can convert Windows apps to run as services such as:
FireDaemon
AlwaysUp
Once an app is running as a service all comunication between a seprate UI presentation app is cross process - so you need to manage that. Depending on your skill set probably the easiest way to do that today is WCF. Your first step is to define the interface between the GUI client application and the service (what calls does GUI need to make on the serivice, are they oneway or duplex (return data), does the service need to trigger events client side (which requires a callback interface)? etc).
Once that is decided you can go ahead and start building your WCF service. That is a dll that needs to be hosted - in your case by a service host - this is quite straight forward and there is plenty on infomation available about that (basically just a few lines of boiler plate code and then run a utility to register the service). It is useful to test your server using a Command line host in place of the service host (easier to debug etc) - so worth while setting up 2 host projects (one service, one cmd line).
I've personally never tried a form client with a WCF service - if your form is simple you might find it easier to dev your client in WPF. The client uses the interface you defined to make calls on the server and the WCF generated proxy code impliments that interface to manage the tranport accross process (or machine). WCF is very flexible via configuration files about the transport to be used (namedpipes, tcp, http etc). Bon courage!
Ricibob's answer is correct. I started the way he suggested. I needed WCF Data Services because I had to edit some data in the db. And I got stuck when I found out that WCF Data Services doesn't support Enums. My business objects widely used enums and now I don't know what to do.
I have a C# application that needs to always be running. I originally planned on making this a windows service but I now have a requirement to make the application host a web admin console.
I haven't played with IIS in quite a few years so my question is this:
What would you recommend I use?
I've thought about making a windows service and embedding a web server such as Cassini but so far I'm not very happy with the open source web servers I've looked at.
Can IIS handle this? Do people use it for this type of scenario, and if so how?
This sounds like a job for two separate projects.
One is the original Windows Service. Windows Services are well suited for what you're doing.
The second is the Web Project that will be used to administer the Windows Service. This is the part that runs in IIS.
It depends on what you mean by always running. An ASP.NET web application deployed in IIS could very well be unloaded by the web server if there aren't any requests for certain amount of time killing all background threads. So if you want an ever running background thread it would be better suited to use a Windows Service. As far as the web admin is concerned, well, here you don't have much choice: ASP.NET in IIS. In order to do something useful those two applications should be able to find a common language to talk. So you could use a database to store the results into which could be used by both applications.
IIS will run your app on first request, not on server boot. So you will still need to run a service to ensure your app is always running.
You can use IIS as a webserver for your web admin part, and link your ASP.net app with your service by means of a configuration database (easy) or webservices (a little more tricky).
Windows and Web services are two very different creatures. A web service will expose external methods that you can implement against an application, while a windows service is an entity within itself. If you're planning on using this service on a timed interval to perform an operation, a Windows service would be the right way to go. If you use a web service, you will need to invoke the method you wish to run from a secondary application.
If you need to queue commands against your windows service, you could always create a database that was accessible by both your website and your windows service. This way you could send commands and query data between the two. Placing a web service in to serve as an intermidary between the two may be overkill.
I am writing a Windows application using C#. I am planning on later to allow it to be controlled over the intranet using browser also. So in future we should be able to control it both using the local interface or over the intranet from the browser.
Is there any pre-defined architecture which will allow me to do this? What are the methods of achieving this? I am new to C#/.Net.
EDIT:
The windows application needs to access the communication ports extensively, and needs to be pretty stable and would probably run for some days together.
Thanks...
I can't tell you if a specific package exists that would ease the development. But, if I were to attempt it, after Googling and not finding something already available and meeting my needs, I would likely make my application a WCF host. Create service entry points to accept control messages remotely. You would also need some well-know location where to register your application so the remote system could find it. You should be sure to provide the user with a way of disabling the application remote control feature.
Your host interface will need to run on its own thread to remain performant. Since you are new to C#, and presumably windows forms application development, you will need to read up on how to properly talk to the GUI controls from a non-GUI thread.
Alternatively, you may want to implement your application as two distinct units, one with a GUI that does all the user interaction. It would form service requests to send to the host portion (with no GUI). Your app could then operate locally or be controlled remotely.
One solution I have used in a similar situation has three parts :-
1) Win32 (local) Service
Manages the COM ports and does whatever is necessary with the attached hardware
2) WinForms/Console Application
Runs on the local machine and communicates with the local service via named pipes or TCP.
3) Web Server + Web App
Runs on local or remote machine & communicates with local service.
The local user can shut the WinForms application down and log-off without affecting the service or remote users.
The newest version of Silverlight (the version that ships with Visual Studio 2010) allows what Microsoft terms the "Out Of Browser Experience" (OOB for short).
This allows the user to set up the Silverlight application as a desktop application as well as running through a browser.
Rudi Grobbler has just blogged about how he went about setting this up on his PC.
Is it possible to create a C# EXE or Windows Service that can process Web Service requests? Obviously, some sort of embedded, probably limited, web server would have to be part of the EXE/service. The EXE/service would not have to rely on IIS being installed. Preferably, the embedded web service could handle HTTPS/SSL type connections.
The scenario is this: customer wants to install a small agent (a windows service) on their corporate machines. The agent would have two primary tasks: 1) monitor the system over time and gather certain pieces of data and 2) respond to web service requests (SOAP -v- REST is still be haggled about) for data gathering or system change purposes. The customer likes the idea of web service APIs so that any number of clients (in any language) can be written to tap into the various agents running on the corporate machines. They want the installation to be relatively painless (install .NET, some assemblies, a service, modify the Windows firewall, start the service) without requiring IIS to be installed and configured.
I know that I can do this with Delphi. But the customer would prefer to have this done in C# if possible.
Any suggestions?
Yes, it's possible, you may want to have a look at WCF and Self Hosting.
Yes, it is possible (and fairly easy).
Here is a CodeProject article showing how to make a basic HTTP server in C#. This could easily be put in a standalone EXE or service, and used as a web service.
One technology you might want to check out is WCF. WCF can be a bit of a pain to get into but there's a great screencast over at DNRTV by Keith Elder that shows how to get started with WCF in a very simple fashion.
http://www.dnrtv.com/default.aspx?showNum=135
You could take a look at HttpListener in the .Net framework.
I would highly recommend WCF. It would fit very well into a product like you are describing. There are a good number of books available.
Sure, you can do that. Be sure to change the Output Type of the project to Console Application. Then, in your Main function, add a string[] parameter. Off of some switch that you receive on the command line, you can branch to ServiceBase.Run to run as a Windows Service or branch to some other code to run a console application.
This question is somewhat older but since I needed something similar some time ago it felt like this question is still relevant.
I wrote a small Rest-API with NancyFx and OWIN. OWIN is a standard interface between .Net applications and web servers. With OWIN it is possible to create a self-hosted WEB-API. Nancy on the other hand is
a lightweight, low-ceremony, framework for building HTTP based
services on .NET ยน
The combination of those two makes it possible to create a self-hosted C# Web service.
I am quite sure that there are many more possibilities to create something like this by now but since I used it like this I thought the Information might be useful to someone.