我自己开始关注这部分的内容，一开始是因为工作需要，公司使用软件之前，要提供软件的License，研究通过了才能安装使用。

再后来，看到国外很多关于License的感觉莫名其妙的新闻。比如曾有人把Google告上法庭，理由是Google没有把服务条款放在首页。在中国就成了奇闻，也看得出国内民众对于软件产品的法律意识的淡薄。

协议是规范软件提供商与用户间权利与义务的最重要的合法依据之一。使用软件之前，不去了解协议或服务条款，真是被人卖了都不知道。比如理财软件，如果协议上说，甲方有权利把你的理财记录发布在甲方的其它产品上，可能你就要考虑一下你是否愿意。如果安装前没有了解，等人家把你的理财发到了网上，后悔也晚了。

在国内更是有不少作坊网站连服务条款都没有给出来，然后注册又要邮箱地址。从技术角度而言，根本不需要邮箱地址的。如果没有服务条款的约束，就等着邮箱变垃圾堆吧。（不过不排除某些网站的服务条款是YY的，不过它YY你就可以告它，但是没有服务条款，或是有但是你没有看。那就……）

BTW：大家有谁知道博客园的服务条款页面在哪儿？

回到原题，我们讨论一下翻译得比较好的书。昨天看《Windows核心编程（第五版）》看到第27页时，发现书中关于MultiByteToWideChar函数的描述有逻辑错误。如下：

“必须在cchWideChar参数中指定这个缓冲区的最大长度（字符数）”

“将第一次MultiByteToWideChar调用的返回值乘以sizeof(wchar_t)后得到的大小作为cchWideChar参数的值传入。”

还有其它的描述放一起会更明显，但是这两句也足够了。分析一下就知道，这两句话一定有一句有问题。

后来查MSDN知道是第二句有问题。直接把返回值作为参数就可以了，不需要乘以sizeof(wchar_t)。会不会是翻译错误了呢？一般翻译问题都是用词不当或句子不通，一般不会莫名其妙多出个逻辑来的。随后我翻看翻看了一下原著，的确是原著就写错了。

这个译著还是很尊重原著的，但是估计译者也没有读出这个问题，不然怎么地也会写个译注什么的更正一下吧。好在这个错误已经发布在了官方的勘误表上。

《罗密欧与朱丽叶》有很多个译本。个人感觉朱生豪先生的译本虽然语言上有些土，但是其实比其它的翻本更能被中国人接受，书中把只有用英语才能读出来的幽默感，用中文也很好的表达了出来，虽然对原著的改动较大，但是读起来的效果最佳。这些都是要建立在对英语和原文的双重深入理解的基础上才能做到的。

  所以，我们还是自己好好努力学习英语，直接看原著吧。

用过NSIS的都知道，NSIS的默认方式是手写卸载脚本的。如果使用了支持LOG功能的特殊版NSIS（也是官方的）。使用这个版本的NSIS生成的安装包可以在安装过程中生成日志文件，再加上网友提供的现成脚本，就可以比较方便地实现用日志文件进行卸载的功能。实现方式可以参考NSIS的基本结构一文。

然而，Unicode NSIS的作者没有提供支持LOG功能的NSIS的下载。而只提供了源代码下载。这样我们就不得不自己重新编译NSIS。编译过程很简单，加上一个NSIS_CONFIG_LOG编译参数就可以。但是如果问题这么简单就没有必要写个文章专门介绍一下了。

问题就在于，用自己编译出来的NSIS生成的安装包生成的LOG文件有错误！什么错误呢？在网上没有搜到任何线索，只能自己分析一下LOG文件，自己找错误了。（昨天给Jim发了邮件，不过没有时间等他的回复了）

查看了Unicode NSIS的相关源代码和《Windows核心编程》，发现最有可能出问题的就是WriteFile函数的问题。相关源代码如下。

if (g_log_file[0] && fp == INVALID_HANDLE_VALUE)

{

    fp = myOpenFile(g_log_file, GENERIC_WRITE, OPEN_ALWAYS);

    if (fp != INVALID_HANDLE_VALUE)

        SetFilePointer(fp, 0, NULL, FILE_END);

}

if (fp != INVALID_HANDLE_VALUE)

{

    DWORD d;

    mystrcat(log_text,_T("\r\n"));

    WriteFile(fp,log_text,mystrlen(log_text),&d,NULL);

}

Unicode NSIS生成的所有字符串都是Unicode编码的，写到这个文件里的字符串也是。那么上面的代码有两个问题。

1. 作者在创建这个文件的时候，没有声明这个文件是Unicode文件，使得记事本在打开文件时，以ANSI编码打开，从而产生错误。这个声明就是Byte Order Mark，只是针对Windows平台的部分Unicode文件有这个约束。（比如VS就可以选择是否在源代码文件中加入BOM。）

2. WriteFile时，第三个参数不正确。第三个参数的单位是字节，但是mystrlen函数返回的是log_text的字符数。而Unicode的一个字符有sizeof(TCHAR)个字节。所以实际写入文件中的字符串，只是log_text的前sizeof(TCHAR)分之一。

好了，问题找到了，着手修改源代码吧。先加上BOM，再把第三个参数乘以sizeof(TCHAR)。编译很顺利地完成。生成的LOG文件也是完整的了并能用记事本打开了。

但是，卸载功能无效。把生成的Unicode编码的Log文件另存为ANSI编码的。能卸载了~~~~看来这个Unicode NSIS的卸载包不是很完美啊。想必要让Uninstaller支持Unicode又要改不少代码。一想还有另一种可能是Uninstaller不认识BOM，毕竟NSIS是跨平台的，但是如果记事本不可读也是不能接受的。后来试了一下，果然不能有BOM。把BOM去掉，Uninstaller就正常工作了。

最终代码修改如下：

if (fp != INVALID_HANDLE_VALUE)

{

    DWORD d;

    mystrcat(log_text, _T("\r\n"));

#ifdef UNICODE

    WriteFile(fp, log_text, mystrlen(log_text) * sizeof(TCHAR), &d, NULL);

#else

    WriteFile(fp, log_text, mystrlen(log_text), &d, NULL);

#endif

}

然后用下面的指令Build一下，

scons UNICODE=yes NSIS_CONFIG_LOG=yes SKIPUTILS=”NSIS Menu” PREFIX=”Your Install Folder” install

支持Log的Unicode版NSIS就生成好了。

另外附上自己编译好的补丁，覆盖现有安装即可。

更新：

这时生成的Log文件是Unicode编码，而FileRead指令是不能正确读取Unicode文件的。这样就导致Uninstall By Log功能无法正常运行。

解决方法也很简单，把读取Unicode文件的FileRead指令替换成Unicode NSIS所特有的FileReadUTF16LE就可以了。

今天在网上找有关网络包方面的资料的时候找的。

从07年10月到现在，基本上天天都有数篇博文更新，内容广泛。而且似乎是原创的。谷歌上搜了几篇，它自己的文章基本是排第一的。可能是多人博客吧。

奇怪的是这又好的站点的PR居然是没有

首先，先在自己的电脑上安装一个网页服务器。我用的是Windows，所以想当然地用IIS了。Apache也是可以的，不过我一向不愿意往自己的电脑装一些多余的东西。Windows自带的东西可以完成任务，那就直接用好了。

安装完之后，你的电脑就是网站了。可以直接用http://localhost/ 来访问。但是还只能从自己的电脑上访问。如果你是内网用户，那和你一个网段的，也可以用你的内网IP访问你的网站。如果你有固定IP，就可以从Internet用你的IP来访问你的网站了。

但是，如果没有自己的固定IP，又不想花钱买网上的虚拟服务器。（自己建立博客的目的之一就是不想把自己的东西放在别人的电脑上。）就要解决动态域名的问题。花生壳就是做这个用的。

先在http://www.oray.cn/注册一个账号（Oray护照）。注册完成时，oray会自动根据你的昵称为你生成一个免费的二级域名。比如我的就是http://XXXX.gicp.net/

然后，从这里http://www.oray.cn/peanuthull/download.php下载花生壳客户端并安装。

登录花生壳，就完成了动态的DNS注册工作。从网上用Oray给你的二级域名就可以访问你的网站了。

硬件问题基本解决了。上http://wordpress.org/下载最新WordPress。我用的是2.8版。在它的Docs页面上，详细介绍了使用WordPress的使用环境和安装步骤，相当的详细。了解到还要安装PHP和MySQL，装吧~~~

参考了一下WebBeta.org上的一篇图文并茂的文章，里面介绍了如何安装PHP
和MySQL。下载了php-5.2.10和MySQL-5.1.35。

安装MySQL没有问题，要配置的东西不少，不过基本都用默认配置就OK。安装完成之后，为WordPress建立一个用户和一个数据库。工作就完成了。

然而在安装PHP时发现，这个最新版本的PHP居然没有文中安装步骤上的选项。文中要求选择IIS ISAPI module，不过我的PHP安装项如下，就是没有想要的。

找了半天，感觉最可行的应该是IIS FastCGI。在网上查了一下，这个东西是微软对于PHP的支持的最佳方式，用于取代老式的ISAPI。不过需要下载IIS的补丁才能使用。

安装好补丁之后，再次运行PHP的安装，一切顺利。除了安装路径，基本不需要输入什么。只是在组件选择的时候，要注意。在Extensions组件里，要至少选择上MySQL，OpenSSL和Sockets。完全安装当然更没有问题了。

如果不是完全安装，安装完了，先不着急用PHP文件做测试。打开一个CMD窗口。输入“php -v”看看能不能出来东西。我安装完之后，测试死活不过，页面只显示有ERROR，又只给个ERROR CODE，我就拿着这个ERROR CODE在网上查啊，查了半天也没有查出解决方案。最后用这个命令发现是少一个DLL~~~我没有完全安装~~~~

都安装好了，就把Wordpress解压出来，在IIS上建立虚拟目录指向这个文件夹。给网站起个别名就可以啦！

