Friday, May 30, 2008 8:00:07 AM UTC #

Before I start, I'd like to acknowledge the fact that having strong opinions about an obscure Windows command-line utility is so not cool. I'm with you.

Things I don't like about using MAKECAB.EXE:

  • If you forget to set an obscure property in your DDF manifest, MAKECAB will silently and happily exclude large files, despite the fact that you explicitly included them in the DDF manifest. Not only is this bad error handling, but it also gives you a false sense of security. This leads to the most awful troubleshooting sessions, where you have to dig into every layer of the stack, before coming back and double-checking every layer. This aggravating troubleshooting session is followed by a brief eureka moment, followed immediately by intense rage.
    Obscure property to set: .Set MaxDiskSize=<<some massive bytecount, I'd go 1 billion plus>>
    • Fun footnote: most online samples fail to set this obscure property, including MSDN and several blogs who obviously copied their DDFs from MSDN, which is why this is such a huge problem. Very few of the online examples get this right!
  • The MAKECAB.EXE SDK document uses Times New Roman as its font. That dates it at pre-1997, when we were all still using either Office 6.0 or Office 95. Awesome. This isn't a complaint as much as it is an observation—OLD!
  • Diamond Directive Files! DDF manifests are awful and, in my limited needs, completely unnecessary! Whenever I need to build a CAB file manually (it's happened a few times), I fired up PowerShell and used a single CabLib Extract/Compress function call to do the same thing that your no-longer-necessary-but-you'd-better-get-all-the-syntax-perfect MAKECAB+DDF file solution did.  And I didn't even have to bust out the ancient Times New Roman-sporting manual! (see below for actual script; it's tiny)

Takeaways

  • Obscure property to set in your DDF manifest: .Set MaxDiskSize=<<some massive bytecount, I'd go 1 billion plus>> 
  • If you're using MAKECAB.EXE as part of your Visual Studio build process, switch to WSPBuilder! You're not losing anything by swapping out one post-build command-line EXE for another, and will gain MUCH more in WSPBuilder's functionality.
  • Use the following PowerShell snippet (or use it as a starting point for your own improved version) to compress cab files:

 image

Copy-pasty version:

function Compress-Directory ($dir, $cabFileFullPathAndFilename)
{
    [void][reflection.assembly]::LoadFile(
        "C:\Program Files\WSPBuilder\CabLib.dll")
    $c = new-object CabLib.Compress
    $c.CompressFolder($dir, $cabFileFullPathAndFilename, $null, 0)
}

Compress-Directory "C:\temp" "C:\sandbox\a.cab"
Friday, May 30, 2008 8:00:07 AM UTC  #     |  Comments [3]  |  Trackback
Friday, January 30, 2009 3:13:03 AM UTC
Peter,
I never thought I'd end up spending so much time and energy fighting MakeCAB's idiosynchosies, but, like you, this has been my fate. I'm curious if you or any others have run into the problem I've run into. I have an application that invokes MakeCAB as part of a custom action in the Windows Installer. We've recently discovered that when run in this way, MakeCAB tries create several temporary files in the Windows\System32 folder. We were not aware that it was doing this because it didn't cause trouble on Windows XP. When run under Vista, however, this attempt is simply not allowed, and the custom action is failing. I've recently come across CABLIB and am hopeful that substituting it for MakeCAB will let me regain control over this frustrating situation. If I could figure out how to force MakeCAB to behave itself and only create files in the folders were the the application's files exist, I would not have to replace MakeCAB with something like CABLib. Have you ever heard of anything like the behavior I describe, and do you have full confidence in CabLIB as production code?
...Jim Black
Friday, January 30, 2009 4:43:49 AM UTC
I'd trust CabLib for reasonably small cab files, as we (the SharePoint developers) have hammered WSPBuilder, and by extension its use of CabLib. You can check the WSPBuilder (codeplex.com/wspbuilder) issues page to see what I mean.

But if you're packing a lot of files or really huge files, I don't know. I'd certainly trust it as much as a commercial Cab library.

On the "trust it" side, I'm pretty sure CabLib just hooks into the built-in Windows API calls which do the real work. On the "don't trust it" side, I haven't tested it with anything more than SharePoint deployments and manually editing one or two site exports (~50MB CAB file) that I didn't have the wisdom to work around some other way.

So, maybe.
Peter Seale
Friday, January 30, 2009 4:45:52 AM UTC
Also given your specific behavior, and because CabLib just hooks into the Windows libraries anyway, you'll have to test out CabLib to see if it's making files in system32 as well (i.e. test your Vista problem with CabLib). It's CAB, so I wouldn't be surprised if it hasn't been updated since 1993 or whenever they wrote that ancient Word document explaining how it works.
Peter Seale
Name
E-mail
Home page

Comment (Some html is allowed: a@href@title, b, blockquote@cite, em, i, strike, strong, sub, sup, u) where the @ means "attribute." For example, you can use <a href="" title=""> or <blockquote cite="Scott">.  

Enter the code shown (prevents robots):

Live Comment Preview
Syndication

Search
Posts on this page
Categories
Sites I visit regularly
About

Powered by: newtelligence dasBlog 2.2.8279.16125

Disclaimer
The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.

© Copyright 2010, Peter Seale

Send mail to the author(s) E-mail



Sign In