6 replies to this topic

[CSalter]

Hi, all.

Working in ISD 7.02, I'm running into a problem.  We need to be able to select either per-user or per-machine install; per-machine works fine, but per-user installs are visible to the other users as well, except that the other users can't use program.  If another user tries to install, it comes up with an error "1605" (I think).  I've checked, and ALLUSERS is being set to an empty string, and it's installing the programs shortcut in the user's programs menu under start, rather than the common menu.

Thinking that it might be some custom script that's causing the problem, we tried again with an absolutely minimal brand-new Standard install project, with the same error.  However, if we build a Basic MSI project, everything works as it's supposed to.  If we then convert it to a standard project but make no other changes, it sometimes stops working.  (We tried it a couple times.)

Does anyone have any idea as to why this might happen?  We've been bashing our heads against it for a couple days, and nothing seems to help.  I'm sure it'll turn out to be something stupid, but at this point I've spent 2 days on it and I can't see what the problem is.

Development is taking place on a WinNT4 SP6 box.  The install was tested on several different WinNT4 SP6 boxes and on a Win2k Server box with the exact same results.

Any help would be greatly appreciated.  Thanks!

[CSalter]

Here's the full error message, in case it helps.

"Error: -1605.  This action is only valid for products that are currently installed."

[Stefan Krueger]

Since you're doing a per-user install, it is the expected result that the application won't work for other users.
But other users also shouldn't see the shortcut. Is that your problem, that other users see a shortcut they shouldn't see?

[CSalter]

Thanks for the reply!

The problem is that the program shows up in Add/Remove Programs for other users.  Whether they use the Add/Remove Programs or go straight to the Setup.exe, they're given the option to remove the program, even though they never installed it.  If they do try to remove it, they get a 1605 error.

At the same time, the shortcut in the Start menu was added to the user's own Start menu.  It's definitely doing part of the install as per-user, but for some reasons when other users try to use the same install it detects the other user's installation and gives the problem I've described.

We get this problem even on a brand-new Standard project that makes no changes to any registry settings or ini files, adds no shortcuts or file types, and only adds a single file.  Doing an identical Basic project, everything works fine.

Does this make more sense?  It seems like an absurd problem, but we've had three people working on it and we can't figure out what's going on.  Any help would be appreciated!

--
Chris Salter
Educom TS Inc.
www.educomts.com

[Stefan Krueger]

I believe in a Standard project ISD creates it own (additional) uninstall registry entries, and it may not do this properly (i.e. in the wrong part of the registry so other users see it). Don't know from the top of my head in which event handler this is done (guess shortly after file copy) and how to correct it. Did you step through the setup with the debugger?

[CSalter]

It looks like something in the RegisterProduct action is malfunctioning; at least, if I turn that off, the per-user install seems to work wonderfully.  On the other hand, it's now impossible to uninstall the product or re-run the install to modify the existing information... *sigh*  

Thanks for the tip!  If I get any closer to the solution, I'll post what's going on, in case anyone else runs into the same problem.

--Chris Salter

[CSalter]

I've finally (after a month!) received word back from InstallShield that this faulty behaviour is a bug in InstallShield Developer.  They're looking into the problem.