【原文地址】Quick Update
【原文发表日期】 Tuesday, September 02, 2008 5:21 AM

我最近收到了不少（好心的）电邮，询问我是否安好，因为在过去的几周内（以及几乎整个夏天），我的博客没什么动静。

就为了答谢大家的关切，我还活着，好着呢，:-)。过去的六周，我在度假，不幸地是，没有空发贴子，但换了很多尿布。

在正式回去上班之前，我还要度一个星期的假。但这个周末，我找到时间写了一篇讨论 ASP.NET MVC第五个预览版中一些新特性的贴子，希望在我上班后恢复正常的发帖日程之前，能给你提供一些临时性的阅读材料。

谢谢，

Scott

【附注】 有点不好意思，就在我去度假前，我刚开始撰写关于“第四个预览版”分成二部分的贴子，但在“第五个预览版”出来前没有时间完成第二部分。在这个月稍后，我会贴出这第二 个部分（是讨论AJAX的），其内容将针对ASP.NET MVC最新的版本。

【附注二】 经常有人问我，我的博客是否是我自己写的。没错，每篇帖子确实都是我写的，希望我过去6周的缺博提供了支持这个答复的一些证据，:-)。

今天从Oren Eini的博客上看到一个很幽默的录像，说实话，都有点心酸的感觉，估计几乎每个开发人员都会有同样的感觉

http://blip.tv/scripts/flash/showplayer.swf?file=http://blip.tv/rss/flash/1067270

请各位老板，开发主管，项目经理，今天一定要去拥抱一下你的开发人员！

 [附其中一些文字的粗浅翻译]

Developers everywhere are in terrible pain.
不论何地，开发人员都是痛苦无比。

I am in pain.
我很痛苦。

We're 4 months into a 5 month schedule and I just received the final requirements yesterday (and they've changed again!)
5个月的日程，开发已经进行了4个月，我昨天才收到最后的需求，而今天，这些最后的需求又变了！

I spend half my days in meetings about how to get more work done (instead of working)
我一半的时间都陷于讨论如何完成更多的工作的会议中，而不是做工作

My boss read in a magazine that developers using "_____" programming language are twice as productive. So he bought us a copy and cut our schedule in half.
我们老板在一本杂志上读到使用某种编程语言的开发人员的效率高2倍之多，所以他给我们买了该语言，然后将我们的日程切掉一半

Every day my boss changes his mind about what we're building
对我们该开发什么，我们老板的主意每天一变

（父亲）People keep asking me to fix their e-mail, so I have no time to code
大家不停地叫我修补他们的电邮，所以我根本没时间编程

（儿子）My daddy has no more time for me
我爸都没时间陪我

Some consultants told my boss they could build our next version in half the time, for half the money. He believed them, but now they've spent all their budget, used all their time and ...are still only half finished. Now they're gone and their code is a disaster. We have to fix it and finish what they started
某些咨询师告诉我老板，他们只要一半的时间，一半的经费就可开发我们下一个版本。他信了他们，但现在，他们花完了预算，用光了时间，还只完成了一半。现在，他们走了，而且他们的代码糟糕无比，我们没有办法，只能来完成他们尚未开发完的东西

Hug a developer today.
今天，请去拥抱个开发人员

（小孩）I just finished an intensive 6 week visual basic course
我刚完成一个6星期的visual basic速成班

上个月家里的电话账单里夹了一张TD-SCDMA的宣传材料（大图）。其中关于TD-SCDMA网卡和CDMA 1X网卡对比的部分，非常颠倒黑白，误导消费者：

关于便携性，的确，USB棒的体积比PCMCIA卡的体积小。但是，很多用CDMA 1X网卡的人都是长年把卡留在PCMCIA插槽里面的，有些只留一截天线在外面，有些连天线都可以在不用的时候收进去。而用USB棒当无线上网卡的话，不用的时候必须拿下来，否则长长的凸在外面，笔记本电脑放不进电脑包。而且，无线宽带上网都是在移动环境下的，比如咖啡馆、地铁、公交车，USB卡很突兀的插在笔记本电脑上，很容易被折坏。以前第一版的iPod Shuffle就曾经传出容易被折断的消息。所以，虽然USB棒的体积比PCMCIA卡的体积小，但便携性反而是PCMCIA卡更好。

关于使用环境，的确，很少有台式机支持PCMCIA接口。但是，有多少用户会在台式机上面用CDMA 1X或者TD-SCDMA上网呢？绝大多数的台式机要么有有线的宽带，要么连一个无线的AP。统计一下CDMA 1X或者TD-SCDMA的用户，笔记本电脑的用户绝对是压倒性多数。所以，关于“CDMA 1X受PCMCIA接口限制，不支持台式电脑使用，只支持笔记本电脑使用”的说法，虽然正确，但毫无意义。

