MEF Issue Tracker Rss Feed

Commented Issue: WP8 support missing in PCL assemblies! [14603]

erezak — Mon, 18 Mar 2013 15:49:40 GMT

Since Windows Phone 8 is not checked as supported target framework in the MEF portable class libraries (currently only .NET for Windows Store apps and .NET Framework 4.5), it will only work in emulator and not on a physical device. So in order to be able to share code between WinRT and WinPRT you have to rebuilt the MEF source yourself, with added support for WP8.

Since the solution is as simple as that I hope there will be a release very soon, with common PCLs targeting all of the above, thus enabling shared assemblies between Windows Store apps and Windows Phone 8 apps for example.
Comments: +1

Created Issue: Plugin can't deserialize -? [14606]

wak — Fri, 15 Mar 2013 13:45:12 GMT

Hi,

I've developed a plugin for my MEF application, and it uses it's own serialize / deserialize utility for persisting state data (BinaryFormatter). On it's own outside of MEF, the plugin project works fine. However, when working with the MEF host, the plugin serialization util fails. While the plugin is able to serialize objects, when it tries to deserialize them (e.g., on the next line of code) it fails. The exception is that it is "unable to find assembly..." and the assembly it can't find is it's self !!!!

By the way, the test object that was serialized is a dummy defined within the plugin project. No issues here. And, MEF solution, apart from this issue, seems to be working fine - Assemblies found, export/imports resolved.

I'm new to MEF and so unsure what the problem is. Any thoughts appreciated.

Thanks!
wak

Created Issue: DirectoryCatalog and assembly with same name, bug? [14605]

ravneetg — Thu, 28 Feb 2013 03:45:31 GMT

Hi All,

I have a scenario where my application (say Program.exe) runs from a Bin folder. There is a Bin/Plugins folder which has some more assemblies (say Plugin1.dll and Plugin2.dll). For some reasons I also have a Plugin1.dll in the Bin folder. (So Plugin1.dll exists in Bin and in Plugins folder). Both DLLs have a little different implementation (another story!)

Next I am creating a DirectoryCatalog for Plugins Folder, and in the output log I see that as soon as I create a DirectoryCatalog for Plugins folder, MEF seems to load the Plugin1.dll from Bin folder, where as I expected it to load the Plugin1.dll from Bin/Plugins folder, as that is where the DirectoryCatalog points to.

I think that even though internal code in DirectoryCatalog intends to load Bin/Plugin/Plugin1.dll, but when it actually loads the dll, it just loads it from the current folder where Program.exe is being run from.

As a different test, I removed the Bin/Plugins/Plugin1.dll and kept the Plugin1.dll in Bin, then it does NOT even look for Plugin1.dll, so it confirms that while creating the DirectoryCatalog object, it certainly looks at Bin/Plugin folder (which is correct) but when it comes to load, it loads Plugin1.dll from the current folder, instead of the folder passed to DirectoryCatalog.

Can anyone confirm that this is not the correct behavior, or if it is, then why?

Thanks!
Ravneet

Commented Issue: Shared part instantiated twice [14604]

nblumhardt — Tue, 12 Feb 2013 22:56:58 GMT

When a:
* Shared part
* Involved in a circular dependency
* Has more than one export

Then the part should be created only once but is instantiated twice.

Found in version 1.0.16.

Failing test case below.

```
[Shared, Export, Export("named")]
public class TwoExports
{
[Import]
public CircularImporter Importer { get; set; }
}

[Shared, Export]
public class CircularImporter
{
[Import]
public TwoExports TwoExports { get; set; }
}

[TestMethod]
public void SharedPartWithManyExportsInCircularityCreatedOnce()
{
var container = new ContainerConfiguration()
.WithPart<TwoExports>()
.WithPart<CircularImporter>()
.CreateContainer();

var a = container.GetExport<TwoExports>("named");
var b = container.GetExport<TwoExports>();
Assert.AreSame(a, b);
}
```

