simpleinjector Issue Tracker Rss Feed

Closed Issue: RegisterOpenGeneric registrations incorrectly give SRP warning [19670]

dot_NET_Junkie — Sat, 04 May 2013 23:26:32 GMT

The following registration incorrectly warns about a Single Responsibility Warning:

``` c#
var container = new Container

// Consumer class contains a IGenericPlugin<IDisposable> dependency
container.Register<Consumer<IGenericPlugin<IDisposable>>>();

// Register open generic type with 6 dependencies.
container.RegisterOpenGeneric(typeof(IGenericPlugin<>),
typeof(GenericPluginWith6Dependencies<>));
```
Comments: Resolved with changeset 100311: Use of ResolveUnregisteredType event (that is primarily consumed by the RegisterOpenGeneric extension methods) could lead to incorrect 'Single Responsibility Violation' warnings in the Debugger Diagnostic view.

Edited Issue: RegisterOpenGeneric registrations incorrectly give SRP warning [19670]

dot_NET_Junkie — Sat, 04 May 2013 22:38:54 GMT

Created Issue: RegisterOpenGeneric registrations incorrectly give SRP warning [19670]

dot_NET_Junkie — Sat, 04 May 2013 22:38:53 GMT

Closed Issue: GetInstance works while GetAllInstances does not [19634]

dot_NET_Junkie — Wed, 24 Apr 2013 18:51:40 GMT

I'm getting an empty result set when I use GetAllInstances<T>() while making the same call GetInstance<T> I get one result (which is correct).

Not sure what to make of it, or how to present a sample code that will demonstrate the issue. Any suggestions in how to present that to you?
Comments: By design. Instances can only be resolved using GetAllInstances when they are registered using RegisterAll.

Commented Issue: GetInstance works while GetAllInstances does not [19634]

vtali — Wed, 24 Apr 2013 18:11:59 GMT

Thank you! I appreciate the response and the help. You need a donate button.

Commented Issue: GetInstance works while GetAllInstances does not [19634]

dot_NET_Junkie — Wed, 24 Apr 2013 17:38:55 GMT

You currently use the following registration:

```
container.RegisterManyForOpenGeneric(
typeof(IDomainEventHandler<>),
currentAssemblies);
```

this leads to a one-to-one mapping between of a closed IDomainEventHandler<T> version (the service type) and an implementation. The RegisterManyForOpenGeneric is a short cut for doing this:

```
container.Register<IDomainEventHandler<CustomerMoved>>, CustomerMovedEventHandler>();
container.Register<IDomainEventHandler<OrderShipped>>, OrderShippedEventHandler>();
container.Register<IDomainEventHandler<OrderCancelled>>, OrderCancelledEventHandler>();
// etc
```

In other words, when calling RegisterManyForOpenGeneric, this method simply calls Register(Type, Type) for you under the covers. Since there is a one-to-one mapping, you need to resolve an event handler as follows:

```
container.GetInstance<IDomainEventHandler<OrderCancelled>>();
```

Simple injector forces you to make an explicit choice between registering a collection, or a single instance. When your application contains multiple event handlers for the same event, the previous RegisterManyForOpenGeneric registration will simply throw an exception. It throws an exception just as doing this manually will throw an exception:

```
container.Register<IDomainEventHandler<OrderCancelled>>, MailCustomerOrderCancelledEventHandler>();
// Second registration on same type: simple injector throws an exception.
container.Register<IDomainEventHandler<OrderCancelled>>, InformShipperOrderCancelledEventHandler>();
```

In that case you will have to registering event types as collection, using the RegisterAll method in combination with one of the RegisterManyForOpenGeneric overloads:

```
container.RegisterManyForOpenGeneric(
typeof(ICommandHandler<>),
(service, impls) => container.RegisterAll(service, impls),
currentAssemblies);
```

Since the registration now happens using RegisterAll, you can now retrieve collections as follows:

```
var collection = container.GetAllInstances<IDomainEventHandler<OrderCancelled>>();
```

Commented Issue: GetInstance works while GetAllInstances does not [19634]

vtali — Wed, 24 Apr 2013 14:23:14 GMT

> var handlers = serviceLocator.GetAll<IDomainEventHandler<TDomainEvent>>();

Is my wrapper that calls this inside the method:

> current.GetAllInstances<T>();

Sorry for the confusion.

Commented Issue: GetInstance works while GetAllInstances does not [19634]

vtali — Wed, 24 Apr 2013 14:15:33 GMT

That's definitely the behavior I'm seeing and I didn't realize it. Here is the code that is making use of it:

