I am finally getting around to doing my taxes. I went out and bought Turbo Tax Home and Business, installed it, and started working. At a certain point in the process, Turbo Tax crashes. Bleh! I fire it back up and try again, same crash same place. I click the “Tell Intuit about this problem” button. It comes back with a link to a ‘fix’.
It would seem that Turbo Tax requires .NET, but will crash if you have the ‘wrong’ version of the .NET framework installed. Their ‘fix’ is to uninstall all of the installed versions, breaking who-knows what other programs that require those specific versions, rename a system directory (because uninstalling it doesn’t really make it all go away) and then install a version of .NET that Turbo Tax likes.
There are (at least) two problems with this.
If Turbo Tax is that finicky about what version of .NET it will run with, the Turbo Tax installer should sort this out. It is totally unacceptable to have the user discover this at runtime, by crashing and losing time and data.
Turbo Tax, a commercial software product that will be installed on systems with every imaginable configuration, should not depend on the .NET runtime at all. In my humble opinion, there are just too many variations of the runtime out there in the wild, and this sort of thing is bound to happen.
If you write in-house software, which will be installed on a homogenous set of systems, then .NET is great. However, if you can’t count on the configuration of the systems your product will be run on, you should probably avoid .NET like the plague. Even if your program installer gets everything right, and makes sure that the ‘right’ version of .NET is installed, it is entirely possible for that version of .NET to be uninstalled later, perhaps because the user is trying to do their taxes!
Personally, I prefer static linking as much as possible, and reducing external dependencies to a minimum. This makes your program much more robust, and is likely to greatly reduce support costs.