The benefits of XCopy deployment

There is a point about NDepend that keeps provoking debate: The product doesn’t come with an MSI-like installer. Indeed, the NDepend redistributable is a zip file. To install NDepend, the user needs first to unzip the zip redistributable file somewhere on the hard drive (usually in C:\Program Files\NDepend) and second, double-click VisualNDepend.exe to start using the tool.

Some users find it awkward for a professional product. Hopefully, some other users don’t. Let me quote Mauro Sant’Anna:

Last but not the least: the NDepend redistributable file is a small (7MB) download, it occupies 17MB after unpacked and it doesn’t need to be installed, which in my opinion speaks volumes about its own quality. They could have written an .msi installer but it seems that they didn’t on purpose to send a silent message to their audience. You see, it’s like a Ferrari, it does not come with an automatic transmission. If you really want an automatic transmission, well, then you don’t belong. Go buy a Mustang.

Benefits of XCopy deployment

I wouldlike to explain why we did this choice of a simple zip file to redistribute our bits. Looking back in 2002, one of the big promise of .NET was XCopy deployment. Indeed, at that time, most of Windows softwares were relying on COM which registered literally thousands of COM classes in the registry to install even a simple product. This lead to un stable install and tons of versionning issues. With the XCopy deployment:

  • Copy/paste some files and the product is installed.
  • Delete the product files and the product is uninstalled.
  • Delete the product files + re-copy/paste the files from the original redistributable and the product install is repaired.
  • Delete the product files + re-copy/paste the files from the newer redistributable and the product is updated.

The only way to get a simpler deployment would be to have a web application but this is not an option for a static analyzer like NDepend with a rich UI. The main benefit of XCopy deployment is simplicity.

Another benefit is the respect of the user’s machine: personally I get pretty anxious when I am waiting minutes that a running MSI file register/unregister tons of registry keys on my machine.

In theory, a benefit from XCopy deployment could be the ability to execute the product from a removable drive (such as an USB stick) or a network shared folder. The problems with this approach comes from the numerous luring security issues, both at Windows level and at .NET Code Access Security level. This is why we decided so far to not support this facility.

Downsides of XCopy deployment

Another benefit of XCopy deployment is that it naturally fulfill the side-by-side installation paradigm. Users can easily install several versions of NDepend on their machines. The only problem here is that, as all ISVs, we support ascendant compatibility but not descendant compatibility. It means that having several versions of NDepend installed could lead to older versions of the product that couldn’t consume data files spited by some newer versions. Thus, this particular side-by-side point could actually be considered as a downside of X-Copy deployment.

The others downsides of XCopy compare to MSI are:

  • No shortcut menu installed.
  • Need to unzip a file manually.
  • Need to choose/create a folder where to unzip the file.
  • No possibility to start the product automatically once installed.
  • No possibility to integrate automatically with tier product (like registering a VS add-in)
  • No possibility to register the user’s licensing data at install time.

Concerning the shortcut menu, the users of NDepend are developers, per-se, we estimate that they know how to create a shortcut. This simple assumption doesn’t hold in general. Most of Windows users are not supposed to know how to create shortcuts. (btw, personally I hate when a software like for example, some printer pilots, install shortcuts and plenty of tier software I will never use. This is just noise!).

The same reasoning applies for starting the product and unzipping the file. We assume that a developer knows how to do that but this assumption is certainly wrong in general.

Concerning tier product integration we solved the problem by proposing an install menu in the VisualNDepend start-page + in the option menu. Certainly, some users missed that point at first glance. But we assume that as soon as the user wishes to integrate NDepend with VisualStudio or Reflector, he knows where to find the integration button. Btw, we are using the VS add-in XML registration which means that here also, NDepend doesn’t tweak the registry in any way.

Concerning the user license registration, a license file needs to be copied in the root of the install dir. Here also, we never heard a complain about a user unable to do so.


Having an XCopy deployment is a trade-off between simplicity/respect of the user machine and the assumption that the user is able to do a few manipulations by himself. For most software, a MSI-like technology is more suited because the user is not supposed to master these manipulations. Concerning a tool for developers, we estimate that it is preferable to show respect for the user’s machine integrity.

2 related notes

There are 2 points that I would like to precise:

  • First we are constructing the redistributable zip file with Windows Vista zip capabilities. Guess what? Some other zip readers software consider our zip file as corrupted! I would say that we get a complain from about 1 user on 1000. A self extracting executable could solve this issue. But in a world where executable files are constantly banished in the name of security, we would certainly have much more users’ complains concerning security permissions to run an executable than we have now concerning corrupted zip
  • Second, XCopy gives more access to the user. The probability that the install gets corrupted because a file got deleted accidently is much higher. Reflector solved this issue by having only one .NET assembly. This is not an option for NDepend (as explained in the post Advices on Partitionning code through .NET Assemblies). Thus we implemented our own versioning and installation verification routine. This piece of code is triggered each time NDepend is started. If an issue is detected, the user is informed immediately and can readily repair the install by overriding it. I detailed this routine into the post Code defensively: Continuously check for corrupted installation. Btw, even if your product relies on an MSI like install, having such a custom verification routine is not luxury : it really saves some time supporting users that meet corrupted installation + it conveys a clean image of the product.


