MEF Issue Tracker Rss Feed

Commented Issue: Calls to ToUpperInvariant () break compatibility on unix-like file systems. [8831]

jhurliman — Thu, 12 Nov 2009 01:32:32 GMT

The Code makes a few calls to ToUpperInvariant () related to files. In particular it does so twice in DirectoryCatalog.cs . This makes it impossible to use the code on filesystems that are case-sensitive. (I've tested this with Mono on Linux.)

Created Issue: Dynamic dll doesn't load the ServiceReference.config [9069]

al011757 — Thu, 29 Oct 2009 01:30:37 GMT

When a xap is downloaded it seems that the PackageCatalog doesn't load the ServiceReference.ClientConfig file into memory. Thhis leads into the WCF client cannot be instantiated

Created Issue: ImportMany and ICollection implementations [8973]

orca — Tue, 13 Oct 2009 10:10:08 GMT

If the custom collection type has more than one implementation of ICollection<T>,
Import fails and the error description is misleading. I had to download source code and debug.

Easiest way to describe is some code:
________________________________________
SampleCollection<T> : Dictionary<string, T>, ICollection<T>
{ ... }

...

[ImportMany(typeof(IService))]
SampleCollection<IService> services;
__________________________

Here, import fails because Dictionary also implements ICollection<KeyValuePair<string, IService>>.
Reflection code throws an exception because of ambiguity.
Why not it does not check directly for ICollection<IService> implementation? I don't know, maybe because of another use case.

BTW, source code for preview 7 is missing, I had to revert back to preview 6.

Commented Issue: Calls to ToUpperInvariant () break compatibility on unix-like file systems. [8831]

nblumhardt — Fri, 02 Oct 2009 21:11:02 GMT

Thanks for letting us know, we'll look into this.

Nick

Closed Issue: ImportMany error fails silently [8830]

nblumhardt — Fri, 02 Oct 2009 21:03:41 GMT

Situation:
You have a class A with an ImportMany of contract type X. Another class B that exports contract type X also has an Import of contract type Y (not an ImportMany, just an Import). There is no one that exports contract type Y.

I would expect this situation to throw a CompositionException, but instead the ImportMany-of-contract-X in class A is simply missing class B with no error given. In debugging this issue, I was unfamiliar with class B (and didn't know at first that it was Import'ing anything) and it therefore took me a long time to debug the issue, whereas a CompositionException would have pointed me to the cause immediately. I can't think of a situation where a silent failure of any Import of cardinality 1 would be preferable to a CompositionException, even if that failed Import is "hidden" under an ImportMany. A failed cadinality-1 Import is a failure, regardless of where in the composition it happens.

This is with preview 6.
Comments:

Commented Issue: ImportMany error fails silently [8830]

nblumhardt — Fri, 02 Oct 2009 21:03:30 GMT

This is part of Stable Composition, and is by design. You can get some ideas of scenarios where this behaviour is desirable here: http://blogs.msdn.com/nblumhardt/archive/2009/07/17/light-up-or-mef-optional-exports.aspx

Debugging can be tricky but there are tools available that make it a ten-second task, e.g. see http://blogs.msdn.com/nblumhardt/archive/2009/09/24/debug-composition-from-within-visual-studio.aspx

Thanks for raising this!

Nick

Created Issue: Calls to ToUpperInvariant () break compatibility on unix-like file systems. [8831]

jroith — Wed, 23 Sep 2009 20:38:51 GMT

Created Issue: ImportMany error fails silently [8830]

ccrain — Wed, 23 Sep 2009 15:34:53 GMT

Created Issue: RecursiveDirectoryCatalog

SandRock — Mon, 31 Aug 2009 15:52:30 GMT

Could it be possible to add a recursive option to DirectoryCatalog? Or can you just make the following method protected in order to permit us to re-implement it?
private string[] GetFiles()

Commented Issue: Allow the updating of MEF extension during runtime of the app

BillL — Mon, 31 Aug 2009 13:01:11 GMT

In its current form MEF locks the extension files after they've been loaded. This means that the extension can not be updated during runtime of the application. In a future version of MEF I would like to see an optional feature which would allow to load the extensions without locking them.
Comments: ** Comment from web user: BillL **

Here is a custom MEF that will do just that. Be sure to read this thread before using it: http://mef.codeplex.com/Thread/View.aspx?ThreadId=65227

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

nblumhardt — Thu, 27 Aug 2009 22:03:30 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: ** Comment from web user: nblumhardt **

Thanks for reporting this BTW.

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

nblumhardt — Thu, 27 Aug 2009 22:01:36 GMT

This behaviour is deliberate, although it may not be expected. This is a side-effect of Stable Composition - there are some diagnostic tools described at http://blogs.msdn.com/nblumhardt/archive/2009/07/09/mef-preview-6-available.aspx that may help.

Post .NET 4 we will consider how this error reporting might be improved.

Created Issue: Allow the updating of MEF extension during runtime of the app

Miksu — Thu, 20 Aug 2009 07:06:00 GMT

Created Issue: If a base class has an import that fails the exception does not give the right reason

NoopMan — Thu, 13 Aug 2009 20:59:23 GMT

Closed Issue: Add AllowPartiallyTrustedCallersAttribute to System.ComponentModel.Composition

haveriss — Fri, 07 Aug 2009 17:20:26 GMT

Hello,

AllowPartiallyTrustedCallersAttribute should be applied to System.ComponentModel.Composition to allow composition to work in partially trusted environments.
I have a fully-trusted assembly loading plugins. Policies have been applied to the AppDomain so that plugins run under a very limited set of permissions, including ReflectionPermissionFlag.RestrictedMemberAccess so they can use reflection on themselves but not on the fully-trusted assembly. These plugins are exported using the classical MEF ExportAttribute.

However, since AllowPartiallyTrustedCallers is not applied to the MEF assembly, every MEF attribute such as ExportAttribute, PartCreationPolicyAttribute, etc are not present when calling GetCustomAttributes() on exported types. The result is that MEF see no export at all, and composition fails. Recompiling System.ComponentModel.Composition with [attribute: AllowPartiallyTrustedCallers] automatically solves this problem, but it'll be nice if we didn't have to do this, since this assembly will be part of .NET Framework 4.0. I think my scenario is pretty common to be considered.

Thanks!
Comments:

Aptca is applied to our shipped binary (not codeplex)

Commented Issue: Add AllowPartiallyTrustedCallersAttribute to System.ComponentModel.Composition

haveriss — Fri, 07 Aug 2009 17:20:01 GMT

Hi, I dont think we will apply APTCA to our codeplex release. That said, the MEF version shipped with .net 4.0 has aptca applied.
Thanks

Closed Issue: ImportMany child failing composition does not throw

nblumhardt — Fri, 07 Aug 2009 16:56:56 GMT

In MEF Preview 6: If you [ImportMany] and one of the 'children' that get imported is impossible to satisfy imports on you won't get an exception from MEF. Instead it tells you the collection does not contain the instance.

In MEF Preview 5: You get one instance of the Export and when you do GetExportedObject() you get an exception.

I prefer the old functionality from MEF Preview 5: The Export is found but when instantiated it throws. Now instead we get a collection that does not contain an import that does exist but has an error.

Is this new behavior intentional or is this a bug?

Below is a test class with a test and some comment code on how to repeat our finding. 1) Run the test. 2) Comment out the [Import] attribute on Foo.Bar and run the test again.