访问你的新站点，之后的步骤就是WordPress的了。按要求配置即可。

使用过种中发现几个问题。

１. 固定链接只能用默认的。IIS5.1默认不支持URL Rewrite。有人在Google Code上给了个补丁。不过没有试。因为我用别的方式也可以，就是自定义一下。定义成这样就OK了。

/index.php?year=%year%&month=%monthnum%&name=%postname%

虽然也不太好，不过也比默认的ID好啊。

２. 不要把文章删空，不然你的BLOG就无法访问了。

３. 还要安装不少插件。比如WP-PostViews，WordPress.com Stats。使用那个WP-PostViews居然还要改PHP文件~~~~更可恶的是，那个WordPress.com stats插件需要一个API KEY，而申请API KEY要翻墙。以后看博客的stats也要翻墙看~~~~~

1.       为什么要显式地关闭StreamWriter？

这个问题可以从《框架设计》P409找到答案，书上用了专门的一节解释了这个问题。简单来说，因为StreamWriter在调用Write方法向Stream写入数据之后，数据还可能是在StreamWriter的缓冲区中。如果不显式关闭StreamWriter，那么数据能否真正写入Stream中，就要取决于.NET的GC先回收Stream还是先回收StreamWriter。如果GC先回收了Stream，那么在回收StreamWriter时，StreamWriter会试图把缓冲区中的数据写入到一个已经关闭的Stream中，从而发生异常。

2.       如何正确地重写GetHashCode方法？

这个问题可以从《框架设计》P123找到答案，也是用了专门一节讲述这个问题。一个正确的GetHashCode方法要满足下面的要求：

1.       与Equals方法行为一致。如果a等于b，则a的Hash应该也等于b的Hash。

2.       Hash值有良好的分布 。

3.       满足生存期的值稳定性。

4.       最好要快速。

这么多要求，如果没有写过可能还真一时不好下手，其实只要把与Equals方法相关的字段的Hash值异或起来就可以了。

3.       C#编译器为什么要用callvirt指令调用实例的非虚方法？

这个问题也是来源于《框架设计》，作者也很惊讶为什么会这样，不过他只告诉我们这样没有问题，却没有说为什么要这样。P139里的“重要提示”，写到如果一个方法从非虚改成虚方法，如果非虚方法是用call调用，那么这个更改会造成虚方法被非虚地调用，产生不可知的后果。所以干脆都用callvirt好了。

我看了一下callvirt与call的区别，除了方法调用逻辑有一定不同，callvirt还会检查变量是否为NULL，而call不会。其实call根本就不能检查，它还要调用静态方法呢，检查谁去？而实例方法，一般是要使用实例字段的，这就要求实例不能为null，所以用callvirt顺便检查一下。（其实书中也是想这么解释的，不过书印错了。见下面勘误。）

所以估计是上面两个原因，让C#团队选择了callvirt。好处多多。

PS：《框架设计》勘误：P139L3，“call”应该是“callvirt”。

4.       Struct可以继承吗？为什么？可以有虚方法吗？为什么？

不可以继承，因为C#语法不允许。（我实在不想这么回答，但是也实在找不出为什么。）

也不可以有虚方法，都不能继承，虚个屁。

5.       什么时候用const，什么时候用static readonly？

所有书上都会告诉你const是编译时常量，readonly是运行时常量。

但是什么时候用呢？比如你想限制你的程序可以运行的实例的个数为5，用哪个好像都可以哦，不过最好用static readonly，因为哪天你可以把这个数改成6。只要你能改的，就用static readonly，而不要用const。什么时候用const？表示MaxInt, PI, e光速等等数学常量，亘古不变的量，才用const。重申一下，个人观点，仅供参考。至于为什么，可以参考这篇文章。

6.       C#为什么要提供析构函数？

一个原因是为了用于方便地释放本地资源（就是非托管资源）。大家补充。^_^

7.       有时，程序的Debug Build可以正常运行，而Release Build不能。可能是什么原因？

我一想到这个问题的时候，感觉无从下手。天知道为什么！谁知道代码怎么写能写出这么恶心的BUG出来。其实细想想，同样的代码，Debug Build可以运行，而Release Build不能运行。只可能是编译器生产的代码不同。只要知道debug build和release build有什么不同，这个问题也就解决了。至于总共有多少不同点，可真是不好说。《框架设计》P387专门用了一节讲了一个不同——变量的生存期不同。Debug build为了方便调试，“将所有变量的生存期扩展到方法结束”。而release build中，编译器就不会做这样的事情，这样一个变量就有可能被过早地当作垃圾回收掉了。这就有可能导致debug build可以正常运行，而release build不能。具体解释可以参考《框架设计》。

这是个开放式的问题，应该不止这一种情况。欢迎大家补充。

另外又想到了几个问题：

1.       我们都知道短小的方法，有可能在编译时被编译器内联处理。那么在什么情况下，我们会希望阻止一个方法在编译时被内联？

2.       在C#中，有几种方式可以防止一个方法在编译时被内联？

1.       为什么要显式地关闭StreamWriter？

2.       如何正确地重写GetHashCode方法？（这个是最简单的）

3.       C#编译器为什么要用callvirt指令调用实例的非虚方法？

4.       struct可以继承吗？为什么？可以有虚方法吗？为什么？

5.       什么时候用const，什么时候用static readonly？他们有什么区别？

6.       C#为什么要提供析构函数？或者说什么时候用析构函数比较合理？

7.       有时，程序的Debug Build可以正常运行，而Release Build不能正常运行。一般可能会是什么原因？

其中1, 2, 3, 5, 7可以在《CLR via C#》中分析出答案。其它的……大家讨论讨论吧。尤其是第4个问题。可能有人认为这种问题没有意义。语法如此，怎么规定的就怎么用就是了。但是C#或CLR团队这么规定一定会有他们的想法，他们的理由，如果不这样一定有什么问题。

功能难点在上一篇中已经有描述，这里就不赘述了。基本原理就是在安装过程中，使用插件中把后台的释放文件的线程挂起，问用户是不是真要取消安装，是的话就使用安装过程中生成的Log文件进行回滚，不是的话就让被挂起的线程继续运行。

大致要解释如下几个问题

1.       编写线程控制插件。

2.       开启安装页面的取消按钮，并自定义取消函数。

3.       与安装日志功能集成，实现回滚操作。

首先是实现线程控制插件。这个插件有如下几个功能：

1.       挂起后台所有线程

2.       继续后台所有线程

3.       终止后台所有线程

为什么是后台？因为UI线程要用来弹出一个MessageBox让用户点，如果也挂起了，程序就死了。为什么是所有线程呢？因为如果有多个后台线程，如果那个线程不主动配合调查，想要找出哪个线程是用来释放文件似乎不是很容易。简单起见，就全挂起得了，好在不会有什么问题。更好的是，这个安装程序在安装页面只有两个线程，一个UI线程，一个后台释放文件。

还有一点要注意的就是TerminateThread函数是异步的。最好多调用一个WaitForSingleObject来保证函数返回时，线程的确已经被和谐了才行。（不调似乎也没有什么问题）

代码就不贴了，可以从这里下载。关于如何编写NSIS插件可以参考制作NSIS命令行窗口输出插件这篇文章。

然后就是开启安装页面的取消按钮，在上一篇在NSIS中实现安装时取消并回滚（1）——现状提到的几个帖子有示例的。代码如下：（仅适用于MUI2）

!define MUI_PAGE_CUSTOMFUNCTION_PRE OnInstFilesPagePre ;必须放在下面的语句前面

!insertmacro MUI_PAGE_INSTFILES

Function OnInstFilesPagePre

    GetDlgItem $0 $HWNDPARENT 2

    EnableWindow $0 1

FunctionEnd

自定义取消函数的代码如下：

!define MUI_CUSTOMFUNCTION_ABORT OnUserAbort

Function OnUserAbort

…

             nsExec::ExecToLog 'cmd /c copy /Y "$INSTDIR\install.log" "$INSTDIR\temp.log"'

             Call CreateLogFromFile

             Call RemoveDirectoriesFromLog

…

FunctionEnd

函数中给出的代码就是实现回滚操作部分的代码。在调用回滚函数（其实就是卸载时调用的根据日志删除文件的函数）前要把install.log复制一份，然后用复制的日志文件进行回滚。为什么要这样呢？因为后台的释放文件的线程被Terminate掉了，而就是那个线程打开的日志文件并写入安装日志，线程被和谐的，那么释放文件句柄的代码就不会被执行。说白了就是资源泄露了。后果就是再次打开这个文件的时候会失败，就算是只读也不行。用NSIS脚本举个例子。

FileOpen $0 “txt.txt” “w”

FileOpen $1 “txt.txt” “r” ;失败

第一次打开写，可以正确打开，第二次打开，虽然只读也会失败。但是如果像下面这样两次都是读。两次都是可以成功的。

FileOpen $0 “txt.txt” “r”

FileOpen $1 “txt.txt” “r” ;成功

上面只列出了功能实现的比较关键的代码。完整的代码可以从这里下载。如果要正确编译成安装包，还要下载这个头文件。

到此为止，基本在NSIS中实现了取消安装并回滚。但是这种实现有下面一些入缺陷。（都快成定律了，解决一个问题，引出三个问题。）

1.       回滚时install.log文件不能被删除。因为在上面已经解释了。

2.       回滚时，滚动条不回滚。其实应该是可以实现的。大家自己试下吧，应该不难。

3.       回滚后程序直接退出，而不会显示安装失败页面之类的页面。因为我们的回滚操作就是在User Abort里做的嘛。使用User Abort的后果就是直接退出了。应该也是有方法绕过去的。

