Finally InnoSetup, a freeware very popular installer for Windows will include support for .NET, that is, constants to execute utilities from the .NET Framework SDK such as regasm.exe, etc. or to install assemblies in the GAC, etc:

InnoSetup 5.3 Beta:
http://www.jrsoftware.org/files/is5-whatsnew.htm#5.3.0

Using regasm.exe is required for COM add-ins (for Visual Studio .NET 2002/2003). Previously you had to write some custom code to get the path of the .NET Framework SDK folder, to execute regasm.exe, etc.

I have been using InnoSetup for my MZ-Tools add-in and I am very happy with it, since I switched to it many years ago after I tried the MSI-based installer of Visual Studio and found some problems.

If you want to use InnoSetup to create a setup for a Visual Studio 2005/2008 add-in, this article of mine will help you:

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

If you have read about and played with Visual Studio 2010 Beta 1, you will have notice that we are under a major change, not so breaking in the external shell but internally. Visual Studio was born as a native, COM-based, C++ application and it seems that it has started a journey of several years towards a managed, .NET application. For the end user, the changes are not so huge: a more nice look and feel in commandbars, toolwindows or editor windows, a new extension manager to discover and install extensions, etc. but for developers extending Visual Studio, although in the long term this will be great, in the short term this is kind of a nightmare because of:

• As it happens with new development, it will be plagued with bugs until all of them are fixed.
• Some things are being “deprecated”. Have you noticed the “DeprecatedException” when using properties of the new CommandBars, CommandBarButtons, etc?
• At the very least, you must test completely your extension (add-in, package) to see if it works with VS 2010, and either report bugs to MS or find workarounds to make it work.
• You need to think carefully whether or how to leverage new extensibility features of VS, or keep using a common denominator. That is, for end-users it is great all the new improvements in each VS iteration, but as a developer of commercial or public extensions, you need to target many versions of VS. For example: do you use an common extension with .NET 2.0 for VS 2005, 2008 and 2010? Or do you create a separate version for VS 2010, maybe with .NET 4.0? Do you use the same setup for all? Or do you leverage the new Extension Manager for VS 2010?
• Since add-ins are starting to be second-class citizens (with few development of new classes, methods and properties in EnvDTE* assemblies and missing or contradicting information about support in the new Extension Manager), do I start migrating to a package? Is it sensible to do it now when VS.NET 2003 should be still supported? Do I wait some years when package development (SDK) is truly easy?

On Windows Vista with the User Account Control (UAC) feature enabled, processes that need to run with admin rights prompt the user for consent (either with a “OK” action if the user is already an admin running as standard user, or with an admin password request if the user is not an admin at all).

While Visual Studio .NET 2002, 2003 and 2005 need to run as admin (so you get the consent prompt when launching them on Windows Vista), VS 2008 was designed to run without admin rights (so you don’t get a consent prompt when running on Windows Vista). For that reason, you need to carefully design your add-in to work correctly on Windows Vista without requiring admin rights, as I explained in the article HOWTO: Design a Visual Studio add-in to install and run on Windows Vista.

But what happens if your add-in running inside VS 2008 on Windows Vista needs to launch a process that requires admin rights? For example, if it needs to launch regedit.exe? It will happen that the call to System.Diagnostics.Process.Start(…) will fail because the devenv.exe process of VS 2008 is running without admin rights. I recently found this situation for my MZ-Tools add-in and fortunately you can get easily the user’s consent with this code (VB.NET) using the “runas” verb:

HOWTO: Launch a process with admin rights from a Visual Studio 2008 add-in on Windows Vista
http://www.mztools.com/articles/2009/MZ2009007.aspx

My latest article is about debugging add-ins for the Macros IDE, which is far from evident.

HOWTO: Debug add-ins for the macros IDE
http://www.mztools.com/articles/2009/MZ2009005.aspx

A long overdue task I had was to revisit the most popular article of the MZ-Tools Articles Series of my web site and provide the samples in C# code:

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

It happened that many developers didn’t bother to read or try the samples because they were only in VB.NET, so I have added them in C# too. It has taken me quite a few hours because I have been enhancing the code with better sections, comments, constants for names and captions, etc. so hopefully it is now more clear how to:

• Add a button to a Visual Studio built-in toolbar
• Add a button to a Visual Studio built-in menu
• Add a button to a Visual Studio built-in context menu
• Create a new toolbar with a button
• Create a new menu in the main menu
• Create a new submenu under a menu

The new code layout will help to identify what does what, and what to remove if you are not interested, both with the temporary or permanent approaches.

My feeling about the commandbar model of Visual Studio (borrowed from Office) has increased after all these hours: commands, buttons and commandbars are incredibly tricky because of:

• Two models: permanent or temporary user interface
• The confusing /resetaddin flag that causes many programmers that they will get a ext_ConnectMode.ext_cm_UISetup phase each time that the add-in is loaded
• The half-backed /resetaddin flag that only reset buttons, but not commandbars, so you get duplicated UI if you don’t take care.
• The CommandBarControls, that can be CommandBarButton or CommandBarPopup
• The confusing connectMode of the OnConnection method, and in general, the IDTExtensibility2 interface.
• The difficulty distinguising Name/Caption when creating commandbars or toolbars.
• The lack of helpful message error from Visual Studio when you make a mistake with a parameter of the call that adds a command, button, commandbar, etc. Only enhancing this area would save tons of hours and questions in forums.
• Etc, etc.

