Drivers, plugins and other extensibility panacea

I’ve been always fascinated about drivers, plugins, etc. They allow you either to extend a system with new functionality or to use a system with pieces of hardware or software from different providers:

  • Back in the early 90’s when I was in college I wrote a program to make crosswords that I sent to a company which published them. I pressed a button once a month to make dozens of crosswords, the program sent them to my dot-matrix printer, I carried them to the publishing company and I got the money in my bank account some weeks later. When I graduated and I started to work in a real company I had to work 40 hours per week for the same money at the end of the month so life has not been so great in that regard since then ;-). The first versions of that MS-DOS program were monolithic, with all the code to generate different crosswords and to print to different printers inside the code. In MS-DOS you didn’t have the luxury of Windows drivers for printers, you had to send escape codes to the printer, which were different for IBM, Epson or HP emulations. Later I moved that code into driver files for crosswords and printers so the actual code of the program was reduced to the half.
  • Later in the college for graduating I had to make a MS-DOS program for digital imaging and again I spent a lot of time writing a mouse driver which worked with different graphic cards in resolutions higher than VGA (640×480), when Windows and its card drivers did not exist yet.
  • Later, then in the corporate world, I learnt about databases and the ODBC drivers. In fact, I gained a lot of experience working with the ODBC API.
  • Then I learnt about source code control (SCC) systems and the MSSCCI plugins which allows an IDE to work with different SCC providers.
  • Then I learnt about Visual Basic and Visual Studio add-ins and when I made the .NET version of my own MZ-Tools add-in I made it extensible through an MZ-Tools SDK and DLL plugins.
  • Visual Studio .NET allows you to use projects and code in different languages (VB.NET, C#, C++, etc.) and provides a unified extensibility model for all them so theoretically your add-in does not have to worry about the target language.

And so on… In a broad sense, you can also think about a kind of reverse plug-in: you have a piece of code and it works on different platforms. For example, a Java J2ME game to be played in different phones (I did a crossword J2ME game a couple of years ago) or an HTML page to be viewed in different browsers. In this case, the operating system or the browser are like plug-ins for your piece of code.

So, all this stuff of drivers, plugins and the such are great and make our life easier, don’t they? Well, not exactly:

  • If you have tried to make your program work with, say, Oracle and SQL Server you know that you cannot be database-agnostic. Despite all efforts put in ODBC, OLE DB, ADO, ADO.NET, etc. you have to know which database vendor you are using to deal with different server behavior, database driver or SQL syntax (despite ANSI SQL or ODBC syntax). And if you have tried to test your app with different ODBC drivers for the same database, for example the drivers for Oracle made by Oracle and the ones made by Microsoft, you know that they behave differently. The only solution for these two scenarios is to write your own abstraction database layer on top of the database driver to deal with the peculiarities of each database or driver.
  • Your experience printing to an HP Laserjet printer can be quite different in performance or output if you are using drivers from Microsoft or from HP. Technicians know what is a driver, what is a manufacturer, how to replace a driver, etc. but the end user doesn’t.
  • According to Eric Sink from SourceGear, which makes Vault (a replacement for SourceSafe), the planet will certainly be a nicer place to live when MSSCCI is a distant memory. In fact the new extensibility model for source code control providers in VS 2005 to overcome the problems of MSSCCI is to make your own provider from scratch, which is what Team Foundation Server does and what SourceGear plans to do
  • If you are going to use the extensibility model of Visual Studio .NET for a serious add-in, you are better off creating your own abstraction layer on top of it, with your own classes like SolutionEx, ProjectEx, ProjectItemEx, CodeElementEx, and so on because things are not the same with a VB.NET project or a C# project, not to mention a C++ project. You will find exceptions when calling methods in some languages, but not in others, or bugs in how a language implements its extensibility, etc.
  • The new Document Outline feature of Visual Studio 2005 theoretically should work with all kind of visual designers, since all components implement the IComponent interface and .NET 2.0 introduced the new ITreeDesigner interface to know the children of a control (better than Control.Controls). But it you look closely, you will notice that the document outline treeview is not the same for Windows forms and for HTML/Web forms. And even further, the document outline treeview for the new Visual Studio 2005 extensions for Windows Workflow Foundation (WWF) is also provided separately by the WWF packages. My MZ-Tools add-in provides a Control Explorer feature that mimics the Document Outline feature, but adds value with more options and a handy “most used properties” feature, so I spent a lot of time studying the Document Outline feature and trying to catch up with the new visual designers of VS 2005.
  • If you try to run a J2ME midlet in those actual phones of Nokia, SonyEricsson, Siemens (BenQ) or Motorola you will notice it does not work exactly the same (you can’t even rely on the software emulator of a phone) and you have to identify the phone brand and sometimes the model to deal with specific behaviors.
  • And what to say about different Internet browsers or different versions from the same manufacturer? …

So, drivers and plugins and extensibility are not the panacea, it’s quite tough, not for the faint of heart, but it is the price to pay for open (and cheap) systems and it is still an exciting world for a developer 🙂

Email this to someoneTweet about this on TwitterShare on LinkedInShare on FacebookShare on Google+

Tools for the toolset of add-in developers

When you think about developing add-ins likely you think that the only tools that you need are Visual Studio IDE and its debugger, right? Well, sometimes you will find that your add-in does not appear in the Add-In Manager at all, or it doesn’t load (apparently) or it causes some COM exception when it is loaded. I see those questions frequently in the extensibility forums and I always recommend to add these tools to your debugging toolset:

  • A registry monitor, to spy what VS does when it tries to discover your add-in (if your add-in uses COM and registry-based registration, not XML-based registration).
  • A file monitor, to spy disk activity when you are using XML-based registration (an .Addin file).

I used two separated tools from sysinternals (recently purchased by Microsoft) but the good news is that they are now merged into a new all-in-one monitoring tool named Process Monitor:

The Process Monitor also replaces the Process Explorer tool that I was using to monitor which processes are running and which DLLs are loaded (it can be configured to replace the Task Manager of Windows too!)

There are other tools here:

There is another invaluable tool named Lutz Roeder’s .NET Reflector (  which allows you to disassemble a .NET assembly and generate not only IL code (like ildasm) but also VB.NET or C# code. There are even plug-ins for that tool that save the disassembled code (which is shown on the screen) to a file or to a whole new VS project. This tool is invaluable when you want to know how VS works internally, for the portions that are managed code (VS is still a COM application), which are most of the new portions of VS 2005. You can use it also to see the internals of the designers of the .NET Framework, etc. The first thing to know is where to look. Many assemblies of VS 2005 are in this folder:

C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\PrivateAssemblies

But others seems to be only in the GAC. Say that you want to know how the Document Outline feature of VS 2005 is implemented internally. It happens that this feature is in this assembly of the GAC (I have been unable to find it elsewhere):


How do you use .NET Reflector to disassemble that assembly (the several “Open” dialogs of the tool don’t show it)? Here is a little trick (it’s a good thing that I am old enough to know MS-DOS):

  • Open a DOS command prompt
  • Type:

SUBST P: C:\Windows\Assembly

and then you can navigate to:

P:\GAC_MSIL\Microsoft.VisualStudio.Windows.Forms\\Microsoft.VisualStudio.Windows.Forms.dll and the class is Microsoft.VisualStudio.Windows.Forms.DocumentOutline. So you expand it, select a method, right-click “Disassembler” and there it is the code! You can also right-click “Analyzer” to show where a method is called. With this tool you can know how the Property Browser works insternally (quite complicated indeed!) and other portions of VS 2005. Alas, many other portions of VS are unmanaged so there is no X-ray for them (unless you like the native x86 code) 🙂

Email this to someoneTweet about this on TwitterShare on LinkedInShare on FacebookShare on Google+

It’s about time!

Finally I decided to start a blog about Visual Studio extensibility: macros, add-ins, templates, SDK packages, and so on. My name is Carlos Quintero, I am from Madrid (Spain) (so I do not speak English natively as you will notice) and I am Microsoft Most Valuable Professional (MVP) since 2004. If you have come to my blog chances are that you already know me from the several forums and newsgroups about VS extensibility and you know about my web site and my MZ-Tools add-in for the family of Microsoft IDEs  (VB5, VB6, VBA, VS.NET and VS 2005).

If you are starting with VS extensibility, I recommend you to visit the a section of my website with lots of resources (documentation, articles, samples, forums, newsgroups, blogs, videos, webcasts, etc.):

Resources about Visual Studio .NET 2002/2003 and Visual Studio 2005 extensibility

As you can see I update it with new resources available on the web and I write 20-30 small articles about VS extensibility each year and from now on I will announce them here so you have a reason to subscribe through RSS to this blog if you are interested in this subject.

If you have questions about VS extensibility, post them on this forum which I visit quite regularly:

Visual Studio Extensibility

And that’s all for now. BTW, I am currently at the TechEd Developers Barcelona 2006 where there are some good sessions about VS extensibility.

Email this to someoneTweet about this on TwitterShare on LinkedInShare on FacebookShare on Google+

VS SDK, packages, add-ins, macros and more…