All posts by Carlos Quintero

MZ-Tools Articles Series: HOWTO: Design a Visual Studio add-in to install and run on Windows Vista

When I searched just “MZ-Tools” on Google some time ago I noticed one of the first results in the second page: Making MZTools for VBA work on Vista and it was amazing to me that some user went as far as finding a way to make an old version of my MZ-Tools add-in for VBA work on Windows Vista and publish a blog post with screenshots of what you needed to tweak that now seems quite popular. Of course I was aware of this problem and I fixed it some months before, so he could have downloaded a new version. But anyway, this illustrates a point: if you don’t take the proper design decisions, an add-in that worked fine on Windows XP (as long as you were administrator), it may not work on Windows Vista because by default even administrators don’t have administrator rights (which although it’s a culture change is a good thing IMHO). My latest article explains some design decisions that you must take into account for your installer (installation time) and your add-in (run time):

HOWTO: Design a Visual Studio add-in to install and run on Windows Vista
http://www.mztools.com/articles/2008/MZ2008011.aspx

MZ-Tools Articles Series: HOWTO: Create a setup for a Visual Studio 2005 / 2008 add-in using Inno Setup

This is another of those articles long overdue that I kept in a list and that I wanted to write. Back in 2004 I finished the first commercial version of my MZ-Tools add-in for .NET and despite my hate for setups (I much prefer XCOPY deployment to be confident that my computer remains uncorrupted) I knew I had to create one because my customers would expect it (the free versions of MZ-Tools for VB6/VBA/VB5 didn’t have a setup until many years after its origin back in the year 2000) and alas, add-ins in VS.NET are much more complicated to deploy (you needed an ActiveX/COM shim control to create toolwindows in VS.NET 2002/2003, for example).

So, my first choice was, of course, the MSI-based setup project that VS.NET 2002 created for each add-in project. The result was that, if I already hated setups, I hate MSI-based setups even more since then. I found several problems:

  • The setup used a progress bar that when reached 100%, it started again for a second phase. Being a perfectionist, I prefer a single pass from 0% to 100%, and if for some reason the setup can’t go from 0% to 50% in the first phase and from 50% to 100% in the second phase, I much prefer no progressbar at all (alas, my current uninstaller has the same problem that I have been unable to solve yet although I am close). Anyway, this is a minor detail.
  • For some customizations you couldn’t use the setup project properties, but you needed a tool named Orca MSI editor, or something like that.
  • If you want a multilanguage setup (not a different setup for each language) I think that it was not possible.
  • I needed slightly different setups for the trial version and the full version, and the setup project didn’t allow that easily.
  • And finally there was a nasty bug (or “by design” issue) that I documented and reported to Microsoft: BUG: Visual Studio .NET Setup Projects Execute Custom Action of Previous Version when Upgrading.

Finally I gave up MSI and searching alternatives, I found Inno Setup, a free script based setup. It allows multilanguage setups in a single .exe, it has preprocessor capabilities (conditional compilation that I use for the Trial/Full version) and despite being script-based it has a companion ISTool to create the setup more user-friendly. Furthermore it has great forums, 3rd party tools and web sites devoted to provide useful scripts for some tasks. And guess what? Its progress bar goes a single time from 0% to 100% and very fast :-).

So, despite being now a Microsoft MVP and being aware that Microsoft greatly recommends MSI for setups due to its transaction capabilities, if you need a setup for an add-in (not for a VS SDK package) which uses XML registration and no COM registration is involved, you are quite safe using a non MSI-based setup (FWIW my add-in uses COM registration for historical reasons and I have had no problems with my customers using Inno Setup).

Since InnoSetup is script-based and it uses Pascal as language for the custom code, I wrote a ready-to-use Inno Setup script that you can customize easily and use. The details are in the following article:

HOWTO: Create a setup for a Visual Studio 2005 / 2008 add-in using Inno Setup
http://www.mztools.com/articles/2008/MZ2008010.aspx

The special and in another time unique “Solution Items” folder of Visual Studio 2005

Back in VS.NET 2002/2003 a solution could contain only up to two folders, which were special: the Solution Items folder and the Miscellaneous Files folder (if you configured a setting in the Options window to show it), and the automation model (EnvDTE) contained their well-known GUIDs to identify them (EnvDTE.Constants.vsProjectKindSolutionItems, EnvDTE.Constants.vsProjectKindMisc).