This entry was posted in Deployment, MSI, XCopy. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Sad Git

    XCOPY and ZIP file all day long – It shows me that you care about the cleanliness of my machine and you know exactly what you need and where to get it from.

    If you need/want an MSI then I suspect you are destined for a spaghetti install.

  • Scott

    Sorry. I’ve got to say this reasoning is either lazy or arrogant. It’s so easy to create an MSI that does very little beyond xcopy deploy. I’m trusting your software anyways, the first time I run it. So, the logic that the MSI is bad, but running some exe is good does not hold up.

    You’re really taxing your users. It doesn’t matter, if we can *figure it out* It’s really wasting the time of thousands of developers.

  • rtpHarry

    Even after the reading this article I still dont see a good reason for not having an installer. Complaining about the msi breaking or being unreliable doesn’t seem a valid argument when every windows app under the sun uses one.

    Creating my own shortcut is something i might have had an interest in when I was a kid using windows 95 but nowadays I just want stuff to work.

    I trust you to only add the reg keys and anything else that you need to the msi and nothing more. If you do go overboard the community will pick you up on it.

    If you have file versioning issues then you should build in a file version so that you can check it is compatible before your app tries to load it.

  • Patrick Smacchia

    It is an interesting debate because, I guess, we won’t find a final answer that satisfies everybody:

    -some prefer MSI-like anyway

    -some (like me) prefer XCopy-Zip anyway

    -proposing both on the download page seems the best solution, despite it is a first headache for the user (which one to choose?)

    In some upcoming releases NDepend integration with VS will play a central role and it will be maybe the opportunity to have a msi-like redistributable to let the user integrate with VS at install time (the other option to integrate with VS is like now, with a button from the VisualNDepend start page as explained in the post).

  • Steve Py

    “Headache”?! My, I doubt you’ve ever used an installer from an Oracle product. 😉

    I can’t say I agree with not providing an MSI in favour of only XCopy, but the benefits of updating, removing, and repairing applications when you know it was simply copied and executed is a big benefit of offering XCopy deployments.

    MSI installers can be quirky to get working right, and prone to errors that are a hell of a lot harder to get rid of than the “headache” of extracting files from a Zip and creating a shortcut. Uninstalls that don’t work, applications where you have to manually hack the new scripting language to even create an uninstall icon, (critical IMO especially for evaluation products) corrupted installations… That’s my definition of a headache.

  • Richard Dingwall

    “John, the value is the implicit message sent to the user: Installing NDepend won’t mess up your machine in any way.”

    Impressive. But does not mean you should force me through some headache manual installation.

    “Does your opinion hold even if taking account the fact that XCopy deployment gives you a full control of the installation?”

    I think most users don’t care. I just want to double click something and see it in my start menu ASAP.

    “But the fact is that we have no real-world measurement of who prefer zip and who prefer msi-like. ”

    Fair call. Why not post both MSI and ZIPs on the download page and count how many prefer the zip after 1 month?

  • Steve Py

    An interesting debate. Coming from the days of DLL-Hell I am a big fan of XCopy deployment. It was one of the key issues I had with VB6 and I nearly jumped to Delphi when I heard that .Net would support it.

    Personally I don’t like MSIs basically for the same reasons Patrick outlines. When I am “forced” to use MSI I always use the “Custom” option whether to remove crap I don’t need, put it in *my* directory structure, or simply avoid it slapping shortcuts everywhere. If given the choice of MSI or Zip, I pick Zip.

    Extracting a zip is pretty easy to explain and figure out. Probably the biggest annoyance when explaining it to novices is to get them to see them as files that need to be extracted rather than “compressed folders”.

    Still, a simple MSI is great to provide to novice users which worship the Windows Voodoo gods. NDepend certainly isn’t any use to such novices so XCopy is perfect.

  • Sylvain

    I am a happy NDepend user but I do not like the idea of having just the zip, despite the fact that I am a developer. Sure I have been able to extract the zip file in my Program Files, but I don’t see much value into HAVING to do that.

    Also, I like to be able to open my SolutionName.Ndepend.xml files from my solution working directory without having to digup several subfolders in order to fireup NDepend. So I went ahead and selected VisualNDepend as a possible program to use to open XML files. Right there you can see that NDepend does not really coexist well with the Windows environment as only the NDepend icon is displayed without the app name (which looks very akward) when I right click my XML and open the “Open with…” menu. That sort of lead me to this general impression that NDepend is like the Oracle products: the core is very good, but don’t expect a great installer or advanced integration with the OS :)

    I think the idea of proposing BOTH a zip and an MSI is the right one. Many products are proposing both downloads and I guess everybody is happy. Some like the 7zip intrusion in their right click menu in the Windows shell (like me, so I installed the MSI)… some don’t (so they get the zip)! and despite being a developer, I don’t really feel like going ahead and code a shell-explorer extension just for NDepend!

  • Patrick Smacchia

    >99.9% of the time having that control has no value?

    John, the value is the implicit message sent to the user: Installing NDepend won’t mess up your machine in any way.

  • Kyle Baley

    I was happy to discover there was no MSI package. I don’t see any particular pain in unzipping a file. It’s fewer clicks then most install packages anyway. Like NAnt and NUnit, I have no need to have a start menu shortcut and I certainly don’t want anything installed in the registry for it. My vote is to leave it as a zip file, like .NET Reflector.

  • John

    > We should do a survey for that.

    Perhaps the survey could be to offer both kinds of package and see which gets the most downloads. :)

    > Does your opinion hold even if taking account the fact that XCopy deployment gives you a full control of the installation?

    99.9% of the time having that control has no value? The files will end up in the same place, I just have to do more work to get them there.

    I think Mauro’s analogy is not quite right. It’s not that I want an automatic transmission, it’s just that I want Ferrari to deliver the car to me in one piece and ready to drive. I don’t want to have to screw in the seats and attach the steering wheel to get started.

  • Patrick Smacchia

    John, you are right, I express our point of view. But the fact is that we have no real-world measurement of who prefer zip and who prefer msi-like.

    Does your opinion hold even if taking account the fact that XCopy deployment gives you a full control of the installation?

    We should do a survey for that.

  • John

    Patrick, I certainly can do the installation manually but why should I? If you give me a Zip file you’re just giving me a headache before I can even try out your product. The first impression I get is that the developer is lazy and unprofessional.

    A small number of people might like having to manually install but I think you annoy more people than you please. Fortunately, the value you get from the product itself overwhelms this initial pain.

  • Patrick Smacchia

    >you job is to make money not to enforce best practices.

    IMHO best practices are here for making more money. Else they are worst practices :o)

    >The key is Simplicity. Yes, you heard it right. 😉 Just double click on the file and blum.. you are ready to go.

    How many time did you try to repair/update/uninstall a product and ended up by killing the msiexec.exe process because after many minutes it looked like hanging?

    To me it happened many times unfortunately (especially with VS ecosystem tools). If I would had to just copy/paste/delete some files I would have been much more happier.

  • Dhananjay Goyani

    Well, in most cases any managed windows application deployment is actually file copy paste. For example take MS’ threat modelling tool. Install it and copy all the binaries to other machine, that will just work.

    However, luxury with MSI based installation is one stop Install and Un-install through Add remove programs. And that make sense to all windows users irrespective they are dev or not.

    Even though, nDepend is a windows app stuff, I would rather favor MSI only. The key is Simplicity. Yes, you heard it right. 😉 Just double click on the file and blum.. you are ready to go. With xCopy, for install/repair/upgrade you have to manage folder/files rather than just one MSI. And secondly, for such a cool tool like nDepend who doesn’t want to always run latest version rather than keeping & managing all available versions. I dont want to be nDepend manager but runner.

    As a side note, I really appreciate your ‘Code defensively’ entry.


  • tobi

    this was the wrong descision. you could just provide both an installer and a zip. the installer is however much more important than the zip version. you job is to make money not to enforce best practices.

  • Patrick Smacchia

    >can easily float the whole lot from one dev PC to the next, settings and all.

    Paul, one caveat here: settings cannot live in the same dir as the application because in Program Files this dir is read-only. For most applications, settings will leave into the AppData folders, for example for NDepend it is:

    You can copy past this dir too, I don’t know for others application but for NDepend it’ll work.

  • Paul Kohler

    Agreed! I am a big fan of XCopy deployment. That said I do think it depends on your audience and I think developers should be completely fine extracting apps via ZIP files or similar. I far prefer this method especially with dev tools because then I just keep them all in an apps directory and can easily float the whole lot from one dev PC to the next, settings and all.
    The other thing I have done in the past is included simple “self install” procedures within the app itself with “/install” options (like .net refector’s /register option etc). Of course this does complicate things especially with different platforms etc…
    Keep the ZIP – PK 😉

  • Martin

    You could create a setup using NSIS (or some similiar tool).

    This results in a very lean (xcopy-like) setup kit, but you still have the advantages from MSIs: user can select install location, you can create start menu entries, user can easily uninstall the app.

  • Yan

    Nice post. In my opinion, the main point expressed here is “consider the target audience when choosing the way to deploy”. If it’s developers, stay with ZIP. If it’s less technical people, stick to MSI.

    Despite MSI has a number of holes, the applications like NDepend can be easily installed with MSI. It is relatively small, doesn’t install databases/IIS objects, doesn’t require complex installation UI, etc. I’m sure that experienced setup developer can work it out in a couple of hours. 😉

  • Patrick Smacchia

    Phil, Bertrand, both proposed solutions lack the simplicity and the transparency of XCopy. Also, from a user perspective, they seems more intrusive.

  • Bertrand Le Roy

    I’m confused about why you couldn’t offer both. Couldn’t the msi just do the xcopy and set a start menu shortcut?

  • Phil

    Why not use click-once?