why use inifile table
Hi all,
As per our standards we have to place ini file in inifile table, it works fine no problem , the application works fine if it is in program files\application folder also
any information why we have to use inifile table
As per our standards we have to place ini file in inifile table, it works fine no problem , the application works fine if it is in program files\application folder also
any information why we have to use inifile table
0 Comments
[ + ] Show comments
Answers (4)
Please log in to answer
Posted by:
nheim
17 years ago
Posted by:
spartacus
17 years ago
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
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
Posted by:
turbokitty
17 years ago
Posted by:
spartacus
17 years ago
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
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
so that the conversation will remain readable.