Software Deployment

Hi raka,
because you can control the settings in the ini-file this way. But if you have a static ini-file, you can put it into the file table like all others.
Regards, Nick

As you have discovered, both methods will work just fine, however (as I see it) there are some pros and cons to either method.

Inifile Method----------------

Pros: If you have settings in the INI file which you may wish to vary at install time through the use of Global Properties on the command line, then this method is well suited.

If the INI file contains any settings that may vary depending on the target Operating System (e.g. path to Windows folder on NT4 compared to XP) then you can reference either directory properties or system environment variables in the INI file table making the package suitable for multiple OS deployment.

Cons: In a locked down environment, you may wish to apply permissions to the inifile to allow non-privileged users write access. This is harder to achieve using the inifile method as you would need to either apply permissions to the containing folder or write a custom action to do this.

"Flat file" method

Pros : Useful for those INI files whose contents do not need to vary at Install Time (or with different target OS's) and so the use of properties to influence the eventual contents is not required.

Easier to apply permissions to because these can be applied on the individual INI files via the LockPermissions table.

Cons : Less suited to those INI files whose contents might need to vary at install time and consequently where Global Properties might be used to influence the contents.

Personally I favor the INI File table method for the flexibility it affords with the one caveat that setting file permissions is made slightly more complicated.


Regards,

Spartacus

The way I see it, you should always use the ini file table. It gives you way more control.

I don't really agree with the file permission negative because you shouldn't be using the file permission table anyway! ;)

I don't really agree with the file permission negative because you shouldn't be using the file permission table anyway! ;)

Is this a cue for a "Why use the LockPermissions table" base note perhaps .... [;)]

But seriously, the LockPermissions table is not one of the stronger parts of Windows Installer technology, granted. However, in my experience many corporates insist (in their packaging standards) that the LockPermissions table is the only method which may be used to set permissions, which was what really prompted my comment in this regard.

Regards,

Spartacus