Archive for the 'VSIP' Category

Visual Studio Text Markers w/o VSIP

One of the reasons for converting DPack from a collection of add-ins to a single VSIP package was to gain access to text markers. Numbered Bookmarks feature utilizes that with text marker being bookmark images shown in the Visual Studio gutter.

In his post Alex shows how to use text markers with add-ins, i.e. w/o VSIP. Keep in mind, that while you can get to the markers already exposed by VS, AFAIK there is no way to create brand new markers with add-ins. You’d still need VSIP for that.

Here’s his Text Markers article.

Sergey @ USysWare

Creating a Visual Studio 2005 Tools/Options Page

Brought to you by Jim Glass of Microsoft:

This draft walkthrough guides you through the steps of creating two Tools/Options pages.

Sergey @ USysWare

Microsoft extensibility chat tomorrow, January 19th

This is just a reminder for those who’re interested in IDE extensibility: “Join the Visual Studio Extensibility Team in a chat where you can ask questions about how the extensibility features of Visual Studio works, and how you can make those features work for you.“

Chat is tomorrow, January 19th, at 1pm PCT.

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

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