Extensibility Tools

Mads Kristensen

An extension built for and by Visual Studio extension authors.

See the changelog for changes and roadmap.

Features

• VSCT files
  • Intellisense for custom GUIDs
  • Intellisense for custom IDs
  • Intellisense for built-in groups and menus
  • ImageMoniker Intellisense
  • Snippets
  • Auto-sync VSCT commands to C# class
• Editor margin
  • Shows document encoding
  • Shows content type of the ITextBuffer under caret
  • Shows active classifications under caret
  • Shows caret position and selection range
• Dialog for digitally signing VSIXs
• Pkgdef/pkgundef files
  • Syntax highlighting
  • Intellisense
  • Snippets
  • Brace matching
  • Validation
  • Formatting
• VsixManifest files
  • Auto-sync to Resx file
  • Automatically create .ico file based on icon file
• Support for VsixGallery.com
• Show Project information (for debug purposes)
• Export KnownMonikers to PNG file
• VS Theme color swatch window
• View Activity Log
• Enable VSIP Logging
• Item templates
  • Snippet file
  • Browser Link Provider class
  • Editor drop handler
• Create ImageManifest files

VSCT files

The Visual Studio Command Table leaves a lot to be desired in terms of both Intellisense and discoverability of even the most common use cases.

This extension improves on that.

Intellisense for custom GUIDs

Get Intellisense for symbols and groups through out the .vsct file whether you’re defining Groups , Menus , Buttons , KeyBindings or CommandPlacements .

Intellisense for custom IDs

Provides Intellisense for IDs based on the guid attribute on the same XML element.

Intellisense built-in groups and menus

All the built-in groups and menus are located under the guidSHLMainMenu GUID and Intellisense is now provided for all the corresponding IDs.

ImageMoniker Intellisense

Over 3500 images is available as ImageMonikers in the KnownMonikers collection in VS. You can now see all the images directly inside Intellisense.

Snippets

All main XML elements in the VSCT file has snippets associated with them and can be invoked by hitting the Tab key.

Auto-sync VSCT commands

Auto-generate the PackageGuids and PackageIds classes every time you save the VSCT file. This keeps your code in sync with the VSCT file at all times.

Feature contributed by phofman

Editor margin

The margin is located below the bottom scrollbar and comes in handy when writing extensions that extends the VS editor.

Document encoding

Shows the encoding of the current document and more details on hover.

Content type

Shows the content type of the ITextBuffer at the caret position. The over tooltip shows the name of the base content type.

Classification

Displays the name of the classification at the caret position in the document. The hover tooltip shows the inheritance hierarchy of the EditorFormatDefinition ‘s BaseDefinition attribute.

Selection

Displays the start and end position of the editor selection as well as the total length of the selection.

Pkgdef files

Syntax highlighting

Colorizes registry keys, strings, keywords, comments and more.

Intellisense

Intellisense is provided for tokens and GUIDs.

Snippets

By typing a question mark on an empty line, a list of snippets appear. Hit Tab on the snippet you want and it will be inserted.

Brace matching

Matches parentheses and square brackets.

Validation

Validates various common mistakes like unknown tokens and unclosed strings and braces.

Formatting

Format the entire document or just the selected lines.

VsixManifest files

You can enable auto-sync on any .vsixmanifest file. Simply right-click the file in Solution Explorer and select Auto-sync Resx and Icon Files.

Auto-sync resx files

This will generate a file called source.extension.resx that is designed to replace the VSPackage.resx file that is added by default by the VSIX project template.

Whenever you change the .vsixmanifest file, the .resx files is updated accordingly as well.

Auto-sync icon file

Icon files (.ico) are always hard to create and maintain, so this feature will auto-generate it for you automatically.

All there is required is that you’ve referenced an image file in the .vsixmanifest’s Icon property and a new .ico file is automtically generated with the right dimensions for VS extensions.

Auto-sync C# class file

A C# class file is also produced which contains a static class with various string constants such as Name, Description and Version of the VSIX.

Example:

Support for VsixGallery.com

VsixGallery.com is an open source gallery for Visual Studio extensions and is primarily used for hosting CI built extensions — a staging environment.

There are two things that make automatic integration with VsixGallery.com easy. Put your code on GitHub and automate the build process with AppVeyor.

It sounds like a lot of work, but it isn’t. Right-click the solution node in Solution Explorer and click both of the buttons shown below.

That will add some files to the solution folder that require almost no modifications by you. These files are AppVeyor.yml as well as common GitHub files such as CONTRIBUTION.md (tailored to VSIX development), CHANGELOG.md etc.

Read more about adding your extension to VsixGallery.

Show Project Information

A context-menu command is available on every project type that makes it very easy to see all the properties on said project.

This makes it easy to troubleshoot and debug project related issues.

Export KnownMonikers to file

