7 replies to this topic

[fredrik.strom]

Hi
I building an application that needs to have an directory for writing persistens settings files available for all users.

Historically we have used c:\program files\my application\appdata, but that does not work very vell in all situations.

So i have tried to deploy data into [CommonAppDataFolder]\my application but it does not work.

Since then i have tried to put files into:
[LocalAppDataFolder]\my application
[AppDataFolder]\my application


But the only folders that work are:
[ALLUSERSPROFILE]\my application

and

[INSTALLDIR]\my application

Anyone that know anything about this?


Regards F

[Glytzhkof]

This probably has to do with the value of the ALLUSERS property. You can find info on this in the SDK.

However, rather than deploying files to these locations via the MSI, it is generally much better to deploy user files to a per machine path such as [INSTALLDIR]\User Data\*.* and then have the application EXE copy the files down to the user profile (or alluser profile - but then you need to apply custom permissions with either the LockPermission table or using a tool such as subinacl.exe in a custom action).

The great benefit of the above is that you will be able to patch and update the user data in the per machine location and hence new users can get updated data. The application EXE file can also make "smart decisions" to force overwrite some files each time the application has been reinstalled while keeping other files.

The best way to detect that a new install has been run since last time the user installed is to use flags in HKLM and HKCU. Essentially the installer will increment a flag in HKLM, for example:

HKLM\Software\My Software\InstallCount = 2

Then for each user that launches the application the EXE file will compare this value to the corresponding HKCU value:

HKCU\Software\My Software\InstallCount = 1

If HKLM is higher than the HKCU value, then there has been a reinstall of the application since last time the user launched the app, and the application EXE knows to copy new files (if any) to the user profile.

Once data is in the user profile it is generally considered user data, and should not be uninstalled (unless this is required). Hence there is no reason to clean out files from all profiles.

You should favor the non-roaming %USERPROFILE%\Local Settings\Application Data over the roaming %USERPROFILE%\Application Data for depkloyment. This is because login times for the user will be extremely long if there is lots of data in the roaming profile. In general you put resource file in the non-roaming section, and settings files such as CUSTOM.DIC (dictionaries) in the roaming section (since in the latter case you want to change the file and always have it available).

[fredrik.strom]

Hi thx for the answer. :-)

The solution you suggest is actually the probable behavior of the application.

It it not likely that the MSI will put some files in the directory, but rather create the directory and set the permissions on the folder so that both users and admins can run the application without any permission conflicts on the files created by the application.

I installed the my test msi on a system where the
c:\documents and settings\all users\application data and c:\documents and settings\logged in user\application data folder existed and then the
[CommonAppDataFolder]\my application and [AppDataFolder]\my application, actually worked.
Seems like a bug to me that that the Application Data folder need to exist for the destination [CommonAppDataFolder] to work.
Im going to report it to Macrovision and see what they say.

I really appriciate you answers and that you take time to answer a noob like me :-). Im going to look into both the LockTable and the use of custom actions to solve the problem.

Thx again.

Regards F

Edited by fredrik.strom, 07 January 2007 - 13:32.

[fredrik.strom]

Hmm, im an idiot.

Application Data is a hidden folder and since i didnt have "show hidden files and folders" check, i didn't see the folder. It worked all the time...

Sorry for wasting your time.

I still need to use your tips for the permission on the folders thought :-)

Regards F

[fredrik.strom]

When using a custom action to set the permission, when in the sequence is it a good ide to execute it?

Regards F

[Glytzhkof]

I would use the CreateFolder table if you need to create an empty folder. If you add the folder via an empty component you could run into "cyclic MSI self repair". This is because MSI is designed to remove empty directories, and since empty components use the parent directory as key path there would be an endless MSI civil war with removal and re-addition of the component.

Schedule your custom action as a deferred execution, system context, synchronous, ignore exit code action towards the end of the InstallExecutet sequence (right before InstallFinalize is always a good choice).

[Glytzhkof]

Also: add subinacl.exe to the binary table and call it from there. Not sure what the option for this is called again, but something like "...execute program from installation".

[fredrik.strom]

Is it possible to use the locktable to set recursive rights on folders?


Regards F