If this delay is only for first load (after computer start), then this is caused by loading all libraries. NET runtime and would not be affected by these delays)

(That's why I asked earlier what kind of client you were running. See this recent post on this subject, which touches on the startup performance of. Incidentally, this is one of the reasons why writing shell extensions in. This is not an issue with using COM it's an issue with loading. NET to write the COM object (more specifically, you should not use. if your program just can't tolerate the delays, then you should not use. It won't make it faster, but it might improve the user experience dramatically.

I suggest you think about whether you can take the hit early in your program's lifetime by creating an object soon after startup. I don't believe there is much you can do to speed things up. The delays you mention are not unheard of. Any additional libraries your code might use also needs to be loaded, verified and possibly compiled into machine code (if not NGEN'd). NET runtime also has to parse the metadata of your assembly, and then dynamically generate and compile the 'COM callable wrappers' ( ) which are the proxies that bridge between the unmanaged COM world and the managed. Then, your DLL has to be loaded, 'verified', and compiled into machine code (although just-in-time helps a lot to speed-up the startup). The first call to CoCreateInstance has to load into the process, and initialize, the.

Runemate instance taking long time