VS 2005 introduced a new concept, the “solution folders”, that could contain projects, and you could create lot of them, and you had a new well-known GUID (EnvDTE80.ProjectKinds.vsProjectKindSolutionFolder As String = “{66A26720-8FB5-11D2-AA7E-00C04F688DDE}” to identify such folders, and guess what, alas, it happens that the old Solution Items folder is just a “solution folder” in the new IDE, indistinguishable from the others but by the name, so the GUID cannot identify it and then you can only rely on the name “Solution Items” to distingush them (because the IDE doesn’t allow you to create two solution folders with the same name), and the Project.UniqueName includes a GUID too (such as “Solution Items{24571E2E-0233-4835-9C48-80E8D75EC95E}”) to make them truly unique I guess (just in case you nest them, because as I said, the IDE doesn’t allow two folders with the same name with the same parent, but it does with different parents).

So, in VS 2005, there is no really a unique “Solution Items” folder, you could rename it, or have tons of them with files, even nested, but if you really want to locate and use it as you could in VS.NET 2002/2003, I think that your only chance is the name, and whether you use the UniqueName or the Name to search the “Solution Items” string, take into account that can be localized (not tested) if you deploy it to international non-English IDEs.

MZ-Tools articles series: HOWTO: Removing commands and UI elements during Visual Studio .NET add-in uninstallation (updated)

I have updated a quite old but useful article (Feb 2005) to document the new /ResetAddin command-line flag of Visual Studio 2005/2008 and how to do it correctly:

HOWTO: Removing commands and UI elements during Visual Studio .NET add-in uninstallation
http://www.mztools.com/articles/2005/MZ2005002.aspx

It is important to note that the /ResetAddin command-line flag will remove permanent controls but not permanent commandbars (another reason to not use them). 

devenv.exe /SafeMode and add-ins in Visual Studio 2005 / 2008

Just a curious difference in behavior between Visual Studio 2005 and Visual Studio 2008 that the MSDN documentation doesn’t cover very well:

According to the MSDN documentation of VS 2005, “This switch prevents all third-party VSPackages from loading when Visual Studio starts, thus ensuring stable execution.” One would expect that if third-party VSPackages are not loaded, add-ins would be also excluded from loading, but they aren’t, they are loaded.

Visual Studio 2008 works as expected and the whole Add-in Manager is disabled.

Unknown error (error number 80131522) loading add-ins

I am writing an article about creating setups for Visual Studio add-ins and testing I have found that if the namespace/class specified in the <FullClassName> tag of the .AddIn XML file does not match the actual namespace and connect class name in the source code, you get an obscure <Unknown error> (error number 80131522) loading the add-in. Searching the web I found in the forums that I was not the first developer with this problem, so I have updated my article to reflect this:

HOWTO: Troubleshooting Visual Studio and Office add-ins
http://www.mztools.com/articles/2007/MZ2007009.aspx

It would be great if Microsoft could provide more helpful message errors when things are not set up as expected…

MZ-Tools Articles Series: HOWTO: Get the text editor font and colors information in a Visual Studio add-in

Although I wrote long time ago an article about EnvDTE.DTE.Properties, it was not until this week that I needed to retrieve font and color information of the text editor of Visual Studio. Basically I am changing the code template editor of my MZ-Tools add-in from black and white to colorized text using a RichTextBox, resembling as much as possible the code editor of VS without using more complex 3rd party products (such as Activepro Syntaxt Editor, which seems excellent) or trying to host the Visual Studio code editor inside a Windows Form.

Here is a new article about this subject and some things that I have encountered.

HOWTO: Get the text editor font and colors information in a Visual Studio add-in
http://www.mztools.com/articles/2008/MZ2008008.aspx

BTW, notice that VS 2005 has a bug (fixed in VS 2008) and the “Comment” foreground color is not returned correctly (although the VS code editor colorizes perfectly). You may want to use the XML Comment or CSS Comment foreground color in this case.

New book on Visual Studio extensibility

As you may have noticed, there aren’t many books on Visual Studio Extensibility, so any new book is great news. This is the case of a new book with the title “Professional Visual Studio Extensibility” by Keyvan Nayyeri:

http://nayyeri.net/blog/professional%2Dvisual%2Dstudio%2Dextensibility%2Dfinally%2Dreleased/

It is already available from Wiley and Wrox (where you can read the TOC, index, and first chapter) and will be available from Amazon shortly. I haven’t read it yet (I am awaiting a complimentary copy in a few days or weeks) but I am excited because this book covers more than add-ins or macros, so you have chapters about VS SDK packages, DSL tools, Visual Studio Shell, extending the debugger or even MSBuild. While there is lot of information about those subjects in MSDN and blogs, I personally prefer a good book to learn new technologies.