Developer Support Blog for Visual Studio Extensibility

Your VS Package may not load after porting it to VS 2012

2012-10-08T22:20:00Z

With VS 2010, the IDE recreates the user's 10.0_Config registry hive and remerges menu resources when it detects a change under HKLM\Software\Microsoft\VisualStudio\10.0. For VS 2012, the IDE team felt this had too much of a negative effect on startup performance, and the feature was removed.

Consequently, if you deploy your VS Package(s) with a custom setup/installer, your installer must run devenv.exe /setup to ensure the registry changes you add under HKLM\Software\Microsoft\VisualStudio\11.0, are propagated to the users 11.0_Config hive.

The only exception to this is when you deploy your package via VSIX. Packages installed by the VSIXInstaller, do not have this requirement.

Therefore, if you find your package does not load under VS 2012, and running devenv.exe /setup fixes the problem; you are in good company. I have seen a number of partners (internal and external) that have encountered this problem.

There is mention that this is a requirement in the documentation link below, but in the absence of a "What's New/Changed" topic for the VS SDK, that can be very easy to overlook.

Commands That Must Be Run After Installation

Sample Browser Extension for Visual Studio 2010/2012

2012-09-07T16:44:33Z

3500+ samples at your fingertips. The new Sample Browser Extension allows you to quickly search, download, and experiment with sample code covering just about anything you can think of. And if you can’t find what you’re looking for, you can submit a sample request. The latest version, which supports both VS 2010 and VS 2012, was uploaded yesterday, and has already been downloaded over 50,000 times.

Give it a try, and be sure to send feedback via the Visual Studio Gallery page.

Visual Studio 2010 Professional Upgrade Pre-Order

2010-03-11T16:21:00Z

Microsoft Visual Studio 2010 Professional will launch on April 12 but you can beat the rush and secure your copy today by pre-ordering at the affordable estimated retail price of $549, a saving of $250.

If you use a previous version of Visual Studio or any other development tool then you are eligible for this upgrade. Along with all the great new features in Visual Studio 2010 (see www.microsoft.com/visualstudio) Visual Studio 2010 Professional includes a 12-month MSDN Essentials subscription which gives you access to core Microsoft platforms: Windows 7 Ultimate, Windows Server 2008 R2 Enterprise, and Microsoft SQL Server 2008 R2 Datacenter.

So visit http://www.microsoft.com/visualstudio/en-us/pre-order-visual-studio-2010 to check out all the new features and sign up for this great offer.

How to register existing packages to run under VS 2010 Experimental Instance

2010-03-08T19:01:00Z

Aaron Marten’s blog “Pkgdef and the Experimental Instance in VS 2010” points out that when devenv.exe is invoked with the ‘/rootsuffix Exp’ switch, the VS Shell no longer uses the experimental registry hive. Instead, the shell merges the HKLM\Software\Microsoft\VisualStudio\10.0 registry settings and the .pkgdef files in the user’s …AppData\Local\Microsoft\VisualStudio\10.0Exp\Extensions folder.

If you have an existing package binary that’s built with an earlier version of VS, and want to have it load into the VS 2010 Experimental instance, you can create a VSIX Project in VS 2010, to ensure the components are properly registered to load in the Experimental instance.

Alternatively, you can copy these files manually. But using a VSIX Project makes this a relatively quick and easy process. Just follow the steps outlined below and you should have your existing package(s), up and running in VS 2010 in no time.

Step #1: Create a new VSIX Project from the “File.New Project” dialog. Note, the VSIX Project template is included under the Visual C#\Extensibility and Visual Basic\Extensibility trees.

Step #2: Right click on the project node in Solution Explorer, select ‘Add->Add Existing…’ and add your package assembly, and pkgdef files to the project. If you currently do not have a pkgdef file for your package, check out “How to create a pkgdef file for your Visual Studio Package”. If your package happens to be a native C++ package with a satellite resource DLL, you’ll want to add a codepage folder to the project add your satellite resource DLL as well. For example:

