【原文地址】100+ PDC Sessions Posted
【原文发表日期】04 August 08 07:33
我刚刚看到,我们已经发布了新一轮的PDC的议程……近年来,我还是首次没有直接参与PDC的计划。因此,观看这届会议的展开对我来说会是件有趣的事……
https://sessions.microsoftpdc.com/public/sessions.aspx
如果你还没有注册的话,那么赶在8月15前注册,你还有机会获得折扣。
我想在这里特别强调其中的一部分与我相关的议程,我将乐于倾听您的意见,以及你对今年的PDC的任何其它想法。
在Dev 10中正在进行着一些非常酷的工作,能够以方便得多的方式发布ASP.NET应用到测试环境与运行环境中,以及内部的web farm和更大的host环境中。
把它想象成是面向大众的Surface ;-)
我很喜欢这些deep dive的讲座,尤其是伴随着Silverlight 2的发布,我想很多客户也希望看到他们能够发挥Silverlight最大的功效。你们觉得我们是否应该在同一个讲座中涵盖WPF图像处理的基础知识呢?
我与许多对企业级RIA应用深感兴趣的客户进行了交谈,这次谈话将会展示一些模式以及某些未来的产品方向。你们有什么杀手级的场景可供我们作为示例呢?
我们应该为此找一个更好记的标题,不过我们的目标是告诉各位,我们正考虑在未来的产品中实现从各位那里收到的关于ASP.NET的方向的建议。同时我们希望能够获得你们的反馈意见。
你一定得参加一次MVC的讲座——尤其是这一堂,它将力求向你介绍MVC……你们是否认为我们也需要做些更深入的钻研呢?
.NET最强大之处就在于一种一致的端到端的连续……这堂讲座会展示如何利用Silverlight与WPF之间的兼容性来共享代码与设计,以最大化这两个平台的价值。是否有哪位已经尝试过了?哪些部分运行良好,又有哪些部分是你们需要更多指导的呢?
IE8做了大量的工作,使得ajax的开发者能更高效地工作。
你们是否对了解所有的控件(包括了一些新的控件),以及学会如何最大程度地掌握它们更感兴趣,或者是如何创建你自己的控件呢?
Chris Anderson与Don Box的表演又回来了!纯粹为了娱乐,这也是你一定要看的.
我们已看到了对于.NET上的并行计算的热爱这一"地隆"(groundswell)现象……这堂讲座中将会谈到我们正在Visual Studio与.NET中所做的一些很酷的东西,以简化这方面的编程工作。
虽然我没有深入地参与到这门讲座中,但VS正开始拥抱TDD,重构以及其它的敏捷方法,这真是太棒了!
有谁能错过Anders Hejlsberg呢?上一届的PDC,Anders为我们介绍了Linq……今年又会是什么呢?
公平起见,Paul Vick将会向你展现VB的发展方向……
【原文地址】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的控制流触及到了集合中的一个或多个方法。
这个工具的完整的输出会包含从一个方法到集合中的某个方法的调用路径中的所有分段。