Software Deployment

Does this Wise KB Article #1334 help?

Regards,
Rob.

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...

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.

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 =)

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 %).

Yup. It does. Thanx!

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

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.

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.

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

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.