【原文地址】Framework Design Guidelines: Serialization Technology
【原文发表日期】16 February 09 05:58
承接我们每周对框架设计规范第二版中新增部分的系列博文。该内容可以在第八章使用规范中的串行化一节中被找到。
面对有如此多工具的基础框架，知道何时使用何种工具显得尤为重要。
8.10.1 选择使用合适的串行化技术。任何已给的类型可以不支持，只支持一个或者多个串行化技术。
考虑：如果你类型的实例需要持久化或者在Web Service中使用，那么使用数据协定串行化。
关于使用数据协定串行化的细节请参考8.10.2节。
考虑 如果你需要在对在串行化过程中所产生的XML格式更多的控制，那么使用XML串行化，来代替或者补充数据协定串行化。 这可能在一些交互场景中显得必要，当你需要使用不被数据协定串行化所支持的XML构造器时。例如，产生XML属性。
关于支持XML串行化的细节请参考8.10.3节。
考虑 如果你类型的实例需要在.Net远程边界中传输，支持运行时串行化，
关于运行时串行化的细节请参考8.10.4节。
避免因为一般的持久化原因而使用运行时串行化或者XML串行化。优先选择数据协定持久化来代替。
【原文地址】Framework Design Guidelines 2nd Edition: Order Yours Now!
【原文发表日期】14 October 08 09:29
Amazon刚刚把Framework Design Guidelines第二版加入预售清单中。如果你打算参加在洛杉矶举办的PDC（目前仍有空位），你将能成为首批买到书的人……Amazon和你家附近的书店将在今后几周到货。
第二版中有哪些新内容？
- 根据.NET Framework 3.0与3.5中的新特性进行了更新
- 来自行业专家的海量的注解
- 扩展方法（Extension methods）
- Linq，Linq，Linq！！
- 新的异步模式
- 序列化规范
- 依赖属性（Dependency Properties）规范
- 对异常这一部分进行了大量修订
- 某些小地方，诸如操作符参数（operator parameters），DateTimeOffSet，Nullable等
- 几乎每一页都做了些修订，从小的语法修正，到文字阐述。
我已经有了第一版，还用买这一本书吗？
虽然我理所应当地乐意看到各位人手一本第二版（也许可以当作圣诞礼物送给朋友和家人），但如果你已经有了第一版，也许你就不需要这一本了。我们尽力使Framework Design Guidelines中的规范没有时效性……因此并没有对规范做出根本上的改动。因此如果你对你已有的版本感到满意，并且对新版本中新的几章内容没有问题或是没有使用到它们，那你可以无视第二版了。
当然，第一版有可能会成为一件收藏品，因此即使你买了第二版也要好好保存它 ;-)
来订购吧！
【原文地址】FxCop 1.36 Released
【原文发表日期】20 August 08 08:49
David Kean宣布了FxCop 1.36的发布
从David的博客中我们能看到以下几处优点：
现在立即下载它 -- 它是完全免费的！你也可以在代码分析（Code Analysis）论坛中告诉我们你的想法。
【原文地址】New Tools for Framework Designers Published
【原文发表日期】03 August 08 02:53
Mircea近期发布了一套新工具，这也是我们近来对.NET Framework进行设计与架构审查所使用的工具。
你可以在这里下载这三个新工具，Deps，Layering和potentialCallers：
http://code.msdn.microsoft.com/fxarch
享受一下吧！
Deps（依赖）
Deps.exe 可以建立在程序集之间的依赖关系图，并且执行分析以侦测的其中的循环。
其命令行格式如下：
deps.exe {d|s} <mscorlib_path> <path_list> [:assembly_name]
示例：
deps s c:\Windows\Microsoft.NET\Framework\v2.0.50727\mscorlib.dll c:\Windows\Microsoft.NET\Framework\v2.0.50727 :System
这个工具会产生以下文件：
- Full.dot。这是一种graphviz格式的文件，它包含了根据每个程序集所声明的引用项，所描述的程序集之间的依赖关系。
- Api.dot。同样是包含程序集之间依赖关系的graphviz格式的文件，但它只包括了public类型中非private的API签名部分。这种依赖关系也包括了类型自身的依赖性（比方说，某个类型A继承于定义在另一个程序集中的类型B，则这两个类所处的程序集之间就建立起了一种依赖关系的桥梁）。
- Full.txt。这是一个文本文件，它显示了从每个程序集中所关联的所有程序集，并指出它们之间是否存在循环引用（"True"/"False"表达式）。
- Api.txt。作用同上，但仅显示基于API的依赖关系。
- Assembly_name.full.dot和Assembly_name.api.dot。如果在命令行中指定了:assembly_name这个选项，则生成两个graphviz文件，仅包含了所给的程序集与其依赖关系的信息。
如果工具在所给的路径（<path-list>参数）查找不到任何依赖关系，它会将程序集名称放在中括号中记录下来，比如：[something]。Mscorlib也以同样的方式记录。
另外，这工具还能输出某些受到广泛关注的统计信息（比方说，类型的数量，成员的数量等等）。
Layering（分层）
Layering.exe能够确认程序集遵从了架构图的设计
其命令行格式如下：
Layering.exe <diagramFile> <mscorlib> <dirs>
这个工具还会输出一个名为“graph.dot”的文件，显示了在同一个层（layer）或跨多个层中的组（group）的关联，以及那些违反了分层规范的依赖关系。可以由graphviz来处理这个文件。
该文件由层的定义组成，每个层又由组定义，而每个组则由一张托管二进制文件的列表定义。
每个层都有一个序号，第二级的各个层可能有着相同的序号。当所处于较低层次中的程序集依赖于处于较高层次中的程序集时，这个工具就会认为它违反了设计。
每个组也有一个序号，两个不同的组可能有着相同的序号。当处于同一层中，某个较低层次的组依赖于某个较高层次中的组，或是在序号相同的组之间存在依赖关系时，这个工具也会认为它违反了设计。
PotentialCallers（潜在的调用者）
PotentialCallers显示了一系列的方法（method），它们可能会直接或间接地通过一个能够静态地决定（statically-determinable）的调用，去访问某个给定集合的中的任何方法。
其命令行格式如下：
potentialCallers <methods> <mscorlib> <dirs>
这个工具在控制台输出了一系列对列表中任何方法的直接调用，输出可以由graphviz程序捕捉到并处理。
进一步的说明一下它的输出：从A->B的一个调用意味着方法A调用了方法B。如果方法B在集合中，那很显然这个引用必然会包含在输出中。如果B不在集合中，那就意味着B的控制流触及到了集合中的一个或多个方法。
这个工具的完整的输出会包含从一个方法到集合中的某个方法的调用路径中的所有分段。
【原文地址】Framework Design Studio Published
【原文发表日期】04 April 08 11:17
Krzysztof Cwalina 和他的团队成员们正致力于一个工具的开发，使得框架设计者能够更简单地设计、复审与维护高度可用的API……你一定要看看这个Framework Design Studio。
我们将乐于倾听您的意见！
这个工具目前致力于：
- 列出某个托管程序集所暴露的API
- 比较某个程序集的不同版本之间的API
- 复审API，为API设计添加注释，某将复审中所发现的bug存入一个缺陷数据库中（通过一个可配置的插件实现）
- 将API复审的注释导出到Microsoft Word文档中
添加复审注释：
比较API版本：
显示删除和添加的API：
导出到Word：
【原文地址】
Stand alone FXCop download
【原文发表日期】
19 March 08 03:31
如你们中很多人所知的那样，FxCop是一个静态代码分析工具，起初我们用它来确保.NET Framework自身能够符合.NET Framework设计规范。
这个工具现在已经作为“代码分析”这项功能集成入Visual Studio中了，但我们仍然在继续发布FxCop独立版本的下载。
查看FxCop团队博客，并且在Code Gallery下载FxCop 1.35。
【原文地址】Framework Design Guidelines: LINQ
【原文发表日期】13 March 08 07:53
哇噢，好像感觉又回到了过去……我很高兴我们正在为框架设计规范提交一份新的建议作为其扩展。Mitch努力开展了这项工作，并且我们已经进行了内部审阅。现在是时候听取你的意见了，请一定不吝赐教！
LINQ 框架设计规范
谢谢！
