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.
Related
I have a windows service for a schedule some jobs. It will be sold for a price.
I created msi file for setup. After the install, installed folder have an exe file and dll's.(By the way, I am going to install service on customers' computer, so they won't be have msi file) I found out, this installed exe file can be installed with InstallUtil.exe. I have done some research but I cannot found any good explanation. My questions is, how to forbid install with installUtil for installed exe? I am new to this area, any help will be good. Thanks in advance.
If I understand correctly, you want to prevent people using your software without paying for it. Unfortunately, it is impossible.
Your code, when it runs on the client, is fully controlled by the client. While you can make things harder, in the end no matter what you do, it will always be possible to run it without your permission. Take any commercial software and then search on torrent for pirate versions. :)
You can go lengths in trying to secure it, and the effort needed from an attacker may become somewhat higher, but it is logically impossible to prevent copying if all of the code is on the client.
What you can actually do is offer your solution as an online service (like a most commonly a webapp these days). That way control remains with you.
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.
I have an application that has to support modifying some registry data depending on the kind of 'installation' that is desired. At present, I have no problems hard-coding to either get elevation and do the changes to the entire local machine, but it is far from nice as ideally, I would also like to support per-user installations. I could hardcode that, but then I lose the local-machine stuff. To be precise, the changes in question involve file association changes, COM stuff etc.
How can I properly support both usage scenarios? Currently I use a set of ON/OFF checkboxes for the variety of associations.
Should I change this meaning on, for example, a MachineInstall file existing in my apps directory, and if not assume User install?
Is it an expected/valid/whatever usecase to say that someone might want to do some things for the entire machine, and some things only for the user? (E.g. mixing of the two.)
Or should I change the entire UI, move away from checkboxes and move to some sort of combobox going 'None/User/Local'? Then again, I think this might have some sort of breakage once you involve multiple users and combinations.
To give an indication, I personally expect the application in question to have its uses for everyone on a computer and as such lean towards the Local-Machine as a 'default', if that makes any sort of difference.
I am likely overthinking the matters quite a bit, so any and all input is very much appreciated. :)
P.S.
Now, someone is probably going to say 'do not do all that stuff from your app, do it from the installer instead'. And they probably have a point, but the point is to allow easy changing of these settings from within the application. To top it off, I am not using .MSI install packages because they make working with 32/64-bit specific executables a disaster requiring merge modules, spawning other MSI's depending on the situation, and so forth (I forgot the details last time I dug into it and forgot about the matter). I don't have that knowledge, nor the time to learn all the intricacies of MSI installations, so it is out for as far I am concerned. To boot, my application is perfectly capable of functioning without any of those registry entries being present, and that is by design. In a way, one might compare it to be like Process Explorer from Sysinternals, which does not require an installer, but can be unzipped and take over the task manager etc without a problem if a user wants, or simply run stand-alone.
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.
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