但是问题问题要解决的，总不能用NSIS开发到一半，发现不能简单地支持取消安装和自动回滚就不用NSIS开发了。INNO和MSI都是内置地支持取消并回滚的，希望NSIS也能加入这个功能的支持。不过在开发者完成这个功能之前，总要有个临时的解决办法吧。不幸的是，在Google上搜索了很久，也只能找到各式各样的提问，而没有一个像样的回答。

下面总结一下网上现有的资源。

Enable cancel button during install?

Afrow UK回复说：“You'd need to modify nsisunz to use an asynchronous thread and include a cancel flag.”nsisunz是什么？我也不知道，先不管了，继续找。

Cancel installation

Red Wine回复说：“No possible to enable the cancel button on page InstFiles pre function, because if you do so, the nsisunz plugin refuses to load the zip file.”好么，连enable the cancel button都不行吗？

Cancelling the installation process as it happens

Darthvader给出了一个这个问题的官方补丁，很好的样子，不过很快就露馅了——太旧了。Kichik回复说：“Abortion isn't the same as the file open problem dialog. Those originate from two different threads. The naive implementation would actually only make it possible to abort in between File commands and not while extracting a big file.”看来不太好办啊。这个Kichik是NSIS的开发者，按他的说法，就算可以Abort，也只能按File指令的个数来取消。也就是说如果你之前用File *.*来压缩文件，现在可以改成有几个文件要打包就写几个File指令，在指令间检测是不是要取消安装。是个办法，不过也太恶心了吧。说像Wizou回复的：“I was just saying that rather than waiting 6+ months for a new "abort" feature fully implemented, that could be nice to start by having a quick implementation that would be already enough to answer the needs of 90% of NSIS users.”最后dmut说他用Multi-volume_Distribution插件把这个功能实现，可是没有具体说如何实现的……

Allow user to cancel during install?

    Kichik直截了当地说：“You can't enable the cancel button yet. It was originally planned for v2 but it looks like it will have to wait for 2.1.”好在那是2003的事儿的，现在应该有所改观了吧？还说要在v2.1加入这个功能。现在都2.44了，还没有看见影呢。

How to enable the Cancel Button during install

Cancelling during MUI_PAGE_INSTFILES

    这里给出了把INSTFILES页面里的取消按钮Enable的方法，和一个让上面提到的方式实现的取消安装。如果这个能满足需要，就将就着用吧。但是要自己写很多代码的。因为取消安装不是取消了就完事儿了，安装过的东西可是要删除干净的，就像是从来没有运行过这个安装程序一样。不过现在的安装包大多数基本上做不到这一点，还要用户给它擦屁股。

HOW to enable a cancel button on a uninstall MUI Page

可怜的人。没有人回答……

Problem with the UMUI cancel button not stopping the install process properly

    不按NSIS的规矩做事，总是要还的。Cancel按钮可以启用，但是当对话框弹出来问用户是不是真的要Cancel的时候，后面的过程还在继续，要是用户点得慢点，没等点OK，安装就已经结束了！开发者这个汗啊。

这些只是网友提问的一部分，记得还有一个帖子给出了开启取消按钮的全部代码。也是遇到了和上面最后一个帖子一样的问题。不过那个帖子死活搜索不到了。

不知道NSIS的作者在研究什么高深的功能，需求这么广泛的取消功能，而且是两个竞争者都已经实现了的功能，却经历了6年时间还没有做出来。

笔者所在项目也是遇到了这样的问题。需求要有取消安装的功能，我们做了，但是后台的安装线程停不下来。上一篇制作NSIS命令行窗口输出插件中我们看到了如何制作一个插件，由于插件是用C++写的，所以理论上可以在里面做任何想做的事情。下一篇中，我们就将实现一个线程控制的插件。用插件把后台的安装线程停下来，为实现取消安装功能做准备。

很奇怪的是，NSIS的官方网站上居然没有介绍如何自己编写Plugin的文章，搜索到在OpenWatcom有一篇介绍了NSIS插件要符合的要求。按照它给出的描述——“NSIS plugins are simply DLLs. The functions provided by these functions are exported functions that have a specific array of parameters. That signature is as follows.”NSIS插件不过是简单的DLL，只要是符合下面参数列表的函数，就会被认为是合法的NSIS插件。

__declspec(dllexport) void __cdecl TestFunc(HWND hwndParent, int string_size, char *variables, stack_t **stacktop)

好啊。那就照葫芦画瓢写个DLL喽。Hello world级的。下面是hello.cpp的源代码。

很简单吧。用下面的命令编译一下。

CL /LD Hello.cpp

编译不过啊！

error C2061: syntax error : identifier 'stack_t'

stack_t未定义！这让我去哪里找啊？只当是外面的吧。把代码改成下面的样子。

#include <windows.h>
#include <stdio.h>
#define NSISAPI __declspec(dllexport) void __cdecl

struct stack_t;

NSISAPI TestFunc(HWND hwndParent, int string_size, char *variables, stack_t **stacktop)
{
    printf("Hello");
}

这下就过了。把这个DLL放到NSIS的Plugins文件夹中，写一个最简单的NSIS脚本测试一下。

OutFile "Test.exe"

Section

    Hello::TestFunc

SectionEnd

结果发现脚本Build不过啊。错误为“Invalid command: Hello::TestFunc”

Command找不到。

看看MakeNSISW上完整的输出信息。列出了NSIS找到的所有Plugin里的可作为Command的函数。如下

Processing config:

Processing plugin dlls: "D:\Program Files\NSIS\Plugins\*.dll"

 - AdvSplash::show

……

- Hello::?TestFunc@@YAXPAUHWND__@@HPADPAPAUstack_t@@@Z

的确是有我们刚加入的DLL的，不过函数名不对啊。“?TestFunc@@YAXPAUHWND__@@HPADPAPAUstack_t@@@Z”怎么会有这么个恶心的函数名？

也许有人已经猜到了，由于使用的是C++，而C++是支持函数重载的，但是导出函数表的函数名不能重名啊。所以CL在编译C++的时候，会自动对函数名进行修饰。这个恶心的名字就是修饰过的函数名。有没有办法不让CL修饰呢？一个办法就是告诉CL我们的代码是C代码，不支持重载，CL就不会修饰了。代码再改如下。

再把编译好的DLL复制到插件文件夹，再编译Test.nsi，这次就编译过了。

双击运行Test.exe，不会看到任何Hello，因为printf是输出到Console的。

从命令行运行Test.exe，也不会在控制台看到”Hello”，因为这个Test.exe是个GUI程序，是没有Console的Output的。寒。那怎么才能有呢？有三个办法，NSIS也是都可以做到了。三种方法可以参考我的另一篇文章让WPF窗体程序支持命令行方式运行的三种方式。方法是通用的。“| more”的方法就不用解释了。让NSIS生成一个CUI程序，可以参考让NSIS生成的安装包在静默安装时从命令行窗口输出安装信息，但是这种方法弊端多多，不然也就不会有这篇文章了。最后一种方法就是AttachConsole了，这种方法也有不好的地方，不过比较而言，还是可以的。

这个DLL的代码很简单，只实现了最基本的功能，大家有需要可以自己添加。

NSIS Console Plugin
#include <windows.h>
#include <stdio.h>
#pragma comment (lib, "user32.lib")
#pragma comment (lib, "kernel32.lib")

#define NSISAPI extern "C" __declspec(dllexport) void __cdecl

HANDLE hOutput;

typedef struct _stack_t {
  struct _stack_t *next;
  char text[1024];
} stack_t;


NSISAPI Attach(HWND hwndParent, int string_size, char *variables, stack_t **stacktop)
{
    if (AttachConsole(-1) == 0)
    printf("failed to attach parent console.");
    else
    hOutput = GetStdHandle(STD_OUTPUT_HANDLE);
}

NSISAPI Show(HWND hwndParent, int string_size, char *variables, stack_t **stacktop)
{
    if (hOutput == NULL)
    printf((*stacktop)->text);
    else
    WriteConsole(hOutput, (*stacktop)->text, strlen((*stacktop)->text), NULL, NULL);
}

参考文献：Writing to and read from the console - From a GUI application using the same cout/cin and printf/scanf

NSIS_CONFIG_LOG_STDOUT=yes

当然，要启用Log功能，还要有下面的编译参数：

NSIS_CONFIG_LOG=yes

结合起来也就是要使用下面的编译指令重新编译NSIS的源代码。

scons NSIS_CONFIG_LOG=yes NSIS_CONFIG_LOG_STDOUT=yes

编译完成之后，在源代码的根目录下，会多出一个build目录，复制下面几个文件到你安装的NSIS的目录下，覆盖相应文件。

Build"release"makensis"makensis.exe

Build"release"Makensisw"makensisw.exe

把几个stub开头的几个文件夹中的可执行文件，覆盖NSIS安装目录下stubs里的相应文件，这时需要重命名一下的。规则就不描述了，比较一下就能知道了。

经过测试，用重新编译过的NSIS生成的安装包文件，可以在静默安装时把原来显示在GUI窗口中的安装信息显示在CMD窗口中。

但是会有新的问题！主要有三个，前两个是我测试时发现的，最后一个是NSIS的开发者在论坛上自己坦白的。

1.    这样生成的安装包事实上是一个带有GUI窗口的CUI程序，这样在安装和卸载时都会带有一个CMD黑窗口在后面，很不好看。

2.    由于是把LOG到文件的输出，重定向到了CUI程序的STDOUT，原本应该生成的install.log文件没有生成出来。这同时会给基于安装日志的卸载带来不利影响。

3.    一部分插件的输出，由于和NSIS本身的输出机制不是很和谐（就是插件开发者没有使用NSIS自身的输出机制，非要自己写一个）并不能把安装信息输出到CMD窗口。

从理论上讲，这几个问题都是可以解决的，但是不是靠几个简单的编译选项就能搞定的了。应该是需要修改NSIS的源代码，而且NSIS的License也是允许你这样做，只要你不找NSIS的原开发者什么麻烦。不过解决一个问题，引出三个问题要解决，似乎有点……要是解决那三个问题再引出九个问题可如何是好啊？

