Update MoqVersion to latest

[Youssef1313]

This version of Moq is extremely old.

During the test run of Microsoft.AspNetCore.Mvc.TagHelpers.Test, I see lots of threadpool threads getting blocked:

This doesn't sound good, and might be cause of some of the flakiness we get.

Let's hope that the newer versions of Moq/Castle.Core are doing better job at not blocking threads.

[Copilot]

Pull request overview

Updates the centrally-managed Moq dependency version used across the repo’s test builds (via custom <Reference>→<PackageReference> resolution), aiming to pick up fixes/improvements from a much newer Moq release.

Changes:

• Bump MoqVersion from 4.10.0 to 4.20.72.

[wtgodbe]

Looks like there might be some reaction needed in some of the MVC tests (Microsoft.AspNetCore.Mvc.ModelBinding.Validation.DefaultObjectValidatorTests.Validate_ComplexType_IValidatableObject_CanUseRequestServices, for example):

Moq.MockException : Mock<DefaultObjectValidatorTests.IExampleService:1>:
This mock failed verification due to the following:

DefaultObjectValidatorTests.IExampleService x => x.DoSomething():
This setup was not matched.

[Youssef1313]

This test passes a mock for validation, and it's now failing the validation. I think the difference might be around this:

I will need to dig further next Monday. But my feeling is that the test should simply avoid passing Mock<T>.Object if the validation logic goes to deep into that object and is surfacing implementation details of Moq (I assume the validation logic tries to do deep validation with reflection). Instead of creating a Mock<IValidatableObject> with Moq, the test could simply just create class MockedValidatableObject : IValidatableObject.

[Youssef1313]

The path how we get there:

• Validation of Mock<IValidatableObject>.Object visits the object. It's seen as complex type, so we visit complex type with DefaultComplexObjectValidationStrategy.Instance.
• Note that the Mock<T>.Object is IMocked<T> and has a Mock property that seems to refer back to the original Mock<IValidatableObject>.
• We visit the children, and specifically the Mock<T> (coming through the Mock property).
• We visit the children of that, and Mock.Setups (SetupCollection) is one of those.
• The setup collection passes the IsEnumerableType check so we call into VisitComplexType(DefaultCollectionValidationStrategy.Instance).
• We then visit Setups[0] which is Moq.MethodCall representing the single setup that the test adds (x => x.Validate(It.IsAny<ValidationContext>())).
• The MethodCall is complex type that we visit and then validate its children.
• InnerMock is one of those children that we visit.
• The InnerMock appears to be null - and fails RequiredAttribute validation.

The reason we validate against ReuiqredAttribute in this case is that it's inferred via nullability annotations. So, IsRequired implementation returns true, then addInferredRequiredAttribute is true and then we fakely add RequiredAttribute instance.

As you see, the validation result can be highly impacted by the implementation details of Moq and we should avoid that in the test altogether, IMO. Meanwhile, devlooped/moq#1672

[Youssef1313]

We're still suffering from threadpool starvation, I think, but the update still feels like a good step forward.

We should still, IMO, find ways to improve this. That might require changes on Moq/Castle sides (castleproject/Core#743). Or alternatively, we try to simply reduce our usage of Moq whenever possible.