Component Model and Visual Studio interfaces

If you still need to get an interface implemented by Visual Studio, or by a Visual Studio extension, you can do this in several ways. The easiest is to simply inject the interface as a constructor parameter to your plugin component, or retrieve it from the Shell’s container. For example, to get to VS's Output Window interface IVsOutputWindow, you can acquire it with the following:

Shell.Instance.GetComponent<Lazy<IVsOutputWindow>>()

Note the use of Lazy<T>. Many of the Visual Studio interfaces can only be resolved using Lazy<T>, to allow for delay loading VS packages and assemblies, or Optional<T>, because there is no guarantee that interface is available - perhaps the required VS package isn't installed.

It is recommended that you use Lazy and Optional. If the plugin is run outside of the Visual Studio environment (e.g. in the Command Line Tools), the Visual Studio dependencies will not be available. It is better for your component to handle this gracefully than for the Component Model to be unable to create your component. An alternative is to mark your component as only being able to run in the Visual Studio environment, by passing in the ProgramConfigurations.VS_ADDIN flag to the component attribute. However, this can have a "viral" effect. If this component isn't created because you're not running inside Visual Studio, any other component that depends on this must also include the VS_ADDIN flag, or the Component Model will be unable to create it, also. A better solution is the use of Optional, Lazy, or perhaps moving the component into a Visual Studio specific assembly that is only loaded in the Visual Studio environment.

[ShellComponent(ProgramConfigurations.VS_ADDIN)]
public class MyShellComponent { ... }

[SolutionComponent(ProgramConfigurations.VS_ADDIN)]
public class MySolutionComponent { ... }

ReSharper only exposes a subset of Visual Studio's interfaces in this manner. In fact, the interfaces are only exposed to support ReSharper's own integration with Visual Studio. In addition, some interfaces are wrapped, to ensure correct usage, e.g. wrapping parameters for COM interop, releasing returned COM intptr's, checking returned HRESULTs, etc. You should consult the whitelist below to see what interfaces are available. If it's there, you can consume it via a component's constructor.

Expose interfaces to the container

You can implement a class that will be called by ReSharper during initialisation that can register additional Visual Studio interfaces. It needs to be marked with the WrapVsInterfaces attribute, and implement the IExposeVsServices interface:

[WrapVsInterfaces]
public class ExposeMyServices : IExposeVsServices
{
  public void Register(VsServiceProviderComponentContainer.VsServiceMap map)
  {
    // For example:
    // map.QueryService<SComponentModel>.As<IComponentModel>();
    // or map.Mef<IOutliningManagerService>();
    // or map.OptionalMef<IOutliningManagerService>();
    // or map.Wrapper(interface => GetInterestingInterface(map, interface));
  }
}

This class allows you to expose one or more interfaces that comes from a service. The first example gets the IComponentModel interface from the MEF SComponentModel service, allowing you to call IComponentModel.GetService to retrieve a service exposed by MEF. The next two examples show an easier way of doing this, by adding support for a particular MEF exposed interface. The OptionalMef call is the same as the Mef call, but requires the interface to be wrapped in Optional<T>, or it won't be found. Finally, the Wrapper method calls a custom function to resolve the interface. Use of this method is discouraged.

public static bool IsRegistered<T>(this VsServiceProviderComponentContainer.VsServiceMap map)
{
  return map.Resolve(typeof (T)) != null;
}

These interfaces are now exposed to ReSharper’s container, and can be injected into the constructor, or retrieved via the Shell’s GetComponent method.

You should use Lazy<TInterface> when consuming a Visual Studio interface, so that Visual Studio packages are not loaded until they are used. For example, accepting a parameter of IEditorOperationsFactoryService will cause the VS editor to be loaded into memory as soon as your plugin is loaded, which is at application startup, rather than when the editor is first needed, which might be after a solution has loaded.

If you expect the interface to not be available, you can use Optional<TInterface> in your constructor. You can even combine the two Lazy<Optional<T>> which will defer resolving the underlying service until you need it, and allow it to be missing.

When using map.QueryService, you can enforce requiring these flags by using the LazyOnly and/or Optional methods. If a component tries to consume the service without Lazy<T> or Optional<T> respectively, the Component Model will throw an exception.

public void Register(VsServiceProviderComponentContainer.VsServiceMap map)
{
  map.QueryService<STextTemplating>.As<ITextTemplatingEngineHost>.LazyOnly().Optional();
}

The Mef and OptionalMef methods register the interface as LazyOnly, so you can only get it if you request Lazy<TMefInterface>. If there is a chance that the MEF interface will not be available, you should register it with the OptionalMef method, and consume it as Lazy<Optional<T>>.

Thanks for your feedback!

Was this page helpful?

Component Model and Visual Studio interfaces﻿

warning

Retrieving interfaces from IServiceProvider﻿

Expose interfaces to the container﻿

Default list of exposed interfaces﻿

Component Model and Visual Studio interfaces

Retrieving interfaces from IServiceProvider

Expose interfaces to the container

Default list of exposed interfaces