MEFContrib Issue Tracker Rss Feed

Reopened Issue: Provider Model - DefinitionProviderPartCatalog does not cache values unless aggregated [1943]

TheCodeJunkie — Fri, 14 Jun 2013 07:15:30 GMT

The DefinitionProviderPartCatalog does not cache any parts unless it's added to an AggregateCatalog first. This means that when the AddProviderPart metnod is called on the CompositionContainer it will fail with an exception. The reason for this is that the method will try to retreive a ProviderComposablePartDefinition for the object instance and the cache will be empty!

Closed Issue: Provider Model - DefinitionProviderPartCatalog does not cache values unless aggregated [1943]

TheCodeJunkie — Thu, 16 May 2013 09:39:41 GMT

Commented Issue: Add Parameter to RegisterCatalog to add UNIQUE parts [10977]

montijr2007 — Thu, 05 Jul 2012 18:53:48 GMT

A suggestion that I believe would be beneficial to a lot of developers, would be to add the ability to register the parts of the Aggregate catalog, ignoring duplicates.

The issue is, that when I register my exported parts, I get duplicate registrations for the same Export - leading me to the exception, "ImportCardinalityMismatchException", when I try to Resolve<T>().

There isn't an easy work around that I have found and I believe it would be nice to have as part of this package.

Code sample below:

private static void RegisterAssemblies(string assemblyPath, string searchPattern)
{
string[] directories = Directory.GetDirectories(assemblyPath, "Debug", SearchOption.AllDirectories);
var exportedParts = new AggregateCatalog();

foreach (string directory in directories)
{
var assemblyCatalog = new DirectoryCatalog(directory);
exportedParts.Catalogs.Add(assemblyCatalog);
}

_container.RegisterCatalog(exportedParts);
}
Comments: ** Comment from web user: montijr2007 **

Here is what I believe would work- Add this to the UnityContainerExtensions source code for the "RegisterCatalog" method:

public static void RegisterCatalog(this IUnityContainer unityContainer, ComposablePartCatalog catalog)
{
lock (unityContainer)
{
var compositionIntegration = EnableCompositionIntegration(unityContainer);
compositionIntegration.Catalogs.Add(catalog);

IEnumerable<ComposablePartCatalog> parts = compositionIntegration.Catalogs.Distinct().ToList();
compositionIntegration.Catalogs.Clear();

foreach (var part in parts)
{
compositionIntegration.Catalogs.Add(part);
}

}
}

Created Issue: Add Parameter to RegisterCatalog to add UNIQUE parts [10977]

montijr2007 — Thu, 05 Jul 2012 17:10:24 GMT

Created Issue: Generic Export With Method Export [10747]

hendryluk — Wed, 09 May 2012 07:11:35 GMT

Given this import:
provider.GetExportedValues<Foo<int>>();

This works:
[Export]
public class Foo<T>
{
public void Blah()
{
}
}
(Returns 1 export for Foo<int>).

This does not work:
[Export]
public class Foo<T>
{
[Export]
public void Blah()
{
}
}
(Returns 0 export for Foo<int>)

I understand that the method export here seems pointless since it can't possibly be imported with out-of-the-box catalogue, but this should be fine since I'll be creating my own custom catalog to handle this method export. What i can't understand is why Foo<int> does not return any export at all.

Created Issue: Add a strong name key to assemblies [10260]

rprimrose — Sun, 29 Jan 2012 23:34:47 GMT

The assemblies available in the download cannot be used in solutions that are strong named.

Created Issue: Unity integration and registration names [9768]

mrinaldi — Mon, 07 Nov 2011 21:50:28 GMT

MefContrib has a bug when using registration names in Unity.
It throws the ImportCardinalityMismatchException, because it ignores the registration names when creating the contract names.

I have the following registrations in unity:

