Archive for December, 2004

DPack 2.0 Beta 1 Refresh released

This refresh release fixes an issue with Beta 1 reporting an error while starting a second instance of VS.NET. Please download the new version at your convenience.

Sergey @ USysWare

DPack 2.0 Beta 1 released

This is a first step towards implementing all of what’s on v2.0 plate. Here’s what’s new in this release:

  • Converted DPack add-ins into a single VSIP package. What that means is that you won’t see individual add-ins in the VS.NET add-in manager anymore. DPack will be listed as a single product entry under Help|About and will also be shown in the splash screen.
  • DPack enjoys some performance improvements as a result of this conversion.
  • Removed administrator user requirements on DPack’s installation. DPack can now be installed by power users.
  • Updated DPack to work for non-administrator users.
  • Changed DPack to persist its settings to HKCU as oppose to HKLM.
  • Added VS.NET 2005 Beta 1 and Beta 1 Refresh support.
  • Miscellaneous Framework Browser fixes.

The new version is available at Let me know if you have any questions or run into any issues. Enjoy and Merry Christmas everyone!

Sergey @ USysWare

Would you like to beta test DPack 2.0?

If you actively use or about to start actively using DPack and would like to beta test v2.0 please contact me via email (use email icon at the bottom of this page). I’m also looking for testers willing to give it a shot on VS.NET 2005 Beta 1. Beta won’t be ready until late December to early January time frame.

Here’s what’s changed or will be changed in v2.0:

  • Converted from individual add-ins to a VSIP package. As a result of that, v2.0 will offer tighter IDE integration and better performance (done)
  • DPack’s commands can be placed on any toolbar now (done)
  • Keyboard mapping scheme doesn’t need to be set to a custom scheme anymore for DPack’s keyboard assignments to take effect. DPack automatically assigns its shortcuts during install (done)
  • VS.NET 2005 integration (not ready yet)
  • Some major changes for bookmarks feature (not ready yet)
  • Tools|Options dialog for DPack (not ready yet)
  • New feature/add-in (not ready yet)

I look forward to hearing from you. Thanks.

Sergey @ USysWare

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

Conversion for the most part is done. Looking back at my other VSIP posts, most of it turned out to be true. What didn’t work quite right is UI context setup. I’ve ended up addin some code to enable/disable individual commands. That was still not as extensive as similar add-ins code.

The installation has been updated to install new package with all of its dependencies. VSIP package appears to be a lot easier to register than add-ins. For one thing, there is no need to call ‘regasm’ on each add-in anymore. I did run into installation side effect though. According to Microsoft, after VSIP package is copied and appropriate registry entries are added, one must call ‘devenv /setup’ to merge in new commands. Similar command must be called at uninstall time. Unfortunately, that command resets all of the customizations made to the IDE, including toolbars and menu items. I’ve read on Microsoft team blogs that it should be addressed in VS.NET 2005 but we’ll have to live with it in VS.NET 2003.

Now let’s see what we’ve gained from this conversion:

Tighter IDE integration and better performance (snappier IDE) as a result of that
DPack’s commands can be placed on any toolbar now
Keyboard mapping scheme doesn’t need to be set to a custom scheme anymore for DPack’s keyboard assignments to take effect. DPack automatically assigns its shortcuts during install
At this point VS.NET 2003 DPack 2.0 beta is ready. I’m working on VS.NET 2005 beta. I plan on releasing both betas as soon as VS.NET 2005 support’s done.

Things to be added/investigated in the betas to follow:

Investigate adding Bookmarks custom images
Add DPack options page to Tools|Options dialog
If anyone is interested in testing the new beta feel free to contact me via email.

Sergey @ USysWare

DPack version 1.3.3 is out

Here’s what’s new in this release:

  • Framework Browser add-in - added new “Show Help” button. This is a very cool feature IMHO. It allows one to open VS.NET help for the selected type. Alternatively, F1 key could be used in the dialog in place of the new button. I highly recommend that you give this add-in a try.
  • Framework Browser add-in - modified to cache delegate types.
  • Bookmarks add-in - added Ctrl-Shift-Alt-C shortcut for Clear All Bookmarks command.
  • File Browser and Code Browser add-ins - fixed a problem with add-ins not being able to open linked files on certain projects (dialogs loading times have improved due to this fix).
  • Bookmarks and Code Navigation add-ins - disabled VS.NET startup warning dialog regarding keyboard mapping scheme.
  • Miscellaneous minor UI tweaks.
  • Added J# support for all add-ins.
  • Introduced preliminary Chrome support for all add-ins (see for more information).

The new version is available at

Sergey @ USysWare

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