A new article of my MZ-Tools articles series about a bug of VS 2005:
BUG: Tooltip not set for add-in commands in Visual Studio 2005
A new article of my MZ-Tools articles series about a bug of VS 2005:
BUG: Tooltip not set for add-in commands in Visual Studio 2005
If you are developing addins for Visual Studio, you should be aware that there are several localized editions (Spanish, German, French, etc.). This article provides info to take into account when locating commandbars by name in your add-in:
HOWTO: Locate commandbars in international versions of Visual Studio
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.
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”:
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
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.
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
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.
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.
HOWTO: Navigate the code elements of a file from a Visual Studio .NET macro or add-in
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.
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
And of course, you have lots more here:
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:
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:
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:
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 (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):
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):
SUBST P: C:\Windows\Assembly
and then you can navigate to:
P:\GAC_MSIL\Microsoft.VisualStudio.Windows.Forms\18.104.22.168__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) 🙂