7

Has anyone used WiX to generate an installer for an ASP.Net MVC website? Do you harvest files from the web project? I can’t find any good examples of this being done. There doesn’t seem to be a documented way to include all the right files, only the right files and put them in the right place.

If you add the website project as a reference in the installer project, and set harvest=True in the properties, then all the website files are captured, but there are issues:

  • Some files that should not be copied are included, e.g. packages.config, Web.Debug.config There doesn’t seem to be any clear or simple way to exclude them (as per this discussion).
  • The .website dll file is in the wrong place, in the root rather than the bin folder (as per this discussion)

However if you do not use harvesting, you have a lot of files to reference manually (e.g. Under \Content\ alone I have 58 files in 5 folders. Most of that is jQuery UI) and they change from time to time, and errors and omissions could easily be missed from a WiX file list. So it really should be kept in sync automatically.

I disagree with the idea that the list of files should be specified explicitly in WiX and not generated dynamically (which is what seems to be suggested at the first link, the wording isn't very clear). If I need to remove a file I will remove if from the source control system, there is no need to do the extra work of maintaining two parallel but different catalogues – one set of files in source control, and the same files listed in WiX. there should be one version of the truth. All files in the website's source tree (with certain known exceptions that are not used at runtime e.g. packages.config) should be included in the deployment.

For corporate reasons I don't have much choice about using WiX for this project

Community
  • 1
  • 1
Anthony
  • 5,176
  • 6
  • 65
  • 87
  • Well, I disagree with you disagreeing. BTW, is there actually a question here? I've written hundreds of installers over the years and many of them have been multiple instance n-Tier solutions incluing ASP.NET web UI and services. I've written automation to cross check that what my installer consumes and my project publishes are identical. When something is added it's trivial for me to add the file to my installer and the best thing is I know it was done perfectly not auto-magically. (Deploy and pray.) – Christopher Painter Feb 22 '12 at 03:13

2 Answers2

4

In our MVC 3 project we use Paraffin to harvest files for the installer. For example, you can use "-ext " to ignore the files with extension , use "regExExclude " to ignore the file name matching the regular expression, etc.

Paraffin also keeps the proper structure, all your files would be in the correct folder as they appear in your project.

Tony Tang
  • 316
  • 2
  • 7
2

I use a program that I wrote called ISWIX that makes authoring wxs merge modules a simple drag and drop operation like InstallShield. I then consume that merge module in an installer that handles the UI and IIS configuration.

I also have postbuild automation that extracts the content of the MSI and compares it against what the project published. If there is a delta I fail the build and you have to either a) add it to the wxs or b) remove it from the publish.

I find that the file count churn from build to build is minimal and that this system is not difficult to maintain. The upside is everything remains 100% intentionally authored and files don't ever magically add or remove from the installer unless you intended them to. Dynamic installer generation isn't worth the risk and most people who argue that it is don't even know what those risks are.

Christopher Painter
  • 54,556
  • 6
  • 63
  • 100