The use of Action<...> instead of Expression<Action<...>> in the public API causes a variety of problems

[stakx]

Action<TMock, ...>s are used instead of Expression<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 called FluentMockContext, 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 FluentMockContext to execute the setup "expression" in order to install the inner mocks relationships and set up all properties on the inner mocks. (These are actually unrelated to this and are now being tracked in #643.)

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 Func<> or Action<> also means that matchers cannot properly work. (Don't know what I was thinking, this is a non sequitur.)

The use of FluentMockContext also causes the following problem(s) which aren't about recursive mocks:

• SetupSet problems with It.IsAny<> and indexer properties #218 - SetupSet problems with It.IsAny<> and indexer properties
• VerifySet fails on non-trivial property setter #430 - VerifySet fails on non-trivial property setter
• Use of SetupSet 'forgets' Method Setup #432 - Use of SetupSet 'forgets' Method Setup
• Heisenberg's virtual property set in ctor with MockBehavior.Strict and VerifyAll #456 - Heisenberg's virtual property set in ctor with MockBehavior.Strict and VerifyAll

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:

• Make matchers (It.Is…) work.
• Avoid setting up more properties than necessary.
• Avoid overriding existing setups.
• Improve Moq performance by avoiding expensive expression tree compilation.

[stakx]

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:

• Make matchers (It.Is…) work.
• [...]
• Improve Moq performance by avoiding expensive expression tree compilation.

The best solution to reach those goals would be for C# to support assignments in expression tree lambdas. See dotnet/csharplang#158 (comment).

[stakx]

As much as I would love to see all of these bugs fixed, this isn't actually possible unless either...

• the Roslyn (C# and VB.NET) compilers start supporting assignments in LINQ expression trees; or
• Moq switches from method compilation to method decompilation, which would mean that a very robust method decompiler must be implemented, which is unlikely to be practical so shortly before Moq 5.

I will keep tracking dotnet/csharplang#158 (comment), but in the meantime I am closing this issue since unfortunately there's nothing much that we can do about these bugs. 😢