Since IE successfully downloads and installs the component after uninstalling the existing version from your computer, all this relates to version control. At this point, I could think of several scenarios.
Scenario 1: bad .inf file
Open the .CAB file. You will see the INI file inside. Open this .INF file and find the [<component name>.ocx] section. Check the value of FileVersion=... , it should be FileVersion=1,0,0,80 . I found out that this value is not updated automatically if you update an existing .CAB file through a .BAT script previously created by the Package and Deployment Wizard.
Scenario 2: test environment contaminated by the assembly process
Another scenario that I can imagine is that you are testing on the same machine as for creating a new version of your control. In this case, your control may be registered by the build process. Here it helps to understand how COM activation works? It is always recommended to test on a machine other than the build server.
Option 1 : the created process is created by the AppID named-value in the HCKR\CLSID\{clsid} registry key
By KB167597 :
In the pseudocode, here is how the component loading for the <OBJECT> tag is controlled:
Check the Registry for CLSID If CLSID of OBJECT is NOT found in the registry Download OBJECT Else If no
There are a few exceptions to the above sequence. If the application key is in the CLSID, the component is usually registered to work through DCOM and not updated. In addition, the key of the installed version takes precedence over the version of the file. This is used for Java and non-PE classes (portable executables).
To confirm the idea, check if the AppID registry value for your component exists on the computer that you use for testing. Your users will most likely not have the AppID for CLSID installed on their machines. This, of course, if your component is not used, in at least one other scenario. Larry Osterman has a blog post When do you need an APPID in a COM registry? Also check out this MSDN blog post if you don't know what the AppID .
How to find out if AppID for CLSID ? Open the regedt32 registry editor and check the values under the HKEY_CLASSES_ROOT\CLSID\{<clsid>} . Find the AppID named-value of type REG_SZ .
Option 2 : Change the default build process HCKR\CLSID\{clsid}\InprocServer32 registry key
Check the default value ( (Default) ) of the HCKR\CLSID\{clsid}\InprocServer32 registry key. If it points to the location that you use as the output compilation of the component, then it most likely was installed during the build (if you do not immediately put the build results into C:\WINDOWS\Downloaded Program Files , which I really doubt) . OS uses this value to determine which binary is used to activate the COM component. Run regsvr32 /u <path to the .ocx created during compilation> and retry the test from the web page.
If all else fails, you need to study the problem more carefully. Launch Process Monitor , ask it to track the registry and file system activity for the IE process and see how IE solves (does not update) your control. Interesting information in the collected traces should begin immediately after a registry request for your CLSID control.