locked
OnConnection - not being called, which class should extend IDTExtensibility2? RRS feed

  • Question

  • I'm trying to extend IDTExtensibility2 for my visual studio add-in so I can get the current visual studio instance from its OnConnection method, but I'm not sure which of my classes should be extending it. I cannot find any useful tutorials or links on how to implement it. Right now my UserControl class also extends IDTExtensibility2, but none of its methods are being called (OnConnection, OnDisconnect, etc). I'm just not really sure how I should be implementing IDTExtensibility2.
    Thursday, December 27, 2012 8:38 PM

Answers

  • Hi,

    Have you created your add-in with the Visual Studio add-In project template? The Connect class is the one implementing the IDExtensibility2 interface.

    Also, see tutorials here:

    http://www.mztools.com/resources_vsnet_addins.aspx#MZToolsArticles


    MZ-Tools: Productivity add-ins for Visual Studio: http://www.mztools.com. My blog about developing add-ins: http://msmvps.com/blogs/carlosq/

    • Proposed as answer by Carlos J. Quintero Thursday, December 27, 2012 10:41 PM
    • Marked as answer by Ego Jiang Friday, January 4, 2013 8:30 AM
    Thursday, December 27, 2012 10:40 PM
  • FWIW, actually, the class that must implement the IDTExtensibility2 is the one whose full name is specified in the .AddIn file, in the <FullClassName> tag. It is not needed to be named "Connect".

    One reason to avoid the "Connect" name is to provide command names with the name of the add-in and without that word (Ex: "MyAddIn.MyCommand" instead of "MyAddIn.Connect.MyCommand"). I explained how in this article:

    HOWTO: Create command names without '.Connect' in Visual Studio add-ins

    http://www.mztools.com/Articles/2007/MZ2007006.aspx


    MZ-Tools: Productivity add-ins for Visual Studio: http://www.mztools.com. My blog about developing add-ins: http://msmvps.com/blogs/carlosq/

    • Marked as answer by Ego Jiang Friday, January 4, 2013 8:30 AM
    Thursday, December 27, 2012 11:10 PM
  • Yes, I was using Connect somewhat colloquially to mean 'the class that VS instantiates', which as you pointed out is the one you register in your manifest file. I was further trying to make it clear that implementing random interfaces on (semi) random classes is not generally how VS extensions work. In order to ever QI (managed 'as' cast) a class VS has to have an instance of it 'in hand' for some reason. Since we are ignorant of most of the contents of toolwindows below the thing that implements IVsWindowPane, and we are also ignorant of the implementation of editors, command handlers, etc... we don't generally tend to QI many things, so the 'where do I implement this' is generally answered with a few, very specific points.

    Ryan

    • Marked as answer by Ego Jiang Friday, January 4, 2013 8:30 AM
    Friday, December 28, 2012 4:01 AM
  • Yes, VS doesn't try to cast random objects (like UserControls) to IDTEExtensibility2, it attempts to do that with the Connect class, and the Connect class only, which is the object VS creates in order to load your AddIn.

    Ryan

    • Marked as answer by Ego Jiang Friday, January 4, 2013 8:30 AM
    Thursday, December 27, 2012 10:58 PM
  • If you are inside a visual studio package and you want the 'current visual studio instance' (I suspect by this you mean DTE, but that is really just 'another interface') you would do something like:

    var dte = (DTE)GetService(typeof(SDTE));

    Ryan

    • Marked as answer by Ego Jiang Friday, January 4, 2013 8:30 AM
    Saturday, December 29, 2012 10:59 PM

All replies

  • Hi,

    Have you created your add-in with the Visual Studio add-In project template? The Connect class is the one implementing the IDExtensibility2 interface.

    Also, see tutorials here:

    http://www.mztools.com/resources_vsnet_addins.aspx#MZToolsArticles


    MZ-Tools: Productivity add-ins for Visual Studio: http://www.mztools.com. My blog about developing add-ins: http://msmvps.com/blogs/carlosq/

    • Proposed as answer by Carlos J. Quintero Thursday, December 27, 2012 10:41 PM
    • Marked as answer by Ego Jiang Friday, January 4, 2013 8:30 AM
    Thursday, December 27, 2012 10:40 PM
  • Yes, VS doesn't try to cast random objects (like UserControls) to IDTEExtensibility2, it attempts to do that with the Connect class, and the Connect class only, which is the object VS creates in order to load your AddIn.

    Ryan

    • Marked as answer by Ego Jiang Friday, January 4, 2013 8:30 AM
    Thursday, December 27, 2012 10:58 PM
  • FWIW, actually, the class that must implement the IDTExtensibility2 is the one whose full name is specified in the .AddIn file, in the <FullClassName> tag. It is not needed to be named "Connect".

    One reason to avoid the "Connect" name is to provide command names with the name of the add-in and without that word (Ex: "MyAddIn.MyCommand" instead of "MyAddIn.Connect.MyCommand"). I explained how in this article:

    HOWTO: Create command names without '.Connect' in Visual Studio add-ins

    http://www.mztools.com/Articles/2007/MZ2007006.aspx


    MZ-Tools: Productivity add-ins for Visual Studio: http://www.mztools.com. My blog about developing add-ins: http://msmvps.com/blogs/carlosq/

    • Marked as answer by Ego Jiang Friday, January 4, 2013 8:30 AM
    Thursday, December 27, 2012 11:10 PM
  • Yes, I was using Connect somewhat colloquially to mean 'the class that VS instantiates', which as you pointed out is the one you register in your manifest file. I was further trying to make it clear that implementing random interfaces on (semi) random classes is not generally how VS extensions work. In order to ever QI (managed 'as' cast) a class VS has to have an instance of it 'in hand' for some reason. Since we are ignorant of most of the contents of toolwindows below the thing that implements IVsWindowPane, and we are also ignorant of the implementation of editors, command handlers, etc... we don't generally tend to QI many things, so the 'where do I implement this' is generally answered with a few, very specific points.

    Ryan

    • Marked as answer by Ego Jiang Friday, January 4, 2013 8:30 AM
    Friday, December 28, 2012 4:01 AM
  • I used this package builder extension to create my add-in. I can't find any sort of .AddIn file, nor is there any Connect class created by default. Did I shoot myself in the foot by using this extension?
    Saturday, December 29, 2012 10:22 PM
  • Hi,

    That builder is for VS Packages, which is a kind of extension different that add-ins.

    VS Packages don't use IDTExtensibility2, nor "Connect" class.


    MZ-Tools: Productivity add-ins for Visual Studio: http://www.mztools.com. My blog about developing add-ins: http://msmvps.com/blogs/carlosq/

    Saturday, December 29, 2012 10:42 PM
  • Ah. Well, my intention for wanting to use OnConnection was to grab the instance of Visual Studio I was using - because my add-in is having problems with multiple instances open - and I was told that GetActiveObject is the wrong way to go for that. If I cannot use OnConnection in VS Packages, is there another way to do it?
    Saturday, December 29, 2012 10:57 PM
  • If you are inside a visual studio package and you want the 'current visual studio instance' (I suspect by this you mean DTE, but that is really just 'another interface') you would do something like:

    var dte = (DTE)GetService(typeof(SDTE));

    Ryan

    • Marked as answer by Ego Jiang Friday, January 4, 2013 8:30 AM
    Saturday, December 29, 2012 10:59 PM