Tweet
Hi there,
I'm using Setup Factory currently in a project that spans 10.000 files and about 6GB. I'm fairly new to it and found it to be powerful, yet limited and sometimes even buggy. The following is based on my experience. I haven't read through all the suggestion section, so excuse me if I'm requesting something others have already asked for. Just take it as another vote for that feature. Also take it easy on me, if that feature already exists and I just overlooked it
- Simulation mode for the installation script. The build process takes about 2 hours on my system. Compressing files over and over again in each run is highly inefficient. It would be great if there was a way to simulate the installation without any file movement. Alternatively, there could be an option to allow building the installer without any files, or only with packages in it, to keep the load low. Another possibility would be if SUF would support to compress files into extra archives and keeping the installation algorithm in an extra executable. This way, the archives could be kept and just the executable would have to be rebuild. This would get rid of redundancy and overhead very efficiently.
- SUF should automatically delete all registry settings that have been made during installation.
- Support for external commandline archivers would be highly appreciated. I know that SUF supports plugins, but it doesn't take a plugin to specify a commandline archiver and having it wrapped by the installer. This stems from my tries to use an updated version of LZMA.exe, because the one that comes with the program is very outdated. Unfortunately SUF 8 seems to use a slightly different syntax, so I couldn't profit from the new version and had to use the old one instead. I don't understand why a program of 2008 uses an external tool that dates back to 2006, yet has seen several updates before SUF 8 was even released. This brings me to more compression-related issues.
- The memory consumption is far higher than it should be. I've been using 7-zip for 3 years now and regularly use 256MB dictionaries on my system with 4GB RAM. I only need about 2800MB of free RAM to utilize 7zip, while SUF's LZMA errored out, even when I had 3300MB freed up. I had to free up almost 3350MB, which is hard to do on Vista. I think you should release a patch that would either allow usage with a more current build of LZMA or enable 7zip support. Either way, your customers would certainly enjoy profiting from multi-core support for compression and installation and better compression ratios.
- After I managed to free enough RAM I let the process run. After an hour I checked back at my computer, only to find over 1700 instances of conime in my task manager. I'm puzzled how this could have happened. After all, conime shouldn't have much to do with compression. Each conime instance coincidentally had the same size as the supplied LZMA.exe (96kb), while my usual single instance of conime takes up a rough MB.
- Support for solid compression. It looks like SUF compresses each file for itself instead of packing them all into a single file. This way compression would gain tremendously in some installations. At least it would be nice to have the option to use it.
- Pause button to halt the build process.
- Resizable wizard window during the build process to see the full pathnames. Also, the slider should stay in position and not jump back to the same position after every window update.
- Support for background music and notification sound when installation is finished.
- SUF should show the full pathname in the installation window when a constant folder is prepended to the destination folder. In my case, I wanted the installation to be always in the same base folder. The customer was allowed to change the final foldername, but not that of the base folder:
path of choice\Company Name\%ProductName%
"Company Name" was unchangeable, because I defined it in the session variables window. So far so good. All installations would end up in a folder with my company name in it, regardless of how the user named the final folder. However, in the installation window SUF stopped showing the installation path at my constant folder definition, so in the installation window, SUF would show the user that the program would go to
C:\program files
instead of
C:\program files\company name\productname
The latter path was still used for installation despite the display of the incomplete link, but it looks rather strange and might cause insecurities among users, or cause them to mess around with the installation path more than they would have to.
- The package window should be more configurable design wise, e.g. size of the package field, its position, style of additional information about the packages. It would be great to be able to personalize the latter, because I don't see a good reason why the mere information of how much space the package takes up should use up another empty field that takes up a fourth of the whole window. In my case, I had a rather large text section above the package selection field, so I trimmed the top bar and moved the main body more to the top, but instead of only moving the text, the selection field was also stretched out and that to a point where it was bigger than it had to be. That wouldn't have been bad (even though it didn't look good), but that field ended up being 50% bigger than it had to, while a good portion of the text was trimmed, because it couldn't fit into the window any more.
- Configurable size of the installer windows. I can't believe that this wouldn't be possible in such a complex program, yet I haven't seen such an option.
- Support for installing external files that do not belong to the installer archive. For example, I want to distribute my program on DVD. The setup files are supposed to be stored in the root directory, which also contains a readme and several pdf-files. I didn't include them in the installer, because they are also supposed to be accessible through the autorun menu, so it would be great if the setup could just copy them into the installation directory, or link to them in the start menu without having them archived in the installer directly.
- Support for uninstall + repair + modify installation. I know this can be done through scripting and I have already done that, but especially modifying installations, or repairing them can get rather tedious to script, especially if you have to check hundreds of files for change or deletion and restore them accordingly. Would be great if SUF supported that right out of the box. After all, this is a rather generic process and it also has all necessary infos to do this job in an automated fashion.
- Longer path/full path display during installation. SUF only seems to display the first directory after root and the final file during installation, regardless of how much space there's still left for path display. This function should be more dynamic and should show as much of the part as possible and not just " C:\Program Files\..\test.txt"
The next list contains odd behavior that I experienced. I think those might be bugs, but may be that are only wrongly interpreted features.
- Using the slider in the wizard window during the build process pauses the current lzma-process in the background. This shouldn't happen.
- When adding files to my project, SUF always replicates the appfolder for subfolders, resulting in invalid installations. Example:
appfolder\main.exe
appfolder\otherfolder\file.txt
The latter path would be changed to "appfolder\appfolder\otherfolder\file.txt" upon import. Of course I can correct this in SUF, but this shouldn't even be happening in the first place.
- Installer just vanished when free space was smaller than installation size.
- Switching between installer windows that feature different background graphics resulted in very unsmooth picture rendering. The new picture didn't pop up at the same time like the new window as it should be, but the process took about half a second in which the picture was kind of expanded around the option settings. So the progression through the menus looked rather jerky. I have never seen such a behaviour and a professional product shouldn't showcase something like that.
This was quite a write-up, but I hope this is appreciated. After all, I like Setup Factory and don't want to get rid of it, because of the few shortcomings it has. I hope some of my suggestions will find its way into the next version.
I'm using Setup Factory currently in a project that spans 10.000 files and about 6GB. I'm fairly new to it and found it to be powerful, yet limited and sometimes even buggy. The following is based on my experience. I haven't read through all the suggestion section, so excuse me if I'm requesting something others have already asked for. Just take it as another vote for that feature. Also take it easy on me, if that feature already exists and I just overlooked it
- Simulation mode for the installation script. The build process takes about 2 hours on my system. Compressing files over and over again in each run is highly inefficient. It would be great if there was a way to simulate the installation without any file movement. Alternatively, there could be an option to allow building the installer without any files, or only with packages in it, to keep the load low. Another possibility would be if SUF would support to compress files into extra archives and keeping the installation algorithm in an extra executable. This way, the archives could be kept and just the executable would have to be rebuild. This would get rid of redundancy and overhead very efficiently.
- SUF should automatically delete all registry settings that have been made during installation.
- Support for external commandline archivers would be highly appreciated. I know that SUF supports plugins, but it doesn't take a plugin to specify a commandline archiver and having it wrapped by the installer. This stems from my tries to use an updated version of LZMA.exe, because the one that comes with the program is very outdated. Unfortunately SUF 8 seems to use a slightly different syntax, so I couldn't profit from the new version and had to use the old one instead. I don't understand why a program of 2008 uses an external tool that dates back to 2006, yet has seen several updates before SUF 8 was even released. This brings me to more compression-related issues.
- The memory consumption is far higher than it should be. I've been using 7-zip for 3 years now and regularly use 256MB dictionaries on my system with 4GB RAM. I only need about 2800MB of free RAM to utilize 7zip, while SUF's LZMA errored out, even when I had 3300MB freed up. I had to free up almost 3350MB, which is hard to do on Vista. I think you should release a patch that would either allow usage with a more current build of LZMA or enable 7zip support. Either way, your customers would certainly enjoy profiting from multi-core support for compression and installation and better compression ratios.
- After I managed to free enough RAM I let the process run. After an hour I checked back at my computer, only to find over 1700 instances of conime in my task manager. I'm puzzled how this could have happened. After all, conime shouldn't have much to do with compression. Each conime instance coincidentally had the same size as the supplied LZMA.exe (96kb), while my usual single instance of conime takes up a rough MB.
- Support for solid compression. It looks like SUF compresses each file for itself instead of packing them all into a single file. This way compression would gain tremendously in some installations. At least it would be nice to have the option to use it.
- Pause button to halt the build process.
- Resizable wizard window during the build process to see the full pathnames. Also, the slider should stay in position and not jump back to the same position after every window update.
- Support for background music and notification sound when installation is finished.
- SUF should show the full pathname in the installation window when a constant folder is prepended to the destination folder. In my case, I wanted the installation to be always in the same base folder. The customer was allowed to change the final foldername, but not that of the base folder:
path of choice\Company Name\%ProductName%
"Company Name" was unchangeable, because I defined it in the session variables window. So far so good. All installations would end up in a folder with my company name in it, regardless of how the user named the final folder. However, in the installation window SUF stopped showing the installation path at my constant folder definition, so in the installation window, SUF would show the user that the program would go to
C:\program files
instead of
C:\program files\company name\productname
The latter path was still used for installation despite the display of the incomplete link, but it looks rather strange and might cause insecurities among users, or cause them to mess around with the installation path more than they would have to.
- The package window should be more configurable design wise, e.g. size of the package field, its position, style of additional information about the packages. It would be great to be able to personalize the latter, because I don't see a good reason why the mere information of how much space the package takes up should use up another empty field that takes up a fourth of the whole window. In my case, I had a rather large text section above the package selection field, so I trimmed the top bar and moved the main body more to the top, but instead of only moving the text, the selection field was also stretched out and that to a point where it was bigger than it had to be. That wouldn't have been bad (even though it didn't look good), but that field ended up being 50% bigger than it had to, while a good portion of the text was trimmed, because it couldn't fit into the window any more.
- Configurable size of the installer windows. I can't believe that this wouldn't be possible in such a complex program, yet I haven't seen such an option.
- Support for installing external files that do not belong to the installer archive. For example, I want to distribute my program on DVD. The setup files are supposed to be stored in the root directory, which also contains a readme and several pdf-files. I didn't include them in the installer, because they are also supposed to be accessible through the autorun menu, so it would be great if the setup could just copy them into the installation directory, or link to them in the start menu without having them archived in the installer directly.
- Support for uninstall + repair + modify installation. I know this can be done through scripting and I have already done that, but especially modifying installations, or repairing them can get rather tedious to script, especially if you have to check hundreds of files for change or deletion and restore them accordingly. Would be great if SUF supported that right out of the box. After all, this is a rather generic process and it also has all necessary infos to do this job in an automated fashion.
- Longer path/full path display during installation. SUF only seems to display the first directory after root and the final file during installation, regardless of how much space there's still left for path display. This function should be more dynamic and should show as much of the part as possible and not just " C:\Program Files\..\test.txt"
The next list contains odd behavior that I experienced. I think those might be bugs, but may be that are only wrongly interpreted features.
- Using the slider in the wizard window during the build process pauses the current lzma-process in the background. This shouldn't happen.
- When adding files to my project, SUF always replicates the appfolder for subfolders, resulting in invalid installations. Example:
appfolder\main.exe
appfolder\otherfolder\file.txt
The latter path would be changed to "appfolder\appfolder\otherfolder\file.txt" upon import. Of course I can correct this in SUF, but this shouldn't even be happening in the first place.
- Installer just vanished when free space was smaller than installation size.
- Switching between installer windows that feature different background graphics resulted in very unsmooth picture rendering. The new picture didn't pop up at the same time like the new window as it should be, but the process took about half a second in which the picture was kind of expanded around the option settings. So the progression through the menus looked rather jerky. I have never seen such a behaviour and a professional product shouldn't showcase something like that.
This was quite a write-up, but I hope this is appreciated. After all, I like Setup Factory and don't want to get rid of it, because of the few shortcomings it has. I hope some of my suggestions will find its way into the next version.
Comment