Reconsider using Moq in testing

[GerardSmit]

I'm not sure if .NET is aware of the current situation with Moq, but they've added a analyzer in version 4.20 that asks the developer in the IDE through warnings to support the project through an external closed-source library "SponsorLink".

This is done by checking if you're a sponsor of the GitHub maintainer by getting the hash of the developer, and checking through an infrastructure that is unknown by the public. If you're not an supporter, the first time the build is delayed by 1 second, then by 100ms (so you read the message).

This means the analyzer does the following:

1. Get the e-mail from your computer
2. Hash the e-mail and send it to an unknown server
   Note: As noted by other people this could also be an GDPR issue...
3. Write and read files to check if you already seen the message
   Note: This had a bug in Mac/Linux (see https://github.com/moq/moq/issues/1369) which caused the build to fail...
4. Add an warning to the error list and delay the build
   Note: If WarnAsError is enabled, you'll get an error instead.

An .NET/Roslyn maintainer (@sharwell) already reached out 4 months ago to the developer that this should not be done through analyzers: devlooped/SponsorLink#10, but this was ignored.

Moq is used by the testing infrastructure (this can be checked here: https://github.com/search?q=repo%3Adotnet%2Fruntime+language%3AXML+Moq&type=code). The used version, 4.18.4, does not include SponsorLink. Version 4.20 or higher is affected.

For more information, see the active issue: https://github.com/moq/moq/issues/1372

An example of SponsorLink blocking the build:

More information about SponsorLink can be found here: https://github.com/devlooped/SponsorLink/

[Atulin]

Crazy that it weaseled its way even into the very .NET Runtime repo

Tagging subscribers to this area: @dotnet/area-meta
See info in area-owners.md if you want to be subscribed.

Issue Details

---

I'm not sure if .NET is aware of the current situation with Moq, but they've added a analyzer in version 4.20 that asks the developer in the IDE through warnings to support the project through an external closed-source library "SponsorLink".

This is done by checking if you're a sponsor of the GitHub maintainer by getting the hash of the developer, and checking through an infrastructure that is unknown by the public. If you're not an supporter, the first time the build is delayed by 1 second, then by 100ms (so you read the message).

This means the analyzer does the following:

1. Get the e-mail from your computer
2. Hash the e-mail and send it to an unknown server
   Note: As noted by other people this could also be an GDPR issue...
3. Write and read files to check if you already seen the message
   Note: This had a bug in Mac/Linux (see https://github.com/moq/moq/issues/1369) which caused the build to fail...
4. Add an warning to the error list and delay the build
   Note: If WarnAsError is enabled, you'll get an error instead.

An .NET/Roslyn maintainer (@sharwell) already reached out 4 months ago to the developer that this should not be done through analyzers: devlooped/SponsorLink#10, but this was ignored.

Moq is used by the testing infrastructure (this can be checked here: https://github.com/search?q=repo%3Adotnet%2Fruntime+language%3AXML+Moq&type=code). The used version, 4.18.4, does not include SponsorLink. Version 4.20 or higher is affected.

For more information, see the active issue: https://github.com/moq/moq/issues/1372

An example of SponsorLink blocking the build:

More information about SponsorLink can be found here: https://github.com/devlooped/SponsorLink/

Author:	GerardSmit
Assignees:	-
Labels:	area-Meta, untriaged
Milestone:	-

[Joe4evr]

4. Add an warning to the error list and delay the build
Note: If WarnAsError is enabled, you'll get an error instead.

Additionally, According to Nick Craver, your build will be broken by WarnAsError even if you're a sponsor.

[MichaelKetting]

There is a follow-up discussion here: https://github.com/moq/moq/issues/1374

Apperently, the change is going to get reverted in v4.20.2. What it means for longterm viability of Moq, I cannot say. Am lookng forward to seeing how the dotnet team is going to handle this.

For background information:
For me, I'm considering a fork of Moq in the event that the project is no longer considered trustworthy since we only recently completed a migration from RhinoMocks to Moq and I am not interested in spending another several hundred hours doing another migration. Originally, I chose this Moq library because it's a) used by Microsoft and b) has a syntax more compatible with what Rhino.Mocks offered as compared to FakeIt.Easy.

[samtrion]

Apperently, the change is going to get reverted in v4.20.2. What it means for longterm viability of Moq, I cannot say. Am lookng forward to seeing how the dotnet team is going to handle this.

The reverted version 4.20.2 is unfortunately only cosmetic. The reference and functionality remains in MOQ.

[kzu]

@samtrion that is false. The reference is gone, and the analyzer is no longer packed with 4.20.2.

Points 1 and 2 will be addressed when it's reintroduced: will most likely just use a GUID.

[RonSijm]

Apperently, the change is going to get reverted in v4.20.2. What it means for longterm viability of Moq, I cannot say. Am lookng forward to seeing how the dotnet team is going to handle this.

They removed the package reference due to compatibility changes with Mac and Linux - not because of community feedback

@samtrion that is false. The reference is gone, and the analyzer is no longer packed with 4.20.2.

Points 1 and 2 will be addressed when it's reintroduced: will most likely just use a GUID.

...

reintroduced

Doesn't sound like they intent do remove it entirely ಠ_ಠ

[karl-sjogren]

Points 1 and 2 will be addressed when it's reintroduced: will most likely just use a GUID.

...

reintroduced

Doesn't sound like they intent do remove it entirely ಠ_ಠ

It also doesn't say anything about the point about the intentional slow downs of the builds for non sponsoring users. If I want to contribute to the dotnet runtime I shouldn't be forced to sponsor Moq just to avoid keeping my builds going full speed..

[samtrion]

Apperently, the change is going to get reverted in v4.20.2. What it means for longterm viability of Moq, I cannot say. Am lookng forward to seeing how the dotnet team is going to handle this.

They removed the package reference due to compatibility changes with Mac and Linux - not because of community feedback

@samtrion that is false. The reference is gone, and the analyzer is no longer packed with 4.20.2.

Points 1 and 2 will be addressed when it's reintroduced: will most likely just use a GUID.

...

reintroduced

Doesn't sound like they intent do remove it entirely ಠ_ಠ

Yes, unfortunately, there is no insight of the misconduct and further efforts to enforce this. Here, it is the community and certainly one or the other security officer who decides.

[RassK]

If I want to contribute to the dotnet runtime I shouldn't be forced to sponsor Moq just to avoid keeping my builds going full speed..

It's just not about Moq, but think if you are using tens of OSS libraries using SponsorLinker. Some of them with nested SponsorLinker (git submodules). So at the end you have to be subscribed everywhere to even build something.
There are major OSS software frameworks (ecoms, cms, etc) built on top of other OSS metapackages, even a single plugin can affect the build.

So in the end your console will be bloated with "thank you"s or "Sorry, sponsor me!" messages? then a massive delay follows.
Remote server goes down - again delay + delay for not supporting?

I see the OSS financing issue but unfortunately this solution is born dead.

[kzu]

Remote server == Azure CDN > Azure Blob Storage. If that goes down, there will be far serious issues :)

Happy to receive feedback which I was hoping to collect when I [announced}(https://www.cazzulino.com/sponsorlink.html) and started mentioning (and shipping!) SponsorLink on smaller packages. Better late than never, I suppose :)

I'm happy to explore other solutions that aren't "born dead" if they can be worked out and actually produce the intended results. Sure the "thank you" can be elimitated. How would you nag "properly" for people to sponsor the projects they use?

And let's address the elephant in the room: Microsoft has been leveraging and enjoying Moq everywhere and in almost every project, and yet it NEVER approached me for support. Neither any devs in any teams (except for @KirillOsenkov from way back then, right when I created my sponsor account). Mind you, @aws DID!

Does anyone think THAT's ok?