Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
The community reviewed whether to reopen this question 10 months ago and left it closed:
Original close reason(s) were not resolved
Improve this question
I've been thinking of rolling my own code for enabling my Delphi application to update seamlessly as I'll be going for "release often, release early" mentality furthermore. There are various Delphi solutions (both freeware and paid) out there and I'd like to ask if you've been using any of them or simply went on with your own solutions in this area. Any comments on the auto-update topic are welcome.
What ever scheme you use, it may be handy to know that you can actually rename a running .exe file. So rename file, copy in new file works nice. And the next time someone launch the program they will launch a the new version. This is ofcourse very handy in enviroment where many users run the same .exe file, like in citrix/terminal server/network share cases.
Years ago I wrote a simple tool which is started instead of the real program, checks for updates, loads and installs them (if any are available), and finally starts the real application.
There are however problems with that approach if your program works in a properly administered environment, where users normally don't have write access to the program directories. You can no longer simply update your own program in such environments. That's why a lot of programs these days come with their own updater tool, which can be installed to run with elevated permissions, so that program updates can be applied even though only standard users do ever log on to the system.
You have to decide whether your target audience can be assumed to run on power user or administrator accounts, or whether you will have to deal with above-mentioned problems. With Vista things got considerably harder already.
With all these problems (net access over proxies, missing write permissions for installation directories, the need to update files that the updater itself is using - just to name a few) I wouldn't try again to code this on my own. Much better to check if any one of the available solutions does all you need it to.
I use the Synapse routines GetHTTP to return a specific resource, and if found then check against the local system to see if an update is required. If so then the resource tells me what page to go to launch and I throw the URL into shell execute so the users
preferred browser is displayed.
Most of the time the download is a setup program created by InnoSetup which updates the users system and database to the latest version. When a new "paid" upgrade is needed, I then send the user to a "purchase upgrade" form. My web resources are ASP pages, so I can redirect to a different resource based on the customers version number.
For the main application (our application has a server piece, and a client piece) I have a loader which will check the server to see if the version of the client file on the server is different than the version on the client...if so, it prompts the user if the user wants to update/revert. We chose to prompt the user as sometimes an accidental bug might make it into the system and the user has to downgrade/upgrade only specific machines to help troubleshoot. I maintain a database record with the minimum version required which is updated via the database patch, so if a version must be retired then the record is updated accordingly.
I created my own solution too based on Indy for downloading and http://sourceforge.net/projects/makeupdate/ for file patching.
Before that I have used and tried several commercial tools, but no one was doing exactly what I needed.
I use TmxWebUpdate. It's free, simple and gives you good control over the process. I actually own TMS Component Pack with TWebUpdate but never really found a good reason to switch.
Edit: Link updated
We rolled our own as well. Its really not too difficult.
Our process goes something like:
When the main app is launched, it checks (using funcs from the synapse library) if there's an update available (assuming its configured to check, of course).
If so, it notifies the user and askes if they want to update.
If they do, it launches an updater .exe, and closes the main app.
The updater exe downloads the new files based on the contents of a text file it retrieves, keepiing the files in memory.
When the updater is done downloading everything correctly, it then saves the downloaded files to disk, backing up any files it replaces. This way if the download gets interupted, you dont end up with half the files installed.
Finally, it launches the main app again, and closes itself.
The trick w/ Vista is that you need to have an entry in the updater program's manifest to force it to run with administrator rights.
Normally we use the third party tool. But in some situations it was not usable so I created an own solution, which was pretty standard:
Get xml (or any other format) with update info.
If newer files are published, download and install them.
I use TWebUpdate . It works ok and has a ton of interesting options, but documentation isn't so great and I did bump into a few problems - which is why I download a full installer, instead of just the files...
I will be keeping an eye on this question, btw...
We use our own solution which follows these steps:
Application connects to http resource and downloads info file (ini text file) to memory, checks version number of newest release.
If newer version available, app downloads compressed binary package to exe location.
When download is finished, user is asked to restart application.
Upon start, application checks for presence of update package
App extracts package contents (usually a new app exe, but additional resources possible as well, e.g. updated language files etc.) - for each file it renames the current/old file to a temp name first, then extracts the new file. If the process fails at any point, the temp files are restored.
When finished, app executes new exe and closes itself.
No additional updater needed, the app exe can handle it all by itself.
For the compressed package we use our own update builder.
The package contains an index of files with a file hash, destination folder (relative path to main exe) and the compressed files.
During update we compare the stored hash with the extracted file to detect corupted files.
With Vista I see two solutions to enable Standard User Accounts to actually update the applications files:
Configure your setup to change permissions of the programs installation directory. This way files in "C:\Program Files (x86)\Your Company\You App" can be modified on Accounts with limited rights.
Example code for InnoSetup would be:
[Dirs]
Name: "{app}"; Permissions: users-modify
Install files that you plan to update to the ProgramData folder instead of the user defined directory and use this directory as an override folder. If files exist in ProgramData, use those, else check in install dir.
InnoSetup code:
[Files]
Source: "C:\Your Project\YourApp.exe"; DestDir: "{commonappdata}\Company Name\App Name\";
Same as "stg" and "GuyWithDogs", I'm using TWebUpdate from TMS. Although the documentation isn't so great, Its not so difficult to learnt.
With TWebUpdate, you have some options what the protocol you use, it could be done via HTTP, FTP or network access.
For communication layer, TWebUpdate uses WinInet. In some machines, the windows / IE URL cache can be frustating, so I've added a routine to clear the auto-update server address from cache first to ensure the information gathered from the server is up-to-date.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I created one service in C# and created installer for that.Installer is working fine and service is installed properly on server. But here is one problem. When server restarts the program connected to service automatically getting deleted from C:\ProgrameFiles location, but service is still there and when restarting this service. I am getting prompt like "windows can not find specified program path". Can somebody help me what I am missing here or what is potential cause for this problem?
I know the the scope of this question is too broad to answer but still I want some hints or any solution to resolve this issue. I tried to searching many forums but unfortuanatly no luck. please consider while vote to closing this question. I can edit more to clarify this scenario.
Thanks.
What kind of server is this? Terminal server?
UPDATE: It isn't a virtual machine is it? If so, are the disks set fully persistent? See 9.
If you run repair on the MSI in question, does the file come back?
What happens if you check the file directly with your malware scanner?
If you shut down the service manually, is the file still there? (just to be sure). Try repeatedly stopping and starting the service a few times.
Did you verify that the service runs from where you expect after installation? (have to ask)
Do you install per-machine or per-user?
Debugging
Check the event viewer and the MSI log files:
MSI Logging: Installsite: MSI log "how-to" and / or More MSI logging information.
Event Viewer: Hold down Windows Key, tap R, type eventvwr.msc and press Enter. Go to Windows Logs => Applications. Look for MsiInstaller events. Check the other logs too (Security, System, Configuration).
Deployment Mnemonic: And a "deployment mnemonic" (yellow section) - some heuristics to think about deployment problems.
Some Ideas
Loose Cannon: While we wait for feedback from you, let's fire off a list of suggestions shooting from the hip. Some of these are bad or
eliminated as causes, let's just list all to remember the bad ones
too:
1) Quarantined malware? (real or false positive, doesn't matter which). The file gets quarantined on every reboot? Upload file(s) to virustotal.com to check binaries that are missing. Do an administrative installation if you need to get hold of the files.
2) Upgrade Problem? (not the cause in this case, but MSI major upgrade can cause this kind of problem - for example when you attempt to downgrade a file to a lower version).
3) System policies? Not really familiar with what policies that could delete files - if any at all. Just mentioning that a lot of policies can affect Windows in general. Check the event logs. Some registry keys are periodically overwritten for example with defined AD settings.
4) Cleanup Scripts? Anything is possible here, but it would be strange to delete a pinpointed executable? Check what runs on boot? Autoruns. Run that tool and have a look at auto-starting binaries - there are a lot on most systems.
5) System Restore? Not relevant here as far as I can tell, but system restore can do VERY strange things such as delete single files from somewhere unexpected out of the blue. Yes, I have seen it (not a fanboyism - I was there - in the fires of mount Doom - it really happened).
6) Recovery hardware? Some computers have hardware devices that restore the system to earlier states on reboot with various options to allow some persistence here and there. No idea how prevailing these are now, but I expect their use for quick malware recovery and stuff like that. Talk to your system administrators?
7) Permissions? Does the package apply ACL permissions to the folder in question? It shouldn't cause this problem, but maybe check it. The service should never be able to start at all if permissioning is wrong.
8) Disk Corruption? An issue that one must always check for.
9) Virtual Machine? One issue that came to mind is whether this server is running as a virtual machine and if so whether the disk setup is one of full persistence? Not sure what is technically possible here at the current day and time.
10) Hidden Icons? One more issue - added in a hurry - some icons can be hidden in the Windows start menu from Windows 8 upwards (I believe, details fuzzy). I suppose this can yield the impression that a product has been uninstalled, when it is just hidden. Almost certainly not relevant for your situation.
Questions
PendingFileRenameOperations: After installation, are there entries in PendingFileRenameOperations? Check BEFORE installation as well.
Are there pending operations waiting for a reboot?
Location: HKLM\SYSTEM\CurrentControlSet\Control\Session Manager
Rollback: Even more obscure, is rollback disabled for Windows Installer? I can't see how that would cause this problem, but it is possible to do and what it triggers and makes possible I am not sure of.
Bitness Confusion: It is possible that people just think that files are missing, because they are looking in the wrong folder (x86 instead of x64 or vice versa). Not relevant here (then the service would start - unless there is something else wrong), but listed to remember it for other, similar cases.
"Out There": This is C:\Program Files\ right? Not C:\ProgramData\? Are there any mounted disks on the NTFS partition? Any symbolic links? Roaming profiles? Do you install per-machine or per-user?
I have a single executable which, via InnoSetup, installs into Program Files\FolderName by default. The exe has a 3rd party component which goes online to check for new versions and downloads them, then does a bit of fiddling to replace the exe - simple stuff. The problem is, it can't do this in Program Files because of the necessary security there. I was reading Windows 7 - Can't update my program's files in C:\Program Files in which David Hefferman gives a solution but then seems to say it's a bad idea - but I don't know whether the bad idea bit refers to his solution or to the OP's comments!
So what is the preferred method by which a program can update itself? One that will work on XPSP3 to Win8. I can't seem to find the right phrase to enter into Google that gives me relevant results. Ignore digital signatures and suchlike for now, for simplicity.
(Please note, it may look like I worded that as an opinion question but it's not - there must be some MS-endorsed way of doing it that I can't find. FWIW this is a Delphi program but any Win32 notes will do)
That 3rd party update utility needs to be run with administrative privileges, you can achieve that programmatically.
There is nothing wrong with installing your application in Program Files, that is the designated purpose of this folder. However, user data that is used by the application should be stored in a different location.
However you run that 3rd party Utility, you should first check the Windows OS version to see if fiddling with UAC is really necessary(Vista+...) and then run the utility in the elevated state.
He says its "extremely bad practice" to fiddle with your system so that normal users can write in "Program Files".
If your program is in "Program Files" it's installed with System Admin rights. So updates need also be installed with System Admin rights.
You can configure InnoSetup to request admin-rights so you can write to "Program Files" but if the 3rd party component does not do this its best to install everything in an other directory.
i.e. C:\Your_Program
That way your 3rd party component can write there.
There are several options here:
The easiest: make updater as a separate program with manifest, which requires admin privileges. Also you can ask for admin privileges when you start your updater. Or you can move your updater into out-of-process COM object instead of separate exe.
You can create hidden user with admin rigths during installation of your program. Then you will run your updater with credentials of this user.
You can install system service during installation of your program and this service will run from system account. So your updater will be implemented as a service.
I have a program I purchased several years ago, the last years when I install a new windows I was call my software programmer to install it again on my PC.
Now I can't find this guy and want to open the program, so I want to know which files is needed to open my exe file and if any keys to the register should I add, I think it's monitoring to check what I should add.
anything like this I can use to know.
P.S: I have the exe file and tried to open it, it asking for some files and already added to the system32, now it not asking for anything but close the program without opening even the 1st screen.
You could also use Dependency Walker to get the static AND dynamic dependencies. The Dynamic dependencies are shown when you use this tool in the so called "profiling mode".
We have a suite of programs that check for new versions at startup, and then download new versions to run if required. This is obviously a problem in Windows 7, when it is locked down as a 'standard user', as they can't write to the c:\program files directory and below. Anyone seen a example of an application that gets around with issue ?
Our applications are written in Delphi, but an example in any language would be useful.
Thanks in advance
Update:
We already have a system for determing whether a new version exists, the only problem is the download and install (if required), as this requires elevation. I can't think of a way that doesn't require an elevation prompt, or our users to reduce their security settings.
Update 2 :
I've asked a subsequent question, rather than adding a new one here
There are two options for application installation:
Application is available for all users: installation or update requires elevation for Windows Vista and up
The application is available for one user: install or update the application in the user profile in %LOCALAPPDATA%, no elevation is required
Ad 2: Google Chrome does this. It installs the .exe here:
%LOCALAPPDATA%\Google\Chrome\Application\chrome.exe
--jeroen
Typically what you will see an application do if it needs to escalate permissions is something like this.
Application determines if upgrade is needed
Application launches an "updater" service that requires "Administrator" permissions
Application updates itself with this updated
Application re-starts
This is a pretty common scenario, especially since to update your own DLL you need to go to a secondary process anyway.
Here are some tips for you to get around updating challenges:
If your file is names 'update.exe' or 'install.exe' then it will automatically force a UAC elevation prompt. This is an easy way to make existing software bypass Windows Vista/7 permissions.
It is not a good idea to have the update checking and update process managed from within your application. The problem is that your app is likely to lock files and need updating itself. An external app should manage your updates.
The simplest update solution is to make an HTTP call that checks for the current product version number, and then download the installer binary if necessary. This won't give you any flexibility in updates, but it is a quick and easy solution.
Our company sells software that specifically helps with automatic updates on Windows 7 UAC (you can visit AutoUpdate+ by clicking here: link text). The best reasons for using a third party solution - any solution - are that you will have more flexibility with your updates and also avoid the finicky challenges of supporting different Windows releases.
Or you can have it so that the user runs a launcher app.
The application uses the LOCALAPPPATH\ folder to store a cache of the main application.
Launcher checks to see if the internet has newer version of file(s) than the cached file.
Launcher launches the cached application in LOCALAPPPATH
Your app can check if a new version is available on the remote server. If it does, then it can download update files in one of user-specific folders, like user's temp folder. You can get address of such special folders using SHGetSpecialFolder API function.
Once the download is done, you can pop up a dialog box telling user that you are ready for update. If user agrees with update, then you can run the updater process with elevated privileges (as administrator), and updater process can replace existing files in your installation path with the ones already downloaded in user Temp folder. To run your updater as administrator, you can use ShellExecute:
ShellExecute(0,'runas','notepad.exe',nil,nil,SW_SHOWNORMAL);
When updating is done, your updater process can restart your app.
You need to have a separate executable to the updating work. The updater needs to have a manifest that marks it as requiring elevation.
See: http://msdn.microsoft.com/en-us/library/bb756929.aspx
If your application uses MSI (Windows Installer) for its installer, then User Account Control Patching, if properly configured, can let you install updates without elevation.
If your installer wasn't run under admin - you don't need any additional rights to install update.
If your installer was run under admin - then it can create a task in Task Sheduler. Say, run this task once a week, under this account (admin) and with highest privs. Task will be your updater. Simple.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
The community reviewed whether to reopen this question 10 months ago and left it closed:
Original close reason(s) were not resolved
Improve this question
I've been thinking of rolling my own code for enabling my Delphi application to update seamlessly as I'll be going for "release often, release early" mentality furthermore. There are various Delphi solutions (both freeware and paid) out there and I'd like to ask if you've been using any of them or simply went on with your own solutions in this area. Any comments on the auto-update topic are welcome.
What ever scheme you use, it may be handy to know that you can actually rename a running .exe file. So rename file, copy in new file works nice. And the next time someone launch the program they will launch a the new version. This is ofcourse very handy in enviroment where many users run the same .exe file, like in citrix/terminal server/network share cases.
Years ago I wrote a simple tool which is started instead of the real program, checks for updates, loads and installs them (if any are available), and finally starts the real application.
There are however problems with that approach if your program works in a properly administered environment, where users normally don't have write access to the program directories. You can no longer simply update your own program in such environments. That's why a lot of programs these days come with their own updater tool, which can be installed to run with elevated permissions, so that program updates can be applied even though only standard users do ever log on to the system.
You have to decide whether your target audience can be assumed to run on power user or administrator accounts, or whether you will have to deal with above-mentioned problems. With Vista things got considerably harder already.
With all these problems (net access over proxies, missing write permissions for installation directories, the need to update files that the updater itself is using - just to name a few) I wouldn't try again to code this on my own. Much better to check if any one of the available solutions does all you need it to.
I use the Synapse routines GetHTTP to return a specific resource, and if found then check against the local system to see if an update is required. If so then the resource tells me what page to go to launch and I throw the URL into shell execute so the users
preferred browser is displayed.
Most of the time the download is a setup program created by InnoSetup which updates the users system and database to the latest version. When a new "paid" upgrade is needed, I then send the user to a "purchase upgrade" form. My web resources are ASP pages, so I can redirect to a different resource based on the customers version number.
For the main application (our application has a server piece, and a client piece) I have a loader which will check the server to see if the version of the client file on the server is different than the version on the client...if so, it prompts the user if the user wants to update/revert. We chose to prompt the user as sometimes an accidental bug might make it into the system and the user has to downgrade/upgrade only specific machines to help troubleshoot. I maintain a database record with the minimum version required which is updated via the database patch, so if a version must be retired then the record is updated accordingly.
I created my own solution too based on Indy for downloading and http://sourceforge.net/projects/makeupdate/ for file patching.
Before that I have used and tried several commercial tools, but no one was doing exactly what I needed.
I use TmxWebUpdate. It's free, simple and gives you good control over the process. I actually own TMS Component Pack with TWebUpdate but never really found a good reason to switch.
Edit: Link updated
We rolled our own as well. Its really not too difficult.
Our process goes something like:
When the main app is launched, it checks (using funcs from the synapse library) if there's an update available (assuming its configured to check, of course).
If so, it notifies the user and askes if they want to update.
If they do, it launches an updater .exe, and closes the main app.
The updater exe downloads the new files based on the contents of a text file it retrieves, keepiing the files in memory.
When the updater is done downloading everything correctly, it then saves the downloaded files to disk, backing up any files it replaces. This way if the download gets interupted, you dont end up with half the files installed.
Finally, it launches the main app again, and closes itself.
The trick w/ Vista is that you need to have an entry in the updater program's manifest to force it to run with administrator rights.
Normally we use the third party tool. But in some situations it was not usable so I created an own solution, which was pretty standard:
Get xml (or any other format) with update info.
If newer files are published, download and install them.
I use TWebUpdate . It works ok and has a ton of interesting options, but documentation isn't so great and I did bump into a few problems - which is why I download a full installer, instead of just the files...
I will be keeping an eye on this question, btw...
We use our own solution which follows these steps:
Application connects to http resource and downloads info file (ini text file) to memory, checks version number of newest release.
If newer version available, app downloads compressed binary package to exe location.
When download is finished, user is asked to restart application.
Upon start, application checks for presence of update package
App extracts package contents (usually a new app exe, but additional resources possible as well, e.g. updated language files etc.) - for each file it renames the current/old file to a temp name first, then extracts the new file. If the process fails at any point, the temp files are restored.
When finished, app executes new exe and closes itself.
No additional updater needed, the app exe can handle it all by itself.
For the compressed package we use our own update builder.
The package contains an index of files with a file hash, destination folder (relative path to main exe) and the compressed files.
During update we compare the stored hash with the extracted file to detect corupted files.
With Vista I see two solutions to enable Standard User Accounts to actually update the applications files:
Configure your setup to change permissions of the programs installation directory. This way files in "C:\Program Files (x86)\Your Company\You App" can be modified on Accounts with limited rights.
Example code for InnoSetup would be:
[Dirs]
Name: "{app}"; Permissions: users-modify
Install files that you plan to update to the ProgramData folder instead of the user defined directory and use this directory as an override folder. If files exist in ProgramData, use those, else check in install dir.
InnoSetup code:
[Files]
Source: "C:\Your Project\YourApp.exe"; DestDir: "{commonappdata}\Company Name\App Name\";
Same as "stg" and "GuyWithDogs", I'm using TWebUpdate from TMS. Although the documentation isn't so great, Its not so difficult to learnt.
With TWebUpdate, you have some options what the protocol you use, it could be done via HTTP, FTP or network access.
For communication layer, TWebUpdate uses WinInet. In some machines, the windows / IE URL cache can be frustating, so I've added a routine to clear the auto-update server address from cache first to ensure the information gathered from the server is up-to-date.