How to build a graph of resolved instances with Autofac?
After all registrations, I am doing ContainerBuilder.RegisterCallback and subscribing to all IComponentRegistration.Preparing and IComponentRegistration.Activating events to be able to handle all activations. With this two events I am able to build a tree, the order of events looks like this:
- Preparing: Root
- Preparing: FirstLevel_A
- Activating: FirstLevel_A
- Preparing: FirstLevel_B
- Preparing: SecondLevel_C
- Activating: SecondLevel_C
- Activating: FirstLevel_B
- Activating: Root
But what if some registrations are not Per Dependency and I will have a graph instead of a tree. Is it possible to handle this case?
c# autofac graph-theory ioc-container
asked Nov 15 '18 at 11:39
astefastef
3,44432758
add a comment |
After all registrations, I am doing ContainerBuilder.RegisterCallback and subscribing to all IComponentRegistration.Preparing and IComponentRegistration.Activating events to be able to handle all activations. With this two events I am able to build a tree, the order of events looks like this:
- Preparing: Root
- Preparing: FirstLevel_A
- Activating: FirstLevel_A
- Preparing: FirstLevel_B
- Preparing: SecondLevel_C
- Activating: SecondLevel_C
- Activating: FirstLevel_B
- Activating: Root
But what if some registrations are not Per Dependency and I will have a graph instead of a tree. Is it possible to handle this case?
c# autofac graph-theory ioc-container
asked Nov 15 '18 at 11:39
astefastef
3,44432758
I want to build something like "execution plan" on initialResolvecall and then propose a user to execute it (call a method) or not. I don't want to model this behavior in all components I have in a container, looking for a fast solution.
– astef
Nov 15 '18 at 11:43
I know there are few assumptions involved: should be no side effects in constructors/destructors (it's ok); some dependencies can be misleading (I'm hiding them). But in general it should work, except this case in question
– astef
Nov 15 '18 at 11:46
add a comment |
After all registrations, I am doing ContainerBuilder.RegisterCallback and subscribing to all IComponentRegistration.Preparing and IComponentRegistration.Activating events to be able to handle all activations. With this two events I am able to build a tree, the order of events looks like this:
- Preparing: Root
- Preparing: FirstLevel_A
- Activating: FirstLevel_A
- Preparing: FirstLevel_B
- Preparing: SecondLevel_C
- Activating: SecondLevel_C
- Activating: FirstLevel_B
- Activating: Root
But what if some registrations are not Per Dependency and I will have a graph instead of a tree. Is it possible to handle this case?
c# autofac graph-theory ioc-container
asked Nov 15 '18 at 11:39
astefastef
3,44432758
After all registrations, I am doing ContainerBuilder.RegisterCallback and subscribing to all IComponentRegistration.Preparing and IComponentRegistration.Activating events to be able to handle all activations. With this two events I am able to build a tree, the order of events looks like this:
- Preparing: Root
- Preparing: FirstLevel_A
- Activating: FirstLevel_A
- Preparing: FirstLevel_B
- Preparing: SecondLevel_C
- Activating: SecondLevel_C
- Activating: FirstLevel_B
- Activating: Root
But what if some registrations are not Per Dependency and I will have a graph instead of a tree. Is it possible to handle this case?
c# autofac graph-theory ioc-container
c# autofac graph-theory ioc-container
asked Nov 15 '18 at 11:39
astefastef
3,44432758
asked Nov 15 '18 at 11:39
astefastef
3,44432758
asked Nov 15 '18 at 11:39
astefastef
3,44432758
asked Nov 15 '18 at 11:39
astefastef
3,44432758
asked Nov 15 '18 at 11:39
astefastef
3,44432758
3,44432758
I want to build something like "execution plan" on initialResolvecall and then propose a user to execute it (call a method) or not. I don't want to model this behavior in all components I have in a container, looking for a fast solution.
– astef
Nov 15 '18 at 11:43
I know there are few assumptions involved: should be no side effects in constructors/destructors (it's ok); some dependencies can be misleading (I'm hiding them). But in general it should work, except this case in question
– astef
Nov 15 '18 at 11:46
add a comment |
I want to build something like "execution plan" on initialResolvecall and then propose a user to execute it (call a method) or not. I don't want to model this behavior in all components I have in a container, looking for a fast solution.
– astef
Nov 15 '18 at 11:43
I know there are few assumptions involved: should be no side effects in constructors/destructors (it's ok); some dependencies can be misleading (I'm hiding them). But in general it should work, except this case in question
– astef
Nov 15 '18 at 11:46
I want to build something like "execution plan" on initial
Resolve call and then propose a user to execute it (call a method) or not. I don't want to model this behavior in all components I have in a container, looking for a fast solution.– astef
Nov 15 '18 at 11:43
I want to build something like "execution plan" on initial
Resolve call and then propose a user to execute it (call a method) or not. I don't want to model this behavior in all components I have in a container, looking for a fast solution.– astef
Nov 15 '18 at 11:43
I know there are few assumptions involved: should be no side effects in constructors/destructors (it's ok); some dependencies can be misleading (I'm hiding them). But in general it should work, except this case in question
– astef
Nov 15 '18 at 11:46
I know there are few assumptions involved: should be no side effects in constructors/destructors (it's ok); some dependencies can be misleading (I'm hiding them). But in general it should work, except this case in question
– astef
Nov 15 '18 at 11:46
add a comment |
2 Answers
2
active
oldest
votes
Not an answer, but it is too big for a comment.
AutoFac is a great IoC container, but it has 2 major problems. One is the awful registration API and the other one is a complete lack of diagnostics. The original author of AutoFac once tried to create an application that would help with this: Whitebox. The development has stopped and moved on to Autofac Analysis, that hasn't been active in years.
What you want to do requires a lot of insight into the inner workings of AutoFac, so you might want to check out the sources for ideas on how to accomplish what you need.
answered Nov 15 '18 at 11:56
JeroenJeroen
726521
add a comment |
According to this answer there's another way of handling these events:
If you want to get fancier, you can set up some event handlers on the
containerChildLifetimeScopeBeginning,ResolveOperationBeginning,
ResolveOperationEnding, andCurrentScopeEndingevents.
During
ChildLifetimeScopeBeginningyou'd need to set up something to
automatically attach to any child lifetimeResolveOperationBeginning
events.
During
ResolveOperationBeginningyou'd log what is going to be
resolved.
During
ResolveOperationEndingyou'd log any exceptions
coming out.
During
CurrentScopeEndingyou'd need to unsubscribe from
any events on that scope so the garbage collector can clean up the
lifetime scope with all of its instances.
It's harder, but should do the job.
answered Nov 15 '18 at 12:07
astefastef
3,44432758
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53318662%2fhow-to-build-a-graph-of-resolved-instances-with-autofac%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
Not an answer, but it is too big for a comment.
AutoFac is a great IoC container, but it has 2 major problems. One is the awful registration API and the other one is a complete lack of diagnostics. The original author of AutoFac once tried to create an application that would help with this: Whitebox. The development has stopped and moved on to Autofac Analysis, that hasn't been active in years.
What you want to do requires a lot of insight into the inner workings of AutoFac, so you might want to check out the sources for ideas on how to accomplish what you need.
answered Nov 15 '18 at 11:56
JeroenJeroen
726521
add a comment |
Not an answer, but it is too big for a comment.
AutoFac is a great IoC container, but it has 2 major problems. One is the awful registration API and the other one is a complete lack of diagnostics. The original author of AutoFac once tried to create an application that would help with this: Whitebox. The development has stopped and moved on to Autofac Analysis, that hasn't been active in years.
What you want to do requires a lot of insight into the inner workings of AutoFac, so you might want to check out the sources for ideas on how to accomplish what you need.
answered Nov 15 '18 at 11:56
JeroenJeroen
726521
add a comment |
Not an answer, but it is too big for a comment.
AutoFac is a great IoC container, but it has 2 major problems. One is the awful registration API and the other one is a complete lack of diagnostics. The original author of AutoFac once tried to create an application that would help with this: Whitebox. The development has stopped and moved on to Autofac Analysis, that hasn't been active in years.
What you want to do requires a lot of insight into the inner workings of AutoFac, so you might want to check out the sources for ideas on how to accomplish what you need.
answered Nov 15 '18 at 11:56
JeroenJeroen
726521
Not an answer, but it is too big for a comment.
AutoFac is a great IoC container, but it has 2 major problems. One is the awful registration API and the other one is a complete lack of diagnostics. The original author of AutoFac once tried to create an application that would help with this: Whitebox. The development has stopped and moved on to Autofac Analysis, that hasn't been active in years.
What you want to do requires a lot of insight into the inner workings of AutoFac, so you might want to check out the sources for ideas on how to accomplish what you need.
answered Nov 15 '18 at 11:56
JeroenJeroen
726521
answered Nov 15 '18 at 11:56
JeroenJeroen
726521
answered Nov 15 '18 at 11:56
JeroenJeroen
726521
answered Nov 15 '18 at 11:56
JeroenJeroen
726521
726521
add a comment |
add a comment |
According to this answer there's another way of handling these events:
If you want to get fancier, you can set up some event handlers on the
containerChildLifetimeScopeBeginning,ResolveOperationBeginning,
ResolveOperationEnding, andCurrentScopeEndingevents.
During
ChildLifetimeScopeBeginningyou'd need to set up something to
automatically attach to any child lifetimeResolveOperationBeginning
events.
During
ResolveOperationBeginningyou'd log what is going to be
resolved.
During
ResolveOperationEndingyou'd log any exceptions
coming out.
During
CurrentScopeEndingyou'd need to unsubscribe from
any events on that scope so the garbage collector can clean up the
lifetime scope with all of its instances.
It's harder, but should do the job.
answered Nov 15 '18 at 12:07
astefastef
3,44432758
add a comment |
According to this answer there's another way of handling these events:
If you want to get fancier, you can set up some event handlers on the
containerChildLifetimeScopeBeginning,ResolveOperationBeginning,
ResolveOperationEnding, andCurrentScopeEndingevents.
During
ChildLifetimeScopeBeginningyou'd need to set up something to
automatically attach to any child lifetimeResolveOperationBeginning
events.
During
ResolveOperationBeginningyou'd log what is going to be
resolved.
During
ResolveOperationEndingyou'd log any exceptions
coming out.
During
CurrentScopeEndingyou'd need to unsubscribe from
any events on that scope so the garbage collector can clean up the
lifetime scope with all of its instances.
It's harder, but should do the job.
answered Nov 15 '18 at 12:07
astefastef
3,44432758
add a comment |
According to this answer there's another way of handling these events:
If you want to get fancier, you can set up some event handlers on the
containerChildLifetimeScopeBeginning,ResolveOperationBeginning,
ResolveOperationEnding, andCurrentScopeEndingevents.
During
ChildLifetimeScopeBeginningyou'd need to set up something to
automatically attach to any child lifetimeResolveOperationBeginning
events.
During
ResolveOperationBeginningyou'd log what is going to be
resolved.
During
ResolveOperationEndingyou'd log any exceptions
coming out.
During
CurrentScopeEndingyou'd need to unsubscribe from
any events on that scope so the garbage collector can clean up the
lifetime scope with all of its instances.
It's harder, but should do the job.
answered Nov 15 '18 at 12:07
astefastef
3,44432758
According to this answer there's another way of handling these events:
If you want to get fancier, you can set up some event handlers on the
containerChildLifetimeScopeBeginning,ResolveOperationBeginning,
ResolveOperationEnding, andCurrentScopeEndingevents.
During
ChildLifetimeScopeBeginningyou'd need to set up something to
automatically attach to any child lifetimeResolveOperationBeginning
events.
During
ResolveOperationBeginningyou'd log what is going to be
resolved.
During
ResolveOperationEndingyou'd log any exceptions
coming out.
During
CurrentScopeEndingyou'd need to unsubscribe from
any events on that scope so the garbage collector can clean up the
lifetime scope with all of its instances.
It's harder, but should do the job.
answered Nov 15 '18 at 12:07
astefastef
3,44432758
answered Nov 15 '18 at 12:07
astefastef
3,44432758
answered Nov 15 '18 at 12:07
astefastef
3,44432758
answered Nov 15 '18 at 12:07
astefastef
3,44432758
3,44432758
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53318662%2fhow-to-build-a-graph-of-resolved-instances-with-autofac%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
I want to build something like "execution plan" on initial
Resolvecall and then propose a user to execute it (call a method) or not. I don't want to model this behavior in all components I have in a container, looking for a fast solution.– astef
Nov 15 '18 at 11:43
I know there are few assumptions involved: should be no side effects in constructors/destructors (it's ok); some dependencies can be misleading (I'm hiding them). But in general it should work, except this case in question
– astef
Nov 15 '18 at 11:46