Tuesday, January 13, 2009

 

Auto Update application


A very common problem for desktop application programmers is the method of upgrading/installing new versions of our applications, when you have, say 10 customers with 5 PC's running your apps and you add a new feature, you have to upgrade 50 computers!, a real pain.

Last week, I was thinking of a method to solve that problem, and taught the way should be to move my applications to the web with IntraWeb or something similar, but after a couple of tests I came to the conclusion that my applications (specially the Medical applications) can't run on a web browser, as they use many technologies very tied to the underlying operating system (multimedia recording cames to my mind). Then I dreamed about creating something like a browser for desktop applications, who connects to a server via Http then the server responds to events requested by the client to draw the dialogs and forms, that way, the client is allways up to date, just like the web pages we look every day. I made a couple of examples, but it turned out to be a very complicated task.

After my failed attempt, I started to look for someone's else's work and found a couple of similar projects for Object Pascal, they are MseIfi (from the author of MseIde/MseGui) and RTC WAC (from RealThinClient), very promising, but both are in its early alpha stages of development.

Then, I went for XUL (Mozilla's rendering engine) and Adobe AIR, but I didn't like them because they are very complicated to program (lots of hand made XML/JavaScript) and too slow to compile/run, at least tha't was my impression compared to native Delphi programs.

Well, let's see...My desktop apps run very well, and my customers love them. Why should I start using a different technology just because I found a stone in my way?. The solution was ages simplier than re-programming the whole thing, just include an Auto Update mechanism!.

TAutoUpdate was born

The AutoUpdate mechanism needed was easy to create, I made a class I called TAutoUpdate, now implemented it in my currently running systems, and It works really neat!. Because of that, I wanted to share with anyone interested and created a new Google Code project for that matter.

If you like it, or have any suggestion, please don't hesitate to share with me and the community around TAutoUpdate.

Again, the link is this: http://code.google.com/p/tautoupdate/
Comments:
For a local net you may place exe's to a single shared directory on common drive (like database is) and set all path's to this directory. This is very very simple! And don't requests anymore
 
Yes, I use your aproach in one of my customers, but what if the app is used outside that network? and what if some customers uses Windows and others Linux?
 
Why you don't create one shared directory on a shared drive? Put into this directory all yours exe's and set all paths to exe's, so you may load exe from one place. It is very very simple :)
 
Anonymous, the same answer is for you. Some times the applications doesn't reside in the same network/domain.
 
A big problem you have if youuse a shared network place to run your exes is that you'll find them locked by the OS when (at least) a user is executing.
So your update needs a cooperation from users that shoud close their application during updates...
 
Have you had a chance to interact with Vista UAC much yet?
 
Only a couple of times, just when I had to configure Windows Mail for my coworkers, and of course I had to disable UAC.

Thank's god I can decide which O.S. I use on my machine, and hopefully I'll never install Vista.
 
Multimedia recoding can be done cross-platform without the need of delphi with flash, e.g.:

http://www.youtube.com/my_videos_quick_capture
 
to Anonymous 12:39 PM
I practice daily builds and
I often have to convert database structure, so my 70 users closes their application during updates
(for 10-15 minutes)
 
Create a launcher that checks a common location for an update ( when compared to the user's local copy of the program). If needed, then copy the newer program. Finally jump into the copy the user has.

Been doing this for years with over 20 users and 15 programs on a lan.

Jim
 
An option is needed to indicate where it stores the opdates options (registry/ini file).
 
I agree with Jim, I use a launcher that checks security, then checks if there is a new version of the executable. Once the new version has been moved across then it's launched.

Because the user has already authenticated, we don't want to make them authenticate again so the username and password are passed to the executable (with the server details, and obviously encrypted) - the end result just looks like a login box!
 
Dumitru: can you send a patch to TAutoUpdate to handle registry entries? it already works with ini files.
 
Try this: http://www.skch.net/columns/HOPE.html
 
Hi Leo,
I post in the forum, just a questions:

Work it for lazarus/fpc?

TIA
 
This project currently has no downloads?.

http://code.google.com/p/tautoupdate/
 
Hi Maximum, you can get the code from the svn server. I didn't uploaded the code to be downloaded yet.
 
[quote]A very common problem for desktop application programmers is the method of upgrading/installing new versions of our applications, when you have, say 10 customers with 5 PC's running your apps and you add a new feature, you have to upgrade 50 computers!, a real pain.Last week, I was thinking of a method to solve that problem, and taught the way should be to move my applications to the web with IntraWeb or something similar, but after a couple of tests I came to the conclusion that my applications (specially the Medical applications) can't run on a web browser, as they use many technologies very tied to the underlying operating system (multimedia recording cames to my mind). Then I dreamed about creating something like a browser for desktop applications, who connects to a server via Http then the server responds to events requested by the client to draw the dialogs and forms, that way, the client is allways up to date, just like the web pages we look every day. I made a couple of examples, but it turned out to be a very complicated task.After my failed attempt, I started to look for someone's else's work and found a couple of similar projects for Object Pascal, they are MseIfi (from the author of MseIde/MseGui) and RTC WAC (from RealThinClient), very promising, but both are in its early alpha stages of development.Then, I went for XUL (Mozilla's rendering engine) and Adobe AIR, but I didn't like them because they are very complicated to program (lots of hand made XML/JavaScript) and too slow to compile/run, at least tha't was my impression compared to native Delphi programs.Well, let's see...My desktop apps run very well, and my customers love them. Why should I start using a different technology just because I found a stone in my way?. The solution was ages simplier than re-programming the whole thing, just include an Auto Update mechanism!.TAutoUpdate was bornThe AutoUpdate mechanism needed was easy to create, I made a class I called TAutoUpdate, now implemented it in my currently running systems, and It works really neat!. Because of that, I wanted to share with anyone interested and created a new Google Code project for that matter.If you like it, or have any suggestion, please don't hesitate to share with me and the community around TAutoUpdate.Again, the link is this: http://code.google.com/p/tautoupdate/[/quote] i agree

PS offtopic [url=http://vidbar.tv]watch movies online[/url] yes all new movies here
 
Post a Comment



<< Home

This page is powered by Blogger. Isn't yours?