所以至于如何改，还没有研究出来。以后有需求再说吧。

关于如何编译NSIS的源代码，可以参考我的另一篇文章——在VS2008环境下使用Scons编译NSIS。

本来是没有报团的，想自己到苏州想去什么地方去什么地方，可是一到苏州就下着小雨。找起公交车实在是麻烦。就在火车站旁边报了一个团。本来计划好的路线也被破坏了。改成了去北寺塔，水上游苏州，枫桥和虎丘。商量好地点之后忘了最重要的一步——砍价，直到一天玩完了，才发现原价105元/人付了钱才感觉不太对。

第一个，北寺塔。一塔，一庙而已，门票25元。面积非常小，离火车站也最近，也是最没有意思的。跟团走还害中午饭都没有吃好。

第二个，水上游苏州。就是在苏州的护城河里打个弯。时间大约有30分钟吧。导游的解说还是不错的，如果只是在船上兜一圈的确没有什么意思。

上岸时，还附赠了一个旅游项目。苏州某真丝纺织单位的展览。虽说心知肚明是导游和单位串通好的推销产品，但是里面的介绍也还是不错了，了解了蚕的生长过程、抽丝剥茧的过程、缫丝机、真丝被的制作和真丝被的鉴别。当然目前就是推销他们的裤子，基本每床在500左右。

然后就是枫桥，去了才知道，原来枫桥和寒山寺是两个景点，要去寒山寺要自己再出钱（而且时间根本就不允许）！枫桥景区还是满小的，可看的东西也不多，最后带我们坐了2分钟的船就又上了岸，很是无聊。景区里吃的也不多，有个龙须糖还是值得一吃的。

然后又是珍珠单位的销售游，一句话，如果你不是钱多得没处花，就别在这里买了。东西比超市里更贵。基本和火车站是一个价钱。

之后就OK了。虎丘呢？不好意思，天气不好，没有看到。连门都没有让进，就是在门口大马路上飘了一下。这才发现105实在是太不值了，更重要的是没有砍价。

之后当天下午就赶赴周庄了，因为晚上7点之后周庄是不要门票的，门票可要100啊。到了周庄才知道重要的不是门票，是根本没有地方住。司机就说白天景区是人挤人。晚上更是住的地方都没有，不少人都是在宾馆的走廊里打地铺的。景区里的小客栈都会要价300，更不要说带星的宾馆了。吸取了白天的教训，宁可露宿街头，也要砍价到底。找了个100元的阁楼睡了。代价是晚饭要在老板的酒店里吃。本想反正要吃，在哪儿都行。结果又错了。

看到这个酒楼提供周庄的招牌菜“万三蹄”和“阿婆菜”，就点了，吃了之后发现实在是大失所望。万三蹄，在我看来就是酱油蹄多加糖，而且炖得一点儿都不烂。所谓的阿婆菜就是咸菜，而且这咸菜是浓烈的防腐剂的气味，而且是我吃过的防腐剂味最大的一次。吃了一口，就不再吃了。想想那个酒店的万三蹄应该不是正宗，也许正宗的好些。不过已经没有兴趣再试了。说实在的，我这个不会做饭的，从自己家里学了个炖排骨。第一次做的排骨GF都说比这个万三蹄好吃。

再好吃的东西，一旦量产，就不是那么回事儿了。就像奶油，几乎所有的面包、蛋糕、饼干、奶茶、黄油的成份都写着含有奶油。但99.9%都是人造奶油。不但不好吃，还有害健康。为什么是人造的？因为奶油的需求太大了，全用真正的奶油根本就不可能，只能人造。地球人太多了，没有办法……万三蹄也一样，就算是正宗的，相信也已经不是那个味了。

第二天7：15就出发了，直到庄上的时候，检票的人还没有上班呢。呵呵。早晨人也少，拍照就会很方便。可以没有门票，很多园子都是进不去的，只能在大街上到处转，转来转发现和逛街没有什么两样，到处都是商铺。不过有些还是满独特的。

早晨的早饭就是豆花+油条，豆花没有北方的好吃，油条还是冷的。吃起来很没有感觉。还有炸的小鱼，腥味很大。臭豆腐也没有什么特别的，到哪里都有的卖。

仔细找的话，应该能找到不少馆的，没有票也可以进去。有讲中医史的，有陈逸飞的故居，有讲捕鱼和风土的，有讲烧窑和酿酒的。说实在的，如果没有这些，周庄就是一商业街。只不过建筑风格比较别致罢了。当然既然是旅游嘛，就别好像看破红尘似的，看什么都是不过如此，而到哪儿旅游都不会有意思，还是出家当和尚好了。

刚到11点，人就已经很多了，一上午也已经把周庄转遍了，打道回府了。外面有人力三轮车，去汽车站要价10元，可以砍到5元的。摩托车也有，不敢坐而已。到了汽车站，才中午，就已经没有回上海的票了，到昆山车的车才回到的上海。

总结一下： 

    1. 尽量避开公共的假期旅游，不然住的地方都找不到实在是很麻烦的。

    2.  最好把酒店订好，行程安排好，至于天气只能听天由命了。天气预报严重不可信。4月4日之前，我连续关注了5天的中央的天气预报，一天一个样。从3月30日到4月3日共5天中，对4月4日的天气预报如下：

           中雨      大雨     暴雨       小雨       阵雨

           从实际情况来看，只有4月3日的天气预报是准的，暴布汗。

     3.  特产要找正宗的。可能还过得去。

     4.  不要轻信导游带着去的购物的地方。如果时间足够，不要参团，玩得才开心。

首先解释一下为什么要编译NSIS的源代码，因为有时要修改NSIS的设置，比如让NSIS支持LOGGING啊，加大字符串长度，虽然这两个在网站上有下载编译好的，但是如果有别的设置要更改呢？如果要自己写个插件扫描器呢？都要把NSIS的源代码重新编译一遍。很不可理解。不过目前也只能这样。

根据文档上的要求，编译NSIS要有Python和Scons。下吧。Python的最新版是3.0.1，Scons的最新版是1.2.0。都下来最新版，安装好了，按文档上的要求，在源代码所在目录下输入“scons”，结果CMD不认为这是个命令。估计是环境变量没有自动设置好。好不容易找到这个scons，不太敢相信，原来就是一个bat，在bat里调用了python的代码。

把Python和Python"scipts都加到环境变量PATH里，OK。Scons认识了，还是不过，报语法错误，是python解释器报的一个py文件的语法错误。心想有可能是自己的Python太新了，Python 3和Python 2的语法还是有一定差别的。不过这年头Python 3.1都快发布了，scons还要用2.x的版本？到scons的网站上看看，的确也说了“SCons will work with any version of Python from 1.5.2 or later.”那3.0.1应该是可以的吧。不过还是报着一线希望，又安装Python 2.6.1。实践证明scons1.2.0的确还不支持Python 3。

现在不报py的语法错误了，改报NSIS源代码的编译错误了，说XXXX.lib或是说xxx.h报不到。

估计又是哪个环境变量没有设置，这个环境变量也不是自己能YY的，就上网找。在WinAmp的论坛上找到了有人有相同的问题，从后面的讨论可以看出的确是环境变量的问题，而且已经有人作为BUG报给了scons，说文件应该自动找到的呀，scons也很高效，马上就在Bug Trace的网站上回复了临时解决办法——改改scons的源代码就行了。汗颜……好在scons是用解释型语言编写的，改完了不要重新编译。解决方法如下：

Index: src/engine/SCons/Tool/msvc.py

===================================================================

--- src/engine/SCons/Tool/msvc.py (revision 3756)

+++ src/engine/SCons/Tool/msvc.py       (working copy)

@@ -554,7 +554,9 @@

     # base installation from the registry and deduce the default

     # directories.

     version_num, suite = SCons.Tool.msvs.msvs_parse_version(version)

-    if version_num >= 8.0:

+    if version_num >= 9.0:

+        return (os.environ['INCLUDE'], os.environ['LIB'], os.environ['PATH'])

+    elif version_num >= 8.0:

         suite = SCons.Tool.msvs.get_default_visualstudio8_suite(env)

         defpaths = _get_msvc8_default_paths(env, version, suite, use_mfc_dirs)

     elif version_num >= 7.0:

其实说白了就是scons还不支持VS2008，只支持VS2005。开发者也表示会在1.3版中提供VS2008的支持——天知道1.3什么时候发布，看样子是要在VS2010之后了。如果不是很明白上面的文件DIFF的结果可以去网站上看，其实一样的。

从解决方案中可以看到，还要设置两个环境变量“INCLUDE”和“LIB”，分别设置为Program Files"Microsoft Visual Studio 9.0"VC里的include和lib。

这样头文件应该也找到了，库文件应该也找到了，为了防止意外，这次不直接用CMD了。用Windows SDK的CMD SHELL，它会自动地加入一些变量。让各种文件更容易被找到。

这一次终于Build过了90%，还有10%还是过不了，就是NSIS Menu，其实文档上也说了要build NSIS menu要安装wxWidgets。其实目的已经基本完成了，NSIS的主体和插件都已经可以编译了，这个NSIS MENU是可有可无的，不过为了看上去舒服一些，还是让它过吧。同样安装了wxWidgets的最新版2.8.10，同样的要设置环境变量。根据文档上的提示，要先运行一下NSIS源代码目录下的Contrib"NSIS Menu"wx"wxbuild.bat（同样要在CMD SHELL里运行）以生成一些必要的库。然后再在NSIS源代码的根目录下运行scons。

如果出现什么问题，可以参考下面二个论坛上的主题。

Problem building the NSIS source

Nsis 2.25 - compilation problem

至此，NSIS编译成功。用VS2008编译出来的文件的大小，和官方下载的大小还是有一定差别的，可能是因为官方打包用的是VS2005的原因吧。理论上自己编译出来的这个应该更好一些的吧。

