I have got a vb.net windows service that runs a File System Watcher to monitor an xml file for changes, when it detects a change it will stop the screen saver running and what I would then like it to do is give one of the other running applications the focus.
I have successfully used Appactivate from a Windows Form App in the past but I think I am correct in saying this doesn't work with Windowless applications (I have tried it and it doesn't).
I have done some Googling but I can't seem to find any way of getting the focus when called from a service \ windowless app. Is this possible?
Thanks
what if you make it a single instance application? and then simply launch its .exe file? it might give focus to the other running application instead of opening a new instance.
Related
I want to develop an application with VB.NET 4.7.2 Framework, using WinForms. The application must run like a service, that is, ran at Windows startup (after boot, before login). It's intended to run only on a local enviroment, and play some sound files while the local user hasn't logon yet.
My first aproach to this problem was developing a WinForm app that accepted command line args, so when it was executed without args, the GUI appeared to let the user customize some of the features of the program, and when it was executed with args, then no GUI is shown and music is played.
However, the method for detecting when login/logouts and other NT Session Events happened was by hooking a script onto the Windows Scheduler, which ended up being a bad idea, because half of the times, the program would lock up (as the Windows Scheduler would try to execute multiple times) or didn't even execute the program (because it didn't even fire up correctly the login event).
Now, I've considered remaking my code into two programs, a service that runs the code, and a GUI app that sets up the settings for the service program. My idea is to embed an executable inside the main GUI app executable, so it automatically extracts it to a folder in order to run the service program.
However, I can imagine this isn't a pretty clean solution; more so if it triggers by error an antivirus.
I would appreciate some kind of help to get this working on a much clean and safe way.
Note: The main goal of this question is to preserve the all-in-one executable format, if possible. If not, either design a way to run a WinForm app like a system service (run at Windows startup, before login), or two individual programs, one as a service and the other as the GUI program.
I have an application that is a Windows Service application. It currently reads an XML file for it's configuration and the code works off those settings.
I have created a separate project that is a Windows Forms application (typical windows app). This app is a GUI interface into the configuration settings (changed from XML to database, but that is relatively unimportant).
What I need to do is:
Integrate the 2 projects
Add a system tray icon to pop up the form
I'm unsure exactly how to proceed on this and wanted to get some advice before messing things up.
You can't integrate these two things (entirely). A service is designed to run without a GUI of any kind (there is a work around to allow desktop interaction but this is messy and clunky and will cause you more problems than it solves)
It sounds like you just need to use the code from the service in the forms application. This should be a simple copy and paste operation.
To show an icon in the system tray is pretty easy:
Create a program to run from the system tray
how to put an .net application in system tray when minimized?
I have built an application that connects to the exchange server and does some scanning tasks on the incoming mail.
Application has a form where i can start and stop scanning,give in an interval, do some other configuration, and a notificationicon in the taskbar to show hide,end and so on..
The problem is that I would like the application to start as a service, because now a user has to log in first on the server before it starts working.
I tried some tools like RunAsService, i had a service, but obviously it didn't run the application.
Of course i understeand now that when the application will run as a service, scanning will be the only thing that will happen, no forms and no notification icons.
However i do not know where to start, should i extract the scanning logic from my configuration as a separate application? What application type should it become then ?
You have two easy options.
First one just create a new Windows Service Project from your New Project button in the Visual Studio, and then just program your app.
Second one, just create a service from the service management window in your computer and add the executable file of your program. It will start running as a service (with visible windows and everything as you coded it).
You should follow this link and schedule your vb.net windows program as windows task
In Your code, at the end ,when everything gets executed you should write Me.Close() to hide your form.
I have a website created in VS 2010 with .NET 4.0. There are multiple projects in the solution. In one of the projects I have a form that gives a user the option to run a console application that is in another project of the solution. (called update.exe)
I have tried just using
process.start(filepath + "update.exe")
but it doesn't seem to run.
It finds the file but then finishes immediately. I tried adding Console.readKey() to the console application so it would stay open after being called, but it was to no avail.
On top of this, I know that the console app isn't running as I have logs set up throughout the console's code and it never even seems to kick off.
Should I be calling the console app differently? (note: I am writing in VB.net)
Thanks!
Purely speculative here.. but my guess is that when the page finishes processing the process is terminated. Try having the page wait for the process to close.
My 'work-around' for a similar requirement is this:
Use the ASP page to create a CMD or BAT file on the server.
Create/write a service that 'watches' for the CMD/BAT file - and when it finds one, it runs it. The service can be written to start a process as a user.
I've attempted just about everything to get our ClickOnce VB.NET app to run under Terminal Services as a RemoteApp. I have a batch file that runs the .application file for the app.
This works fine via RDP desktop session on the terminal server. As a TS RemoteApp, however, well... not so much.
I get a quick flash of command prompt (the batch file) on the client system and then... nothing...
Same goes for having it point to the .application file directly (without using a batch file) or even copying the publication locally and having it point to that.
I found a technet.microsoft.com discussion about a similar issue, but there's no resolution to it listed.
For anyone who has run into this before and got it working, what did you have to do?
We currently use RemoteApp's for everything else on that server, so I'm hoping to stick with that if possible.
The current workaround is to build and run an MSI-based installer for the app on our terminal server whenever we publish via OneClick out to the network, but this can be quite a pain at times and is easy to forget to do.
Since the app works fine via Terminal Services when run in full desktop mode but not during RemoteApp, I don't think it's anything specific to Terminal Server permissions so much as ClickOnce requiring something that isn't available when running as a RemoteApp.
The Key to getting it to work is to use Windows Explorer "C:\windows\explorer.exe". This process is the base process when you login to a full session.
If you setup the RemoteApp to use Windows Explorer and the command line argument of the path to the .application file for the ClickOnce application then it will work when launched as a remote application. Windows Explorer will flash for a second when it starts, but it will disappear then the ClickOnce application will launch.
Why does it have to be a ClickOnce application? I would consider just deploying the exe file and assemblies.
I know it only half a solution, but if the application does not change much, it might be a good solution.
I believe your problem is related to the fact that ClickOnce needs to store it's data in a special user folder called the ClickOnce application cache. Apparently because of how Terminal Services sets up user folders ClickOnce can't access this in TerminalServices mode.
See this link for more information.
http://msdn.microsoft.com/en-us/library/267k390a(VS.80).aspx
There may not be a way to do it :(
Can you launch the .exe directly? It's buried under your profile in \AppData\Local\Apps\2.0[obfuscated folders], but you should be able to find it.
That will skip the built-in update process, but if it can be launched that way you could then write code to do a manual update after the application starts.
Faced the same problem this morning and got it resolved by copying the clickonce app's directory from the user settings folder to somewhere like c:\MyApp\ - I know its nasty and not very ideal.. but good enough for me!
We recently ran across this issue and decided to post a bug report on this issue to the Visual Studio development team. Feel free to comment on the bug report. It has to be a bug in ClickOnce caused by some changes in Server 2008.
https://connect.microsoft.com/VisualStudio/feedback/details/653362/net-clickonce-deployment-not-working-as-remoteapp-or-citrix-xenapp-on-server-2008-server-2008-r2
We also have a discussion on the MSDN forums covering this issue:
http://social.msdn.microsoft.com/Forums/en-US/winformssetup/thread/7f41667d-287a-4157-be71-d408751358d9/#92a7e5d9-22b6-44ba-9346-ef87a3b85edc
Try using RegMon and FileMon when starting the app - You may be able to track it down to a file and/or registry permission issue.
Also maybe check the event logs to see if anything's getting logged when the process fails.