As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Heavy emphasis on simple. I've never made an installer and I'd rather not have to learn much. A system that I could hand a pile of files to and it would make some smart guesses about where to put them would be ideal.
Go ahead and answer the general question.
However In my cases I'm stuck with some extra constraints. The program to be installed is written in VB6 (or is it 5?) and a few previous versions of VB, so it's not going to be updated any time soon. I have a running install and will have a Clean VM to play with So I'll be doing a loop of: run the install, find where it's broken, fix it, add that to the installer, revert the VM, try again. If anyone has a better approach I'm open to suggestions.
I MUST get it working on XP and I'd really like to also have something that will work on newer versions of Windows as well.
InnoSetup or NSIS, whichever seems easier to you. ISTool is a nice GUI tool for InnoSetup which makes creating setup scripts even easier.
I've used InnoSetup several years ago, before Vista, and was very happy with it then. I only had a few files to install and a Start menu icon. It worked great, and was easy to learn.
Dependency Walker is super useful for finding out which dll is missing from the installer. Once you know the dll, you can find what merge module it is in using the Merge Module Finder.
I have worked with NSIS and getting past some of its minor complexities its a fantastic system. its free, offers tons of plugin ability and managed to do everything I needed to do.
Creating a full setup package for a program is almost a subject area in itself. There are many factors to consider and most of us aren't running Windows 95 anymore. The world is not as simple as it once was.
There are a lot of things that need to be addressed, and some of these "setup" issues mean changing the program too. For example the "protected folders" concept that seemed to be new to people when Vista UAC came on the scene. I guess they were all running as admin or something? In its simplest form it means you don't put writeable files next to the EXE in Programs (aka "Program Files") anymore.
Another factor is that the way the registry is used has changed. I'm not talking about registry virtualization, though that's part of it as well. But COM registration can be done both per-machine and per-user and even turning UAC off can muck this up. See Per-User COM Registrations and Elevated Processes with UAC on Windows Vista SP1. The result is that a setup package shouldn't be running regsvr32 (or otherwise calling the self-reg entrypoint of a COM library). See "Remarks" at SelfReg Table.
Windows Installer is the way to go forward in most cases. VB6 programmers have Visual Studio Installer 6.0 version 1.1 available as a free download for creating MSI packages. See "COM Servers" at the VFP article Using Microsoft Visual Studio Installer for Distributing Visual FoxPro 6.0 Applications for some valuable information.
This isn't the easiest option but there is a VB Setup Wizard in VSI 1.1 to help get the basics right. Doing advanced things like creating a [CommonAppData] subfolder and setting Everyone rights on it has to be done in a post-build step outside the IDE. That's where 3rd party tools can be useful to give you more control without resorting to Orca or post-build Installer scripts.
Those guys making scripted "legacy" installers try to keep up, but the scripting gets more and more complicated. The results are sometimes iffy. Windows 7 introduces a few new wrinkles of its own.
While ClickOnce isn't really the best option for VB6, nothing says you can't use reg-free COM for XCopy installs of many programs. Reg-free COM can even be a good option for use in an Installer package for that matter.
So in the end the "simplest" way to deploy VB6 programs is probably going to be reg-free COM XCopy packages wrapped in a self-extracting EXE that will fire off a script to create a Start Menu shortcut. If you can live without the shortcut this is even easier: just unzip the package where it needs to go!
See Make My Manifest or alternative tools for reg-free COM packaging.
This requires that the target systems be running XP (preferably SP2) or later. The only possible glitch here is that XP did not include the VB6 SP6 runtimes until XP SP3, so you'll want to test your program against the VB6 SP5 runtimes first. Well one more glitch: you can't use ActiveX EXEs this way, they still require registration.
My advice is this. Try to keep the installer as simple as possible. Windows Installer is a very complicated piece of software and when things don't work right it can be hard to figure out what's going on. I'm sure we have all experienced the endless loop of Windows Installer trying to repair a file that you no longer have the source .msi file for.
Most of the time using Windows Installer is like using a sledge hammer to crack a nut.
I use InnoSetup for my own stuff and InstallShield at work (against my will). Start with a simple script based installer and only use Windows Installer if you have a good reason to.
Note that support for installing assemblies to the GAC may be missing for some non Windows Installer setup tools (such as InnoSetup).
I used to LOVE Inno Setup. Emphasis on "used to".
When you run the single file installer (what you'd typically do), it unpacks the real setup program into a folder under the temp folder and then tries to execute it. The problem is... some anti-virus programs don't allow this.
The author is aware of this and refuses to do anything about it. The folder name is random, so cannot be added to any exemption list your anti-virus program may use.
Again. The author is aware of this and suggests that I tell my users to turn off their anti-virus programs during installation. (Like that's going to happen)
Related
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.
this may very well be a stupid question, but when i was asked something much simplier then this, i didn't have much of an answer...
why are most programs installed via some several step process of adding and changing and whatnot? we have programs that can be ran straight from a self contained executable, but a large portion of programs cannot. why is this? is it due to the programs growing exponentially by needing to include everything within itself? if that is the case, it is so difficult to design an OS from the ground up to be completely modular... ie. having an OS with a standard set of modules, that can be accessed and used from any 'standalone program' that doesn't require a lengthy install.
thanks
David Kirsch.
It's really a question of how complicated your program is. Many windows programs have dependencies on Visual Studio C++, .Net, Java etc. runtimes that are not delivered by the substrate OS. This means that for your programs to work those components must already be on the system.
If those prerequisites are missing, then your program won't even load, so you can't even get your program to check for them and tell the user to go and get them. This is where an installer comes in, as it generally doesn't have any prerequisites, but is able to sniff out the ones your progam needs and can either tell you to go and get them, or try to install them for you.
Also many programs need some logical, as well as physical, installation work to be done as part of deployment. This might mean registry changes (such as COM registration), changes to IIS (setting up a web application and virtual directory), or changes to the Service Control manager (setting up Windows Services).
In short, unless your program is extremely self-contained and has no external dependencies, an installer is the only way to get your application on the desktop.
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.
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
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I'm not the best programmer so I found it was much easier to write a program as several separate executables, which occasionally call each other. But now I need an easy way to actually run them without writing detailed instructions like Run file one, wait until its completed and no longer in process manager before running file two, file three can be executed 15 seconds after file two has been created. Then Add a key to your registry. Etc. I figure there must be a good software out there where I can just drop all my exes in, tell it when to run them, and output one file for my clients to run. Any ideas?
Inno Setup is easy to use, free, open source and scriptable if you need it.
I've always had a good experience with NSIS
It's open source
It has a big community (and hence lots of plugins)
For simple things, its script-based approach is nice and easy
It's lightweight and fast
On the downside, if you want to do something more sophisticated, you need to use something that looks a bit like assembly language - very odd, and not particularly pleasant. Thanks for the comments about that - I'd forgotten all about it!
Inno Setup is simple, light-weight and covers a lot of ground. I've used it for 5-6 apps over the last 5 years and it never let me down. Highly recommended!
Before that I used InstallShield, which is one of these systems that are so complicated that they "offer" you to "utilize" their "professional services" to create your installations. In other words it's kind of a hack that only managed to build a customer base in the childhood of Windows because there was no competition. It's a bit like a 747 that runs like a Trabant.
The worst, by far, installer product I've worked with is "WISE for Windows Installer". This had me literally smash my mouse in the office floor in frustration. It is (or at least was, 4 years ago) utter crap and should be avoided at all costs. This is exactly the kind of software that those pesky license agreements are there for, else the publisher would be sued into oblivion...
Yes, two ideas:
If you're looking for a way to statically put files, registry keys, start menu shortcuts, et cetera on your customer's systems, you should be looking for an installer solution. Many of these exist, and choosing the best one mostly comes down to features and pricing. I happen to like Caphyon's Advanced Installer, and it does have a freeware version that looks like it might meet your needs, except for the ability to run executables at scheduled times (which would require the Windows Task Scheduler support only found in the Enterprise edition, which is in the ultra-expensive price range, comparable to InstallShield...)
If controlling the flow of events on your customer's systems is more important than getting the executables on the system, you may want to look into Automise, which is basically an ultra-friendly UI for creating scripts, which makes things like scheduling tasks quite easy.
Anyway, you can download trial editions of both pieces of software, to see which one (or possibly both) will allow you to do what you want in the easiest way, or at least give you some ideas on how to best serve your customers. It may turn out that simply adding a new, 'supervisor' executable to take care of registry keys, scheduling, etc. could solve the problem without any third-party add-ons...
WixEdit is an open source (install shield like) authoring tool that uses the Wix Runtime from Microsoft.
Wix Tutorials
If you don't have any specific requirements apart from being able to install a few executables, then basically anyone will do. I'd recommend NSIS, not because it is particularly easy to work with (it has a cumbersome assembly-like language which isn't to practical to do more complex things in), but because it is free, has a large and active community, and it generates fast installers with very low overhead. As an extra bonus, you can run the compiler (i.e. the tool which generates the installer) on Linux.
Edit: ...and whatever you do, do NOT use InstallShield.
The ones I've worked with are:
InstallShield
NSIS
INNO Setup
Custom created installer
My preference is INNO Setup. It's free, it's easy.
I heart wix, MSFT's open source, declarative (XML) based toolkit for building MSIs.
It's ace.
If you want to install binaries, add reg keys and even run "custom actions" (have your own code execure during install) you should have a look at it. Then you'll have a one-click (msi) solution. Good eh?
Definately Wix. :)
Wix allows you to do the most things with ease and the difficult things without hacks, it's free and open-source.
You can use Wix within Visual Studio (using Votive) or you can use it using the .Net SDK, MSBuild and your favorite XML editor. Wix supports creating MSI installers, MSP patches, MSM Merge modules, Wix libraries and much more.
You should take a look at InstallJammer. Not only is it free, it's cross-platform and very easy to use. Most common actions don't require any scripting at all, but with a powerful scripting language underneath the hood, you can make an install do just about anything you want.
If all you want is a basic installer to install your application, you can have it built in a matter of minutes from the first time you start it up. If you want something more powerful, the capabilities and documentation are excellent.
If you're not after an installer (which is doesn't sound like you are) Why not just write a program to do what you need?