The result is that after several years working with add-ins, I am unable to write code to add commandbars, popups, context menus, main menus, etc. by heart. I have always to go to read the code of the article.

Some days ago I wrote about testing a Visual Studio add-in against new Visual Studio tools or extensions from Microsoft. I have been testing my MZ-Tools add-in and I have had to make it aware of those new project types, mainly to display correctly the project/file icons in some features. I wrote long time ago how to get the project type Guid from an add-in. I have updated that article with the C# version:

HOWTO: Get the project flavor (subtype) of a Visual Studio project from an add-in
http://www.mztools.com/articles/2007/MZ2007016.aspx

and I have updated too the list of known project type Guids to include XNA Game, Silverlight and SharePoint projects:

INFO: List of known project type Guids
http://www.mztools.com/articles/2008/MZ2008017.aspx

Finally, it can happen, as in my case, that I don’t want to use the services from the SDK to get the project type or flavor (I still support VS.NET 2002/2003), so I use another approach through extenders, as I explained in the article:

HOWTO: Guess the type of a Visual Studio project from an add-in or macro
http://www.mztools.com/articles/2007/MZ2007014.aspx

I have updated it to provide the C# code and to document “creative ways” of getting the project type flavor when the extender is the same for several project flavors, such as “VST” for Visual Studio Tools for Office (Word, Excel, Outlook) or “Microsoft.Xna.GameStudio.CodeProject.ParentProjectExtender” for XNA game projects (Zune, XBox, Windows).

Long time ago I wrote about HOWTO: Know the actual type behind a System.__ComObject type returned by an .Object property since chances are that you are going to find System._ComObject when using Visual Studio automation (because internally it’s all COM).

Last January 2009 Lucian Wischik, the Visual Basic Specification Lead, wrote an article in MSDN Magazine about Inspecting COM Objects With Reflection, which can be useful if you are unable to get the assembly DLL that contains the actual type behind System._ComObject to perform the cast and you need to use Reflection against the _COMObject to get its properties, call its methods, etc.

Suppose that you have an add-in, like my MZ-Tools add-in, that has a feature that needs to open (invisibly) each form of a project to (do some review, modify some properties of controls, etc.). In that case you need to call ProjectItem.Open(EnvDTE.Constants.vsext_vk_Designer) to get the EnvDTE.Window, which remains invisible (you would have to call Window.Visible = True), and then get the Window.Object property to cast it to IDesignerHost. If the operation is very long because the project has many forms, chances are that the user will want to minimize the Visual Studio IDE to do other things meantime. However, due to a bug introduced in VS 2005 (it didn’t happen in VS.NET 2003), the IDE is annoyingly restored from the minimized state each time that a form is processed.

Here you have the article that I have written with the details:

BUG: ProjectItem.Open(EnvDTE.Constants.vsext_vk_Designer) restores the IDE from minimized state
http://www.mztools.com/articles/2009/MZ2009001.aspx

And the bug report sent to Microsoft if you want to vote to fix it or track its resolution (hopefully they fix it because it ruins the user experience):

https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=420890

If you have written add-ins for Visual Studio that deal with Windows Forms, and have tried to make it work with HTML/ASP.NET pages and controls, you already know that, well, it is quite difficult if not impossible because:

1) HTML pages contain HTML controls, while ASP.NET pages can contain HTML controls or ASP.NET controls

2) VS 2008 changed the internal designer arquitecture for HTML/ASP.NET

3) VS doesn’t expose good extensibility points for add-ins (and maybe not even for packages)

There were lots of questions in the forums about all this and I wrote a post a year ago:

The (lack of) IDesignerHost in Visual Studio 2008 (Orcas) ASP.NET Web pages
https://www.visualstudioextensibility.com/2007/12/18/the-lack-of-idesignerhost-in-visual-studio-2008-orcas-asp-net-web-pages

OK, now the good news: Mikhail Arkhipov, the person within the Visual Studio team that can change this (I exhanged e-mails about this in the past) has just posted this in his blog:

What kind of extensibility would you like to see in HTML/ASPX editor?
http://blogs.msdn.com/mikhailarkhipov/archive/2009/01/19/what-kind-of-extensibility-would-you-like-to-see-in-html-aspx-editor.aspx

So, Microsoft is listening. It is our chance to speak 🙂

I will write Mikhail in a couple of days with a detailed explanation and sample of what I would like to do from within an add-in.

Last year I spent some weeks adding links to my MZ-Tools articles series in the Community Content section of the MSDN documentation of Visual Studio extensibility, to help developers extending Visual Studio with HOWTO articles, etc. This week Microsoft has notified me that I’ll receive one of the “20 Community Content Top Contributor Awards for your contributions to the MSDN & TechNet wiki” 🙂