ashmind / net-feature-tests Goto Github PK

Looking at current generic constraints description, it is not clear that Test is actually resolves Many services and filtering out those not matching with constraints.

I want to suggest to change Feature Test description to be more explicit about test case.

And additionally add another Feature Test to check Single resolution like below (courtesy to SimpleInjector issues feed, should be fixed by now):

internal interface ICommandHandler<TCmd> { }
internal class SpecialEntity { }
internal class UpdateCommand<TEntity> { }

internal class UpdateCommandHandler<TEntity, TCommand> : ICommandHandler<TCommand>
    where TEntity : SpecialEntity
    where TCommand : UpdateCommand<TEntity> { }

[Test]
public void Can_match_generic_parameter_from_constraint()
{
    var container = new Container();
    container.Register(typeof(ICommandHandler<>), typeof(UpdateCommandHandler<,>));

    var handler = container.Resolve<ICommandHandler<UpdateCommand<SpecialEntity>>>();

    Assert.IsInstanceOf<UpdateCommandHandler<SpecialEntity, UpdateCommand<SpecialEntity>>>(handler);
}

This Use Case is specifically applied to modern developed libs like MediatR.

What do you think?

In the graph it states that Unity is not mono compatible, but it says here it supports it https://unity.codeplex.com/wikipage?title=Unity3.5ReleaseNotes

See #21 for details. I've not decided on those yet.

Hi!

LightInject is now available as a binary distribution from NuGet and it would be really nice to see LightInject included in your feature comparison.

I will send you a pull request :)

Best regards

Bernhard Richter

Some containers let you resolve a type even if you haven't registered it, by examining the constructor and resolving all the dependencies, but a lot of them don't. Can you add this feature to the list tested?

[SpecialCase(typeof(SimpleInjectorAdapter), @"
        Simple Injector does allow resolving types with multiple constructors out of the box, but this 
        behavior can be changed by replacing the Container.Options.ConstructorResolutionBehavior.
    ", Skip = true)]

shoulp probably say "Simple Injector does not allow"

Hi Guys,

According to the features table LightInject allows to register/override dependency at any stage, but it actually does not.
Here is corresponding thread: seesharper/LightInject#133

We are using DI Container for our projects with .Net 4.0 2 years before.
Please correct the metrics

Some containers are not thread safe. E.g. Unity container is thread unsafe for registration, but safe for resolve. Search "unity container thread safe".

Different containers throw different errors, may be some silently eat concurrency errors. E.g. possible error is "Collection was modified; enumeration operation may not execute". I see these while running my patch danielpalme/IocPerformance#50 with Multi mode.

I think this important feature to document cause can lead to some errors, not sure how to create all such tests. At leasy this can be manually documented, just need some start point to commit changes.

Debatable if it is good practice or not, but it may be important and decisive factor for someone. Especially when migrating from Container that supports it.

Using DryIoc as example.

Named:

container.Register<IService, Service>(named: "for test");
container.Resolve<IService>("for test");

Keyed:

container.Register<IService, Service>(named: SomeEnum.Special);
container.Resolve<IService>(SomeEnum.Special);

Hi,

adding this code to the Castle Adapter should get the List test working

public CastleAdapter()
{
    kernel.Resolver.AddSubResolver(
        new Castle
            .MicroKernel
            .Resolvers
            .SpecializedResolvers
            .CollectionResolver(kernel));
}

(I'm no expert, I downloaded it for the first time yesterday but I was testing the IEnumerable<> functionality)

See #21 for details. I've not decided on those yet.

As mentioned in our e-mail conversation:

On your DI container comparison website you say regarding TinyIoC:

Code-only NuGet package

I wasn't sure what you meant with that, so you clarified:

I ignored source-only containers mostly because of nuget update concerns (and because I wanted to encourage proper dlls)

I just searched for it and it looks as if TinyIoC is available on NuGet now: http://www.nuget.org/packages/TinyIoC/. It would be great if you could add it to the comparison, because it's being used in the popular REST framework Nancy by default and it would be interesting to know if it makes sense to switch to another DI container from the beginning or if you're good to go with TinyIoC until you need some advanced features.

It may go to either Essential or Convenience topic but important for DI integration into some existing infrastructure or framework.

Using DryIoc as example

class Client { public Client(IService service) {} }

c.Register<Client>();
// forgot to c.Register<IService, Service>()

var client = c.Resolve<Client>(ifUnresolved: IfUnresolved.ReturnDefault);
Assert.IsNull(client);

I think you should include frameworks / assemblies that are not installed by default on a developers machine:

• X-unit
• AshMind (should be restored via nuget, but is not)

There are number of features that may be important (even deciding factor) for people to introduce IoC into current code. Especially in legacy systems it should be possible to start using Container incrementally, then refactoring to the better code.

Features may start with:

• Injecting primitive values.
• Support for default parameters.
• Support for factory methods (static and instance) in addition to constructor.

I know that most of these things could be done with Delegate Registration, but it is less refactoring friendly, or sometimes is not feasible for Runtime scenarios (when types are not known). The latter is common for plugin systems.

The above also may be treated as Convenience, but I would like to separate.

hi
please explain me what does "Sometimes it is inconvenient or impossible to define schema as a static type in advance. This leaves two options -- dictionaries and dynamic types." mean

is it some kind of schema additional initialization through defining a dictionary for it, or dictionary referencing to Collections.Dictionary, or something else?
as it is mentioned along with dynamic types it leads me to thinking, that Dictionary is included as field of serialized object.. but it doesn't make much sense, considering json will serialize dictionary as container (but if it can be 'flattened', that makes sense, tho)

also the term 'roundtrip'. i understand roundtrip as process of decerializing/serializing in one. is it that or smth else meant? what is the point of it in considered context?

Information about Catel: http://www.catelproject.com

Documentation about IoC: https://catelproject.atlassian.net/wiki/pages/viewpage.action?pageId=622682

I'd like to see where MEF is in this comparison, any ideas, or are you purposely leaving that out?

Thanks!

See #21 for initial discussion.

This is opt-in feature activated by LazyOfTComponentLoader registration:

container.Register(Component.For<ILazyComponentLoader>()
                            .ImplementedBy<LazyOfTComponentLoader>());