You can now easily export any of the KnownMonikers from IVsImageService2 to a PNG file on disk in the size you need it in.

The button to invoke the Export Image Moniker dialog is located in the top level Tools menu.

Theme color swatch window

To see all the VS environment colors available used in the Light, Blue and Dark theme, you can use the Theme Swatches window.

Open it from View -> Other Windows -> Theme Swatches

The tool window lets you search for colors and provides an easy way to copy them into XAML or C#.

View Activity Log

Getting to the Visual Studio Activity Log can sometimes be a bit cumbersome when dealing with both the regular and the experimental instance.

A menu command under the top level View menu let’s you open the right Activity Log easily.

This will open the Activity Log in the Visual Studio web browser.

Enable VSIP Logging

VSIP Logging allows you to see GUIDs and command ids for menu commands. Just press Ctrl+Shift as you click a menu item or group with the mouse.

Item Templates

Several item templates are added to make it easier to create extension. These item templates all come with functionality that’s easy to modify to your needs.

Create Image Manifest files

Right-click any .png or .xaml files and invoke the Generate Image Manifest command from the context menu.

This will ask you where to put the .imagemanifest file and then generate it. If a .imagemanifest file already exist, the guid will remain the same but the sources and IDs will be updated.

Contribute

Check out the contribution guidelines if you want to contribute to this project.

Microsoft windows design extensibility

XAML designer extensibility migration

In Visual Studio 2019, the XAML designer supports two different architectures: the designer isolation architecture and the more recent surface isolation architecture. This architecture transition is required to support target runtimes that can’t be hosted in a .NET Framework process. Moving to the surface isolation architecture introduces breaking changes to the third-party extensibility model. This article outlines these changes, which are available in Visual Studio 2019 starting with version 16.3.

Designer isolation is used by the WPF designer for projects that target the .NET Framework and supports .design.dll extensions. User code, control libraries, and third-party extensions are loaded in an external process (XDesProc.exe) along with the actual designer code and designer panels.

Surface isolation is used by the UWP designer. It’s also used by the WPF designer for projects that target .NET Core. In surface isolation, only user code and control libraries are loaded in a separate process, while the designer and its panels are loaded in the Visual Studio process (DevEnv.exe). The runtime used for executing user code and control libraries is different from that used by the .NET Framework for the actual designer and third-party extensibility code.

Because of this architecture transition, third-party extensions are no longer loaded into the same process as the third-party control libraries. The extensions can no longer have direct dependencies on control libraries or directly access run-time objects. Extensions that were previously written for the designer isolation architecture using the Microsoft.Windows.Extensibility.dll API must be migrated to a new approach to work with the surface isolation architecture. In practice, an existing extension will need to be compiled against new extensibility API assemblies. Access to run-time control types via typeof or run-time instances must be replaced or removed because control libraries are now loaded in a different process.

New extensibility API assemblies

The new extensibility API assemblies are similar to the existing extensibility API assemblies but follow a different naming scheme in order to differentiate them. Similarly, the namespace names have changed to reflect the new assembly names.

Designer isolation API assembly	Surface isolation API assembly
Microsoft.Windows.Design.Extensibility.dll	Microsoft.VisualStudio.DesignTools.Extensibility.dll
Microsoft.Windows.Design.Interaction.dll	Microsoft.VisualStudio.DesignTools.Interaction.dll

New file extension and discovery

Instead of using the .design.dll file extension, new surface extensions will be discovered by using the .designtools.dll file extension. .design.dll and .designtools.dll extensions can exist in the same Design subfolder.

While third-party control libraries are compiled for the actual target runtime (.NET Core or UWP), the .designtools.dll extension should always be compiled as a .NET Framework assembly.

Decouple attribute tables from run-time types

The surface isolation extensibility model doesn’t allow for extensions to depend on actual control libraries, and therefore, extensions can’t reference types from the control library. For example, MyLibrary.designtools.dll should not have a dependency on MyLibrary.dll.

Such dependencies were most common when registering metadata for types via attribute tables. Extension code that references control library types directly via typeof or GetType is substituted in the new APIs by using string-based type names:

Starting in Visual Studio 2019 16.4, the AttachedPropertyBrowsableForTypeAttribute is supported when added directly to a runtime control library. In a .designtools.dll extension AttachedPropertyBrowsableForTypeIdentifierAttribute should be used instead to reference the type using a string name.

Feature providers and Model API

Feature providers are implemented in extension assemblies and loaded in the Visual Studio process. FeatureAttribute will continue to reference feature provider types directly using typeof.

Currently, the following feature providers are supported:

• DefaultInitializer
• AdornerProvider
• ContextMenuProvider
• ParentAdapter
• PlacementAdapter
• DesignModeValueProvider is supported with the limitation that TranslatePropertyValue will be called via InvalidateProperty or when modified in the designer. It will not be called when modified in run-time code.