宣传材料想要突出某产品的优点，必须实事求是，而不能从一个正确的事实出发，以错误的假设和推理，得出一个荒谬、无意义或者错误的结论。

今天碰到了一个超级怪异的问题， Visual Studio 调试一段代码时，如下图：监视窗口显示这个变量有值，但是代码却执行到这个变量无值的逻辑中了。

为了这个问题，我简直疯了。

后来看到其中一些变量的察看时，会报错误

Cannot obtain value of local or argument 'oo' as it is not available at this instruction pointer, possibly because it has been optimized away.

在装配脑袋的提醒下，觉得可能是Visual Studio的代码优化导致了这个问题。

取消编译时候的代码优化。 再Debug，就没有这个问题。

竟然是代码优化导致了这个让我困扰了一下午的问题。

代码优化取消在下面位置， 取消 Optimize code 之前的 CheckBox 即可。黄线上面的选项

[原文链接]：  STA Thread vs. MTAThread(WHost)

          最近我遇到一个有趣的线程问题，想跟大家分享一下，以免大家也遇到这种容易混淆的问题。

          打开一个其他人写的C#程序，为了下面的讲解，我把这个程序叫作”DeltaEngine”。DeltaEngine会调用一个本地的程序集，并处理其中某些事件。然后建一个工程，把DeltaEngine作为库项目引用，这个工程又被一个VB程序引用。我把这个VB程序叫做"VBApp"。所以，引用结构就像： 

         VBApp (VB) -> DeltaEngine (C#) -> NativeCode

      当我把VBApp作为启动程序运行时，它会一直等待NativeCode里面的事件在DeltaEngine中被处理。我注意到，如果我把DeltaEngine作为启动程序来运行的话，事件就会像预期那样得到处理。我花了很多时间想解决这个问题，但还是很困惑。

      最后有人指出，VB项目的默认线程模型是单线程套间（SingleThreaded  Apartment），而C#项目的默认线程模型是多线程套间 （Multithreaded Apartment）。因为DeltaEngine最初是作为C#工程开发的，被默认为使用MTA。当使用VBApp作为启动程序调用DeltaEngine时，DeltaEngine就会使用STA。因为这样，DeltaEngine就会开始等待其实它已经唤起的事件，所以DeltaEngine会一直等待下去。如果我把DeltaEngine作为启动程序运行，它就会使用MTA并且会像预期那样工作。

      解决的方法就是把MTAThreadAttribute加进VBApp的主函数里面。如下：

    <MTAThread> Sub Main()

      类似，如果你想把STAThread attribute加进C#的主方法里面，如下：

      [STAThread]

      static void Main()

      WindowsForms程序要求使用STA，所以创建C# Winapp后，你可以在Program.cs看见像这样的代码。

      我就不重复一些已经有的关于STATread 和MTAThread的文件，所以我给出下面的一些link可以学到更多关于STATread 和MTAThread的东西。

     STAThreadAttribute

      http://msdn2.microsoft.com/en-us/library/system.stathreadattribute(VS.71).aspx                           

      http://blogs.msdn.com/jfoscoding/archive/2005/04/07/406341.aspx

      MTAThreadAttribute

      http://msdn2.microsoft.com/en-us/library/system.mtathreadattribute(VS.71).aspx

悄悄的，Windows SharePoint Services 3.0 SDK v1.4发布了。还有Microsoft SharePoint Administration Toolkit v2.0。

（原文 - Harry Miller：http://blogs.msdn.com/vsto/archive/2008/07/18/removing-customization-code-before-e-mailing-a-document.aspx）

　　为一个 Word / Excel 文档创建 VSTO 自定义代码之后，这个文档的后续拷贝也会和这些代码关联，哪怕你“另存为”的时候换一个文档名字，关联依然存在。每次文档被打开的时候，它就会试图去寻找关联的 VSTO 代码并且开始运行。问题来了：如果我们需要把文档发送给外部人员呢（比如客户、供应商）？他们没有权限访问到我们的内部网络，文档也就找不到关联的代码，于是一个讨厌的错误对话框就会跳出来，告诉一头雾水的用户“无法找到或加载自定义程序集”，对于普通 Office 用户来说，这简直就是天书一样的信息。

　　所以有时候我们需要在向外派发文档之前移除文档和 VSTO 代码的关联。

　　一个方法是手工在文档的“属性－高级属性－自定义”项目中删除“_AssemblyName”和“_AssemblyLocation”属性。

　　另外一种方法是通过编程，使用“ServerDocument.RemoveCustomization()”方法，可以解除文档和代码的关联。VSTO 文档中的示例程序包含了相关的代码可以参考。

相关资源：

ServerDocument.RemoveCustomization 方法（2007 Office 系统）
ServerDocument.RemoveCustomization 方法（2003 Office 系统）
ServerDocument 示例代码
使用 ServerDocument 类在服务器上管理文档

今天IE 8 Beta2发布，第一时间安装到了自己的电脑上。感觉尚好，只是在打开新的Tab，或者关闭某个Tab时，IE8不断的Crash（不过现在IE8终于不再像IE7那样，一个Tab的Crash会搞死整个IE了。）将IE中所有的Add-on都Disable掉，终于好了。

-------- 从爱枣报学来的分割线 -----------

在第一篇文章中，我讲了如何使用Feature Stapling来自定义网站初始化过程，但是Feature Stapling还是有一些限制的。相比之下，虽然创建一个定制的Site Definition要更加复杂一些，但确实可定制性要更强更灵活。如果再配合上Site Provisioning Engine，那简直可以说是强大无比了。

首先澄清一个概念。在一个SharePoint网站的网站设置页面中，使用“将网站另存为模板”链接，管理员可以将整个网站保存为一个扩展名为.stp格式的模板。使用这个stp网站模板，管理员可以重复创建同样结构（和内容）的新网站。那么这种stp格式的网站模板，和我们下文所说的Site Definition有什么区别呢？简单来说，Site Definition是一种通过磁盘上的一系列文件（包括xml、页面模板文件等等）来对一个网站的结构和内容进行描述的一种方式。Site Definition可以对一个网站模板的方方面面进行非常细致的定义，基本上无所不能。而stp网站模板只是一种简单的将一个已存在网站进行转存之后，可以重复使用的网站模板格式。stp网站模板没法直接修改，没太多可控性。下文中说的“网站模板”一次，默认是指Site Definition。

接着来详细说一下Site Definition。在SharePoint服务器的“Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\2052\XML”位置，有一堆以WEBTEMP开头，扩展名是.xml的文件。这些WEBTEMP*.xml文件，就是SharePoint中用来标明Site Definition的文件。

我们在SharePoint中创建一个新网站时，有一个“工作组网站”的网站模板可以让我们选择。打开“WEBTEMP.xml”文件，就能看到这个“工作组网站”的Site Definition。



在WEBTEMP*.xml文件中，“<Template>”节点表示一种Site Definition，它的“Name”属性指明了这个Site Definition保存在“Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\SiteTemplates”中的哪个子目录中。一个Template可以包含多个子Configration。一个Configuration对应到一个用户所理解的网站模板。如果我们需要多个网站模板，它们大致相同，只有一些微小的地方有区别，那么我们就可以只定义一个Site Definition，然后用这个Site Definition的多个Configuration来体现这多个网站模板的不同之处。

在上图所示中，我们可以看到，其实“工作组网站”、“空白网站”、“文档工作区”这三个网站模板，都是同属于“STS”这个Site Definition的三个Configuration。“STS” Site Definition位于“C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\SiteTemplates\sts”目录中。

当然，WEBTEMP*.xml只是让SharePoint知道有哪些Site Definition，以及每个Site Definition中有哪些网站模板（也就是Configuration）可用。但是具体每个模板中包含的内容，包括列表、文档库、页面、页面上的web part等等等等，都是定义在Site Definition中的ONET.XML文件中。比如，下图就是“STS” Site Definition的ONET.XML文件。

ONET.XML几乎定义了一个网站模板的方方面面。比如，为什么使用“工作组网站”模板创建的新网站的default.aspx页面，在页面右侧会显示一个SharePoint的Logo图片？这是因为在ONET.XML里面有下面的内容。

于是我们就看到了

现在你应该已经明白了Site Definition是怎么回事，以及它是如何起作用的。了解这些之后，我们就可以根据自己的需求，来创建自己所需要的Site Definitiion了。你一定要记住一点：永远不要修改SharePoint自带的Site Definition。这是因为微软可能在某些后续的Service Pack或Hotfix中，用更新的文件覆盖旧的Site Definition文件。

创建新的Site Definition的基本步骤是：

1、找一个磁盘上已有的，用来起步的Site Definition，将这个Site Definition目录复制一份；
2、创建新的WEBTEMP*.xml文件，比如WEBTEMP.MySiteTemp.xml，在里面写明新的Site Definition的名称（也就是Site Definition所在的目录名），Configuration等等；
3、修改这个新Site Definition的定义文件直到满足你的需求为止；
4、IISRESET

接着介绍Site Provisioning Engine。什么是Site Provisioning？当你在SharePoint里面，使用某个网站模板，创建了一个新SharePoint网站，这个过程就叫做Site Provisioning。（干嘛不直接叫做Site Creating？嗯，有时候用用时髦词挺Cool的，不是吗？）SharePoint内置了一个Site Provisioning Engine，来完成Site Provisioning过程。这个过程包括给站点应用模板、将所需文件“拷贝”到站点中、根据网站模板类型进行一些其他的必需操作等等。但是，这个Site Provisioning过程也是可以自定制的。

一个Site Provisioning过程，需要由一个继承自Microsoft.SharePoint.SPWebProvisioningProvider的类来完成，具体点说就是由这个类的Provision()方法来完成。所以我们如何自定制这个过程呢？写一个新类，继承自Microsoft.SharePoint.SPWebProvisioningProvider，然后重载Provision()。

我们来用一个实际的示范进行讲解。用户的需求是：“工作组网站”这个网站模板的首页的右侧那个SharePoint Logo图片实在碍眼（没错，就是上面那个截图中的图片），能不能创建网站后，不要那个图片了？当然，我们可以创建一个新的Site Definition，然后修改新Site Definition的ONET.XML文件，去掉这个web part，但是，因为演示的缘故，我故意不用这个简单的方法，而用更“高级”的定制Site Provisioning来完成。

由于“工作组网站”这个模板的其他部分并不需要调整，所以我决定新建一个WEBTEMP.CustomTeamSite.xml文件，并在文件中创建一个新的Configuration。

上图中的名称为“定制工作组网站”的“Cinfiguration”节点有两个属性，“ProvisionAssembly”和“ProvisionClass”，这两个属性指定了这个Configuration使用了一个定制的Site Provisioning过程，而不再使用SharePoint默认的Site Provisioning模式。

接着是上面指定的那个定制Site Provisioning类。

在重载的Provision()中，首先，代码仍然让新网站应用“工作组网站”这个网站模板。“STS#0”的意思是，使用“STS”这个Site Definition的ID为“0”的Configuration，也就是“工作组网站”这个模板。但是，在应用了默认的“工作组网站”模板之后，再调用了InitTeamSite()方法，在这个方法中通过SharePoint API，将网站首页上的那个图片web part去掉了。

将我们的项目部署到服务器上，IISRESET之后，就能在新建网站页面中看到这个新的名为“定制工作组网站”的网站模板。

使用这个网站模板创建一个新网站后，就会发现，这个网站和用“工作组网站”模板创建的网站一模一样，除了首页上再没有那个图片web part。

通过创建定制Site Definition，以及创建定制的Site Provisioning类来接管Site Provisioning过程，我们就能够完全自定义一个SharePoint新网站的创建过程了。:)

