Wise Installer Studio 7 target directory question

You need to look into the detailed log file of the installation, and into the table Directories.

I don't think however that installing into C:\AppName is good idea. If the users are not admins, maybe better idea is to make the installation per-user, so it will be installed into user's local storage. You can be fairly certain that C:\AppName will backfire sooner or later.

Vista and Win7 presents even worse problems when installing to Program Files. We make sure our users are logged into the machine as Administrator and then install from there.

If you install it in program files, what is the problem you came across? Write Access?

In program files, because it is a database application, if UAC is ON, the database gets moved, along with the INI file, which messes up reporting and backups.

You should not install to the root of C: - in the long run you will have more problems than it is worth.

I would advise you go back to using C:\Program Files.

If you need to have compatibility with XP and Vista / Windows 7 and you are willing to re-write your software to be compliant - then use %APPDATA% to store your database and INI file.

If you are willing to re-write your software for just Vista and later, then use %ProgramData% for the database and ini file.

If you cannot re-write your software to comply with program data storage, then you should use Windows Installer's LockPermissions table to loosen permissions on the specific files (not the directory).

You may also use MsiLockPermissionsEx if you either: a) currently do not use LockPermissions for XP (delete it if it is in your project as both cannot be in the same .MSI) or b) will have a separate .MSI for Vista.

A good tutorial on and helper utility for MsiLockPermissions is here: http://csi-windows.com/toolkit/csigetsddlfromobject

I hope this response get's you on your way andr is helpful enough for you to mark it as the answer!

The philosophy in Vista and 7 is that someone who installs the software for all the users, i.e. installs in Program Files, must be local administrator - which does make sense. But non-admin users can also install software per-user, in which case it's installed under user's own hive and is not available to other users.

Correct. However, anything that is installed in Program Files MUST have the user account control turned off, otherwise any files that are changed in the install folder are replicated in the user's nest, resulting in a major headache if the resulting database is shared on the network.

We've switched away from Wise, to InstallShield, and have build new installers accordingly.

Maybe "install from source" might be the answer as well.

Anyways, returning to the original problem of Installer's repair of %programfiles%\appname , you have not posted the log we asked for. But even without the log, almost certainly there's some component within the installation that has %programfiles%\appname as its directory. You need to find it and take care of it. Also see our article "How to fix Windows Installer Efforts to Self-Repair"

the link to article is
http:A_3507-How-to-fix-Windows-Installer-Efforts-to-Self-Repair.html

The best approach is to change the application to store it's data one of the many advisable places that are excluded from UAC Virtualization.

If that cannot be worked out, there are several ways to turn off UAC Virtualization ONLY (Not all of UAC) for ONLY your specific application.  Most notably an external or internal .manifest file that specifies "asInvoker" for the "requestedExecution" level.

You would have to open up rights to the SPECIFIC files in the Program Files folder - if you open up the entire folder you are risking your EXEs being hacked by malware.

By installing to the root of C:\ you are moving in the direction of making your software even less compatible with the Windows platform.  If you service sizable corporate clients you'll get a lot of push back on installing to the root of C:\

Is there a reason the application cannot be made to retrieve one of the special folder values for %APPDATA% or %LOCALAPPDATA% (could also provide a button in the app to open this location so they can easily copy it)?

> By installing to the root of C:\ you are moving in the direction of making your software even less compatible with the Windows platform.  If you service sizable corporate clients you'll get a lot of push back on installing to the root of C:\

I concur. From my own experience, I did see a couple of packages where the vendors have moved in exactly this direction, and this step appeared to be on par with, shall we say, general coding quality of their software product. So this issue kind of became a litmus test, and you don't want it to be positive.

If this means that the author brought in a consultant in order to implement experts' suggestions, then certainly those suggestions have to be accepted.

If experts' suggestions were wrong, then some explanation is needed, not necessarily all details, but some idea about what was done instead (which then should be accepted as the solution) , or at least why we were wrong (delete).

Ohterwise, split between http:#35028413 and http:#3502841

I've requested that this question be deleted for the following reason:

The solution was too involved to detail here, as I needed to bring in a consultant to fix the problem.

(not sure if I clicked "submit" or"object" above - should be the latter)

correction:

"Ohterwise, split between http:#35028413 and http:#35023802"