|
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
|
|
|
|
|
I guess we're coming from different fundamental positions. I'll forgive your insinuation that I might be a VB developer as I nearly said the same about developers taking the "easy" option of InnoSetup or NSIS when any real C++ developer is bound to go for a hairy-chested MSI installer. ![Sheep | [baah]](https://www.codeproject.com/script/Forums/Images/sheep.gif) 
In my view, the benefits of MSI to the customer are so compelling that there is no excuse for not going pure MSI (I'd be prepared to accept that some driver installations might need to be excepted from that), so we're fundamentally not going to agree if you don't share that view.
That's not to say that I don't have criticisms of the Windows Installer service, InstallShield, and Microsoft's own failure to use and promote their standard as much as they might - I've even had a similar experience of things going wrong when I upgraded to DevStudio 9 - but the benefits of using MSI installers outweigh all of these. (I would be happy to criticise other tools such as Wise too, if I had any experience of them, but I refer to InstallShield and occasionally InnoSetup because those are the authoring tools I've used personally.)
Windows Installer is designed to enforce good installation behaviours which developers habitually ignore when using scripted installers, so it's bound to be a bit more exacting in its requirements of the developer - but then compiling with warning level 4, warnings set as errors and checking source code with Lint are more exacting than just hitting the build button and accepting it's good if it compiles. The fault is more likely to lie in your (or my) development work than in the tool - even though the tool may have faults of its own.
Add to that the installation functionality you (and your users) get almost for free - transactioned installs, application management through Active Directory, upgrades and optimised patches, repair installations, standard components installed (correctly!) by merge modules - and it doesn't seem to me that any scripted installer can match that power and flexibility.
That's before you consider the relatively high accessibility of a standards-compliant MSI installer to a sysadmin who might have to make modifications to respond to a local requirement that, as a developer, you couldn't predict.
The forthcoming MSI 3.0 looks like a significant improvement, with more flexible patching, including roll-backs, and speed improvements. It seems to me that now is not a good time to be jumping off the train!
If anyone knows about what makes a good installer, it's going to be the sysadmins who have to deal with them on a daily basis. I asked a few of my sysadmin friends for their opinions on this issue, and the least vehemently expressed opinion I got was along the lines of "yes, it's a no-brainer that MSI is the only way to go, but our organisation doesn't have the clout to insist that the clueless developers wise up".
Maybe we'll just have to agree to differ...
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.
|
|
|
|
|
I totally agree with you : as I only have to install small software (<5 MB) I also threw InstallShield and call it from nowadays "InstallShit" (sorry guys it's really not doing the right thing for me)...
I have to propose some custom screen and use as well the silent mode in some remote updates and... NSIS works terribly well
Finally I'd like to state that it needs some real coding knowledges, but fortunatly I got some 
And once you have your base script shape you go really fast and efficient in creating a new one...
Ray Duku
Il torche un max
|
|
|
|
|
Agreed. (though perhaps not in the same words)
I only install small software, and when a software project is only worth $3000, it's not really worth it to spend $999 on a peice of software you could get for free. InstallShield was simply overwhelming and couldn't perform all the functions I needed. NSIS works great, with the reasonably simple addition of custom setup pages and external DLL functions.
|
|
|
|
|
Gavin Greig wrote:
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.
It sounds appealing, but i'll have to take your word for it. The version of InstallShield still in use here predates the inclusion of MSI support, and (according to the IS guy here at least) has no such patch feature.
Gavin Greig wrote:
The only advantage I see left for NSIS is the price, which is usually not a large part of the final project cost.
A quick look over their site lists VBuild (which sounds like what you're describing) at $999. This isn't bad, providing we make that up in lowered distribution costs. The current project to steer customers toward downloading upgrades vs. recieving them on CD is still in its infancy - but if it works out, I'll definitly be recommending something like this (providing the current NSIS solution hasn't become completely painless that is). Thanks for the heads-up!
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.
|
|
|
|
|
I have no personal experience of VBuild, so can't recommend or otherwise, but good luck in finding a solution that works for you.
We've been using MSI for a couple of major releases now and we ship major releases on CD, so we can be confident that our customers have Windows Installer on their machine. Given that assumption, we have also gone with using the InstallShield Update Service for distributing downloadable updates, and it saved our butts last year when Microsoft put out an (acknowledged) buggy update that caused a high profile failure in our app. We were able to push out a coded workaround on a much shorter timescale than Microsoft were able to deliver a proper fix, and most of our customers never experienced the problem as a result.
I'm sure it would have been possible to develop something like that without paying out for third party products, but we're a small shop - we just don't have the time. For what it's worth, I have my criticisms of the update service too, but on the whole, it's still a big plus for us.
I'm sorry that won't help you out in the short term, as you won't have guaranteed presence of Windows Installer on your clients' machines, but it's worth thinking about.
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.
|
|
|
|
|
Joshua Quick wrote:
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).
Well InnoSetup alone might not be easier - together with ISTool, it's just as easy. What I *LIKE* about InnoSetup is that I have full access to it all - I can script, I can tweak, I can dig into the bowels if needed (hardly ever!), I can script special actions in PascalScript. Try that with MSI technology!
Phew.... I just never quite got the hang of MSI stuff - it just feels WAY TOO complicated for even the simplest installs. I did an install project in VS.NET, and it worked - at first. Suddenly, at some point, it just wouldn't compile anymore, and good luck trying to find the culprit there!!
I prefer InnoSetup by far - it's small, it's compact, it's friendly and easy to use, it's powerful, heck, I even get the Delphi source for it! MSI is a huge behemoth and hardly easy to get the full picture of - I can do tons of stuff - but that makes even the simplest installs a hassle..... just my 2 cents.
|
|
|
|
|
Because InstallShield is expensive and it is a royal pain in the arse to use. I have a batch file that automatically generates (using recursion and include / exclude filters) an innosetup script to add my applications along with the complete source so when I add a file to the application I do not have to make any changes to the install script and everything is done in the build phase.
John
|
|
|
|
|
Found Inno to be easy to use and with a good community of people working to improve it.
Inno Setup does allow MSI to be installed.
[Files]<br />
Source: "Your-MSI-File.msi"; DestDir: "{tmp}"<br />
<br />
[Run]<br />
Filename: "msiexec.exe"; Parameters: "/i ""{tmp}\Your-MSI-File.msi"""
|
|
|
|
|
Because it's so easy and has a very quick learning curve(10 minutes), unlike instal(blargh)shield.
Like NSIS, Inno is also free.
My history so far:
InstallShield (~2years)
Winrar exe's (really) (2 months, for quick fixes)
InnoSetup (-1 year)
Currently our next product will use NSIS, just because it has a nicer client GUI(my boss thinxs so )
Z
|
|
|
|
|
It's not only the GUI that is "nicer". You have much more possibilities and options in NSIS unlike Inno Setup. The problem (if you might think this is a problem) is that NSIS has a learning curve (more than 10 minutes) but when you got passed that you are free to write code almost exactly as you write code in C.
NSIS does not support DiscSpanning so if you plan having several installation files for your installation then Inno is "better".
|
|
|
|
|
Free, and easy to use. Also is nice an lightweight, and the fact that it does not need MSI2 or whatever makes things easier.
You should really give it a try. There are some nice thrird party tools that work really well with it such as a gui interface, which simplifies things like grabing ODBC and registry settings.
Personally, I use this over the version in VS.NET as for me its just easier to use. A monkey could use the script in it.
It can emulate the all the gui features of modern installers, e.g. selecting components and sub components to install or not install.
Did I mention it was free?
I use it for VB6, VC6, & VS.NET solutions. No problems.
|
|
|
|
|
So how do you handle and install your application's dependencies?
From what I've seen on InnoSetup's website FAQ, you have to figure it out and handle it yourself, which isn't nice.
The advantage of the Visual Studio Installer is that it automatically figures out and includes your project's dependencies into the MSI.
|
|
|
|
|
The advantage of the Visual Studio Installer is that it automatically figures out and includes your project's dependencies into the MSI.
I've seen you mention this a few times.
Not having used VSI, but having used MS tech for numerous years, I'm gonna guess how this works:
VSI will indeed determine dependencies, *until* your project gets complicated, beyond whatever basic ideas the VSI developers had in mind when they built it, at which point it will either then fail spectactularly, or in little subtle ways that you don't realize till you test the installer.
I've used Inno Setup alot, and don't mind at all that it doesn't track deps. I've never had that hard a time figuring this out. And, for common things, like the VB Runtime, the MFC runtime, Borldand's Database tools, etc, there are standard InnoSetup scripts prepared that you can just include in your app.
¡El diablo está en mis pantalones! ¡Mire, mire!
Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)!
SELECT * FROM User WHERE Clue > 0
0 rows returned
|
|
|
|
|
If you want to have easier access to the Win32 APIs and still want to use one of the freeware installation systems I suggest you look at NSIS.
NSIS is also fast and doesn't add so much overhead to your installation. The overhead is just ~35kb. Compared to Inno Setup you have more choices (except one thing: the diskspanning thing supported by Inno which does not exist in NSIS) but otherwise NSIS is much more powerfull than Inno.
NSIS supports plugins and for system calls there is one official plugin called System.dll. With this plugin, you can do whatever you'd like to do. You can allocate memory, create structures, call Win32 APIs and much more. You can even create windows and program in the same way as you program in C.
I might also add that it's a good idea if you use the "logiclib.nsh" which provides all the if/else/while ... statements.
Sincerelly, you should look at NSIS - just for curiosity if not for something else. If you have questions about it, try to send me an email - I might answer it if it's about NSIS  [paul.edfeldt@strusoft.com].
|
|
|
|
|
So, what's up with NSIS "Super PIMP" technology?
I personally find the name amusing, but my more conservative customers will likely take offense to it. (I noticed that the install creates a SuperPimp directory.)
|
|
|
|
|
Joshua Quick wrote:
So, what's up with NSIS "Super PIMP" technology?
As you probably also read, NSIS was developed by the people behind Winamp (the first versions of the installer anyway). NSIS was first designed to distribute the Winamp installation. However this was a long time ago and the name "Super PIMP" belongs to "history". Somehow the Winamp team wanted to be cool so they came up with this name...(and they are still cool! )
I understand that you find the name amusing, so did I when I first read about it. The first impression you might get when you see "Super PIMP" is probably that NSIS is not a serious system, only a joke - so why wasting time on using it?
I think both you and me agree on the fact that things are not always the way they seems to be. Personally I don't have any doubts about using NSIS and as a matter of fact we do use it for all our software distributions (almost, we are still porting…).
The only thing I can say is that I really like to work with it and I fully trust it. I might also add that previously we used InstallShield Dev 9.0. To redesign all your installations using a relatively unknown system like NSIS seems to be madness – but we don’t regret it.
/Paul
|
|
|
|
|
free !
easy to use !
very powerfull !
never got any troubles with it !
hum... doesn't require the msi installer stuff to work ?  
|
|
|
|
|
Since InnoSetup really ROCKS! We used it after months of struggling with InstallShield and Visual Studio Setups to deliver our component - PortSight Secure Access (http://www.PortSight.com/SecureAccess). It does what we expect it to do and it's without complication. Not saying it's free and continuosly updated...
Petr Palas
Product Manager
PortSight - Portals & .NET Components
http://www.PortSight.com
mailto:petrp@portsight.com
----------------------------------------------------------
Secure your .NET apps and integrate with Active Directory!
http://www.PortSight.com/SecureAccess
----------------------------------------------------------
|
|
|
|
|
I started using InnoSetup when I needed to deploy a VB package 2 years ago. The MS Package & deployment wizard setup kept rebooting certain machines, and didn't install.
It took me about a week (on and off) to get Inno to work the way I wanted it to. Now, there are tools to help take MS P&D projects and put them into Inno.
Also, there is pascal scripting. I wrote a PocketPC installer for Inno in 2 hours.
PLUS: I don't have to worry about MSI stuff!
The Support Newsgroups are great, and you have access to the developers, and it is free, even for commercial use.
|
|
|
|
|
An installation program gets written once in a while, and in-between those whiles, I pretty much forget all the tricks and workarounds and usage. I only remember that it's always a frustrating experience as I approach the end of a project and the dreaded "need to write the installer" task looms ominously on the "to do" horizon.
Marc
Microsoft MVP, Visual C#
|
|
|
|
|
hi all,
As I generate setup using Install-Shield that comes along with Visual Studio 6.0, There are so many files generated along with setup.exe.i.e All executables,some .cab
files etc.
I want ot know is it possible to generate single setup.exe file for installation,using same Install Shield version.
Waiting for reply...
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
