Need to create a Installation Package that would need to
a) install a Database,
b) create database and tables,
c) installed already created installable in Visual Studio,
d) create ODBC datasource,
e) copy files.
f) create shortcuts, etc
Can you please suggestion which one to use? To simplify following would be my criteria(Descending Order)
Stable
Fullfill all my needs.
Easy to learn
Can you please suggest?
If you want to use WiX, you need at least a basic understanding of how Windows Installer works. The best reference around is The Definitive Guide to Windows Installer, which runs through the all basics with examples using Visual Studio and Orca.
WiX is very easy to learn once you understand Windows Installer.
A properly written Windows Installer package will be more stable and resilient than anything else you can imagine. It'll take a month or so to get your head around it, and you'll get better and learn more about it over time.
On the other hand, NSIS only takes a day to learn - it's just a simple scripting language.
#wcoenen - I'd agree that you definitely will learn more by reading various blogs of those on the WiX team, but I personally find that particular book gives a really solid foundation which makes it easier to understand the concepts they're talking about.
#Sandeep - You need an MSI package for corporate software, if you have no intention of selling your product to customers who need automated deployment in a locked down environment then NSIS will suit you just fine :)
#romkyns InnoSetup is fairly limited in my opinion, you can do just as much with a batch file and a self extracting EXE - it all comes down to your target market, corporate/enterprise clients demand MSI - home users don't care as long as it works and would happily double click on a SETUP.BAT file :)
I would like to suggest another installer which is InnoSetup combined with ISTools
Innosetup has very good scripting language, and has a wizard to make it easy for you do the installation package and ISTools have the GUI interface for most of Innosetup options,
I was able to Install Mysql, its service and creating tables and other things with it, and it's much easier to learn than others.
It depends on what you are trying to install. If it is a simple application installation, then NSIS is fast and easy to implement (wix has a very bad documentation).
But if your installer does some changes in Windows OS, like, creating restore point, installing kmdf or umdf driver, then WIX is much better than NSIS.
Related
What is the best tool to create an installer for asp.net application? My objectives are to:
Install an asp.net application on iisexpress
Install sqlexpress (as a prerequisite)
Configure IIS for my application
Restore data on sqlserver
Either will do the trick, so it comes down to what your needs are, and how they stack up against each other
InstallShield
Will guide you through the process a lot more than WiX, and so will get you off the ground quicker
Has built in functionality for talking to IIS, SQL and a bunch of other sources
Has built in functionality for installing a number of prerequisites, such as .NET. I believe installing sqlexpress as a prereq is supported.
Can target InstallScript, MSI, or a mix of the two
WiX
Is free & open source.
Is much more flexible in how you organise your code. It uses XML like InstallShield, but unlike InstallShield you have pretty much complete control over how the code is organised, and it's generally much easier to compare and merge the code in your source control system.
Is very extensible - you can hook into the compiler mechanism through WixExtensions
Has functionality for talking to IIS and SQL via custom actions and syntax extensions
Comes with Burn, a flexible and powerful bootstrapper, install chainer, and install host. This can handle your prerequisite installation for you, and even host your UI.
Conclusion
Personally, I recommend learning WiX - the code is easier to manage for large projects over time, and you are less likely to reach that brick wall where stuff just can't be done because of how extensible it is.
However, it will take you longer to get off the ground because you have to actually understand what's going on to a greater degree than with InstallShield.
I am currently migrating projects from various versions of InstallShield to Wix. You need to put more effort into Wix, but it is worth it in the long run. The problems I have found with InstallShield is it is relative expensive to license, and once you start using it you become hooked into paying out more money to upgrade it or get the latest version, because the person who used it last is no longer around, license keys have gone astray, there are not enough license keys anyway, a license key that used to work no longer does for some strange reason...etc, etc. Without a up-to-date and functioning license key InstallShield will not work.
Because an installation project is not something we use all the time, but when we do use it we need it to work, I have decided to junk InstallShield for something more reliable (in terms of licensing).
We have written a bunch of Java code and need to package this code in MSI so that we can deploy on user's Windows machines.
The MSI should:
Install our class files at appropriate location
It should also add a task in Windows task scheduler
I was looking at http://www.advancedinstaller.com/. It seems to be the perfect tool for my case, except it's not free to add the scheduled tasks in the MSI. I will have to buy their license to use that feature, which doesn't fit into our scheme of things.
http://nsis.sourceforge.net is free and looks good but has a steep learning curve.
How do people normally achieve this? Obviously not everybody will be buying this tool. What are the other options? Are there any other such free/open source tools?.
I believe the Advanced Installer guys are known to offer discounts for such cases, try contacting them by email.
Regarding NSIS, it depends on how much effort you're willing to put in the maintenance.
From the same category, there's also WiX. Also steep learning curve.
Installer kits are usually something you edit once a month or once every new version of your product. I find that in between those periods I tend to forget stuff, so having an intuitive and easy to use editor definitely helps, and free tools aren't really known for that.
One benefit of NSIS is that is has a wiki that covers most of the basic and some advanced topics needed for the language. It is quite powerful, but EddieBytes is correct about the learning curve.
I started using it for my package and application installation needs a while back. It took a little bit to get moving, but once I did it became my preference.
Here's the NSIS wiki
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I'm comparing these two tools. The impression I have is:
Inno Setup does not produce an MSI, but can do everything WIX can do
WIX does produce an MSI, but has a steep learning curve
Do you agree with this characterization? What other differences are there? How does WIX# shake-up this story? Since Inno Setup does not use the windows installer, does it have difficulty with uninstalls? Can Inno Setup, upon command, downgrade an installation to an earlier version - or can it only install / upgrade applications?
It's been a long time since I worked with MSI, when I switched to InnoSetup I never looked back.
I did not want my installation to be a headache. I needed something where I could "Set it and forget it"
By default InnoSetup produces an uninstall.
It can handle simple or complex install and uninstall needs.
With InnoSetup You have a few different ways you can upgrade applications.
Initially we did use the overwrite method which just overwrote the existing installation.
Recently we switched an automatic uninstall of the previous version when new version was installed.
With InnoSetup downgrades are typically uninstall and reinstall the older version.
You are right about the MSI not MSI part and you are right that learning curve of MSI is steeper. But both have features others don't. Let me quote Glytzhkof on the advantages of MSI.
Glytzhkof says hi ;-). Please do read both my original answers on serverfault.com for a summary of common problems with MSI resulting from its steep learning curve. This answer here focuses on the theoretical benefits, the other answer (in the same thread) summarizes common MSI problems off the top of my head. Additions there are most welcome - I just added the most common issues.
Transparency (Open installer format)- An MSI can be reviewed and
inspected. This is a huge issue for
large corporations. With the exception
of compiled custom actions an MSI file
is a "white box". If the setup changes
something crazy such as the
system-wide network settings, you can
actually see it.
Customizability - An MSI can be customized via transforms to fit an
organization's needs and standards
whilst still allowing interoperability
with the vendor's installer updates.
You don't change the installer itself,
you create your customization in a
separate, organization-specific file
called the transform. You are free to
disable custom actions and in general
anything in the installer, and "black
box" custom actions can be approved by
contacting the vendor for explanation.
These transform files are also
sometimes used to localize an MSI file
to different languages. Several
transforms can be applied to a single
MSI.
Standardization - MSI does not lend itself to "allowing anything". It
provides a comprehensive framework for
the installer, which crucially also
includes the uninstall - all in
standard format. The installer GUI is
also standardized with built-in
features to support silent
installation and uninstallation which
can be triggered remotely.
Management and reporting - Windows Installer maintains a
comprehensive database of all items a
product has installed. You can
reliably determine if a product is
installed, what features were
installed, and what file versions were
installed. In addition you can get a
list of any patches that have been
applied to the base product, if any.
Security - following from the comprehensive installation database it
is possible to detect security
vulnerabilities in the installed
products. MSI also encompasses
"elevated rights" principles which allows a restricted user to trigger
the install of a product that requires
admin privileges to install. This is
part of the "advertisement feature"
which allows an administrator to make
installers available to users without
actually installing them on all
workstations. There is no need to mess
with temporary rights to get things
working.
Validation - MSI files can be checked with validation rules to
ensure it is in compliance with a
number of internal consistency rules
(referred to as ICE). Corporations can
create their own ICE checks to enforce
special corporate rules and
requirements. This helps greatly with
QA.
Resiliency - The Admin install feature of Windows installer
provides a standard way to extract the
source files from an MSI. These source
files can then be put on a share and
be available to all workstations for
installation. This ensures repair,
uninstall and modify operations
complete without requesting the
installation media on CD or similar.
This is particularly important for
patching and update operations which
may require access to the old versions
source files in special circumstances.
Rollback - The installation of an MSI file will normally trigger the
creation of a restore point.
Furthermore all files and registry
items replaced or overwritten during
the installation will be saved and
restored if the install fails to
complete. This ensure that the
workstation is left in a stable state
even if the install should fail. As
you might expect poorly designed MSI
files can violate the built-in
features of Windows here, see my other
post in this thread for more details.
Patching & Updates - though highly complex patching in Windows
installer is fully managed and
registered on the system so that a
systems security state can be
determined by checking what has been
installed. Updates are standardized to
a few basic variants, and this allows
updates to be performed with a higher
degree of certainty. Deployment
systems will be able to report what
updates failed and why.
Logging - Windows Installer provides a standardized logging
feature which is greatly superior to
previous incarnations, though almost
excessively verbose. Log files can be
deciphered using log analyzers, and
custom log levels can be used to
eliminate generating too large log
files with unnecessary information.
For debugging purposes verbose logging
is extremely useful. See Rob Mensching's blog for a good manual way to read an MSI log file.
I'm late to responding to this thread. I have used Inno Setup for my company's product for years. It does most things very well but the biggest hurdle for me is custom actions. In Inno Setup, one must use a variant of the Pascal language. With the WiX Toolset, I can and do use C# for my custom actions which is much more comfortable for me. Admittedly, that is a personal preference but it is the primary reason why I switched from an otherwise excellent Inno Setup platform to an also excellent WiX platform. That, and the fact that there were so many benefits from using MSIs which have already been mentioned in another response.
Frankly, for me, the learning curve of Pascal was greater than that of WiX using the book, WiX 3.6: A Developer's Guide to Windows Installer XML.
I realize this answer comes VERY late. But I ran into this post and figured one answer to the question could simply be: "Why not have both?" (eat cake and have it too) and also "Why expend the effort on implementing both when I could just expend the effort for one and get the second one for practically free?"
Toward that end, I present an Inno Setup script w/ MSI support:
https://github.com/cubiclesoft/php-app-server/blob/master/installers/win-innosetup/yourapp.iss
There are some custom Pascal functions in use here that kick in when passed /MSI={GUID} on the command-line that trigger useful changes to the script (e.g. no Uninstall icon in Start or Add/Remove Programs).
And I present a WiX script w/ support for the above Inno Setup script:
https://github.com/cubiclesoft/php-app-server/blob/master/installers/win-wix/yourapp.wxs
The WiX script wraps the Inno Setup-based installer EXE (the only payload) in a way that triggers the Inno Setup script to do things in a more MSI-compatible way and cranks out the MSI. It isn't perfect, but it saves a ton of time by letting you do things the Inno Setup way and then get most of the benefits of MSI (e.g. GPO/SCCM/DSC silent deployment) without pulling hair. This works best if mostly just deploying files to the system and a handful of registry entries (i.e. a basic app). I wouldn't recommend this approach for a larger application where there are lots and lots of components, but if you try it and it works, let me know! Having a MSI version that launches the Inno Setup EXE at least gives sysadmins doing deployments something reasonable to chew on.
Note that the WiX script depends on the custom Pascal functions on the Inno Setup side of things. You can't just take any ol' Inno Setup installer and wrap it with the WiX script and expect it to work (it probably won't). But maybe a future version of Inno Setup will natively support something similar.
We integrated both into our build system.
But we decided to promote innosetup exe files for non business customers and msi only on demand for one simple reason.
You can't ship a multi-localized version of setup program with MSI. You would need one installer for every language and this sucks huge. There might be some heavy hacking allowing you to rewrite the whole GUI but this is not well documented and no open source to steal and a lot of work.
The GUI is infact tbe worst part on WiX which otherwise is technically superior to Innosetup.
With Innosetup it's easy to ship one exe in 5 languages. We already have 6 binaries [Free,Home,Pro - each 32/64bit] so the variant explosion would be just huge and if you market a japanese version with a japanese webpage and the first thing that comes up is an english only installation it is a bad impression.
The MSI for business users who need group policies etc. is english only and thats fine for business users.
I have to migrate our current software installation to be able to install in Windows 7.
It's a MFC application in Visual C++. The installation is not extremly complex but it does have some complexity. It has to detect if some other software is installed previously to launch the msi file and let the user install it if it's not. There is some merge modules and nested msi, some custom actions (in dlls, vbscript, etc.). And one of our requeriments is that a non-administrative user has to be able to install the software. And preferably without having to agree any message once the installation is launched.
I think that the way it is done right now is a bit of a mess and I would like not just migrating but making a refactoring to make things better. So I would like to have some recommendations, a website with best practices, some books (preferable something up-to-date with specific information about installations in Windows 7). Any kind of help will be appreciated.
By the way, we are using InstallShield right now but I wouldn't mind to change to a better tool if there is any.
has anyboy used InstallShield LE for Visual Studio 2010? It's worthy to give it a try?
Thanks,
Javier
NSIS installer has plenty of features, including what you mentioned.
I don't think there's a book that deals with only installation for Windows 7. Although there are article on how to write Setup.
It's best to start with Microsoft User Experience Guidelines for Setup:
Users don't enjoy installing software, so modern setup experiences need to be simple, efficient, and problem-free.
If you do only three things...
Make setup as simple and lightweight as possible. Remember that users don't enjoy setup, they endure it. Look carefully at every question, option, page, and path, and trim away everything that isn't essential to completing setup.
Design for all setup scenarios, including unattended installations, scripted installations, and uninstall. For efficient unattended installations, make sure there is a clean separation between the setup phases.
Design your setup program so that users can resolve setup problems on their own, but also log the information needed for technical support just in case. Keep in mind that setup is the one task that all users must complete successfully.
Guidelines for the First Experience, that is the first of an application, are also worth reading.
An older article Redesign Your Application's Installer talks about the separating executable files and data, both per-user and per-machine, about the shared components, etc.
In your case, since the setup needs to detect and install additional components if they're missing, it's better to use a setup bootstrapper.
You have two options:
Elevate with the bootstrapper then run the complete setup elevated.
Elevate only when you need to install the additional components, the prerequisites of your application.
The second option applies only when your application can be installed by standard users, i.e. per user installation as opposed to per machine or all users. In this case, if the additional components require elevation to install, and if at least one of them is not installed, you start an elevated process to install all the prerequisites. When it completes, you continue the installation of your application as the standard user.
The point is to show UAC confirmation only once: it would be really annoying if each of the prerequisites show their own UAC confirmation.
Last year, in 2009 GSoC, I participated with an organization called Winlibre. The basic idea is having a project similar to Aptitude (or Apt-get) and a GUI like Synaptic but for Windows and just to hold (initially), only open source software. The project was just ok, we finished what we considered was a good starting point but unfortunately, due to different occupations of the developers, the project has been idle almost since GSoC finished. Now, I have some energy, time and interest to try to continue this development. The project was divided in 3 parts: A repository server (which i worked on, and which was going to store and serve packages and files), a package creator for developers, and the main app, which is apt-get and its GUI.
I have been thinking about the project, and the first question that came to my mind is.. actually is this project useful for developers and Windows users? Keep in mind that the idea is to solve dependencies problems, and install packages "cleanly". I'm not a Windows developer and just a casual user, so i really don't have a lot of experience on how things are handled there, but as far as I have seen, all installers handle those dependencies. Will windows developers be willing to switch from installers to a packages way of handling installations of Open source Software? Or it's just ok to create packages for already existing installers?
The packages concept is basically the same as .deb or .rpm files.
I still have some other questions, but basically i would like to make sure that it's useful in someway to users and Windows developers, and if developers would find this project interesting. If you have any questions, feedback, suggestions or criticisms, please don't hesitate posting them.
Thanks!!
be sure to research previous efforts on this. Google turns up several similar/relevant efforts.
http://en.wikipedia.org/wiki/Package_management_system#Microsoft_Windows
http://windows-get.sourceforge.net
http://pina.plasmite.com
IIRC there was an rpm for windows at some point
Also I think there was some guy (who used to work at MS) in the news recently that basically is starting up a very similar project. I can't find a link to this now.
But anyway, yeah, it would be awesome if there was such a standard tool and repository.
I can only speak for myself, but obviously I could definitely make use of such a tool as I found your post through googling! ;)
My two use cases for this tool would the following ones:
1. I generally avoid to re-install my system as long as possible (in fact I manage to do so only for switching to a reasonable (not each an every) new version of Windows every few years or to setup new computers). But still I'd like my software to be up-to-date. Neither do I want to have to go to all the web pages and check manually if there are compatibility issues with the new version of Doxygen, Graphviz and the latest version of MikTeX for example, nor do I want to have to navigate to the download pages and run the setups all by myself. I just want to schedule ONE SINGLE (!) tool, which checks whether there are new updates or not and updates those applications which are not in conflict with any other application version.
If it unavoidably happens to me that I have to re-install my system, I don't want to get the new setups neither (and check compatibility). I even don't want to wait for one setup to finish in order to start the next one, I just want to check the tools I need, or even better, I want to simply load my "WinApt XML" batch installation file, which gets the installers and handles the setups sequentially all by itself.
I don't know enough about the architecture of .deb or .rpm but IMHO the most reasonable would be to maintain a DB with only the names, versions, dependencies and the location of the different versions' download locations. I mean, most of the tools available for Windows provide .msi packages anyways, which (I guess) is the application itself and some custom installation properties (really not sure how scripting is handled, but I know that creating a MSI in Visual Studio has very limited abilities to create custom installation steps and I can only imagine this is due to limitations of MSI protocol).
I guess a GUI will be mandatory for Windows users ;) but I personally would prefer the additional ability to handle the setups with the console.
Well, I like the idea and would love to hear from that (or such a) tool in the future.
Cheers
Check out NSIS. It's an open source MSI creator. You might be able to use it as part of your package creation software.
http://nsis.sourceforge.net/Main_Page
For the ALT-.Net tool/lib stack there have been some affords in this direction: Horn Get
However, the usability in a real world project has been subject in this SO question.