How about a bounty for a new windows installer using inno setup ?

Thomas Mader via Digitalmars-d digitalmars-d at puremagic.com
Tue Dec 6 22:31:41 PST 2016


On Tuesday, 6 December 2016 at 17:28:25 UTC, Jim Hewes wrote:
> On 12/6/2016 12:21 AM, Thomas Mader wrote:
>>
>> You can also create a WiX installer out of an InnoSetup 
>> installer.
>> I think it's more important to decide upon the feature set, 
>> readability
>> and the time needed to build an installer.
>> Have you experience with both? I only have experience with 
>> NSIS and
>> InnoSetup and in InnoSetup the feature set for Windows is 
>> really good
>> and the readability is good.
>
> I started out by using InstallShield some years ago and got 
> battle scars there. I don't recommend that. I used NSIS a 
> little because a company we partnered with required it but I'm 
> no authority on NSIS or Inno.
>
> It really depends on how complicated your particular install is 
> and where you expect it to go in the future. If you're just 
> copying a few files then anything will work. I don't mean to 
> make too big a deal out of it if the requirements are really 
> simple.
>
> Personally I think it's better in the long run to generate an 
> MSI for several reasons you can probably look up 
> yourself---security, ability to rollback (installation is a 
> transaction), appears in Programs and Features, transforms, etc.
>
>> I wouldn't advise doing the coding part externally in D this 
>> makes
>> things much more complicated than it should be. Stick with 
>> what's
>> supported by the tool.
>
> I'm not suggesting you necessarily use D together with 
> something like NSIS. But you do want to have a one-button 
> automated build process, not just for convenience but for 
> repeatability. That's important. Soon you will want to get away 
> from the tool's own GUI and run things programmatically.
>
> After having not-so-good experiences with InstallShield I 
> looked at things like SCons and msbuild, which was just coming 
> out at the time. (This was a while ago). I tried msbuild but it 
> didn't have modules to support many of the things I needed to 
> do. Things like code-signing with a verisign signature, 
> injecting data and files into exe resources, etc. Fortunately 
> you can build your own custom modules using C# which is what I 
> tried. But the process of transferring variables back and forth 
> from the script to C# for every custom module was painful and I 
> thought, "if I just do this all in C# it will be much easier". 
> So I switched. I used C# not only to call on the WiX tools to 
> run them, but to easily manipulate pathname and filename 
> strings, which were different because I needed to build 
> different configurations for different customer companies. And 
> I also needed to build different combinations of language 
> localization. I could use .NET to build a nice GUI for 
> selecting configurations, and C# to call the Windows API when 
> needed, move files around, anything.
>
> You may also run into issues when you need to do complicated 
> updates and there are already earlier versions in the field. 
> You may want to remove features, but your installer has to both 
> update existing users in addition to supporting new users. It's 
> hard to predict the future though so I won't say much about it 
> except that it helps to have a more powerful tool when you run 
> into such situations.
>
> The scripting-type tools are tempting because they're easy and 
> no one wants to spend any time on installers. It's usually 
> something that people hope to just slap on at the end and it 
> often gets underestimated. But as I said, maybe it IS easy if 
> you're just copying files and you will only ever have one 
> configuration. So it depends.
>
> Jim

Nice writeup.
In our company we used NSIS and are switching over to InnoSetup. 
Most of the work is already done, just a few apps need to be 
moved.
I think no one really wants NSIS because of readability issues. 
It's assembler like language is too low level and many common 
functions are just missing.

InnoSetup on the other hand gives you everything you could ever 
want. I never missed a thing because pretty much everything is 
right there and if you happen to have very special needs you can 
do it quite nicely with the pascal scripting ability. You can 
call every Windows API function you just need to wrap it if it is 
not provided in one way or another via the InnoSetup API.
I don't think you need to do that for the D Installer though.

Our installers need to handle quite a few things.
- Signing and timestamping of exes, dlls, Installer and 
Uninstaller
- SendTo Handler registration (Windows doesn't provide a common 
SendTo directory so you need to handle it quite complicated for 
each users individual SendTo directory if you don't want to write 
a proper SendTo COM thing)
- Registration of a COM server
- Differentiate between 32 and 64 bit installs
- User elevation for Installs and Uninstalls but Updates are done 
for the current User (We still use Inno for our Updates too but 
move away from that because it's not at all transactional and 
cannot be undone in the middle of the update)
- Create MSI Installer from InnoSetup Installer via Wix

The update case could be better supported by Inno by default 
though I don't know how to really do it transactionally/atomic. 
Once everything is on the drive, how would you be able to switch 
from the old directory to the new one with one atomic action 
under Windows?

Apart from that I don't miss a thing in Inno for now apart that 
messing with Installers is always not that funny. :-)


More information about the Digitalmars-d mailing list