You can create Components (for example Main Application, Documentation, Additional Companion Software 1, Additional Companion Software 2, ...), but as far as I know, you cannot provide a description of these components. That would be useful in many setups. It would be useful to tell the end-user what the component is used for, which often is not entirely obvious only by looking at its short name,

Add support to create projects with main iss file and additional files used by #include. I suggest that debug support for included files is very helpful and make debuggin easier than having a debug session on the preprocessed file and fixing in several other files with no navigation support from the preprocessed file to the other file. You are pretty lost in open editors in such a case (default usecase!).

[Run] Entries may not be valid if files are waiting to be copied; e.g. a database update program that has a shared file awaiting replacement on reboot. This entry should be skipped if the flag is provided and the install triggers a reboot. Unfortunately, all the run operations happen prior to the user being notified of the required reboot. This leads to installers that perform invalid operations with programs that are not up to date.

Hi all,
Right not logging the output of command run during install is not very nice, you would have to run the tool through cmd and manually redirect the output to a file. Maybe even have to manually check if log has been requested on install and redirect to nul if it hasn't.
All these makes it a little harder to maintain a install script (maybe you just forgot to put the whole command inside quotes, etc).

So, having a way to redirect command output to the main log file or to a custom log file, as an option for each command run or at installer level would be a great feature which will increase usability and productivity of the one making the install script.

Thanks,
florin

Files generated in the code section by extracting temporary files or just generate files at install should have the possibility to be added to the "known Files" list in unins.dat that the uninstaller can remove them in same manner as files from [File] section. Flaging with "Components" assignment (and other stored in record for files in unins.dat) should be provided by the function.

See discussion of this over the years:
http://news.jrsoftware.org/news/innosetup/msg23027.html
http://news.jrsoftware.org/news/innosetup/msg56090.html
http://news.jrsoftware.org/news/innosetup/msg62005.html
http://news.jrsoftware.org/news/innosetup/msg57194.html

We have a complex application, with numerous configuration files which are installed by the installation package. If the end-user modifies a configuration file, then we don't want it deleted at uninstall time, and don't want it overwritten by upgrades.

As far as I can tell, to implement this Inno Setup should do a hash of such files, and record it in the uninstall log. At uninstall time, check the file's hash, and don't delete the file if it's changed.