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.