|
A bit late, this post...
When this survey started we were using Wise. Today we have started migrating to NSIS. I never before considered NSIS an option, mainly because it is Open Source, but after reading some opinions here I decided to have a look. And after being convinced myself, I have now also convinced the others that NSIS is the way to go.
I think it has a lot to do with magic. If you like the wizards that by some strange reason works but you don't really know why, then InstallShield is probably the choice. But if you don't like surprises then NSIS is the way to go. Wise is somewhere in between, but probably closer to NSIS. But there are still too many things in it that just happen by itself.
This is the good thing about NSIS. All that ever happens in the installer is found in the installer file(s). This file is normal text so you can edit it with your favourite editor (I have never understood what is good with binary file formats -- do you want to hide something? Do text files make things too easy? Exception are of course raw data files). And there's nothing you can't do. You can create plug-ins both for compile time and for install time to do whatever the core system can't do.
The main reason we are sanctioned to leave Wise is actually that we are reaching a limit. Wise can only have 15 different languages (I wonder what the code looks like -- an array with a fixed size of 15?!? I haven't done one of those since my first programming assignment at school). We are now at 12 and will probably hit the limit within half a year.
Another plus for NSIS is the excellent support. They have a forum where if you post a question you will get an answer within the hour. Wise is slow and you can not always count on a solution. And which one cost money?
I have nothing much to say about InstallShield as I have very little experience with it. It has never been an option because of all the magic.
|
|
|
|
|
OK. This is a good subject.
Part of my work, with my former employer involved packaging and deployment (I was the "build" guy).
A colleague had already created a package with InstallShield (v.7-ish), investing 2-3 months.
Mistake #1: I decided that I didn't really want to learn a new scripting language and that I would rather convert the project to basic MSI. Unfortunately, the payoff was very minimal... I think that the whole thing was a bit more streamlined and compact, but in the eyes of my employer, the payoff was not tangible... learning InstallShield and then delving into MSI took me something like two months... <cough> (shame).
With the InstallShield scripting, there was some weird logic implemented in order to "remember" the order in which the dialogs were being presented to the user (I think because we had to present different dialogs based on user choices)... just so that the Back button would work correctly (so there was an incentive for me to clean it up).
But even with MSI, you're pretty much stuck with the same problem. If, for instance, you wish to change the order in which dialogs are presented, you must modify the behavior of both the Next and the Back buttons of all the dialogs that are linked to the change, either at the source or destination. This problem is compounded if, for instance, there are multiple dialogs that may be invoked depending upon a condition. You wouldn't expect it to be so complicated since conceptually, it's so simple (the discrepancy is huge).
So I'm glad I got rid of the weird scripting, but now I'm also stuck with a few little custom actions that are necessary to populate an XML configuration file (values drawn from the user's choices). Simple. I must have used either JScript or VBScript (not my favorite, but...). For another task, I had to write a C wrapper around the C++ interface, and then call it from a custom action, ensuring that the signature and values carefully entered (i.e. pain).
And this is only the tip of the iceberg.
I think at one point, I needed to invoke a "deferred execution custom action" ('cause you can't invoke the DLL function until the DLL has actually been copied to the target)... there was some magic involved there. And then there were problems propagating the information (property value) to the DLL (had to do with the CustomActionData). (i.e. more pain)
Don't even get me started about "sequences".
Due to this and other problems, I was ultimately fired (I accept my part of the responsibility). This is my recommendation (for those who like their work)... gleaned from what I think I would have done differently:
1. I'm not ready to dump MSI entirely, but the only thing preventing me is that I think it's necessary if you require logo certification (not a bad thing even if you don't need it). I'm not even sure I understand the logic of why they (MS) developed it. Sure, if you put the data in the tables and if there are enough tables to describe all the data, you can write an engine that scans the data (and you can write ICEs, internal consistency evaluators, to validate), and then turns around and calls an API. I'm not persuaded that this is so much better than just providing the API, letting developers call it directly (works for all the other APIs).
During my investigations for the build system, I was impressed by Ant. One of the tasks developed for NAnt, the "MSITask" seemed to duplicate all the installers, but allowing the data to be described in XML format, which I thought was kind of cool. This provides an analogous method, which I didn't see enumerated as part of the choices of this survey. But even for Ant, the above logic is applicable: what is the difference between copying a file whose name is parsed from an XML data file or compiled into a program?
2. So I sold my sold my soul to Bill and I think that if I'm going to start programming in C# and DotNet, that I want to do everything with it (sure, when you get a hammer, everything starts to look like a nail...). The idea here is that, even though dialogs and other program resources are commonly described in resource files, that the MSI database approach is nowhere nearly as flexible and powerful as even the most primitive RC (resource compiler), such that, even if you elect to continue using MSI, you can still write your interface using your traditional (form-based) development methods. I think this is basically what is being suggested by ("Windows Installer for Game Developers", Dave Bartolomeo, October 14, 2003). My own solution, had I been smarter, would have been to write the UI in C# with forms, and (as is described somewhere) bootstrap the DotNet installation with the custom UI program and the final MSI installation (whose duties are now relinquished to just copying files and a few registration scripts and what not). No MSI UI!
Even if your installation procedure requires extensive configuration, this is best handled in-house. A custom UI allows you to put your best foot forward during the very critical initial phase of customer acceptance... for very little cost. After all, it's only a couple of screens and it probably won't be worse than the rest of the application.
Microsoft must dump MSI in favor of XCopy deployment (or one-click is good too) as soon as possible. I don't think they can pull it off, but in the mean time, perhaps VSI will keep things hidden well enough. Problem is... doesn't XCopy entail that every application will then duplicate all the common DLLs, making them run side-by-side, preventing them from being shared across processes (sure memory is cheap, but isn't this a cornerstone?). Also: InstallShield must die.
Disclaimer: you may have gathered… there are still a lot of areas where my knowledge of MSI/InstallShield is lacking, despite having studied them for some time (patching and upgrade scenarios, for instance). Take my advise for what it’s worth… and nothing more.
|
|
|
|
|
InstallShield and the other installer are very good, but when you need some especific features of your program to be installed (like a matrix for criptography or somethings like that), you can not trust these installer, so I develope my own and used in this kinds of installations...
I know some people may say that you can add some scripts and dll's to some of this installers but you don't have the real control over what is been doing....;P
Galo.
|
|
|
|
|
I'm not saying that is wrong to design your own installer...What I'm saying is that it's kind of stupid to do that when you have the complete source code (for free!) for an installer like NSIS for example, which can do more than your own-designed installer can do.
Please have in mind that an installer like NSIS have been developed for ~4 years. Probably, you will understand after a while that you'll spend more time in developing your own installer than doing what you really have to do - distribue your application. This is not OK I think  .
Don't be so suspicious about using someone elses code...I doesn't mean it less intelligent than your own! It's probably more bug free than the code you write for your own installer.
|
|
|
|
|
...in which case any setup will work fine.
But for enterprise deployments, the *only* way to install a software of any kind is by using the Windows Installer services, thus MSI.
Weird that, if you use the VS.NET integrated setup project wizard, and build a Windows Installer 2.0 MSI package, then, believe it or not, end users might well have to install an installer (windows installer 2.0 run-time) and reboot before they install your app. 
A lot of MSI-capable installers have a better quality/price ratio than InstallShield, arguably the worst installer ever known to mankind. (in the early days, one had to download tens of patchs only to be able to use it).
That being said, a comprehensive support for deployment is the weakest piece in Microsoft development products. I am talking .NET (try installing an add-on with shared assemblies, try installing a program doing at least one P/Invoke or COM call without admin rights, try versioning assemblies without strong signing them first...), and this is kind of frightening that the coming ClickOnce will not solve issues until the Longhorn milestone. Does it mean it's impossible to install a piece of software reliably? Won't answer that, but you had better keep it simple and uncorelated to other pieces of code.
The last problem is admin rights. Double-clicking on a .exe that masquerades as a setup package, or some nasty scripts within a neutral setup, can wreck the machine. I wish installers would be rated just like products for their support (or lack thereof) to installation with non admin profiles.
RSS feed
|
|
|
|
|
Screwdriver, duct tape, and a ball-peen hammer
(the one item missing from the list is prayer/cursing, depending upon your metaphysical bent)
Software Zen: delete this;
|
|
|
|
|
- Screwdriver for those loose screws in the case
- The tape for the cd-rom.
- Hammer for the computer if it freezes during the installation
I get that, but what about the software itself? It's a lot easier to install software...
Greetings....
|
|
|
|
|
I use WinZip's self extractor to create simple-minded "installs" for users who aren't savvy enough to extract the contents of a zip file to a folder.
/ravi
My new year's resolution: 2048 x 1536
Home | Articles | Freeware | Music
ravib@ravib.com
|
|
|
|
|
Anyone has ever installed MSDE 2000 w/o using the setup.exe provided by Microsoft
-OR- using the Installshield MSI component for MSDE 2000 ?
I have been using Installshield so far. Any other way to install that
component ?
|
|
|
|
|
I use Installshield as it is the easiest way of building the complex MSI installers I need.
MSI is a big thing with IT departments at the moment. They all want installations that can be deployed / un-deployed via Win2k group policies. Whilst it makes their lives easier, it just makes my job harder.
I do miss the DOS days where we had a batch file that XCOPYied the files into a folder. It was all so much easier. Now, with the registry, uninstall information, com server registration and the like, it takes me longer to build and test the installer than it does for some of my applications.
Michael
But you know when the truth is told,
That you can get what you want or you can just get old,
Your're going to kick off before you even get halfway through.
When will you realise... Vienna waits for you? - "The Stranger," Billy Joel
|
|
|
|
|
Michael P Butler wrote:
MSI is a big thing with IT departments at the moment. They all want installations that can be deployed / un-deployed via Win2k group policies. Whilst it makes their lives easier, it just makes my job harder.
Indeed - MSI is a good idea, but another implementation gone badly wrong - it's just WAY TO screwed up to be useful and efficient... Go with InnoSetup - it's free, fast, compact, and easy to use, and still handles 99% of your install needs. And you can always wrap an Innosetup "Setup.exe" inside a .MSI for camouflage 
I do miss the DOS days where we had a batch file that XCOPYied the files into a folder. It was all so much easier.
Well, rejoice - with the advent of .NET apps, these days are (FINALLY!) coming back (when done correctly). No more messy COM registration crap, no more flood of registry keys that need to be set before the app can even start up....
=============================
Marc Scheuner, Berne, Switzerland
m.scheuner - at - inova.ch
May The Source Be With You!
|
|
|
|
|
I would like MSI if it weren't so limited and you didn't have the headaches of making sure the user has the correct MSI engine on their machine. 
"I'd be up a piece if I hadn't swallowed my bishop." Mr. Ed, playing chess
|
|
|
|
|
after too many years mucking about with my previous employer's homegrown installers (must have seemed like a good idea once upon a time) i've decided that if my own stuff can't be installed from a zip file then it's simply way too complicated! 
.dan.g.
AbstractSpoon (subscribe)
|
|
|
|
|
Nothing wrong with that, as long as you don't need any services, don't install any shared files, don't install any shortcut items, want a GUI, need to write any registry entries, etc., etc...
Oh how I wish I could have something so simple it could be distributed as a ZIP file!
"I'd be up a piece if I hadn't swallowed my bishop." Mr. Ed, playing chess
|
|
|
|
|
Nothing can be simple enough; there will always be at least one who totally screws it up.
Zip files are the worst solution on earth.
|
|
|
|
|
Or more accurately, are writing our own. It is and will always be a work in progress. Why, dear ![Green Alien | [Alien]](https://www.codeproject.com/script/Forums/Images/alien.gif) , you may ask, did we write our own installer when so many others already exist? Well, we needed all of these features and there was no commercial install package in existence that can handle this:
Install drivers.
Install, stop, and start services.
Handle shared items - files AND registry entries - elegantly.
Handle shared applications elegantly.
Allow customer to perform a silent script install.
Be able to install remotely.
Support multiple languages easily.
Installation rules are controlled by a script.
Installation GUI is controlled by a script.
Be able to remove certain items created *after* the install.
MSI doesn't make sense for most our stuff, except simple, non-shared, non-driver applications. Perhaps MSI will get better in the future and will be usable without having to add layers of custom actions to it...
I would not recommend this for the faint at heart. So many minefields and problem situations to take into account (especailly uninstall...  ) but it was definitely worth it for us.
"I'd be up a piece if I hadn't swallowed my bishop." Mr. Ed, playing chess
|
|
|
|
|
Navin wrote:
Install drivers
I understand that one. I've got a custom action in an InstallShield install that runs an EXE that installs a driver. Blech.
Software Zen: delete this;
|
|
|
|
|
Yeah... it's a royal pain. In theory, MS is coming up with a nifty tool that can package a driver so that it can install a lot eaiser... but I'll believe it when I see it (and use it, and don't get customer complaints. )
"I'd be up a piece if I hadn't swallowed my bishop." Mr. Ed, playing chess
|
|
|
|
|
I'm a little shocked that InnoSetup is ranked #2 so far. Especially since it doesn't support Microsoft's current MSI standard.
So, for those of you who voted for InnoSetup, I'm interested in knowing why you chose it over the other installation tools.
|
|
|
|
|
InnoSetup is free, fast and easy to use. Not everybody has InstallShield. I do, but I found it a bit unwieldy. Perhaps it just has too much flexibility. Maybe it's improved with the new standard, but I haven't bothered to check it out.
Is it just me, or are MSI installers annoying?
|
|
|
|
|
Joshua Quick wrote:
I'm a little shocked that InnoSetup is ranked #2 so far. Especially since it doesn't support Microsoft's current MSI standard.
I see this "missing" support of MSI not as a flaw, but actually a benefit. The basic idea behind MSI (to have a system-wide standard for installs) is good - but the way MS implemented it is just WAY TOO complicated for 99% of all installs.
So, for those of you who voted for InnoSetup, I'm interested in knowing why you chose it over the other installation tools.
It's free, it's fast, it does its job without tons of overhead, it JUST PLAIN WORKS without all the hassle and costs (both purchasing and also learning to use) other installation behemoths....
=============================
Marc Scheuner, Berne, Switzerland
m.scheuner - at - inova.ch
May The Source Be With You!
|
|
|
|
|
I took a look at InnoSetup's website. I fail to see how it is easier to use compared to the Visual Studio installer (VSI).
In VSI, when I want to build a new install program, then I just do the following:
1) Select a solution or project file.
2) Build it.
That's it. I'm done. VSI automatically determines and includes the project's dependencies.
From what I've seen in InnoSetup, and correct me if I'm wrong, you have to script every file you want to include and you have to determine the file dependencies yourself. If it's VB runtimes, MFC runtimes, ComCtrlX.dll, MDAC, etc. (these cannot be installed easily) then you have to fetch these packages from MS themselves and then script them into the installer. What a hassle! Plus, it's error prone.
However, at least you "can" script the installs in InnoSetup for the more complicated installs.
I've tried InstallShield and Wise. Both are very complicated and I don't care for them much. I like VSI because it is simple to use and I don't like spending a lot of time working on an installer by the end of my software projects. I'm still willing to be convinced. Is there anything else I should know about?
Oh, and I briefly took a look at NullSoft's installer. I can't see most professional software companies using any program having "Super PIMP" technology!
|
|
|
|
|
Joshua Quick wrote:
I can't see most professional software companies using any program having "Super PIMP" technology!
Well, another reason for me to be glad i'm not most professional software companies then. Honestly, it does sound like a rough time! 
(but yeah, you don't exactly have to put "PIMP" on your splashscreen to use the installer)
Still, you've made some good points otherwise - determining dependancies can be tedious and error prone. Until recently though, that was how writing installs went - hence the reluctance of many to write them. From what i've seen, a well-written MSI can be a wonderful thing indeed - but still, there are times when it is more trouble than it's worth.
For instance: i just finished putting together an update for our software, meant to be distributed online. The full installation is something like 300MB - a bit much for users with slower connections to be downloading. The update, by including only files changed since the previous release and including only changed portions of the files that had been updated, was reduced to just under 70MB - not small, but at least manageable. There the flexibility of something like NSIS comes into play. A small program written to generate an install script based on changes between the two installations, plus four custom macros, and the installer can be built with the push of a button as single file redistributable for any system from Win95 to Win2k3.
As with most things (VB vs. C++, VS vs. Notepad), the right tool for the job.
How do you move in a world of fog, That's always changing things?
Makes me wish that i could be a dog, When i see the price that you pay.
|
|
|
|
|
Shog9 wrote:
There the flexibility of something like NSIS comes into play. A small program written to generate an install script based on changes between the two installations, plus four custom macros, and the installer can be built with the push of a button as single file redistributable for any system from Win95 to Win2k3.
Mind you, if you were using InstallShield to build your MSI you wouldn't have to bother with writing the small program or the custom macros. Modify your existing installation project to create a new compiled version of your full install, and tell it which older compiled versions you want to be able to upgrade from. Then decide which configurations you want to supply a patch for, tell InstallShield where the compiled versions are so that it can work out the differences and compile the patch, or patches, that you want.
The result: the same sort of optimised patch you're getting from NSIS, but without the programming requirement, and with the sysadmin-friendliness of Windows Installer. The only advantage I see left for NSIS is the price, which is usually not a large part of the final project cost.
Gavin Greig
"Haw, you're no deid," girned Charon. "Get aff ma boat or ah'll report ye."
Matthew Fitt - The Hoose O Haivers: The Twelve Trauchles O Heracles.
|
|
|
|
|
Almost everyone here complaining of InstallShield hate it because of all the hidden bugs and problems that it generates.
I don’t agree with you that the only advantage using NSIS is the price! I can tell you about all those hours/days/weeks we spent on making the InstallShield installation to work as WE want it to work. I’m sorry to say this, but I don’t share your patch needs. Our software distributions are small (up to 100 Mb)
To me and to all people I met having IShield experience, InstallShield is nothing else than the installation systems Visual Basic which is also an awful programming language. Maybe you are a VB programmer…and like this way of dealing with things…
When you build in abstraction in your system, things will get complex and eventually you will get problems that you never could guess even existed. And what should I tell you about my experience with IShield?
I used it for 9 years and the last version we purchased was thrown out trough the window after testing it for 4 days. Old installations “converted” to IShield 9 didn’t worked any more, strange things happened with objects like font registering and services...and other things like this. And please tell me, why should I use it? Because there is this company behind it that nothing else produces than bugs? Is this the reason, because you feel comfortable to “purchase” the software and think that paying for it will solve all your problems? I don’t think so.
So, you were right, the cost of the installation software (like InstallShield) is not even a small part of the cost of the whole project...but, have you added all the time you’ve spent to build the installation for your software in that cost?
I don’t think so.
/Paul
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
