我正在评估将 CAB 用于新的 .net 3.5 winform 项目的过程
我计划使用 Infragistics 工具集，它被称为“符合 CAB 标准”
虽然 CAB 的直接优势是让我专注于我的业务，而不是编写基本的对接/登录/等代码，但我觉得我自己能够非常迅速地实现相同级别的功能（增加了灵活性/反应性奖金当你'拥有'代码时你有）。
我正在向使用它的人寻求一些关于微软 CAB 的反馈：
几年前我有一些使用 CAB 的经验，我的结论是它太复杂并且学习曲线陡峭。因此，它提供的好处不值得为加快速度而付出代价。但是，不要相信我的话，尝试关注他们的一些实验室，看看你的想法。
Jeremy Miller 撰写了一系列关于构建自己的 CAB 的优秀博客文章
这些值得一看，因为您可以从那里获取您需要的东西。
我的建议是继续你的项目，而不是预先构建一个框架。随着项目的发展，您应该发现将代码重构为基类并有效地从应用程序中获取框架的机会。
这样，您最终将获得一个满足您需求的框架，并且开发团队中的每个人都会理解。无论你做什么，都不要预先构建一个框架——这就是毁灭之路:-)
我们已经在几个项目中使用了 CAB+SCSF。学习曲线确实很陡峭。您可能会在第一个月后跟上进度。其他缺点：
优点：
遵循业界最佳实践架构设计模式：
从长远来看，使用 CAB-SCSF 将意味着更少的错误和更可维护的代码。如果您的项目能够承受学习曲线的初始冲击，我肯定会推荐它。
虽然我从未真正使用过 CAB，但它附带了源代码，因此如果您需要应用程序块未提供的额外灵活性，您仍然可以对其进行调整以满足您的确切需求。
我们已经在 CAB 框架上构建了我们的企业应用程序，但是已经修改了它的许多部分以满足我们的需要。
从那次经验中，我可以看出 CAB 更适合，当你需要一个非常灵活和模块化的架构，并且在 ui、业务逻辑和数据层的开发之间有明确的划分。
CAB 确实存在生成大量代码的缺点，有时会诱使开发人员使用复杂的机制来实现简单的结果（例如过度使用事件发布/订阅模型，即使是最简单的 ui 的 mvp 模式，...）
如果您想对此进行介绍，请访问 http://richnewman.wordpress.com/intro-to-cab-toc/上的 Rich Newman 的精彩系列
如果您只想使用依赖注入/控制反转，那么托管可扩展性框架 ( http://mef.codeplex.com/ ) 可能是一个非常好的、轻量级的替代方案。