欢迎来到忆约科技! 手机版
编程专栏
网络探索
科技频道
社会话题
美文鉴赏

在 64 位系统注册 DSOFramer

编辑时间:2017年08月29日 17:03 作者:E小编

DSOFramer是微软提供的一款用于在线编辑、调用Word、Excel等Office程序的ActiveX组件。很多第三方的Office组件都是基于DSOFramer组件开发的。今天我们不讲如何使用DSOFramer组件,网上关于DSOFramer组件使用方法的文章已经很多了,而是讲一下在使用DSOFramer组件开发时的一些坑。

DSOFramer组件的全名是dsoframer.ocx。所有关于DSOFramer组件使用方法的文章都会告诉你,使用DSOFramer组件,第一步必须在Windows操作系统中注册该组件。注册方法很简单:

将dsoframer.ocx复制到%windir%\system32目录。
在命令行运行regsvr32命令注册dsoframer.ocx。
注册成功后,Windows操作系统会提示“DllRegisterServer 在 dsoframer.ocx 成功”。



到目前为止,貌似一切顺利。不过如果你像我一样使用64位Windows操作系统,你已经不知不觉掉到坑里去了。为什么呢?我们继续往下看。

假设,我们已经编写好调用DSOFramer的程序,当我们运行程序时会发生什么事情?“铛”!是的,没错,系统弹出“应用程序无法处理的异常”。



为什么会出现这个错误呢?我们不是已经在system32目录注册dsoframer.cox了吗?为什么会提示“没有注册类”呢?

是的,问题就在这里。如果我们使用的是32位Windows操作系统,那么,OK,程序在运行时不会有任何问题。但是很不幸,我使用的是64位Windows操作系统。使用64位Windows操作系统的朋友可能会发现在%windir%目录下除了常见的system、System32目录以外,还有一个SysWOW64目录。在32位Windows操作系统中,System32目录用于存放32位DLL,而在64位Windows操作系统中,据称为了保持向下兼容性,System32目录用于存放64位DLL,而新增加的SysWOW64用于存放兼容的32位DLL(虽然感觉上System32和SysWOW64两个目录的作用应该完全相反)。

之所以会出现前面的异常,是因为DSOFramer是32位组件。因此,在32位Windows操作系统中,应该将其复制到System32目录中注册;而在64位Windows操作系统中,应该将其复制到SysWOW64目录中注册,而不是复制到System32目录中。



如果在64位Windows操作系统中,我们将dsoframer.ocx复制到SysWOW32目录,然后使用regsvr32注册组件。那么,运行程序时就不会再出现“没有注册类”的异常了。

另外,需要注意的是,在Visual Studio的编译选项中,目标CPU选项的默认设置是Any CPU。很多情况下,我们不会改变这个默认设置,而是由.net framework JIT在运行时根据系统环境自由决定如何装载程序。但是,由于DSOFramer是32位组件的原因,在编写调用DSOFramer组件的应用程序时,应该将编译选项中的目标CPU设置为x86。这样才能保证程序在运行时能够在正确的位置找到注册的DSOFramer组件。

因此,在使用DSOFramer组件时,最佳实践是:

在32位Windows操作系统中,将dsoframer.ocx组件复制到%windir%\System32目录,并使用regsvr32命令注册。
在64位Windows操作系统中,将dsoframer.ocx组件复制到%windir%\SysWOW64目录,并使用regsvr32命令注册。
在Visual Studio中,将调用DSOFramer组件项目的编译选项中的目标CPU设置为x86。
最后,SysWOW64中“WOW64”的含义是“Windows on 64-bit Windows”。所以,你就会明白,为什么在64位Windows操作系统中把dsoframer.ocx组件复制到SysWOW64目录了,因为它是运行在“64位Windows上的(32位)Windows”的32位DLL组件。
二维码