Monthly Archives: July 2013

MZ-Tools Articles Series, VS Packages

MZ-Tools Articles Series: HOWTO: Get an EnvDTE.DTE instance from a Visual Studio package

Two extension approaches (add-in, packages), two APIs (automation model, services)… and four combinations:

It happens that add-ins not only can use its more natural API (the EnvDTE automation model), but can also use services provided by the Visual Studio shell and packages. The EnvDTE automation model doesn’t provide a direct way to get a service but you can do it as I explained long time ago in this article:

HOWTO: Get a Visual Studio service from an add-in
http://www.mztools.com/Articles/2007/MZ2007015.aspx

And packages not only can use its more natural API (services), but can also use the EnvDTE automation model. In fact, the EnvDTE*.* reference dlls are added by default to VS Package projects!. Getting the DTE instance from a package is not difficult except for a little detail: if the package is marked to load on startup (autoload), rather than using delayed loading, it can happen that the IDE is not initialized yet and the package can’t get the DTE instance. This IDE initialization problem happens also with add-ins, which have an OnStartupComplete method and therefore there is pattern to initialize correctly an add-in. Alas, packages need to use a more complicated pattern to get notified when the IDE is fully initialized, with a trick that Microsoft explained originally in this post:

Dr. eX: Why does GetService(typeof(EnvDTE.DTE)) return null?
http://blogs.msdn.com/b/vsxteam/archive/2008/06/09/dr-ex-why-does-getservice-typeof-envdte-dte-return-null.aspx

Since I found the code of the package class somewhat dirtied with that approach, I have rewritten it with a more clean approach (using a separate class for the task):

HOWTO: Get an EnvDTE.DTE instance from a Visual Studio package
http://www.mztools.com/articles/2013/MZ2013029.aspx

MZ-Tools Articles Series

MZ-Tools Articles Series: HOWTO: Create a project from a Visual Studio add-in inside a solution folder

A couple of weeks ago I wrote about how to create a project from a Visual Studio add-in. A question today in the MSDN VSX forum has made me to realize that I only covered the case when you add a project directly to the solution, not the case when you want to add the project to a solution folder.

At first I thought that it wouldn’t be possible because of this similar scenario:

PRB: NotImplementedException adding a solution folder to a solution folder in Visual Studio from a macro or add-in.
http://www.mztools.com/articles/2011/MZ2011002.aspx

But it happens that it is possible, so I have written another article with sample code in C# and VB.NET:

HOWTO: Create a project from a Visual Studio add-in inside a solution folder
http://www.mztools.com/articles/2013/MZ2013028.aspx

And of course I have to correct the article above because it is also possible to add nested solution folders, although it seems that only virtually (not on disk).

MZ-Tools Articles Series, VS Packages

MZ-Tools Articles Series: HOWTO: Autoload a Visual Studio package

One of the first things that you learn about Visual Studio packages is that by default they are loaded on demand (delayed loading), not when Visual Studio launches (because there are tons of them and it would take a lot of time, CPU and memory to load all of them).

To show their user interface (for those that have one) without loading them, Visual Studio uses a trick: the UI is created and persisted on disk at installation time; the same “permanent UI” approach that is also available to add-ins, although add-ins have also the “temporary UI” approach.

However, what if you really need to load a package on startup? (for example because it needs to listen to VS events). It happens that the answer is more complicated than just a binary flag. It is made with an attribute with a special Guid. My second article about packages explains it, with some insight of the whole mechanism from that attribute and Guid to the Windows registry where Visual Studio locates which packages to autoload and when:

HOWTO: Autoload a Visual Studio package
http://www.mztools.com/articles/2013/MZ2013027.aspx

VS 2013

Visual Studio 2013 Options window now resizable

Finally (well, after 6 releases and 10+ years…) the Options window of Visual Studio 2013 will be resizable (at least in VS 2013 Preview it is), and of course it will remember the size between sessions. This opens an opportunity for better integration of “heavy” Visual Studio extensions (ie, with lots of options) that previously used its own Options window because they required more room or wanted to provide resizable listviews (like my MZ-Tools add-in).

The built-in VS options window has always provided a two-level navigation tree so, with the new resizing capability, it should meet the needs of most extensions, if not all. However:

