摘要:最近似乎不太顺利，总是一钻进 Reflector 就 N 久时间找不到问题所在，一点一点琢磨那些可疑的、没有头绪的、没有注释的 BCL （.net 的基础类库）源代码，以确认到底是我错了，还是微软错了。 这不，又发现一个疑似bug，如标题所写。 XmlDataSource 控件一般是和 TreeView 组合使用的，如果是静态的 XML 数据是不会碰到什么问题的，但一变成动态数据，就总碰到一些怪异的现象。（虽然大部分最终还是被克服了。） 想让 TreeView 显示动态数据，第一条，可以不用绑定，直接一个 TreeNode 一个 TreeNode 的添加，保证 100% 符合要求。 第二条，在画面上放上多个 XmlDataSource 控件，根据情况将 TreeView 的 DataSourceID 属性指到相应的 XmlDataSource 控件。但局限也很明显，总不能一下子放上 100个，1000个 XmlDataSource 控件吧？ 第三条，XmlDataSource 只用一个，但改变它的 DataFile 或者 Data 属性，以改变数据。 改变 DataFile 属性的方案，经试验是可行的。不过相对于 Data 属性，局限就是必须有硬盘上存在的 XML 文件做源。虽然你可以选择动态生成 XML 文件，然后绑上去，但还是有些麻烦，还得考虑考虑这些临时文件的废弃处理措施。 Data 属性相对就比较合我的口味，不过，我就在这个方案上栽了跟斗：我发现无论怎么改变 Data 值，TreeView 的显示总是不变。（只有页面初始化那一次有效。） 先是怀疑是不是 TreeView 没有自动去 XmlDataSource 去取最新数据？对 BCL 的 debug 是有点麻烦的，好像是有办法下载微软公开的源代码，然后进行 debug 的，不过我这会儿没功夫去调。就用 Reflection 将我看到的那些 private 变量的值弄出来看，结果没发现 TreeView 有“偷工”的迹象。 然后把矛头掉转到 XmlDataSource，看看是不是它有问题。一钻去，首先就发现这个家伙跟其他的 DataSource 控件相比，有一点很与众不同，它默认的 Cache.Enabled = true。这个默认设置，也算可以理解，毕竟 XML 文件相对于数据库那些数据源来说，还是很稳定的，而且加载很多节点的 XML 文档也是很费劲的。 进一步的追踪发现，问题的原因应该就是出在缓存上。Data 属性变化后，缓存没有自动失效，导致了问题。 下面是我使用 Reflection 的 Hack： public static void XmlDataSourceCacheHack(XmlDataSource dataSource) { try ......[阅读全文]

摘要:痛苦了debug了一个多钟头，后来终于在网络上找到了这篇“救星”文章： http://columns.chicken-house.net/blogs/chicken/archive/2007/04/06/system-net-mail-bug.aspx 立此存照，如果您也碰到同样问题，希望能够能比我更幸运些，更早找到问题所在。 症状是：调用 SmtpClient.Send 方法后，出现 System.FormatException， 英文消息为“An invalid character was found in header value.” 中文消息是：“邮件标头中找到无效字符”。 原因是在 SmtpClient.Send 之前曾经调用过该 MailMessage 对象的 From, To, Cc 等字段的 ToString 方法。很有可能的情形是，你尝试在发信前留下日志时，“无意间”调用到了。而微软的工程师在此处出现了一些失误，最终产生了该错误消息，具体情况请参看上面链接中的文章。 P.S. 当然还会有其他原因可能导致此问题，比如微软知识库里给出的一种原因是因为收件人显示名称中包含有引号。...[阅读全文]

摘要:I suppose you were searching the keywords in the title before entering this page. The problem may be: In a GridView (ASP.NET 2.0), you want to use a HyperLinkField, but you find it doesn't support UrlEncode, while you are planning to pass some variables via URLs. The bug report shows that Microsoft doesn't have any plan on adding such a property, because their policy on backward compatibility between different version of .net frameworks. I also made a lot of searching and browsing. The popular way to solve this problem always is, to tranform your HyperLinkField into TemplateField, and do UrlEncode by yourself via......[阅读全文]

摘要:我假定你是碰到了和我相同的问题，搜索标题中这几个关键字来到这篇文章的。 简单的描述一下这个有点挠头的问题，就是对于 GridView 中的 HyperLinkField 列，MS 并没有像 BoundField 那样提供 UrlEncode/HtmlEncode 之类相关的属性设置。可实际运用中，你很可能碰到需要在 URL 中传中文参数的问题。Google 出来的网页表明，西方人也会因为一些特殊字符（比如 &）碰到同样的问题。当然相比西方人，CJK 圈子里更普遍一些。 目前看到的文章给出的方案大都是将 HyperLinkField 转化为 TemplateField 之后，手动用 HttpUtility.UrlEncode 方法处理数据绑定。代码会增多，看起来也不太雅观。而且如果你反悔或者想调整字段时，从 TemplateField 也不能自动转回 HyperLinkField。 Google 出来的网页中，有一些网友跟我同样的想法，希望 MS 能够在 .net 2.0 下个版本（也就是 .net 3.x）中提供一个这样的常用属性，并且已经有人向 MS 提交了“bug 报告”。MS 的答复应该令不少人失望：为了在版本升级中保持 backward-compatibility，MS 不会添加这样的属性。 （顺便多句嘴，backward-compatibility 这个词，国内有人译作“向前兼容”，也有人译作“向后兼容”，呵呵，很有意思的一件事，都有点道理，“以前”是指 before now，“向前看”却是 look forward。） 在 MS 说明 backward-compatiblity 的 blog 上，很多网友表达了跟我类似的疑惑：既然 .net 各个版本之间可以互不影响的独立工作，那就没有必要去“过分”地追求 100% backward-compatibility。当然，为了大家不至于重新学习，做到尽可能兼容就可以了，但以前写的程序，就还让它们在原来的 .net framework 上运行就好了。 而至于版本迁移，决策者准备迁移之前，就应该考虑好迁移的优点和缺点，就像 PetShop 从 .net 1.x 迁移到 2.0 改动不可谓之不大，但为了利用 2.0 最新的技术，它那样去做了，到底值不值得，那就是决策者的算盘了。 好了，上面对于多数人来说都是废话，来主要的吧： 下面这段代码给你一个新选择，避免将 HyperLinkField 转换为 TemplateField ，但同时实现了 UrlEncode。   public static void HyperLinkFieldUrlEncodeHack(GridView gridView) { if (gridView == null) ......[阅读全文]