Aaron Marten

“Invalid License Data” after VS 11 Beta to VS 2012 RC Upgrade

Aaron Marten — Sat, 02 Jun 2012 14:54:19 GMT

We’ve been seeing reports of some users hitting an “Invalid License Data” error on VS startup after upgrading from VS 11 Beta to VS 2012 RC. This could be due to upgrading from a “higher” Beta SKU (e.g. Ultimate) to a “lower” RC SKU (e.g. Professional).

Fortunately, the fix is simple. Go to the Windows Programs and Features control panel and uninstall the Visual Studio 11 Beta.

Visual Studio @ UserVoice

Aaron Marten — Wed, 20 Jul 2011 16:53:36 GMT

We now have an official site for Visual Studio on UserVoice! Please use this as a way to send suggestions and feature requests to the Visual Studio team. For specific bugs and errors, please continue to use Microsoft Connect.

http://visualstudio.uservoice.com

Visual Studio Extensions and Build Servers

Aaron Marten — Tue, 10 May 2011 18:35:00 GMT

From time to time, we see questions around building a project created with the Visual Studio 2010 SDK on a build server (e.g. Team Foundation Build, TeamCity, CC.NET, etc…). The primary misconception that folks have is that you must install Visual Studio 2010 + SDK on the build server.

In this post, I’ll walk through the process of getting a C#/VB VSPackage project up and running on Team Foundation Build, without requiring an install of Visual Studio on the build agent machine. The same steps apply for editor extensions or other extensibility project types.

Once you’ve configured the build server and are ready to try out a build, you’ll probably see something like the following error in your build log:

Step #1: Put Visual Studio SDK targets/tasks in source control

Since neither Visual Studio nor the Visual Studio SDK are installed on my build machine, the build complains about the missing Microsoft.VsSDK.targets file. This is simple enough to fix by doing the following:

Create a folder at the root of your solution directory called “vssdk_tools”. We’ll be adding all the necessary targets, tasks, etc… to this folder and adding it to source control.
Copy the contents of %ProgramFiles%\MSBuild\Microsoft\VisualStudio\v10.0\VSSDK into this directory.
Add the contents of your vssdk_tools directory to source control.
- If you’re using TFS Source Control, you can do this via the “tf add” command or through the Source Control Explorer tool window in Visual Studio 2010.
Edit your project file to point to this new targets file. Change the line:
<Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v10.0\VSSDK\Microsoft.VsSDK.targets" />
to
<Import Project="..\vssdk_tools\Microsoft.VsSDK.targets" />

Let’s try checking in again and seeing where we are now:

Step #2: Put COMReference binaries in source control

The reason that MSBuild is trying to run AxImp.exe is because we have a collection of COMReference elements in our VSPackage project. Instead of registering these assemblies as COM components on the build server, let’s copy these binaries to our local project and add them as normal assembly references:

Remove the following COMReferences from your project:
- EnvDTE
- EnvDTE80
- EnvDTE90
- EnvDTE100
- Microsoft.VisualStudio.CommandBars
- stdole
Create a “binaries” folder in our VSPackage project
“Add existing item…” on this binaries folder for the following assemblies:
- %ProgramFiles%\Common Files\Microsoft Shared\MSEnv\PublicAssemblies\EnvDTE.dll
- %ProgramFiles%\Common Files\Microsoft Shared\MSEnv\PublicAssemblies\EnvDTE80.dll
- %ProgramFiles%\Common Files\Microsoft Shared\MSEnv\PublicAssemblies\EnvDTE90.dll
- %ProgramFiles%\Common Files\Microsoft Shared\MSEnv\PublicAssemblies\EnvDTE100.dll
- %ProgramFiles%\Common Files\Microsoft Shared\MSEnv\PublicAssemblies\Microsoft.VisualStudio.CommandBars.dll
- %ProgramFiles%\Common Files\Microsoft Shared\MSEnv\PublicAssemblies\stdole.dll
Select all the binary files and set the “Build Action” property to “None”.
Re-add assembly references to the binaries you just added.
Important: Select all the references and set the “Embed Interop Types” property to false. (You can select and change them all in one operation.)

Let’s check in and try another build on the server

Step #3: Manually set the VsSDKInstall locations

Let’s take a look at the actual line where we’re hitting the error in Microsoft.VsSDK.Common.targets:

<Target Name="FindSDKInstallation" Condition="'$(VsSDKInstall)'==''">
<FindVsSDKInstallation SDKVersion="$(VsSDKVersion)">
…

