The use of Action<...>
instead of Expression<Action<...>>
in the public API causes a variety of problems
#414
Labels
Action<...>
instead of Expression<Action<...>>
in the public API causes a variety of problems
#414
Action<TMock, ...>
s are used instead ofExpression<Action<TMock, ...>>
because the compiler doesn't support e.g. assignments in expression tree lambdas. Moq solves this by then executing the setup action "expression" in some kind of dry-run mode and observing the side effects caused. The internal component used for this trickery is calledFluentMockContext
, and because it's basically an incomplete workaround around a missing language feature, it causes a variety of problems.Many of them are related to recursive mocks setup: [...] At least in some cases, it seems probable that these issues could be caused by the (internal) use of(These are actually unrelated to this and are now being tracked in #643.)FluentMockContext
to execute the setup "expression" in order to install the inner mocks relationships and set up all properties on the inner mocks.In order for the setup expression to be executable, its expression tree must be compiled (which btw. in #188 is given as the main reason for Moq's bad performance on 64-bit .NET). Compiling an expression tree to a regular(Don't know what I was thinking, this is a non sequitur.)Func<>
orAction<>
also means that matchers cannot properly work.The use of
FluentMockContext
also causes the following problem(s) which aren't about recursive mocks:I'm closing the above issues in favor of this one.
It might be a good idea to replace the use of
FluentMockContext
to "dry-run" setup expressions and instead do proper analysis of the expression trees, wherever possible. The potential advantages are:It.Is…
) work.The text was updated successfully, but these errors were encountered: