At the office, when I leave for the night I very rarely log off or reboot. I simply lock my workstation and go home, leaving all my development tools exactly how I left them.
If Windows-Update rolls through and reboots my machine in the middle of the night I'm only slightly peeved because when I log back in the next morning, any MS Office application, or Visual Studio instance I had running will have already automatically restarted, opening whatever file(s)/projects/solutions I may have been working on.
My question is: How can I make my Windows Forms applications (C#) do this? Is there some way for my application to "register" that it wants to be restarted if the system automatically reboots?
I think the RegisterApplicationRestart Win32 API function might be what you're after, it's part of the Restart Manager API.
If you have Windows Vista or Windows 7, you can use the Managed Restart and Recovery API. The links on that page also point to some useful blog entries
http://channel9.msdn.com/posts/DanielMoth/Windows-Vista-Restart-amp-Recovery-APIs-from-managed-code/
A simple way is to add an entry to the following registry key :
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce
Just create a value containing the path of your app (optionally including command line arguments). The app will be run at the next startup, then the value will be deleted.
Step 1: Figure out a way to differentiate a windows-triggered restart from a standard one. One solution would be to try preprocessing messages. They're probably different for a windows-triggered restart...or at least they are in Vista in some cases :/
Step 2: If you detect it's a windows-triggered restart, add a scheduled, one-time task.
Related
I have a windows app (written in C#...) that is installed on multiple remote workstations, the installation is being done by a MSI package.
An updated installation with changes to the program is being conducted from time to time, at this point, for each update, for each station we need to go to where the .MSI is located copy it and run it and only than start the app.
I would like that: whenever a user tries to start the app a background process will be initialized that will compare the installed version with the most recent version on the .msi location and if an update in needed will run the installation and than start the app.
The problem is that it can't be done from within the program since the program cannot be running when the installation/upgrade is taking place. Another consideration is that not all the stations operating at the same time so I can't schedule a timely upgrade, and it can't be done on stations boot since sometimes the updates needs to be done while the station is already operating(the station has several functions beside my app).
I have considered several approaches, it seems like a windows service could do the trick but I don't know if it could be "bound" to the initialize of the program and if it could suspend the program to do the necessary checks and updates and only than to restart the app.
I am open to all ideas so please don't feel obligated to my ideas...
at this point, for each update, for each station we need to go to where the .MSI
is located copy it and run it and only than start the app.
Fire the guy pretending to be a system administrator.
Unless you have done something odd in your installer - it should be doable with your standard software distribution package. Heck, I can roll out updates with active directory ONLY and no third party software as long as the MSI allows administrative no ui installs.
You try to fix a non-problem. Software distribution is a solved solution for the last 15 to 20 years. MSI was particularly created to handle this issue because other approaches demonstrated issues.
So, whoever pretends to be the administrator on your company needs to get his act together and be one. Do nothing (except making a good MSI) and let the admin do his job.
Everything else just creates a lot of problems (at least in the cost side). And it is totally not needed.
I'm updating my answer,
This is what we did....
Create the Installer / Package ( you can install for all users here)
Generate Bootstrapper (https://msdn.microsoft.com/en-us/library/ms165429.aspx
You can use this tool create bootstrapper (http://www.softpedia.com/get/Programming/Other-Programming-Files/Bootstrapper-Manifest-Generator.shtml)
Add dependencies and other conditions in bootstrapper
Set the URL for updates
This will solve your problem. I was too quick to answer but this how we did.
Thanks.
Some comments and answers about the assumptions in the question:
"I would like that: whenever a user tries to start the app a background process will be initialized that will compare the installed version with the most recent version on the .msi location and if an update in needed will run the installation and than start the app."
The only time this is likely to be a useful approach is when the MSI is at a company's web server. The web site can host a web api that you send your ProductCode, Version, Upgrade to and it reports whether there is an upgrade, patch etc, and a location to download it from. In a company domain, just use AD, as has been said.
"The problem is that it can't be done from within the program since the program cannot be running when the installation/upgrade is taking place."
Why? Windows Installer will show FilesInUse dialogs for the end user to close down the running app. So this situation is already dealt with, and I'm not sure where you see a problem.
"...and if it could suspend the program to do the necessary checks and updates and only than to restart the app."
This is exactly what Restart Manager is for. Integrate your app with RM and Windows Installer will allow you to close down the app (saving whatever data you need to recover) and then restart you afterwards so you can recover your data and the user sees a minimal interruption. One example:
http://www.codeproject.com/Articles/772868/Restart-Manager-Support-For-Windows-Application
So I think TomTom's point is valid - there is no need to re-invent what AD does, or worry about how to update programs that are running, or how to restart a program after an installer update because all these problems were solved years ago.
I'm working on a small piece of software which is designed for some special Windows based kiosk devices. It listens for certain keystrokes/commands using a driver, intercepts them and performs certain actions.
At the minute, I've got my Proof of Concept working great. I can either run it as a console application in the background, or I've also built it as a Windows Service. The Windows Service is really effective and is working well, but a colleague has hinted that it'd be good to be able to do tasks based on what user application/window is active - something I can't do (legitimately) from a Windows service because it can't enumerate user applications.
The obvious solution would be to simply run it in the background - no drama there, except these kiosks use a custom Windows shell (Deployed using Group Policy). Because of this, the normal explorer Run keys don't initialise. I'm now at a loss on how to make my software autorun in this scenario?
Alternatively, if someone has a workaround for enumerating active windows and such for a specific user from a Windows service I'd be interested in that. NB: I don't need to actually do anything TO the desktop, just read data.
Windows Vista and above won't let a service interact with desktop apps at all, part of the new focus on security in the OS. I have something similar (in spirit) that I developed for an application system, which enumerates windows looking for a specific legacy app then sends some messages to it (all very much above-board, no other way to automate the creaky old app). I just launch it as a system-tray app when people log on, using Group Policy. But I don't have the issue of a custom Windows shell that you're apparently dealing with. Good luck!
So, userinit (HKLM\Software\Microsoft\Windows NT\Current Version\Winlogon\) probably isn't a particularly bad place to do this, but there should be an alternative or two. It's actually a little silly (if you ask me) how many Autorun locations have cropped up in Windows over the years.
The following is largely copied from http://www.bleepingcomputer.com/tutorials/windows-program-automatic-startup-locations/, with an update or two. I figured it might be handy here, too, and who knows what will remain live on the web forever (or not)?
Other Autorun locations include the following in order:
Boot device drivers
Hardware related.
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services
Windows does some housecleaning then starts Winlogon, which starts the service control manager, which starts services and drivers.
Services
The SCM launches services and drivers that are marked with a Start value of 2.
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services
RunServicesOnce
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunServicesOnce
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunServicesOnce
RunServices
HKLM/.../RunOnce entries won't run until these finish starting.
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunServices
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunServices
** The logon prompt is shown, user logs on, then auto-start processing continues.
Notify runs programs in response to events, including logon, logoff, startup, shutdown, startscreensaver, stopscreensaver. Malware often uses this key to start itself.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Notify
UserInit specifies programs that should be launched immediately after a user logs on, takes a comma-separated list of programs. The default userinit.exe program loads your profile. Also a common key for malware to use.
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Userinit
Shell contains a comma-separated list of programs that userinit.exe will launch. The default shell is explorer.exe. First the program(s) in HKCU are launched, then the ones in HKLM.
HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell
** The rest of the Autostart locations are processed now...
RunOnce (HKLM) Primarily intended for setup programs, deleted by the OS after the first run if the path is preceded by an exclamation point (!), else deleted before the program runs. These programs are started synchronously in an undefined order, so they must all complete before the HKLM/.../Run, HKCU/.../Run, HKCU/.../RunOnce and Startup folders can be loaded. These keys are ignored when booting in safe mode.
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnce
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnceEx
Run Most common startup locations for standard programs to autorun from, ignored in Safe Mode unless prefixed with an asterisk (*).
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
Startup Folder (All Users)
Win7 and up %ProgramData%\Microsoft\Windows\Start Menu
Win XP/2K C:\Documents and Settings\All Users\Start Menu\Programs\Startup
Startup Folder (Per User)
Win7 and up %USERPROFILE%\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup
Win XP/2K %USERPROFILE%\Start Menu\Programs\Startup
RunOnce (HKCU) intended primarily for setup programs, same semantics as the HKLM RunOnce key (above).
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce
Explorer Run generally used to run programs as per policy configuration.
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run
Load Key deprecated, not commonly used anymore.
HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows\load
AppInit_DLLs this registry value contains a list of dlls that will be loaded when user32.dll is loaded. Many programs load user32.dll, so anything listed here gets loaded into all of those programs, as well. Used by malware.
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Windows
ShellServiceObjectDelayLoad similar to the Run key, but points to a registered CLSID InProcServer value. Files listed under this key are automatically loaded by Explorer when the computer starts, early in the startup process.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ShellServiceObjectDelayLoad
SharedTaskScheduler Files listed here run automatically when you start Windows.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\SharedTaskScheduler
Other potential autostart locations, depending on the OS:
c:\autoexec.bat
c:\config.sys
3 . %WINDIR%\wininit.ini - Usually used by setup programs to have a file run once and then get deleted.
%WINDIR%\winstart.bat
%WINDIR%\win.ini - [windows] "load"
%WINDIR%\win.ini - [windows] "run"
%WINDIR%\system.ini - [boot] "shell"
%WINDIR%\system.ini - [boot] "scrnsave.exe"
%WINDIR%\dosstart.bat - Used in Win95 or 98 when you select the "Restart in MS-DOS mode" in the shutdown menu.
%WINDIR%\system\autoexec.nt
%WINDIR%\system\config.nt
I've got the end result I want by adding my application to the UserInit registry key:
HKLM\Software\Microsoft\Windows NT\Current Version\Winlogon\
Userinit c:\windows\system32\userinit.exe,c:\myapp\myapp.exe
This works great, but does seem incredibly hacky and I'd love alternatives.
Using a Windows Service is the best option and since services are isolated in Session 0, you can have this service starts another exe upon user logon, by calling [CreateProcessAsUser][1]. In fact, the service executable can call itself with a parameter indicating that it is invoked as a user and therefore all User Interface parts (which normally won't work from Session 0), will be enabled.
My application is installed on ATM-like machines arouns the world.
It is a WPF application which needs to be automatically updated behind the scenes and without user interaction at all.
Right now we're using Click-Once silent install API and it works perfectly. Our current functionality keeps checking constantly behind the scenes if there is a new version and if such exists, it updates the application, waits for the machine to be Idle (untouched by any users for 5 minutes) and only then it restarts the app. After the restart, a new version is loaded.
Is there a way i can achieve all this using MSI's ? Here's a summary of what i need:
Remote and silent updates for all machines - i already know i can achieve this using LogMeIn and MSIEXEC (so no need to answer this bullet)
Update the application while it is running, without restarting it.
Restarting the application and running the new version only when the application is Idle for 5 minutes.
Any suggestions? If not MSI then any other installer perhaps?
I Can't use clickonce because i want to set my application as the Shell (instead of cmd.exe) in Windows Embedded 8.
It's an interesting high availability story and I can' think of a way to solve it and while MSI will work, it's not really an installer problem per say.
I'd create two installers: ContentManager and Application
The CM once finished should hardly ever change. It's job is to check for available updates and the idle status of the application. When an update is available and the application is idle it can perform a new silent side by side install of application in the background. Note I said install not upgrade. Now you have 2 versions of application installed. When the old application is still reporting idle it could be shutdown and the new version launched.
This would be highly available and MSI wouldn't need to know anything about the scenario. It's simply performing an install.
If you don't need it quite this highly available, then the other thing to consider is that Windows Installer supports "Restart Manager". Your WPF application can also. Your application could check for updates and start an upgrade. The restart manager interaction would then stop and restart your application during the upgrade.
The nice thing about the HA solution is your old version is still there. The content manager could back out the change simply by running the old version of the application.
#Christopher Painter, Thanks for your response. A few thoughts:
The High-Availability solution is good at its base but it would require us to implement too much stuff on our own. A few things you haven't mentioned for such scenarios: 1. what happens if a download fails, what happens if the unzip fails, i would need to uninstall the previous version once install is complete, i would need to implement some security measures on my own (hashing for the 'version xml' or something like that...) how about shared resource locking? i would need to handle it on my own as well... Click once handles all this stuff nicely. Oh and one more thing i'd like to avoid is maintaining two applications instead of one as you suggested. I can't count on the 'Manager' so much that i wouldn't support updating it remotely. I can, however, use a 'push' methodology to activate the MSI using LogMeIn - It lets me upload and send a command to all machines (AMTs). The Restart Manager solution would work for me. Only thing i still haven't figured out is if i can make it hault until the application is Idle, and for how long (it must have some sort of a timeout). I've also researched MSI Custom Actions which can wait on a shared mutex ('idle'). What do you think?
This question may be some times funny for all. Created an application in c# but my problem is in implementing that, the application should not be stopped in any case with out system restart. How can i do this? I heard about circular reference what is it and how can i apply it in my windows application
if it can be done using windows service then service can also be stopped from task manager but i don't want my application to stop
you can not do this, since the application can be closed using Task Manger. So the only way is to create two processes first represent your app second to check if your app is closed run it again.
You could create a service, as suggested in one comment. This will prevent people without administrative controls from stopping it. If people do have administrative control, they will be able to stop your program quite easily.
I checked for tricks kids use to go around Net Nanny. The most common trick is to install a virtual machine and use that for accessing the network. Users who aren't administrators can't install Virtual Box or the like, so the service solution will work against these, as well.
I need a deployment method that do following thing:
Auto-update, like click-once;
Install on all users, like Visual Studio Setup projects.
without admistratives privileges. (except the first times for the requirements)
Can install VB Powerpacks.
The problems is that I'm making a winforms program, that might need to be updated anytime, and that our computers are use by many users (our company run 24hours/days). And we don't want to update my program manually on our 80 computers, for each users!
Click-once could be great if we can do an install for all users (but yes, I already find that it's not possible).
I'M STUCK! Please help.
We use a system where the shortcut to launch our application actually launches an auto-updater. The updater checks the server for any update dlls, and if it finds them, it copies them to the local machine. After that (or if it didn't find any updates), it then launches the application.
This will only work if you have some way to force everyone to log out every now and then. We get around that by having the application watch for a specific file to be updated (the exe itself), and alerting the user every 5 minutes until they relaunch.