OnMoved called twice - why??

[brianthegood]

I have an Installscript program with 4 components.

I get the status screen (with the progress bar) showing the files being installed.

Then, for some unknown reason, a new status page is put up where it hangs with one bar displayed for 10 - 15 seconds.

A log file I've created says that the OnMoved event is called a second time, but no files are moved on the second call.
I do not know which routine called the second OnMoved event.

What is the installer doing? No DLLs are being registered.

This seems to be tied to Vista.

Any ideas?

[MGarrett]

Is your InstallScript manually calling OnMoved?
This event is called automatically after FeatureTransferData finishes, so you should not call it in your script.

[brianthegood]

Thanks for the quick response!

I do not explicitly call OnMoved.

If FeatureMoveData calls it the first time, what is happening after FeatureMoveData that would call OnMoved a second time?

[MGarrett]

Hmm...
If your script doesn't do multiple calls to FeatureTransferData() or FeatureMoveData() after the file transfer completes, then I'm not really sure why OnMoved would be called twice.
However, are you sure that OnMoved is the cause of your progress bar?

Something could be calling SetStatusWindow after the first progress bar is done. Are you doing any CopyFile() or XCopyFile() operations after the file transfer?

I was once handed a Merge Module that would throw up its own empty progress dialog, even though it was supposed to install silently. Are you using any Prerequisites, InstallShield Objects, or Merge Modules? Are you installing any other program (LaunchApp) that might be throwing a progress dialog? Are you kicking off any uninstalls? I'm just brainstorming here.

[brianthegood]

The only thing that I'm doing is calling a few different LaunchApps but without delays. Also these occur after the second OnMoved appears in the log file.

But I think you characterized the problem perfectly when you said I get a second 'empty' progress dialog.

I need to find out what Installscript is doing prior to the second OnMoved call. If there was a way of tracing the calls to and from the functions, that would shed somemore light.

Thanks for the thoughts...

[MGarrett]

I need to find out what Installscript is doing prior to the second OnMoved call. If there was a way of tracing the calls to and from the functions, that would shed somemore light.

You could always do a debug install. That way, you could step through the installation script line-by-line, and see specifically what code generates the second call to OnMoved, and the extra dialog.
Good Luck!

[brianthegood]

My problem in debugging this, is that the development environment (Installshield 2008) resides on Windows Server 2003 and the problem exists on installations on Vista platforms.

Can I remotely debug? I've never done that before.

B

[Happy_Days]

I believe you need to have the InstallShield installed on the machine where you want to debug the InstallScript code. To debug, run the setup.exe with /d option.

[MGarrett]

Actually, you can remote debug.
In InstallShield 2008, go to the help topic "Debugging an Installation on Any Computer".
It involves copying a few files, including the project files to the other machine. It's really pretty simple if you follow the steps in the help topic.

[brianthegood]

So I got the debugger to work on the remote machine.
But I can't 'break' after the Return 0 from the OnFirstUIBefore. It's off in the ether somewhere until it drops to the second OnMoved.

Is there a stack I can consult?
Where is the installer going after OnFirstUIBefore and before the second OnMoved?

FYI- Heed the advice from TheTraveler (third one down)
The folder arrangement on the remote machine must be identical to the original folder inorder for the debugger to pick up the .dbg file

http://community.installshield.com/showthread.php?t=180719&highlight=isdbg.exe

B

[MGarrett]

If I remember correctly, after OnFirstUIBefore(), it goes to
OnMoving()
and then the files are actually transfered. If you have any custom feature installing events (in FeatureEvents.rul) such as OnInstalling() or OnInstalled(), they are run here.
After the file transfer and custom feature handling, the OnMoved() event is run.

Don't quote me on this, I'm just pulling from memory. 😛

[brianthegood]

I checked my log file under XP and it appears that OnMoved is called twice there as well.

So truly the difference is the time it takes Vista to get to the second OnMoved which is about 5-7 seconds.

What that pig-on-stilts is doing, who the hell knows.

Thanks Vista!

[peterbi]

Hi,

I am new to InstallScript MSI - I have done Basic MSI for some time.

Now I am working on a InstallScript MSI project to convert from DevStudio9 to InstallShield 2008 and make it compliable with Vista 😞

Of course you can imagine how many problems I can run into (already some). The current one is that my project throwed out error after calling OnMoving() (by looking at log file). The dialog is stating that "You must have local administrative privileges to install THE_PRODUCT. Setup will now exit.", then with 'Feature transfer error' dialog:"Error -1603 Fatal error during installation. Consult Windowsw Installer Help (Msi.chm) or MSDN for more information."

My first guess is that it's from UAC, but I have replied (allowed) once with the same logon. The second reason may be that we are installing files to 'program files' folder, since I read somewhere that Vista doesn't like or allow files other than dll/exe (we are pouring all our files to there, including help/data/config files).

The real problem for me is that I don't know where I can look at FeatureTransferData() - I searched the existing script files and there is no call to it, but my good guess is that after OnFirstUIBefore(), it will transfer the files of the features, but how can I know which feature/component/file caused the error? I do find that some destination folders have permission to 'Everyone', some others don't. Maybe I need to make all of them permitable to 'Everyone' on Vista?

If you have any suggestions on debugging InstallScript MSI project, I will very appreciate.


Thanks in advance,
Peter

[joshstechnij]

It should be possible to install files/folders to the Program Files folder on Vista. The only requirement for doing so is you must be running with elevated privileges.

If you are seeing an error indicating administrative privileges are needed, this would seem to indicate the installation process is not running with elevated privileges. Can you verify what the Required Execution Level setting is set to on the Setup.exe tab in the Releases view for the release you are building?

[peterbi]

Hi Josh,

Thank you again for answering my troublesome questions from both of the projects I am working (struglling) on:rolleyes:

I put a SQL Server 2005 Express SP2 in this project (InstallScript MSI with IS2008) as a prerequisite, if I set "Required Execution Level" as "Invoker", the SQL 2005 install failed immediately before any log can be created.

But if I set it to "Administrator", then I ran into problem to launch the setup.exe from a mapped drive (I have been using mapped drive from testing system to dev system for quite a while). Do you know how to overcome this problem?


Thanks,
Peter

[MGarrett]

peterbi,
I'm guessing that your local administrator account does not have permissions to access the network drive. After clicking on setup.exe, Vista will open a dialog to elevate you to admin, but the local admin does not have access and cannot continue the setup.

Make sure that the local admin has full permissions on the network share and files, or use a domain account with local admin permissions.

[brianthegood]

The delay that is experienced on Vista (and to a lesser extent on XP and 2003) is the call to CreateInstallationInfo() in the OnMoveData routine. I only found this when I included the OnMoveData routine and ran in debug mode.

Now I put up appropriate messages as to when this routine is called (Installation, maintenance or update mode). It is called in all three modes.

Installscript never fails to amaze me with all it's back alleys and curves.