Comments: Issues is in DiscoveredPart.cs -> DiscoveredPart.GetActivator(). This code is reentrant during activator creation, but doesn't account for that fact. Because of this, it creates two activators for the one part; the activators themselves carry the shared instance, so two activators == two shared instances. The fix is simple - the class just needs to detect when it is already initialising, and return a thunk in that case. The class is single-threaded so no synchronisation is required. First the class needs a Boolean to track whether initialisation of the activator has started: ``` bool _activatorCreationStarted; ``` Then after the initial check in GetActivator(): ``` public CompositeActivator GetActivator(DependencyAccessor definitionAccessor, IEnumerable<CompositionDependency> dependencies) { if (_partActivator != null) return _partActivator; ``` We insert a new condition: ``` if (_activatorCreationStarted) return (c, o) => _partActivator(c, o); _activatorCreationStarted = true; ``` The tests now pass, including the new one in the issue above.

Created Issue: Shared part instantiated twice [14604]

nblumhardt — Wed, 30 Jan 2013 06:12:56 GMT

Commented Issue: If a base class has an import that fails the exception does not give the right reason [8492]

vivmaha — Tue, 01 Jan 2013 04:56:55 GMT

In the code below the test fails until you un-comment on the line "var typeCatalog = new TypeCatalog(typeof(Foo));//, typeof(Bar));". Then the test works.

FooImporter is a class that imports Foo. The Foo has a base class FooBase. FooBase has an import on IBar. The contract IBar is not possible to satisfy without the type Bar that exports the contract IBar.

If I try to satisfy imports on Foo without the container knowing Bar the error reported is not that an IBar Export is missing. The error is that IFoo is missing which it technically is not. It is present but has a child that is missing.

On the other hand if you try to satisfy imports on the Foo class direct the error shows that IBar is missing (second test).

As I see it there is a break in the error reporting causing the erroneous assumption that IFoo is missing when it is IBar that is missing. But only when Foo is not the root of the graph satisfied by MEF.

Cheers,

M.

[TestClass]
public class MEFBadBaseImportTests
{
[TestMethod]
public void Bad_base_class_messes_up_the_error_message()
{
var typeCatalog = new TypeCatalog(typeof(Foo));//, typeof(Bar));
var compositionContainer = new CompositionContainer(typeCatalog);

var fooImporter = new FooImporter();

try
{
compositionContainer.SatisfyImportsOnce(fooImporter);
}
catch (CompositionException ce)
{
var stringBuilder = new StringBuilder();
stringBuilder.AppendLine("Message:").AppendLine(ce.Message);
stringBuilder.AppendLine(new string('*', 42));
foreach (var error in ce.Errors)
{
stringBuilder.AppendLine("Error:").AppendLine(error.Exception.Message);
stringBuilder.AppendLine(new string('*', 42));
}
Assert.Fail(stringBuilder.ToString());
}

Assert.IsNotNull(fooImporter.Foo);
}

[TestMethod]
public void Using_the_class_direct_shows_the_correct_error()
{
var typeCatalog = new TypeCatalog(typeof(Foo));//, typeof(Bar));
var compositionContainer = new CompositionContainer(typeCatalog);

var foo = new Foo();

try
{
compositionContainer.SatisfyImportsOnce(foo);
}
catch (CompositionException ce)
{
var stringBuilder = new StringBuilder();
stringBuilder.AppendLine("Message:").AppendLine(ce.Message);
stringBuilder.AppendLine(new string('*', 42));
foreach (var error in ce.Errors)
{
stringBuilder.AppendLine("Error:").AppendLine(error.Exception.Message);
stringBuilder.AppendLine(new string('*', 42));
}
Assert.Fail(stringBuilder.ToString());
}

Assert.IsNotNull(foo.Bar);
}

public interface IFoo { }

public interface IBar { }

public abstract class FooBase : IFoo
{
[Import]
public IBar Bar { get; set; }
}

[Export(typeof(IFoo))]
public class Foo : FooBase
{ }

[Export(typeof(IBar))]
public class Bar : IBar { }

public class FooImporter
{
[Import]
public IFoo Foo { get; set; }
}
}
Comments: I ran into the same issue. Very misleading message....

Created Issue: WP8 support missing in PCL assemblies! [14603]

Will_o_Wisp — Tue, 11 Dec 2012 19:11:02 GMT

Commented Issue: Missing Component DeploymentCatalog [14602]

thaehn — Fri, 07 Dec 2012 22:36:55 GMT

