This is a topic that I’ve been wanting to write about for awhile but I just haven’t had the time: Holy Crap the .NET Framework 3.5 is HUGE!
How did we get here? Let’s see….
.NET Framework 1.0 Redist: 19.7MB
.NET Framework 1.1 Redist: 23.1MB
.NET Framework 2.0 Redist: 22.4MB
.NET Framework 3.0 Redist: 50.3MB ( x86 )
.NET Framework 3.0 Redist: 90.1MB ( x64 )
.NET Framework 3.5 Redist: 197.0MB
Wow! 197MB! The funny thing is there is a Doctor Dobb’s article from 2003 that was questioning the size of .NET 2.0 when it was a mere 1/5th of the size that it is now. Just what in the world would they think now?
It should be understood that the 3.5 redist contains a lot of junk under the hood. It’s really invasive… it contains windows patch, patches for previous versions of the framework, different versions for different platform types and so on. There have also been a long list of installer defects already announced that are going to pose problems when it comes time for ISV’s to try to integrate the framework into their bootstrappers for their own products.
Related to this topic are a couple observations that I wanted to share. The first is a long list of blogs that I’ve seen recently detailing installer defects in various .NET / Visual Studio installs. The quality and user experience in these installs really seem to be going downhill. It’s not like taking hours to install VS 2005 SP1 wasn’t bad enough. Now you are lucky if the installs work in the first place. As an aside, I really can’t help wonder if all of the Virtual PC CTP’s during the beta cycle didn’t contribute to an environment where the installs just wasn’t getting close scrutinizing.
The second observation is how many people are willing to just blindly believe in `Microsoft Best Practices`. For example, I recently read the following comment over at InstallSite:
I wonder if there’s a specific reason that some of the installer products feel the need to wantonly violate Microsoft’s best practices?
When asked to elaborate, the poster mentioned the use of non-standard cab compression techniques such as LZMA. This technique is used by other vendors such as InstallAware. For example, InstallAware is able to reduce the .NET Framework 3.5 Redist by 33% to 132MB. This is still huge, but atleast InstallAware is trying to do something to help out.
This advance in installation technology did not go unpunished though. WiX creator Rob Mensching flamed InstallAware over this issue with the following statement:
So why do I have a negative impression of InstallAware? Two reasons. First, they repackaged redistributable packages (such as the .NET Framework) which violates the EULAs of the products. Messing with other people’s stuff then redistributing your modifications without explicit permission bothers me at a philosophical level.
The irony is InstallAware was specifically asked by Microsoft if their technology could be used to reduce the size of the framework SDK.
So it seems to me that LZMA compression really is a best practice. It’s just that our overlords at Microsoft just haven’t been smart enough to admit and/or support it yet.
Getting back to the framework size issue… I’m afraid I don’t see magic bullet for mitigating it. Considering setup developers don’t typically get to tell the architects how to code, if 3.5 comes down the pipe we are pretty much just going to have to bite the bullet. As an aside, ClickOnce apps on .NET 3.5 are officially a joke, right?
Sadly I now find myself waiting for MSI 4.5 and it’s transacted prereqs patterns to see just how much more complicated ( and worse ) Windows Installer packages for .NET / Visual Studio can become.