This project has moved and is read-only. For the latest updates, please go here.

Error in .NET 4.0 MEF Assembly Load

Jul 17, 2009 at 6:24 PM

I'm doing a different test so I can keep going around the earlier bug that is blocking main line development. I have the following error. I have rebuilt everything, but I'm wondering what could cuase a  part not to be castable to an interface it implements. The declaration of the class is shown below the error to indicate that superficially it does implement the interface. This is in VS2010 Beta 1 running in Win 7 RC. This problem appears to have begun when I switched to x86 to get around a different problem with imports being seen as badly formed.

Message: "The composition produced a single composition error. The root cause is provided below. Review the CompositionException.Errors property for more detailed information.\r\n\r\n1) The export 'AppVenture.DefaultOutputServices.OutputAgregatingService (ContractName=\"AppVenture.Common.IOutputService\")' is not assignable to type 'AppVenture.Common.IOutputService'.\r\n\r\nResulting in: Cannot set import 'AppVenture.TemplateHarness.TemplateHarness._outputService (ContractName=\"AppVenture.Common.IOutputService\")' on part 'AppVenture.TemplateHarness.TemplateHarness'.\r\nElement: AppVenture.TemplateHarness.TemplateHarness._outputService (ContractName=\"AppVenture.Common.IOutputService\") --> AppVenture.TemplateHarness.TemplateHarness\r\n"

 Class Declaration:


   [Export(typeof(IOutputService)), OutputServiceComposition(Priority = Utilities.DefaultPriority)]
   public class OutputAgregatingService : IOutputService

And I triple checked that there aren't two classes in different namespaces. 

Jul 17, 2009 at 6:34 PM

I seem to be totally confused about 64 bit options.

When I run my main MEF app with x86 selected, I get the error above.

When I run my main MEF app with Any CPU selected I do not get this error, but I have a supporting dll which gives the follwoing error whether its compiled with x86 or Any CPU. Note that it doesn't get this far when the main app is anything other than Any CPU so I have no clue whether this is related to the problem.

{"Could not load file or assembly 'T4CompiledTemplates, Version=, Culture=neutral, PublicKeyToken=null' or one of its dependencies. An attempt was made to load a program with an incorrect format."}

 Is there guidance on MEF with x86 and 64 bit platforms?

Jul 17, 2009 at 7:00 PM

Okay, with the first error it's very likely that the same assembly is being loaded into two different Load contexts - what kind of catalog are you using? Are you doing any manual Assembly.Load or Assembly.LoadFrom calls?

The second error is almost always caused by loading a x86 assembly in an x64 process or vice versa. Can you open a Visual Studio command prompt and post the results of running corflags over your main MEF executable, System.ComponentModel.Composition.dll and TFCompiledTemplates.dll?

Jul 17, 2009 at 7:20 PM

Interesting. Let's start with the second problem first...If I'm reading this below, then yes, I have a 32 bit and a 64 bit dll loading. I selected the composition dll from the references, and created the other. So, how do you work with and debug x86 apps with MEF in VS 2010?

I'm rather new to 64 bit so there is a great deal I do not understand about developing in it. Are there guidelines? Am I doing something weird or is this something everyone is going to run into doing MEF development on VS 2010?

C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4
.0>corflags system.componentmodel.composition.dll
Microsoft (R) .NET Framework CorFlags Conversion Tool.  Version  4.0.20506.1
Copyright (c) Microsoft Corporation.  All rights reserved.

Version   : v4.0.20506
CLR Header: 2.5
PE        : PE32
CorFlags  : 9
ILONLY    : 1
32BIT     : 0
Signed    : 1



D:\Users\Kathleen\Current Projects\Universal\AppSilverlight2F - 2010\AppSilverli
ghtGeneration\GenerationRuntime\Templates>corflags T4CompiledTemplates.dll
Microsoft (R) .NET Framework CorFlags Conversion Tool.  Version  4.0.20506.1
Copyright (c) Microsoft Corporation.  All rights reserved.

Version   : v4.0.20506
CLR Header: 2.5
PE        : PE32
CorFlags  : 3
ILONLY    : 1
32BIT     : 1
Signed    : 0

Jul 17, 2009 at 7:57 PM


I wanted to thank you for your help. That trick of corflags was really helpful. Configuration Manager seems a bit confused on one of my projects, but using the explicit setting in the project I was able to get everything marked as "Any CPU" Once I did that these two problems both went away.

Thank you again for your help


Jul 17, 2009 at 9:14 PM

This problem isn't limited to MEF development, this problem applies to all applications. Here's a couple of tables that hopefully help explain it:


On x86 OS, the ‘bitness’ of the process is:

On x64 OS, the ‘bitness’ of the process is:

If entry executable is x86


x86 (WOW64)

If entry executable is x64

Won’t Run


If entry executable is any (MSIL)





Loading a x86 assembly

Loading a x64 assembly

Loading an any (MSIL) assembly

In an x86 process




In an x64 process




This means, if the entry assembly is:

x86: All reference assemblies must be compiled as x86 or any.
x64: All reference assemblies must be compiled as x64 or any.
any: All reference assemblies must be compiled as any.

Hope that helps.


Jul 18, 2009 at 9:51 AM

I'd like to mention that using "ANY" can make Edit Or Continue unusable. It has to be X86 to use Edit Or Continue.