There is a rather timely article about VSIP package deployment on the Microsoft extensibility blog (Dr Ex). Due to some recent Clover.NET experiences I think there are a few additional points to be made.
Most of the problems we had revolved around the Microsoft.VisualStudio.VSIP.Helper.dll assembly. This assembly is not as well “controlled” as the VSIP interop assemblies. The beta versions of Clover.NET shipped with this assembly exactly as it comes with the VSIP Extras install – i.e. not modified at all. While it was not installed in Common7\IDE\PublicAssemblies, as Dr Ex. recommends, this dependency was a source of problems. In a few instances there was a conflict with an existing version of the assembly on the user’s machine.
In the end, we repackaged the whole Helper assembly into our own DLL to avoid conflicts with other VSIP packages. I’d be very careful about depending on the Helper DLL as it comes with VSIP Extras and would probably recommend you also repackage it, even if you do not change it.
Such assembly conflicts in a VSIP package are very difficult to diagnose because Visual Studio gives no indication whatsoever when a package fails to initialize. Some logging or an event viewer entry would be good. To diagnose these you need to have your user use debugCLR or the Visual Studio debugger to launch a separate Visual Studio instance. You need to trap any CLR exceptions and then try to initialize the package. VSIP packages are initialized on demand by the IDE, so you usually need to access some feature such as a menu item to activate the package. As the package initializes, the debugger will catch the CLR exception and you can sort out your package load errors.
Luckily for the Clover.NET development we had two cluey users who were able to help us isolate this issue.