– While many extensions need only “personal” settings, some extensions (like mine) provide also shared “team” settings, that are stored in a shared network folder and allow “read-only” access for team members that are not team leaders. This is because, as you know if you are a team leader, you may desire to enforce team settings, rather than just documenting and “telling” the team members the settings that they should use (ex: this company uses 3 spaces indentation, rather than the default 4). Visual Studio doesn’t provide this capability.

– If your extension targets several Visual Studio versions, you need to wait some years until VS 2013 is the lowest one that your extension supports.

VBA add-ins

MSADDNDR.DLL 12.0.20617.1 installed by VS 2013 Preview breaks setups of VBA add-ins

In the last couple of days two users of my add-in MZ-Tools 3.0 for VBA have reported me that the (latest) setup failed with error “Unable to register DLL/OCX:RegSvr32 failed with exit code 0x5”.

Again?

After discovering some months ago that the problem happened because Office 2013 no longer ships the MSADDNDR.DLL file, officially confirmed by Microsoft, I modified the setup to install that file if missing. Then I had to modify the setup again because apparently an older version of that file didn’t work either, so the setup installs it now “if missing” or “if present file older”.

And then, these two bug reports with the same problem? One of the users provided me the version installed on his system: 12.0.20617.1, and a copy, so I could reproduce the problem. Where does that version “12.0.20617.1” come from, if older versions were “6.x.y.z”?. At first I thought about Office 2010 (internally version 12.0), but once I verified with Orca.exe that it ships version 6.x, I searched the term 12.0.20617.1 on the web, and you know what? It is installed by VS 2013 Preview (internally version 12.0)! (I have verified and reproduced the problem). And why does it break existing setups that ship version 6.x? Because it is not backwards compatible! I explain the details in this bug report that I have opened at Microsoft Connect:

MSADDNDR.DLL 12.0.20617.1 installed by VS 2013 Preview breaks setups of VBA add-ins
http://connect.microsoft.com/VisualStudio/feedback/details/793386/msaddndr-dll-12-0-20617-1-installed-by-vs-2013-preview-breaks-setups-of-vba-add-ins

The workaround is easy: force the setup to install its version, not matter which version is installed, but I want to know from Microsoft if I will break VS 2013 doing that.

MZ-Tools Articles Series, VS Packages

Announcing the MZ-Tools Articles Series about Visual Studio SDK packages

2 Comments

One of the consequences of my decision to move to SDK packages (apart from changing the title of the blog “Visual Studio Extensibility with Add-ins” at some point) is to start the MZ-Tools Articles Series (about Visual Studio SDK packages). I have created a new section on my Resources about Visual Studio .NET extensibility page for the MZ-Tools Articles Series (about packages) that I plan to write in
the next years. My first impression is that if extensibility with add-ins is tricky, extensibility with packages is hard, because of the lack of an object model, the COM roots of Visual Studio, etc. You only have to compare the code of the projects generated by the add-in project and the package project wizards… so there is a lot to learn and to write about :-). My approach will be the same than in the MZ-Tools Articles Series about add-ins: many small articles, with sample code, focused on specific things (HOWTO, INFO, BUG, etc.), classified by area. I hope they will help not only developers starting with Visual Studio extensibility from scratch, but also developers moving from add-ins to packages.

Since all this means that I will create a lot of packages for
the articles samples, the first article is how to customize the templates used by the package wizard:

HOWTO: Changing the source code of Visual Studio Package project templates
http://www.mztools.com/articles/2013/MZ2013026.aspx

VS Packages

Moving to SDK packages (slowly)

I have been developing add-ins for Visual Studio since the first Visual Studio .NET 2002 version. But, as you already know if you are long-time reader of my blog, add-ins have become now second-class citizens in the Visual Studio Extensibility (VSX) ecosystem, something that manifests in the following facts:

– Minor enhancements of the automation code model (EnvDTE*.*, EnvDTE80, VSLangProj*.* etc.). The last Visual Studio versions, while have shipped new assemblies EnvDTE90.dll, EnvDTE100.dll, etc., they have provided very little new functionality.

– The code model (EnvDTE.ProjectItem.FileCodeModel) has lacks and bugs (that I reported at Microsoft Connect) that are not going to be fixed.

– Add-ins can not use the VSIX deployment mechanism, nor the Visual Studio Gallery as packages can. They remain in a separate Add-In Manager, rather than the new Extension Manager.