public class DomainEvents : IDomainEvents
{
private readonly IServiceLocator serviceLocator;

public DomainEvents(IServiceLocator serviceLocator)
{
this.serviceLocator = serviceLocator;
}

public void Raise<TDomainEvent>(TDomainEvent domainEvent) where TDomainEvent : IDomainEvent
{
var handlers = serviceLocator.GetAll<IDomainEventHandler<TDomainEvent>>();
foreach (var eventHandler in handlers)
{
eventHandler.Handle(domainEvent);
}
}
}

What's the appropriate way of retrieving all the registrations of that service type?

Commented Issue: GetInstance works while GetAllInstances does not [19634]

dot_NET_Junkie — Wed, 24 Apr 2013 13:28:07 GMT

I don't see any registrations in your configuration that are made using one of the `RegisterAll<T>` overloads. Only registration made with one of these methods or using `Register<IEnumerable<Something>>` will be resolved when calling `GetAllInstances<T>`. The default behavior of Simple Injector is to return an empty collection when no collection is registered for the given T.

Commented Issue: GetInstance works while GetAllInstances does not [19634]

vtali — Wed, 24 Apr 2013 12:43:48 GMT

Definitely. Here's my App_Start.SimpleInjectorWebCommon class that registers all my services:

```
private static void RegisterServices(Container container)
{
var serviceLocatorResolver = new SimpleInjectorServiceLocator(container);
ServiceLocator.SetServiceLocator(() => serviceLocatorResolver);

var currentAssemblies = AppDomain.CurrentDomain.GetAssemblies();

// Validations
container.RegisterSingle<IValidator>(
new DataAnnotationsValidator(container));

// Command Validations
container.RegisterManyForOpenGeneric(
typeof(ICommandValidator<>), currentAssemblies);

container.RegisterSingleOpenGeneric(
typeof(ICommandValidator<>), typeof(CommandValidator<>));

// Events
container.RegisterManyForOpenGeneric(
typeof(IDomainEventHandler<>),
currentAssemblies
);

container.RegisterSingle(
typeof(IDomainEvents),
() => new DomainEvents(serviceLocatorResolver)
);

// authorizations
// register first concrete
container.RegisterManyForOpenGeneric(
typeof(ICommandAuthorize<>),
currentAssemblies);

// then those not yet registered, register with default
container.RegisterSingleOpenGeneric(
typeof(ICommandAuthorize<>),
typeof(CommandAuthorizeDefault<>));

// Db work factories
container.RegisterSingle<IUnitOfWorkFactory<CompaniesUnitOfWork>, CompaniesUnitOfWorkFactory>();

container.RegisterPerWebRequest<ICompanyContextResolver, SubDomainCompanyContextResolver>();

container.RegisterSingle<IUnitOfWorkFactory<PointsUnitOfWork>, PointsUnitOfWorkFactory>();

container.RegisterManyForOpenGeneric(
typeof(IQueryHandler<,>),
AppDomain.CurrentDomain.GetAssemblies());

container.RegisterSingle<IPasswordService, PasswordServiceSha256>();

// Command Handlers
container.RegisterManyForOpenGeneric(
typeof(ICommandHandler<>), currentAssemblies);

container.RegisterDecorator(
typeof(ICommandHandler<>),
typeof(ValidationCommandHandlerDecorator<>));

container.RegisterDecorator(
typeof(ICommandHandler<>),
typeof(TransactionCommandHandlerDecorator<>));

container.RegisterDecorator(
typeof(ICommandHandler<>),
typeof(AuthorizationCommandHandlerDecorator<>)
);

// Not needed yet
//container.RegisterDecorator(
// typeof(ICommandHandler<>),
// typeof(PerformanceTimerCommandHandlerDecorator<>));

container.RegisterMvcAttributeFilterProvider();
container.Verify();
}
```

Commented Issue: GetInstance works while GetAllInstances does not [19634]

dot_NET_Junkie — Wed, 24 Apr 2013 07:08:51 GMT

Can you show how your registration looks like?

Created Issue: GetInstance works while GetAllInstances does not [19634]

vtali — Wed, 24 Apr 2013 01:39:02 GMT

Edited Feature: Generate and compile collections more lazily [19601]

dot_NET_Junkie — Tue, 16 Apr 2013 15:36:23 GMT

