UPDATE:
This is definitely a bug in the current release. This somehow slipped through the unit testing cracks. The code misses a check that verifies whether a built closed generic implementation actually implements the requested closed generic service type. If all the generic type constraints are valid, the framework considers the resolution successful, which is incorrect in your case.
The fix is rather easy and the coming v2.4 will definitely fix this, but in the meantime, you'll have to with the following workaround.
UPDATE 2:
The is actually quite nasty and can be quite hard to workaround in some cases. Besides RegisterOpenGeneric, decorator registrations are affected as well. This made me conclude that this had to be fixed fast and can't wait till the next minor release. I therefore pushed Version 2.3.6 to NuGet and CodePlex. v2.3.6 fixes this issue.
WORKAROUND:
The workaround is to prevent supplying generic type arguments that are nested into other types (such as your DeleteBaseCommand<TModel>
). Instead you can fall back to using generic type constraints instead, as can be seen in the following example:
public class CreateCommandBaseHandler<TCommand, TModel>
: ICommandHandler<TCommand, TModel> // no nested generic arguments here
where TCommand : CreateBaseCommand<TModel> // but type constraint here.
{
public TModel Handle(TCommand command)
{
// create the thing
return default(TModel);
}
}
public class DeleteCommandBaseHandler<TCommand, TModel>
: ICommandHandler<TCommand, TModel>
where TCommand : DeleteBaseCommand<TModel>
{
public TModel Handle(TCommand command)
{
// delete the thing
return default(TModel);
}
}