微软的框架设计规范是设计的准则，它期望所有的微软类库和独立开发者都能够遵循这一准则。随着每个.NET框架版本的发布，以及在行业内的测试，它们的版本也得到了精化。通过Cwalina与Abram所著的《框架设计规范》第二版的发布，我们可以看到微软在今后几年的发展方向。

或许最令人惊讶的事实是日渐增长的对于测试驱动开发和依赖注入的重视。在可重用框架的场景下，通过测试驱动开发设计出的框架是真实可用的，而不是简单地推理。他们希望这样可以反过来杜绝某种趋势，那就是过度复杂地设计一些根本不会用到的功能。

谈到这一问题，就不得不指出的是微软当前正在推动的一个活动，即针对所有库的第1个版本进行最低限度设计。这不同于在第一次就要试图将所有事情做对，微软推荐在最开始只需要满足需求中绝对需要的特性。Abrams和Cwalina建议在最初并不需要考虑扩展性，只有到需求变得非常清晰的时候，才在后一个版本中考虑。从某个方面来讲，这是微软旧有传统的回归，它只会在第三个版本中提供真正完成的应用程序。

在其它领域，微软则完全没有改变。他们仍然强调所谓的“基坑成功（Pit of Success）”，并将其作为设计圭臬，特别是在谈及开发者的生产力时，尤其如此。例如，对于Exception类的构造函数应该定义为protected，而不是public，这就可以强迫开发者采取正确的方式，抛出一个适当的异常。相反地，我们现在必须借助于FxCop准则对此进行检查。

他们不断鼓吹的另一个原则是“相同的力量”，对这一目标的追求可以使得新类库的工作方式，对于其他.NET类库的用户而言是直观的。它被应用在代码的各个方面，包括命名规范、术语约定以及设计模式。

微软强调的新增内容是依赖注入。虽然他们总是被用在各个类库中，但从未如此正式地将其看作为一种设计模式。相反，它仅仅在API需要时作为一种补充。这种情况到了.NET 3.0有所改变，依赖注入与控制反转都是一种特定的要求。

一旦涉及到CLR顶端的技术，框架设计规范就是不可知的。例如，微软并没有用它来推动依赖注入类库，即托管的可扩展性框架的运用。相反，其重点放在设计目标、编写松散耦合、可测试的代码上。

在PDC中，特别强调了某些特定的建议，包括：

类的构造函数应该是延迟的。从本质上讲，他们所要做的不仅仅是要捕获参数，因为通常不会用到新的被实例化的类。

属性应该：

不要抛出异常（getter）
不要被用作转换（getter）
不要产生副作用（setter）
足够快速，而不用考虑对象的状态
永远不要返回一个数组，或者一个克隆的列表（getter）
扩展方法应该用于为接口“添加”重载，也可以用于管理类库之间的依赖。例如，如果程序集B依赖于程序集A，则A中的类不会暴露B中的功能。然而，A中的类可以通过B中的扩展方法进行标记，提供依赖的效果，但实际这种依赖并不存在。

对于类的层级，总体不应超过2到3个层级。过深的层级会导致很难保证每个实现，因为实现必须遵循整个契约。谈到这一问题，其中至关重要的一点，就是为了保证工作正确，任何重写的成员都应该具有一个显式的契约细节，以包含子类需要做的内容。

接口应该小，最好只包含一个方法。每增加一个额外的方法，就可能使得接口难以正确设计，而在将来甚至会需要更多的方法。如果不适用于抽象基类，可以将接口串联在一起，以构建其功能。