I have a exe of windows form application which is copied in AppData folder of each logged in user. Currenly that exe gets started after user log in but it takes lot of time to start. So I am thinking of developing a windows service which will invoke that exe as soon as the User logs in. I want to start that exe separately for each logged in user.
Am I going in right direction developing a windows service if yes please tell me how to do that else what is ideal way to do this?
As far as I know, the service can only interact with the default desktop.
In a corporate network based on Active Directory, you would use a group policy to run the exe for each user.
On a stand-alone PC, you could set the startup programs for each user.
Related
I have a desktop application made in WPF. I have seen third party tools to auto update my application easily, but I haven't seen a solution when a computer reset his files automatically.
We can ask the system administrator to install my application and everytime the computer reset, the application is still there. But, if I want to update my application, I have to go ask the system administrator again to update my application because as far as I know, the application cannot update itself.
So is there a solution for auto-updating the application by itself without asking the system administrator to do it? I'm not necessarily (but it could be) asking for a coding solution, but if the system administrator can do something about it to solve the problem, that could be a solution too.
As i mentioned in the comment, one way would be to :
Keep your main app in a shared folder of the main server, which can be accessed by all the connected computers on which a user might use your app.
Make a second application which can access and copy your application from the network source. This code might help you to start with:
string MainAppPath = #"\\NetworkLocation\myMainApp.exe";
AppDomain.CurrentDomain.SetPrincipalPolicy(PrincipalPolicy.WindowsPrincipal);
WindowsIdentity identity = new WindowsIdentity(username, password);
WindowsImpersonationContext context = identity.Impersonate();
File.Copy(MainAppPath , #"D:\UserFolder", true);
Ask your system admin to add this application in windows StartUp Folder with full rights.
Now every time the computer starts your application will be updated to the latest version that you will keep in the network folder
I have a WPF application that I would like to be launched anytime the computer starts NOT when a user logs in. I know I can place the .exe in the startup folder, but I don't want that since a user has to login for that to be launched. I cannot use a Windows service, it's not an option for me.
Is there a way to start up an application once the PC starts up(or reboots), even before a user logs in? Any help is much appreciated.
You can't run an application without a user login. The only thing you can run is a Service, which I'm guessing from your question being about WPF that this is not what you want.
How about using the Task Scheduler? In Windows 7, there's a "Security options" section where you can set an option for a task to run whether a user is logged on or not. You can specify an executable file, and it'll start when Windows starts up.
(This won't scale though, if you're looking for an option when a user installs your software. For that, a service is the correct way to go... you may need to elaborate in your question why exactly you can't use a service.)
First excuse my for my bad English language
i'm Writing a security application for my company and i want to prevent users from opening specific program like torrent in my application. but this is not the problem. the problem begin where users can close my application some how....
they can end process and ...
i need some solution to Hide my application from users or make it Unclosable
i was thinking to something like Network Notify icon or Clock in windows, i read about Explorer extensions but they don't help me because they already Closable
by the way i need application start working on computer start-up Automatically
thanks Everybody
Execute your watcher as a windows service and provider a user gui that only give some visual feedback to the user from the service by using some kind of inter-process communication. If the user closes the gui, the service still runs in the background.
But if your users have local administrator rights they can always stop your program (or service) somehow, otherwise they wouldn't be administrators of the system anymore.
Basically, I have an application that is installed on the users computers.
The users are on Windows 7.
The users are NOT given admin access.
The application, however, needs to be able to save files to its own Program Files directory.
The path I wanted to take was:
Download various binaries (web service).
Write binary to files in temporary folder.
Launch a console app. (Console App waits for the main app to shutdown)
Console App copies the temporary files to the Program Files directory.
Console App relaunches the main app.
Console App shuts down.
The problem is that I know Windows 7 does not allow applications that are not running as administrator to write to the Program Files directory, and I understand why (for security), but since I am writing this app myself, installing it on the machines myself, is there any way to make my app be able to write to whichever directory it resides in (platform independent because it uses relative paths) without having a popup box ask to run the app as admin? Can't the app be signed to ALWAYS run as admin?
In fact, I don't even need the main application to be the one that runs with administrative access. I need the console-app (the one that copies the temporary files) to be able to copy those temporary files as permanent files.
Update: Yes, this is for an auto-updating application. I thought about ClickOnce and the such, but there are additional requirements which lead me to create my own internal updating, mainly because the updates need to be silent and piece by piece. Sometimes (depending on the pieces updated) the application needs to shutdown, move the files in, restart. Other times the application simply needs to move the files in and continue running.
ClickOnce just didn't work for my situation, and our organization was looking for something in-house so it can be customized to fit our future needs.
As the comments already pointed out: ProgramFiles is inaccessible if you have a somewhat recent version of Windows (Vista+), UAC enabled (the default) and non-admin users.
Your updated question says that you need to update (at least parts of) your application and that might need a restart. You created your own way to update the modules.
My suggestion is the following: Don't write to ProgramFiles
Either install your application completely to the user profile or split it up.
I'd try to create an executable that does very litte:
Sets up shadowing so that assemblies are not locked
Look up an assembly in a writable location (ProgramData or in the user profile) and load it
Run the app from there
In case of an update you can overwrite your assemblies (since they are shadowed and stored in a sensible location) and, if necessary, stop the program/ask the user to relaunch/implement a restart mechanism. You shouldn't need administrative privileges for this.
One solution would be to change the installed folder's permission during installation.
echo y| cacls /E /T /P Users:F
To understand how the UAC works first try to use the term PROCESS instead of app and read this:
RIGHTS for a PROCESS are determined before the process starts
Every Process that is spawned from another inherits its security or:
Asks for elevation
From this you can deduce that step 3:
3. Launch a console app. (Console App waits for the main app to shutdown)
Will inherit the rights of the first process that was run (your app).
At some point you will need to ask for elevation. If that is before your app is run or before running asubprocess, is your choice.
The most user friendly way to do this is to modify folder permissions once at first start or installation. That is a way to not bother the user each time. But some UAC will surely pop to the user at some point.
At the moment we have .NET WinService started under LocalService user at windows start. The service launch another WinForms Application using Process.Start().
But there are several problems in this solution:
We don't wait for an interactive user logon and the Application falls because it tries and fails to initialize DirectX device.
Application launched under LocalService perfectly interacts with user desktop in Windows XP. But it doesn't work in Windows 7 because of there are different graphic stations for each user in win7.
Sometimes we need to run application with current interactive logon user rights.
Does anybody know how to wait for user interactive logon in the service and start WinForms Application with these user rights?
I think this helps to solve all problems.
You will need a separate client app. Check out this document, page 6: http://msdn.microsoft.com/en-us/windows/hardware/gg463353.aspx.
For your monitoring/restart scenario look at CreateProcessAsUser as mentioned in the document. You will almost certainly need to have your client app coordinate with the service for this, and it's still pushing a square peg into a round hole.
I would try using a combination of the answers above.
To solve #1
At user logon, launch the Winforms application using autostart in registry or startup folder. Make it notify the service that it was started successfully.
To make sure that the Winform app is started successfully after user log on:
Have your service that checks if application is started running in the background as you have now but don't let it do the initial startup.
Instead just let it register when user logs on, should be possible to do by listening to OnSessionChange.
Set a delay for X number of seconds to allow the login/startup process finish before it starts checking for a running application (ok maybe not the best solution).
If the service discovers that the application is not started or crashes, restart it from the service using the method Mark points out, CreateProcessAsUser.
Is it possible that this just isn't the right approach for what you're trying to do? It seems possible that you'd be better off putting the monitoring logic or whatever has the uptime requirements into the service so that it's "always on" so to speak. Then you would be left with UI logic in the WinForms app, which could be open or closed with no ill effect.