Step #3: Set the ‘Build Action’ property to “Content”, the ‘Copy to Output Directory’ property to “Copy Always”, and the ‘Include in VSIX’ property to “True”, on each of these files. For Example:

Step #4: Open the .vsixmanifest in the VSIX designer (if it isn’t open already), and fill in the some of the details. For example:

Note, use the “Add Content” button, and add the .pkgdef as a “VS Package, as illustrated below.

Step #5: Right click the project node in Solution Explorer, and select the “Properties…” command to display the project designer. Then select the “VSIX” tab and ensure the “Deploy VSIX content to experimental instance” is selected. For example:

Step #6: Build the project to register the package for execution in the experimental instance of VS 2010.

Finally, note that the Debug settings are already configured to launch DevEnv.exe with the /RootSuffix Exp switch. So you can readily launch and debug your package running in the experimental instance. If your package happens to be native C++ like mine, you’ll want to also set the “Enable unmanaged code debugging” checkbox on the Debug Tab.

How to create a pkgdef file for your Visual Studio Package

2010-03-08T18:39:19Z

The .pkgdef file was first introduced with VS 2008, to allow for easily registering packages targeting the VS 2008 isolated shell. Bill Wienberger details the rationale behind this change in the following blog entry: What’s A PkgDef? And Why?

There are a couple of ways .pkgdef files can be created. For a managed package, the .pkgdef file can be built using the RegPkg.exe utility with the /pkgdeffile switch. The RegPkg.exe utility will read and execute the various registration attributes in the package assembly to construct the pkgdef file. If the package project was initially created with the VS SDK 1.1 (or later) project wizard, build rules were automatically added to the project file that will automatically generate the .pkgdef during your build operation. For example, you may have noticed something similar to the following in the build output window after building your managed package:

C:\Program Files\Microsoft Visual Studio 2008 SDK\VisualStudioIntegration\Tools\bin\RegPkg.exe /root:Software\Microsoft\VisualStudio\9.0Exp "/pkgdeffile:obj\Debug\VS08ManagedPackage.pkgdef" "C:\Users\<user>\Documents\Visual Studio 2008\Projects\VS08ManagedPackage\VS08ManagedPackage\bin\Debug\VS08ManagedPackage.dll"

Or possibly if you’re using VS 2010:

GeneratePkgDef:
   Creating intermediate PkgDef file.
      C:\Program Files\Microsoft Visual Studio 2010 SDK\VisualStudioIntegration\Tools\bin\CreatePkgDef.exe /out="obj\Debug\My2010Package.latest.pkgdef" /codebase … "c:\users\<user>\documents\visual studio 2010\Projects\My2010Package\My2010Package\bin\Debug\My2010Package.dll"
   Copying file from "obj\Debug\My2010Package.latest.pkgdef" to "obj\Debug\My2010Package.pkgdef".
   CopyPkgDef:
      Copying file from "obj\Debug\My2010Package.pkgdef" to "bin\Debug\My2010Package.pkgdef".

Creating a .pkgdef for C++ based packages requires a bit more work, as the C++ project system (in VS 2008) was not based on MSBuild. If your native C++ package was originally created with VS 2008 SDK 1.1 (or later) project wizard, an initial .pkgdef file was automatically included with your project. This default .pkgdef will contain the settings/tokens based on the initial settings you specified in the project wizard. Additional entries, or changes to the existing .pkgdef must be done manually, as we cannot leverage the RegPkg.exe utility.

A list of the various replacement tokens that can be used in a .pkgdef file can currently be found in the following help topic: Isolated Shell Extension Points. The topic title is a little out of date, but the tokens listed are entirely valid for packages targeting either the isolated or integrated shells.

Tips for creating a pkgdef file (if you don’t already have one):

If your package is a managed package that targets VS 2005, use RegPkg.exe to create a .reg or .vrg file for guidance to find the registry keys and values you’ll need to include for your package.
If your package is a C++ based package, review your installer and note the various registry keys and values it creates/adds.
Create and build a test package using the VS 2008/2010 SDK. And use the generated pkgdef as a template.

Dissecting VS 2010 Package Registration

