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.
6 comments:
Well, I just don't see "the point". Sure, saving a few MB on the .NET 3.0 framework's rediculous ~200MB size is a good thing, but is this really a best practice? Wouldn't Microsoft have done it if they thought it was?
Compression formats being cab compliant is one of the major things that Microsoft Windows Installer requires. Deployment tools are designed around your install using proper Cabs.
What Microsoft is (or more specifically isn't) doing with their installs have nothing to do with the fact that the MSI spec only supports Cab compliant compression algorithms.
Perhaps my wording of "Best Practices" left something to be desired; however, the fact remains that many installation authoring companies are just walking over what MSI is supposed to do in order to add a bullet point to their feature list.
That's fine & great, but it's starting to get to the point where an MSI is no longer just an MSI. Now it's a Wise MSI or an InstallShield MSI or a WiX MSI or a whatever you used to create it MSI.
So my question is, are they really helping the situation? I don't know about that. My thought is more that they're doing something, but I guess it remains if that's the right thing?
I would like to think that some community backlash on the topic and actually getting in touch with some of the people involved would go further.
To me, reliance on LMZA compression to resolve a fundamental flaw in the whole design of a 3rd party application is just asking for more woes later.
But eh - maybe it's just me? :)
I agree with many of your points. However, at the end of the day, what the Windows Installer team fails to do, tools vendors or setup developers must do on their own. I completely agree that all of the various vendor add-on's such as InstallShield IIS/XML, WiX CA's should be refactored and adopted as standard action patterns. However the MSI team has shown for years now that it's just not a priority to them.
MSI was realeased in 1999. This was back in the day when the 200MHZ Pentium was pretty normal for a corporate environment. Processing power has radically improved since then and additional compression technologies should be supported. In other industries you see MPeg2 being replaced with Mpeg4/h.234 and others yet in MSI we keep sticking with the same old same old.
And I wouldn't say that LMZA `solves` the .NET problem... it's just a best effort to try to do something. But shouldn't every package have a best effort to be compressed as optimally as possible? I think so.
My thought is more on the topic of accomplishing your first point, which is that the Windows Installer's priorities are not in any way in-line with what their users actually want to accomplish.
I hate to go all over the place, but posts about how CA's are evil and terrible are an admission of failure make me wonder (especially when written by Rob Mensching) if they're directed at the community or the MSI team themselves.
What should be supported and what is supported are, unfortunately, two different things. In my perfect world, MSI should just provide simple callbacks you can override with whatever the compression algorithm you want can handle. Or they should just leave the compression thing alone and make the best practice that you handle it through your setup.exe or something like that.
I don't know what the full solution would be, but I will not argue that their current path is the wrong one.
My argument is that most seem to be content with violating the rules and making it a bullet pointed feature. Should package vendors be building the most compressed package available? I guess I don't know. On one hand I say "Yes", but the other hand says "No".
But I do know that had the .NET team made customer-friendly decisions regarding their deployment strategy, this conversation would likely not be happening.
I see a lot of overlapped but yet separate pieces here, and they each lead to different questions and answers
1) The full .NET 3.5 redist is huge
2) Alternate compression technologies could mitigate that (but the EULA does not permit it)
3) Windows Installer is stuck with a set of built-in deployment capabilities that offer a decreasing coverage of what setups must accomplish
4) Windows Installer, for all that it's an open format, is stuck on old compression technologies (not only does the EULA probably not permit it, but the closed implementation does not enable it)
The size of the .NET 3.5 redist doesn't bother me. It is insane, but it's not like you're expecting each customer to download 200MB; if you were, you'd use the small downloader which downloads maybe a third of that max (32 vs 64-bit; pre vs Vista). And if you can't make room for 200MB on a DVD or a network server, don't use 3.5. Maybe I'm favoring the wrong spot on the compression-performance curve?
Alternate compression technologies making this even smaller would be a good thing, but the right place for this is like the missing standard actions: upstream. Meanwhile I know I wouldn't want to risk breaking the redist by trying to shrink it; it's bad enough to have to cover for the blogged data-risking bugs.
Due to its extensible nature, missing upstream support for new installation patterns isn't a fatal flaw, but does lead to fractured results at odds with Windows Installer's open nature. Though since I am paid to extend MSI, I'm not about to fight hard for this to change. Furthermore, is everyone ready to require the latest version of Windows Installer just for some new action you could do in any version with a vendor-specific solution? We won't be able to take our custom support out just because version next will have something native.
The last is actually what I want to see most. I'd really like to be able to plug in my own file archive format. Let me stream a dll which translates simpler requests (give me the data stream for filekey xyz) to whatever I want (zip, rar, local server download), and then Windows Installer no longer is tied to 16-bit friendly archives.
And yet each of these just leads to further complexity in either Windows Installer or its packages, and between that and the larger systems in which they interact, we will continue to see more failures. It's a tough shell to crack.
I have stopped distributing the .NET Framework with my installations. There are too many issues that can arise, and technically the user should accept the license from MS before installing it on their system. I think that is why Rob has a fundamental issue with it.
I put the check in the installation and force the user to download and install it themselves if they don't have it.
You can override with whatever the compression algorithm you want can handle. such as InstallShield IIS/XML, WiX CA's should be refactored and adopted as standard action patterns
Post a Comment