April 07, 2008

.NET Download Pain

Back in December, I posted an article about the incredible size of the .NET 3.5 framework. In it I complained that the framework redist package has bloated at an astounding rate.

Since that time I had a couple of responses from both ends of the spectrum. Aaron Stebner defended the size claiming (without mentioning my name):

I have seen some size comparison charts that show the .NET Framework size growing from 20 megabytes in 1.0 up to 50 megabytes in 3.0 and then 200 megabytes in 3.5. It looks like this type of size chart was based on the size of this full install package for the .NET Framework 3.5. That isn't really an accurate comparison though.

On the other hand, many agreed with me. Such was the case with Microsoft C# MSVMP Rich Strahl. He recently wrote a blog entry about the challenges of adopting the 3.5 framework.

At the time, my observations were mostly academic. We can argue back and forth over whether it's `fair` or not to talk about the framework being a 57MB package or a 197MB `union of packages` but the reality is that it still needs to be serviced in a variety of deployment models.

Recently I delivered a project to a client that had several dependencies. The application was a tray app ( .NET 3.5 ), an optional Office 2003 add-in ( VSTO2005SE - 6MB ) and an optional Office 2007 add-in ( VSTO 3.0 - 2MB ). The application is intended for web download distribution rather then physical media distribution.

With this in mind, I decided to consume the VSTO runtimes into the installer but only consume the web download version for the framework installer. According to `those in the know` this is the way it's intended to be since the download bootstrapper can pull only the pieces the target system needs.

Now that the installer has been kicked around a bit in the wild, I've only recieved one negative feedback: "It's painful to wait 20 minutes while the framework downloads. Can you do anything about it?"

If anyone reading my blog has a suggestion, I'm listening. But from where I sit, there isn't a whole lot I can do about it. I can't get the developer to drop WPF. I can't drop support for either version of Office and the customer doesn't want to use a physical media distribution model.

I guess all I can really do is hope that people will use Windows Update and that .NET 3.5 penetration will rise. Because while it's really easy for an ISV to develop vertical applications using .NET, deploying them painlessly is an entirely different story.

I'm working on deploying an Office 2007 Add-In, written in VS2008 and using the VSTO 3.0 Runtime. Is there a way to deploy this type of application without using Click-Once and the Office Customization Installer? I want complete control over my deployment and updates, and would love to have it inside an InstallShield Badic MSI project. Do you know if this is possible?