Missing reference to System.Composition.CompositionContext

Topics: APIs, General
Nov 14, 2014 at 11:25 AM
Edited Nov 14, 2014 at 11:27 AM
After updating the NGet package from 0.7 to 1.0 Beta I get the following compiler error:

Error 1 The type 'System.Composition.CompositionContext' is defined in an assembly that is not referenced. You must add a reference to assembly 'System.Composition.Runtime, Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.

The project is a WPF application. I have created a sub class of the Workspace class and passed the CompositionContainer (MEF). Now the new Workspace class requires a CompositionContext class.
public ScriptingWorkspace(CompositionContainer container) 
    : base(MefHostServices.Create(container), WorkspaceKind.Host)
  • What do I need to reference?
  • How do I get the CompositionContainer from MEF (the .NET Framework variant of MEF)
Nov 14, 2014 at 3:37 PM
The core Workspaces API moved from using MEF in the .NET Framework to "Portable MEF"/"MEF v2" which is available on NuGet. Add a NuGet reference to that version and you'll be good. Assuming you're using MEF to expose additional language services/workspace services, you should just move to using it as well and remove all references to the full .NET Framework version of MEF. If you were using the ExportLanguageService/ExportWorkspaceService attributes, this as already more or less been done for you: those now inherit from the MEF v2 attributes and shouldn't require any significant code changes. A word of warning: don't mix MEF v1 "Import" and "Export" attribute with the MEF v2 ones. Just removing a reference to MEF v1 entirely means you can't make any mistakes.

To give some background on the change: the .NET Framework version of MEF is only supported on the "full framework", meaning we were restricted to running into Console/WinForms/WPF app scenarios. It would have meant the workspaces layer wouldn't be able to easily run on things like Windows Phone, ASP.NET, or even Mono. By moving to Portable MEF it means you can run your stuff using Roslyn in more places and on more devices, which is a good thing.
Nov 14, 2014 at 4:17 PM
Thank you for the information.

I got it running with MEF v2 in a small prototype application. However, our product uses the old MEF version very intensively. Thus, we are not able to switch to the new MEF version because there are a lot features missing.

Visual Studio uses the old MEF version as well. I don't think that MEF will be updated in VS because this would be a breaking change in the Extensibility model. How is this solved within Visual Studio?
Nov 14, 2014 at 4:42 PM
In Visual Studio 2015 we have actually created a new MEF engine that can work with both System.ComponentModel.Composition (i.e. MEFv1) and System.Composition (i.e. MEFv2) MEF attributes. In this way, MEFv1 based components like the editor and MEFv2 based components like Roslyn can work together. This new MEF engine is part of Visual Studio and is not licensed for use or redistribution outside of Visual Studio, so this isn't a technique that you can use, unfortunately.

Can your app host both MEFv1 and MEFv2 containers, using MEFv1 for all your existing stuff and MEFv2 for the Roslyn extensions?
Nov 17, 2014 at 9:14 AM
Thanks for the insight how VS2015 solves this.

Yes, we could host both containers and use them for different aspects (MEFv2 for Roslyn services; MEFv1 for everything else). However, I agree with 'jasonmalinowski' that mixing both MEF versions will create a lot confusion. Especially, regarding the Export attributes.

I stumbled over the MefV1HostServices class. But this approach would only work if I expose all Roslyn services again via the MEFv1 Export attributes.
Nov 17, 2014 at 2:56 PM
Yes, the MefV1HostServices class isn't useful as you point out. We were going to move it to the Visual Studio layer where it can be used: Visual Studio's MEF version can provided a MEF v1 ExportProvider that it can consume. We just didn't get that done with all the other stuff we were doing to release the Visual Studio 2015 Preview.

In regards to the v1 and v2 mixing: it's tricky but not that tricky. More than anything else it just requires some quick training to anybody working in the codebase so it doesn't get too confusing. The good news at least is if somebody does something wrong it'll break in a fairly obvious way, so it's not like you'll have an insidious bug that'll only appear months later.
Nov 18, 2014 at 5:57 AM
Thank for your feedback. I will give it a try.