目前发现的NSIS的主要缺点是：不支持在安装过程中取消安装。如果你觉得这个功能很重要的话，还是不要用NSIS了。

下面就从最简单的说起——如何用NSIS建立一个安装包。建议见看看NSIS的帮助文档。因为下面的内容主要介绍帮助文档还没有讲到的部分。

NSIS的User Manual第二章“Tutorial: The Basic”是这样描述脚本的结构的。

Required is the OutFile instruction, which tells NSIS where to write the installer, and one section.

大意就是说一个NSI脚本只要有一个OutFile指令和一个Section就可以了。就是下面这个样子：

OutFile "Min.exe"

Section

SectionEnd

一个什么也没有做的Installer就大功告成了。但是这样的示例对于学习NSI脚本可以说一点儿帮助也没有。因为我们需要的是一个可以完成基本功能的安装程序，而不是一个连“Hello world”都没有输出的可执行文件。而NSIS的User Manual从头到尾没有给出一个完整的示例，并解释一下。这篇文章将向大家介绍一个功能基本完整的，行为基本正确的安装程序脚本。文中不会介绍NSI的语法，语法请参考User Manual。

环境准备：

首先，如果大家还没有安装NSIS，请先从http://sourceforge.net/projects/nsis/下载最新的安装包。以2.44版为例，需要下载nsis-2.44-setup.exe和nsis-2.44-log.zip两个文件。安装完NSIS之后，把nsis-2.44-log.zip里解压出来的文件覆盖安装目录下的文件。这个nisi-2.44-log用于开启NSIS的安装日志功能。默认的安装包是没有这个功能的。

NSI脚本的编辑器推荐Notepad++。可以从http://notepad-plus.sourceforge.net/tw/site.htm下载最新版本。（之前一直用Emeditor，不过它目前不支持NSI脚本。用了Notepad++很惊异于其支持的语言数量。）

需求描述：

我们将要实现的Installer需要满足下面几个要求：

1.       界面看上去别太土：因为很不幸，NSIS编译出来的程序默认的风格很Win 98。要使用MUI2库来生成一个比较XP风格的安装包。关于MUI2包的使用，可以参考在线帮助文档。

2.       支持安装日志：安装时把安装的文件记录下来，主要用于卸载时只删除安装程序安装的文件。

3.       支持多语言。这个就不用解释了吧。

4.       基本的页面。这个是自带的，也不用怎么解释。

示例代码：

下面是一个比较完整的安装，但是功能还不是很完整，因为具体功能就要自己加了。

; 头文件应该放在最上面，C++也是这样。

!include "MUI2.nsh"

!include "uninstallfromlog.nsh" ; 卸载时要用的一个头文件，没有在默认安装包里，可以从这里下载

; 然后是一些基本的设置

Name "YourApp"

OutFile "YourAppSetup.exe"

InstallDir "C:\Program Files\XXXX\YourApp"

RequestExecutionLevel user

; 参数的定义

!define MUI_ABORTWARNING

!define MUI_FINISHPAGE_NOREBOOTSUPPORT

; 安装页面定义

!insertmacro MUI_PAGE_WELCOME

!insertmacro MUI_PAGE_LICENSE "license.txt"

!insertmacro MUI_PAGE_DIRECTORY

!insertmacro MUI_PAGE_INSTFILES

!insertmacro MUI_PAGE_FINISH

; 卸载页面定义

!insertmacro MUI_UNPAGE_WELCOME

!insertmacro MUI_UNPAGE_CONFIRM

!insertmacro MUI_UNPAGE_INSTFILES

!insertmacro MUI_UNPAGE_FINISH

; 界面语言定义，想多支持就多加，但是加的语言，受OS限制不一定能显示出来，必须放在页面的定义之后。

!insertmacro MUI_LANGUAGE "SimpChinese"

!insertmacro MUI_LANGUAGE "English"

; 开启安装时的Log功能，必须是第一个Section

Section "-LogSetOn"

 LogSet on

SectionEnd

; 然后是安装段和卸载段

Section "install"

    SetOutPath $INSTDIR

         WriteUninstaller $INSTDIR\Uninstaller.exe

    File "..\YourApp\bin\Release\*.*"

SectionEnd

Section Uninstall

    Call un.CreateLogFromFile

    Call un.RemoveDirectoriesFromLog

         Delete $INSTDIR\install.log

         Delete $INSTDIR\Uninstaller.exe

         RMDir $INSTDIR

SectionEnd

; 最后是各个函数，最好放在最后。

; 安装程序的初始化函数，显示了语言选择页面

Function .onInit

 !insertmacro MUI_LANGDLL_DISPLAY

FunctionEnd

Function un.onInit

 !insertmacro MUI_UNGETLANGUAGE

FunctionEnd

快乐无极博客也给出了一种根据log文件进行卸载的另一个头文件，原理一样，大家可以参考一下。

先到这里吧，下一篇将介绍MUI2库的配置。

懒惰的程序员都会去写个程序做这个事情。上学的时候就写过一个Power工具包，里面就包括这个功能。现在想想那个时候还是太勤快了，写那么多代码做这么点儿破事儿，累不累啊？

因为用bat，几行代码就可以搞定。而且不用编译，用的时候不用选择目标文件夹。

在网上找了半天始终没有找到一个合适的。没办法，自己写了。代码如下 

参考文献：Microsoft DOS for command

using System;
using System.Collections.Generic;

namespace YeildReturn
{
    class Program
    {
        static void Main(string[] args)
        {
            GetNotEmptyItems(new string[] { "a", "", "b" });
        }

        private static IEnumerable<string> GetNotEmptyItems(IEnumerable<string> args)
        {
            foreach (string arg in args)
            {
                Console.WriteLine(arg);
                if (string.IsNullOrEmpty(arg))
                    yield return arg;
            }
        }
    }
}

大家猜猜会有几行输出？2行？3行？

答案是没有输出。明明输入的string列表里的每个item都Console.WriteLine了，为什么会没有输出呢？

想要有输出，要改改代码，下面的代码就可以了。

把对GetNotEmptyItems的调用，放在一个foreach语句中，然后什么也不做。结果就有输出了！

有时写代码，返回值只是为了方便组成链式表达式，使用yield是为了提高性能(^_^参考PS)和简化代码。所以很可能出现这样的情况，只调用函数，而不使用其返回值。但是这时就不应该用yield了，否则就会造成上面的问题。因为yield是要和foreach一起用的。

这里只是给大家提醒，想要打破沙锅问到底的朋友们可以参考网上丰富的yield的资料。下面随便找了两个园子里的链接。

C# 2.0 新特性之迭代器, Yield Return

迭代器（yield return ）

PS：几乎所有的对yield return和直接return list的测试结果都会告诉你，yield return更慢。但是当你真正了解yield之后，相信多数情况下都会选择yield return的。

检测部分的NSI代码如下：

         nsExec::Exec 'sqlcmd -S .\SQLEXPRESS -d SampleDB'

         Pop $0

         IntCmp $0 1 Update Ask

原理很简单，用sqlcmd登录到想要创建的数据库，如果已经存在了，那么成功登录，$0里的值将是0，否则就是1。

NSIS里有很多种Exec的方式，而且检测数据库存在也有很多种。今天试了很多种，有些行不通，有些过于复杂，上面这种是相对简单的方法。希望能给需要的人一些提示。

示例代码非常之简单。 

TextBox要设置为Wrap使其自动换行。

重现Bug的步骤如下：

图1. 运行程序

图2. 输入很多字母

图3. 将光标放到行首

图4. 输入空格，光标不见了

光标不可见，其实还是存在的，只是跑到了第一行的行尾。这就是微软的人说的“by design”的行为的后果。

如果大家试着改一下窗体的大小，比如改成200，那么最后一步输入一个空格之后，光标的确还是可见的，多输入几个空格就又看不见了。这是字体大小与窗体宽度的比例问题造成的。

而且重现上面的问题，也并不需要这么多步骤，只要在文本框里输入足够多的空格就会有问题——根本原因就在于空格不会被Wrap。

不知道微软为什么会这么做？但是相信用户在文本框输入着东西，突然发现光标看不到了，绝对不会觉得很自然。而且WinForm的TextBox是没有这个问题。

不知道微软的这个by design是作何考虑的？大家觉得呢？

同系列的其它文章：

[WPF Bug清单](序)与之(1)——可以多选的单选ListBox

[WPF Bug清单]之(2)——RadioButton的IsChecked绑定失效

[WPF Bug清单]之(3)——暗中创建文件的打开文件对话框

[WPF Bug清单]之(4)——点击RadioButton的空白没有反应

[WPF Bug清单]之(5)——隐藏模态对话框后变成非模态

[WPF Bug清单]之(6)——Button的IsCancel属性失效

[WPF Bug清单]之(7)——顽固的Error Template

[WPF Bug清单]之(8)——RowDefinition中MaxHeight在一定条件下失效

这个小程序大体分了了M，VM，V三层，一层一个DLL。（也许这就有问题……）其中VM层里定义了Command。V层里都是窗体类。

关系是：V使用VM和M，VM使用M。

问题是这样的：有一个Command（在VM层）需要窗体的切换（跳转），但是从VM层又无法直接使用V层的窗体类。一时不知道用哪种方式实现比较好。

自己想到的有这样几个方法。

1. 在M层定义一个公共的CommandProcess，并由V层具体实现，然后在VM层发消息到M层，由V处理。

2. 在M层为所有窗体类做抽象，并维护窗体列表，由V实例化。然后VM使用M层定义的抽象窗体列表进行跳转。

3. 将VM和V合并到一个DLL中。

4. 使用反射。

5. 将Command放在V层，或不使用Command?

不知大家建议应该怎么做呢？

在stackoverflow上有人讨论过这个问题。下面的条目都是摘自各个网页。做个汇总，方便大家参考。 

