Support for loading a VS (solution) addin

Oct 6, 2011 at 3:43 PM
Edited Oct 6, 2011 at 3:50 PM

I have been looking for a general solution to allow a NuGet package to load a VS Add-in as part of the package.

The essential demo is T4MVC, to allow a simple VS Add-in that can run the .tt file when files changed or when the solution builds. Creating such a VS Add-in is simple (see but it does not come installed with the NuGet package for T4MVC.

Now I just had the idea to create a generic VS Add-in that would allow a NuGet package to 'register' a dll as a 'solution add-in'. (see

This would require the generic VS Add-in to 'regasm' the dll when the solution loads/package is added and -to keep things clean- 'regasm -unregister' the dll when the solution/VS is closed.

Another option would be to load the dll myself and load the VS Add-in and delegate objects and events through to the loaded add-ins. (Not my favourite) This however would avoid the requirement of registering the dll's. Might also make it easier to load different version (of the same tool?), unload the assemblies, etc. (in general, more control = more options)

Just now I also stubled upon an post of haacked ( where a new type of scaffolder is again added. This triggered me to look at the source code and found that the MVC tooling allows to load an assembly and it provides the EnvDTE to the assembly. This does seem rather specific to Scaffolders, so I wonder:

Since NuGet is a VS Package, could it not provide a feature to allow the loading of an assembly as a 'Solution add-in'?


ps: this is another way to get my 'world domination plan' going:

Oct 18, 2011 at 10:54 PM

The topic of having a NuGet package trigger installation of some VS extensions has definitely come up before, though I don't think we ever got too far on that.

But maybe we were looking at it from a different angle, where a NuGet package would point to some extensions from the VS gallery, such that installing the NuGet package would globally install that extension. The example we were often using was having the Spark View Engine package bring in the Spark tooling VSIX.

It seems that you're more looking at having VS Add-Ins only be active while the project is up, and then go away. I don't know enough about add-in architecture to judge on the feasibility, but it seems you've investigated some of that. I would definitely stay away from any approach that uses the global registry (via regasm), as that would blow up if you have multiple instances of VS opened and using the same Add-In (unless you start doing some ref counting, but that's really hard to get right when things crash, etc...).

Oct 19, 2011 at 12:05 PM

David, thanks for the reply (and your time).

The main idea here is indeed to have a VS Add-In loaded only when needed (e.g. for a certain project/solution). Not to be able to install more general use VSIX packages.

Ref counting ;-) Well VS is still very much COM is it not?

No the issue needing to register the add-in to allow it to be a Solution Add-in is indeed the reason I stopped the 'project' and head in here to ask if there are better options. Since you guys are inside (Ms), I wondered if you could find the reason why a solution add-in needs to be registered, as opposed to regular add-in, which can just be placed in the users' folder (C:\Users\Rudi.Larno\Documents\Visual Studio 2010\Addins) and VS will load it. If VS could load a solution add-in from a folder, the solution folder, it could work like magic. To then be able to include it in a nuget package could be really easy.

The other option is for Nuget to recognize the presence of an 'Add-in' in the package and load the add-in when the solution is opened. This add-in would not need to implement the Visual Studio IDTExtensibility2 interface. It could implement a much simpler interface, just passing in the EnvDTE, to allow it to hook up to VS.

I'm very much a Lean & Agile consultant switching client/projects and lots of add-ins all the time. Therefor I'd also like VS to be more lean and agile (see my 'world domination plan'). So for me this would be a great solution. I do understand that most developers often are just using a single solution and do not need this type of feature. On the other I can see a benefit to all developers using VS if only the required add-in (and Project Item templates, relevant Menu Items) are shown in the VS UI.

Oct 19, 2011 at 8:19 PM

The MVC team has actually taken a step in that direction with their 'recipe' feature. I'm not all that familiar with it myself, but @haacked may be able to comment further on it (here is a blog post).

Oct 20, 2011 at 8:57 AM

Interesting, it would depend on what other type of 'IRecipe' would become available. e.g. considering the case of T4MVC, all you really need/want is access to EnvDTE to be able to hook up the events, so that we can execute the 'Run Custom Tool' command on the

As an alternative, next to having IRecipe, the Extensibility could also provide a more generic IAddIn (giving direct, non UI access to EnvDTE).

If time permits, I'll have a look at the Developer Preview. See what I can come up with.