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.
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.
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?
i've created an setup project for a .net-application which works fine. The problem is, that the application begins to write log-files after startup and this requires administrative rights on windows vista and windows 7. I know there are some folders which i could use to write into without administrative rights. When i start the application as administrator, everything works fine.
I asked myself, if it's possible to change the setup project in visual studio in a way that the installed application automatically owns administrative rights on the target system?
Thanks for every help in advance!
Alex
You don't want to do this. If it needs rights to a particular directory, then create an account that has them (or modify the subdirectory's rights so that anyone can access it). But don't run as admin just for one feature. Also, look into whether there's another directory you could be writing to, which you already have rights to.
To answer your direct question, yes you can setup a launch condition for the setup project to require administrator, I believe this will take care of the proper escalation for you.
here is a thread with detailed instructions.
Now, to expand, I agree with Steven that you SHOULDN'T do this, at least not just to be able to write a log file.....
You could technically do this with a bad hack: The idea is to have the Setup program which runs elevated create a scheduled task that runs the program as admin.
Instead of directly creating a shortcut to your application, the setup creates an shortcut to execute this scheduled task.
See this as reference on how to do that manually: http://www.howtogeek.com/howto/windows-vista/create-administrator-mode-shortcuts-without-uac-prompts-in-windows-vista/
You just need to find a way to create the task programatically from your setup.
On the other hand, I totally agree with Steven too. Try to do it the 'right' way and don't trick the Windows security. It's a good thing and working around it makes the system potentially unsecure, and you don't want to be the one compromising tht Security of others computers.
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.
I know there have been a ton of questions about how to implement automatic updates in a .NET application, and I've probably read most of them. Unfortunately, none I have seen quite fit my situation as far as I can tell.
I am trying to build a self-updating .NET application that will run in an environment with limited user accounts. No admin rights here. The application must run on Vista and XP, and probably Win 7 when it comes out. An X-copy deployment would be fine. I would prefer NOT to use click-once
So far I have tried a system where the application checks a manifest and downloads updated binaries, which worked great in development, but not so much when the app was installed. Vista refuses to to let me copy files to Program Files. After that, I tried downloading an updated .msi, which works except that the MSI has a UAC prompt -- no go if the user does not have an account with local admin privileges.
Some posts have suggested that running the program in AppData and using the x-copy method might work, but I have not seen anyone say that they have tried it and it did work. Will that work for an account without admin rights? Can anyone vouch for this method before I start writing more code?
You do just need to make sure that you're 'installing' (i.e. copying to) a location which non-privileged users have access to.
There's nothing magic about Program Files except that a non-privileged user can't write to it (by default).
If you have an admin do your initial install, then you could change the permissions on your program files folder so that subsequent upgrades could overwrite those files. But that's not really in the spirit of things.
The main disadvantages of ClickOnce are the uncommon install location and the primitive installer - if you're going to be doing xcopy to somewhere weird anyway, then you already have much of what's already icky about ClickOnce, without any of the advantages.
Although fairly complex, one strategy which will work is to create a windows service which runs as local system. Install it once as an administrative user, then have this service download your updates and copy them to the program files directory.
You'll probably also need to make some sort of user interface to display progress and status during the update process. Fairly easy to expose it via a WCF service, or the like.