I am trying to make an application as easy to deploy as possible for Windows and I am trying to choose between packaging the application as a .exe or using an installer. I was wondering if anyone had opinions on the relative merits of either way? My preference would be to use a .exe as it would be just click and run for a user.
You should only need an installer if you have lots of components that need to be installed in specific places, or components that need to be registered for them to work (eg COM components that need to be added to the registry). An installer can obviously also add shortcuts to your app in the start menu etc.
If your app can exist as a single .exe file that can be run from anywhere in the file system, then that would be a much simpler and cleaner solution for a lot of people.
Keep in mind though, that less technical users might expect an installer and won't understand that there are no links in the start menu.
I just prefer dealing with a standalone exe, much less hassle, if you can get away with it (i.e.: you don't depend on a lot of other stuff).
It's more portable than an installer application. You can copy it from one machine to another machine, or to another folder, easily.
If you reinstall the OS, it doesn't break the application.
You can have the application itself check for existence of a desktop and/or start-menu shortcut and create them if desired (perhaps according to a preference). E.g.: Textpad does this.
I've only been doing Windows development a short time, but one issue you might run into is dependencies. If you depend on .NET 3.5, for example, what do you do if a user does not have .NET 3.5 installed on his box? In that case, an installer might work better.
In general, standalone executables are much easier to work with. They are easy to move, delete, run from a portable drive, etc due to a lack of external dependencies. If your app does not need registry settings or does not require certain libraries or helper utilities to be placed in system folders, then a standalone .exe will fit your problem.
If you do need to modify the registry, install files in different locations, create subfolders, etc, then you will need an installer of some sort. If you provide an installer, make sure you provide an un-installer as well (and make sure that the uninstaller doesn't leave behind orphan registry entries or temporary files).
To solve your problem both ways, you can have a single-file executable that is installed via an installer. That way, you get the benefits of both approaches (not to mention that the installer would be very easy to write in this case). I have also seen some apps that are available for download either as an installer or as a bare executable (let the user choose their preferred delivery option).
If you don't have any dependencies, don't have to add/change data in the registry, don't have to clean after your application removal/update, then using just an .exe seems quite reasonable.
Related
WiX can be installed silently by passing in a flag, but can I design the setup in such a way that it will run silently by default, require the flag, or otherwise prevent the user from attempting to install it non silently?
reason: This is to be released as a distributable for other software projects to include in their application, and we would like to avoid any expectation of localizations/ui issues/ etc.
You can compile a setup without a GUI at all. Then it will install directly when you launch the MSI I believe. Frankly I am not sure if this works properly with the UAC (elevation prompt), but I think it does.
As I answered in your other question, you can also use a merge module to allow your setup content to be merged into another setup at build / compile time instead of running as a setup in its own right.
If you want an MSI, I don't think it matters that much if you do not localize the setup to all kinds of languages. Just link a default English GUI. You can even include ready-made translations for several languages as far as I know (been ages since I have done real localization).
The real point is that your customer can kick off your install in silent mode easily from within their own setup.exe, so your setup GUI will never be shown - just make sure to document this for your customers so they know how to do it.
I am supporting a vb6 application. I am trying to transfer the executable and DLL to a new server and I am prompted with component not registered errors. I have got round this by manually registering the components on the new server.
I have found two files with file extensions of 000 and 001 that have registry commands in them (registering components) Can anyone explain how these files are generated? I have experience creating installation files in vb.net to a certain extent.
Repackaging and redeployment is not a developer issue and really doesn't belong here. Such issues are more appropriate for someplace like ServerFault.
It is one thing to have lost all of the source code of an application, but even worse in some ways to have lost the deployment package. Sadly some shops fail to archive either of these.
However it was also common enough for shops to see RAD tools like VB6, Delphi, PowerBuilder, etc. as things to shove off on the worst of the worst of their developers. These poor slobs seldom got official Microsoft training that should have emphasized the importance of creating proper installers. For that matter even those courses tended to marginalize the topic. It doesn't help that the Web is full of "Mort teaching Mort" half-baked development even today, or that the pioneers who wrote many of the early serious VB programming books tended to be loose cannons and contrarians who didn't really believe deployment was a serious concern.
The end result is that lots of shops have machines with VB6 programs shoehorned onto them in a half-baked way. Often when deadlines loomed they let Old Mort install VB6 right onto the production server and let him hack away right there! So it's no wonder people get into trouble once a server needs to be replaced or its OS updated.
Those REG files with .000, .001, etc. extensions aren't anything normal that I'm aware of. For all I know they've fallen out of REGMON runs or some 3rd party packaging tool. Manual registry exports created using REGEDIT would normally have .REG extensions.
If you are actually "supporting" this application it implies that you have the source code, VB6 compiler, developer install packages for any 3rd party controls, and a writeup describing any special packaging and installation requirements (target machine DCOM/COM+ configuration, system requirements such as IIS or MSMQ or 3rd party DBMS Providers and Drivers, special folder requirements, software firewall rules, etc.).
From those it ought to be possible to compile a clean new copy of the EXE, DLLs, etc. and create a clean deployment package - even if some configuration still needs to be done manually before and after running the installer.
Without those you are a computer janitor and your question belongs over at ServerFault. It is no fun, I know. I've had to take part in such janitorial services myself all too often.
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.
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.
There's lots of questions about installers but I haven't seen one about whether or not to actually use one in the first place.
What is the logic behind using them in the first place? Can't the user just extract it somewhere? But I guess it depends on the target user.
And on the subject of the actual setup: Can't that be done on the first startup?
It very much depends on your target audience, and what your installer needs to accomplish.
If your audience is technically savvy, and the installer just has to extract some files, and create shortcuts, I probably wouldn't bother.
If you need to modify system variables, register services, etc, definitely create an installer to make life easier for your users - regardless of how technically savvy they are.
You can always offer the option of installer / no installer, and let your users decide what they want. The number of downloads and resulting support requests will tell you whether you should utilize one or not.
And on the subject of the actual setup: Can't that be done on the first startup?
uTorrent used to do this (I'm not sure if it still does... I update automatically) and I found it a little confusing at first, since I'm used to installers. For users that are possibly clueless though, it's perfect.
For more complicated applications that have multiple files installed to several locations, I think it's better to have an installer. For a series of products we produce where I work, we have several 'flavours' of installer for each product: auto-update installers can be smaller as we know the user already has prerequisites. New users, though, get a larger installer.
I can't see any reason not to use an installer. When you use something like Inno Setup, creating the installer is no more difficult than creating a zip file, and you don';t have to explain to the user how to install.
Having an installer will help your users a lot.
The application will be installed at the right place
The user won't have to set links in program files himself, or copy the extracting content you suggest in a directory
Your application will looks more professionnal
Moreover:
The user will know that using the uninstall system of windows will safely remove your application without affecting the system
You need something which can set up the registry and install prerequisites before starting the app, that's why you need an installer :)
Including a well designed installer can also add value over the lifetime of the application by enabling the application to be updated and enabling the application to be uninstalled cleanly. Eventually the user will want to uninstall the application, and the ideal is to leave their computer in the same state as prior to installation.