最表面上来看，用的类库不同，这个问题很好通过一个宏来解决。

#if !NUNIT

     using Microsoft.VisualStudio.TestTools.UnitTesting;

 #else

     using NUnit.Framework;

     using TestClass = NUnit.Framework.TestFixtureAttribute;

     using TestMethod = NUnit.Framework.TestAttribute;

     using TestInitialize = NUnit.Framework.SetUpAttribute;

     using TestCleanup = NUnit.Framework.TearDownAttribute;

     using TestContext = System.String;

     using DeploymentItem = NUnit.Framework.DescriptionAttribute;

 #endif

NUnit有这样几个优点

1.       独立于IDE，可以单独运行。也可以以命令行方式运行。（vs应该也可以吧？）

2.       版本更新快。（我不认为这是个优点，而且我也并不觉得快啊。）

3.       VS的UT工具运行速度慢。（不一定）

NUite也有这样几个缺点

1.       不支持Debug，要安装TestDriven.NET才支持。

2.       不支持代码覆盖率的查看，要和NCover一起用。而VS的代码覆盖很清楚。

3.       不能自动生成测试代码，也许和CodeSmith一起用好些，不过后着要收费的。

补充一点：NCover生成的XML太大了，动不动IE就Crash了，（用NCoverExplorer更好，不过公司没有……）。今天找了半天，都没有找到办法让NCover只生成特定Namespace的数据的命令行参数。最后改了xsl,不显示Method级的XML，好了些。

VS UT最大的缺点——价格！只有VS Pro才支持UT，只有VSTS才支持代码覆盖。

还有人认为VSUT比较难以与CC.NET集成。虽然没有去试着在CC中直接使用VSUT，但是感觉应该是可以的。

再来看一下VS的价格。

最新报价请参考：http://msdn.microsoft.com/en-us/aa700832.aspx

另外，ReSharper（30天试用）、xUnit（开源）、MbUnit也都是UT的不错选择。

参考：http://stackoverflow.com/questions/92869/nunit-vs-visual-studio-2008s-test-projects-for-unit-testing

http://stackoverflow.com/questions/709/net-testing-framework-advice

http://stackoverflow.com/questions/1760/net-unit-testing-packages

有人对此倒是看得很开，知道现在其实什么东西都不健康，可是知道不能不吃啊。结果都懒得去了解什么不健康，也全然不在乎吃东西健康不健康，反正大家都这么吃，要死一起死，活下来了还给人类的进化做贡献了不是？

最近牛奶出了那么多事儿，从三聚氰胺、OMP、到最近的苯甲酸，火车上也听一养牛的说，所谓的天然牧场根本就不存在。已经对牛奶彻底失去了信心。可是还时不时喝着，没办法，人在江湖，身不由己。有人说不喝不就是了？其实多了解一些就会发现，什么都是有问题的。牛奶还算好一些的，因为喝的人多，被关注得多，不敢太放肆。

最近了解了一些食品上的信息，分享给大家，希望能给大家在吃上一些提示。

1.       珍珠奶茶：没有奶，也没有茶。

把这个放第一条，因为奶茶这个东西到处都是，危害不大，却最广泛。珍珠奶茶，主要成份奶精、糖、香精、色素，奶精含有的氢化植物油（俗称反式脂肪酸），提高心血管病风险。里面只有糖还有点儿用。如果放糖精呢？

当然不是所有的奶茶都这样，不过路边3、5、8元一杯的一定是的。在石家庄这样的中等城市，真正的奶茶，一杯至少在20元以上。（曾经有过这么一个地方，好像叫什么“绿野仙踪”啊？忘了，后来也关了……）谢谢，我回家自己兑去。

2.       反式脂肪酸：不常见——罕见的名字，其实无处不在。由植物油人工氢化而成，天然食品中含量极少。能增加食品酥脆感、比脂肪酸易于长期保存（因为连一部分微生物都不认这东西……），最重要的是成本低。世界卫生组织的建议摄入量为低于总热量的1%。大致是2g。因为其会导致动脉硬化。

那么什么食品里有呢？简单而言，有奶油或黄油的基本就有。因为没有几个会放天然奶油或天然黄油的。拿面包来说，我所知的在上海使用天然奶油的只有Breadtalk。但是那东西的价格不是所有人都承受得了的。

列举一下：人造黄油、巧克力、糖果、蛋糕、面包、饼干、薯片、奶精、几乎所有油炸食品（比如方便面）、比萨饼、人造奶油、爆米花、威化饼、部分沙拉酱、全部咖啡伴侣、麦片、汤圆、芝麻糊……。

另外，几乎所有的方便面都说自己的“非油炸食品”，就像说自己没有放防腐剂一样，就像一些牛奶说是来自天然牧场一样，真的假的？呵呵，反正目前没有人反对这么写，是吧？（五谷道场好像不是油炸的，不过已经倒了）

所以，给老人过生日，如果不放心，先把奶油刮了再吃吧。

看网上有人把蛋挞列为十大不健康食品，理由是猪油放多了。我想说，要是放的真是猪油，我……我感谢他十八代祖宗！

PS：美国本士的KFC，炸东西用的是大豆油[信息来源：WIKI]，是因为有人告了，中国地区呢？好像目前还没有人告。

3.       猪肉（内脏部分）：丁磊为什么养猪？我要是有足够的钱，我也想，这年头，吃个健康的猪真是不容易啊。但是我们要现实一点。毕竟目前多数猪都是吃瘦肉精长大的。这也难怪，现在全民都不爱吃肥肉，猪为是为大家着想啊。毕竟猪肉里瘦肉精残留得不多，主要都留在了肝和肺里，近10年，仅上海，有记录的就有1700人瘦肉精中毒，1人死亡。

最后给大家一个很久的链接。42种有毒食品，图文并茂。但愿现在已经有所改善了吧。

问题就出在了后台逻辑获取资源的部分，代码类似下面。

Application.Current.Resources[XXXX]

运行时抛出NullReferenceException，Application.Current为null。

很好理解，当前由于是用NUnit测试后台DLL，这时这个程序是基于WinForm的，而代码中要获得的是WPF Application，的确应该是null。这时才发现代码写得有问题——可测试性不好，但是代码已经冻结了，不是Fix bug不可以改。（这个时候才开始写UT，汗……）而这种代码在DLL中也不少。怎么办呢？

Application.Current是只读的，在UT里先启动原来的WPF程序？肯定不行的。只读其实不是问题，邪恶地想到了用反射给后面的变量直接赋值。得知道变量名啊，打开Reflector，发现变量名叫_appInstance，好在这时多想了一个问题，这个变量是什么时候被赋值的呢？第一感觉就是在个什么初始化的方法里，没找几个就发现就是在Appliction的构造函数里。

看来不用反射了。

在UT的Startup方法里加两行代码。

Application app = new Appliction();                      //这个app，就是Application.Current

Application.Current.Resources = Application.LoadComponents(…);

完成，这样资源就可以被正常地访问到了。如果没看一下源代码，真要傻呼呼地用反射赋值了。

BUG描述：当RowDefinition的Height属性被设置为Auto时，MaxHeight将不会对这个Row的Height起到限制作用。

Bug发现过程：想做一个像Visual Studio 2008里Error List一样的东西。平时自动占用最小的空间，可以在适当的时候自己弹出来，但是又不要弹得过高。

示例窗口代码如下： 

Demo Window
<Window x:Class="InvaliMaxHeight.DemoWindow"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    Title="MaxHeight of RowDefinition NOT Effct"
    WindowStartupLocation="CenterScreen"
    Height="240" Width="300"
    ResizeMode="NoResize">
    <Grid>
        <Grid.RowDefinitions>
            <RowDefinition/>
            <RowDefinition Height="5"/>
            <RowDefinition Height="Auto" MaxHeight="50"/>
        </Grid.RowDefinitions>
        <DockPanel Margin="12">
            <TextBlock DockPanel.Dock="Top" TextWrapping="Wrap"
                       Text="XXX"/>
            <Button Content="Show Large Tab"
                Click="OnShowLargeTabClick"
                HorizontalAlignment="Center"
                VerticalAlignment="Center" Width="125"/>
        </DockPanel>
        <GridSplitter Grid.Row="1" HorizontalAlignment="Stretch"/>
        <TabControl Grid.Row="2" Margin="12">
            <TabItem Header="Empty Tab"/>
            <TabItem Header="Large Tab" Name="largeTab">
                <ListBox Name="listBox"/>
            </TabItem>
        </TabControl>
    </Grid>
</Window>

注：RowDefinition的Height的默认值为*。 

为了避免多余代码产生不必要的误会，上面的代码中尽量减少了大小的设置。设置的Margin是为了美观。运行效果如下图。 

图1. Startup

可能大家不知道50px有多大，大概就是现在灰线下的部分的高度。就是说点击Button之后，高度不应该有太大的变化。可是结果却是这样。 

图2. Clicked

这时，如果拖一下上面的GridSplitter，那么Large Tab那个部分又会突然变小。

程序源代码 

同系列的其它文章：

[WPF Bug清单](序)与之(1)——可以多选的单选ListBox

[WPF Bug清单]之(2)——RadioButton的IsChecked绑定失效

[WPF Bug清单]之(3)——暗中创建文件的打开文件对话框

[WPF Bug清单]之(4)——点击RadioButton的空白没有反应

[WPF Bug清单]之(5)——隐藏模态对话框后变成非模态

[WPF Bug清单]之(6)——Button的IsCancel属性失效

[WPF Bug清单]之(7)——顽固的Error Template

[WPF Bug清单]之(9)——消失的光标

关于WPF数据绑定的Validation更多细节，请参考Data Validation in 3.5。

关于WPF数据绑定的Validation中的ErrorTemplate怎么用，请参考ErrorTemplate Attached Property。

ErrorTemplate将被绘制在Adorner Layer上，关于Adorner Layer，请参考Adorners Overview。

