Using Update Service with IS Pro 7?

[slezberg]

I am trying to use the Update Service with a new IS 7 Professional setup.exe and for some reason it is registering it as a version 1.00 even though I have changed the version property to 1.00.145.

Do I still need to add these lines:

set oObject = GetObject( "New Update Service 1" );
oObject.ProductCode = PRODUCT_GUID;
oObject.ProductVersion = "1.2";
oObject.ScheduleInterval = 30; // this line is optional

even though I have enabled Update Service from Project-->Settings-->Update tab?

Thanks

Scott

[CChong]

I'm running into the exact same problem. It appears as if Update Services is only looking at or able to look at the Major and Minor parts of the version number, and ignoring the rest.

Maybe that's how it's supposed to work?

The documentation (and real world usage) seems to suggest otherwise.

I'm using the Evaluation Version of Professional 7.0, and not sure it matters but I'm creating the installer for a VB6 application.

[Chris_Woerner]

I will try to answer both questions in one post....


1. If you are moving from a Pro6.x project into Pro7 > you need to remove the script that was in your Pro6.x project in the OnBegin, remove the object from your project and enable the Update Service in the project setting. More details on this are in the Pro7 help topic titled: "Use the InstallShield Update Service with my product"

2. Your script must have code like the following. This code is in the default code supplied by InstallShield Professional versions 7.0 and later. If you are migrating a 6.x project, you need to add it.

Also, if you want to specify the full version string (instead of just using major.minor), modify this code in your project. It will tell the Update Service to use the version string you enter here instead of just reading the major.minor from the project settings.

In OnMoveData:

/* If this is not an uninstallation and the Update Service is enabled ... */
if( !REMOVEALLMODE && (ENABLED_ISERVICES & SERVICE_ISUPDATE) ) then

/* Register prod - use major.minor from project settings */
UpdateServiceRegisterProduct( "", "", TRUE, 30 );

/* OR use the following to use the a full version string */
/* Register prod - using custom string */
UpdateServiceRegisterProduct( "", "01.02.1234", TRUE, 30 );


/* Enable this if you want to create a "Check For Updates" shortcut. */
//UpdateServiceCreateShortcut( "", "", "" );
endif;

[Chris_Woerner]

We have had much confusion related to product versions and the Update Service. We tried to do two things:

1. Provide a good default behavior. The Update Service will read the major.minor portions of the version string from the project settings.

2. Provide a way to override this behavior. You can set a different version in the script (or MSI property in Developer).

Is this confusing? Any suggestions for making this easier? Should we allow a setting to use full version string from the project settings?

[CChong]

Thanks for the information, very helpful.

I think the confusion for me stems from the help documentation.

In Help, I found this: "Specify a version number for your product update in the Project Settings property sheet's Application page. (By default, InstallShield Professional 7 uses version numbers in the format major.minor.build, with major and minor between 0 and 255, and build between 0 and 65535; for example, 1.2.3 or 255.255.65535. This format is assumed in the default script code for registering the version number of the product that is being installed, and for comparing that version number to that of the already installed product during an update setup. "

Unless I'm misreading this, it doesn't appear to be accurate. The default behavior is what you described (major.minor), which is the opposite of what this Help indicates. So when I attempted to include the 'Build' portion and Update Services couldn't find the product version, it appeared to be broken or that I was doing something wrong.

Perhaps the ability to choose how the version number gets read would be a good idea. Better documentation might have cleared it up prior to or without requiring that though.

In the end, I've decided to go with the product's current default behavior and stick to major.minor. We are in development mode for our product right now so the 'build' portion seemed important. But after some thought, it became apparent that from the customer/user view point, it's less confusing and easier to maintain things simply utilizing major.minor.

Thanks again for the response,

Chris

[slezberg]

I agree...I think the documentation is confusing. I had assumed by reading that that it would take the ProductVersion property from the Project Settings everytime. I think it should take that property by default in IS 7 and then if you need to override it in script you can. That would make the most logical sense to me.

Does that mean I could change the IS 7 default script to include the @PRODUCTVERSION property so I only need to change it in one place?

Thanks

Scott

[CChong]

I’m testing also ISPRO 7. In this new version it’s possible to use a Multi-Instance Setup. But you can’t use the Update Service in combination with the Multi-Instance?! What I see is that when you use the multi-instance setup it creates for each new copy a new GUID. But I assume that you can still use the PRODUCT_GUID for the InstallShield Update Service ? So when you install a new copy of the Setup it makes a PRODUCT_GUID.ini file and no a INSTANCE_GUID.ini for the Update Service ?

Does anyone already tried this ?