Because feature providers are now loaded in a process different from the actual run-time code and control libraries, they are no longer able to access run-time objects directly. Instead, all such interactions must be converted to use the corresponding Model-based APIs. The Model API has been updated, and access to Type or Object is either no longer available or has been replaced with TypeIdentifier and TypeDefinition .

TypeIdentifier represents a string without an assembly name identifying a type. A TypeIdenfifier can be resolved to a TypeDefinition to query additional information about the type. TypeDefinition instances can’t be cached in extension code.

APIs removed from the surface isolation extensibility API set:

• ModelFactory.CreateItem(EditingContext context, object item)
• ViewItem.PlatformObject
• ModelProperty.DefaultValue
• AssemblyReferences.GetTypes(Type baseType)

APIs that use TypeIdentifier instead of Type:

• ModelFactory.CreateItem(EditingContext context, Type itemType, params object[] arguments)
• ModelFactory.CreateItem(EditingContext context, Type itemType, CreateOptions options, params object[] arguments)
• ModelFactory.CreateStaticMemberItem(EditingContext context, Type type, string memberName)
• ModelFactory.ResolveType(EditingContext context, Type) changed to MetadataFactory.ResolveType(EditingContext context, TypeIdentifier typeIdentifier)
• ModelService.ResolveType(TypeIdentifier typeIdentifier) changed to MetadataService.ResolveType(TypeIdentifier typeIdentifier)
• ViewItem.ItemType
• ModelEvent.EventType
• ModelEvent.IsEventOfType(Type type)
• ModeItem.IsItemOfType(Type type)
• ModelParent.CanParent(EditingContext context, ModelItem parent, Type childType)
• ModelParent.FindParent(EditingContext context, Type childType, ModelItem startingItem)
• ModelParent.FindParent(Type childType, GestureData gestureData)
• ModelProperty.IsPropertyOfType(Type type)
• ParentAdpater.CanParent(ModelItem parent, Type childType)
• ParentAdapter.RedirectParent(ModelItem parent, Type childType)

APIs that use TypeIdentifier instead of Type and no longer support constructor arguments:

• ModelFactory.CreateItem(EditingContext context, TypeIdentifier typeIdentifier, params object[] arguments)
• ModelFactory.CreateItem(EditingContext context, TypeIdentifier typeIdentifier, CreateOptions options, params object[] arguments)

APIs that use TypeDefinition instead of Type:

• ValueTranslationService.GetProperties(Type itemType)
• ValueTranslationService.HasValueTranslation(Type itemType, PropertyIdentifier identifier)
• ValueTranslationService.TranslatePropertyValue(Type itemType, ModelItem item, PropertyIdentifier identifier, object value)
• ModelService.Find(ModelItem startingItem, Type type)
• ModelService.Find(ModelItem startingItem, Predicate match)
• ModelItem.ItemType
• ModelProperty.AttachedOwnerType
• ModelProperty.PropertyType
• FeatureManager.CreateFeatureProviders(Type featureProviderType, Type type)
• FeatureManager.CreateFeatureProviders(Type featureProviderType, Type type, Predicate match)
• FeatureManager.InitializeFeatures(Type type)
• FeatureManager.GetCustomAttributes(Type type, Type attributeType)
• AdapterService.GetAdapter (Type itemType)
• AdapterService.GetAdapter(Type adapterType, Type itemType)
• PropertyEntry.PropertyType

APIs that use AssemblyIdentifier instead of :

• AssemblyReferences.ReferencedAssemblies
• AssemblyReferences.LocalAssemblyName changed to AssemblyReferences.LocalAssemblyIdentifier

Furthermore, ModelItem APIs like SetValue will only support instances of primitive types or built-in .NET Framework types which can be converted for the target runtime. Currently these types are supported:

• Primitive .NET Framework types: Boolean , Byte , Char , DateTime , Double , Enum , Guid , Int16 , Int32 , Int64 , Nullable , SByte , Single , String , Type , UInt16 , UInt32 , UInt64 , Uri
• Known WPF .NET Framework types (and derived types): Brush , Color , CompositeTransform , CornerRadius , Duration , EasingFunctionBase , EasingMode , EllipseGeometry , FontFamily , GeneralTransform , Geometry , GradientStopCollection , GradientStop , GridLength , ImageSource , InlineCollection , Inline , KeySpline , Material , Matrix , PathFigureCollection , PathFigure , PathSegmentCollection , PathSegment , Path , PointCollection , Point , PropertyPath , Rect , RepeatBehavior , Setter , Size , StaticResource , TextAlignment , TextDecorationCollection , ThemeResourceExtension , Thickness , TimeSpan , Transform3D , TransformCollection
• Starting in Visual Studio 2019 16.4, Proxy Objects can be defined to map custom types.

More code samples are available in the samples folder.