Printable View
Is there a way in which I could invoke a windows form from a particular windows service....??
Have created a windows service, installed it and everything is working fine...
Now I want to design another windows form that I would call from the service while running it
I know that with the help of ServiceController class we could interact with windows service from a windows application but am not sure of the other way round implementation....
Pls help...
services are not meant to have user interfaces. That is the entire point of a service. If you need a UI, then you should not use a service, or you should use a secondary application that managed the service settings, and the service should poll for changes to these settings so once you do make changes in the UI app, the service can adopt those changes.
Hi,
You are talking of controlling services from application but I am talking of the other way round (services controlling the application). I already know Services are meant to run in the back groung but here the task involved something like that actually....
Anyway, can anybody give me some links or references on windows api programming for vb.net as I could not get good results on googling.
Thanks to all...
You didn't get real good results googling because most of the API's available/used in VB6 have been incorporated into the Framework as classes.
What, specifically, are you looking for?
Hi Hack,
I have a task of creating a windows service which upon fulfilling some conditions invokes a black screen in front of user(no interaction). Had it been a windows application, calling a black form would have been easy; but here it is windows service which ideally should not include any form as such. I thought of creating another windows app with only a form (only the form without any button or any other component) in its design that would be called by the service. But could not implement it...
Now I am not aware of any method to invoke a black screen through this win service. Thats why I was looking for windows api tutorials that are being used as a part of vb.net programming...:(
Do you have any other idea of invoking such screen...?
google for Named pipes
You can mark a service as "interactive" and then it can show forms etc on the screen but I would recommend against this as you will find that in Windows Vista/7/2008 this can cause a separate empty desktop to be shown to the user temporarily whilst your UI is being displayed (this is probably to encourage people not to use a UI from their services).
What I would suggest is do as Klienma mentioned and have a separate windows forms application that just stays hidden (perhaps just showing an icon in the system tray) and when the service needs to show this form you can send a signal to the winforms app to tell it to make itself visible. As for how you would send such a signal, one way would be to have the winforms app listen for incoming TCP connections on a specific port (using the System.Net.Sockets.TcpListener class) and then the service uses the System.Net.Sockets.TcpClient class to send data on this same port so that the winforms app picks it up.
EDIT: You can also use Named Pipes as cicatrix mentioned but I've never tried using that in .NET (unless using WCF) so not sure how easy it is.
Quite easy actually, I've tried it only yesterday.
I've considered using TCP against named pipes but TCP connections could cause issue with firewalls, etc so I chose named pipes.
I didn't know that .NET had native support for them but then I've found System.IO.Pipes namespace and all it takes is creating a NamedPipeServerStream on one side and NamedPipeClientStream on the other.
Thanks All,
It will take sometime to try implementing either of the two things(as I am totally unaware of them...), but will continue till get I the soln. :)
Cicatrix, can there be firewall issues for that "tcp-implementation-stuff" when both the server as well client sytem is the local system... ??? (Please forgive me if that was stupid enough to ask as I have no idea regarding that..:blush:)
Chris, since the windows serive would be starting with the booting of the system, how would I start application without actually running it, so that service can call that application...?
This depends on the firewall configuration. Yes, there can be 'issues' even in your case. And I've found using of named pipes easier from the coding point of view.
It depends - in the majority of cases no, especially if you tell the TcpListener to listen on the local loopback IP 127.0.0.1, but some firewall programs might be a little over sensitive and flag it as a warning or block it.Quote:
Originally Posted by prdnitjsr
There are several ways you can make an application launch as soon as any user logs with Windows (and several posts on this forum alone on how to do it) but one common way is to create a registry key in HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run that points to your application.Quote:
Originally Posted by prdnitjsr
If the communication does not ever leave the single machine, there is not much need for TCP since you can use IPC (inter process communication). It doesn't go through the TCP stack, so firewalls don't matter. It is also faster.
http://msdn.microsoft.com/en-us/libr...nnels.ipc.aspx
I have used this before when I was having an issue where I could not figure out why my app was getting caught by the firewall when it was starting up, when my app wasn't trying to access the internet at all. It turns out that when you check off the option for "Single Instance Application" the framework sets up a TCP channel to check for and notify of additional instances of the application being opened. So I implemented single instance functionality myself using a IPC channel, and it took care of the firewall issue.
Quote:
Originally Posted by chris128
I can help explain this behaviour. A service creates a little environment around itself when created that has access to basic stuff, like local disks and a small area of the registry. If you want to access anything else like printers, network drives etc you have to load up the user hive or run commands like 'net use' to setup connections. However, the first time a user logs into that machine the hive is loaded and can then be used by the service, even after they have logged out. Basically the service and user are logged into the same session. A restart of the machine will unload it.
This area that things run under in pre-vista is pretty open and allows you to get access to gui stuff, so create and show forms (even though you can't see them). Interaction between the service and logged on user (there may be more than 1 !!) sessions is very open.
Vista comes along and locks down everything. A service has its own session (session0) and is blocked from talking outside, you even had to bully the OS into lettting you create excel objects and the like as the new service area has no idea they even exist. Its all to stop a service being installed that has full access to break your system, ie virus installed services.
Full explaination can be found ere:
http://technet.microsoft.com/en-us/m...ritywatch.aspx
Out of interest, what does this black screen do?
I didnt think it was anything to do with registry hives not being accessible etc, just that services run in session 0 as standard (even on pre Vista machines) so they dont have access to anything in the user's session without the special 'interactive' flag that allows them to communicate with the user's session to show GUI objects in there. I'm also not sure you are correct when you say that once a user logs on to a PC then a service and a user are both logged in to the same session... I'm pretty sure a service can access any part of the registry as soon as the service starts, without a user having to log on first. Obviously the user must have logged on to that machine at some point in the past if you want to access any settings from the user's profile because otherwise the subkey for that user in HKEY_USERS would not exist, but I dont think the user has to log on once the machine boots up for a service to be able to read registry keys under that user's key in HKEY_USERS. After all the majority of services run as the Local System account which has full access to pretty much everything on the machine.
Before vista the first user who logged on shared the session0 with the services.Quote:
Originally Posted by chris128
That link backs me up, but I can confirm from personal experience that the pre-vista service does not have access to user hive. We have a service that would work for a while and for some reason would fail. We logged onto the box to see the issue and it started working, logged off the user and it still worked. Restart the box and it fails again, as soon as the user logs on again, it fixed it. We use mapped drives and have to manually net map them everytime after a restart to be sure its still available.
So it does. I just created a service with the following in the startup code:
vb Code:
When the service starts with windows it produces the following log file:
So just the local system key (at least thats what I think S-1-5-18 is) and presumably the other 2 SIDs there are Network Service and Local Service.Code:.DEFAULT
S-1-5-19
S-1-5-19_Classes
S-1-5-20
S-1-5-20_Classes
S-1-5-18
If I start the service once already logged on then it does get the user's profile key as well, as you said.
However, if I set the service to run under that user's account rather than local system then it does load the user's profile key even when the service starts with windows (ie without the user logging on interactively), which makes sense.Code:.DEFAULT
S-1-5-19
S-1-5-19_Classes
S-1-5-20
S-1-5-20_Classes
S-1-5-21-3506883985-3211363968-318860529-1121
S-1-5-21-3506883985-3211363968-318860529-1121_Classes
S-1-5-18
So yeah, thanks for pointing that out, I'm sure it will save me a headache or two in the future :)
We had to ask a M$ guru to explain it to us at one of the devdays years ago, we couldnt work out what was going on ;).
lol yeah I can imagine, certainly not something you would suspect without someone else pointing you in the right direction.
I'm also interested in the answer to this question as I suspect there may be a better way to do whatever it is that the OP is trying to do..Quote:
Originally Posted by Grimfort
Is the "black screen" app on the same machine as the windows service? If it's all on the same box, won't process.start work? So far in this thread, I haven't seen anything to suggest that the service isn't on the same machine...
-tg
Process.Start will work if the service is marked as interactive but as already discussed that is a bad idea, especially if your code will be running on Vista/7/2008 machines. If the service is not marked as Interactive then Process.Start is no use as it will run the process in a different "windows station" to the logged on user (for more info on windows stations see http://msdn.microsoft.com/en-us/libr...96(VS.85).aspx). It will also run the process as the SYSTEM account (or Local Service or Network Service) rather than the logged on user - unless you manually set the service to logon with the user's credentials but then you would have to change it every time the user changed their password. Even making the service run as the user would not allow the service to display anything to the user's session, only specifying that the service is Interactive can do that.
I have seen a way to accomplish this after a bit of digging:
http://www.codeproject.com/KB/vista-...gVistaUAC.aspx
If this is going to be an internal app for local domain you can likely install to the required places/security. Trying to create an app you can distribute and it might come under the banner of a Shatter Attack.
Alt way: Start Process
OK so it is possible with a lot of work and several Windows APIs... but I still think the best way (and the way MS probably intend for people to do it) would just be to communicate between the service and the GUI application via Named Pipes, IPC, or TCP/IP