Monthly Archives: April 2008

Other

Introducing the Automation Model (EnvDTE) Enhancement Request series

Apart from very simple approaches (macros, templates) and super-specialized DSL tools for very specific purposes, there are really only two general Visual Studio extensibility approaches: the Automation Model (formerly Extensibility model), a.k.a. EnvDTE, and the Visual Studio SDK.

While the Visual Studio SDK will be enhanced over the next years to make it truly simple, .NET-oriented, object-oriented, free of COM or C++ style APIs, etc. and maybe some day we will have a unified approach, the automation model (EnvDTE) still have its place, and there are quite a few areas of it that could be enhanced. Seeing the EnvDTE90.dll of the last Visual Studio 2008, it seems that it hasn’t been enhanced a lot :-(. So, I am planning a series of enhancement requests that I will send to Microsoft through the official channel (Microsoft Connect). Supposedly requests from MVPs get more consideration, but that plan is to post links on this blog so if you are an add-in developer (or not) you can vote for them. Hopefully Microsoft can implement them for the next Visual Studio version. I think this is a very good moment because Visual Studio 2008 has just been released, the version cycle lasts 2 years and it should be the proper time to write the specs of the next version.

My first enhancement request is the problem #1 of all times in the extensibility of Microsoft IDEs since more than 10 years ago, the problem of custom, transparent pictures for buttons:

Automation Model (EnvDTE) Enhancement: Accept .NET System.Drawing.Icon to set custom pictures in add-in commands and toolwindows
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=336868

Vote for it!

MZ-Tools Articles Series

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

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

4 Comments

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

Other

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

1 Comment

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.