Is TrueUpdate what we need?

[Victor Heijke]

I posted this question in the wrong group, sorry:


We made a setup (with SUF7.0) for our company that is able to setup and/or update a program.
Currently the users have to run the setup to see if there is an update.
What I want is an option that silently checks if the setup on the server is newer than the installed version on the client.

I tried TrueUpdate to do this automatically, but as far as I noticed, we still have to start the TrueUpdateClient manually or in the Startup folder. The other thing I noticed is that I have to tell TrueUpdate the newest version. This gives me the idea that TrueUpdate is right to update to a specific version and not to the latest version. Is this corrrect?

[Steven Carr]

TrueUpdate, or any program, needs some reference to be able to know when to update a local copy.

Fortunately TrueUpdate is quite flexable in this task.

I will briefly describe my *general* setup and you can ask further questions if needed.

We use TrueUpdate as the controller of the updates and SetupFactory does the actual udpates.

When the client program starts if intermittantly starts TrueUpdate. TrueUpdate will in this case silently search for an update. If one exists it will prompt to install the udpate.

The update is performed by:
- shutting down the application
- downloading the patch/isntaller
- executing the (SetupFactory) installer which works like a patch program. Sorry IndigoRose guys, i am not using VisualPatch in this case.

If there is not update required then TrueUpdate silently closes.

I have set it up so that you can also manually check for updates in which case the standard wizard style update is displayed.

When a new update becomes available then we do need to update the TrueUpdate project.

However you could configure your TrueUpdate project to use a web based resource to indicate if an update is available, without having to change your TrueUpdate project in anyway. You are going to somewhere, somehow create some resource which can be located by the client which can allow them to tell if there is an update. This could be the scripting inside TrueUpdate2 or done by another means, but it needs to be done somewhere.

[Victor Heijke]

Thanks for your information.
What I don't get in the first place is, what is the use of having a client that has a build-inn knowing of the latest version.
I expected that Trueupdate would look at the server to know the latest version. (In the way your suggestion works)

Or do I understand TrueUpdate's g_TargetVersion wrong?

[Mark]

Hi Victor,

What I think Steven is saying is that he has configured his update so that it is entirely client based, however this is not the only way to do it.

In general TrueUpdate 2.0 has been designed to look for a server in order to determine which screens to show and what actions to perform in order to check for an update. But, as Steven has shown, the flexibility of TrueUpdate 2.0 lets you design a solution that is the best fit for your situation.

[Steven Carr]

Mark,

What I think Steven is saying is that he has configured his update so that it is entirely client based

No, we don't use an entirely client based setup. Basically a standard type of installation. It will download the required files via http/ftp list most configuration. Victor seems to be confused on how TU2 works.


Victor,

what is the use of having a client that has a build-inn knowing of the latest version.

Say you have created Update.exe and Update.dat which are given to your end-user(s). When this is run, manually or otherwise, it will run the "Client Script".

At some point you have the client script (via the TrueUpdate.GetServerFile command) get the files from one of the servers you have configured. This is basically the .ts1 file.

This .ts1 file contains the rest of the scripts which you then you to determine what version the end-user is running and what to do about it.

I expected that Trueupdate would look at the server to know the latest version.

So yes it does. In the TrueUpdate program the client only gets the "Client Script" while the server(s) store the "Server Script(s)" and the client needs to connect and download the "Server Script" each time it runs.

[Ted Sullivan]

Victor,

TrueUpdate 2.0 will work perfectly for what you want to do. The most common use of the software goes as follows:

1. The TrueUpdate client (installed on your user's computer) determines what version of your software is currently installed. This can be done using just about any method you can dream up, but it most often done by reading a registry key or read the file version resource information.

2. The TrueUpdate client connects to a TrueUpdate server to find out what the current release version of your software is. You can update this server file whenever you want and with whatever instructions you want.

3. If the TrueUpdate client determines that the installed software is out of date, it downloads the installer or patch file that will update the installed software to the most recent version.

That's the basic flow. The thing about TrueUpdate 2.0 though is that it can handle just about any situation you throw at it, whether simple or incredibly complex. It's certainly not a tool that you will outgrow.

[Victor Heijke]

Thanks for all the information.
I kept on working with the trial and I'm now stuck. Maybe anybody can help me out.

My setup writes 1.0 in the registry as version info. I installed it on a machine with TrueUpdate. Everything went perfect.
I changed the version info in this setup to 1.1 and uploaded it to our ftp server
I changed the server script to this targetversion of 1.1. and published it to the server
When I Run the updater it tells me that there is indeed a new version, but it doesn't download it. It uses the old 1.0 patch.
Even if I use a File.Delete on the patch folder, the old setup is comming up.

Any clues?

[Steven Carr]

What do you have as your "Server Script"?