***Disclaimer: This information applies to Visual Studio 2010 Beta 1 only.***
In the previous post we covered the details of the Microsoft.VisualStudio.ComponentModelHost.IComponentModel service
Now it’s time to talk about the Microsoft.VisualStudio.Shell.Interop.IVsComponentModelHost, which is the other service that is proffered by the host package.
Microsoft.VisualStudio.Shell.Interop.IVsComponentModelHost service
This service has the following responsibilities:
- Get the catalog cache folder
- Get MEF component locations
The catalog cache folder is located @ %LocalAppData%\Microsoft\VisualStudio\10.0\ComponentModelCache.
The Microsoft.VisualStudio.ExtensionManager.IVsExtensionManager service
To query extensions locations the IVsExtensionManager service is used. To filter only MEF component extensions, the “MEFComponent” content type in the VSIX extension manifest is used.
This service has many responsibilities which I will cover in future posts, but the one I will describe is:
- Get enabled extension locations
To get the list of enabled extension locations Visual Studio looks in the following folders:
- %LocalAppData%\Microsoft\VisualStudio\10.0\Extensions
- %VS10_Install_Dir%\Extensions
- %VS10_Install_Dir%\Common7\IDE\Extensions
- %VS10_Install_Dir%\Common7\IDE\CommonExtensions
The first location is where VSIX files are deployed once you double a VSIX file from the Windows explorer shell.
The other locations are being used Visual Studio core extensions and to deploy a VSIX file under those locations you will need administrator privileges.
Stay tuned,
Pablo
***Disclaimer: This information applies to Visual Studio 2010 Beta 1 only.***
These series of posts will cover two types of Visual Studio 10 Beta 1 extensions:
- MEF component (assembly that contains exports and imports)
- VSPackage
In the previous post we said that Visual Studio is a host for MEF components. This is being done by the introduction of a new VS core package called Microsoft.VisualStudio.ComponentModelHost.HostPackage
The host package is declares the following two core services:
- Microsoft.VisualStudio.ComponentModelHost.IComponentModel service
- Microsoft.VisualStudio.Shell.Interop.IVsComponentModelHost service
Microsoft.VisualStudio.ComponentModelHost.IComponentModel service
This service has the following responsibilities:
- Get MEF catalog by name
- Get MEF export / exports
- Creates and maintains a list of available catalogs
- Declares the GlobalCompositionContainer
The VsCatalogProvider, AssemblyListCatalog and VSCatalogName classes:
The GetCatalog method returns a catalog by name by searching the list of available catalogs that is maintained by the service itself.
If the catalog doesn’t exist it is created and then added to the list. To create a catalog the Microsoft.VisualStudio.ExtensibilityHosting.VsCatalogProvider class is used. This class has the following responsibility:
- Build and return an AssemblyListCatalog
The Microsoft.VisualStudio.ExtensibilityHosting.AssemblyListCatalog class derives from the MEF ComposablePartCatalog and it is basically a list of AssemblyCatalogs.
The AssemblyListCatalog is constructed by adding every MEF component assembly found in the system filtered by the catalog name. To find the MEF component assemblies, the Microsoft.VisualStudio.Shell.Interop.IVsComponentModelHost service is used.
To specify a catalog name for a MEF component assembly there is a VsCatalogName attribute:
[assembly: VsCatalogName("Microsoft.VisualStudio.Editor")]
Multiple MEF composition containers:
Visual studio supports multiple MEF composition containers. A core component is responsible for creating its own container. For example the Visual Studio editor creates its own container. There is a service that maintains the list of available containers and it is the Microsoft.VisualStudio.ExtensibilityHosting.VsExportProviderService class.
The GlobalCompositionContainer:
The GlobalCompositionContainer acts as the root MEF composition container. This container is used by the IComponentModel service to get MEF export / exports.
Behind the scenes the GlobalCompositionContainer uses the VsExportProviderService to search in all available containers.
The VsCompositionContainer class:
A container in Visual Studio derives from the MEF CompositionContainer class and adds features such as export providing settings, export sharing policies, export provisioning scope, etc. And it modeled by the Microsoft.VisualStudio.ExtensibilityHosting.VsCompositionContainer class
In the next post I will cover the details for the Microsoft.VisualStudio.Shell.Interop.IVsComponentModelHost service.
Pablo
I just received the confirmation email. I am a MVP again for Visual C#.
I want to thank my MVP lead Fernando Garcia Loera and the rest of people involved in the evaluation process for the recognition of my community efforts.
Thanks Microsoft!!!
Pablo
As you might know, the new VS10 editor extensibility infrastructure is based in the Managed Extensibility framework (MEF).
MEF is a library for creating lightweight, extensible applications. It allows application developers to discover and use extensions with no configuration required.
The core of the MEF composition model is the composition container, which contains all the parts available and it responsible for performing composition.
Visual Studio has it own composition container which means that Visual Studio itself is a host for MEF components.
And of course MEF can be used not only to extend the editor, but other VS components too.
In the next series of posts I will start describing how the new IComponentModel service, the new VsShellComponentModelHost, VsCompositionContainer and VsCatalogProvider classes, works in details. (At least in VS10 Beta 1)
Some MEF pointers:
Managed Extensibility Framework project
Managed Extensibility Framework Programming guide
Managed Extensibility Framework Overview
Pablo
From my friend Pablo:
I just got an email from Miguel Angel Saenz confirming the date of the next biggest Microsoft event in Buenos Aires Argentina, "MSDN briefing", which will take place on March 25th.
They are now accepting proposals or suggestions for possible sessions in the event, or to give an specific name to event itself :).
If you are interested in participating, check out this website.
See you there!
After a long time my nineteenth How do I is up.
Scenario
Sometimes we need to initialize services in the Package.Initialize() method and these services have a dependency on the STE/DTE or other services. The problem is that if the shell is not fully initialized by that moment the SDTE/DTE GetService call will return null. The solution to this problem is to initialize this kind of services when the shell is fully initialized. The focus of this How do I tackles this scenario.
Interfaces and classes needed
Code snippet
public
sealed
class
VSPackage1Package : Package, IVsShellPropertyEvents
{
private uint shellCookie;
protected override void Initialize()
{
base.Initialize();
IVsShell shellService = this.GetService(typeof(SVsShell)) as IVsShell;
ErrorHandler.ThrowOnFailure(
shellService.AdviseShellPropertyChanges(this, out shellCookie));
}
public int OnShellPropertyChange(int propid, object var)
{
if(propid == (int)__VSSPROPID.VSSPROPID_Zombie)
{
if((bool)var == false)
{
//At this point the environment is fully loaded and initialized
//Lets initialize our services
IVsShell shellService = this.GetService(typeof(SVsShell)) as IVsShell;
if(shellService != null)
{
ErrorHandler.ThrowOnFailure(
shellService.UnadviseShellPropertyChanges(this.shellCookie));
}
this.shellCookie = 0;
}
}
return VSConstants.S_OK;
}
}
Assemblies needed
- Microsoft.VisualStudio.Shell.Interop
- Microsoft.VisualStudio.Shell
Stay tuned,
Pablo