Wise Installer Studio 7 target directory question

I have Wise Installer Studio 7. My project, for years, displayed the target directory as C:\Program Files\AppName. We need to move it out of there to accommodate Vista and Windows 7. It is easy enough to create a new target folder and get all the required files in there, and the setup compiles nicely, and also installs perfectly, creating the new C:\AppName folder. So far so good.

However, when we launch the app, you can see the Windows Installer fire up, 'configuring the application,' and it creates the old C:\Program Files\AppName folder, putting the former files back in there. The app runs from the C:\AppName location, but it is disturbing to see that old folder created.

What have we missed in moving the target directory?
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Vadim RappCommented:
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.
BlueCrystalManAuthor Commented:
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.
Rory de LeurConsultant End-User ComputingCommented:
If you install it in program files, what is the problem you came across? Write Access?
Bootstrap 4: Exploring New Features

Learn how to use and navigate the new features included in Bootstrap 4, the most popular HTML, CSS, and JavaScript framework for developing responsive, mobile-first websites.

BlueCrystalManAuthor Commented:
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!
Vadim RappCommented:
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.
BlueCrystalManAuthor Commented:
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.
Vadim RappCommented:
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"
Vadim RappCommented:

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)?
Vadim RappCommented:
> 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.
Vadim RappCommented:
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
BlueCrystalManAuthor Commented:
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.
Vadim RappCommented:
(not sure if I clicked "submit" or"object" above - should be the latter)
Vadim RappCommented:

"Ohterwise, split between http:#35028413 and http:#35023802"
BlueCrystalManAuthor Commented:
The answer is was in the tables section of Wise Installer... A couple of the tables were showing the wrong value for INSTALLDIR. I do not know which one it was, as the consultant changed several entries in a few different areas.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.