visual studio shell SelectionEvents OnChange事件丢失问题

解决办法如下：

http://stackoverflow.com/questions/14165885/add-in-events-are-never-executed

down vote

If you look at applicationObject in the debugger you'll see its a COM object, but the xxxEvents classes are not (If you can't get the code to break on OnConnection, then possibly your addin isn't getting loaded when you debug, check the tools menu) Events in COM are handled by a separate COM interface (several in this case) in the other direction which the server (VS) calls to fire them. Although COM objects have a similar typed assembly concept to CLR assemblies they are unmanaged code internally, so cannot hold roots to managed objects. So although you can hook a delegate to a COM event in a way that looks exactly like a native CLR event, your event is hooked to an RCW (runtime callable wrapper). There is a COM reference from the server to the RCW com interface, but without a CLR root the RCW eventually gets disposed which unloads the com interface, after which you won't sink any events. I'm not sure but I think this normally works when you consume a single COM object with a direct association to its event interfaces so its maybe due to how the DTE COM interface is structured... Anyway as others have said you just need any kind of managed reference to the BuildEvents, SelectionEvents and DocumentEvents classes from the app object to fix it. Multiple instances of VS load separate instances of the add in so you could just add a list of static object refs and set them in OnConnect. Subscription to DTE events doesn't seem to work - Events don't get called http://msdn.microsoft.com/en-us/library/k639e386.aspx

1 down vote

If you look at applicationObject in the debugger you'll see its a COM object, but the xxxEvents classes are not (If you can't get the code to break on OnConnection, then possibly your addin isn't getting loaded when you debug, check the tools menu) Events in COM are handled by a separate COM interface (several in this case) in the other direction which the server (VS) calls to fire them. Although COM objects have a similar typed assembly concept to CLR assemblies they are unmanaged code internally, so cannot hold roots to managed objects. So although you can hook a delegate to a COM event in a way that looks exactly like a native CLR event, your event is hooked to an RCW (runtime callable wrapper). There is a COM reference from the server to the RCW com interface, but without a CLR root the RCW eventually gets disposed which unloads the com interface, after which you won't sink any events. I'm not sure but I think this normally works when you consume a single COM object with a direct association to its event interfaces so its maybe due to how the DTE COM interface is structured... Anyway as others have said you just need any kind of managed reference to the BuildEvents, SelectionEvents and DocumentEvents classes from the app object to fix it. Multiple instances of VS load separate instances of the add in so you could just add a list of static object refs and set them in OnConnect. Subscription to DTE events doesn't seem to work - Events don't get called http://msdn.microsoft.com/en-us/library/k639e386.aspx