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. :-)
