VSTO中的Exception Handling技术
今天在做一个VSTO (Visual Studio Tools for Office)的示例时遇到了点儿麻烦，一开始百思不得其解，后来找到问题的根源之后发现蛮有意思的，写出来和大家分享一下。
posted on 2004-06-17 21:50:00 by musicland 评论(12) 阅读(4564)
VSTO中的Exception Handling技术
今天在做一个VSTO (Visual Studio Tools for Office)的示例时遇到了点儿麻烦，一开始百思不得其解，后来找到问题的根源之后发现蛮有意思的，写出来和大家分享一下。
问题是这样的，我想在Word文档中通过Linked Assembly使用System.Xml命名空间中的功能，最简单的就是用XmlDocument载入整篇XML文档，然后再通过XPath查询取得所需的数据。这个在.NET开发时也经常遇到（是不是太小儿科了？），所以我就随手写了份XML文档作读取的测试，这份文档的内容如下：
?????
?????
XML文档的正确性先不说，我接着又在VSTO项目中增加一个辅助类用来读取这份xml文档并取出其中所有book的信息，然后在code behind文件里 (ThisDocument.cs)调用这个辅助类及相应方法来获取这些信息，然后在指定位置创建表格进行显示。OK，一切好像都进行得很顺利，可当Word文档运行时就是无法读出XML信息，也没有任何错误提示。这是怎么回事？
为了找到错误，我打开VS.NET的调试器，根据应用程序的运行，发现每当运行到下面这行代码之后，代码执行马上结束：
doc.LoadXml(this._fileFullPath);
怎么，无法正确读入XML文档？难道XML语法有误？这么一想，我再回过头仔细检查一下上面那份XML文档的代码，果然发现了问题——属性值应该包含在括号里，id=1应该写成id=”
看来错误应该找到了（而且是个低级错误），可是为什么Word在运行的时候一点儿错误的提示都没有呢？带着这问题又查了查帮助文档，果然有解答：
When you are developing Visual Studio Tools for Office projects you will find that if an exception occurs, it will not be shown in the Office application and execution of your code will simply end at that point. This can make it difficult to find and resolve bugs.
原来Word（以及Excel）在运行与之关联的.NET assembly时，一旦运行出错不会给出任何提示，从而也就出现了我上文中所提到的那种情况——应用程序运行非常“顺利”，但指定功能却无影无踪了。
文中还给出了两种解决办法：
You should include exception handling code in your projects to notify users of any issues. However, when debugging you can set the debug options to notify you of errors: in the Exceptions dialog box, change the When the exception is thrown option to Break into the debugger. Using this setting may result in you being notified that msosec.dll is not found. This error is not directly associated with your code and you can continue past it.
简而言之，我们可以通过手动增加错误例程处理(比如try… catch)来捕捉出错的迹象，另外也可以像上面英文资料中提示的那样，更改“异常”对话框（在“调试”－“异常”菜单中）中的相应设置，来达到出错时返回调试器的作用（必须是在调试状态下才可以）。这样，就可以在开发VSTO应用时即时捕捉到异常，并能尽早解决问题。
posted on 2004-06-17 21:46:00 by musicland 评论(5) 阅读(3882)
感受Download Manager
昨天把收到的Longhorn (build: 4074)装在自己的开发机器上，算是迟迟地体会了一把Longhorn的威力。
因为还没有下载完SDK，所以我的体会仅限于Longhorn所提供给最终用户（以及管理人员）的一些新特性，其中比较让我感兴趣的就是IE中的新增功能——Download Manager。
其实类似的工具早已经在其它的游览器中提供了，也有一些第三方的很棒的工具，比如Flashget等。我个人感觉，IE所提供的Download Manager最主要的目标不是提供一套完整的下载以及下载过程/文件管理工具，而是直接针对IE本身进行一种Add-on嵌入，帮助用户对下载过程和下载文件进行简单的管理，比如设定和修改下载优先级（High/Background/Suspended），提供安全警告，显示下载进度，断点续传等等。同时，Download Manager让用户可以很方便地定位已经下载的文件，而此前经常会发生用户下载完以后却找不到文件的情形。另外，在下载提示对话框中就已经显示了即将要下载的文件的大小，而在原来，只有真正去下载该文件才能看到文件大小的提示。
从整体上来看，Download Manager对用户的下载过程起到了很有必要的帮助。虽然我们很可能还要寻找一些专业下载工具的支援，但至少在系统自身里已经提供了这样的辅助功能。我想这样的进步本身就已经让人感到由衷的高兴了，呵呵。
BTW:用过微软的File Transfer Manager (通常在MSDN/MCT下载站点中提供)的人能一眼就看出，Download Manager与前者如出一辙，可能它们走的是同一条技术路线吧。
下载提示对话框，可以显示要下载的文件的大小
Download管理界面
Download Manager的设置选项，这里和File Transfer Manager几乎一模一样
posted on 2004-06-12 13:01:00 by musicland 评论(17) 阅读(5441)
Windows Messenger中的远程协助
前天，我开发机器上的POP3/SMTP服务出了问题，一时无法解决，于是就在MSN Messenger上找严诺(Nuo Yan)求助。因为问题涉及的面比较广，文字沟通很难说清楚，所以我邀请他进行了一次远程协助(Remote Assistance)。
首先是发现MSN Messenger中的远程协助功能失效，软件提示要安装最新版本的Windows Messenger。于是下载安装Windows Messenger 5.0，重新登陆，终于进入了远程协助的界面。
我请严诺直接控制我的本机（他在汕头，我在北京），他用最快的速度排除了我DNS设置中的一个问题（该问题来自于我的Server 2003一开始设置为动态获取IP和DNS地址，该机器同时是Domain Controller和DNS Server），然后检查POP3/SMTP中的设置。在这个过程中遇到了一串怪问题，最后SMTP的management console竟然在Inetmgr里失踪了，以致最后的时间几乎完全花在寻找SMTP management console上。
整个过程大概持续了一个半小时，SMTP management console还是找不见，不过随后当我按http://support.microsoft.com/default.aspx?scid=kb;en-us;323350这篇文章中给出的方法对本机POP3/SMTP服务进行测试的时候，竟然发现邮件已经收发自如了，这更让我觉得奇怪，难道SMTP management console的失踪是个bug?还是我的操作有误？
不过，我真的要在这儿再次感谢严诺的无私帮助，特别是后来他对我问题的解答更让我受益：
musicland: 你说我有没有必要找时间学一学Windows Server 2003方面的知识呢？
Nuo Yan: 非常有必要，对系统的了解会有助于开发的。马骐老师就是两方面都很精通。
（因为Windows Messenger中没有聊天记录存储功能，所以以上对话内容是我凭印象记忆的
posted on 2004-06-11 12:27:00 by musicland 评论(33) 阅读(20467)