Comments on DeploymentEngineering.com: .NET Framework Size

I have stopped distributing the .NET Framework wit...

2007-12-21T11:32:00.000-06:00

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.

I see a lot of overlapped but yet separate pieces ...

2007-12-21T11:08:00.000-06:00

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.

My thought is more on the topic of accomplishing y...

2007-12-21T10:54:00.000-06:00

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 agree with many of your points. However, at the...

2007-12-21T08:47:00.000-06:00

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.

Well, I just don't see "the point". Sure, saving ...

2007-12-21T08:31:00.000-06:00

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? :)