Normal
0
21
false
false
false
FR
X-NONE
X-NONE
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 would
like 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.
Conclusion
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
file.
- 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.