Auto-update add-on to VB?
I'd like to add support for auto-update à la Yahoo/MSN to our VB applications, so that our customers who have Internet access are notified at launch time whether an update is available.
Before writing my own clunky solution, I'd like to have your feedback ...
1. on the products I found (feel free to add products I missed):
FileStream InstallConstruct http://www.filestream.com
Bennet-Tec UpdateLive http://www.bennet-tec.com
Sunisoft IncUpdate http://www.sunisoft.com
Indigorose TrueUpdate http://www.indigorose.com
Lindersoftware SetupBuilder Web http://www.lindersoftware.com
Asta Binary Patcher http://www.astatech.com/products/binarypatcher + add-ons TWebUPdate or WebUpdate2
Install Shield's WebUpdate http://www.installshield.com
Wise Installer http://www.wise.com
Installer VISE http://www.mindvision.com
2. ... and on some requirements I thought of:
- Little or no work to integrate to existing VB applications (eg. just a call in Sub Main() or ActiveX to add to project)
- Ideally, this tool can parse the source code and the compiled EXE and update the list of dependencies automatically (ie. I don't need to think about updating the list of dependencies when adding a file to the project such as a new OCX or some JPG, etc.)
- The UI (eg. "A new version is available. Would you like to upgrade?") must be available in major languages, not just English
- For those customers connecting in dial-up, must be possible to let them ignore the update only for so many launches or time (ie. we want them to update at least once a month)
- Also for dial-up users: The tool must be able to launch the RAS connection directly, instead of requiring their clicking on Cancel in the UI, connect themselves, and relaunch our app
- Dial-up users again: Able to deploy the update to other hosts on the LAN from the host that has the Internet dial-up modem
- Since our www server is a shared host, this solution should not require our installing any binary program on the server, unless it's a PHP script
- Must be easy to deploy, ideally compiled into the main EXE or as an OCX that we can stick into the EXE with PE Bundle so as to make this change transparent to our existing customers
- Works on all flavors of Windows
- Anti-virus- and firewall-friendly, and knows how to handle the case where the user is logged on with
insufficient rights to update files
- Handles cumulative patches, and only download the delta this particular customer needs (ie. if many patches are available since the customer didn't upgrade for a month, should only retrieve the latest patch, instead of downloading and patching multiple times)
I doubt any tool satisfies all of those requirements, and at an affordable price, but we'd be happy to find an affordable solution that could at least handle customers with a permanent Internet connection.
Thank you for any help
Saturday, August 28, 2004
Fred -- I don't know any of the listed product but we have a commercial VB6 app being used by about 2000 users (small companies) and wrote our own autodownload program... due to the fact that we had spesific requirements.
We wrote an update program using TCP/IP controls from n/software (IP*Words) -- great software.
Some issues that we had to deal with .
- Will it need to work via a firewall -- is all supported?
- What should happen with new exe's of the application. Shut down application and restart?
- Do you want to download non exe/dll's, what should happen to them?
- Should different users get different files? based on what?
- What should happen if the file can not be downloaded?
- Is some files mandatary and some optional?
- Do you want to use the method to also upload files to the server?
- Should it communicate with just 1 server or find the best connection between a few?
- Can the download run in silent mode or must it always be visible?
- Will updates be full files or incremental (patches)
- http / https?
I will be following the tread with interest but don't write off custom application just use something like IP*Works to take care of protocol.
Saturday, August 28, 2004
Thx Liam. I assume IP*Works is a more solid alternative to MS' ITC control that comes with VB?
>>Will it need to work via a firewall
I mean that ideally, it should be like Yahoo, ie. either transfer files through a special port, or through HTTP so as to avoid having to ask customers to pay the person who handles their computer needs (most don't have anyone handy)
>> What should happen with new exe's of the application. Shut down application and restart?
Right. I guess there's no way to update a running app, but it doesn't matter, as it's a client application.
>> Do you want to download non exe/dll's, what should happen to them?
Yes. The thing is that I'd rather a tool that generates the update automatically starting from the VB project, so we don't update an INI file manually on the server (eg. just adding a TXT to a project = new dependency. As I'm sure someone will forget to update the list of dependencies on the server, I'd rather that the solution handles this as well)
>> Should different users get different files? based on what?
No, we just want to automate updates. Right now, we have to ask them to go to the Download section of our site, and download such and such files. Time consuming and just plain stupid as we can't call all of our customers each time, so only the one(s) who made the request for a change are asked to download.
>> What should happen if the file can not be downloaded?
It should be able :-) If it can't because the Internet is down repeatedly (ie. it's been a month since the last update), they should call us.
>> Is some files mandatary and some optional?
Whatever files need to be downloaded. For some, it'll be an update. For others, it will be a brand new file since this is a new dependency, ie. the tool should keep track of all the changes made to a project.
>> Do you want to use the method to also upload files to the server?
Not right now, but it could be handy if we need to have a copy of their DB file to investigate a bug.
>>Should it communicate with just 1 server or find the best connection between a few?
No, just one. We're a small shop, and only have one, shared www server.
>>Can the download run in silent mode or must it always be visible?
Visible is OK. Like Yahoo/MSN, it should just show a dialog when launching the main EXE, handle the update if need be, launch the main EXE, and die.
>> Will updates be full files or incremental (patches)
Since a good portion are still on dial up, I'd rather that the tool handles patches, but they should be cumulative (ie. if we have issued multiple updates since the last time the application was launched, the tool should do like MS, and generate cumulative patches.)
>> http / https?
HTTP is fine.
There are possibly more requirements I couldn't think of since it's not my line of duty, though :-)
Saturday, August 28, 2004
MMm... I'm already trying a fifth tool :-)
I narrowed it done:
1. A software is not just a single EXE, but a bunch of files
2. At 56Kbps, you should handle patches, not sending out whole files (since only part of each file changed from n-1). No one is going to wait 20mn for the whole thing to get updated, especially when they launched your app to get some work done
3. Non-binary files don't have version numbers, and those that can have one, often don't have any, or the developer forgot to update them. Use a hashing algo instead to identify a release.
4. The UI must be available in languages other than English, and come with the standard stuff pre-translated (don't want to do this myself, or pay a translator)
Moral of the story: It's always worse than it appears :-)
Monday, August 30, 2004
Fog Creek Home