2010-03-01T22:35:04Z

While it’s still possible to register your packages, by manually or programmatically adding the requisite registry keys and values under the HKLM\Software\Microsoft\VisualStudio\10.0 registry hive, it’s no longer the recommended way to register your packages with the integrated (or isolated) shell.

VS2010 now uses pkgdef and vsixmanifest files to integrate custom packages into the shell. For managed packages, the pkgdef file is generated through the GeneratePkgDef target in Microsoft.VsSDK.targets, which runs the CreatePkgDef build task in Microsoft.VsSDK.Build.Tasks.dll. The CreatePkgDef build task will construct the pkgdef file, by reading/executing the various attributes (like PackageRegistration, ProvideMenuResource, etc) applied to the Package object. For native C++ packages, the .pkgdef file is initially created via the project wizard template, and must be edited manually as changes are made to the package.

The pkgdef file is basically just a tokenized .REG file, which the shell merges with the registry. Note, the use of the registry here is now considered an implementation detail, and may change with subsequent releases; hence the above mentioned recommendation not to use the registry directly, to register your packages. Aaron Marten’s blog ‘All Your RegKeys Are Belong To Us’ details some of the specifics.

The .vsixmanifest is typically used to describe the content of a VSIX package, but is also required to notify the shell about your package, and allows for listing the package under the new Extension Manager.

Unlike VS 2008 where packages are loaded directly from the projects build output directory, a VS 2010 package is loaded from a copy made in the users AppData\Local\Microsoft\VisualStudio\10.0<Exp>\Extensions subdirectory. With a managed package, these files are copied over via the DeployVsixExtensionFiles target defined in Microsoft.VsSDK.targets. From the proj file, you can define the DeployExtension property to turn this on or off. For native C++ projects, these same files are copied via the <Package>VSIX project, which is a C# flavored project type that uses the above mentioned targets and properties the C# and VB based package projects use.

In summary, if you want to manually add a package to run under the experimental shell environment (when launching devenv.exe with ‘/rootsuffix Exp’), you will need to do the following:

Copy your package assembly to a subdirectory under …<user>\AppData\Local\Microsoft\VisualStudio\10.0Exp\Extensions
Create and copy a pkgdef and vsixmanifest to the same directory
Launch devenv with ‘/rootsuffix Exp’ command line switch
Enable the package via the ‘Tools.Extension Manager’

Hotfix posted for VS 2010 RC1 Intellisense crash

2010-02-16T21:12:43Z

On systems where an application or device is actively using UIAutomation (Tablet, Multi-touch, etc), the IDE may crash if the user is typing while intellisense is being displayed or dismissed.

KB article describing this problem will be posted to http://support.microsoft.com/default.aspx?scid=kb;EN-US;980615 in the next few days.

A hotfix that addresses this problem can be downloaded from the following locations:

MSConnect: http://connect.microsoft.com/VisualStudio/Downloads/DownloadDetails.aspx?DownloadID=26662
Code Gallery: http://code.msdn.microsoft.com/KB980610

Problems building VS 2008 SDKSample

2009-11-12T22:30:00Z

Recently, one of our partners had a question pertaining to Help 2.0 integration, and I wanted to use the SDKSample to try a few things out with filters and help content. Apparently, it's been a while since I last played with that particular sample. Upon attempting to build it, I was confronted with the following build errors.

c10100b1: Failed to load file "..\..\..\Release\ExportTlbFromAssembly.exe". The system cannot find the path specified.
c10100b1: Failed to load file "..\..\..\Debug\ExportTlbFromAssembly.exe". The system cannot find the file specified.
LGHT0100 : File of type 'File' with name '..\Common\TypeLibs\Debug\DotNetAssembly.tlb' could not be found.
LGHT0100 : File of type 'File' with name '..\Common\TypeLibs\Release\DotNetAssembly.tlb' could not be found.