在Adorners Overview里，对Adorner是这样解释的， 

Adorners are rendered in an AdornerLayer, which is a rendering surface that is always on top of the adorned element or a collection of adorned elements.

Adorned element的红色是我加的。表面上看，这个adorned element就是一个element，但是这个element的范围有多大呢？对我们的程序会有什么影响呢？看文档很难想到。用过之后才知道，影响太大了。 

还有这样一个不太起眼的Note。 

Anything placed in the adorner layer is rendered on top of the rest of any styles you have set. In other words, adorners are always visually on top and cannot be overridden using z-order.

这句话是对的。大意就是说这个Adorner layer里的东西，总会被绘制在它所adorn的东西之上。这个无可厚非，人家这样设计，我们就这么用就是了。但是，问题就在于，一个Window里的东西，是可以有层次的，有区域，有可见性的。但是adorner layer不分青红皂白地总在最上。结果就出了问题。请看下面的例子。

DemoWindow
<Window x:Class="FixErrorTemplate.DemoWindow"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    Title="Stubborn Error Template Demo"
    Height="200" Width="300"
    ResizeMode="NoResize"
    WindowStartupLocation="CenterScreen"
    Name="window">
    <Grid>
        <Grid.RowDefinitions>
            <RowDefinition Height="50"/>
            <RowDefinition Height="5"/>
            <RowDefinition/>
        </Grid.RowDefinitions>
        <Grid Height="50">
            <TextBox HorizontalAlignment="Center" VerticalAlignment="Center" Width="100">
                <TextBox.Text>
                    <Binding ValidatesOnDataErrors="True" ElementName="window" Path="Value"/>
                </TextBox.Text>
            </TextBox>
        </Grid>
        <GridSplitter Grid.Row="1" HorizontalAlignment="Stretch"/>
        <Grid Grid.Row="2" Margin="12">
            <TabControl>
                <TabItem Header="Tab1">
                    <TextBox HorizontalAlignment="Center" VerticalAlignment="Center" Width="100">
                        <TextBox.Text>
                            <Binding ValidatesOnDataErrors="True" ElementName="window" Path="Value"/>
                        </TextBox.Text>
                    </TextBox>
                </TabItem>
                <TabItem Header="Tab2"/>
            </TabControl>
        </Grid>
    </Grid>
</Window>

这个窗口，就出了两个问题。看图。

启动时如下图所示。

图1. Startup Window

窗体的上下由一个GridSplitter分割，可以上下拖动。 

在TextBox中输入一个字符。会产生一个Validation Error，并用默认的ErrorTemplate显示出来。如图2所示。

图2. TextBox in Error

好了，我们慢慢地将GridSplitter向上拖。慢慢地，看到什么了？TextBox消失了，可是那个红框却赖着不走了！如图3所示。

图3. Move GridSplitter Up

再来看看下面的红框。把GridSplitter慢慢地向下拖。TabPanel的空间小了，TextBox也变矮，最后消失，那个红框也很尽忠，化成了一条线也要告诉我们那个TextBox其实还在。如图4所示。

图4. Move GridSplitter Down

再细看看，那个红线甚至已经在TabControl之外了！

当然，我们总可以想办法解决或是绕过这个问题，然后说这不是个问题。但是最自然的代码写出来的东西却不对，就象之前一篇介绍的如何用代码选中一个ListBoxItem一样，很不爽。因为按理说，adorned element都消失了，这个红框也应该跟着消失的。

同系列的其它文章：

[WPF Bug清单](序)与之(1)——可以多选的单选ListBox

[WPF Bug清单]之(2)——RadioButton的IsChecked绑定失效

[WPF Bug清单]之(3)——暗中创建文件的打开文件对话框

[WPF Bug清单]之(4)——点击RadioButton的空白没有反应

[WPF Bug清单]之(5)——隐藏模态对话框后变成非模态

[WPF Bug清单]之(6)——Button的IsCancel属性失效

[WPF Bug清单]之(8)——RowDefinition中MaxHeight在一定条件下失效

[WPF Bug清单]之(9)——消失的光标

Window的Show和ShowDialog，用于将窗体展现（我没有用显示）出来，而Close用于关闭。Close之后就不能再用Show或是ShowDialog再次将窗体展现出来，否则会抛出异常，所以5楼的gboxcc回复的是错的。很同情这位gboxcc，因为他认为我说错的那句，恰恰是我写过代码验证过的。

如果想隐藏而不关闭一个窗体，显然用Close是不行的。而且还要把所有的Close事件Cancel掉，保证窗体不会被Close，然后只能用Visibility 将窗体隐藏起来。隐藏之后，如果要将窗体再次显示出来，我的第一感觉是用Visibility，但是发现不行。

从这个角度而言，Window类，Show/Close只在开始和结束的时候调用，因为它们不能交替调用；在窗体Show之后，用Visibility控制其可见性，因为可见性可以随意交替设置的。我认为这才是一个非常自然的事情。但是Window的实际情况是，Visibility的设置，会使isShowingDialog变量的值发生变化，单从需求上讲，这是不应该的。所以将其做为一个Bug提了出来。Colin Han认为这是“为了更好地用户体验，专门做出的设计。”，我亦不以为然。而且我感觉微软的UX团队与开发团队的沟通还很不充分，比如我在另一篇文章中提到的WPF的Window，没有提供一个属性来设置一个窗体是否显示Icon，这本身就不符合微软自己的UX Guide。

回复的人一致认为，再次显示这个窗体时也应该用ShowDialog。好，这篇文章就是为次而生的。因为用ShowDialog将窗体再次显示出来同样有问题。连代码都不用改，直接用上次的代码就可以重现这个问题。使用ShowDialog方法将一个窗体再次显示出来之后，窗体上的”Hide Self”按钮失效了。注意是再次，第一次ShowDialog出来时的行为是正常的。

这里顺便介绍一下IsCancel属性，MSDN上对它的解释如下：获取或设置一个，该值指示Button是否是一个“取消”按钮。用户可以通过按ESC键激活“取消”按钮。其实我感觉这句话对于新手而言实在是没有什么帮助。好像就告诉别人这个属性就是给Button加了个ESC键作为快捷键。必须要和MSDN上的很多文档合起来看才知道这个IsCancel按钮在不同环境下分别起什么作用，其实还不如自己写个代码试一下来得方便。

对于示例中的代码而言，IsCancel就相当于让当前窗体关闭。这是给窗体添加一个关闭按钮最简单的方式（没有之一）。因为这个Bug用的就是上一篇的代码。所以就不给大家贴图了。自己运行一下吧。逻辑如下：

1.       点击示例中的Show Model Dialog按钮——显示一个模态对话框。

2.       可以用Hide Self关闭弹出框。

3.       再用Show Model Dialog弹出这个对话框。

4.       那个Hide Self按钮不再起作用了。

同系列的其它文章：

[WPF Bug清单](序)与之(1)——可以多选的单选ListBox

[WPF Bug清单]之(2)——RadioButton的IsChecked绑定失效

[WPF Bug清单]之(3)——暗中创建文件的打开文件对话框

[WPF Bug清单]之(4)——点击RadioButton的空白没有反应

[WPF Bug清单]之(5)——隐藏模态对话框后变成非模态

[WPF Bug清单]之(7)——顽固的Error Template

[WPF Bug清单]之(8)——RowDefinition中MaxHeight在一定条件下失效

[WPF Bug清单]之(9)——消失的光标

我是MS Fan，但是我依然会以挑剔的眼光看它；只因为我是MS Fan的原因是，从多数开发和娱乐和应用的角度而言，MS是目前最好的选择。如果有一天Linux的哪个发行版在多数方面超过了MS，我会义无反顾地投入Linux。不过是一个平台，不是女友，也不是“知已者”，不需要相守一生。

问题描述：用ShowDialog方法弹出一个模态对话框，然后将此对话框的Visibility属性设置为Hidden，再设置回Visible，发现这个对话框已经不是模态的了。

有人会觉得关就关了得了，也不会有这个问题，干什么要把Close取消掉然后再显示出来呢？因为这是有应用环境的。

应用环境：有些对话框，从逻辑上就是单例的，比如Office和Visual Studio里都有的查找对话框，显然没有必要同时显示两个。而且也没有必要每次重新实例化并显示出来，在用户关闭窗体时，将窗体隐藏起来会更好，这样上次查找的关键字还存在着。可以省去一些代码保存这个历史关键字。

当然，这种方式也会有不好的地方，欢迎大家指摘。

写了一个程序来模拟这个Bug，效果如下面三张图所示。

图1. 主窗体，点第一个按钮

图2. 弹出的模态对话框，点击按钮将自己隐藏

图3. 再点击主窗体的最后一个按钮，显示出来，已经是非模态对话框了

以前发Bug，一般没有去看过.NET的源代码，这次感觉这个Bug 有点儿太不应该了，就看了看源代码，发现WPF还特意为Dialog(模态的)的Hidden做了单独的处理，感觉就更不应该有问题了，我们来看看源代码。

DoDialogHide
[SecurityCritical, SecurityTreatAsSafe]
private void DoDialogHide()
{
    SecurityHelper.DemandUnmanagedCode();
    bool isActiveWindow = false;
    if (this._dispatcherFrame != null)
    {
        this._dispatcherFrame.Continue = false;
        this._dispatcherFrame = null;
    }
    if (!this._dialogResult.HasValue)
    {
        this._dialogResult = false;
    }
    this._showingAsDialog = false;       //Cause this Bug
    isActiveWindow = this._swh.IsActiveWindow;
    this.EnableThreadWindows(true);
    if ((isActiveWindow && (this._dialogPreviousActiveHandle != IntPtr.Zero)) && UnsafeNativeMethods.IsWindow(new HandleRef(this, this._dialogPreviousActiveHandle)))
    {
        UnsafeNativeMethods.SetActiveWindow(new HandleRef(this, this._dialogPreviousActiveHandle));
    }
}