– Add-ins suffer a lot when Microsoft decides to change some internal implementation (the VS 2010 release, which changed Office-based commandbars by WPF-based ones was specially painful, I had to report tons of bugs). The reason is Microsoft doesn’t use add-ins (only packages), so they are less tested, either manually or automated (CommandBar model, etc.).

– Several improvements that I have suggested have been rejected, to the point that I won’t bother to suggest anything more about add-ins.

Ultimately, it seems that Microsoft’s intention at some point is to remove add-ins, as they did with macros in VS 2012. That doesn’t mean that the automation model will be removed, because packages can use it too, but it means that the Add-in Manager and the way add-ins create commands and UI items will be removed.

So, I have decided to start moving to Visual Studio packages, although slowly. I have already completed the “theory” part reading the available information, and I will start practicing the next weeks and months, until I find the best approach to migrate a heavy add-in like MZ-Tools to a package. Rather than migrating right now as soon as possible, I want to explore a concept that I am thinking about a lot lately: the dependency inversion principle, which means to make a Visual Studio “plug-in” independent of Visual Studio dependencies, through the use of “adapters” and programming against interfaces. For example, the plug-in would use an invented ISolution interface, that would be implemented by a type that can use the automation model (EnvDTE.Solution) or the IVsSolution interface of Visual Studio, depending on the adapter that I use to connect it to Visual Studio. While more complex at first sight, that independence allows to host a plug-in in several Visual Studio versions, different hosts (Visual Studio and VBA editor, for example) and to use the same integration tests used in Visual Studio (real but slow) with stubs (fake but fast). I will share all this as it develops.

MZ-Tools Articles Series

MZ-Tools Articles Series: HOWTO: Changing the source code of Visual Studio Add-in project templates

Nine years ago, back in July 2004, my very first article of the MZ-Tools Series was about changing the source code of templates used by Visual Studio when generating projects (Class Library, etc.):

HOWTO: Changing the source code of templates used by Visual Studio .NET wizards
http://www.mztools.com/articles/2004/MZ2004001.aspx

All these years later I have used hundreds of times the Visual Studio add-in wizard to generate the samples of add-ins for the articles, and I find myself changing the default code over and over. Some days ago I wondered about publishing online better templates with the correct patterns, etc. but that is not possible because the code is generated by a wizard, that is needed to generate the .AddIn file outside the project folder (otherwise an add-in project is just a Class Library project). So, what I have done is to modify the templates used by the wizard, which happen to be in a hidden location, documented in this new article:

HOWTO: Changing the source code of Visual Studio Add-in project templates
http://www.mztools.com/articles/2013/MZ2013025.aspx

The strange case of...

The strange case of error 80131515 loading a Visual Studio add-in

This morning I got an error 80131515 loading my MZ-Tools add-in that I had never seen before, and it was not mentioned in my article HOWTO: Troubleshooting Visual Studio and Office add-ins, so I searched the web.

It happens that after installing the add-in through the setup on a virtual machine on Windows Azure, I downloaded a new build from my web (just the dll, not a new setup), replacing the existing dll. And this error appears when you download a dll in such way, so it is “blocked” by the OS preventing its execution for security reasons. The solution is to right-click the dll file to show its Properties window, and in the General tab, Security zone, click the “Unblock” button.

VS 2013

Visual Studio 2013 Preview: add-ins still supported, add-in template moved to SDK

The question that I raised one month ago about support for add-ins in Visual Studio 2013 already has an answer: they will be supported. If you install the Visual Studio 2013 Preview or set a virtual machine in Windows Azure with the Visual Studio 2013 Ultimate preview image (my approach), your will notice two things:

1) The Add-in Manager is still there.

2) In the New Project dialog, the “Other Project Types” “Extensibility” node doesn’t exist (nor the “Visual Studio Add-in” template).

About this second fact, I guess that now I can reveal this: Microsoft consulted me confidentially many months ago about moving the “Visual Studio Add-in” template to the Visual Studio SDK and I thought that it would be a good idea, a more natural place with other Visual Studio Extensibility (VSX) templates. And certainly, if you install the Visual Studio 2013 Preview SDK, the “Other Project Types” “Extensibility” node appears with the “Visual Studio Add-in” template and others for “Visual Studio Package” and “Visual Studio Shell Isolated”. BTW, I requested Microsoft support for add-ins in the Extension Manager (removing Add-in Manager), VSIX, etc. as other extensions (to gain parity) but it seems that to no avail. Add-ins will remain as second- class citizens in the VSX ecosystem.