I moved some code from the 4.0 framework to the 4.5 framework and the object System.ComponentModel.Composition.Hosting.DeploymentCatalog doesn't exist anymore.
Comments: I copied the older DLLs from another project and now I get this error: {System.IO.FileNotFoundException: Could not load file or assembly 'System.Threading.Tasks, Version=2.5.11.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified. File name: 'System.Threading.Tasks, Version=2.5.11.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'} When I new up a Deployment Catalog. The version in the GAC is 4.0.0.0. The code is simple: aggregateCatalog = new AggregateCatalog(); aggregateCatalog.Catalogs.Add(new DeploymentCatalog()); Any idea on what to do?

Created Issue: Missing Component DeploymentCatalog [14602]

thaehn — Wed, 05 Dec 2012 22:15:38 GMT

I moved some code from the 4.0 framework to the 4.5 framework and the object System.ComponentModel.Composition.Hosting.DeploymentCatalog doesn't exist anymore.

Created Issue: Couple of very hindering issues with RegistrationBuilder [14601]

Vladan — Sat, 27 Oct 2012 14:32:50 GMT

Hi everyone,

I found several issues with RegistrationBuilder that are quite strange...can anyone confirm are they really like this or?

1) When defining convention on generic interface to export interface

builder.ForTypesDerivedFrom(typeof(IRepository<>)).Export(b => b.AsContractType(typeof(IRepository<>)));

This doesn't work for me...when I put concrete type and start with ForTypes() than it works...but that is not what I need, for every type then I need to repeat.

This works for non generic exports, only not for generic ones

2) When wanting to use the builder for properties...is it possible that for every property we need to define ImportProperty??

That means that this case is not possible:

builder.ForTypesDerivedFrom<Window>().Export();

But instead for each window I need to define:

builder.ForType<ListingsWindow>().ImportProperty(w => w.ListingsRepository).Export<ListingsWindow>();

Is that possible?

3) Rewriting [ImportMany] properties to Builder approach not working when having metadata defined

So when having property

public IEnumerable<Lazy<IRepository<Listing>, IRepositoryMeta>> ListingsRepositories { get; set; }

This does not work in any case?

When I put it in constructor as constructor binding of *Many properties works, it only works if I remove the Lazy<...IMeta>, so if its a direct binding of IEnumerable<IRepository<Listing>>.

Is this possible??

Kind regards,
Vladan

Closed Issue: Nuget for Portable Class [14600]

alokshriram — Mon, 22 Oct 2012 19:19:03 GMT

Hello,

I am trying to use MEF on a portable class library (supporting .NET 4.5 and Silverlight 5), but I am getting this error with NuGet:

>>Could not install package 'Microsoft.Composition 1.0.15'. You are trying to install this package into a project that targets '.NETPortable,Version=v4.0,Profile=Profile24', but the package does not contain any assembly references or content files that are compatible with that framework. For more information, contact the package author.

Comments: The package has now been update to support being targeted by portable librarise

Commented Issue: Nuget for Portable Class [14600]

alokshriram — Mon, 22 Oct 2012 19:18:31 GMT

Hello,

I am trying to use MEF on a portable class library (supporting .NET 4.5 and Silverlight 5), but I am getting this error with NuGet:

>>Could not install package 'Microsoft.Composition 1.0.15'. You are trying to install this package into a project that targets '.NETPortable,Version=v4.0,Profile=Profile24', but the package does not contain any assembly references or content files that are compatible with that framework. For more information, contact the package author.

Comments: The version of MEF that can be used to target portable class libraries is now uploaded. Please update your NuGet package to get the latest bits. However please make sure that you have the latest version of NuGet. http://docs.nuget.org/docs/start-here/installing-nuget thanks

Commented Issue: Nuget for Portable Class [14600]

alokshriram — Fri, 19 Oct 2012 16:25:55 GMT

Hello,

I am trying to use MEF on a portable class library (supporting .NET 4.5 and Silverlight 5), but I am getting this error with NuGet:

>>Could not install package 'Microsoft.Composition 1.0.15'. You are trying to install this package into a project that targets '.NETPortable,Version=v4.0,Profile=Profile24', but the package does not contain any assembly references or content files that are compatible with that framework. For more information, contact the package author.