The reason this task needs to run is because the VsSDKInstall property (and friends) hasn’t been set yet. Let’s use the “vssdk_tools” folder we had set up earlier. Edit your project file again, and add the following properties to the first <ProjectGroup> element:

<VsSDKInstall>..\vssdk_tools</VsSDKInstall>
<VsSDKIncludes>$(VsSDKInstall)\inc</VsSDKIncludes>
<VsSDKToolsPath>$(VsSDKInstall)\bin</VsSDKToolsPath>

Clearly, this won’t work until we actually have the corresponding files from the Visual Studio SDK also checked in to those directories. Let’s do that now:

Copy the contents of %ProgramFiles%\Microsoft Visual Studio 2010 SDK SP1\VisualStudioIntegration\Common\Inc to vssdk_tools\inc
Copy the contents of %ProgramFiles%\Microsoft Visual Studio 2010 SDK SP1\VisualStudioIntegration\Tools\Bin to vssdk_tools\bin
Add all these new files to source control

Let’s checkin again and see where we are now:

Step #4: Set VsSDKToolsPath as an Environment Variable

Hmmm…this one is a bit tricky. It turns out that some of the VSSDK build tasks rely on not only the $(VsSDKToolsPath) MSBuild property, but they also rely on this being set as an environment variable. We can do that fairly easily with an inline build task which we can add to our project file:

<UsingTask TaskName="SetVsSDKEnvironmentVariables" TaskFactory="CodeTaskFactory" AssemblyFile="$(MSBuildToolsPath)\Microsoft.Build.Tasks.v4.0.dll">
<ParameterGroup>
    <ProjectDirectory Required="true" />
</ParameterGroup>
<Task>
    <Code Type="Fragment" Language="cs">
      System.Environment.SetEnvironmentVariable("VsSDKToolsPath", System.IO.Path.GetFullPath(ProjectDirectory + @"\..\vssdk_tools\bin"));
    </Code>
</Task>
</UsingTask>
<Target Name="SetVsSDKEnvironmentVariables" BeforeTargets="VSCTCompile">
<SetVsSDKEnvironmentVariables ProjectDirectory="$(MSBuildProjectDirectory)" />
</Target>

Let’s cross our fingers and try again:

Step #5: Use 32-bit MSBuild.exe

By default, TFS will use the x64 version of MSBuild.exe (assuming you’re on a 64-bit server). Since the VSCT assembly is 32-bit only, it will fail to load in a 64-bit process. To use 32-bit MSBuild.exe on the server (if you’re using Team Foundation Build), simply edit the build definition and change Process => Advanced => MSBuild Platform to “X86” instead of “Auto”.

One more try:

Step #6: Add other VSSDK Assemblies to source control

In step 3, we only added the COMReferences to source control. Now, let’s do a similar procedure with the other assemblies:

Remove the following assembly references from your project:
- Microsoft.VisualStudio.OLE.Interop
- Microsoft.VisualStudio.Shell.10.0
- Microsoft.VisualStudio.Shell.Immutable.10.0
- Microsoft.VisualStudio.Shell.Interop
- Microsoft.VisualStudio.Shell.Interop.10.0
- Microsoft.VisualStudio.Shell.Interop.8.0
- Microsoft.VisualStudio.Shell.Interop.9.0
- Microsoft.VisualStudio.TextManager.Interop
“Add existing item…” on the binaries folder for the following assemblies:
- %ProgramFiles%\Microsoft Visual Studio 2010 SDK SP1\VisualStudioIntegration\Common\Assemblies\v2.0\Microsoft.VisualStudio.OLE.Interop.dll
- %ProgramFiles%\Microsoft Visual Studio 2010 SDK SP1\VisualStudioIntegration\Common\Assemblies\v2.0\Microsoft.VisualStudio.Shell.Interop.dll
- %ProgramFiles%\Microsoft Visual Studio 2010 SDK SP1\VisualStudioIntegration\Common\Assemblies\v2.0\Microsoft.VisualStudio.Shell.Interop.8.0.dll
- %ProgramFiles%\Microsoft Visual Studio 2010 SDK SP1\VisualStudioIntegration\Common\Assemblies\v2.0\Microsoft.VisualStudio.Shell.Interop.9.0.dll
- %ProgramFiles%\Microsoft Visual Studio 2010 SDK SP1\VisualStudioIntegration\Common\Assemblies\v2.0\Microsoft.VisualStudio.Shell.Interop.10.0.dll
- %ProgramFiles%\Microsoft Visual Studio 2010 SDK SP1\VisualStudioIntegration\Common\Assemblies\v2.0\Microsoft.VisualStudio.TextManager.Interop.dll
- %ProgramFiles%\Microsoft Visual Studio 2010 SDK SP1\VisualStudioIntegration\Common\Assemblies\v4.0\Microsoft.VisualStudio.Shell.10.0.dll
- %ProgramFiles%\Microsoft Visual Studio 2010 SDK SP1\VisualStudioIntegration\Common\Assemblies\v4.0\Microsoft.VisualStudio.Shell.Immutable.10.0.dll
Select all the binary files and set the “Build Action” property to “None”.
Re-add assembly references to the binaries you just added.

