Suggestion: when including SponsorLink in a project, call the integration project something other than <ProjectName>.CodeAnalyzers

[stakx]

Not actually a bug but a suggestion that I think could further help along acceptance of SponsorLink.

When SponsorLink got briefly introduced to Moq, people complained about it being obfuscated & closed-source. This has since been addressed, the point to take away here is that it was perceived as something that's got something to hide.

I noticed that SponsorLink was included in Moq as a project called Moq.CodeAnalyzers. This likewise seemed a little... disingenuous to me. Pardon the term, I don't mean to offend, but the point I'm trying to make is that it's once again easy to perceive this as an attempt to hide something.

While technically a Roslyn analyzer, SponsorLink doesn't really analyze code. The <ProjectName>.CodeAnalyzers project name ought to be reserved for actual code analysis; the SponsorLink integration would perhaps better be named more transparently, e.g. <ProjectName>.SponsorLinkIntegration. (Assuming you're free to name Roslyn analyzer projects whatever you want.)

[jeroenwalter]

Well, I wouldn't put it past @kzu to actually start code analyzing and add red squiggly lines for each Moq call in case you didn't sponsor the project and an additional tooltip with a link to the sponsor page. He certainly has the know-how, reading his nice post in https://www.cazzulino.com/smart-libraries.html

[kzu]

Agreed with @jeroenwalter. The reason for having IDE-level features that enhance the experience is a good one where users might opt-in to sponsoring. Hence the generic name.

Moving forward, the SL check will not even involve any package dependency or the like, and will be entirely up to each package author how to implement it (could be a build task, analyzer, source generator, whatever).

SL itself will just provide the CLI tool to generate a manifest that can be checked by any tool from any language at any time, without involving network calls, and for whatever purposes the library author may deem useful. See https://github.com/devlooped/gh-sponsors for more info on that part of the experience.

[stakx]

@kzu, apologies if perhaps my issue wasn't opened in quite the right place, I understand that SL is flexible enough to be used in a variety of ways. I was mostly thinking about the specific instances where you will reintroduce SL to your projects in the future... such as Moq. Perhaps I should've opened the issue at the Moq repo even. I just wanted to raise awareness about naming the project (if there's gonna be one) since people might be sensitive even about that. :)

[kzu]

I think in general, since the goal is to provide enhanced functionality via analyzers/codefixers/codegen, the SL check will make no sense as a separate project decoupled from the main analyzers. I just need to come up with a great one to kickststart the analyzers project again 😉 .

BTW, entire analyzers project gone now: #65

[stakx]

I just need to come up with a great one to kickststart the analyzers project again 😉 .

Regarding Moq in particular, code analyzers have been discussed a few times before. One obvious use case for them would be to warn at compile-time about those cases where the library will throw ArgumentExceptions due to usage mistakes. Such as trying to setup any unsupported / non-overridable type member (extension methods!) or when providing lambas to setup.Callback or setup.Returns with a non-matching method signature. (The C# type system isn't powerful enough to catch that.) Just some ideas to get you started, I could probably dig up the Moq issue about it if needed.

[kzu]

Those are awesome ideas! I was thinking of a codefix that could transform a lengthy set of Setup(...).Returns(...) into the more idiomatic Linq to Mocks too, for example.

[jeroenwalter]

Those are awesome ideas! I was thinking of a codefix that could transform a lengthy set of Setup(...).Returns(...) into the more idiomatic Linq to Mocks too, for example.

Then take a look at how NSubstitute does that. No lengthy Setups with a ton of lambdas, I found that really much nicer than how Moq works.

Also, NSubstitute has really helpful analyzers :)
https://nsubstitute.github.io/help/nsubstitute-analysers/

[kzu]

That's the direction v5 was going too, yeah. It may still happen, we'll see. Also, absolutely nobody has Linq to Mocks.

Mock.Of(x => x.This == 42 && x.That.Other(true, 25) == "yeah")

Perhaps you just aren't using Moq's full feature set ;)

[jeroenwalter]

No, I just never found the syntax of linq to mock intuitive or readable.
Also it's not well documented.
For instance, how do you use linq to mock with mocks that throw exceptions, or use callbacks?

[kzu]

You don't. It's for stubs, which is the way I personally use Moq the most.

[kzu]

I'm closing this for now. Proof that doing this will only make it trivial for unethical straight re-packaging is https://github.com/nike4613/unnugetizer. I don't think making it straightforward for folks that don't give a damn about OSS sustainability to strip off SL is a good thing for package authors that are struggling with precisely that issue.