Nsis Vs Installshield Error
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.
What Is Nsis Error
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. JimNice 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. On 12/6/2016 10:31 PM, Thomas Mader wrote: 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?I'm not sure what you mean by switch the directory. If you mean that the update uses a different directory for the program than the original, then you can probably just use a 'major' upgrade.
Windows Installer has the idea of minor upgrade and major upgrade. (So, it's independent of whatever tools your using.) A minor upgrade just updates the files that have changed.
A major upgrade essentially removes the original product totally and installs the new one. Some people even use a major upgrade for every new version just to avoid problems that might occur with a minor upgrade.If your install is simple it may not matter whether it's transactional or not.
If it fails halfway through just try again or else ask the user to delete files. But for a more complicated install it's possible that it fails halfway through and leaves the system in a bad state where the half-install cannot be easily removed nor can you try again because the installer now thinks the product is already installed. Trying to fix this on a remote user's system can be a headache.I liked WiX because it was down to the metal and I don't think there's anything you can't do. With other tools (like InstallShield) I spent too much time trying to get the tool to do something I could have done really easy at the low level if I could've just gotten to it. But granted, for simpler install situations the scripting tools can work OK and have a smaller learning curve.Jim.
On Monday, 5 December 2016 at 19:33:33 UTC, Jim Hewes wrote: On 12/5/2016 3:19 AM, Kjartan F. Kvamme wrote: On Monday, 5 December 2016 at 09:24:59 UTC, Basile B. Wrote: How about a bounty for a new windows installer using inno setup?
There are several issues related to the nsis-based windows installer (even on bugzilla). The problem that happened last Fall with a virus false detection may happen again. 'Braddr' proposed to handle digital signatures in case it would involve payment.
Programming an installer is a small job but it has a long term impact on the user experience. Worth 100€ imo. Any particular reason to use Inno Setup over for example Wix Toolset?
In my last job I worked on installers (which I didn't like but someone had to do it.) I recommend WiX over Inno. The main reason is that WiX produces an MSI and Inno doesn't. An MSI is just a data file, not an executable, and is thus better for security. I normally wrapped the MSI in a bootstrap exe. But we had one customer that was part of the government and wouldn't accept anything but an MSI. If you want, you can generate the XML with a program. I just didn't because I figured it was easier to modify if you can directly see the XML.
My install builder was actually a combination of C# and WiX. I never found scripts to be flexible enough and it's just one more language to know.
Jim Yes, if DMD is going to switch the installer to something else it should be MSI. It's the official way to create installers on Windows and IT departments prefer it. Just switching to another installer executable generator is a lateral step, rather than a step forward.Microsoft seems to be wanting to quietly deprecate MSIs too and are increasingly not using them for their own products (likely to push people to the Windows Store). I'm not sure if the Windows Store is suitable for DMD though and adapting DMD to it would probably involve quite a bit of work and would likely involves legal agreements with Microsoft that only the D Foundation could make.
On Wednesday, 7 December 2016 at 23:00:13 UTC, Jim Hewes wrote: On 12/6/2016 10:31 PM, Thomas Mader wrote: 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? I'm not sure what you mean by switch the directory. If you mean that the update uses a different directory for the program than the original, then you can probably just use a 'major' upgrade.
Inno Installer Creator
Windows Installer has the idea of minor upgrade and major upgrade. (So, it's independent of whatever tools your using.) A minor upgrade just updates the files that have changed. A major upgrade essentially removes the original product totally and installs the new one. Some people even use a major upgrade for every new version just to avoid problems that might occur with a minor upgrade.The Update is triggered by the application itself. If the install fails or is Canceled in the middle the application can not start anymore and so the user needs to do something manually.It would be possible to update everything into a new directory and after everything is done just exchange the stuff in the already installed directory with the new update directory.But even this operation isn't atomic even though it's much better.What might work is to make it work like the Nix package manager.NixOS (Nix Package manager) provides atomic updates because the entire system environment is build by links.
Replacing a version with another one is just a matter of changing the link to the proper directory.So in Windows you could do it the same. Install versions in separate directories. The installation directory is linking to the appropriate version directory. On update just install to new version directory and after everything is done just update the installation directory link to the new update directory.No matter what happens either the old or the new application version should be workable. On Wednesday, 7 December 2016 at 23:00:13 UTC, Jim Hewes wrote: On 12/6/2016 10:31 PM, Thomas Mader wrote: 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? I liked WiX because it was down to the metal and I don't think there's anything you can't do. With other tools (like InstallShield) I spent too much time trying to get the tool to do something I could have done really easy at the low level if I could've just gotten to it. But granted, for simpler install situations the scripting tools can work OK and have a smaller learning curve. JimI think you might be right about using WiX.
MSI seems to be build upon transactional installation.Do you think it would be possible to use D instead of C to write custom code? On Thursday, 8 December 2016 at 11:03:07 UTC, Thomas Mader wrote: I think you might be right about using WiX. MSI seems to be build upon transactional installation. Do you think it would be possible to use D instead of C to write custom code?Short answer is yes, I've created such and actually inject my custom DLL for testing purposes.MSI's are pretty awkward, no one knows how to create the MSI database instead there are 3 example databases provided which you can merge together if you desire that feature.
From there the Database consists of tables which layout the installation sequence along with the installation sequence for the GUI. These sequences can call 'Custom Actions' which are just table entries that point to a DLL (there is more to Custom Actions).The signature looks something like below. I've got a little wrapper around the MSIHANDLE so as to add some safety and convenience.extern(Windows):export uint MyCustomActionName(const MsiLiveHandle hModule) I'm not too familiar with WIX and the exposure I've had is with older versions (3.x) which have had annoying and weird bugs. D certainly could be used to create the D MSI installer, but that is even lower level than WIX.
Installshield Error Codes
On Friday, 9 December 2016 at 10:35:00 UTC, Kagamin wrote: On Thursday, 8 December 2016 at 20:04:01 UTC, Jesse Phillips wrote: These sequences can call 'Custom Actions' which are just table entries that point to a DLL (there is more to Custom Actions). Why not just unpack the stuff and run a configuration program?
NSIS (Nullsoft Scriptable Install System) is a professional open source system to create Windows installers. It is designed to be as small and flexible as possible and is therefore very suitable for internet distribution.Being a user's first experience with your product, a stable and reliable installer is an important component of successful software. With NSIS you can create such installers that are capable of doing everything that is needed to setup your software.NSIS is script-based and allows you to create the logic to handle even the most complex installation tasks. Many plug-ins and scripts are already available: you can create web installers, communicate with Windows and other software components, install or update shared components and more.Featured 3rd Party Projects.