My previous post about moving from Visual Basic to Python prompted a comment by Rob Relyea from the WPF team about an upcoming “servicing release” that will simplify and slim down the download for XP users. This must be the .NET Framework Setup for Client Applications which was announced two months ago and is scheduled for the summer. Scott Guthrie’s announcement is quite specific and Rob’s post adds a number to the mix: thirty megabytes download. This number is way better than the 197MB that faces anyone downloading the .NET Framework 3.5 full package but it is the same size as our current installer. So, if I chose to use the WPF for the next version of GeneXproTools the best case download for an XP user would be around 60 Mb which is quite reasonable.
Up to a point the download size is not a huge issue in our market as most of our clients have good connectivity, not to say I don’t prefer Python’s five megabyte footprint but the comparison would not be fair. Anyone creating software uses several runtimes and libraries. Let’s see; GeneXproTools ships with the C runtime, the Visual Basic runtime, Codejock’s ActiveX libraries and SQLite’s runtime adding up to about 15MB of libraries. Slightly less than half of our current download is third party code and it will be inflated by another 5 MB for the Python libraries (built by py2exe). But all these runtimes are transparent to our users and, more importantly, to their IT departments. Having an application installed on your work computer when you are not a software developer can be a problem. There’s compliance, license management issues, security concerns and maintenance issues. Any small wrinkle can lead to the refusal of the installation and one less sale for us. And this is the main reason that has me hesitating about adopting the .NET framework or Java’s, for that matter.
We need a linker
There is no point in dancing around it. I will adopt the .NET framework the day Microsoft ships a linker for the .NET framework. There are other points that need considering but such a step would remove most of the barriers because then the framework is not an issue anymore. As far as my clients are concerned my application would not have any external dependencies and would not add funny named folders to the Windows folder. It would be a monolithic application that lives under Program Files and adds a few entries in the registry. Most IT departments are happy with that because it gives the illusion (and the justification) that the application is self contained.
I don’t understand why this is an issue for Microsoft. I have read all the usual excuses about reaping the benefits of the new fixes and service packs applied to a shared framework but I don’t see how they might apply to my software. I want to be able to determine the exact version of the libraries my desktop application loads even if they are buggy and I dread any unwanted upgrades because they can generate hard to solve and expensive support calls. Some people argue that the .NET Framework is targeted at the Enterprise, not the ISV but I worked in large companies before and the problems were the same. There was always resistance to rolling out software with large dependencies.
This is not news. Joel Spolsky has been saying this since 2004 without any results so I don’t expect Microsoft to change course anytime soon. Another solution is to wait for Vista to become the dominant OS. I don’t know if it is being adopted faster than XP was but at the moment it represents only 10% of our website logs and support calls. Until then CPython seems to be the ideal platform for transitioning to modern programming paradigms.
Going back to Rob’s comment, I am curious to see what they have come up with and will be considering it very seriously but at this moment it does not look like it will be the ultimate solution to my problem.