One more time…

Step #7: Add Microsoft.VisualStudio.Shell.Immutable.10.0.dll to the tools directory

CreatePkgDef.exe is the tool used to create a pkgdef file for your VSPackage. The tool itself relies on types defined in the Microsoft.VisualStudio.Shell.Immutable.10.0 assembly. On a machine with Visual Studio 2010 installed, there isn’t a problem loading it since the assembly is installed to the GAC. However, on our build server, the assembly is not in the GAC since Visual Studio 2010 isn’t installed.

In order to allow CreatePkgDef.exe to find the assembly, we can simply add a copy of this binary in our vssdk_tools\bin directory. Do the following:

Copy Microsoft.VisualStudio.Shell.Immutable.10.0.dll from our project binaries folder to vssdk_tools\bin.
Add this new file to source control and checkin

Step #8: Add the VSIXManifestSchema.xsd to allow VsixManifest validation on the build server

This task fails because the build task can’t locate the XML schema file for VSIXManifest to do schema validation. We could just switch this task off, but since it’s a good idea to run this validation when we build, let’s do what’s necessary to enable validation. There is an MSBuild property we can set to override this location on our build server. Simply add the following property to the first <PropertyGroup>:

<VsixSchemaPath>$(VsSDKInstall)\schemas\VSIXManifestSchema.xsd</VsixSchemaPath>

Of course, we also need to add the schema file to this directory:

Copy the VSIXManifestSchema.xsd file from “%ProgramFiles%\Microsoft Visual Studio 10.0\Xml\Schemas” to vssdk_tools\schemas.
Add VSIXManifestSchema.xsd to source control

Let’s try again and see where we are:

Step #9: Disable deployment to the Experimental Instance

To make ‘F5’ debugging work without any work by the user, by default, there are some additional targets that run in Microsoft.VsSDK.Common.targets. These targets ‘deploy’ your extension’s files to the Experimental instance for debugging. Since this scenario doesn’t make sense for our build server, we should disable it.

The Visual Studio SDK includes a project property page for configuring this property:

Note that you will probably want a separate build configuration for your build server (to set this property to false) so that developers can still easily debug their package on a client machine.

If you prefer to configure this directly in your project file instead of using the UI, use the following property:

<DeployExtension>False</DeployExtension>

Let’s see how this affects our build:

Success!!

Hooray! If I check the build output directory, we now see that we have a VSIX file that was built on the server:

PerfWatson – Automatically report responsiveness issues in Visual Studio 2010

Aaron Marten — Fri, 29 Apr 2011 22:41:00 GMT

We’ve just released a new extension on the Visual Studio Gallery called PerfWatson. Have you ever seen this dreaded error message?

Microsoft Visual studio is waiting for an internal operation to complete. If you regularly encounter this delay during normal usage, please report this problem to Microsoft.

Well, now you actually can report these problems to Microsoft…automatically. Here’s a description of the extension from the Visual Studio Gallery page:

“We’re constantly working to improve the performance of Visual Studio and take feedback about it very seriously. Our investigations into these issues have found that there are a variety of scenarios where a long running task can cause the UI thread to hang or become unresponsive. Visual Studio PerfWatson is a low overhead telemetry system that helps us capture these instances of UI unresponsiveness and report them back to Microsoft automatically and anonymously. We then use this data to drive performance improvements that make Visual Studio faster.

Here’s how it works: when the tool detects that the Visual Studio UI has become unresponsive, it records information about the length of the delay and the root cause, and submits a report to Microsoft. The Visual Studio team can then aggregate the data from these reports to prioritize the issues that are causing the largest or most frequent delays across our user base. By installing the PerfWatson extension, you are helping Microsoft identify and fix the performance issues that you most frequently encounter on your PC.”

I’d strongly encourage you to install PerfWatson if you’re frustrated with seemingly random UI hangs in Visual Studio. This extension won’t fix the issues, but it will help us see where the real-world responsiveness issues are to help improve future releases.

Custom Extension Types with VSIX

Aaron Marten — Fri, 16 Apr 2010 21:28:23 GMT

