I’ve been in many discussions lately with various folks about Visual Studio 2010 extensibility. Inevitably, someone suggests a solution to some problem involving changing/adding/deleting a registry key/value for an extension. If you need to do this, just remember this one rule:

Do not ever edit a key that ends in “_Config”

HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\10.0

This key contains your user-specific settings and works the same as it has in prior VS releases. This could be things like pointers to your default project locations, window layout data, etc… In general it is OK to make tweaks to this key. The worst thing that could happen is that you end up corrupting your user settings. Deleting the key will cause the first-launch “Please choose a profile” dialog to come up the next time you launch Visual Studio.

HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\10.0_Config

If you examine the contents of this key, you’ll see that it contains the configuration data for VS 2010. This includes things like package registration, project system registration, editor factory registration, etc… You may also notice that the contents are very similar to HKLM\Software\Microsoft\VisualStudio\10.0.

You can think of the _Config key as a volatile cache of VS’s configuration data for a particular user. It is simply the combination of HKLM\Software\Microsoft\VisualStudio\10.0 and any pkgdef files coming from VS extensions (either from Common7\IDE\Extensions or %LocalAppData%\Microsoft\VisualStudio\10.0\Extensions).

(A previous post discussed how the Experimental Instance works.)

If you edit a key in 10.0_Config, Visual Studio will (quite possibly) delete it on startup.

If you need to change a value, always do one of the following:

1. Edit the value under HKLM\Software\Microsoft\VisualStudio\10.0
2. Edit (or add) a pkgdef file for the extension in question (For managed VSPackages, this is likely editing/adding a RegistrationAttribute in your code).

We’ve just released Visual Studio 2010 Beta 2 (and the SDK) on MSDN. If you’re a MSDN subscriber, you can go grab the bits right away.

There are also several other related announcements around RTM dates, pricing, and SKU’s:

Soma’s Announcement
Ars Technica : Visual Studio 2010 simplified to four SKUs, Beta 2 arrives

One of the things you may notice is missing from the Visual Studio 2010 Beta 1 SDK (compared to 2008) are the user interface guidelines.

You can now find the Visual Studio 2010 User Interface Guidelines at the following location: http://code.msdn.microsoft.com/VS2010UX

Disclaimer : This is about working with the Visual Studio 2010 Beta 1 SDK. Information is likely to be inaccurate for future or previous Visual Studio SDK releases.

When you install the Visual Studio 2010 SDK Beta 1, you’ll notice a new node in the new project dialog under Visual C#\Extensibility and Visual Basic\Extensibility:

The editor extension templates are what you would expect. They give you a project that builds a MEF component (which the VS core editor consumes) to provide various adornments, etc…

If you would want to build a VSPackage, the trusty package wizard still lives where it always has under Other Project Types\Extensibility:

So then, what is that “VSIX Project” template for (in the first screenshot)?

The VSIX Project is meant to be a very simple project template that is used for building a raw VSIX “bundle” (i.e. the zip container). That’s why there is essentially no code in the project at all. This could be useful in situations where you were only just packaging up something like a project or item template, and weren’t really building any code. Pedro mentions this in his blog post series on how to build a VSIX-based project/item template for distribution on the VS Gallery.

Preventing the DLL/PDB from being added to the VSIX

One thing you may notice is that the DLL and PDB built from the project (that you don’t need if you’re just packaging up some templates) gets included in the VSIX file. To suppress this, you could either use the VSIX Explorer tool to edit the file post-build (tedious since you need to do this for each build)…or simply add the following XML snippet to your CSProj/VBProj to prevent the DLL or PDB from being included in the VSIX file at all:

<PropertyGroup>
  <CopyBuildOutputToOutputDirectory>false</CopyBuildOutputToOutputDirectory>
  <CopyOutputSymbolsToOutputDirectory>false</CopyOutputSymbolsToOutputDirectory>
</PropertyGroup>

***Disclaimer: This information is about Visual Studio 2010 Beta 1 only. The following may not be accurate for future releases.***

One of the new features we introduced with the Visual Studio 2008 Isolated Shell was the concept of a pkgdef file. Pkgdef is essentially a REG file with tokenization. For example, you could put $RootFolder$ in your pkgdef file to refer to the root directory of your isolated shell application. At runtime, these files are consumed by the VS Isolated Shell runtime and merged into the registry (with the tokens replaced by literal values). The registry merely acts as a cache of the information in your pkgdef files.

In Visual Studio 2010, the pkgdef model has been integrated into Visual Studio itself. As such, the manner in which your packages are built and (locally) deployed when developing with the Visual Studio 2010 SDK Beta 1 is significantly different (although the “F5 experience” should be the same).

Visual Studio Startup / Pkgdef Merge

On the very first launch of Visual Studio, the first thing that needs to happen is merging the pkgdef files into the registry. You can think of the destination registry key where these go as merely a cache used for performance. The fact that it’s a registry key is somewhat of an implementation detail. Here’s a graphical view of what happens:

