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

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

1. 将dsoframer.ocx复制到%windir%\system32目录。
2. 在命令行运行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组件时，最佳实践是：

1. 在32位Windows操作系统中，将dsoframer.ocx组件复制到%windir%\System32目录，并使用regsvr32命令注册。
2. 在64位Windows操作系统中，将dsoframer.ocx组件复制到%windir%\SysWOW64目录，并使用regsvr32命令注册。
3. 在Visual Studio中，将调用DSOFramer组件项目的编译选项中的目标CPU设置为x86。

最后，SysWOW64中“WOW64”的含义是“Windows on 64-bit Windows”。所以，你就会明白，为什么在64位Windows操作系统中把dsoframer.ocx组件复制到SysWOW64目录了，因为它是运行在“64位Windows上的（32位）Windows”的32位DLL组件。