.NET Framework Size

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.

Fighting The Good Fight

I really wish that I was referring to Setup related issues when I mention Fighting the Good Fight. Unfortunately, I am once again talking about the fight for survival against cancer.

Tomorrow morning my wonderful wife ( of nearly elevent years ) Cheryl will be undergoing liver surgery to attempt to deal with a metastatic tumor. The following months will involve additional surgery to deal with a lung tumor and many, many rounds of chemotherapy. With any luck the surgery will deal with the localized problems and the chemo will take care of the systemic problems.

So I once again come to you and ask that you please keep my wife and family in your thoughts, hearts and prayers in any way that you can.

An Example of the Importance of Setup

As a result of my division being sold to another company earlier this summer, one of the many things asked of me was to complete a `Jobs Analysis Questionnaire`. Basically it's a really long form trying to figure out what the heck I do ( think of the Bobs in Office Space asking `So just what is it you do here?` ), how much responsibility I have and what could go wrong if I do it incorrectly.

A lot of people seem to think that Deployment Engineering isn't really important. Very frequently I am contacted by potential clients and recruiters who seem to grossly underestimate their needs. I even see this attitude from very seasoned developers and program managers who really should know better.

Recently I've seen a lot of postings talking about very .NET Framework and Visual Studio installer errors. However even these blatant defects are nothing compared to this gem.

The summary of the story is that a gaming company was putting together an installer using NSIS and in the process they wiped out the BOOT.INI on their customers computers. They try to explain how their entire development process failed to catch this issue but in the end it's inexcusable. In the end they are feeling the pain of trying to make it right.

Sadly this is the case in a lot of development shops. Deployment Engineering just isn't treated as a first class activity. Resources with little or no understanding of deploying applications get assigned, the requirements aren't clearly defined, inferior tools are selected and the test plan is non-existent.

Windows Installer Useful Web Sites

This blog post is going to be a continual work in progress. Please feel free to contribute to the list via a comment.

Windows Installer Useful Web Sites


Installation Phases and In-Script Execution Options for Custom Actions in Windows Installer

More Interesting and Uninteresting Comments

Stefan Krueger recently waded into the custom action debate with some very interesting comments.

Stefan references my believe in InstallScript custom actions and mentions a couple downsizes. Mainly Installscript engine size ( package bloat ), possibility of InstallScript engine failure and the temptation to use InstallScript CA's to make system configuration changes instead of built-in MSI patterns. Specifically he says:

However I believe that the tasks of a custom action often aren't typical installation tasks (copying files, accessing the registry) but require calling some APIs to interact with other applications.

Personally my packages tend to be very large and complex so the engine overhead is a non-issue to me. However, I could see it could be a consideration for small packages. I've also found the InstallScript engine to be very reliable.

I find InstallScript's ability to call Win32 API, COM and ManagedCode with very little plumbing ( let's just say you won't be worrying about things like allocating memory, casting datatypes and hosting COM servers and the CLR ) to be one of the strongest reasons for using InstallScript. For example, in one of my client installs I prompt the user for the hostname and port number of an application server. I then pass this information off to a .NET class that invokes uses the information to invoke a webservice. Anyone want to take a guess at how many lines of InstallScript and C# that is? Anyone want to take a guess how many lines that would be in C++? I've been using this code in production for 1 1/2 years now and I've never ever seen it fail.

Another example would be where you need to make a change that MSI doesn't support. The built-in MSI functions make it easy to implement the database queries needed to author data driven CA's and the extensibility makes it easy to interop with whatever external API you need to talk to install, uninstall, commit or rollback the configuration change.


Now for the uninteresting comment. A developer named Carl replied to Stefan's blog with this nugget:

Christopher Painter is wrong. InstallScript MSIs are never appropriate. Leveraging the language into MSIs was dreamed up by InstallShield's marketing team to con people into 'upgrading' to InstallShield 7 saying that "you can upgrade to MSI and your old scripted package will still work"

It had no place in an MSI then, and it has none now.

Personally I like VBScript. It has the advantages of being easy to read, open source and can be debugged from within the MSI using the MSOffice debugger.

Well, I've said it before and I'll say it again. Some developers just LOVE to HATE InstallShield. Here is another developer who's convinced that I'm wrong and InstallShield sucks. Never mind that he doesn't know the difference between an InstallScript MSI and a Basic MSI with InstallScript CA. Never mind that he mentions InstallShield 7 and that he prefers to use ( shudder ) VBSCript CA's. InstallShield is evil and they have conned the world.

InstallShield 2008 Beta Support for Visual Studio 2008

I noticed a thread over on InstallShield Community where Mike Marino mentioned that InstallShield 2008 now has beta support for VS2008 VSIP. You can find the InstallShield Knowledge Base article here. The hotfix can be downloaded here.

WiX Takes The Next Step

I was reading on Windows Installer Expert Stefan Krueger's InstallSite Blog today that that the Visual Studio team is finally incorporating WiX into VSTS. I am very pleased to hear this and I can't help think `about time`. :-)

Regular readers of my blog are no doubt aware that I've been advocating over and over for months that Microsoft make WiX a priority.

Getting the core tool set in VSTS is a very good step but there is still a huge gap in the authoring/designer/editing tools. Considering Microsoft has purchased other products for inclusion in VSTS ( TeamPlain ), I think Microsoft should seriously consider purchasing WiXAware and incorporating it into VSTS as well. This would be a very potent combination of technology that would really make me rethink which tools I use to write my installs.

Eitherway, congratulations go to Rob Mensching.