Large application which is piece-wise updateable

[battler.]

Hi all,

Whenever we make changes to large applications we distribute then we need to get users to:

1. Completely uninstall the previous version from the Control Panel.

2. Install the new version which is a large zip file containing run-time engine.

Other more clever programs, and I'm sure there's some of you out there doing this, search for updates and only replace the parts of the program(s) which has changed without requiring uninstallation.

To do this does the application need to be built and combined from DLL's or something?

I have seen this done by just distributing the application as VI's but this is not secure and I am talking about distributing as an EXE.

What is the correct architecture to provide an application which can be updated merely by exchanging pieces of the program?

Can an update utility program be written which automatically updates an application and say (freely) replaces files (perhaps DLLs) from the Program Files (admin required?) or Program Data folders?

I hope this is clear.  Thanks for your help!

Battler.

[Norbert_B]

Battler,

in general, you are talking about mechanisms available by building an Microsoft Installer (MSI). Good news: You can directly build an installer using the LV application builder!

But there are also some points you might want to consider:

a) Application Architecture: A monolythic EXE can only be updated by a complete replacement. So at least the EXE will change. Runtime/drivers are often not affected by that changes.

b) Installer Size: Putting everything required for the application (the EXE itself, drivers, runtimes, external code like DLLs, ini/cfg-files, documentation, ...) into a monolythic installer might result in huge packages. Building and installing those might eat a lot of time.

c) Splitting Architecture/Installer: This might result in a good method to update applications, might be a little tricky for installing fresh machines.

The most important part for "updates" with MSI is the "upgrade code": this must be the same in the update as it was in the base package.

hope this helps,

Norbert 

[battler.]

Bit confused.

There are programs which check for updates, download and replace only parts of an application; I have these programs.  This is what I would like to do with my LV app.

Would I need to write an additional EXE which sits manages this updating?

Still confused...

I'm looking for a smarter and easier way to apply updates to my programs without the user having to completely uninstall and reinstall.

[Norbert_B]

---

@battler. wrote:

[..]There are programs which check for updates, download and replace only parts of an application; I have these programs.  This is what I would like to do with my LV app.[..]

---

Are you talking about e.g. Adobe Acrobat, virus scan applications, internet browser, and such?

This is a feature implemented directly into the application. They download the update (installer or similar) and start it in the back ground. But afaik most of those programs have to be shutdown and restarted for the update to take place. So it is common that just replacing some ini/cfg/inf/... files is not sufficient for an update.

If you want to implement something like this, yes, you can do it. But this is really a load of work you have to do easily blowing any time schedule within your project....

Norbert 

[dan_u]

Since a compiled LV application is usually mainly a big .exe file it might be difficult to replace only parts of it. But for just a software update you might not need runtime and probably additional drivers.

So what you could do is that your application checks on a server if there is a new version available, and if there is it will launch an "Updater" which downloads the new executable and replaces the old one. Of course the application must not run when it's being replaced, therefore the separate updater.

(The updater could just download the exe, then ask the user to quit the application (or quit it remotely after the user agrees), then replace the old exe with the new one.)

If your application contains other files in addition to the exe you'll just have to check the versions of all files and replace all which have a newer version available.

[Ben]

You could do it using LVOOP.

It would require the application be developed such that it loads the Classes dynamically and some logic tht checks for updates somehow and downloadds them.

I have never developed the "check for updates and get them" part of the app myself, but I have designed multiple apps using LVOOP that are updateabel without changing the exe.

Ben

[battler.]

I have designed multiple apps using LVOOP that are updateabel without changing the exe.

Ben

---

How does developing with LVOOP make this possible?  I thought it was all compiled into an exe anyway.

I do not want to distribute app as bunch of VIs as these are not secure.

[nathand]

---

@battler. wrote:

I do not want to distribute app as bunch of VIs as these are not secure.

---

 Are you willing to distribute your VIs with the block diagrams (and possibly front panels) removed, or that's not secure enough for you?

[Norbert_B]

Ben is talking about a LVOOP plugin architecture. Some of the classes will not be compiled into the EXE but supplied as extra packages. Those can be updated "quite" easily and, if implemented for this purpose, exchangeable during runtime of the EXE.

Norbert 

[Ben]

---

@battler. wrote:

I have designed multiple apps using LVOOP that are updateabel without changing the exe.

Ben

---

How does developing with LVOOP make this possible?  I thought it was all compiled into an exe anyway.

I do not want to distribute app as bunch of VIs as these are not secure.

---

I supose tht in theory you could write a launcher that after determining it has the latest and greatest invoke dynamcially a top level GUI class that in turn uses dynamic dispatching on all other components but I have nto thought one throug hall of the way.

Plug-ins can be updated rather easily if the required classes are selected and run when the exe goes live.

re:Compiled into the exe

If you code your class hierachies such that they invoke methods that part of the parent class, the exe only has to know about the parents and the icon connector (calling convention). Since child data can flow on a parents wire, the application could serach the compatable classes (if the can be type cast as the parent without error they are children) and load the "Latest and Greatest".

A word example:

Say you have a file work you have to do and the methods used are Set Path, Open, Read, Write, Close.

So planning ahead of time you create  File class that has those methods but in the exe you first search for the children to see if there is a better version. TO support this you add another method like "Get Rev" to the parrent class that will return a revision ID.

You deploy it with any children so the app does not find anything bu the parent so your app runs using the Parent class to do you file stuff.

You then get a phone call saying that the File functions are adding an etra byte when the file is closed.

You X-shoot and find the problem and then you create a child class that has an over-ride VI to fix the bug. The new child class then goes into your on-line update repository.

The next time your customer restarts the app it goes to the repository find the new child adds it to the plug-in directory and the Top-level load s as before but now finds the child that says it is newer. The will now run with the fixed child and you have realized an auto-updatable application that can update itself.

The same concept I think can be applied in teh app specific classes as well. This would allow adding functionality to the app by using a NEW child class in the place of the ORIGINAL parrent and let you get at new method that you added to the child but where not availabe in the orignal parent class.

I hope that helps,

Ben