Tuesday, October 19, 2010 7:26 AM
I have a COM-object, and use it in my app.
COM object raises many events and my app subscribed on some of this events.
When I create this COM-object, my app loads the processor on 50%.
I'm traced it with profiler and found that the processor is loaded by processing of events on which I didn't subscribe!
Than I make a conclusion that .NET processes all events of COM object, and if my app is subscribed - raises my handlers.
How I can disable subscribing on all events?? Or how I can generate Interop dll without events that i don't want to process?
Thursday, May 10, 2012 12:24 PM
You can write your own wrapper class over COM object which will make only API calls that are needed and also subscribe/raise events.
Here is in example to do the same.
- Proposed As Answer by Sharad Birajdar Thursday, May 10, 2012 12:24 PM
Tuesday, July 24, 2012 4:02 PM
I know exactly what you are talking about. The short version is that every time you hook an event on a COM object, an instance of an object is created that contains the event handler you assigned and stubs for all the events in the event package that you didn't provide handlers for. When the event you hooked is raised, your handler is called, but so are all of the stubs. If you hook multiple events you will get an instance for each event handler that also fires all the stubs when that event is raised. This, obviously, can be expensive as you have noticed. Rather than re-type detailed explanations of what is happening behind the scenes, I'll refer you to the following links:
You may have better results if you use .NET 4.0's NoPIA feature by setting "Embed Interop Types" to true on the reference assemblies that you're using to hook events. It only pulls in the bare minimum, so maybe it won't create/fire the stubs.
I'm trying to test this myself, but have run into some problems, that I've documented here. I don't think that this problem is common, so you may not encounter it:
Anyway, please post your results if you give this a shot.