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.
Example
The following example is a managed representation of a tool window icon.
<data name="1001"
type="System.Resources.ResXFileRef,System.Windows.Forms">
<value>
MyToolWinIcon.bmp;
System.Drawing.Bitmap,
System.Drawing,
Version=1.0.0.0,
Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a
</value>
</data>
The following example demonstrates how to embed the CTO byte array, which must be named CTMENU.
<data name="CTMENU"
type="System.Resources.ResXFileRef,System.Windows.Forms">
<value>
MyPackage.cto;
System.Byte[],
mscorlib,
Version=1.0.0.0,
Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a
</value>
</data>
Implementation Notes
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.
