Ninject provider can't resolve types registered within a named scope -

i using namedscoped ninject extension in attempt create object graphs constructed everytime command handler constructed container. in other words, want fresh object graph every command might processed corresponding handler.

i have used .definesnamedscope("toplevelorhcestrator") binding when registering "command handlers" top level command processing.

a type in named scope needs injected result of method call on type registered in named scope. thought best way ninject provider. inside provider attempt resolve type in hopes can call method on pass object creating within named scope. problem i'm having when ask icontext instance inside customer provider exception says "no matching scopes available, , type declared innamedscope(toplevelorchestrator).

context.kernel.get<typealreadyregisteredinscope>().methodthatgetsanotherdependency() 

is possible types container inside ninject provider when registered inside named scope?

edit

i apologize if use case seems bit odd, experimenting ideas how manage units of work , other services/managers may need handle uow complete business usecase. know common unit of work "started" , passed dependencies may need take part in larger process. thinking i'd rather let orchestrator take unit of work factory deterministically destroy uow , clear owner of usecase is. supplied managers/services proxy unit of work null until real unit of work started orchestrator. that's why attempting link proxy registered type in provider. experimental @ point , testing ideas.

i'd happy hear further thoughts.

for methodthatgetsanotherdependency() able .get<>() instance bound .innamedscope(...) need add context preservation extension.

this because namedscope adding parameter request context of binding has .definesnamedscope(...). request over, context , it's parameters forgotten. contextpreservation extension context kept , reused late / factory creations (func<>, interface factory .tofactory() binding...). think should work providers. if not, switch factory instead of provider.

however have admit don't understand why/what trying achieve. there might simpler ways.