Should DTE be avoided?

[reduckted]

I've been thinking about this for a while, but it's probably more important now that Visual Studio 2022 is here. Should using the DTE (or DTE2) be avoided when there are other ways of getting the functionality that you need, even if it's more complicated?

For example, to get all of the projects in the solution, you can use DTE.Solution.Projects, or you can use the IVSHierarchy API. There's DTE.Events, but there's also Microsoft.VisualStudio.Shell.Events (I'm not sure if they provide similar functionality though). There are numerous other examples.

I was under the impression that DTE was old, outdated and possibly not as efficient as using the other services because of all the COM overhead. Is that right? Should we try to avoid it as much as possible?

[madskristensen]

Yes, the DTE should be avoided, but that has been hard due to the complexity of the alternatives. I'm in the middle of converting some of the events in the toolkit away from the DTE events.

[yannduran]

Why do you say that DTE should be avoided? Is that some insider knowledge? Or a direction that the team want to emphasise?

Personally I think the complicated old COM ways should be avoided at all costs as it leads to hard-to-understand, brittle code. The DTE actually gives some protection. It's all of the complicated old COM interop stuff that's outdated, not DTE. DTE is a managed wrapper around all that hard stuff. The DTE method implementations can be changed much more easily than COM interface-based code, as has been clearly demonstrated by VS 2022.

The issue with DTE vs DTE2 is a non-issue really as nobody should be using DTE anymore in 2021. Switching to DTE2 is a very easy fix to implement. I think that more and more COM-based code should be hidden behind something like DTE, and is exactly what the toolkit itself is trying to accomplish.

VS is in the mess that it is precisely because there's too much very old COM-based code that very few people understand and that nobody wants to change, and preventing improving it.

I've heard the 'avoid DTE' argument for years now, but I've never been given any reasonable explanation as to why.

[madskristensen]

I use the DTE all the time for the same reason you list. However, it is old, unmaintained, not async, doesn't follow the latest best practices, is missing capabilities. Also, the Visual Studio team has been recommending people not using it for many years now

[yannduran]

You're right, it's old. But the COM stuff is even older :-P The COM interfaces are set in concrete and are almost impossible to change. DTE gives the opportunity of changing the implementations to whatever is current without breaking its contract. On the other hand, the COM interfaces are like coding knee deep in molasses, or slowly sinking into quicksand.

Until I hear some actual reasons from anybody as to why it should be avoided, I won't be changing my mind about it, nor will I be stopping using it.

If the the team is seriously suggesting we should resort to using the archaic, brittle, hard to understand, even harder to maintain COM interfaces, then I have my doubts about the team. You know what I mean?

[shaggygi]

If trying to avoid/hide the DTE, is it good to expose publicly? Not sure a way around, though.

For example...

Community.VisualStudio.Toolkit/src/Community.VisualStudio.Toolkit.Shared/ItemNode.cs

Line 124 in 64ffb81

public EnvDTE.ProjectItem? ToProjectItem()

[yannduran]

I agree that it should be used internally. I don't believe that it should be exposed publicly, no.

Just my opinion of course, for what it's worth.

[shaggygi]

A few pennies regarding ItemNode...

IMHO, ItemNode is too vague.

At first, I was thinking maybe HierarchyItem and let it implement IVsHierarchyItem. However, I'm starting to lean toward HierarchyNode and pass in IVsHierarchyItem as it is currently.

As mentioned previously, I'm not sure it is wise to expose DTE stuff if the goal is to avoid it. Plus, it would decrease possible breaking changes when future decisions are made on VS Extension model vNext (at least on the direction of using DTE and IVsXXX).

I noticed in the IVsHierarchy doc, it states IVsHierarchy is not meant to be specific to a Solution/Project hierarchy.

The IVsHierarchy interface is not used only for project hierarchies. For example, the Server Explorer window implements the IVsHierarchy interface to display its hierarchy, which is not a project hierarchy.

Therefore, I wonder if we should create different types of Nodes for the Toolkit. Meaning, ItemNode should be named something related to Projects if it going to expose related functionality. I would not want one class to include everything as that creates maintenance/confusion issues. Does that mean ItemNode becomes ProjectItemNode or ProjectHierarchyNode?

When it comes to guidance on avoiding DTE, use IVsXXX, etc., it would be nice to hear from the VS team on the thinking/reasoning as it would help the community provide input to building out this toolkit. The unknown makes it more difficult to help/support the effort.

I'm still reading up on all this so take it as "thoughts from a newbie" 😄

[madskristensen]

I went with SolutionItem

[yannduran]

Nice choice, I like it! But does that conflict in any way with Solution Explorer's Solution Items node though?

[madskristensen]

It does not. Solution Item is just a string name for the solution folder and doesn't have any underlying types associated with it

[yannduran]

Ah cool! I just wanted to mention it, just in case.

[shaggygi]

In this case, should NodeType be renamed to SolutionItemType as it is only used with related?

[madskristensen]

The toolkit is now completely free from any EnvDTE references

[shaggygi]

If we went with the extensions approach above, what would the Type (SolutionItemType) be for external extensions? Would they always be Unknown? I recall the C# design team working on "extension everything", but not sure when that feature will be added or if it would help in this scenario.

Also, and in addition if it were Unknown, how would you find other items in hierarchy? Using FindParent for example, how would you find item based on your extension item?

[madskristensen]

You can always make your own by assigning an arbitrary integer unit to the Enum. I forget how I have done it in the past, but something like this:

SolutionItemType type = (SolutionItemType)123;

However, I don't know if there is a use case for adding additional item to the list. Alternatively, send a PR to the toolkit to add any missing items.

[madskristensen]

I've added Project and PhysicalFile classes. Do they capture the idea correctly?

[shaggygi]

I noticed a mention of having interfaces or not. Should SolutionItem be changed to at least an abstract class? Recall seeing peeps in the .NET review streams recommending abstracts over interfaces.

[yannduran]

@madskristensen I always add an Unknown with a value of 0 to all of my enums.

@shaggygi For many years Microsoft has been recommending composition over inheritance. I guess it wouldn't be the first time MS has flipped on its own advice.

@madskristensen it'd be nice to compile a list of Microsoft's latest advice somewhere, either as questions like this arise, or a researched list. This would be a good place for developers to learn about Microsoft's latest recommendations. Online sources (including videos) are often out of date.