I just posted an article entitled “Custom Extension Types with VSIX” on the Visual Studio Blog.

Check it out if you’re interested in distributing custom content (not necessarily code) as a Visual Studio extension.

Visual Studio 2010 Released

Aaron Marten — Tue, 13 Apr 2010 04:30:31 GMT

By now you’ve probably heard that we launched Visual Studio 2010 and .NET Framework 4.0 today!

Download Visual Studio 2010 (MSDN subscribers only)

Download Visual Studio 2010 SDK

The Visual Studio Industry Partner (VSIP) team has also posted a slew of videos showing off some of the great add-on products that bring additional functionality to the new IDE.

Enjoy, and do please let us know what you think via email, forums, blogs, Twitter, and Microsoft Connect!

Including Existing Templates in a VSIX Container

Aaron Marten — Sat, 13 Mar 2010 00:24:44 GMT

In the Visual Studio 2008 SDK, we have several samples (most notably, IronPythonIntegration) set up to use the ZipProject, ZipItem, and VSTemplate build actions to create template zip files.

Last week, I published a post on the Visual Studio Blog discussing how you could build templates from source files and package them up in a VSIX container using the new templates in the Visual Studio 2010 SDK.

We’ve been hearing questions about how to take an existing project (updated from Visual Studio 2008, still using ZipProject/ZipItem) and include the built zip files in the VSIX container.

Unfortunately, this doesn’t happen automatically for you. The reason is that the zip files are not specified as input files for building the VSIX container in the VSSDK build targets.

Fortunately, since MSBuild is a highly extensible system, we can make up for this with a little bit of project customization. Simply add the following to your C#/VB project file to get your existing templates included in the VSIX container:

<PropertyGroup>
    <GetVsixSourceItemsDependsOn>$(GetVsixSourceItemsDependsOn);GetVsixTemplateItems</GetVsixSourceItemsDependsOn>
</PropertyGroup>
<Target Name="GetVsixTemplateItems" DependsOnTargets="ZipProjects;ZipItems">
    <ItemGroup>
        <VSIXSourceItem Include="@(IntermediateZipItem)">
            <VSIXSubPath>ItemTemplates\%(IntermediateZipItem.Language)\%(IntermediateZipItem.OutputSubPath)\%(IntermediateZipItem.Culture)</VSIXSubPath>
        </VSIXSourceItem>
        <VSIXSourceItem Include="@(IntermediateZipProject)">
            <VSIXSubPath>ProjectTemplates\%(IntermediateZipProject.Language)\%(IntermediateZipProject.OutputSubPath)\%(IntermediateZipProject.Culture)</VSIXSubPath>
        </VSIXSourceItem>
    </ItemGroup>
</Target>

You will also need to add the following lines (as appropriate) to your source.extension.vsixmanifest:

<Content>
    <ProjectTemplate>ProjectTemplates</ProjectTemplate>
    <ItemTemplate>ItemTemplates</ItemTemplate>
</Content>

These lines each declare a root folder in your VSIX file that VS should examine for template files. Project template zip files will be placed in the ProjectTemplates folder inside the VSIX file. Item template zip files will be placed in (you guessed it)…the ItemTemplates folder inside the VSIX file.

Targeting VS 2008 with the Visual Studio 2010 SDK

Aaron Marten — Tue, 08 Dec 2009 00:44:50 GMT

Recently, a customer asked us if it was possible to develop and debug a VB/C# extension with Visual Studio 2010 (and the 2010 SDK), but still have a binary that also works with VS 2008. This is indeed possible, but it requires some hacking of your project file to get it set up.

One nice thing about this solution is that you can easily switch between targeting 2008 and 2010 by simply changing the startup project between the package project and the VSIX project.

Setup machine with VS 2008 SP1 + VS2008 SDK 1.1 + VS2010 Beta 2 + VS2010 Beta 2 SDK

In VS 2008 : create a VB or C# VSPackage
- (optionally) Build/F5 to verify that it builds/loads as expected in 2008 Experimental Hive
- Close VS 2008 Instances
Launch VS 2010, open the solution, and proceed with project upgrade wizard
Unload the VSPackage project, edit the project file, and add the following target after the Imports statements at the bottom:

<Target Name="PkgdefProjectOutputGroup" Outputs="@(PkgdefOutputGroupOutput)">
<RegPkg ItemToRegister="$(TargetPath)"
    ProductVersion="$(TargetVSVersion)"
    RegistrationRoot="$(__InternalTargetRoot)"
    SDKVersion="$(VsSDKVersion)"
    UseCodebase="true"
    OutputFile="$(IntermediateOutputPath)$(TargetName)_.pkgdef"
    Unregister="false"
    UseVS2005MPF="$(__InternalUseMPF80)" />