container.RegisterType<IDataLayer>(new
ContainerControlledLifetimeManager(), new InjectionFactory(
(container) => DataLayerFactory.CreateSqlDataLayer());

container.RegisterType<IDataLayer>("Local", new
ContainerControlledLifetimeManager(), new InjectionFactory(
(container) => DataLayerFactory.CreateLocalConfigurationDataLayer());

And on my exported class it has an IDataLayer parameter on its constructor.

I noticed that on PrivateFactoryExportProvider.GetExportsCore method it always gets the contract name by its contract type.

Also the UnityContainerAdapter registers the contract name as the registration name, while contract names should be unique (which doesn't happen with unity where the registration name must be unique
to each type and not globally) and therefore should contain a namespace or something to identify uniquely the registration.

I've modified the project with the following changes:

On PrivateFactoryExportProvider.GetExportsCore:

protected override IEnumerable<Export> GetExportsCore(ImportDefinition
definition, AtomicComposition atomicComposition)
{
if (definition.Cardinality == ImportCardinality.ZeroOrMore)
{
return from exportDefinition in this.ReadOnlyDefinitions
let contractName = exportDefinition.ContractName ??
AttributedModelServices.GetContractName(exportDefinition.ContractType)
where contractName == definition.ContractName
select new Export(exportDefinition, () =>
exportDefinition.Factory(SourceProvider));
}

return base.GetExportsCore(definition, atomicComposition);
}

And on UnityContainerAdapter:

public override void Initialize()
{
TypeRegistrationTrackerExtension.RegisterIfMissing(container);

var tracker = this.container.Configure<TypeRegistrationTrackerExtension>();

foreach (var entry in tracker.Entries)
{
OnRegisteringComponent(entry.Type, GetContractName(entry.Type, entry.Name));
}

tracker.Registering += (s, e) =>
OnRegisteringComponent(e.TypeFrom ?? e.TypeTo,
GetContractName(e.TypeFrom ?? e.TypeTo, e.Name));

tracker.RegisteringInstance += (s, e) =>
OnRegisteringComponent(e.RegisteredType,
GetContractName(e.RegisteredType, e.Name));
}

public override object Resolve(Type type, string name)
{
return this.container.Resolve(type, ExtractName(name));
}

And on CompositionStrategy:

public override void PreBuildUp(IBuilderContext context)
{
// If type is registered in the Unity container, don't even bother
messing with MEF
var policy =
context.Policies.Get<IBuildKeyMappingPolicy>(context.OriginalBuildKey);
if (policy != null)
return;

var container =
context.Policies.Get<ICompositionContainerPolicy>(null).Container;
var buildKey = context.OriginalBuildKey;
var lazyExport = ContainerServices.Resolve(container,
buildKey.Type, buildKey.Name);
if (lazyExport != null)
{
context.Existing = lazyExport.Value;
context.BuildComplete = true;
}
}

The methods GetContractName and ExtractName may be anything you want,
as long as it creates an unique contract name and extract the
registration name from the contract name.
In my case, the contract name is "type[registrationName]".

This solved the problem. Hope it helps someone else and makes it to next release.

Regards

Commented Issue: MefContrib.MVC3 [9101]

Alive43 — Thu, 08 Sep 2011 20:59:58 GMT

Hi All,
I'm using MefContrib.MVC3 and have a rather bizar issue.

When i use DependencyResolver.Current.GetServices<T>() it returns my items twice.

I made an interface IStartupTask and decorated it with the InheritedExport(typeof(IStartupTask))
I have some base class implementing it and finally derive this into my concrete tasks, beside the interface i have no other attributes on these.
When I call DependencyResolver.Current.GetServices<T>().ToArray() it gives me 4 items, but I should have only 2.
Any clues on how I can debug/solve this ?
I tried to add PartCreationPolicy as shared, I would expect this to solve the issue (in a bad way i agree) but still 4 items are returning.
Edit :
I've reflectored the code and did a couple of other tests. This seams to occure with anything that gets imported with ImportMany attribute also.

Regards
Comments: ** Comment from web user: Alive43 **

Hi,
I've the same issue described above. All resolutions using the [ImportMany] attribute produces twice instances. Tried using PartCreationPolicy as long as PartCreationScope and with no luck.
Any thoughts of the authors would be appreciated.
Thanks!

Commented Issue: MefContrib.MVC3 [9101]

sebdg — Sun, 17 Jul 2011 16:40:51 GMT

I apparently fixed my issue, but i might have broken the logic in there.
To resume i had to create a custom dependency resolver and overwritten the way the Container property works
The small change i did is not passing in any export provider. to the container that is hold on a request base.
Now my tasks and controllers are resolved only once.

public CompositionContainer Container
{
get
{
if (!CurrentRequestContext.Items.Contains("__CompositionDependencyResolver_Container"))
{
CurrentRequestContext.Items.Add("__CompositionDependencyResolver_Container", new CompositionContainer(this.filteredCatalog, true, new ExportProvider[] {}));
}
return (CompositionContainer) CurrentRequestContext.Items["__CompositionDependencyResolver_Container"];
}
}

Created Issue: MefContrib.MVC3 [9101]

sebdg — Sun, 17 Jul 2011 13:49:13 GMT

Hi All,
I'm using MefContrib.MVC3 and have a rather bizar issue.

When i use DependencyResolver.Current.GetServices<T>() it returns my items twice.

I made an interface IStartupTask and decorated it with the InheritedExport(typeof(IStartupTask))
I have some base class implementing it and finally derive this into my concrete tasks, beside the interface i have no other attributes on these.
When I call DependencyResolver.Current.GetServices<T>().ToArray() it gives me 4 items, but I should have only 2.
Any clues on how I can debug/solve this ?
I tried to add PartCreationPolicy as shared, I would expect this to solve the issue (in a bad way i agree) but still 4 items are returning.
I have no clue on how i can digg in deeper in this issue.

Regards

Commented Issue: [ImportingContsructor] doesn't work with an open generic. [5856]

dancemonkey — Fri, 17 Sep 2010 03:08:49 GMT

To fix add the following to TypeHelper

public static bool IsReflectionParameterImportDefinition(ImportDefinition definition)
{
return definition.GetType().Name.Equals("ReflectionParameterImportDefinition");
}

and change: if (!exports.Any() && TypeHelper.IsReflectionMemberImportDefinition(definition))

to: if (!exports.Any() && (TypeHelper.IsReflectionMemberImportDefinition(definition) || TypeHelper.IsReflectionParameterImportDefinition(definition)))
Comments: ** Comment from web user: dancemonkey **

been looking on how to solve this, thank you.

Created Issue: Missing Unity (Silverlight) library in latest source (47517) [6019]

metaman — Wed, 28 Apr 2010 08:11:53 GMT

The latest source (changeset 47517) has a missing Unity (Silverlight) library, The desktop version is present.

Created Issue: [ImportingContsructor] doesn't work with an open generic. [5856]

jabbera — Mon, 05 Apr 2010 17:59:06 GMT

Created Issue: GenericCatalog CreateDynamicExport returing null is some cases [5833]

jabbera — Wed, 31 Mar 2010 18:59:56 GMT

If the importDefinition passed to CreateDynamicExport is a non generic interface the return value could be null. This should never happen or the program will crash.

Using reflector on CatalogExportProvider::GetExportsCore you will see why.

foreach (Tuple<ComposablePartDefinition, ExportDefinition> tuple in valueAllowNull.GetExports(definition))

I see two solutions: set the export before the return value if it is null or change:

if (importDefinitionType.IsClass)
to
if (importDefinitionType.IsClass || importDefinitionType.IsInterface)

I don't know if that change is correct but for now it seems to work around my issue.

Mike

Closed Issue: Unity Integration: Order of registrations and ChildContainers [4981]

pwlodek — Mon, 28 Dec 2009 12:20:57 GMT

Hey,

We are currently using UnityIntgration in a Silverlight 4 / .net 4 beta2 project and we have encountered several bugs :
The first one, wich is least critical is that if you register types in your container before calling RegisterCatalog, MEF cannot resolve these registered types.
The second, which if very critical (as complex UI architecture depends highly on it), is that MEF components do not respect ChildContainer Registered Instances.

Here is an exemple of code that fails :

IUnityContainer container = ConfigureMefThenUnity();

var unityComponent = container.Resolve<IUnityComponent>();
container = container.CreateChildContainer();
container.RegisterInstance<IUnityComponent>(unityComponent);

var component = container.Resolve<IMefDependingOnUnity2>();
Assert.IsNotNull(component);
Assert.IsNotNull(component.UnityComponent);
Assert.AreEqual(unityComponent, component.UnityComponent); // fails here, MEF is using the rule defined on the parent container instead of the overriden one in the child container

Attached is the full test file highlighting the 2 bugs described above
Comments:

Commented Issue: Unity Integration: Order of registrations and ChildContainers [4981]

pwlodek — Mon, 28 Dec 2009 12:19:34 GMT

Bug 1
Unity does not provide tracking mechanism that is available to the developer. In order to make types registered in the Unity available to MEF before calling RegisterCatalog, developer needs to explicitly add tracking extension to the Unity. This is done in single line of code, ofcourse MEF does not participate here.

var container = new UnityContainer();
TypeRegistrationTrackerExtension.RegisterIfMissing(container);

Bug 2
In order to make a child container properly work with MEF, developer needs to manually enable MEF integration.

IUnityContainer container = new UnityContainer();

container = container.CreateChildContainer();
container.EnableCompositionIntegration();

Commented Issue: Unity Integration: Order of registrations and ChildContainers [4981]

pwlodek — Mon, 28 Dec 2009 12:19:30 GMT

var container = new UnityContainer();
TypeRegistrationTrackerExtension.RegisterIfMissing(container);

Bug 2
In order to make a child container properly work with MEF, developer needs to manually enable MEF integration.

IUnityContainer container = new UnityContainer();

container = container.CreateChildContainer();
container.EnableCompositionIntegration();

Created Issue: Unity Integration: Order of registrations and ChildContainers [4981]

simonferquel — Wed, 23 Dec 2009 15:14:12 GMT

Commented Issue: Provider Model - DefinitionProviderPartCatalog does not cache values unless aggregated

TheCodeJunkie — Sat, 07 Mar 2009 20:26:52 GMT

This issue has been resolved in change set 15094

Commented Issue: Provider Model - DefinitionProviderPartCatalog does not cache values unless aggregated

TheCodeJunkie — Thu, 05 Mar 2009 21:36:41 GMT

A quick work around for this, until a fix has been checked in, is to add the DefinitionProviderPartCatalog to an AggregateCatalog which is then passed to the CompositionContainer