Was this page helpful?
Your feedback about this content is important. Let us know what you think.
Additional feedback?
1500 characters remaining
Export (0) Print
Expand All
Important This document may not represent best practices for current development, links to downloads and other resources may no longer be valid. Current recommended version can be found here.

Resources in Managed VSPackages

The Visual Studio SDK is designed to end the era of native satellite user interface (UI) dlls by making managed resources available for VSPackage authoring. You can now embed localized resources in native satellite UI dlls, managed satellite dlls, or in a managed VSPackage itself.

Some resources cannot be embedded in VSPackages. The following managed types can be embedded:

  • Strings

  • Package load keys (which are also strings)

  • Tool window icons

  • Compiled Command Table Output (CTO) files

  • CTO bitmaps

  • Command-line Help

  • Help About data

Resources within a managed package are selected by resource ID. An exception is the CTO file, which must be named CTMENU. The CTO file must appear in the resource table as a byte[]. All other resource items are identified by type.

You can use the PackageRegistrationAttribute attribute to indicate to Visual Studio that managed resources are available:

[PackageRegistration(UseManagedResourcesOnly = true)]
public class MyPackage : Package

Setting PackageRegistrationAttribute in this manner indicates that Visual Studio should ignore unmanaged satellite dlls when searching for resources, for example, by using LoadPackageString. If Visual Studio encounters two or more resources with the same resource ID, it uses the first resource it finds.

The following example is a managed representation of a tool window icon.

<data name="1001"

The following example demonstrates how to embed the CTO byte array, which must be named CTMENU.

<data name="CTMENU"

Visual Studio delays loading of VSPackages whenever possible. A consequence of embedding a CTO file in a VSPackage is that Visual Studio must load all such VSPackages in memory during setup, which is when it builds a merged command table. Resources can be extracted from a VSPackage by examining the metadata without running code in the VSPackage. The VSPackage is not initialized at this time, so the performance hit is minimal.

When Visual Studio requests a resource from a VSPackage after setup, that package is likely to be already loaded and initialized, so the performance loss is minimal.

Community Additions

© 2015 Microsoft