Note in the above diagram that the cache location is under KHEY_CURRENT_USER, and that the key name is 10.0_Config. If you view this key in regedit, you’ll notice a sibling key named simply “10.0”. This 10.0 key holds your per-user settings (things like your personal preferences for fonts, window position, and other options).

In comparison to Visual Studio 2008 and running with the /ranu switch, these 10.0 and 10.0_Config keys map to the UserSettings and Configuration keys under HKCU\Software\Microsoft\VisualStudio\9.0 respectively.

It is a completely safe operation to delete the HKCU\…\10.0_Config key since Visual Studio will re-create it on the next launch.

“Experimental Instance” Startup / Pkgdef Merge

A very similar process happens when you run “devenv /rootsuffix Exp”. Instead of merging the pkgdef information to “10.0_Config”, everything is merged to “10.0Exp_Config”:

What are the “Pkgdef Files on Disk” locations?

There is a file called “devenv.pkgdef” in your VS installation folder (under Common7\IDE) that defines where pkgdef files are picked up from. First, pkgdef files are picked up from a few sub-folders under Common7\IDE. Secondly, you’ll notice that we scan a folder called “$AppDataLocalFolder$\Extensions”. On my user account this maps to:

C:\Users\aaronm\AppData\Local\Microsoft\VisualStudio\10.0\Extensions

When running with “/rootsuffix Exp” this would be:

C:\Users\aaronm\AppData\Local\Microsoft\VisualStudio\10.0Exp\Extensions

In order for a pkgdef flie in the per-user location to be picked up by VS, it must also be declared as owned by a VSIX-based extension and enabled in HKCU\Microsoft\VisualStudio\10.0\ExtensionManager\EnabledExtensions. When you build a VSPackage or MEF component from one of the project templates in the Visual Studio 2010 Beta 1 SDK, this is all happening for you during the build.

The Visual Studio 2010 SDK Beta 1 is now available for download. Be sure to check out the latest supplemental readme as you’re likely to encounter some of these issues in using the SDK.

Somasegar (VP in charge of DevDiv) has just blogged that Visual Studio 2010 Beta 1 has been released to the web. It will be available on MSDN in the next few hours, and available as a public download on Wednesday. (We will be releasing a matching Visual Studio SDK soon also.)

Beta 1 is the first time that you’ll be able to get a glimpse at the new Visual Studio Extension Manager as well as the other new features coming (WPF based Shell/Editor, MEF-based editor extensibility, Architecture Explorer, etc…).

Yesterday, the folks responsible for building the core text editor in Visual Studio announced that Consolas (10pt) will now be the default font in Visual Studio 2010.

So long Lucida Console!

I’ve moved the syndication feed for this blog to use FeedBurner. If you read this blog via an RSS/Atom reader, please re-subscribe or update the feed settings to use the following URL:

http://feeds2.feedburner.com/AaronMarten

Jason Zander, the General Manager for Visual Studio, has just announced some more details (with screenshots) on the new look and feel for Visual Studio 2010 (which relies heavily on WPF).

In the same post, he also includes a screenshot of the new Visual Studio Extension Manager (mentioned previously):

You’ll be able to find more details about the Extension Manager here as we get closer to shipping VS 2010 Beta 1 (no dates announced yet). Stay tuned!

Don Syme has just announced that F# will ship in the box with Visual Studio 2010.

One of the new features we plan on shipping for VS 2010 that I've been heads down on for the past few months is the "Extension Manager". I'll be posting more details about it here over the next several months.

For the meantime, you can hear more about it (and see some very early mockups) in Dr. Tim Wagner's PDC talk. The part about the Extension Manager starts around 50:20. The earlier parts of the talk discuss some of the other new features that we're working on, including the new MEF-based editor extensibility model, the VS Gallery, and a general introduction to VS extensibility.

Recently, a question was asked on the VSX Forum about bad behavior from a language service after the user issues a “split window” or “new window” command. (Fonts are wrong, scroll bars don’t work and are corrupt, etc…) The problem is even present in the RegExLanguageService sample in the Visual Studio 2008 SDK (which is just about the simplest language service one could imagine).

After debugging, it turns out that this is a bug in the sample and not in Visual Studio.

Fortunately, the fix (which you must make in your VS Package and/or installer if you see this behavior) is quite simple. We had failed to add a ProvideLanguageService attribute to the package owning the service (which writes the registry keys at <VSRoot>\Languages\Language Services\<My Language Name>), ultimately causing the strange painting behavior at runtime. Please see Doug’s post in the thread linked above for more details.

The Boo programming language now has a Codeplex project called BooLangStudio which adds Boo intellisense, project templates, etc… to Visual Studio. Cool!

Earlier this week, we released the Visual Studio 2008 SDK 1.1. This is the SDK which is compatible with Visual Studio 2008 SP1.

The blog post linked above has more details on new features and fixes in this release.