其中直接把_showingAsDialog设置为了false，当再次把窗体的Visibility设置为Visible的时候，Window类又会根据这个变量的值来判断是否将窗体按模态的方式显示出来。而MS对这行代码的的注释仅仅是“// clears _showingAsDialog”。

从源代码上来看，WPF的Window似乎是使用下面的代码将一个窗体从非模态变成模态的。

SetAsModal
try
{
    // tell users we're going modal
    ComponentDispatcher.PushModal(); 

    _dispatcherFrame = new DispatcherFrame(); 
    Dispatcher.PushFrame(_dispatcherFrame); 
}
finally 
{
    // tell users we're going non-modal
    ComponentDispatcher.PopModal();
}

但是当我自己在使用里使用这个方法的时候，却发现根本达不到目的。后来突然想到一个方法，试了一下，就可以。解决方法是，不使用Visibility = Visible，使窗体再次显示出来。而且再调用一次ShowDialog方法来显示这个窗体。这个方法也许只有对WPF不熟悉或是非常熟悉的人才能想得出来（我是死马当作活马医碰对了），因为正常情况下，继续地第二次调用ShowDialog方法是会抛出异常的。类似的诡异的Window的异常在[WPF]如何在关闭非模态子窗体时用消息框确认——解决最小化窗体时抛出的异常里也有描述。

另外，在非UI线程弹出的MessageBox也是非模态的。这个解决方法很简单，只要在Dispatcher里弹出这个MessageBox就可以了。

更多关于WPF Bug 

同系列的其它文章：

[WPF Bug清单](序)与之(1)——可以多选的单选ListBox

[WPF Bug清单]之(2)——RadioButton的IsChecked绑定失效

[WPF Bug清单]之(3)——暗中创建文件的打开文件对话框

[WPF Bug清单]之(4)——点击RadioButton的空白没有反应

[WPF Bug清单]之(6)——Button的IsCancel属性失效

[WPF Bug清单]之(7)——顽固的Error Template

[WPF Bug清单]之(8)——RowDefinition中MaxHeight在一定条件下失效

[WPF Bug清单]之(9)——消失的光标

这个谁说都没有用，看看微软的已经有的软件，主窗体都有，从主窗体弹出的绝大多数子窗体都没有。再来看看微软自己的UX Guide上是怎么说的。

Title bars

● Dialog boxes don’t have title bar icons. Title bar icons are used as a visual distinction between primary windows and

secondary windows.

􀀀m Exception: If a dialog box is used to implement a primary window (such as a utility) and therefore appears on the taskbar, it does have

a title bar icon. In this case, optimize the title for display on the taskbar by concisely placing the distinguishing information first.

                                                                                                Page 421 in pdf

Title bar icons

● Dialog boxes don’t have title bar icons.

􀀀m Exception: If a dialog box is used to implement a primary window (such as a utility) and therefore appears on the taskbar, it does have

a title bar icon.

                                                                                                                                  Page 426 in pdf

Icons

● Modal error message dialogs don’t have title bar icons. Title bar icons are used as a visual distinction between primary windows

and secondary windows.

                                                                                                         Page 541 in pdf

程序里的不在任务栏里的弹出框实在是太常见了，而现有的程序和UX Guide都告诉我们这个弹出框上不应该有左上角的Icon。好，知道了，以后这么做就是了。

等等，WPF的Window不愿意给你这个机会！看看WPF的MSDN上是怎么说的。

A WPF window always displays an icon. When one is not provided by setting Icon, WPF chooses an icon to display based on the following rules:

1. Use the assembly icon, if specified.
2. If the assembly icon is not specified, use the default Microsoft Windows icon.

得，微软自己两个TEAM打起来了。说直接点就是，WPF的Window没有WinForm里Form里的ShowIcon属性。

当然人不能让尿憋死，办法总是有的。不过要直接调用Win32 API。介绍在这里。我在项目里也试了一下（毕竟UX优先级高些），不是很好用。后来看了看Form里的ShowIcon方法是如何实现的才正确地解决了。要在上面的方法的基础上，SetWindowPos之后，再用下面的代码给Window发两个消息。

SendMessage(hwnd, 0x80, 0, 0);

SendMessage(hwnd, 0x80, 1, 0);

才能把Icon删掉。

记得做DEMO时，把东西给CTO看后，得到的反馈之一是，为什么用WPF做这么点儿功能用了这么久？怎么还要写逻辑？

不知道CTO是不是只看过WPF的广告，而没有自己涉足过。似乎在CTO的观念中，WPF是可以极大地减少代码逻辑，增加开发效率的新技术。如果XAML不属于代码的话，前半句算是正确的。但是后半句无论如何是不能做为结论的。要完成功能，就要有逻辑，无论用什么技术，总要把逻辑完整地表达出来。库多做一些，我们少做一些而已。

那么WPF为我们带来了什么呢？

评价总要有个比较的对象，就拿WinForm或MFC作比较好了。

相对于上面的两种技术，WPF高度抽象控件的外观表示，分离了控件的外观与逻辑、同时为分离界面与后台逻辑提供了可能。里面的Command和DataBinding其实就是为此服务的。而Template、Style和Animation等不过是UI抽象的必然附带结果。

由于是新发布的产品，不足也是难免的。最直接的一个就是XAML本身其实就是String，而在当前的Visual Studio 2008中进行重构是不会对XAML进行操作的（除了部分类名），增加了代码维护的成本。比如Spin，Calandar，DataTimePicker，DataGrid，Balloon这些WinForm控件在当前的版本中并没有，.NET 4才会发布几个控件以弥补。现在WPF的缺陷在我的WPF Bug清单系列文章里也有部分描述。

另外，WPF中所推崇的MVVM很好，但是会带来更高的设计与编码复杂度。

大家觉得呢？

晚饭没有像平时一样在公司吃。回到家里，吃着刚买回来的饺子，想起了儿时在家过年的情景。

不懂事的时候就发现，哪天早晨起来，吃的是腊八粥，那么就快要过年了，就要发压岁钱了。这一天，家里人还会剥些蒜，泡在醋里准备过年的时候吃。就是北方人熟知的腊八蒜。到了大年三十儿的晚上，家家都会开着屋子里所有的灯“守年关”，等着新的一年的到来。大人们总要熬到半夜，出去放炮，把一些睡着了的小孩子叫起来，一起吃饺子。虽然饺子什么时候都吃得到，但是三十儿晚上和全家人一起吃，还是更有味道的。

别家我不知道怎样，我从小吃饺子的时候，总会先剥几瓣生蒜，用个小碟倒上醋，滴几滴香油，最好再放些芥末。和饺子一起吃，真是舒服啊。想想都会流口水。现在眼前的醋碟里，芥末换成了“老干妈”，吃起来一样很爽。

到了十五，又会买来元宵，各种味道的都有，那时最爱吃山楂馅的。可是不知从什么时候起，山楂馅的元宵很难买到了。再到后来，元宵都很难买到了，满世界都是汤圆。汤圆煮出来水是清的，吃起来没有元宵那种糊糊的感觉。

不知听谁传的——“南甜北咸，东辣西酸。”以为南方以甜食为主，也的确见过有南方人吃馒头要放糖的。来上海之前，也充分考虑到了这点，觉得自己挺爱吃甜的，去上海应该也没有什么吃不习惯的。后来证明我错了。

一年前来到了上海，发现这里甜的东西比我想象的要少得多。

在北方，粽子里放的是枣，家里放的更是蜜腌过的枣，从小就很爱吃，还有一次一顿吃了三个，结果撑得住了院的经历。来到了上海，发现粽子里放的是肉和鸡蛋，味道更是咸的。吃了两次，就再也不去尝试适应上海的粽子了。也许上海人把粽子当饭吃吧？家里一直把粽子当零食吃。和饭一起吃的菜（粽子里的肉）应该是咸的，倒也说得通。

在北方，汤圆主要是芝麻的，还有山楂、五仁等口味，统一的特点就是甜。来到了上海，发现汤圆里放得还是肉。我无语了。都没吃过肉不成？得着（北方方言）个什么东西都放肉……

在北方，平时吃个饺子，吃个面条是再常见不过的。而且饺子的馅也是多种多样。家里常吃的就有“猪肉大葱（北方特色）”、“三鲜（韭菜、鸡蛋或海肠、虾仁）”、“荠菜猪肉”、“羊肉（萝卜）”、“纯牛肉”、“纯鱼肉（什么鱼忘了，不爱吃）”、别的什么白菜、芹菜、茴香多了去了。至于面条就更不用说了，单单面条的制法，山西人就想出了不少。不过我最爱吃的还是炸酱面（不是北京的），而且这个酱是要用黄豆和西瓜的汁（不是水）做的哦。而且无论是吃饺子还是面条，我都会和蒜一起吃。

到了上海，外面卖的饺子倒也不少。可是问起上海本地人，基本上一年不会吃几次饺子，面条就更少了。估计外卖的饺子，多是被北方人买去了。而且吃的饺子，多是肉馅的。也许把饺子当一种象征，不是当饭吃，只是一种仪式，自然要用好一些的原料——肉。

还有就是面包，很久之前在北方没有见过肉松面包的，可能也是南方传过去的吧。真是千方百计地放肉啊。冷笑。

现在天天吃饭，总是要想着法的多吃些菜。结果有一天，在食堂打了两份素的，结果被打卡的伙计鄙视了，说“这么省？”。自认语言比较贫乏，只是笑笑，沉默以对。

上海人拿着自己的价值观看着周围的人，然后得出结论说，都是一群乡巴佬儿。却不知道这群乡巴佬儿也是这么想的。上海的现在繁荣，上海的本地人有多少的份儿呢？

看着眼前就要吃完的饺子，似乎找回一点感觉。家乡的感觉！一口把剩下的醋喝掉，暗笑，这就是北方人的感觉！在上海，少的就是这种感觉！