Comments: We are aware of this issue. Hang tight, we should have this fixed really soon. Will update here when we do so. thanks -alok

Created Issue: Nuget for Portable Class [14600]

vbgraphix — Wed, 17 Oct 2012 20:34:50 GMT

Commented Issue: Method Exports do not work with Registration Builder [14570]

nblumhardt — Wed, 18 Jul 2012 23:36:49 GMT

Closed Issue: Open Generic Support Doesnt Work With Delegate-Type Arguments [14594]

nblumhardt — Wed, 18 Jul 2012 23:34:02 GMT

Given this export:
[Export(typeof(Foo<>))]
public class Foo<T>
{
}

This works:
provider.GetExports<Foo<int>>();

But doesnt work with delegate types:
provider.GetExports<Foo<Action>>();

Comments: We've moved this issue to our internal system and will continue to track it for a future release, however we do not plan to take action on this in the short term. Thank you for the report with repro, much appreciated.

Closed Issue: Method Exports do not work with Registration Builder [14570]

nblumhardt — Wed, 18 Jul 2012 23:10:27 GMT

See discussion thread: http://mef.codeplex.com/discussions/283605#post714795

Parts with [Export]s on methods cannot be composed if a RegistrationBuilder is in use.
Comments: We've moved this issue to our internal system for future tracking, but don't expect to take action on this in the short term. The recommended workaround is to use property exports in place of method exports when using RegistrationBuilder (properties of delegate types behave equivalently to method exports). Thanks for following up.

Closed Issue: Exception on multiple open generic exports of same arity [14586]

nblumhardt — Wed, 18 Jul 2012 23:07:02 GMT

Here is a test case:

[TestMethod]
public void MultipleOpenGenericExports()
{
var container = new CompositionContainer( new TypeCatalog( typeof( GenericPart<> ) ) );
var obj = new GenericImporter();
container.SatisfyImportsOnce( obj );
}

public interface IGenericA<T> { }
public interface IGenericB<T> { }

[Export( typeof( IGenericA<> ) )]
[Export( typeof( IGenericB<> ) )]
public class GenericPart<T> : IGenericA<T>, IGenericB<T> { }

public class GenericImporter
{
[Import] public IGenericA<int> ImportedProperty { get; set; }
}

This case causes an exception saying that "there are more than one export for IGenericA(Int32)".
This happens because of how the ReflectionComposablePartDefinition.GetCandidateParameters method is implemented: when there are multiple open generic exports with same arity, the method will yield as many identical results as there are such exports, resulting in that many identical exports returned from TryGetExports.

One possible fix (that I have implemented for my own use) is to call a Distinct operator on the result of GetCandidateParameters:

foreach (Type[] candidateParameters in this.GetCandidateParameters(genericTypeParameters).Distinct( TypeArrayComparer.Instance ) )

Where TypeArrayComparer is a trivial implementation if IEqualityComparer<Type[]>:

class TypeArrayComparer : IEqualityComparer<Type[]>
{
public static readonly TypeArrayComparer Instance = new TypeArrayComparer();

public bool Equals( Type[] x, Type[] y )
{
if ( x == null ) return y == null;
if ( y == null ) return false;
if ( x.Length != y.Length ) return false;
for ( int i = 0; i < x.Length; i++ ) if ( x[i] != y[i] ) return false;
return true;
}

public int GetHashCode( Type[] obj )
{
if ( obj == null ) return 0;
var hash = 0;
foreach ( var t in obj ) hash += t.GetHashCode();
return hash;
}
}

Comments: This issue is fixed in the .NET Framework 4.5 RC and later. Thank you for the detailed report.

Closed Issue: MEF DirectoryCatalog not override the Project References at time of Loading [14593]

nblumhardt — Wed, 18 Jul 2012 23:05:02 GMT

I have a interface as follows:

[InheritedExport(typeof(ITransform))]
public interface ITransform
{...}

Now, I have two classes:

namespace ProjectA
{
public class Transform:ITransform {....}
}

And

namespace ProjectB
{
public class Transform:ITransform {....}
}
I have another project ProjectXYZ(auto generated by third party tool(Altova Mapforce 2012 SP1)).

For ProjectA customized auto generated code from altova mapforce 2012:

namespace ProjectXYZ
{
public classA{...}
}

For ProjectB customized auto generated code from altova mapforce 2012:

namespace ProjectXYZ
{
public classA{...}
public classB{...}
}

Third party auto generated codes are not exported, But its binaries I used as reference of ProjectA.Transform and ProjectB.Transform.So I am using [DirectoryCatalog] for loading all binaries of ProjectA.Transform and ProjectB.Transform in CompositionContainer of MEF. Each project is compiled and their binaries(build output) location is given as an input to DirectoryCatalog

for further composition.

extensionPath = Location of Debug directory of ProjectA.Transform and ProjectB.Transform.

[1] C:\ProjectDemo\ProjectA.Transform\Bin\Debug

[2] C:\ProjectDemo\ProjectB.Transform\Bin\Debug

The methd code for fetching ITransform parts is as follows:

public class ExtensionFactory
{
public ITransform GetExtension(string extensionPath)
{
IEnumerable<ITransform> extensions = null;
try
{
AggregateCatalog catalog = new AggregateCatalog();
catalog.Catalogs.Add(new DirectoryCatalog(extensionPath));
CompositionContainer container = new CompositionContainer(catalog);
container.ComposeParts(this);
extensions = container.GetExportedValues<ITransform>();
return extensions.FirstOrDefault();
}
catch (Exception ex) {........}
return extensions.FirstOrDefault();
}
}

ProjectA.Transform uses ProjectXYZ.ClassA, whereas ProjectB.Transform uses ProjectXYZ.ClassB from another implementation of ProjectXYZ. The implementation and classes

of ProjectXYZ varies across for different implementation of ITransform. The classes in ProjectXYZ are automatically generated through some third-party tools, which I

need to use directly. So, I cannot make any changes to ProjectXYZ.

So, when first time MEF loads ProjectA.Transform, it also loads ProjectXYZ to be used as a reference for ProjectA. When ProjectB.Transform is getting loaded/exported,

then as ProjectXYZ Assemblies being already in MEF memory, it uses the ProjectXYZ Assemblies reference available from **"C:\ProjectDemo\ProjectA.Transform\Bin\Debug"**. Thus, when ProjectB.Transform is executing, it searches for ProjectXYZ Assemblies from **"C:\ProjectDemo\ProjectB.Transform\Bin\Debug"**, which it does not gets as MEF has load ProjectXYZ Assemblies reference available in **"C:\ProjectDemo\ProjectA.Transform\Bin\Debug"**.

How to resolve this problem. The MEF loads the parts correctly, but it does not load the supporting dll's references in a desired manner. I have also tried

PartCreationPolicy attribute, but the results are same.
Here I attach the problem source code too.
[1]: http://mef.codeplex.com/wikipage?title=Using%20Catalogs
Comments: As noted on Stack Overflow this is the behavior of the .NET loader, not MEF. Thank you for the issue report.

Closed Issue: Expose reasons for ignoring types in TypeCatalog [14585]

nblumhardt — Wed, 18 Jul 2012 23:03:08 GMT

Hi,
I've got confused when using MEF2 framework and hopefully this will help others if they get to the same problem.
I've read about the new RegistrationBuilder which allow to use "register by convention" way. The nice thing there is that I don't have to put ExportAttribute all over my types.

I've got confused when try to use TypeCatalog by to create a catalog of types which do not have Export attribute on them. I fail to realize I have to either have Export attribute or pass a RegistrationBuilder to the TypeCatalog.

1. It will be handy to have something like TypeCatalog to which I can pass types that I want to have in the catalog without the need to create RegistrationBuilder for them. I can think of corner cases like multiple ctors which may pose difficulty but maybe it worth thinking about.

2. It will be helpful to know that a Type I've pass into TypeCatalog was not included in it and why. The behavior today is that the TypeCatalog silently ignore they types and it's hard to understand why.

3. What is the relation between the attribute programming model and the RegistrationBuilder? If I have Export attribute on a type and also pass RegistrationBuilder, which one is actually been used?

Thank you,
Ido.
Comments: The ContainerConfiguration class in the Microsoft.Composition version of MEF now exposes an IgnoredTypes property when viewed in the debugger - this goes some way to aiding in this scenario.