When a collection is requested for the first time, the expression trees for all items are generated, the expressions intercepted and any possible decorator applied for each item in the collection. This can have a big impact on performance if the collection contains many items and all you need is to retrieve a single item of that collection (using the index of the collection's IList<T> implementation for instance).

Instead, the container should do this processing later, at the last responsible moment, which is when that item is requested for the first time. This gives pay-for-play behavior.

Of course this only applies when Container.Verify() was never called, because this ensures all collections are 'pre compiled'.

Created Feature: Generate and compile collections more lazily [19601]

dot_NET_Junkie — Tue, 16 Apr 2013 15:36:23 GMT

Commented Issue: NuGet SimpleInjector.Integration.Web: Use WebActivatorEx instead of WebActivator [19598]

dot_NET_Junkie — Mon, 15 Apr 2013 10:20:57 GMT

It is preferable to use the WebActivatorEx package over WebActivator since the latter is not signed.

The API's of both packages are the same.
Comments: ** Comment from web user: dot_NET_Junkie **

Here is a [related issue](https://simpleinjector.codeplex.com/workitem/19358) about this. Please read the comments.

The bottom line is, (from Simple Injector 2.0 and up) only the quick start packages contain a reference to the unsigned WebActivator. None of the shipped DLLs take a dependency on WebActivator. Replacing WebActivator with WebActivatorEx in those quick start packages will unfortunately cause a compile error. On the other hand, manually replacing WebActivator with WebActivatorEx is very easy to do and only a very few developers actually need to use a strongly signed version.

Because of this we decided to stick with the old WebActivator.

Created Issue: NuGet SimpleInjector.Integration.Web: Use WebActivatorEx instead of WebActivator [19598]

Sebazzz — Mon, 15 Apr 2013 09:22:58 GMT

It is preferable to use the WebActivatorEx package over WebActivator since the latter is not signed.

The API's of both packages are the same.

Closed Issue: Decorated collections are not verified correctly [19596]

dot_NET_Junkie — Sat, 13 Apr 2013 13:42:58 GMT

When the Container.Verify() method is called it iterates the initial registered collection, but not the actual collection that will be returned by the container. This differs when decorators are applied to the collection. In other words, Verify() does not check the creation of the decorators (and their dependencies), but only the original types.
Comments: Resolved with changeset 99944: Bug fix: Verify only checked the original registration of collections and not whether the final collection (that could be intercepted and decorated) worked as expected.

Edited Issue: Decorated collections are not verified correctly [19596]

dot_NET_Junkie — Sat, 13 Apr 2013 13:41:52 GMT

Created Issue: Decorated collections are not verified correctly [19596]

dot_NET_Junkie — Sat, 13 Apr 2013 13:41:51 GMT

Commented Feature: Make container controlled collections indexible [19575]

dot_NET_Junkie — Fri, 12 Apr 2013 14:42:46 GMT

Container controlled collections are collections with items that are created and controlled by the container. The following is an example of a registration of a container controlled collection:

``` c#
container.RegisterAll<ILogger>(typeof(DbLogger), typeof(FileLogger));
```

Compared to the following registration of an uncontrolled collection:

``` c#
IEnumerable<ILogger> loggers = GetLoggers();
container.RegisterAll<ILogger>(loggers);
```

Container controlled collections have known size and the order of the items is deterministic (which is the same order as they are registered), while uncontrolled collections could change during the lifetime of the application.

Retrieving a certain element of the list using a controlled collection however is an O(n) operation and forces the creation of all other elements in the list. For instance:

``` c#
var loggers = container.GetAllInstances<ILogger>();
var logger = loggers.Skip(1).First();
```
This forces the creation of the of the first item in the list as well. This is probable not a problem for a list of a few items (especially when they're singletons), but will hinder performance when applied to a big list of types. For instance:

``` c#
var types = (
from type in Assembly.GetExecutingAssembly().GetExportedTypes()
where typeof(IController).IsAssignableFrom(type)
where !type.IsAbstract
select type)
.ToList();

container.RegisterAll<IController>(types);

// By registering all controllers in a collection instead of by their
// concrete type, we can apply decorators to those controllers.
container.RegisterDecorator(typeof(IController),
typeof(ValidationControllerDecorator));

// Inside a custom controller factory
var set = types.ToDictionary(t => t, t => types.IndexOf(t));

var controllers = container.GetAllInstances<IController>();

int index = set[typeof(HomeController)];

// This line currently throws an exception since IList<T> is not
// implemented, which disallows resolving a single item from the list.
return ((IList<IController>)controllers)[index];
```
Comments: Associated with changeset 99911: Bug fix. The set_Item (indexer) of DecoratableEnumerable did not throw an exception but failed silently.