I’m trying to build a general understanding for what’s common in this situation so that I can decide if it makes sense to pursue it further.
- Are installers welcome in a typical corporate environment with the following?
- Change control process
- Dev/QA/Production environments
- Designated deploy teams for various areas (firewall, database, windows, etc.).
- Is there a “litmus test” that could be applied to an application to see if it is a good candidate for creating an installer? *
- Are installers simple enough that every application should have one?
- Are installers even the right tool?
- Is it reasonable to expect developers to learn something like WiX to support installers?
- Maintainability in general is a concern, i.e., is creating an installer a niche skill?
*
For example, I have a set of winform applications that are in a shared directory on a production server. Specific groups can run the applications from this directory but only system admins can modify the executables. The current deploy process involves having an admin copy/paste the executables and libraries to the shared directory.
Since the applications are not installed on the individual users’ machine, does it make sense to create an installer for deploying new versions of these applications to the shared directory?
Edit–
I felt that the answers here gave some solid advice so I wanted to share what I came up with for my current project where I needed to build a large number of applications and deploy them to individual folders.
I found a NuGet package called _PublishedApplications that mimics the behavior of _PublishedWebsites for web projects. The idea is you install the NuGet package to your projects and it adds a target that will copy the build artifacts to a _PublishedApplications directory in the output path. This behavior is activated by running MSBuild from the command line and specifying an outdir property:
msbuild /p:Configuration=Release /p:outdir=C:pathtooutdir MySolution.sln
This will give you a directory structure similar to the following:
- C:pathtooutdir
- _PublishedApplications
- Project1
dlls, exes, etc.
- Project2
...
- Project1
- _PublishedApplications
From there, creating a zip that can be extracted in the various environments is fairly painless.
3
An installer always makes sense, if deployment requires anything more complicated than copying the relevant file(s) to some folder and running the EXE. If there are additional steps that need to be taken to set the product up properly, there’s two ways to go about it.
- You can write out a list for someone to follow. Humans being humans, someone’s bound to screw it up, and then call you up asking for help because your program isn’t running right.
- You can write out a list for a computer to follow (an install script). This makes it much less likely that user error will screw up deployment.
On the other hand if you don’t have any setup tasks that need to be performed, then just give them a zipfile. That’s simpler than running an installer.
Wyatt takes off his programmer hat and puts on his Director of IT hat
If this is an internal line of business application then you only need aim at one environment — said business. I would call the head of IT and ask him how they would like to manage deployment. IT departments have been dealing with this for a while so they might have a strong preference for xcopy or MSI-based options or something else entirely such as your current option.
I’ll add that department would at the very least appreciate the gesture and could likely become a valuable ally as chances are they know more about the existing line of business app and problems than you realize.
2
Windows Installer applications are widely used to install internal business applications in environments using Windows. You should also ask yourself whether over the application’s life it will likely ever need to be updated, patched, repaired, or cleanly removed from user’s systems. In many cases the answer is “yes” – in which case having a properly written installer can reduce the total cost of maintaining the application over time. There are other services and features designed to work with Windows Installer, such as Restart Manager and WMI and product and patch inventory functions. If your application can benefit from these, then that’s another reason for including an installer.
The upfront costs to develop a useful installer for your application may pay off in the long term, and the costs of development can be mitigated by selecting an appropriate Windows Installer authoring tool, such as WiX or InstallShield or another.
As with all engineering decisions, it depends.
Probably the most important factor is to understand who the consumer of your installation process is and what skillset the development team has.
Since it’s internal, I assume it’s deployed by an internal IT department. They are probably no strangers to command shells.
Graphical install wizards are useful for software that is distributed to external customers directly because simple assumptions about your configuration are no longer valid, such as file server locations, security policies, etc. Therefore, you need to guide each user through picking settings themselves.
In your environment, this stuff is probably dictated by either development or IT and rarely change. Therefore, I recommend using shell scripts to copy files around to the appropriate place. The scripts should live within your product as part of the package that is released. It should also be version controlled along with your app.
Where I work, our entire web application is installed via an InstallShield wizard, which asks a bunch of questions, most of which are file system locations, db connection information and other settings that just end up in config files. It’s difficult to automate. Since the web app installation at its core just created a couple of databases and copies files, I am writing a new installer using either Ant or Powershell which simply runs .sql files and copies files.
Then everybody can understand how it works and maintain it more effectively.
2