I wrote, installed, and successfully started a Windows Service in c# that does nothing :) Initially I just want echo stuff to the console, db queries the service makes etc. I used the OnStart in my service, but from a cmd prompt when I do a net start "My Service" where do these messages show up?
I'm open to better ways. I'm new to this and feeling my way through it step by step by echoing back to the console my progress. Should I echo to the event log instead? How do I do that?(I know, I know, google it)
protected override void OnStart(string[] args)
{
base.OnStart(args);
Console.WriteLine("Sham-Wow!");
}
You cannot write the console from a Windows Service.
I recommend you using any logging utility, such as log4net.
The second alternative is writing to the Event Log (System.Diagnostics.EventLog)
Try System.Diagnostics.Trace.WriteLine and you will see your messages in Output window of Visual Studio or with dbgview utility.
If you want to run your application as a console application (so you can see your console output) or as a service you can achieve this with the following:
Ensure that your application is compiled as a Console application.
Alter the application's Main method so that you can branch for service or console execution.
Run your application as follows to get a console "myservice.exe /console".
It's been years since I have done this so might need a little tweaking, but something like follows:
static void Main(string[]] args)
{
if (args.Length == 0)
{
//Service entry
System.ServiceProcess.ServiceBase[] services;
services = new System.ServiceProcess.ServiceBase[] { new WinService1() };
System.ServiceProcess.ServiceBase.Run(services);
}
else
{
//Console entry
OnStart(args);
}
}
protected override void OnStart(string[] args)
{
base.OnStart(args);
Console.WriteLine("Sham-Wow!");
}
This is fine for some early experimentation, but I would recommend Log4Net once you have got your head around things.
The most common/accepted way of communicating the status of your service is to write to the Windows Event Log.
For easier debugging, I would recommend that you put all of your business code into a separate class from the service component. You can then use that class from either your service, or from a console application. While you are creating the service, you will use the console application to host your component, so that you can easily step-into the code.
Very old question, but very relevant. This is how I implemented a logging mechanism that I could inspect while the Windows service is running.
Create a log file. My favorite is Log4net as mentioned before.
Open PowerShell and run this command Get-Content "path/to/file.log" -Wait
You will be able to monitor the file as it changes. This is like the tail command in linux.
Related
What would be a short example with a Windows service and how to install and run it?
I've searched on the Internet, but what I've tried didn't have anything written on the On Start method. Plus, when I've tried to install it the error OpenSCManager keeps popping up.
Find install util at C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\InstallUtil.exe
Then run InstallUtil.exe "c:\myservice.exe"
Go to services.msc and then locate and start your service
Here are some examples about how to write and install a Windows service in C#:
A Windows Service Application
Simple Windows Service Sample
ASP.NET Tutorials : Creating Windows Service in C#
Creating a Windows Service in C#
How to Create and Work With Windows Services in C#
Creating a Simple Windows Service in C#
My answer to this question gives you step-by-step instructions for creating a Windows service in C#.
Easiest language for creating a Windows service
My answer to this question shows you have to modify the service so that it can install and uninstall itself from the command line.
How to make a .NET Windows Service start right after the installation?
InstallUtil.exe has been part of .NET since 1.1, so it should be on your system. However, you likely can't use it from a 'normal' command prompt. If you have Visual Studio installed, open the Visual Studio command prompt. That'll define the appropriate environment variables that make InstallUtil accessible without path information.
The OnStart() callback gives you an opportunity to start the business logic of your service. If you don't do anything in the OnStart() callback, your service will immediately shut down. Typically, you'll start a thread that performs the work you're interested in. Here is a small example to show you what it looks like.
private static System.Timers.Timer _timer;
private static void OnTimedEvent(object source, ElapsedEventArgs e)
{
// Write a message to the event log.
string msg = String.Format("The Elapsed event was raised at {0}", e.SignalTime);
EventLog.WriteEntry(msg, EventLogEntryType.Information);
}
protected override void OnStart(string[] args)
{
// Create a timer with a 10-econd interval.
_timer = new System.Timers.Timer(10000);
// Hook up the Elapsed event for the timer.
_timer.Elapsed += new ElapsedEventHandler(OnTimedEvent);
// Signal the timer to raise Elapsed events every 10 seconds.
_timer.Start();
}
protected override void OnStop()
{
// Stop and dispose of the timer.
_timer.Stop();
_timer.Dispose();
}
Doing something like this will effectively keep your service running until it shuts down. Hope this helps.
I have a WCF service that is hosted on a c# console application. Is there a way to restart this service, preferably by calling an endpoint in the service itself (ex. myService.Restart()).
Thanks
I have to do something similar when I perform an automatic update of a remote WCF service. In your Restart() method, close the host:
try
{
host.Description.Endpoints.Where(x => !x.Address.ToString().EndsWith("MEX")).ForEach(endpoint => _log.InfoFormat("Closing {0}", endpoint.Address));
host.Close(TimeSpan.FromSeconds(5));
}
catch (Exception)
{
host.Abort();
}
I wait for my update to apply, and then after a success or failure, I re-open the host using the same code I used to start it in the first place.
If you just wanted to restart immediately, you could just call host.Open(), or you could set up a timer to call it, etc.
try
{
host.Open();
host.Description.Endpoints.Where(x => !x.Address.ToString().EndsWith("MEX")).ForEach(endpoint => _log.InfoFormat("Host opened at: {0}", endpoint.Address));
}
catch (Exception ex)
{
_log.Error("Unable to open host.", ex);
}
To answer my question, I have solved the problem by doing the following:
Separating the code that loads the DLL files from the WCF service code into another class library project
Create an interface with the same method signatures as the ones that load DLL files in the new project (this interface is used by both projects now)
In the web service, load the other project in a new application domain. This way the DLL files are locked by the new application domain not the default.
If I want to update my nunit DLL files now, all I have to do is unload the application domain from the web service, update the files and finally create a new application domain.
AppDomain remoteDomain = AppDomain.CreateDomain("New Domain");
IClass1 class1 = (IClass1)remoteDomain.CreateInstanceFromAndUnwrap(
"Test1.dll", "Test1.Class1");
Note: IClass1 is the common interface between the projects.
you definitely are not going to be able to 'restart' a faulted service from calling that same service itself. In theory you could host 2 services in the same process. put the one you want to be 'restartable' in a public static variable and restart it within the other service. The problem would be restarting the restarter service if it faults... :) and you definitely want 'administrator-like' restrictions on your restarter service so unauthorized users can't do it.
It's a bit kludgy, but I suppose you could expose a callback on your service that the host could attach to and take appropriate action when it's triggered. That would give your host the ability to decide what a "restart" really means and how it needs to be executed. More importantly, it lets your decide whether it should do something extreme like spawn off a watcher process and then off itself or gracefully trash and reinstantiate your service (preferable).
Mmmmmm... kludge....
You cannot ask a service to restart itself. Consider a windows service (a service hosted in windows provided container) which has a RESTART functionality. Here RESTART functionality is provided not by the service but by the container. The container controls how to stop the service and start it.
Similarly in your case, you should try to look out for options if your container can provide the functionality you need. Since you want to control it remotely, the container should also be available remotely, which cannot be possible if the container is a console application. Instead it has to be another web service or web application.
I'm not using a Windows Form Timer--I'm using a System.Threading.Timer. No exceptions are raised when instantiating the timer, and to my understanding, System.Threading.Timer's do not need to be explicitly started.
I've tried using a System.Timers.Timer (See comments in code) and changing the signature of the callback with no luck. Inside the callback method, I stubbed in some EventLog writes, and not even the first writes to the event log. All I see in the Event Log is MyService.OnStart fired followed by MyService started (these are both from the OnStart event). Why aren't the timer callback events firing?
public partial class MyService : ServiceBase
{
private static System.Threading.Timer timer;
public MyService()
{
InitializeComponent();
if (!System.Diagnostics.EventLog.SourceExists("MyService"))
{
System.Diagnostics.EventLog.CreateEventSource(
"MyService", "MyServiceLog");
}
eventLog1.Source = "MyService";
eventLog1.Log = "MyServiceLog";
}
protected override void OnStart(string[] args)
{
eventLog1.WriteEntry("MyService.OnStart event fired");
// setup timer to poll and execute an event
//Timer timer = new Timer(new TimerCallback(CheckCalls), null, 0, 10000);
try
{
timer = new System.Threading.Timer(new System.Threading.TimerCallback(CheckCalls), null, 0, 10000);
}
catch (Exception ex)
{
eventLog1.WriteEntry(ex.Message + " Stacktrace: " + ex.StackTrace);
}
eventLog1.WriteEntry("MyServicestarted");
GC.KeepAlive(timer);
}
}
and the callback method, CheckCalls:
private static void CheckCalls(object objectState)
{
EventLog eventLog1 = new EventLog("MyServiceLog", "DAVIDWIN7", "MyService");
eventLog1.WriteEntry("MyService is polling");
}
Arg--For some reason when you Build->Clean Solution, then Build->Build Solution, Visual Studio does not rebuild your setup project. I believe my code above works fine, but I had tried many different fixes without explicitly right-clicking the setup project and selecting Build.
I thought Clean Solution would force all projects to be rebuilt on next build???
it's got to be an error with the timer thread writing to the event log.
I got it working on my computer but I replaced all the eventlog with Console.writeline because I didn't want to mess with my event log permissions.
Did you check if the account under which the service is running has access to the eventlog?
Please can you go and download this test application which mirrors exactly the scenario you are talking about:
https://docs.google.com/leaf?id=0Bw_NnV9fhgmgMThjNDgzOTgtODNiOC00NDE1LWEyMTYtNzVhOTMyNzlmZjZk&hl=en&authkey=CMuupNkC
I've just created this. It's a service that effectively uses the same code as you. The only difference is that I have used the toolbox to drag and drop an eventlog on to the service designer - setting the log to 'Application' and the source to 'Service1'.
Open a VS command prompt at the project folder, go to bin\debug and run installutil windowsservice1.exe - specifying some credentials (so you're installing the dev service directly from your bin output folder).
Start the service and monitor the application log - it will write every ten seconds as you expect to see from your code.
Assuming this works on your machine(tm) like it does on my machine(tm) then I would suggest that the problem is the event logging itself, or, horror of horrors - your service isn't running from your build output folder (most of the devs in my team insist on running their dev services from a different folder and then swear when they forget to actually update the binaries when they start debugging it!).
As I suggested in my comment, you really need to be able to attach the debugger to this and breakpoint the callback to verify that it's not getting fired. I never rely on the eventlog for diagnostics messages simply because the log might be full, or permissions might prevent you etc etc - it might be a windows platform component, but it's not as reliable as I would like.
The debugger, however, rarely lies (unless the deployed binaries are out of date ;) ). Compile a debug build of your project and make sure it's the one that is installed in the services list, start it up and then attach directly to the service exe (there's no point trying to attach to [service].vshost.exe - VS cannot auto-attach or host windows services as the only way they can run is via svchost.exe shelling them).
Hope this helps.
I installed my Windows Forms .NET 3.5 application and it installed correctly. When trying to run it the application crashes and the typical Microsoft Windows error dialog shows. You know the one that asks you to send an error report.
My question is, how can I see what actually caused the program to fail to launch?
The application runs well on my development machine, the problem is when running on another computer when installed with the Setup file I created.
Is there a way to see the 'innerException' when not running on a development machine?
Besides checking the Windows Event Viewer (from Computer Management) you could also try to build some error logging around your program. If you extend your Main() method to contain the following lines you will be able to get some further information about the cause of the program failure:
[STAThread]
static void Main()
{
Application.ThreadException += new ThreadExceptionEventHandler(Application_ThreadException);
Application.SetUnhandledExceptionMode(UnhandledExceptionMode.CatchException);
AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(CurrentDomain_UnhandledException);
Application.Run(new Form1());
}
private static void Application_ThreadException(
object sender, ThreadExceptionEventArgs e)
{
//Log error here using e.Exception
}
static void CurrentDomain_UnhandledException(object sender, UnhandledExceptionEventArgs e)
{
//Log error here using (Exception)e.ExceptionObjecte.Exception
}
You could for example log the error to a simple text file using a StreamWriter:
string dateStr = DateTime.Now.ToString("yyyy-MM-dd");
StreamWriter sw = File.AppendText(Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "ErrorLog_" + dateStr + ".log"));
sw.WriteLine(exception);
These are the default options you have:
(If possible) change the application so that it logs errors and warnings, using e.g. log4net or the windows event log, then redistribute your app.
If the first option is not possible, you'll have to check out more advanced debugging: run-time debugging on the client machine. One way is to use WinDbg with the .NET extensions (SOS) or related tools from Debugging Tools for Windows. You can set it up on a client machine without running an installer, so it should have little or no side effects (as opposed to the non-option of setting up Visual Studio). One article on this is here, where they're debugging a crash dump file. Here is another article on the topic. You'll find endless resources on this googling - the topic is not simple but I recommend you look into it.
(If you need the results now, and don't have time to dig into advanced debugging with WinDbg and related tools at the moment, I would just add some tracing into the application.)
Did you check the EventLog? If your program starts, and then begin crash. put EventLog.WriteEntry(exceptionMessage). If not, best way to see it is EventLog.
I have a project that is deployed to production as a windows service. However for local development purposes it would be useful to run it as a console application. At the moment I have a class Called ReportingHost that provides my core functionality, And a class called ReportingServiceHost that inherits from ServiceBase and allows me to run the application as a service. There is also a program class with a main method that calls ServiceBase.Run on my ReportingServiceHost.
I think I need to write a ReportingConsoleHost class that allows me to run the functionality in a console. Then I need to modify my Main to react to a command line switch and choose one or the other. These are the two bits I am having trouble with.
I have had a look at this and attempted to use that code but my app exits immediately, it doesn't show a console window and it doesn't wait for Enter before closing.
Part of the problem is that I dont have a deep understanding of how these things work. a definitive pattern for splitting my functionality, my two different ways of running that functionality, and a main method that chooses one of these ways based on a command line argument is what I am hoping to achieve.
I suspect your test project was configured as a windows exe, not a console exe. With a windows exe Console.ReadLine will return immediately.
To have a console exe that works both as a service and at the command line, start it as a service project (in Visual Studio) - and add a check on Environment.UserInteractive - i.e.
static void Main() {
if(Environment.UserInteractive) {
// code that starts the listener and waits on ReadLine
} else {
// run the service code that the VS template injected
}
}
You can of course also use a command line switch. I have example on microsoft.public.dotnet.languages.csharp that acts as:
an installer / uninstaller
a service
a console-mode app
depending on the switches
I have done this before by implementing a normal Windows Service (by deriving from ServiceBase), but putting a check in the main method to check for a command line argument.
If the args contain /console, start the console version, otherwise start the service.
Something like this:
internal class MyService : ServiceBase
{
internal static void Main(string[] args)
{
if (args.Length == 0)
{
// run as a service....
ServiceBase[] servicesToRun = new ServiceBase[] {new MyService()};
Run(servicesToRun);
}
else
{
// run as a console application....
}
}
}
My advise? Put all your logic for your service in a separate assembly. (A class library or DLL.) Then create one project as service which references your class library and puts the code to use as services. Create a second console project which also references your class library but which will make it available as a console application.
You would end up with three different projects in your solution but it does allow you to keep things separate. Actually, this would make it possible to extend your service in several other shapes too. You could, for example, create a 4th project as a web service and thus call your service from a web browser on a client system. Because the software logic is separated from the usage logic, you gain lots of control over it.
Be aware that a service will possibly run with more limitations than a console application. In general, services don't have network access by default, don't have a monitor assigned to them to display error messages and in general run with a limited user account or system account. Your service might work as a console yet fail as a service because of this.
There are already two good answers above - but I thought I'd post a link to Brian Noyes' Debuggable Self-Host Windows Service Project blog post - it talks about WCF but should apply to any 'Windows Service'.
The best thing is the sample code - if you can't figure out where the above examples 'fit', grab the complete project and see how it works. Thanks Brian!