12 replies to this topic

[jpbrassard]

I can't figure this out. I've got a setup project that contains logic for both a first-time install and an upgrade install using Maintenance (this is version 2 of our software). I'm using the same Project GUID as the previous setup project.

In the OnBegin handler, I'm checking for registry entries that I made in the previous (v1) setup, and if they match what I expect, set a global BOOL value to TRUE and proceed to OnMaintUIBefore.

In OnMaintUIBefore, I simply flash an SdWelcome dialog, informing the user that this is an upgrade. If they don't click cancel, this code executes:

Code Sample

SetStatusWindow(0,""); Enable(STATUSEX); StatusUpdate(ON,100); ComponentUpdate("");

Then it reaches the end of the OnMaintUIBefore event, zips through OnMoving, and gets to OnMaintUIAfter - it never goes to the Component_Installing or Component_Installed events at all. None of the new files are copied to the machine.

I thought it might have been because the uninstall entries that InstallShield makes, both in the registry and in the Setup.ini in the InstallShield Installation Information directory, stored the old AppName (which has changed in v2 of our software to be a bit more generic). I wrote code to change these entries in OnBegin, but it didn't help.

I'm totally stumped. I'm no InstallShield expert, by any stretch, and it's only a small part of my job, but I've done upgrade setups using Maintenance mode before, and they've succeeded. I more or less copied the exact sequence of events (and much of the event code) from previous, interim-build upgrade setups I developed for v1.x of our software (all of which had worked). I've been trying to puzzle this out using InstallShield's docs, but that's not been entirely helpful, so I call out here. Anyone have any ideas (other than NOT doing upgrades through Maintenance mode - I'm not entirely comfortable with calling a silent uninstall through command line switches in InstallScript yet, and I don't think I've got the time to learn it).

Thanks in advance for any and all help,
Josh

[Taco Bell]

Hmm, I don't really like how you're doing this install, but despite that, let me ask you a very simple question to get us going.

Are you using the same components as 1.x or did you add new ones?

[jpbrassard]

Components are the same - there's only the one, called 'Program Files'. Copied the definitions for it from the original setup project - the only thing different about it are the new or updated files, and a couple of added directories to go under TARGETDIR. The associated FileGroups have been set to Always overwrite (which is slightly different than the original setup - only one of the FileGroups, the one that contained the actual Application executable and associated files and docs, was set to Always Overwrite). Include in Build is set to Yes.

In the interim, right now we've built a setup that, if it detects the previous installation, forces the user to uninstall it from the Control Panel before they can proceed with the upgrade and abort the setup from OnMaintUIBefore. This seems a kludge to me, but there's a time factor involved and that's the way the higher-ups want to do it for the time being. I'd still like to find a solution that reduces end-user interaction, and the curious part of me really wants to figure out just why the hell the setup won't work as an upgrade when I essentially copied the logic from previous (successful) Maintenace-mode upgrades.

Thanks for taking this on, TacoBell00 (even if you don't like the way I'm doing the install!   )

Josh

[Taco Bell]

What calls are you making in your OnMoving event?

[jpbrassard]

Just the default stuff:

Code Sample

szAppPath = MY_APP_PATH; RegDBSetItem(REGDB_APPPATH, szAppPath); RegDBSetItem(REGDB_APPPATH_DEFAULT,szAppPath ^ @PRODUCT_KEY);

I had added some misguided handling in the OnMoving event (where, if the global BOOL value was set to TRUE, I would call ComponentLoadTarget(MEDIA)), but it's been removed for a while and hasn't changed anything.

Thanks,
Josh

[Taco Bell]

I asked the wrong question.  What I really wanted to know is what calls you were making for ComponentTransferData?  Should be something like this:

Code Sample

nResult = ComponentReinstall();  nResult = ComponentTransferData(MEDIA);  HandleComponentError(nResult);

[jpbrassard]

I'm not making any explicit calls to ComponentTransferData, as I was under the assumption that, since I'm letting the OnMaintUIBefore event handle this, that ComponentTransferData is automatically called if there's a component selected. Am I wrong in this assumption? I can do an uninstall from OnMaintUIBefore just fine by calling ComponentRemoveAll without explicitly calling ComponentTransferData.

I had some code explicitly calling ComponentTransferData in there at one point, but it didn't seem to do anything. I wasn't capturing the result code and resolving any error messages, however.

ComponentTransferData shouldn't be called from OnMaintUIBefore, should it? Should be in OnMoving or some event like that, right?

Thanks,
Josh

[Taco Bell]

I don't use an event-based model, so it may not be necessary in that scenario.  To be honest, I'm not sure.

I use a program-driven model and do these ComponentReinstall calls at the very end of OnFirstUIBefore, after the user has re-confirmed his/her selections.  I also do ComponentRemoveAll in the uninstall context for Add/Remove Programs.  In both cases though, I _do_ explicilty call ComponentTransferData.

You didn't mention uninstalling earlier.  Does this work as expected?  In other words, are both the original v1 stuff as well as the new v2 stuff _ALL_ being removed?  Just curious given your approach.

[BobT]

I have had this happen to me twice.

How did you create the update project?  Normally to create the update project, I go into my original project and select save as.  This creates a project with a different GUID which I then change to the original project's GUID.  Doing it this way has always worked.

Recently, I created an update project by creating a new project.  Created the same components and file groups and changed the GUID to the one in the original project.  When I tested this, I found that it would not overwrite the files of the original project.  Went back to the method described above, and everything worked fine.

The other time this happened is when we accidently created new files that had a version number that was not higher than the old ones.  Had to change the file group property to overwrite by date rather than version.

Except for those two cases, update installs have always worked for me.

[Taco Bell]

Well he says, at the very beginning, "I'm using the same Project GUID as the previous setup project."

Switching GUIDs would certainly resolve this, but it sounded like I he wanted to avoid that at all costs.

[BobT]

Taco you missed what I was saying.  There are two ways to create the upgrade project.  Going to the original and doing a File -> Save As which creates a new project or simply creating a new project in the IDE.  I know the GUID must be the same as the original if it is going into Maintenance for the upgrade.  My upgrade programs always have the same GUID's as the original install.  The point is when I created a new project by selecting New, the new files did not overwrite the old.  When I did a File -> Save As form the original project, the new files were installed.  My question is how did he get the project.  He says he is using the same GUID, not the same project.

[Taco Bell]

Yes, in my haste I did miss that point.  Sorry.

However, there's a third way to create an upgrade project.  That is to simply make a copy of the project folder and rename the core project files.  This way your media and GUIDs stay intact.  No need to mess with either, unless of course you want to.

But yes, definitely trying to "match" the original project could cause problems.  Especially since he says that he "Copied the definitions for it from the original setup project."

Good question BobT and nice to have your here with us.

[Taco Bell]

Hmm, now that I think about it more, I have done one event-based setup before.

When I re-released it, I attempted to use the Maintenance mode functionality.  I initally used the same project and components, but in revising it I had changed the names of the file groups.  If I recall correctly, the new file groups were NOT being automatically taken into account.

I didn't want a new GUID either, so I did a kludge of my own.  I simply added coded to OnBegin & OnEnd which deleted the (old) uninstall information (i.e. C:\Program Files\InstallShield Installation Information\<ProjectGUID> and Add/Remove Program entry).  For those who had used the previous cut, it still came up in Maintenance Mode initially, couldn't help that, but if you cancelled out and re-ran the setup, it would come up as a being installed for the first time.  It was good enough for me at the time, so I just noted that behavior in the readme.  I also didn't need uninstall support since this was a patch and I could rely on a previous full install to clean things up.

Obviously this little experience didn't turn me over to the Maintenance mode dark side, so I'm still a program-based guy.