最近不知道各位有没有到MS的网站上面看,在VS的页面里面有一个.NET的十个必用工具的Post。这个Post里面介绍的好几个工具都确实非常有用,比如说Reflector、NUnit、Regulator等等。
说起来真巧,这里面介绍的Reflector最近就被我检查出一个Bug,这个Bug在查看Microsoft.WindowsCE.Forms.dll里面的_SIPWnProc函数,翻译出来的C#代码竟然是:
internal PAL_ERROR _SIPWnProc(IntPtr hwnThis, WM wm, int wParam, int lParam)
{
if (this.EnabledChanged == null)
{
return PAL_ERROR.Handled;
}
this.EnabledChanged.Invoke(null, EventArgs.Empty);
}
竟然有可能没有返回值,这个Bug出现在4.0.7.0的版本。在反馈的email发出之后,作者跟我联系了,说最新的4.0.7.0版本没有这个问题。我但是不知道我用的已经是4.0.7.0了,还say sorry了。然后我立刻就发现这个问题,马上又给他发了一封信,后来没过多久就出现了4.0.8.0的版本了。
其实有时候还是直接用ILDasm比较让人放心,至少不会有很多逻辑性的错误。(我还试过用Reflector看Terrarium的程序的时候崩溃掉了,看的是一个import dll的函数,也不知道目前是否有修正。)
另外一个Regulator就更让我觉得还是自己写东西比较安全。虽然说这个东西好像挺好的,但是实际上我还是觉得他没有脱离写正则表达式的繁琐和重复性的工作。而让我感到更加吃惊的是,我的一个工作得非常好的正则表达式,竟然在他那里出错了,不知道为什么。这个正则表达式就是我上一次提供的.NET CF程序源代码级优化器的第一阶段的表达式,主要就是去除代码里面的注解、字符串等可能会引起错误理解的部分。这个表达式如下:
(?>/(?>/(?:[^/n])*|/*(?>/*(?
写到这里,我就觉得正则表达式的构造还是用我自己写的那个软件比较放心,而且能够比较轻松的构造出比较复杂的内容。上面的那个还不是最长的,至少加速器里面的第二步骤所用到的正则表达式就有783个字符(上面那一个有516个字符)。像这么复杂的东西,如果要用Regulator这样的工具去创造(注意是创造,而不是有人指点你怎么去做),真是不可想象的一件事情。
不知道有没有人想知道我的那个正则表达式的编写器有什么“优点”呢?这个东西和上面的The Regulator相比较有什么最大的区别的?这个就恕我留下来卖个关子了。
还是自己写的东西比较放心
最新推荐文章于 2025-12-12 22:11:02 发布
本文介绍了VS页面中.NET的十个必用工具,如Reflector、NUnit、Regulator等。指出Reflector存在Bug,4.0.7.0版本查看特定函数翻译的C#代码可能无返回值。还提到Regulator处理正则表达式时出现问题,作者认为自己编写软件构造正则表达式更放心。
13万+

被折叠的 条评论
为什么被折叠?



