底层是COM，但是会自动生成Interop的dll给.net平台用，问题是用regsvr32注册COM的时候好像不会更新那个Interop出来的DLL，遇到一个问题就是这个导致的，编译没有问题，运行的时候死活找不到新加的那个类，后来没有办法，搜索整个计算机，把COM的DLL和Interop的DLL全部搜索出来并且删除，再看Visual Studio，才发现它实际上使用的是c:\windows\assembly\GAC_MSIL下的那一份，你在搜索的时候把搜索系统文件和隐藏文件都勾上也不会去搜索这个目录下的东西。应该是有命令可以更新的，不过我现在还是暴力替换：
c:
cd \windows\assebmly
attrib -r -h -s Desktop.ini
del Desktop.ini
这样这个目录就可以进去看并且直接替换DLL了。
对于熟悉的人而言，这个可能不是什么问题，但是对于我这个.net菜鸟和其它的菜鸟，可能还是有用的。
我们新的项目是基于.NET开发的，而我们要调用或者说依赖很多C++的COM组件，我们有COM的源代码，我们的.NET代码在调用COM的时候经常会有问题，但是我们想知道到底是什么问题，这样就需要跟踪进COM里面，详细的步骤在这里：
http://support.microsoft.com/kb/919519
这个KB是How to debug a COM+ component by using Visual Studio 2005 or by using Visual Studio .NET
不过这个KB还不够，它指出了原理性的东西，但是还有些细节没有说：
如果你的工程是C#的工程或者是其他的.NET的工程，那么需要修改工程的debug属性，把Enable unmanaged code debugging选中（如果不选中这个，那么会出现the symbol file does not match the module，即使其实他们是match的）。
那个KB很长，其实重点就是两个：
另外文章中的那个加载dllhost那个进程的操作似乎是不需要的，我现在没有操作，可能那个操作对调试COM+有用，对于普通的COM不需要。
向后兼容性和历史上的诸多古老的解决方案对于微软阵营的开发者而言就是梦魇，它的多语言支持又是另外一个败笔。
我现在被迫从Java阵营临时到了微软阵营，但是遇到的问题多多。
现在有几个比较简单的任务：得到Exchange Server的邮件大小，Exchange本身没有API做这个事情，但是有一些其他的变通方式，例如得到所有的Mailbox然后统计每个Mailbox的大小，而Mailbox的大小也没有直接的API，需要统计所有的Folder的大小，虽然性能上不太好，但是总归是可以做到的。
目前发现的解决方案有这样几个：
接下来只能尝试写COM组件把它包起来给c#用了。
© 2024 解惑
本主题由Anders Noren提供 — 向上 ↑