不过，有些人做事比较马虎，经常就是直接将VS生成的解决方案目录直接打包，这样就会包含大量垃圾文件，诸如：obj目录下的所有文件，而且有时bin目录还有二个目录，PDB文件有二份，甚至连xxx.vshost.exe文件也有二份！更让人无语的是，有些人用SVN这种源代码管理软件，每个目录还有个.svn目录！
这种做法显然很容易将一个不大的项目搞成一个比较大的压缩包，这种压缩包一旦做好，上传也慢，人家下载也慢，还会浪费许多服务器资源，下载到这种压缩包，只能让人无语了。没办法，有些人就是很懒，而且那些压缩软件也不懂这是个源代码目录，反正是见文件就压缩！虽然很悲剧，但悲剧却一直在重复上演！现实就是这样，估计有些人已经麻木了！
我是个追求完美的人，自然是不希望让悲剧在我这里重复上演。我不希望浪费我的上传时间，不希望浪费服务器的硬盘资源，不希望浪费服务器的带宽，也不希望浪费所有网友的下载时间，更不希望有人会因此而骂我。因此我每次做出来的压缩包是不包含那些垃圾文件的。我是如何做的呢？很简单啊，不要把一些垃圾文件打包进去不就好了吗？还要怎样？
不过，我也很理解一些懒人，每次打包前去把这些文件找出来，删除它们，也是有些麻烦。当然了，我也不愿意每次都做这种机械的事情，我也想偷懒。
嗯，既然打包前删除这些垃圾文件是件机械的事情，那么能不能搞个程序去做呢，我是程序员啊。
终于有一天，我也受不了了，尤其是我平时喜欢写点小东西，每天改了之后要备份，也要用压缩包，但我不想浪费硬盘空间啊。在一次一次地被那些压缩软件折磨后，我还是选择自己来设计一个工具来专门解决这个问题。不就是个压缩的事情不好解决嘛，那我就自己做吧，反正现在的压缩类库是一大把，不过，我最终还是选择了Windows自带的FCI/FDI接口，它能直接生成cab格式的压缩包，且现在流行的各种压缩软件都能支持它。选择它还有其它原因：1.我早在使用C#之前就已经使用过它了，有现成的包装库（C语言版的，速度还不错），2.由于是Windows自带的接口，因此不需要引入额外的组件，工具可以保持较小的体积， 3.cab算法的压缩率还不错，比zip要好(与rar相当，比7z差点)。
今天，我将向大家推荐一个我几乎天天在用的工具。它能很完美的解决以上问题，它还有其它功能，我也非常喜欢它。下面，我就来介绍此工具。
记住哦，这个工具的名字叫：FishCabTool
工具介绍
来看看我的工具吧，总共由4个文件组成：
虽然是4个文件，但依然很小，离300K还有些距离哦。下面来依次介绍这4个文件的用途：
1. FishCabToolHelp.chm，它是一个帮助文件，介绍了工具的特色功能，操作方式，以及其它说明：
2. FishCabTool.exe，它是这个工具的主程序了，是一个WinForm程序，运行界面如下：
通常，并不需要直接运行它，而是从资源管理器的上下文菜单中启动它，操作方式与现今流行的压缩软件一样，如下图。
3. FishCabToolExt.dll，它是一个Windows资源管理器的插件，可以让我的工具也能像一些压缩软件一样，直接在Windows资源管理器的右键菜单中操作，如下图：
为了不影响操作体验，这个插件采用ATL的方式实现，因此速度还是很不错的。说到速度，再给个具体的数据吧：当年在开发这个工具时，是在一台（02年的）老机器上进行的，由于机器配置较差，所以性能相当敏感。测试时我选择Windows/System32文件夹下的所有文件，右击鼠标并测量菜单出现的时间，WinRar V2.6花了27秒，7z V4.x花了差不多8秒，我的工具还不到3秒。所以，不要担心这个插件的会影响您的机器性能。
说明：FishCabToolExt.dll采用Unicode方式编写，所以理论上即使不是简体中文的Windows下也能正常显示汉字。
4. FishCabLibU.dll，它是一个包装层，用于封装Windows的FCI/FDI接口，因为这二个接口是基于C的，且接口较为复杂，我也只好用C来封装了，并以标准的导出函数提供给其它编程语言调用。导出的API函数如下图：
在写这篇博客时，看到当年给这些API取的名字，我也郁闷了：这些名字也太乱了吧。哎，2004年咱的命名规范还真差劲啊。