Cheers,

Magnus and Peter

[TestClass]
public class MEFTests
{
[ImportMany]
public IEnumerable<Lazy<IFoo, IFooMetaData>> TestMetadata { get; set; }

public interface IFoo { }
public interface IFooMetaData { string Foo { get; } }

// Note: There is nothing that [Export]s IBar only an [Import] below
public interface IBar { }

[Export(typeof(IFoo)),
ExportMetadata("Foo", "bar")]
public class Foo : IFoo
{
[Import]
public IBar Bar { get; set; }
}

[TestMethod]
public void ImportMany_child_failing_composition_does_not_throw()
{
var typeCatalog = new TypeCatalog(typeof(MEFTests), typeof(Foo));
var container = new CompositionContainer(typeCatalog);

// I would expect the next line to throw because Foo's dependency on IBar cannot be resolved in MEF.
container.SatisfyImportsOnce(this);

// However it does not throw but rather gives me an empty collection.
// Which causes the following Assert to fail.

Assert.AreEqual(1, TestMetadata.Count());
IFoo value = TestMetadata.First().Value;
Assert.IsNotNull(value);

// Finally comment out the [Import] on Foo.Bar and run the test again.
// The test now succeeeds!
}
}
Comments:

This is by design - see: http://blogs.msdn.com/nblumhardt/archive/2009/07/17/light-up-or-mef-optional-exports.aspx

