工作中自己用C#寫了專門讀寫EXCEL(不需要OFFICE環境,直接讀原始文件，速度快)的COM組件,在使用過程中，發現原先的注冊程序是有問題的。網上也有同樣的網友碰到這個問題，但都沒找到合適的解決辦法。現在我把問題和解決方法都寫出來，供讀者參考。
其實問題都是出在COM組件的注冊上，根本的原因就是REGASM /u 命令有些時候是無效的! 我這邊提供的注冊過程是先卸載，然后注冊。原先的注冊過程是： （1） regasm /u XLSRW.dll （2） regasm XLSRW.dll (/codebase) 實際上，上述反注冊命令是有問題的，具體例子如下： （XLSRW.dll 的CLSID 是61D993F1-CB5E-444d-BB3D-EB2BEA4ACB8D）
上圖中我分別用上面的過程注冊了1.0.0.2和1.0.0.3版本，然后發現用1.0.0.2版本的XLSRW.dll再注冊使用是無效的，因為程序默認仍然去找1.0.0.3版本的XLSRW.dll（因為注冊表項中仍然存在1.0.0.3項）。程序搜索XLSRW.dll的過程是先查找注冊時的路徑下的XLSRW.dll,如果發現版本不對或者沒有，就在程序的當前路徑下尋找，找到后就加載該DLL。這無疑對COM組件的版本升級帶來了災難。
解決該問題的辦法是修改COM的注冊過程，直接刪除COM組件對應的注冊表項（COM組件的注冊路徑都為 HKEY_CLASSES_ROOT/CLSID 下）：
（1） REG DELETE "HKEY_CLASSES_ROOT/CLSID/{61D993F1-CB5E-444D-BB3D-EB2BEA4ACB8D}" /f
（2） REGASM XLSRW.dll /codebase
寫成控制台程序的代碼如下：（main.c)
#include <windows.h>
void main()
{
WinExec( "REG DELETE /"HKEY_CLASSES_ROOT//CLSID//{61D993F1-CB5E-444D-BB3D-EB2BEA4ACB8D} /" /f",SW_HIDE);
Sleep(100);
WinExec( "Regasm XLSRW.dll /codebase ",SW_HIDE);
}
至此，問題已經得到了解決。 讀者們在更新c#寫的COM組件版本時用上面的注冊方法就可以解決你們的問題了。更改的地方只有COM組件對應的CLSID和對應的COM組件名字。