<ItemGroup>
    <_PkgdefOutputGroupOutput Include="$(IntermediateOutputPath)$(TargetName)_.pkgdef" />
</ItemGroup>
<ItemGroup>
    <PkgdefOutputGroupOutput Include="@(_PkgdefOutputGroupOutput->'%(FullPath)')" />
</ItemGroup>
</Target>
Reload the VSPackage project
Add a VSIX Project to the solution (From Visual C#\Extensibility or Visual Basic\Extensibility in the New Project Dialog)
- Note: You do not have to distribute your package in a VSIX container. This is simply a requirement for registering and debugging in the VS 2010 Experimental Instance.
Add a Project Reference from the VSIX Project to the VSPackage project
Unload the VSIX project, edit the project file, and add the following inside the <ProjectReference> node:

<IncludeOutputGroupsInVSIX>
BuiltProjectOutputGroup;
PkgdefProjectOutputGroup
</IncludeOutputGroupsInVSIX>
<IncludeOutputGroupsInVSIXLocalOnly>
DebugSymbolsProjectOutputGroup
</IncludeOutputGroupsInVSIXLocalOnly>
Reload the VSIX Project
Right-click the VSIX Project node and “Set as Startup Project” (if you wish to run/debug the package under VS2010)
F5 to debug the package running in the VS2010 Experimental Instance with VS2010

All Your RegKeys Are Belong To Us

Aaron Marten — Fri, 06 Nov 2009 17:39:00 GMT

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:

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

Visual Studio 2010 Beta 2 (+SDK) on MSDN

Aaron Marten — Mon, 19 Oct 2009 16:16:45 GMT

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

Visual Studio 2010 User Interface Guidelines

Aaron Marten — Thu, 25 Jun 2009 07:01:54 GMT

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

What is the “VSIX Project” template?

Aaron Marten — Tue, 09 Jun 2009 16:11:19 GMT

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>

Please note that this workaround is only meant for the Beta 1 SDK. This may change in future SDK releases.

Pkgdef and the Experimental Instance in VS 2010

Aaron Marten — Fri, 05 Jun 2009 15:42:00 GMT

***Disclaimer: This information is about Visual Studio 2010 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 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 HKEY_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 SDK, this is all happening for you during the build.

Visual Studio 2010 SDK Beta 1

Aaron Marten — Thu, 21 May 2009 20:04:55 GMT

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.

Visual Studio 2010 Beta 1 Shipped

Aaron Marten — Mon, 18 May 2009 19:17:06 GMT

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…).

Consolas : Default Editor Font in VS 2010

Aaron Marten — Thu, 12 Mar 2009 17:34:55 GMT

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!

New Syndication URL

Aaron Marten — Wed, 25 Feb 2009 00:07:00 GMT

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

Update on Extension Manager and Visual Studio 2010

Aaron Marten — Tue, 24 Feb 2009 23:38:53 GMT

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!

F# Included in Visual Studio 2010

Aaron Marten — Thu, 11 Dec 2008 21:12:05 GMT

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

Extension Manager

Aaron Marten — Tue, 04 Nov 2008 16:40:40 GMT

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.

Split Window / New Window – Bad Painting Behavior in your Language Service

Aaron Marten — Wed, 10 Sep 2008 20:32:10 GMT

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.

BooLangStudio

Aaron Marten — Sat, 23 Aug 2008 17:47:44 GMT

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

Visual Studio 2008 SDK 1.1 Released

Aaron Marten — Sat, 23 Aug 2008 17:24:05 GMT

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.

Visual Studio 2008 SP1 Shipped

Aaron Marten — Mon, 11 Aug 2008 22:56:16 GMT

We shipped Visual Studio 2008 SP1 & .NET 3.5 SP1 to the web this morning!

Soma has more details.

We are currently putting the finishing touches on the Visual Studio 2008 SDK 1.1 (which targets SP1) and plan on releasing it soon.

VSX Developer Conference : Sep 15-16, 2008 - Redmond, WA

Aaron Marten — Mon, 04 Aug 2008 21:30:04 GMT

In just a few weeks, we’ll be hosting a conference here in Redmond at the Microsoft Conference Center devoted to covering Visual Studio Extensibility.

I’ll be presenting a session entitled “Deploying VSX Projects”.

One of the best parts about the conference is that the fee is only $100. That fee also covers an included copy of “Professional Visual Studio Extensibility” by Keyvan Nayyeri (which sells for $49.99).