Thanks for raising this though. If you need any help working with this behaviour feel free to post on the discussion group.

Commented Issue: Add AllowPartiallyTrustedCallersAttribute to System.ComponentModel.Composition

nblumhardt — Fri, 07 Aug 2009 16:53:19 GMT

Thanks for reporting this, we'll look into your scenario.

Created Issue: Add AllowPartiallyTrustedCallersAttribute to System.ComponentModel.Composition

MrJul — Wed, 05 Aug 2009 10:04:25 GMT

Created Issue: Add support for filtered and projected imports

dcazzulino — Sun, 02 Aug 2009 17:52:00 GMT

Hey guys,
I have seen it now in a couple places that filtered imports would be a very handy thing to have. This is done manually by the DSL toolkit/ModelBus guys, as well as ourselves (as I showed Glenn last week)

The current implementations (workaround) involves doing an ImportMany on some interface, and re-exporting the enumerable after applying some filter and/or transformation.

For filter-only, I could see how having ImportManyAttribute-derived classes would remove the need for these "man in the middle" class:

[MyImportMany(Host="VS")]

This attribute would receive a filter string, that would be applied against export metadata to filter out things that do not belong to the "VS" host (model bus has such a scenario). You can see an example today in VS TeamArch in:
Name: Microsoft.VisualStudio.Modeling.Integration.CompositionConfigurationManager
Assembly: Microsoft.VisualStudio.Modeling.Sdk.Integration.10.0, Version=10.0.0.0

the base ImportManyAttribute would just have a new member that would allow filtering:

abstract class FilteredImportManyAttribute<T> : ImportManyAttribute
{
protected abstract bool Filter(Lazy<T, IDictionary<string, object>> export);
}

you could also provide another base class for typed metadata:

abstract class FilteredImportManyAttribute<T, TMetadataView> : ImportManyAttribute
{
protected abstract bool Filter(Lazy<T, TMetadataView> export);
}

The base ImportManyAttribute would just return true for all exports, and provide the hook for the strong-typed derived attributes to hook into (doing the down casting of the export as necessary, etc.).

For transformations/projections you could apply the same principle, essencially having a SelectorImportManyAttribute (or something like that ;)):

abstract class SelectorImportManyAttribute<TSource, TTarget> : ...
{
protected abstract Lazy<TTarget> Select(Lazy<TSource> source);
}

With this, I would be able to provide something like:

[BusAdapterRegistrations]
IEnumerable<IBusRegistration> Registrations { get; set; }

the AdapterRegistrationsAttribute would actually be the adapter that transforms Lazy<ModelBusAdapter> to Lazy<IBusRegistration>, ready for the import. Yes, this may cause a proliferation of import-derived attributes, but I don't think that's a bad thing (the fact that you opened that in the first place is a good sign IMO), as it gives domain-specific semantics to the generic import/export MEF mechanism. An end user wouldn't need to know MEF core concepts to leverage it.