Relax dependency on Moq

[jnyrup]

#84 upgraded the dependency on Moq from 4.8.0 to 4.20.72 (the latest version).

That fixed #82 because Moq 4.8.0 depends on Caste.Core 4.2.1, which targets. NETStandard.Library 1.6.1.
The dependency on NETStandard.Library 1.6.1 is what raises the two warnings for the CVE's listed in #82.

As mentioned in #82 upgrading Moq to version 4.18.0 is sufficient to fix the warnings.
Moq 4.18.0 depends on Castle.Core 5.0.0, which added targets for .NETStandard 2.0, .NETStandard 2.1 and .NET 6.0.

As you might be familiar with, there has been some controversies around Moq 4.20, since it introduced a mechanism (SponsorLink) to check if users were sponsoring the Moq project.

Therefore I'm asking if it would be possible to relax the dependency on Moq from 4.20.72 and down to 4.18.4, which is the version right before SponsorLink was introduced.

cc @kkoynov @Catlandor

[ramantsitou]

Hello @jnyrup.
Thanks for the detailed analysis and for raising this concern — this topic is genuinely important to me as a maintainer.

I agree that Moq 4.18.x represents a reasonable and safe baseline for users who want to avoid the recent controversy, while still addressing the original warnings. At the same time, I’m hesitant to simply roll back the dependency for everyone, as there are already users who rely on compatibility with the latest Moq versions. A forced downgrade would likely cause frustration on the other side.

The approach I currently see as the most balanced is to maintain parallel variants of the library: one with full support for Moq 4.18.x, and another that continues to track the latest Moq releases. This would give users an explicit and convenient choice, instead of pushing a single decision onto all of them.

That said, this approach does require additional effort in terms of design, testing, releases, and ongoing maintenance.

I maintain this project in my spare time, so timelines can be unpredictable. If this change is particularly important for you or your organization and you would like to see it prioritized, supporting the project via a donation or sponsorship would help me dedicate focused time to implement and maintain this setup. There is no paywall here — the issue itself is valid regardless — sponsorship would simply affect prioritization and lead time.

I’m happy to hear your thoughts on this approach, and whether a clearly separated Moq 4.18.x–compatible variant would meet your needs.

[jnyrup]

Thank you for getting back to me.

Maintaining two separate versions of this library certainly doesn't seem like fair use of your spare time.

I tried lowering the version of Moq in MockQueryable.Moq.csproj to 4.18.4, while bumping it to the newest version in MockQueryable.Sample.csproj and all your unit tests passed.

I then compared the public APIs of 4.18.4 and 4.20.72 and the latter is a strict superset of the former.
So from an API perspective it should be possible for users relying on one of those few new APIs to manually bump Moq in their project to 4.20.72.

This path is of course only valid until Moq introduces an API breaking change but comparing with older APIs, it seems there haven't been breaking API changes since 4.10.0 released back in 2018-09-08.

moq_comp.cs

#:package DiffPlex@1.9.0
#:package Moq@4.18.4
#:package PublicApiGenerator@11.5.4

using PublicApiGenerator;

ApiGeneratorOptions options = new()
{
    ExcludeAttributes = [typeof(ObsoleteAttribute).FullName!],
    IncludeAssemblyAttributes = false
};

var assembly = typeof(Moq.Mock).Assembly;

var publicApi = assembly.GeneratePublicApi(options);
File.WriteAllText($"moq{assembly.GetName().Version}.txt", publicApi);

dotnet run moq_comp.cs

// change version number from 4.18.4 to 4.20.72

dotnet run moq_comp.cs

diff -d --color=always moq4.18.0.0.txt moq4.20.72.0.txt

362a363
>         public System.Threading.Tasks.Task RaiseAsync(System.Action<T> eventExpression, params object[] args) { }
386a388
>         public void Verify<TResult>(System.Linq.Expressions.Expression<System.Func<T, TResult>> expression, System.Func<Moq.Times> times, string failMessage) { }
470a473,474
>         public static Moq.Language.Flow.IReturnsResult<TMock> ThrowsAsync<TMock>(this Moq.Language.IReturns<TMock, System.Threading.Tasks.ValueTask> mock, System.Exception exception)
>             where TMock :  class { }
764a769,770
>         void Verifiable(Moq.Times times);
>         void Verifiable(System.Func<Moq.Times> times);
765a772,773
>         void Verifiable(Moq.Times times, string failMessage);
>         void Verifiable(System.Func<Moq.Times> times, string failMessage);