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.
Related
I need to investigate the installation of a product that consists out of several setup.exe files, MSI installers and related prerequisites. My thoughts are; I perform the installation manually and another piece of software monitors and logs what is installed and when it is installed. So I can figure out the sequence the software is installed so I can package it.
Deployment / Installation: The better way to do this would be to install the MSI files in the correct sequence once you have extracted them all from the setup.exe files. You can then install all required components via a distribution system, or even just via a batch file.
Even without extraction you can install the different components via a batch file or a distribution system such as SCCM - if you figure out what switches to use for the setup.exe to run them reliably in silent mode (which is not always that easy - and sometimes impossible, and generally always somewhat unreliable - which is why we tend to convert legacy setup.exe files to MSI format - or App-V). Check this answer for a description of how to run various setup.exe files in silent mode (towards bottom). They are not created the same, and they support very different switches depending on what tools they were made with (WiX Burn, Installshield, Wise, Advanced Installer, PACE Suite, Wise, Inno Setup, NSIS, etc... See more on these tools below). MSI tools (includes the free, open source WiX toolkit). Non-MSI tools.
To get a rough idea of what has been installed by running your deployment operation, you could check the list of installed product in Add / Remove Programs before and after installation. Products can be installed without showing up here - which I am sure you are aware of. Working out the exact details can take quite a while. You can also check event logs and see what new shortcuts were created on the start menu, if any. You can also compare the disks (installation folders) of a clean and a deployed virtual machine. There are many tricks and ways to get an idea of what was installed. The best is often to run in interactive mode and see what each installation screen tells you about what is being installed. Also look for documentation embedded in the setups or in installation folders after installation.
Overall - if you ask me - I would say: Get on the phone and call the software vendor and ask for their documentation on the deployment of their software. They should be able to provide both documentation, examples and basic help on what is necessary to run their software solution. And the good, real-world advice that they just didn't get time to add to their documentation - or was acquired after it was written. The real solutions. If they can't, why not question the whole software solution? I have wanted to throw out dysfunctional software many times, based on their poor deployment strategies. A massive cost for clients to deal with, and sometimes impossible to fix in reliable ways.
Extract Setup.exe: I have an "organically evolved" answer here on the issue of setup.exe extraction - in other words getting the MSI files (if any) out of the wrapper setup.exe files. When I say organic, I mean that the answer has been updated so many times that it has become a structured mess, but it is still OK information if you take the time to read it (I think): Extract MSI from EXE.
Capture / Repackaging: It is possible to "capture" the installation of legacy setup.exe files and convert them to MSI format, or App-V which many corporations use as their deployment format these days. They usually use repackaging tools (list from installsite.org) to do this, and they are available as commercial tools like AdminStudio (from Installshield now Flexera), Advanced Installer Architect, PACE Suite, etc... There used to be several free capture tools out there, but they tend to disappear over time as they don't get maintained. MSI files should generally not be repackaged - it is very ill-advised to try to do so - they are almost always possible to run reliably in silent mode, barring a few relatively common design flaws (that can usually be resolved with acceptable efforts by trained packagers). If your organization uses App-V, though, then this is often what they do - repackage MSI installations - and other types of installations.
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.
We've got an EXE which works great for installing our application. However, we have multiple customers who are requesting an MSI for ease of deployment in their current domain.
If we use our existing EXE install process, can we wrap that into an MSI and expect good results? The EXE creates an "Uninstall" that is added to the control panel's uninstall list... will the MSI also generate an uninstall point, leaving us with two entries?
Is there anything else I should watch for?
Thanks
Your customers are probably asking for MSIs so they can manipulate the MSI with the variety of tools that work only on MSIs. For example, there are deployment tools that are able to look at MSIs and only send down the changed files to a system when it gets a new version of the MSI. These work off the file table in the MSI. If you wrap your exe in a MSI, the only file in your MSI file table is the exe, which makes tools used to manipulate the files you are installing, useless.
An EXE setup file can be anything, including an MSI in a setup.exe launcher. However, in your case I don't believe that is the case. You probably have a legacy non-MSI installer.
Most big companies actually take older, legacy-style setups and repackage them as MSI themselves - whole teams exist to do this job (as mentioned by Linda). This is to benefit from a substantial number of MSI benefits for corporate use that are crucial for large scale deployment (the administration of software for many computers). See the same link for common problems with MSI files - it is definitely not an easy technology to deal with.
Wrapping your existing EXE in an MSI is not an option. This adds nothing but risk and complexity for no gain at all. In fact you will irritate application packagers in large companies by making it harder to repackage the right way.
Remaking your setup to be an MSI file is a good investment if you use good consultants to do it, or take the time to train your developers to do it right. MSI is an unusual technology, and distinctively unorthodox to deal with. Many developers feel it is impossible to understand, and for good reason. It is an entirely different installation paradigm than what used to be.
The latest and greatest for MSI is the Wix toolkit. A free open-source toolkit allowing you to create full-fledged MSI files without any expensive third-party tools. This short summary of its history and creation might be helpful to understand what MSI is about as well.
I guess the overall summary is that wrapping your software in an MSI file is no small investement with regards to the work involved, but it has major benefits when done right.
Wrapping your existing EXE inside an MSI has no value at all - it just causes new problems.
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 7 years ago.
Improve this question
I recently had to struggle with one installation project (which uses most popular product for creating installations: InstallShield) to make it work for product upgrades (migrating from one version to another). In the end it turned out that I needed to use one long package code but was using some other. It wasted my 8 hours (testing and debugging installers is a pain).
Now if I think about it, once you are done all the hard part of coding, all you want to is that correct applications, libraries are copied to target computer and user just runs it. Period. This apparently simple task normally turns out to be a tricky one and "being closed to finish date" makes in even harder.
Don't you think deploying a product is made damn difficult on windows which should have been simpler? (or installer really deserves that much attention and I am just being crazy about it?)
Have you ever used simpler deployment schemes such as "copy the folder to wherever you like and run the exe. When you want to remove it, just delete the folder!"? Was it effective and made things simpler?
Painful as it is you need to wrestle with the windows installer for the benefit of your customers. Otherwise you will need to do a lot more work to
Handle situations where for some reason an error occurs during the installation. What do you do next?
Handle issues like security. What if the installing user does not have rights to particular folders/registry keys?
Correctly cleanup after installation
Patching and patch management
Performing additional tasks -- registering COM objects, creating databases, creating shortcuts, creating an un-installation shotcut and so on
Installing prerequisites
Letting users choose which features to install
Your own custom scripts to solve all these problems eventually become a bigger problem than the installation itself!
I recommend that you check out Wix. It's not exactly child's play but it gets the job done. If you install Votive as a visual studio add in you get intellisense to help you strucutre the tags correctly. With the help file you can create pretty functional flexible installations
I don't think you'll see too many disagreements here, especially regarding MSI. I think one thing to keep in mind is to watch the way many programs are using MSI files these days. Displaying UI dialogs and making complex configuration choices with an MSI is very weak simply due to the way Windows Installer was designed, so I've noticed a lot of programs being split into a bunch of baby MSIs that are installed with the minimal UI by a parent setup program. The SQL Server 2008 setup wizard does this. UPS WorldShip does this. And Paint.NET does this, too--the wizard you see is a Windows Forms app, and it launches msiexec itself (you can see the minimal UI of the Windows Installer pop up on top of the white wizard window), passing any configuration parameters as property arguments to msiexec.
A common scenario where this comes up is where someone is tasked with building an installer for an application that has both server and client counterparts. If the user chooses the server option, then they may or may not want a new database to be installed, which means installing SQL Server. But you can't just install SQL Server while you're in the middle of your own installation because Windows Installer won't let you do that. So a frequent solution is to write an app that displays a wizard that allows the user to configure all of the setup options, and then your app launches the MSI files as needed for SQL Server, your server application, and your client application in the minimal UI mode; basically, eschewing the "features" aspect of Windows Installer entirely and moving it up to the MSI level. 4.5's multiple-package installations seems to be a step further in this direction. This format is also especially useful if you also need to loop in non-MSI installers from third parties as part of your installation process, like installing a printer driver for some bizarre point of sale printer.
I'll also agree that Windows Installer lacks built-in support for common deployment scenarios. It's meant for when setup isn't XCOPY, but they seem to miss the fact that setup usually isn't just "files + shortcuts + registry keys," either. There are no built-in actions for setting up IIS Web sites, registering certificates, creating and updating databases, adding assemblies to the GAC, and so on. I guess they take the opinion that some of this should happen on first run rather than being a transactional part of the install. The freely available tooling and documentation has been awful--flat out awful--for the better part of a decade. Both of these issues are largely addressed by the WiX project and DTF (which lets you finally use managed code custom actions), which is why we're all so grateful to Rob Mensching and others' work on that project.
I've had the same experience. Installation can quickly suck up your time as you go down the rabbit hole of "Oh God, I guess I have to become an expert in this too." I second the idea that's it's best to address it early on in your project and keep it maintained as part of your build process. This way, you can help avoid that scenario of having developed a practically uninstallable product. (Trac was an example of this for a while, requiring to track down specific versions of weird Python libraries.)
(I could go on about how Windows Installer sometimes decides to use my slow, external USB hard drive as a place to decompress its files, how it seems to sit there doing nothing for minutes on end on computers that have had lots of MSI installs on them, and how that progress bar resetting itself a bazillion times during a single install is the most idiotic thing I have ever seen, but I'll save those rants for another day. =)
My two cents; please note that I really just know enough about Windows Installer to do damage, but this is my assessment coming from a small business developer just trying to use it. Good luck!
Well, its a lot easier if you build your installer first, make it part of your build system, and let it grow with your project.
I agree, the windows installer drives me insane. But there are a lot of situations that xcopy just doesn't solve. Sometimes you want to install for multiple users, not just the current user. Sometimes you have to register COM objects. Sometimes you have to make a whole bunch of changes to the system, such as registering services to run at startup, connecting to network servers, etc. Sometimes you have users that can't use a command prompt. And you always want to be able to role the whole thing back when something fails halfway through.
Was the whole MSI database approach the best way of doing it? I'm not sure. Would I rather pound nails into my head than write another line of WiX code? Probably. But you have to admit, it does a good job of doing everything you could ever possibly want. And when it doesn't there is always the CustomAction option.
Really, what I would like to see, is better documentation (really, what is a type 50 action? How about giving it a name?) and a lot more easy-to-usurp templates.
And the WiX users group alias does a good job of answering questions.
You should read RobMen's blog. He does a good job explaining why things are the way they are. He has done a lot of thinking (more than any human should) about the problems of setup.
Have you looked at NSIS: http://en.wikipedia.org/wiki/Nullsoft_Scriptable_Install_System ?
And 1: Yes, 2: No
Personally, I mostly agree with #Conrad and #John Saunders. I wrote about this topic a long time ago on my old blog. I think #jeffamaphone has a point about the Windows Installer complexity (and my over attention to setup, in general ) but I believe the Windows Installer is still the best all round option for installation on Windows.
"Once you have done all the hard part of coding", you haven't done a thing if all your hard work doesn't install. Installers need to be built and tested on every nightly build, every night, almost from day one. You need to test that the installer can be built and run, and you need to verify the installation.
Otherwise, who cares how much hard work you've done coding - nobody will ever see your work if it doesn't install!
Note that this also applies to XCOPY.
Another thing: what is your QA testing if they're not testing what your installer installs? You have to test what the customer will get!
For exactly the reasons you state, we've done internal releases, handled by the dev team by copying the required files, and then done the rest of the setup using scripts and our own utilities.
However, for end users you have to have some kind of hand holding wizard, I've used the MS installer from within VS and found it confusing and clunky. After that experience I've avoided the pain by getting others to do the installation step. Can anyone recommend a good .Net installer?
I use Installshield and if you are not trying to do anything too fancy (I why would you) then it's pretty straighforward - set initial setting, select files, set up shortcuts and create setup.exe.
All future updates I handle inside my code - much more convinient to the user
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 9 years ago.
Improve this question
I have been evaluating the wide range of installation and web deployment solutions available for Windows applications. I will just clarify here (without too much detail, these tools have been covered in other questions) my understanding of the options:
NSIS - Free tool that generates setup executables. Small binary. Specialized, sometimes obtuse, scripting language.
Inno Setup - Free tools for setup executables. Various binary compression schemes. Pascal scripting engine.
WIX - Free toolset to generate MSI binaries. XML definitions language.
WIX ClickThrough - Additional tools for packaging, web download and auto update detection (now part of WIX core).
InstallShield - Commercial development environment for installation packaging. Generates MSI binaries. C-like InstallScript language.
Wise - Commercial development environment for installation packaging. Generates MSI binaries.
ClickOnce - Visual Studio supported framework for publishing applications to a webserver, with automatic detection of updates. No support for custom installation requirements (INI files, registry etc ...). Packages setup as an MSI binary.
Install Aware - Commercial development environment for installation. Generates MSI binaries. Automatic Update framework (Web Update).
If I have missed any, please let me know.
And found some useful discussions of these technologies on StackOverflow:
Best Simple Install System
Best choice for Windows installers
Alternatives to ClickOnce
I have worked with a few of these solutions, as well as a handful of proprietary internal installation solutions. They are mostly concerned with packing installations and providing a framework for developers to access the run time environment. With the growing requirement for web deployment and automatic software updates, I expected to find more of a consensus among developers on a framework for web delivery of software and subsequent updates, I haven't really found that consensus. There are certainly solutions available (ClickOnce, ClickThrough, InstallShield Update Service), but they each have considerable limitations (please correct me if I mis-represent any of these). I would be interested in a framework that provided some of the following:
Third party hosting/management of updates.
Access to client environment (INI files, registry, etc..).
User registration/activation.
Feedback/Error reporting
This is leaving me with the strong impression that the best way to approach the web deployment problem is through a custom built proprietary solution (possibly leveraging existing installer packaging). I have seen this sort of solution work well for a number of successful applications:
FileZilla - HTTP request to update.filezilla-project.org to check for updates, downloads an NSIS binary (I think) and then shuts down to run the install.
Automatic updates for Massively Multiplayer games are entirely necessary and universally implemented using proprietary systems.
So, at last, to my questions:
Have I missed a web deployment framework that will provide the functionality I need?
Are my requirements too specific to reasonably expect a third party framework to deliver?
Should I buy or build?
I would urge caution on Installaware. We recently had a shocking experience with their customer support.
We followed one of their sample projects to the letter which failed miserably. Raised a support ticket with customer support and were told it was going to cost us $199 for them to look at fixing their own code.
We then raised the same issue in the user forums and were promptly banned because this constituted cross posting and was not allowed. Even though this is not mentioned in their terms and conditions. In fact, they banned our IP so no one in our company can post to the forums.
A very poor experience and one we wont repeat. We are now looking to replace Installaware as soon as possible.
Purchase Installaware at your own peril.
Absolutely agree with poster who said to stay away from InstallAware. They've had a long history of really absurd ethics problems, and they treat their own customers horribly. They can be downright abusive and insulting.
Beware InstallAware!
I completely agree about InstallAware.
After using WiX, NSIS and InstallAware, I have to humbly admit that they were all overkill for what I really need as a software developer. There are no projects that I've done so far which couldn't be deployed using the Visual Studio deployment project.
Is it limited? Yes.
It is also very simple to learn an use. Moreover, you actually can do really neat things like automatically create patches (.MSP files) by using techniques as described here
I fully understand that you can't do everything inside of a Visual Studio setup project, but it's rather surprising what you can accomplish. It's free, it's easy and, frankly, for general use is a better option than spending endless hours learning WiX's mind-boggling XML (impressive as it is), or InstallAware's verbose scripts...
With VS Setup, it's drag'n'drop & build'n'deploy. Every other solution I've tried had set backs... they can't automatically detect your project output... or need special filters so as not to include unwanted outputs from the build.
My suggestion is thus: If you simply wish to get your project deployed, then learn:
How to build a custom installer class, and
How to author your own pre-requisite packages
These are both reasonably easy skills to master, and satisfy the needs of most developers.
If your specific requirements are core to your business; ie part of your business is to provide a smooth and user-friendly deployment/installation and you feel that none of the available deployment libraries can let you achieve this, then certainly go ahead and build your own.
If your specific requirements would be nice to have but they do not make a significant part of your business; ie the end user will not typically be expecting or needing a smooth installation procedure, or will never need to do that themselves (ie they pass that step onto their IT department), then the need to build your own just for your own specific requirements is likely to be outweighed by the extra effort that would involve.
I think that your impression that you will be needing a custom solution is a sound one; it seems like your requirements are going to be key to the experience of your product, especially if you need really smooth automatic updates and feedback.