It looks like Wise and/or Windows Installer does not want to cooperate with my application's need to install 2 files and a directory to the root of the Current User profile. Boy do I hate ignorant application developers, putting their crap where it doesn't belong. Anyway, when Windows Installer goes through its paces, instead of installing files to the root of the current user profile, the files end up in the Windows directory.

Anyone know the trick, workaround or whatever to get the files in the right place (without resorting to a Custom Action)?
0 Comments   [ + ] Show Comments

Comments

Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Answers

0
What's the path you're using now to place these files?

I would THINK that placing files in Windows\Profiles would do the trick...
Answered 06/28/2005 by: sean_c_roberts
Senior Purple Belt

Please log in to comment
0
Yeah, I thunked that too... Stuff in there is ending up in \Windows with no errors produced, as if that's what's supposed to happen. Now I don't think that anymore.
Answered 06/28/2005 by: VikingLoki
Second Degree Brown Belt

Please log in to comment
0
strange.. mine too =)

good thing i dont have any apps with this kind of behaviuor but it pays to be ahead.. if you did get any fixes without using ca could you post too.. never know when any of us will be needing it =)
Answered 06/28/2005 by: rikx2
Purple Belt

Please log in to comment
0
My company uses Wise Studio 5.x and ran into the exact same issue a month ago. Here's the work-around:

Delivering Files/INIs to User Profile Root Directory (%USERPROFILE)

PROBLEM:
Wise provides the “ProfilesFolder” directory property, which is supposed to translate to “C:\Documents and Settings\<Username>\”. Unfortunately, in practice, anything you try to deliver here will end up in C:\Winnt.

SOLUTION:
Use %USERPROFILE (windows environment variable) as the directory property in your MSI tables. This will generate an ICE validation error (because this variable is not defined in the Directory table), but will not prevent the MSI from installing.
Examples:
INI Files Set the DirProperty value in IniFile table to %USERPROFILE (no brackets, no trailing %).
Files Set the Directory_ value in Component table (for file’s component) to %USERPROFILE (no brackets, no trailing %).
Answered 06/28/2005 by: norexx
Orange Belt

Please log in to comment
1
Does this Wise KB Article #1334 help?

Regards,
Rob.
Answered 06/29/2005 by: MSIPackager
Third Degree Black Belt

Please log in to comment
0
Yup. It does. Thanx!
Answered 06/29/2005 by: VikingLoki
Second Degree Brown Belt

Please log in to comment
0
Yes, but there's another problem.

It makes a directory in user's profile folder but only in the user's which is currently logged and runs the installation.
It does't make the same directory in other users' profile folders even if this is advertised application.

Maybe you know how to resolve this problem?

BR,
Jahro
Answered 07/12/2005 by: jahro
Senior Yellow Belt

Please log in to comment
0
The "currently logged on and runs installation" part is normal, but the self-repair should kick in for subsequent users. Did this pass validation? Sounds like the component that installs the user profile stuff has a per-machine (or otherwise invalid) keypath, which generates an ICE error. The component(s) that install user profile files should have a registry key in HKCU as its keypath. If your applicaiton doesn't have an HKCU registry key to use as a keypath, which is often the case in this situation, then you simply add dummy flag key(s) such as HKCU\Software\[ApplicationName] - UserProfilleFlag = 1. Once set as the keypath, if that registry key doesn't exist, the self-repair will kick in and install the registry key, and all files in the user profile. It is also a good idea to break out components like this into a separate, root level feature that contains all per-user components. That way the self repair will only address the missing per-user items and not run a self-repair of the entire application. It's not a requirement, but it does make the 1st run self-repair much faster.
Answered 07/12/2005 by: VikingLoki
Second Degree Brown Belt

Please log in to comment
0
I've spent a bit of time looking at this, if the component references a Directory Table entry ( which is user specific ) then the self-repair does not work. I believe it is due to Directory table not being re-evaluated when self-repair happens later down the track.

However if the component references a hard-coded directory property ( e.g h:\ ) then the self-repair will work.

Best bet, is to install files to Installdir and use a launch script to copy files to the user profile location.

Hope this helps.
Answered 08/18/2008 by: msaad
Senior Yellow Belt

Please log in to comment
0
You dont need launch scripts at all, in the component that has the current use files in add a reg key under the currentuser registry key, some temp folder under software. Make a dummy value in there, like the component guid, app guid, app name, doesnt matter what it is, but make a string value. Set this string value as the keypath, this should then initiate a self repair when the advertised shortcut is run on a user that didnt install the application as effectivly that keypath is missing.

P
Answered 08/18/2008 by: Inabus
Second Degree Green Belt

Please log in to comment
0
Did some further investigation into this. The reason why self-repair wasn't working for files to the Userprofile, was due to the msi. The Custom Action SetUserProfileNT ( Installshield specific ?? ) is in the InstallUISequence, when i moved it to InstallExecSequence before CostFinalise, this solved the problem.
Answered 08/19/2008 by: msaad
Senior Yellow Belt

Please log in to comment
Answer this question or Comment on this question for clarity