In a previous post I mentioned several tools that are part of my toolset as an add-in developer. In this post I would like to mention Microangelo, an icon editor that I use to create the icons/pictures for the command buttons of my MZ-Tools add-in. Once created there, I copy and paste them in the image editor of Visual Studio to change the background to almost green (R=0, G=254, B=0) that you must use for command pictures as explained here:

HOWTO: Creating custom pictures for Visual Studio .NET add-ins commands, buttons and toolwindows.
http://www.mztools.com/articles/2005/MZ007.htm

I have been using MicroAngelo since almost 10 years ago, when I started working at my current company where we purchased it. I liked it, so years later I purchased a license of version 5.x for my own use on Windows XP and I used it to create the TrueColor icons of the version of my add-in for VS 2005, which was very easy thanks to the tool (I am not very talented for graphics but I got managed to create some gradients). But several weeks ago I got a new laptop (a very nice Sony Vaio SZ3) and I installed Windows Vista, Office 2007, but alas, the capture feature of Microangelo 5.x did not work. Today I have got a new version 6.0 of Microangelo that is compatible and certified for Windows Vista 🙂

It has been several weeks since my last post but December 2006 was a quite hectic month, apart from the Cristhmas I got a LASIK operation for myopia on December 1 and I worked hard to get a new build of my MZ-Tools add-in with many optimizations for January 1. So, Happy New Year!

I also got the MVP title one more year on January 2 so the year could not start better…that means my 4th year as MVP, still in the generic “Visual Basic” category since there is no enough people for a “VS extensibility” category. But it doesn’t matter, I am commited to VS extensibility and this year I do plan to write many more mini articles (HOWTO, BUG, etc.) on my web site that I will announce here.

