Converting DPack add-ins to VSIP package tales, part 2

Everyone knows that VS.NET IDE loads pretty fast. This is due to its package delay loading design. Let me step back to how packages are registered before we get to loading.

When you create your VSIP package, setup its commands and their UI visibility/availability context, you then merge the commands into VS.NET. That’s done via ‘devenv /setup’ command. IDE caches all commands and menus from all configured VSIP packages (and from all regular add-ins for that matter). (That command unfortunately resets all IDE customization in the process. Hopefully this will be fixed in VS.NET 2005)

Having the commands cached allows IDE to automatically show or hide commands depending on current UI context. The UI context (represented by guids) could be one of “solution is opened”, “no solution is available”, “code editor is activated”, etc. The great part about it is that package doesn’t have to be loaded to show the commands as command cache is all IDE needs to figure it out. Note that commands have to be declared as dynamic in order to be managed by the IDE in this fashion.

In the above scenario the package doesn’t get loaded until user actually selects one of the package’s commands. The whole approach works great for all DPack’s add-ins but presents a problem for Surround With one. Surround With add-in dynamically updates its menu captions based on current file project language. For this dynamic caption update to work, two things must happen: 1 - Surround With commands must be marked as able to change their captions (easy), and 2 - VSIP package has to be loaded as soon as user activates code editor (that’s Surround With’s default UI context).

And now we come to another cool VS.NET IDE feature - being able to delay package loading until a certain UI context is set. With this feature, IDE still comes up very fast and package is not automatically loaded unless it needs to be loaded (UI context based). To set it up you’d use


registry key. You’d add a sub-key corresponding to UI context and then under that sub-key you’d add a DWORD value, one per package, with the name set to your package guid and value of 0. To illustrate, suppose DPack’s package guid is {ABCD0001-1234-5678-90AB-CDEF01234567} and code editor’s UI context is {ADFC4E64-0397-11D1-9F4E-00A0C911004F}. This is how registry setup would look like:


This works like a charm. So, if your commands are more or less static, set their UI context/visibility in the .ctc file and you should be all set. If you need finer control over commands visibility, use AutoLoadPackages with correct UI context(s).

That’s all for now.

Sergey @ USysWare