|
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...
|
|
|
|
|
I suggest you rewrite your installation script to NSIS and use the NSIS installation system instead. We used InstallShield at our company from 1995 to today and I can tell that InstallShield is a very slow system that gives you a lot of nerves and gray hair! Things are somehow very complicated in InstallShield and you can never really trust it. In other words, you cannot be sure on what's happening while performing the installation.
I might add that the InstallShield version I'm talking about is the Dev Edition 9.0. Very big, very slow, too complicated and requires to much memory.
Nowadays, we use NSIS for all our installations and I can tell tell you that this is the best thing that happend to us.
|
|
|
|
|
I'll second that one. I used InstallShield for a fairly complex installation problem, and found more bugs than I have ever seen in a product. Nerves, gray hair and a hell of a lot of anger at the company that subjected me to it. With any complex product, there will be difficulties and pitfalls, but when 80% of the problems you encounter turning out to be a result of bugs they haven't acknowledged, it starts to piss you off. I ended up using it almost exclusively for installing the files and wrote a configuration utility that launched after it finished that did all the heavy lifting. You just couldn't trust it.
I will never use that product again. It boggles the mind that they have been able to stay in business.
Tom Clement
Apptero, Inc.
P.S. Ask me how I really feel.
|
|
|
|
|
|
We are using the nastyness that is InstallShield. 
Install is the worst and least-rewarding type of dev work. It's no fun, and if you make any little mistakes it can make the whole thing blow up in spectacular fashion, possibly taking out some system files with the splash damage.
--Mike--
Personal stuff:: Ericahist | Homepage
Shareware stuff:: 1ClickPicGrabber | RightClick-Encrypt
CP stuff:: CP SearchBar v2.0.2 | C++ Forum FAQ
You cannot stop me with paramecium alone!
|
|
|
|
|
Michael Dunn wrote:
We are using the nastyness that is InstallShield
A (happily) decreasing amount of stuff here is done through the VB Package And Deployment Wizard (yes, I put that in) - the most brain dead install software I've ever used.
I managed to persuade the boss (after fighting the wizard for a day, as it kept totally f***ing up the dependencies of this large project) that the Visual Studio .NET installer tools were at least usable, and I'd get the installer for this large project done in something less than a day and the loss of my not inconsiderable amount of hair
Ian Darling
"The trouble with the world is that the stupid are cocksure and the intelligent are full of doubt." - Bertrand Russell
|
|
|
|
|
But if you do it well, you have great job security.
Nope, I'm not the installer guy, but I bet the guy who is would NOT be the first one they let go in lean times.
|
|
|
|
|
I am the install guy and I really like InstallShield.
|
|
|
|
|
Wrong --- my last development position was managing the installation for a cross-platform JAVA/GUI App. 'Cause I did it so well (after developing it, I integrated the whole package generation into the regular daily build), they figured they didn't need my services anymore. I was the first lay-off....
My advice for installation developers: don't quit your day job 
|
|
|
|
|
That said, I do not understand why people do not apply more effort to the task of building the distribution units. It is the customer’s first experience with a product. If the installation facility falls to its knees, what is the perception of the rest of the product?
Michael Dunn wrote:
Install is the worst and least-rewarding type of dev work. It's no fun, ...
I can see what you mean. Consider that the installation developer has the opportunity to see which “macro” strategies really do make the product easy to maintain, support, and deploy.
Michael Dunn wrote:
... blow up in spectacular fashion, possibly taking out some system files ...
Take a look at Windows File Protection and the Windows Installer Service. These two facilities on modern Windows systems have made resource contention a thing of the past. Windows File Protection covers the most common case where this can occur. Further, you might be impressed with the transacted state and file versioning rules of Windows Installer to cover the other side of the coin.
Michael Dunn wrote:
using the nastyness that is InstallShield
I feel the same way sometimes. Then again, I feel the same way about my compiler now and again. It always seems to comes back to the usage of the tool.
I like the adage "Use the tool, don't trust the tool." Meaning, know what your tool does and how it does it, before you use it. Trust me; if you had to do it everyday, you would want InstallShield.
"A good plan is short on vision and long on detail." - Lou Gerstner
|
|
|
|
|
Ed Preston wrote:
That said, I do not understand why people do not apply more effort to the task of building the distribution units. It is the customer’s first experience with a product. If the installation facility falls to its knees, what is the perception of the rest of the product?
I couldn't agree more. I'll go one further and say that the old model of having a "Installer Developer" (that poor sap that has to deal with all of the dependencies at the last minute) is obsolete.
On the project I'm working on, we've architected things such that each "logical package" has a VS.NET solution with all of the assembly projects as well as a merge module project. The enigneer(s) responsible for developing a package are also responsible for managing its deployment.
Creating the installer is just a little bit of GUI sugar on top of a collection of merge modules. Breaking the installer now has the same conotation as breaking the build: the engineer who did it is responsible for fixing it.
This has worked really well for us (Plus since I've often been the poor sap who develops the installer, makes me a much happier camper).
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
