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.
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.
We are currently looking at modifying the update process for our application, there are many possible ways to do this however I will give a little background first. We are currently running a MVVM WPF / Silverlight application, which has a SQL Server 2008 R2 database running locally and online. We currently have an update process which checks online for an update and then launches an updater program to elevate the permissions ahead of running the MSI or MSP patch files to apply the update.
Unfortunately due to the setup of most of our clients we find that most users struggle with access rights as their local administrators aren't always available. This has led us to looking at alternative approaches.
Our ideal situation would be to have a process run silently in the background under a system user account, which would check the server periodically for updates. When an update was deemed to be available the current user should be informed that an update is available and asked if they wish to download it (There is also discussion of a silent download with a user clicking to run the update when ready). The process could then run a UI to show the downloads in progress, it would again be ideal if this was displayed in the notification area of the Toolbar. At the end of this process it should then run the MSI file under raised permissions to allow the user to update the software without Administrator privileges.
The initial install of the software would be performed by an administrator who would be made aware of this full automated update process.
So my question is:
What is the best practice approach to performing this kind of process?
What suggestions would you have for coding this, for example should we have an application or run the process off Tasks or Services?
Is there software specifically designed to solve this problem?
Is there a specific Windows account which is designed for such as purpose?
Any examples and Pros and Cons of different practices.
I realise this is a very vague question but I would prefer to follow a recommended approach as opposed to reinventing the wheel.
Thanks.
I might be off track here but why not make your application a Click Once application. That way every time your app starts it can check if there is a newer version and prompt the end user to install the updated version.
If there did happen to be a problem with a new version then the end user would be able to roll back to a previous version.
We have used this approach with several WPF applications to great effect.
We tend to publish to a folder on the development machine and then ftp to the public server.
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.
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.
Has anyone managed to get administration rights through the UAC without restarting the application or embedding a manifest file?
I'd like to write to some files that only administrators can modify, without relying to another elevated application. Is it possible to impersonate an administrator previously calling with some native API the UAC prompt?
I guess this is not possible and I'll have to use an external tool with elevated rights, but I'm asking just in case.
EDIT: I know there are some other similar questions around, but since they do not cover the topic of impersonation (as fas as I've seen), nor some possible native call to the UAC prompt I decided to give a new thread a go...
As stated in this other question, it is not possible, you have can eleveate COM object or another process, but not the current process.
Request Windows Vista UAC elevation if path is protected?
I read that thread (along with a lot more heh), but you never know what other people has managed to do recently. And maybe the release of SP2 changed something, dunno.
Well, I guess there are no changes on how the UAC works nor any discovery on workarounds, so I'll mark the previous answer as the right one.
I'll make another application that performs the administrative tasks I need.
Thank you.
If all you want to do it get admin rights without a manifest (ie: im assuming you're not talking about cracking/hacking the UAC implementation), then just create a shortcut with the "Run As Admin" checkbox checked. You can programmatically generate this shortcut as long as you look up how short cuts are written (in terms of their fiel contents) and I'm sure there is some name/value pair you will need to include inside the shortcut to ensure that Run As Admin is checked by default. Now, when people run that shortcut instead of your exe, they will get prompted to run your exe in elevated mode (with admin rights), and this way you will not need to restart or use a manifest.
Excuse me if I have misunderstood your question.
Adding a manifest file in the same directory as the executable "works for me". Not actually getting the permissions, but it prompts for the permission.