The VC++ 2008 project system now attempts to generate and embed a manifest into a project's target binary. Because the C++ projects in question don't produce a DLL or EXE binary, the subsequent invocation of mt.exe to generate the manifest fails the build. Consquently, no .TLB files are created for the ExportTlbFromAssembly or Setup projects. The easiest way to fix this, is to simply change the C++ project settings so that the project system thinks it's building a static library instead of a .EXE.

Just right click on each of the projects in solution explorer, and from the project's 'Property Pages' dialog, select the 'General' category under 'Configuration Properties', and then change the project's 'Configuration Type' property to 'Static Library (.lib)' instead of 'Application (.exe)'. Be sure to do this for each configuration (debug and release).

After setting the 'Configuration Type' property, you should be able to build the SDKSample project without error.

Replacing the Default Error Dialog in the Isolated Shell

2009-10-14T17:49:00Z

Background:

Recently one of our VSIP partners asked if it was possible to customize the default error dialog that the Isolated Shell displays when encountering an error. Let's suppose you have a package command handler that might throw an error with code that looks like the following:

private void OnTestErrorDialog(object sender, EventArgs e)

{

// throw an exception which will invoke the shells error dialog

ErrorHandler.ThrowOnFailure(DoSomeWork());

}

If 'DoSomeWork()' happens to return an error code like E_ACCESSDENIED for example, the shell will catch the thrown exception, and display a default error dialog that looks like the following:

Solution:

As it turns out, there is support for doing just this in the isolated shell. The problem is that we never documented or published the interface. This blog entry is an 'interim' solution, until we can get the documentation updated, and perhaps the interface and service definitions into an interop assembly.

In the Isolated Shell, if you have a package that proffers an IVsMessageBoxService, you can supply your own dialog to display error messages. The IVsMessageBoxService is defined as follows

[
   uuid(1DD71F22-C880-46be-A462-A0A5542BC939),
   version(1.0),
   pointer_default(unique)
]
interface IVsMessageBoxService: IUnknown
{
   //contains information used to display the message box.
   // (same as Win32API MessageBoxIndirect)
   HRESULT ShowMessageBox( [in] HWND hwndOwner,
      [in] HINSTANCE hInstance,
      [in] LPCOLESTR lpszText,
      [in] LPCOLESTR lpszCaption,
      [in] DWORD dwStyle,
      [in] LPCOLESTR lpszIcon,
      [in] DWORD_PTR dwContextHelpId,
      [in] DWORD_PTR lpfnMsgBoxCallback,
      [in] DWORD dwLanguageId,
      [out, retval] int* pidButton // id of the button return value
   );
}

cpp_quote("#define SID_SVsMessageBoxService IID_IVsMessageBoxService")

Because the above interface is currently not defined in any of our interop assemblies, you will need to define it yourself. For example:

[PreserveSig]
[ComImport]
[InterfaceType(ComInterfaceType.InterfaceIsIUnknown)]
[GuidAttribute("1DD71F22-C880-46be-A462-A0A5542BC939")]
public interface IVsMessageBoxService
{
    int ShowMessageBox(int hWndOwner,
    IntPtr hInstance,
    [MarshalAs(UnmanagedType.LPWStr)] string lpszText,
    [MarshalAs(UnmanagedType.LPWStr)] string lpszCaption,
    uint dwStyle,
    IntPtr lpszIcon,
    IntPtr dwContextHelpId,
    IntPtr pfnMessageBoxCallback,
    uint dwLangID,
    out int pidButton);
}

The next step is to implement the interface. For example:

class CustomMessageBoxService : IVsMessageBoxService