最后一个问题，我们应该选择哪种方式呢？Feature Stapling？还是Site Definition + Site Provisioning Engine？我更推荐Feature Stapling。将各种自定义功能封装成（一个或多个）Feature，让网站管理员可以自己选择启用或停止这些Feature，如果需要，使用Feature Stapling使网站自动应用并激活这些Feature，是一种更好、更优雅、更具封装性、更容易迁移的方式。

上面所示的定制Site Provisioning项目源码下载。

我们在调试GAC中部署的程序时候，很可能碰到下面的报告：

---------------------------
Microsoft Visual Studio
---------------------------
The following module was built either with optimizations enabled or without debug information:

C:\Windows\assembly\GAC_MSIL\CSDN.Community.TopicListDataCenter.EnterpriseComponents\2.5.1.23407__cdde601ea7585548\aaa.dll

To debug this module, change its project build configuration to Debug mode. To suppress this message, disable the 'Warn if no user code on launch' debugger option.
---------------------------
确定  
---------------------------

这是因为VS开发工具在C:\Windows\assembly\GAC_MSIL\CSDN.Community.TopicListDataCenter.EnterpriseComponents\目录下没有找到aaa.pdb调试符号文件。当然这个目录是GAC的目录，不可能有的。

如何解决，最笨的方法是吧 PDB 文件 Copy 到那个目录去。

我这里要说的解决方法当然不是这样的了。而是如下：

在Visual Studio 的调试属性中去掉 Enable Just My Code(Managed only)

这时候我们再去调试就不会出现上述提示文本了。也不会找不到 PDB文件了。一切都OK了。

我们在Modules窗口也可以看到成功加载了正确位置的pdb文件。

参考资料：

You Don't Need to Copy PDB Files to Debug in the GAC!
http://www.elumenotion.com/Blog/Lists/Posts/Post.aspx?ID=23

这个估计是最常用的.net工具，Lutz Roeder同学终于把它转交给Red Gate Software去开发了……这个东西居然有8年多了。

After more than eight years of working on .NET Reflector, I have decided it is time to move on and explore some new opportunities.

I have reached an agreement to have Red Gate Software continue the development of .NET Reflector. Red Gate has a lot of experience creating development tools for both .NET and SQL Server. They have the resources necessary to work on new features, and Reflector fits nicely with other .NET tools the company offers.

Red Gate will continue to provide the free community version and is looking for your feedback and ideas for future versions.

For news and updates on Reflector, sign up for the .NET Developer’s Newsletter from Red Gate. To find out more about the agreement, see the interview on Simple Talk.