Some Words About Visual Studio Extensibility
Working on a book title about Visual Studio Extensibility in the latest five months and spending much time on stuff related to this topic in depth (or at least deeper than what normal developers do), I believed some facts about Visual Studio Extensibility (aka VSX) and found that many developers consider it as a hard topic to learn and its APIs as complex APIs.
Microsoft has had several attempts to fill this gap in the latest months and one of their main strategies was activating a good community for Visual Studio Extensibility. Last year Visual Studio Ecosystem team created a survey to gather community ideas about its work and I took that survey and shared those ideas. However, I thought it's worthwhile to dedicate a blog post and share my opinions publicly to see if it has some effect on the community to help improve Visual Studio Extensibility.
Before anything, I personally agree that Visual Studio Extensibility is a hard topic to learn but this isn't by its nature and I'll describe it more. I also agree that Visual Studio APIs especially those related to extensibility features aren't written well. Some guys call these APIs dirty because there isn't a good structure, naming convention and consistency between these APIs.
This Old COM-Based Product
First of all, I think that one reason of the hard concepts of Visual Studio Extensibility to learn is the fact that Visual Studio is one of old Microsoft products that now is ten years old. This product was created in COM days for COM programming but came to .NET world after its birth. Now that .NET is the common way for software development for Microsoft products, developers learn .NET codes easier and faster because it has more references to learn and also because .NET is actually a technology with great design that has a simplicity in its core.
Visual Studio is built on COM components and most of traditional extensibility points rely heavily on COM programming. Moving forward from COM to .NET, Visual Studio has changed in a way to adapt things to look more familiar to .NET but keep their COM nature and used .NET and COM interoperability in advanced levels to do this. However, normal .NET developers shouldn't know about .NET and COM interoperability in this level and most likely it's hard for them to work with Visual Studio Extensibility.
Some new features of Visual Studio Extensibility have been built based on newer technologies so are easier to learn or at least Microsoft has tried to provide these extensibility points in the way that developers work with them easily and don't care about the underlying layers. An example of this is Code Snippets that are easy to develop and deploy and you don't know what's going on behind the scene for them. Anyway, main extensibility options like add-ins, VSPackages, Visual Studio Shell and ... rely on COM components and interfaces.
Variety of Extensibility Options
The other reason is variety of Visual Studio Extensibility options. During these ten years, Visual Studio has grown and some new extensibility features have been added to it. Learning all these options that have different purposes, natures and implementations isn't so easy. There are many extensibility points that are a very wide topic for themselves like add-ins, macros, Visual Studio Shell or new Domain-Specific Languages tools in Visual Studio. On the other hand, extensibility options can be grouped in different levels based on their priority. When I put myself in charge of someone who wants to learn all these topics then it looks hard for me to learn all of them especially because these options aren't very related to general .NET programming topics and are completely new and specific to Visual Studio.
Not a Good Design
Going back and forth in Visual Studio Extensibility and seeing its APIs, codes and structure as well as the architecture of Automation Model, you can understand that they aren't designed very well (you may not agree but this is my personal opinion based on my personal experiences). In some cases, you can even stop and say what a poor design! Being an old product that is built on two technologies (.NET and COM) has made it a product with a bad inconsistency in code. Moreover, different teams and developers have worked on Visual Studio on different times and this may be another reason to see this inconsistency.
As Visual Studio is built on COM components then the necessity of usage of interfaces hasn't been avoidable. Having tons of interfaces and their implementations in a complex inheritance hierarchy makes the API hard to discover and learn especially when you can't find a general constant structure between all APIs. The number of the interfaces and their implementations is another negative point that has a mental effect on each developer who comes to this world at first glance.
On the other side, the most important drawback of interfaces shows its effect here and probably Visual Studio APIs are the best example to demonstrate about the extensibility of interfaces in APIs. As you know, extending interfaces needs some extra effort in any framework so in Visual Studio you face with many class and interface names that have a number index at the end that specify their version like Solution, Solution2 and new Solution3 in Visual Studio 2008! You know that this naming convention isn't recommended at all but it seems that this is the best way to handle the variety of interfaces and classes in Visual Studio and its automation model.
Inconsistency Between Naming Conventions
The other annoying thing in Visual Studio Extensibility is the bad naming convention for many interfaces, classes, properties, methods and ... In some places, you see some unrelated names that don't make sense at all. This point in conjunction with poor documentation for these programming elements makes it so hard (and even impossible) to learn anything about them! I faced with two instances of this when writing my book and I couldn't find any resource to know anything about them. Probably the only way to know what's behind these names is asking from Microsoft developers! You already know the importance of a good naming convention and choosing related and meaningful names in codes but Visual Studio lacks this programming principle as well.
One predictable reason for this can be that these parts of VS codes weren't supposed to be used publicly before so developers at Microsoft teams didn't care about them very much. Anyhow this doesn't seem logical to me when someone works on a very well-known product like Visual Studio!
Documentation
And the last point as I mentioned is about documentation. Even though some parts of Visual Studio Extensibility have excellent documentation but this isn't a general statement about the whole thing. I see that Visual Studio Ecosystem team is trying to improve documentation seriously so I guess this won't be a problem for developers in near future.
Conclusion
Aside these, I think that we can see a better future for Visual Studio Extensibility in the future. Microsoft changed its strategies and have gathered all teams that were working on extensibility of Visual Studio under a single umbrella named Visual Studio Ecosystem team and this team is trying hard to make things much better. It doesn't seem to be easy to change current structure of Visual Studio API completely but I think this team can solve many of the abovementioned problems and make them simpler and easier to learn and use.
However, although Microsoft can make things much better than this but this doesn't mean that Visual Studio Extensibility isn't a hard topic to learn by its nature. As I said, the variety of extensibility options, their different purposes and implementations and of course, depth of each option to learn, make it harder than many normal .NET programming topics to learn.
All in all, I hope that my forthcoming Professional Visual Studio Extensibility book, that I tried to write in a way to help the community, can be helpful for its readers to get their hands and assist them in learning about this topic in a straightforward way. The good news is I'm going to finish writing its manuscripts very soon and probably I'll finish it when Microsoft releases final version of Visual Studio 2008 later this month!
[advertisement] Axosoft OnTime 2008 is four developer tools in one: bug tracking, project wiki, feature management, and help desk. It manages your development process so developers can focus on coding. Installed or Hosted – Free Single-user license -- Free 30-day team trial.
2 Comments : 11.10.07
#1
Andrew Tobin
11.11.2007 @ 2:56 PM