9 replies to this topic

[aldebarande]

Hi,

I'm working on a Basic MSI project written with InstallShield premier edition SP2.

Despite the fact I've read the docs and made numerous tests, I need some serious expanations about the property ALLUSERS.

When I began to work on the project I found the property set in "Property Manager" and the build warning is clearly not recommend that.

The project is not using currently the CustomerInformation dialog. However I just did a test using that dialog and whatever I do in that project ALLUSERS is always set to 1

According to the table shown in the help for this property the application cannot be installed by a non admin user with ALLUSERS = 1 Precisely I'd like this app to be install by non admin users. At least I'd like to be able to change the value of this property to get a chance to try differents configurations

- So if the ALLUSERS property cannot be set in Property Manager where am I suppose to define it ?

- CustomerInformation dialog can do that, ok but why the ALLUSERS value did not change while I was using this dialog ?

- And for projects that do not use this dialog where ALLUSERS should be defined ?

- In another dialog ? Ok but why when I run my application with a non admin user I have the message at the very beginning explaining admin rights are needed ?
It it due to ALLUSERS or to some others components that needs admin rights to be installed ?

- In a custom action ? I tried was still equal to 1 ...

I'm a bit confused

Thanks in advance for your clarifications.

[aldebarande]

Ok, I found the place where a condition is set to permit only user with admin rights. It's in "Product Properties".

But even without this condition ALLUSERS stay to 1 when I test it in one of the first dialog.
A simple user can install but is stopped by an "admin needed" error message later.

So why ALLUSERS is keeping value 1 ?
Even if I set ALLUSERS in "property manager" to 2, it stay to 1

Is it because the installer find some components com objects or other stuff that allways needs admin rights so that the installer change the ALLUSERS value to 1 ?

This value to 1 is an issue for me. If the app cannot be installed for non admin, ok no problem, but I need to make some per user install.

Please help.

Edited by aldebarande, 24 October 2007 - 10:11.

[Stefan Krueger]

For a per-user install you just don't set ALLUSERS at all. If it's undefined, the install will be per-user.
I don't know why your ALLUSERS keeps to be 1. Go to direct editior and perfom a full text search for ALLUSERS to see if it might be set somewhere.

[aldebarande]

Hi,

Thanks for your reply.

I already made a search in direct editor, only the unused CustomerInformation dialogs was having ALLUSERS entry.

Could we please redefine per-user and per-machine ?
(all these test makes me a bit confused)

- Is it only a matter of choosing the place where configuration and personal files that may results of the application use are ?

- Or is it possible to install an application only for a user: i.e. another user will not see at all this application. And one user is able to uninstall it without uninstall for the other user ?

Currently all users (with admin rights) are able to use the app and all "AppData" files are in "documents & settings / <username>

The test I make to see ALLUSERS value is a simple test in setup.rul script called in a dialog. It's like:

if (ALLUSERS = 1) then
MessageBox("ALLUSERS = 1", INFORMATION);

I've made a test with the CustomerInformation dialog implemented between InstallWelcom and setupType and whatever radio button I check, the app's data files are allways in "documents & settings / <username> so according the doc ALLUSERS is not set.

Thanks,

Edited by aldebarande, 24 October 2007 - 16:44.

[Stefan Krueger]

In a per-user install:
- Shortcuts are created in the user's start menu only (instead of the all users start menu)
- some registry entries might go to HKCU instead of HKLM
- Only this user sees the product listed in Add/Remove Programs control panel
- other users can install and uninstall the product independently

However: the files exist, and thus can be seen by any user (if they have read access to the install dir), and the might be able to use the application by double clikcing the exe file.

Please generate a verbose MSI log (see http://www.msifaq.com/a/1022.htm) to see the real value of ALLUSERS. If you are using MSI 3 or above it will even log changes to the property.

If you are using InstallScript in your project, that might have an impact on the value of ALLUSERS.

The user running the install still needs write access to the INSTALLDIR. This typically means he has to be administrator. Therefore, per-user installs are often not useful.

[aldebarande]

[aldebarande]

Hi Stefan,

A very last question.

When user A and B have installed the app.
Let's say user B uninstall

When user A look in his program files he cannot see the app's folder but he can use it anyway because when he wants to use it there's some kind of install that goes on and the folder app comes back.

This behavior is working with .MSI not with .EXE.
Do you confirm it's normal behavior ?

Do you think that testing ALLUSERS to put INSTALLDIR in user's personal folder can solve that issue so that even .EXE will work with per-user ?

Thanks,

[Stefan Krueger]

Okay, these are many questions

In case B it is normal that ALLUSERS switches vom 2 to 1.

In case A where ALLUSERS isn't set, both users should be able to install and uninstall without affecting each other. Windows installer keeps reference about the usage of files, and they should not be removed if another user still needs them. So there seems to be something wrong.

[aldebarande]

Hi,

Now I got my project to be a per-machine install.

When you look at the doc about ALLUSERS property you can see that if this property has 1 or 2 as value the doc says it should use AllUsers folders ...

But it's using personal folder "documents & settings /<userName>/..."
instead of allusers folder.

Main app files are installed in Program Files as wanted

Why ?

[Stefan Krueger]

Maybe you should use the CommonAppDataFolder instead?