|
For huge enterprise apps, InstallSheild would do good. NSIS (Nullsoft Scriptable Installer) needs lot of scripting right?
|
|
|
|
|
Vasudevan Deepak Kumar wrote: For huge enterprise apps, InstallSheild would do good. NSIS (Nullsoft Scriptable Installer) needs lot of scripting right?
Let me just say this: A few years back, i wrote a GUI application to collect and configure file sets for five configurations of sixty-odd components, generate compressed diffs, generate the NSIS script, and compile the whole thing into an installer... in about the same amount of time it took to create a similar installer for the same app using InstallShield.
And i only had to write mine once...
----
It appears that everybody is under the impression that I approve of the documentation. You probably also blame Ken Burns for supporting slavery.
--Raymond Chen on MSDN
|
|
|
|
|
The biggest advantage of NSIS over InstallShield is the simplicity of the source files, you can write simple scripts / programs which will automatically create the installer for you, and faster than accomplishing the same thing in InstallShield.
|
|
|
|
|
Absolutely right! NSIS rocks! 
cheers,
mykel
OMM: "Let us be thankful we have commerce. Buy more. Buy more now. Buy. And be happy."
|
|
|
|
|
A lot of the script can be autogenerated using HM NIS Edit[^] - from there you can just use snippets of script to customize as required.
NSIS rocks.
|
|
|
|
|
As a sysadmin:
I know things are a lot better now but I can remember dozens of times that I have run into some bug in InstallShield that made it very difficult or impossible to install an app on a users pc. 
As a programmer:
That crap they gave away in visual studio 6 made me realize this was definitely not the installer that I wanted to use with my applications.
John
|
|
|
|
|
|
I agree : I use InstallShield (corporate constraint) but had no chance to experiment anything else, so I'd need an "other" or "nothing particuliar" as recommendation...
(BTW, InstallShield is OK, but maybe something's better...)
|
|
|
|
|
I wonder why 'ClickOnce' is missing from this list. Eventhough it is not a installer tool, this gives the best solution I have found so far. No need to worry about updates, patches etc.
|
|
|
|
|
I agree. I've been using it for about 2 months with our new application, and I couldn't be happier with it.
|
|
|
|
|
My installer of choice is a home-grown C++ command-line application. It is for use over a networked system, where a commonly accessible server contains the application components.
It uses a simple ASCII textfile argument list, and works as both an updater and installer, and includes the ability to update its own install list and reexecute it. A few other bells and whistles.
Given an install list, files are copied if they don't exist or over-written if a newer version exists. All the obvious features: del, md, rd, and behaviour variations if errors are detected (source file existance validation) . . . and best of all, lots of default behaviours that make sense (to me).
The update/installer includes ability to spawn another process: typically, the application it installs.
Typical use is to have the icon (also installable by the installer if precreated) call the installer with the appropriate list-file argument. This does its thing and then spawns the actual application the user wanted (with command line args if desired) and it closes. If the arg list file is modified, it reruns itself, instead.
Upsides: Installs and keeps application continiously updated from a selected repository. All items in its instuction list may be modified and rerun allowing simple-through-complex scenarios to handle application changes. Can be called recursively by simply changing the arg-file, which allows for complex re-setup (and cleanup) of an application already installed on a desktop. Very easy setup setup, even for new user.
Downside: I don't do any registry-entries. This may appear, maybe, after some soul-searching. It also feeds my compulsion to build software tools and keeps screaming out for some feature creep.
Some (where I work) have abandoned the commercial installers (like VS) in favor of this one.
Balboos
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
|
|
|
|
|
Ever looked at their editions? The so-called "developer" editions doesnt have a debugger, doesnt have automation interface (or however it is called), and a bunch of other features are missing compared to the whole package. How dare they take away the debugger/automation tools from the developers? Thats like saying "here's your new VS2009. Oh, btw, you cant debug C++ and C#, and cant deploy VB.Net and Java.net"
|
|
|
|
|
That's why we bought the Studio edition.
Minor annoyances aside (notably the poor support for copy/paste in the script editor and the fixed paths in "Install From" MSICode commands) we've so far found it to be far, far easier to use than the better known alternatives.
As an FYI: InstallAware seem to send a couple of their senior people to the ESWC[^] each year (it's in Köln in Germany this year). They seem pretty approachable, so if you've got a beef about something in the product you would at least have an opportunity to let them know how strongly you felt about it.
You'd probably get a beer out of it as well (as we did out of MS). It's that sort of conference. 
|
|
|
|
|
I have recently moved from Windows Development / Programming to "Repackaging". This is the process of taking a Vendor installation, and changing / modifying it to a MSI / MST package. I can only say, that although with the InstallShield products (which I have used extensively in the past, mainly due to it's powerful scripting capabilities) let them be! Do not use them. They cause so much trouble when creating MST's (if provided as MSI installations) or deploying them using the 'SYSTEM' context (mostly used when automated installations are required using Radia etc.) Something as 'simple' as repackaging a vendor installation that copies a few files, makes a few registry entries, and maybe installs a service becomes a major headache. Also, please take into account the guidelines provided by Microsoft when creating installation packages using the MSI technologies! You would be surprised how often these simple guidelines are ignored by the 'major players' (Try repackaging Nero Burning)
This may be going 'off topic' but perhaps when I find the time, I would like to write an article about the problems that can occurr if
1. Application developers do not take the access rights of a 'normal user account' into consideration whilst developing an application. (Opening a registry key, for reading, using the ALL_ACCESS flag, or requiring read / Write / modify rights to a file if it only needs to be read from.
2. Taking into account that more than one person may use a machine to work with.
There are various other things, and like I said, it deserves an article, which I would love to write given the time...
mfg
Phil
Who the f*** is General Failure, and why is he reading my harddisk?
|
|
|
|
|
Agree - trying to install into some of the "tied down" environments is a nightmare with many installers.
I was trying to do a "simple" task - create a folder on a C:\ drive that had full rights set for any user on the machine. It may be my lack of knowledge, but no basic installer I had available seemed to provide that sort functionality.
I can make any PC 100% secure in seconds, it involves a pick axe through the hard drive
|
|
|
|
|
Could the survey also report how many people recommend one of the installers that they use?
-Steve
|
|
|
|
|
Well in the first question (which I believe multiple answers were ok ) I selected only one although I have tried a lot of the choices and I have used 4 of them in the past.
John
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
![Badger | [badger,badger,badger,badger...]](https://www.codeproject.com/script/Forums/Images/badger.gif)
![Rose | [Rose]](https://www.codeproject.com/script/Forums/Images/rose.gif)
