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