Is it possible to set automatic updates in PowerBuilder? - powerbuilder

I’m curious if you can set up automatic updates in a program that was created in PowerBuilder? I read something about PBupdate, but was wondering if any one some insight?

We set this up at one company I worked at. The applications were started from a 'master program' called 'Launcher'. Each application had a version file. When the user started the Launcher, each PB application had its version checked against what was stored on the server. If the versions did not match then the files were copied from the server to the client. Launcher then launched the application executable. With this set up we could easily deploy a new version of an application simply by copying the files to the server and then have the user close the launcher and then re-starting it.

You can download PBUpdater from here:
http://www.topwizprogramming.com/tools.html
I use it for my PBSearch tool. It checks the UTC datetimestamp of all the files and downloads them.

What I did is to create a special directory on our file server. It contains all files needed to run an application. Client PCs just have an icon pointing to the executable(s) there.
This way, each time I need to put a new version in production, I just copy the new file in that directory. Done. Everybody has the same version at the same time.

Related

How to auto update my program on clients [duplicate]

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.
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.
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.
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
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 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.
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.

C# Deployement retaining files over an installation

I have created a Setup and deployment project using the Visual studio and install the setup.
After i install the setup it copies a few files(XML) which on using of the application are configured programmatically .
Now , If the user is reinstalling this setup again i need to ask the user whether these configured files need to be overwritten or be retained ??
Any idea as to how this can be accomplished ?
Thanks & Regards,
Fran
Look into file versioning rules for Windows Installer.
In short, assuming that these XML files you refer to are unversioned text files, MSI will compare the Created and Modified dates and will not replace the updated XML files which you say are updated programmatically (post-install-time).
I would suggest several other variables you need to consider to make sure things are working as you expect: major vs. minor upgrade, and the REINSTALLMODE property.
I find that the best way to approach this kind of scenario is to implement the "preserve changes" logic in your application as opposed to via the setup. This avoids complicating your setup and yields greater control of the config process since all logic is embedded in your main EXE file. This means you can step through the process and debug it the normal "development way".
To achieve this you can install your "base config" files to a read-only location such as
%ProgramFiles%\MyCompany\MyApp\MyConfig*.*
Then your application can detect on launch whether existing config files exist in the user profile (or in a writable shared location), and ask the user whether the new config files should overwrite the existing config or not. You can also easily implement backup functionality for the old config.
In order to ask the question only once per user after deployment, the normal apporach is to flag HKLM with the latest installed version of the application and then write a corresponding flag in HKCU when the copy operation has completed or the user dismissed it:
HKLM\Software\MyCompany\MyApp\Version = 2.0.0
HKCU\Software\MyCompany\MyApp\Version = 1.0.0
In the above scenario version 2.0.0 of the application has been installed, but the per user config copy has not run for the user in question yet. Once it has run the HKCU version will be set to 2.0.0 and the operation is not run again until HKLM is incremented.

Delphi: How do you auto-update your applications? [closed]

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.
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.
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.
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
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 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.
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.

How to delete application file from AppData\Roaming folder

I am using windows installer to create setup project.
How I can remove/delete application files from AppData\Roaming folder when application uninstalled.
I tried added a special folder and set DefaultLocaltion to [AppDataFolder] but it didn't working.
Do I need to do anything else?
I'd need to understand what you are trying to do to give you specific advice. In general what you are trying to do would be OK removing files from CommonAppDataFolder but not AppDataFolder as trying to clanup user data from multiple user profiles is not a best practice. Additionally trying to cleanup Roaming Profile User data is outright impossible because the other users aren't logged on.
You'll want to read:
Managing Roaming User Data Deployment Guide
Assuming you are trying to do what I think you are, you'll need a cleanup script / exe that you leave behind on uninstall and a custom action to write to the registry during uninstall ( MSI can't do this natively ) to call that script/EXE. You'll want to leverage the Active Setup trick as described here:
Using Active Setup to Repair User Settings
The way it'll work is your uninstall leaves the EXE and registry entry behind so that when a user logs on it's roaming data gets pulled down from the server to local and Active Setup realizes it hasn't run the script yet. The script runs (once) and the data is deleted. When the user logs off the data is replicated / deleted on the server. Then they log on again it doesn't run again.
By default Windows Installer does not remove the files created by your application, after the installation. To do that you need to either write your own custom action, that will run upon uninstall, or depending on the tool used for authoring the MSI, you can use built-in options for cleaning the application locations, as some tools have this support.

