Windows Deployment – Internal Business Applications Installers

deploymentinstallerwindows

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.

  1. 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.).
  2. 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?
  3. 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:\path\to\outdir MySolution.sln

This will give you a directory structure similar to the following:

  • C:\path\to\outdir
    • _PublishedApplications\
      • Project1\
        • dlls, exes, etc.
      • Project2\
        • ...

From there, creating a zip that can be extracted in the various environments is fairly painless.

Best Answer

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.

  1. 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.
  2. 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.

Related Topic