{

internal CustomMessageBoxService() {}

public int ShowMessageBox(int hWndOwner, IntPtr hInstance, string lpszText,

string lpszCaption, uint dwStyle, string szIcon, IntPtr dwContextHelpId,

IntPtr pfnMessageBoxCallback, uint dwLangID, out int pidButton)

{

IVsUIShell vsShell = (IVsUIShell)Package.GetGlobalService(typeof(SVsUIShell));

vsShell.EnableModeless(0);

// TODO: Display a customized dialog

System.Windows.Forms.MessageBox.Show(lpszText, "Oops");

vsShell.EnableModeless(-1);

// NOTE: Returning a 0 or -1 value for pidButton will result in the shell

// displaying its default error dialog

pidButton = 1;

return VSConstants.S_OK;

}

And finally, you need to proffer the service from a package running in your isolated shell. First, apply the following attribute to your Package object to ensure the service is registered with the shell.

[ProvideService(typeof(IVsMessageBoxService))]

Then add the following code to your Package.Initialize implementation (after calling base.Initialize()):

Caveat:

// Proffer a custom IVsMessageBoxService service to replace the shells default error dialog.

IServiceContainer svcContainer = (IServiceContainer)GetService(typeof(IServiceContainer));

svcContainer.AddService(typeof(IVsMessageBoxService), new CustomMessageBoxService(), true);

Note this feature is only available with the Isolated Shell. The Integrated Shell does not look for, or attempt to utilize the IVsMessageBoxService.

Macro that tests for proper implementation of AutomationProperties

2009-10-13T20:07:43Z

Background:

VSPackages can offer up a set of custom properties for their Tools.Options pages, by registering the pages under Visual Studio's AutomationProperties registry key, by using the ProvideOptionPageAttribute. This allows for programmatic access to the Tools.Options properties via DTE.Properties(<categoryName>, <pageName>).

The Example.OptionsPage sample in the Visual Studio SDK is missing the following attributes on its DialogPage derived objects.

[ComVisible(true)]
[ClassInterface(ClassInterfaceType.AutoDual)]

Unfortunately, this mistake has been copied by many package partners (including internal teams here at Microsoft). Consequently, we occasionally see customers running into problems attempting to programmatically access Tools.Options properties with the above mentioned DTE.Properties interface.

Solution:

To help address this oft made mistake, Paul Harrington and Doug Hodges recently wrote the following macro which tests all VSPackages registered under AutomationProperties, to see which objects are implemented properly, and which are not. If you have a VSPackage that adds pages to the Tools.Options dialog, you may also which to add this macro to your arsenal of testing tools.

Imports Microsoft.Win32

Sub TestAutomationProperties()
   Dim properties As EnvDTE.Properties
   Dim ow As OutputWindow = DTE.ToolWindows.OutputWindow
   Dim op As OutputWindowPane = ow.OutputWindowPanes.Add("Test Automation Properties")
   op.Activate()
   op.Clear()

   Dim regrootKey As RegistryKey = Registry.LocalMachine.OpenSubKey(DTE.RegistryRoot, False)
   Dim automationPropertiesKey As RegistryKey = regrootKey.OpenSubKey("AutomationProperties", False)
   Dim categoryName As String

   For Each categoryName In automationPropertiesKey.GetSubKeyNames
      Dim categoryKey As RegistryKey = automationPropertiesKey.OpenSubKey(categoryName, False)
      For Each pageName As String In categoryKey.GetSubKeyNames
         Dim pageKey As RegistryKey = categoryKey.OpenSubKey(pageName, False)
       Try
          properties = DTE.Properties(categoryName, pageName)
          If properties.Count = 0 Then
             op.OutputString("*** BUG: " + categoryName + "." + pageName + " must add [ClassInterface(ClassInterfaceType.AutoDual)] attribute" + vbCrLf)
          Else
             op.OutputString(categoryName + "." + pageName + " has " + properties.Count.ToString() + " properties" + vbCrLf)
          End If
         Catch ex As Exception
            op.OutputString("*** BUG: " + categoryName + "." + pageName + " must add [ComVisible(true)] attribute" + vbCrLf)
         End Try
      Next
   Next
End Sub

Caveats:

While adding the [ClassInterface(ClassInterfaceType.AutoDual)] attribute allows you to expose the DialogPage's properties through the DTE.Properties method, it exposes 'all' public properties, including those from your base classes, such as the "Site", "AutomationObject" and "Container" properties, and others hidden from the Import/Export Settings feature (through the use of the DesignerSerializationVisibilityAttribute).

However, the development team is currently working to address this in VS 2010, and alleviate the need to use the ClassInterface attribute to expose the dialogs properties.