tag:blogger.com,1999:blog-9537945.post-6779257052677127912007-12-21T11:08:00.000-06:002007-12-21T11:08:00.000-06:00I see a lot of overlapped but yet separate pieces here, and they each lead to different questions and answers<BR/> 1) The full .NET 3.5 redist is huge<BR/> 2) Alternate compression technologies could mitigate that (but the EULA does not permit it)<BR/> 3) Windows Installer is stuck with a set of built-in deployment capabilities that offer a decreasing coverage of what setups must accomplish<BR/> 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)<BR/><BR/>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?<BR/><BR/>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.<BR/><BR/>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.<BR/><BR/>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.<BR/><BR/>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.Michaelnoreply@blogger.com