12 replies to this topic

[Ajawl]

I am trying to do a minor upgrade, but it fails when the update tries to overwrite the first file to be updated.

The first version was installed from my hard

[Ajawl]

(I sent my question befere end it, so I will describe again my problem.)
I am trying to do a minor upgrade, but it fails when the update tries to overwrite the first file to be updated.

The first version was installed from my hard disk.
Then I tried to install the second version (update) from the CD-ROM. This is a minor update, with the command line REINSTALL=ALL REINSTALLMODE=vomus.
When the update tries to overwrite the first file to be updated, it comes up an error:  "Default Installer Information: Please insert the disk: 1".
Then I have to cancel the setup.

When I copy the setup of the update from the CD-ROM to a temp directory in my hard disk, then the updates runs without any error.

This error happens just when I install the first version from the hard disk and then the update from the CD-ROM (or from the floppy disk).

When I run the first installation from a CD-ROM and then the update also from another CD-ROM, then this error does not happen.

Does anybody have any idea the reason of error? Any solution?
Thank you for any help.

Ajawl

[Craig Post]

Have you tried setting REINSTALLMODE to "omus"?  The "v" switch in REINSTALLMODE tells it to recache the source package on the local machine, but all you have on your cd is a .msp package, no msi.  It's possible that it's trying to recache the local image from your SourceDir(in this case, the CD), and it can't find any source image on the SourceDir so it prompts you for a CD, thus screwing up your install.  

Hope this helps.

[Ajawl]

Thank you for your help, but it does not work yet.
I set REINSTALLMODE=omus, but it came up the same error massage.
I am running the update from a .msi file, like a reinstallation. I am not running a patch (.msp file).

It seems that it is a bug from the InstallShield or the Windows Installer.

Thank you,
Ajawl

[Stefan Krueger]

The volume label of your CD must match the label of the original install media.
As a workaround copy the install to hard disk and run from there. In this case the volume label will be ignored.
You can do this by packaging your setup file with PFTW.

[Johannes John]

Hello,

it's a problem when installing form medias like CD with different volumelable.

I've a solution, created with a very hot needle ( perhaps only a german expression ). If wanted, I will tell it here.

Regards!
Johannes

[MichaelU]

Hello, Johannes!
How about your decision for described problem?
If you tell us about this, it will be useful for many installer developers in the world. Waiting for your reply.

MichaelU

[Johannes John]

Hello MichaelU,

yes, the principle way is:

1) Get the Volumelable of the current media
-> I do this by using the property CURRENTMEDIAVOLUMELABEL
-> I don't know who's creating this property and therefore I don't know, how long this property exists

2) write this lable to the registry before the current lable is compared with the saved value.
I'm doing this, in the Execute Sequence behind CostInitialize.

-> I don't know exactly when these values are compared
-> I don't know how long the value will be stored in the registry
-> I don't know how long the registry key I'm using is the correct key
HKLM\Software\Classes\Installer\Products\{transformed Productcode}\SourceList\Media
VolumeLabel={Current Value};1

If you need more information, let me know.

Regards!
Johannes

[MichaelU]

Hello again, Johannes!
Thanks a lot for your answer. Yes, I tried this approach some days ago (but one comment : this key is not only under HKLM, but under HKCR too on NT platforms, and under HKCU, HKU on 9x platforms). And my results : this approach works for OS with Windows Installer below then 2.x... On Windows XP, for example, (WI 2.0) this approach follow to not understandable results, unfortunately.
Why? I don't know now... Actually, Windows Installer is a "black box" for developer :-))) You feel it, I believe.
Some else about my problem with upgrade. My product can be installed from CD, from WEB and from network shares. I  perform some attempts with any WI versions and registry key corrections, but I have't a full good results (for all possible source locations)... If you want, I'll inform you when I decide this big problem.
Michael.

[Johannes John]

Hello Michael,

in the Aug 2001 SDK I've found two articles of interest:
- HKEY_CLASSES_ROOT Key
- Merged View of HKEY_CLASSES_ROOT

Two questions minimum remain:

In which case the Installer will write into HKCU?

Which function the Installer is using ( 1.x , 2.x ) - RegOpenUserClassesRoot or RegOpenKeyEx with HKCR or HKLM\Software\Classes?

I will do some tests on different OS and give a report here.

Regards!
Johannes

[Johannes John]

Hello Michael,

yes, with Installer 2.0 my solution isn't a solution.
Until now I couldn't find, where the Installer is saving the volume lable of the media to compare with the update media.
I couldn't find it in the registry nore in the cashed MSI file.

We need a new solution!!!!

Reagrds!
Johannes

P.S. I will put this question into the IS forums ISWI and Dev7

[MichaelU]

Hello, Johannes!
I think, that I found a way to resolve this problem by writing extension C++ function and call this function from custom action. I can send to you source codes if you want. Please, ask me via e-mail irishman@newmail.ru
Michael

[Johannes John]

Hello!

It seams to be, that I've found the solution! Examine please!

The MSI 1.x seams to check the Volume Label between first installation and the update from CD.
-> HKCR\installer\products\GUID\SourceList\Media\1=

MSI 2.0 doesn't seam to check the Volume Label anymore, but seams to check the value
-> HKCR\installer\products\GUID\SourceList\Media\MediaPackage=

Perhaps it has something todo with the MEDIAPACKAGEPATH.

If I change these two registry values to the current values direct after CostInitialize, the installer doesn't want to have the Volume 1.

Little bit dirty workaround, I know.
Regards!
Johannes