Why is the loader looking in registry for my Registration-Free COM component?

Question

I've been successfully using registration-free COM to load COM components into my .Net process. Suddenly something has changed (whilst I was out at lunch, it seems :-) ) and the loading process has stopped working.

Whereas before my COM components where loading correctly, now I'm getting a FileNotFoundException.

Running ProcMon to explore what's going on, I find that the loader is looking up the CLSID in the registry, and finding that the component has been registered. Then it looks in at the registered path, and discovers that the dll is not there.

Can anyone tell me why the loader is going to the registry to look for the component when I have configured it using registration-free COM? I assumed that the manifests would take precedence over the registry, but I can't find any documentation about this.

Answer 1

It turns out that the culprit was the Visual Studio Hosting process. When this is involved your application's manifest file (which specifies the COM dependencies) doesn't get read.

So the easy fix is to disable the hosting process.