A service is a contract between two VSPackages. One VSPackage provides a specific set of interfaces for another VSPackage to consume. Visual Studio is itself a collection of VSPackages that provides services to other VSPackages.
For example, you can use the SVsActivityLog service to obtain an IVsActivityLog interface, which you can use to write to the activity log. For more information, see How to: Write to the Activity Log.
Services have no discoverability. Therefore, you must know the service identifier (SID) of a service that you want to consume, and you must know which interfaces it provides. The reference documentation for the service provides this information.
VSPackages that provide services are called service providers.
Services that are provided to other VSPackages are called global services.
Services that are available only to the VSPackage that implements them, or to any object it creates, are called local services.
Services are loaded on demand, that is, the service provider is loaded when the service it provides is requested by another VSPackage.
To support on-demand loading, a service provider registers its global services with Visual Studio. For more information, see Registering Services.
After you obtain a service, use QueryInterface (unmanaged code) or casting (managed code) to get the desired interface, for example:
GetService(typeof(SVsActivityLog)) as IVsActivityLog;
Managed code refers to a service by its type, whereas unmanaged code refers to a service by its GUID.
When Visual Studio loads a VSPackage, it passes a service provider to the VSPackage to give the VSPackage access to global services. This is referred to as "siting" the VSPackage.
VSPackages can be service providers for the objects they create. For example, a form might send a request for a color service to its frame, which might pass the request to Visual Studio.