locked
GetService vs DTE RRS feed

  • Question

  • What is the difference between the DTE and the GetService method inherited from Package? They seem to do the same. Get elements that is part of Visual Studio.

    I have another question that is somehow related. When we create a new file or project we add stuff to the Automation model. Do we also add stuff to the automation model when we create a VSPackage? I see a collection called Add-ins but not a collection called Packages. A VSPackage can have a Command, so I guess it does?

    I hope someone can help me answering these questions : )
    Monday, April 25, 2011 4:10 PM

Answers

  • What is the difference between the DTE and the GetService method inherited from Package? They seem to do the same. Get elements that is part of Visual Studio.

    DTE itself is just a VS service, more properly a service that is a wrapper over a whole lot of other services. As for when to use DTE vs say GetService on your package class, it depends.  DTE can only fetch 'global' VS services, GetService, since it is a 'sited' call can get global services as well as ones that are 'scoped' or specific to the site.  This is clear if you try to fetch 'psuedo-services' like IMenuCommandService. This is not a real VS service and DTE can not retrieve it, but GetService on Package (or WindowPane) can.  This is because this 'service' is injected at the Package/WindowPane level by MPF and isn't globally visible/available (because there are unique instances for each Package/WindowPane in the system).

    In general you should use your package / window pane class over DTE. In fact DTE is a wrapper layer over the real underlying VS services and thus it brings with it perf slowdowns (more indirection) and possibly memory hits (due to internal caching it may do) that are generally undesireable, though the 'cost' of any particular piece is highly dependent on that piece and can't be generally predicted. Further, since DTE was originally created to expose VS to scripting/automation when you are in DTE calls most UI that may otherwise popup as a result of whatever you are trying to do is likely to be supressed, this may or may not be desireable in your situation.

    I have another question that is somehow related. When we create a new file or project we add stuff to the Automation model. Do we also add stuff to the automation model when we create a VSPackage? I see a collection called Add-ins but not a collection called Packages. A VSPackage can have a Command, so I guess it does?


    Well you don't 'add stuff' per-se, you add elements into Visual Studio that Visual Studio happens to expose via DTE.  There is no 'Packages' colleciton exposed via DTE afaik, there is a way to enumerate packages via a VS service, but in general you don't need to do this.  As for a 'VS package can have a command', that is somewhat unrelated.  Commands are a fundamental part of VS, far below the DTE layer, so the fact that a 'package can add a command' is independent of the fact that commands are exposed through DTE.

    Ryan

    Monday, April 25, 2011 5:11 PM

All replies

  • What is the difference between the DTE and the GetService method inherited from Package? They seem to do the same. Get elements that is part of Visual Studio.

    DTE itself is just a VS service, more properly a service that is a wrapper over a whole lot of other services. As for when to use DTE vs say GetService on your package class, it depends.  DTE can only fetch 'global' VS services, GetService, since it is a 'sited' call can get global services as well as ones that are 'scoped' or specific to the site.  This is clear if you try to fetch 'psuedo-services' like IMenuCommandService. This is not a real VS service and DTE can not retrieve it, but GetService on Package (or WindowPane) can.  This is because this 'service' is injected at the Package/WindowPane level by MPF and isn't globally visible/available (because there are unique instances for each Package/WindowPane in the system).

    In general you should use your package / window pane class over DTE. In fact DTE is a wrapper layer over the real underlying VS services and thus it brings with it perf slowdowns (more indirection) and possibly memory hits (due to internal caching it may do) that are generally undesireable, though the 'cost' of any particular piece is highly dependent on that piece and can't be generally predicted. Further, since DTE was originally created to expose VS to scripting/automation when you are in DTE calls most UI that may otherwise popup as a result of whatever you are trying to do is likely to be supressed, this may or may not be desireable in your situation.

    I have another question that is somehow related. When we create a new file or project we add stuff to the Automation model. Do we also add stuff to the automation model when we create a VSPackage? I see a collection called Add-ins but not a collection called Packages. A VSPackage can have a Command, so I guess it does?


    Well you don't 'add stuff' per-se, you add elements into Visual Studio that Visual Studio happens to expose via DTE.  There is no 'Packages' colleciton exposed via DTE afaik, there is a way to enumerate packages via a VS service, but in general you don't need to do this.  As for a 'VS package can have a command', that is somewhat unrelated.  Commands are a fundamental part of VS, far below the DTE layer, so the fact that a 'package can add a command' is independent of the fact that commands are exposed through DTE.

    Ryan

    Monday, April 25, 2011 5:11 PM
  • Thank you very much!

    Should I understand this as the automation model/DTE being a more old fashion way of getting a service and one we should not use anymore except if we are writing add-ins or macros?

    This is quite an eyeopener for me. I thought I should look at the Automation model diagram to get an overview of what services I could get hold on. How do I know which services I can get with GetService? Is the following services all I can get hold on?

    http://msdn.microsoft.com/en-us/library/bb164288.aspx (Microsoft.VisualStudio.Shell.Interop Namespace).

     

    Is there any written material on this?

    Monday, April 25, 2011 6:57 PM
  • Should I understand this as the automation model/DTE being a more old fashion way of getting a service and one we should not use anymore except if we are writing add-ins or macros?

    Not necessarily, just understand that DTE was originally written as an exposure to scripting languages (not managed code) and as such its design is not going to be optimal for all managed code scenarios.  Like in all software engineering you have to watch your CPU/memory usage and decide if it is presenting problems and if so figure out where the bottleneck is and fix it.


    This is quite an eyeopener for me. I thought I should look at the Automation model diagram to get an overview of what services I could get hold on. How do I know which services I can get with GetService? Is the following services all I can get hold on?

    http://msdn.microsoft.com/en-us/library/bb164288.aspx (Microsoft.VisualStudio.Shell.Interop Namespace).

    You can get every service with GetService, it is stricly MORE powerful than using DTE.  As for 'a list of all the services', not that I am aware of, there are probably thousands and I don't think anyone has a canonical list.  The things you see in Shell.Interop are interfaces for which we have published interop assemblies, it is probably a good collection of the most frequently used interfaces but I doubt it is exhaustive.

    Is there any written material on this?


    MSDN and the SDK, but as I said before I don't think there is a 'big architecture diagram of all of VS' as that would be massive.

    Ryan

    Monday, April 25, 2011 7:18 PM
  • Thank you!
    Monday, April 25, 2011 7:31 PM