由于版本问题,当您从计算机中删除现有版本后,IE成功下载并安装组件,这就是版本控制的问题。在这一点上,我可以想到几种情况。
情况1:.INF文件错误
打开您的.CAB文件。您将看到其中的.INF文件。打开此.INF文件并找到[<component name>.ocx]
部分。检查FileVersion=...
的值,它应该是FileVersion=1,0,0,80
。我发现,如果您通过Package & Deployment Wizard之前生成的.BAT脚本更新现有的.CAB文件,则此值不会自动更新。
情况2:测试环境被构建过程污染
我能想到的另一种情况是,您正在测试与您用于构建控件新版本的同一台计算机。在这种情况下,您的控件可能已被构建过程注册。了解COM激活是如何工作的?对于理解有所帮助。不过,最好在除构建服务器外的其他计算机上进行测试。
可能性1:创建了名为
AppID
的命名值在
HCKR\CLSID\{clsid}
注册表键下的构建过程。
根据
KB167597:
以下是如何控制<OBJECT>
标记的组件下载的伪代码:
Check the Registry for CLSID
If CLSID of OBJECT is NOT found in the registry
Download OBJECT
Else If no #Version specified in CODEBASE tag
Use OBJECT installed on system
Else
Check InprocServer32 key for location of installed component
If File version of installed component < CODEBASE #Version Tag
Download OBJECT
以上顺序有几个例外情况。如果在CLSID下找到AppID密钥,则该组件通常是通过DCOM注册运行的,不会被更新。此外,已安装版本密钥优先于文件版本。这用于Java类和非PE(便携式可执行)文件。
为了确认这个想法,请检查您在测试中使用的计算机上是否有组件的AppID注册表值。您的用户很可能不会在其计算机上为CLSID设置AppID。当然,除非您的组件在至少另一种不同的情况下使用。Larry Osterman在他的博客文章
When do you need an APPID in your COM registration?中提到了这一点。如果您不确定AppID是什么,请参阅
this MSDN blog post。
如何查找是否为CLSID
设置了AppID
?打开注册表编辑器regedt32
,并检查HKEY_CLASSES_ROOT\CLSID\{<clsid>}
键下的值。查找类型为REG_SZ
的AppId
命名值。
可能性2:构建过程更改了HCKR\CLSID\{clsid}\InprocServer32
注册表键的默认值
检查HCKR\CLSID\{clsid}\InprocServer32
注册表键的默认值((Default)
)。如果它指向您用作组件编译过程输出的位置,则很可能是在构建过程中设置的(除非您直接将构建结果放在C:\WINDOWS\Downloaded Program Files
中,我真的很怀疑)。操作系统使用此值来确定在COM组件激活时要使用哪个二进制文件。运行regsvr32 /u <path to the .ocx created during compilation>
,然后使用网页重新运行测试。
如果没有任何帮助,您需要更仔细地调查该问题。启动
进程监视器,要求其跟踪IE进程的注册表和文件系统活动,并查看IE如何决定(不)更新您的控件。收集到的跟踪信息中有趣的信息应该会在查询控件的
CLSID
之后立即出现。
#
改成问号吗? - Tyler Crompton