Microsoft has just published some early specifications (http://msdn2.microsoft.com/en-us/vstudio/aa948851.aspx) about the new Visual Studio “Orcas” and among them, it is the “CommandBar Improvements” (http://download.microsoft.com/download/5/9/c/59cd0dc5-4691-4c3e-840c-66d865f27692/command-bar-improvements.xps) which has an intriguing paragraph:

“The work we will do here will cause us to diverge from Office’s MSO Commmand Bar look and feel. Office 2007 (formerly known as Office “12”), will still use MSO Command Bars in applications such as Outlook. There, for example, customers will still see bubbly, beveled Command Bars. We believe that it is appropriate for Visual Studio to diverge from Office’s Command Bar appearance”

So, it seems that for the first time Visual Studio “Orcas” will not borrow the commandbars from Office, and I don’t know how to feel about that because all add-in developers know that creating commandbars and buttons in Visual Studio is tricky and to give a button a transparent custom picture is, well, I don’t want to get started about this… Also, I have experienced (well, my customers too) random COMExceptions (although very very rarely) creating or destroying commandbars, which are not reproducible and therefore don’t seem to be a problem on the side of the add-in. So, with a new commandbar model it could be that things get worse, or that finally commandbars are easy and problem-free, time will tell, but what is sure is that if those especifications get real, add-in developers will have to test their add-ins since the early CTPs of Orcas with the new commandbars, to report the problems that they find with the new model. Stay tuned!

Microsoft has a FAQ: Visual Studio and Windows Vista (http://msdn2.microsoft.com/en-us/vstudio/aa948854.aspx) where it is stated that Visual Studio .NET 2002/2003 will not be supported on Windows Vista, and that only VS 2005 will be supported with the SP1 and a (post-SP1) Vista Support Update. I have some comments about this:

The first one is that although .NET Framework 1.x applications will be supported, since an add-in is intended to be hosted inside a Visual Studio IDE, and since VS.NET 2002/2003 will not be supported, there is no need to test an add-in for those IDEs on Windows Vista.

Second, the VS 2005 SP1 will ship soon (maybe December 2006, maybe January 2007) and the Vista Support Update will be released “in the first quarter of 2007” but SP1 will not wait until then because “Delivering great product quality is something that we have always aimed for. We wanted to deliver the update to Visual Studio 2005 as soon as possible to our existing customers”. Given the long delay of the SP1 of previous IDES (VS.NET 2002/2003), it is quite shocking that VS 2005 SP1 can not wait a couple of months and include the Vista Support, because to run VS 2005 on Vista you will have to go through three installations, and it can be a mess.

My MZ-Tools 2005 add-in, like many others migrated from VS.NET 2002/2003 still uses COM registration, rather than XML registration (.AddIn file) and since it wants to be a good citizen in the new Windows Vista operating system, it uses HKEY_LOCAL_MACHINE to register within Visual Studio 2005 so the administrator installing it makes it available to other users of the machine (which may be other than the administrator). Previously I was using HKEY_CURRENT_USER but since I changed to HKEY_LOCAL_MACHINE, I am experiencing a problem that many of you will have seen: the Add-in Manager of VS 2005 does not persist changes in the Startup column if the add-in uses COM registration, even if you are an administrator of the machine.

I investigated this issue in the Microsoft Connect database and to my consternation it was reported twice but either the bug reports were not very clear or the Microsoft team failed to understand the problem so it is still unsolved, I reported it a third time, very clearly (I hope) but MS has answered that there is no time to fix it for SP1. So, if your add-in is affected by this problem take a look and vote for the bug to get it fixed for SP2 or VS “Orcas”:

http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=238492

I have been visiting forums about Visual Studio extensibility since year 2002 or so, and it is almost a law that if you are a newbie starting in this world of add-ins, you will have to ask the same questions that others before you because you don’t know the basics or you find an unexpected behavior. So, I have written many HOWTO, INFO, BUG and PRB articles on my web site but here are the most popular.

If you only have time to read one of the articles, this is the most popular one:

HOWTO: Adding buttons, commandbars and toolbars to Visual Studio .NET from an add-in
http://www.mztools.com/articles/2005/MZ003.htm

Chances are that if you are writting an add-in, you will need a command and a button and likely a set of them so you will want a toolbar. Alas, commands, buttons and commandbars are the most difficult part of writing add-ins, so ensure that you understand how they work. The question is so complex that there are several related articles at the end of that one, so I won’t repeat them here.

If you are working with C#, then ensure that you read this one:

PRB: Visual Studio .NET events being disconnected from add-in.
http://www.mztools.com/articles/2005/MZ012.htm

Because again, chances are that you will want to capture events, and if you don’t do it correctly, you will capture them for a while but at some point you won’t capture them. VB.NET developers are more fortunate and thanks to the WithEvents keyword they don’t incurre in the pitfall described in the article.

Before I said that creating commands, buttons, and toolbars is the most difficult task and now I realize that I lied. Or at least, partially. The most difficult task is to put a custom picture in a button, and once you think that you have got it, you are only half way, because, of course, you want it transparent and sometimes you get it green, or magenta, or gray. Somehow, Microsoft have managed to do this incredibly painful since VB5 back in 1997 and it is yet painful in 2005 with VS 2005 and I wish it was so easy as to pass a .NET managed icon (icon, which support transparency, not bitmap) but I have no hope for VS “Orcas” in 2007 ten years later so get familiar with the lime green and magenta colors, a resource editor, a satellite dll and here we go:

HOWTO: Creating custom pictures for Visual Studio .NET add-ins commands, buttons and toolwindows
http://www.mztools.com/articles/2005/MZ007.htm

If you want to work with Windows Forms controls from an add-in, you need to meet a new (foreign) guy in town, the PropertyDescriptor type:

HOWTO: Manipulating controls of Windows forms from Visual Studio .NET add-ins.
http://www.mztools.com/articles/2005/MZ001.htm

If you are just creating macros (not even add-ins) to navigate your code (projects or code elements), again a tricky proposition, here are the ones that you need:

HOWTO: Navigate the files of a solution from a Visual Studio .NET macro or add-in.
http://www.mztools.com/articles/2006/MZ004.htm

HOWTO: Navigate the code elements of a file from a Visual Studio .NET macro or add-in
http://www.mztools.com/articles/2006/MZ008.htm

Sometimes you want to work with the references of a project but, alas, they don’t appear in the EnvDTE namespace. Did Microsoft omit them? No, but they are a little hidden:

HOWTO: Getting information specific to VB.NET and C# projects from an add-in or macro.
http://www.mztools.com/articles/2005/MZ011.htm

And finally this one also appears from time to time: how do I create a tabbed window (like a document window) from an add-in? Well, a toolwindow will do the trick:

HOWTO: Understanding toolwindow states in Visual Studio
http://www.mztools.com/Articles/2006/MZ025.htm

And of course, you have lots more here:
http://www.mztools.com/resources_vsnet_addins.htm

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 🙂

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:

http://www.microsoft.com/technet/sysinternals/FileAndDisk/processmonitor.mspx

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:

http://www.microsoft.com/technet/sysinternals/default.mspx

There is another invaluable tool named Lutz Roeder’s .NET Reflector (http://www.aisto.com/roeder/dotnet/)  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):

Microsoft.VisualStudio.Windows.Forms.dll

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\2.0.0.0__b03f5f7f11d50a3a\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) 🙂