Alistair Evans

It appears to me as though you were circumventing an accidental loophole in our "Containers are Immutable" rule, that appears to have been closed as of 6.0. Internally, the first...

The singleton behaviour is expected and makes sense if you think about it; you can't have components in an outer scope that depend on services only defined inside an inner...

I'm afraid I can't think of a way to make this work precisely the way you need it. Lifetime Scopes are the way to go for this sort of functionality,...

@tillig, did you mean to link to the Stack Overflow question? Anyway, this is a tricky one. The matching lifetime scope tag is specifically for the scope selection behaviour when...

Yeah, I can see how that's pretty broken. I don't think we can just leave this as a permanent known issue (or deprecate matching scopes), but I'm hoping we can...

As @tillig said, a bunch has changed since then. 2x slower sounds like a lot, but in fairness we don't really benchmark container build times, we try to optimise in...

Thinking about this, diagnostics are attached after the container is built, however AutoActivated components are resolved before the Build method returns. So I can see the problem. To trace them,...

Ouch, that workaround seems painful. I've got an idea in my head of a simpler workaround that means you can still use `AutoActivate`; I'll put it down on paper (so...

Ok, so I have a workaround; it's not ideal, but it'll work consistently while keeping the AutoActivate behaviour. Basically, you need this method somewhere: ```csharp private void AddAutoActivatingTracer(ContainerBuilder builder, DiagnosticTracerBase...

There's probably an argument for it either way; regardless it would be a breaking change to change the point at which the event fires. Perhaps a better option is just...