How to prevent Windows from caching Com Class info?

Windows 7 is caching some of the COM class information. Older OSs didn't do this. After the OS looks up theHKCU\Software\Classes\CLSID\{GUID}\LocalServer32 value, it caches the value, and doesn't look it up again.

When we update our software, we place the new updates in a different directory, and then update the HKCU\Software\Classes\CLSID\{GUID}\LocalServer32 value to reflect the new path. The next time the software runs, it will use the latest files if running under older Windows OSs. However, on Windows 7, it will continue to use the older file, until the OS is rebooted.

I ran process monitor, and discovered that under Windows 7, it never reads the registry key again, after the first read. On older OSs, it reads that key every time.

My question is: Is there开发者_如何学Go any way to force Windows 7 to re-read the LocalServer32 information from the HKCU hive each time a new out of proc COM object is created?

---

I have only been able to solve this problem by...

1: Stopping the Process

2: explicitly unregistering using regsvr32 the library ( or exename /unregserver)

3: Registering the new component

4: Starting the process back up.

I would suspect that it is the Un Reg part that is failing for you. If you are just changing the registry key directly then you should call RegSvr32 /u instead.

Also make sure the new directory location is the current directory when you call RegSvr32.

Note that I have always stopped the process and then unregistered, this is probably a significant detail.

---

As this is a top result in Google for this narrow-ish problem, I thought it would be valuable to add my troubleshooting outcome for this problem.

I found this response on SO: C# : How to change windows registry and take effect immediately

And linked solution from that answer: Registry Watcher C#

Both of which seem viable options for managing changed keys without forcing a reboot. For us (like the OP) this was when installing updates. For us (possibly unlike the OP) this is infrequent and we decided the effort to implement and test a fix as described was outweighed by the simple solution of requiring a reboot: a process Windows users have come to expect with installing software anyway.