Updating EXE file from server…

I need to update my application from a central server.
The application checks always if it is a correct version, against the server installation.
So when it is not, I need it to update itself.
So how can I copy the EXE if it is running? What solution do I have?
As you can see by all the answers there is no set way to do this, so I thought I would add the way we have successfully done this.
We never run an application directly from the network.
We run the application from the local machine and have it copy from the network on startup.
We do this using an application launcher. It downloads an XML file that contains CRC and Version Resource Values for the application files. The XML File is created during the deployment process, in a FinalBuilder Script.
The application then compares the XML File to local content, and copies down needed files. Finally we then launch the application in question. This has worked well for deploying an application that serves around 300 local users. Recently we switch from a file copy to an HTTP download as we found problems with remote user disconnecting drives.
We still still build installations (With Innosetup) to get the basic required files deployed.
I rename the current running exe to MyTempExe.exe, copy the new exe to the correct location (request elevated privileges if necessary) and then run a separate app to restart the main app. On start up I check for MyTempExe.exe delete it if it's there.
The reason I use a separate app for the restart is I don't have a set time frame for the app to close down and need to wait for it to finish whatever it's doing, on shutdown it writes information to disk about its current state that the updated app will use to resume where the old one left off.
I don't know if it's the best solution but it's the one I use.
Package your app with an installer such as Inno. Download and execute the installer. Have the installer search for and kill your app, or instruct the user to close it. The setup will replace your .exe, and if the app can't be killed or the user is non-cooperative, it'll issue a re-start notice.
Download new EXE to TEMP
Create Batch from EXE, content:
taskkill /PID %process id of running EXE%
copy %new EXE% %running EXE%
%EXE%
all values in %...% are placeholders
execute batch from the running EXE
delete batch
I use TMS TWebUpdate myself, for software updates. The advantage is that there a bunch of extra actions you can put into the script, if you need anything other than plain EXE updates.
I have two components at work the application executable itself and a web-service (SOAP) which provides version details and file downloads.
The application calls a method on the SOAP service to ask for the number of files in the project (project is identified by using the application.exename usually).
The soap service gets its info from an INI file, which has entries like:
[ProjectName]
NumberOfFiles=2
File1=myapp.exe;1.0.0.1
File2=mydll.dll;1.0.0.2
You just update this file at the same time as uploading your new files.
The process of updating the application this:
Get number of files available on the web service
For each file, the application asks for the name and version number from the SOAP server.
The application compares this information to its own version info and decides if the file needs updating, building a local list of files that need updating.
For each file that needs updating the application downloads the file to filename.ext.new
Finally, the application renames all filename.ext to filename.ext.old and renames filename.ext.new to filename.ext and then restarts itself. (No real need for an external app to restart your own program).
Note 1, that you may have to ask for elevation to replace files, depending on where you install your files.
Note 2: be kind to your users, think carefully before you force updates on users.
Note 3: You cannot delete a running exe, but you can rename it and then restart the new version.
Edit===
For some reference data files which cannot contain version information resources, you can have entires like File99=MyDataFile;1.1.2011 the 3 elements to the version number indicates to the client that it should check against the file date/stamp.
You could have a separate update executable whose task is to check the server version, download an updated executable if necessary, and then run the local executable.
Or you could have one executable running in two different modes: 1. on startup, check for an update, if there is one, download the executable to a download directory, run it and quit.
2. The new executable would check if it's running from the installation directory, if not, it would copy itself there, overwriting the old version, start the copy from there, and quit.
My way is the other way round: If a new version is online, promt the user to update. If he want's to (or is forced to...) I end the app and start a new exe (updater). this updater loads the update and replaces the old exe (not running). then it starts the new exe. ready. (You can of course replace other files too.) BUT: Using an Installer like InnoSetup gives you more possibilities and doesn't mix up with the regular uninstaller, so it is really better...
You can do this without running another application. Push the updates to the client from the server while running, storing in a temporary directory on the client. When you want to upgrade move all your running files to another temporary directory, move the new files into the original application directory, and just restart the application using the standard executable name on shutdown.
I upgrade client applications running on unattended machines automatically this way.

Resources