On Mon, 11 Oct 2004, Duncan Godwin wrote: > On a related issue, is there any known problems with setting a services > application type to Console Application as opposed Windows Application?
Not exactly sure what you mean by this? It's normally the other way around. i.e. you create a Console or Windows application first, and then turn it into a Windows service later. If you create a console application and make it a Windows service, then, you will not get any console I/O from the service. You need to rely on some external mechanism to do this. I achieve this in several different ways: 1) I can make my service a .NET Remoting Server and talk to clients via remoting channels. For example, you can create a console client, which will interact with the service via remoting and get the "feedback" from it. 2) Use COM Interop to access the service and invoke methods on it. 3) Use .NET Sockets to communicate with the service 4) Using P/Invoke, create named pipes to the service and redirect its console I/O into your feedback client. So, basically, once you make your application a Windows service, you can use any of the traditional Windows IPC mechanisms or .NET mechanisms to interact with the service. > > I would like to do this so that I can give my service custom install > options, and give feedback via the Console. What are the custom install options you have on mind? Once you add a ProjectInstaller to your Windows Service project, you can override the normal Installer class methods to do the custom operations. AFAIK, this doesn't have anything to do with whether the service is a console application or a Windows application - it's basically a Windows service. > > Cheers, > > Duncan > > ----- Original Message ----- > From: "Srihari Angaluri" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Monday, October 11, 2004 9:43 PM > Subject: Re: [ADVANCED-DOTNET] Console I/O in a Windows Service > > > Makes sense! Thank you. > > Srihari > > On Mon, 11 Oct 2004, Dominick Baier wrote: > > > is there some kind of an internal "/dev/null" where the messages are > > redirected? > > > > hi, > > > > from my understanding that's exactly what happens - to get std in/out/err > > handles in a non-console app you have to call the AllocConsole win32 API - > > otherwise you simply won't have them. > > > > but this is not related to if the app is running as a service or not. > > > > If you are calling AllocConsole in a service you will get a console in that > > window station... > > > > --- > > Dominick Baier - DevelopMentor > > http://www.leastprivilege.com > > > > > > -----Original Message----- > > From: Unmoderated discussion of advanced .NET topics. > > [mailto:[EMAIL PROTECTED] On Behalf Of Srihari Angaluri > > Sent: Montag, 11. Oktober 2004 22:24 > > To: [EMAIL PROTECTED] > > Subject: Re: [ADVANCED-DOTNET] Console I/O in a Windows Service > > > > Hi, > > > > Thanks for the information. I am indeed aware of Window station and > > Interative Desktop issues (I read interesting articles on security and logon > > sessions by Keith Brown before). I am not worried about how to see the > > output generated from a Windows service (I know the different techniques - I > > debugged a lot of Windows services before :). I just want to know "what > > really internally happens" to these messages, when the service writes to > > Console. Note that even if the service is configured to interact with the > > "winsta0\default desktop", you won't still see a console window, unless you > > create one from within the service. This is what Keith did in his > > "cmdasuser" utility, when you run it as "localsystem". If it was a Windows > > Forms application, then, yes, you will see the Windows. So, what I am trying > > to understand is, , in case of a interactive/non-interactive Windows > > Service, which is basically a Console (not Win Forms) application. > > > > Srihari > > > > On Mon, 11 Oct 2004, Dominick Baier wrote: > > > > > Hi, > > > > > > services run in their own window station. window stations are like > > > sandboxes > > > - with their own virtual in/out devices. > > > > > > Only one Window Station (WinSta0) is bound to the physical hardware - > > > WinSta0 is automatically associated with the interactive logon > > > session. You can configure services to run in WinSta0 with the "allow > > > service to interact with desktop" option in the services MMC. > > > > > > that said - you have In/Out/Err attached to a service - but no one can > > > see it - e.g. you can open a MessageBox in a service - but noone will > > > be able to press "Enter" - and the program is locked. > > > > > > on a related note - try to call Console.WriteLine in a WinForms App - > > > what happens - nothing - that's cause no console is allocated to the > > > WinForms app > > > - the same happens to a service... > > > > > > if you want to ouput console messages from a service, use a console > > > monitor like app that runs in WinSta0 and do some kind of IPC between > > > the service and your monitor app. You could do that through a custom > > TraceListener e.g. > > > and use the trace class to output the messages - Trace also supports > > > tracing in a file or the event log and has an infrastructure to > > > configure trace behaviour through config files. > > > > > > --- > > > Dominick Baier - DevelopMentor > > > http://www.leastprivilege.com > > > > > > -----Original Message----- > > > From: Unmoderated discussion of advanced .NET topics. > > > [mailto:[EMAIL PROTECTED] On Behalf Of Srihari > > > Angaluri > > > Sent: Montag, 11. Oktober 2004 21:43 > > > To: [EMAIL PROTECTED] > > > Subject: [ADVANCED-DOTNET] Console I/O in a Windows Service > > > > > > Hello, > > > > > > I have a console application, which outputs a lot of standard output > > > and error messages to Console. This was mostly for my initial > > > debugging. I later made this application into a Windows service. I > > > abstracted all my console I/O messages into a "debug" class, which has > > > a static bool variable "bDebugOn". Whenever I want to debug this app > > > in console mode, I turn this flag on and the class will start printing the > > messages to the console. > > > > > > I am curious to know what happens when this app is run as a Windows > > > service, with the bDebugOn flag set. As I understand, a Windows > > > service doesn't have Standard In/Out/Error attached to it. Perhaps, > > > Windows doesn't allow services to access CRT library either - I don't > > > know. In this case, what happens to my Console.WriteLine(...) calls? > > > Where does the output go? How does the CLR handle these instructions? > > > Also, are there any performance implications for these calls (which > > > have no effect BTW, as if they were a NULL instruction). In other > > > words, do I waste CPU cycles in my Windows service in order to execute > > these calls anyway? > > > > > > Thanks, > > > Srihari > > > > > > ------------------------------------ > > > Srihari Angaluri > > > Sr. Software Engineer > > > Verari Systems, Inc. > > > E-mail: [EMAIL PROTECTED] > > > Phone: +1-603-891-4766 > > > Web: http://www.verari.com > > > > > > ---------- > > > > > > The information contained in this communication may be confidential > > > and is intended only for the use of the recipient(s) named above. If > > > the reader of this communication is not the intended recipient(s), you > > > are hereby notified that any dissemination, distribution, or copying > > > of this communication, or any of its contents, is strictly prohibited. > > > If you are not a named recipient or received this communication by > > > mistake, please notify the sender and delete the communication and all > > copies of it. > > > > > > =================================== > > > This list is hosted by DevelopMentor. http://www.develop.com Some > > > .NET courses you may be interested in: > > > > > > Essential .NET: building applications and components with CSharp > > > August 30 - September 3, in Los Angeles > > > http://www.develop.com/courses/edotnet > > > > > > View archives and manage your subscription(s) at > > > http://discuss.develop.com > > > > > > =================================== > > > This list is hosted by DevelopMentorR http://www.develop.com Some > > > .NET courses you may be interested in: > > > > > > Essential .NET: building applications and components with CSharp > > > August 30 - September 3, in Los Angeles > > > http://www.develop.com/courses/edotnet > > > > > > View archives and manage your subscription(s) at > > > http://discuss.develop.com > > > > > > > =================================== > > This list is hosted by DevelopMentorR http://www.develop.com Some .NET > > courses you may be interested in: > > > > Essential .NET: building applications and components with CSharp August 30 - > > September 3, in Los Angeles http://www.develop.com/courses/edotnet > > > > View archives and manage your subscription(s) at http://discuss.develop.com > > > > =================================== > > This list is hosted by DevelopMentor� http://www.develop.com > > Some .NET courses you may be interested in: > > > > Essential .NET: building applications and components with CSharp > > August 30 - September 3, in Los Angeles > > http://www.develop.com/courses/edotnet > > > > View archives and manage your subscription(s) at http://discuss.develop.com > > > > =================================== > This list is hosted by DevelopMentor� http://www.develop.com > Some .NET courses you may be interested in: > > Essential .NET: building applications and components with CSharp > August 30 - September 3, in Los Angeles > http://www.develop.com/courses/edotnet > > View archives and manage your subscription(s) at http://discuss.develop.com > > =================================== > This list is hosted by DevelopMentor� http://www.develop.com > Some .NET courses you may be interested in: > > Essential .NET: building applications and components with CSharp > August 30 - September 3, in Los Angeles > http://www.develop.com/courses/edotnet > > View archives and manage your subscription(s) at http://discuss.develop.com > =================================== This list is hosted by DevelopMentor� http://www.develop.com Some .NET courses you may be interested in: Essential .NET: building applications and components with CSharp August 30 - September 3, in Los Angeles http://www.develop.com/courses/edotnet View archives and manage your subscription(s) at http://discuss.develop.com
