Dominique Schuppli

**P.S.** regarding my above comment: > [...] but I found out that this would break long-standing, specified behavior, so I opted to close that issue without acting on it. [...]...

**Note to self:** Making this change ("mocks own setups, not other mocks") is likely a prerequisite for doing behavior-driven setups (#1002) properly; the reason being that we currently have different...

@killergege, hard to say what's going on with a full minimal repro. Perhaps post such a one (preferably in a separate issue).

Except those setups aren't truly identical. The question here is when captured variables should be resolved to their values: at the time when the setup is created vs. when an...

Thanks for your interest in working on this! I haven't finished looking through all of your PR, however my first impression is that this exposes far too many Moq internals...

> I can also confirm that with these rather crude changes, we are now able to plug in our own proxy generator, and by utilizing Cecil, we have managed to...

@siprbaum, thanks for asking! > ``` csharp > childMock.Setup(c => c.Property).Returns("some value").Verifiable(); > parentMock.Setup(p => p.Child).Returns(childMock.Object); > > parentMock.Verify(); > ``` > > Would this also do the recursive verfication...

@kzu, thanks for chiming in. I would love to hear how you originally intended (recursive) verification to work, or (if that differs) how you think it should operate now. Without...

@kzu > My intuition is that in general, recursive setups are "owned" by the mock you perform them on[.] Agreed 💯, a recursive setup like `mock.Setup(m => m.Foo.Bar)` should be...

Oh yes, by all means, don't add `MockRepository` to v5 if it wasn't planned anyway. I only mentioned it in the context of v4 because it lends itself quite well...