Updates showing everyday

[emcknight]

So I have an update that is available and when I download and install that update, the next time I check for updates, there it is again. Any ideas why this would be?

[Brad_Peterson]

My first guess is that you installed the update correctly, but in your Update Service, you don't have the right versions checked for that update.

For example, when you publish an Update in Update Service, there is a step (step 6 or 7 I think) where it asks what versions this update should be applied to. My guess is you checked to update the newest version of your product with that update Or in other words, lets say you have two versions of your product, version 1.00 and 1.01. You released an update to take it to 1.01. So while publishing that update in Update Service, it asks you to check which version the 1.01 update should be applied to. And my guess is, that you checked both 1.00 and 1.01. But of course, that shouldn't be. Only the 1.00 should be checked. You don't want to update the 1.01 version to the 1.01 version again 🙂

My second guess, is that your update did not correctly update your products version number. So, lets say you *thought* you updated from 1.00 to 1.01, but really, your computer still thinks its the 1.00 version. You can see the products version number by clicking on start->InstallShield->Update Service->Test Utility. In here, find your product, and see what it says. If it's not what you thought it should be, that means something didn't increment your version number in your last update.

[emcknight]

I think it was your first guess, the fact that I have version 1.0 on the server available and the new version is still 1.0. So how can I force the version to include the build number, 1.0.504 for instance? That way I can link to a specific build and not have to increment my minor version number until I have a version that actually warrants a new minor number. I looked through the documentation, but it wasn't very clear. Thanks.

[Brad_Peterson]

emcknight wrote:
So how can I force the version to include the build number, 1.0.504 for instance? That way I can link to a specific build and not have to increment my minor version number until I have a version that actually warrants a new minor number. I looked through the documentation, but it wasn't very clear. Thanks.

Yes, the documentation is pretty unfriendly. It describes what they provide in a technical sense, but not in an examples sense. I really wish they'd write up details of a few examples of the update process from start to finish. Otherwise, we have to take a week or more to just figure it all out ourselves. Fortunately, the forums are starting to fill the gap of providing actual examples and actual problems faced in those examples. If only many of the questions asked get answered....

First, how do you update your product. Do you create an MSI patch (my InstallShield Express calls it a QuickPatch). If so, you can update the version number in that process. Also, there may be another way to update your version number, but I don't know of any off hand.

If you are just trying to update files using conditions, then...hmm...it should be possible, you just have to make sure your appropriately check the file version number or date or whatever and update only what you need to.

Finally, there are a lot of technicalities you MUST be aware of when working with the major.minor.build.revision numbering system. I know using a major.minor format is pretty much problem free. But some things ignore the build number (I think some InstallShield products do thatt). And some other things ignore the revision number (I think MSI patches do that).
You should definitely study this issue and see if your build number is fully supported by what you are trying to do. Also, check the actual version number of your programs main exe. You may think you put in it in major.minor.build format, but some programs (like Visual Basic 6) display what you'd think is the build number and places it in the revision field. So a version 1.0.504 in Visual Basic is really 1.0.0.504 in the compiled .exe.

As for us, we used to use the major.minor.build format, but I didn't want to waste a day researching the issue fully, so we just went to a major.minor system, and ignored build and revision numbers completely.