• Turn on warnings as errors
• Also cleanup <NoWarn> elements
• Clean up warnings backlog

<TreatWarningsAsErrors>true</TreatWarningsAsErrors>
<MSBuildTreatWarningsAsErrors>true</MSBuildTreatWarningsAsErrors>

• NuGet Central Package Management
• Migrate from .nuspec to project properties

The package that is available on nuget.org (and here on GitHub) does not show up in the Visual Studio Solution explorer under "Analyzers". I think the reason for this is that the package stores the dll in \lib\netstandard1.3 instead of \analyzers\dotnet\cs

I tried to investigate this a bit, but both the Diagnostic.nuspec and Moq.Analyzers.csproj look fine. Both use "analyzers\dotnet\cs" as the path. I don't know which of these two is used to built the actual nuget, my guess is Diagnostic.nuspec as it's using 0.0.9 while the csproj is still on 0.0.6.

Could you please upload an updated nuget with the correct path?

• Squash by default (appears to currently be set to merge)
• Set the squashed commit message to the PR message

• Setup() should be us-ed for methods, not for properties
• AdvancedMatcherAttribute should accept only IMatcher types
• Checks for protected mocks when dynamically referencing their members
• Setup() requires overridable members
• Mock.Get() should not take literals

Current analyzer uses fake "new T(args)" to understand whether constructor exists. It does not work for abstract classes because they cannot be instantiated directly.

Consider dropping the VISX package:

• Only 3k installs: https://marketplace.visualstudio.com/items?itemName=AndreyLipatkin.moqanalyzers&ssr=false#review-details
• Doesn't support VS2022
• Requires full Visual Studio install to build

https://licenses.nuget.org/BSD-3-Clause

There are duplicate steps and configuration necessary. Adding this here to see if what makes sense to keep things DRY

• Package icon
• README badges
• Add README to package

• Turn on analyzer
• Baseline existing code
• Create backlog for fixes

• Use the artifacts output path
• Emit and save TRX files as a build artifact

Scenario

internal abstract class AbstractClassWithCtor
{
    protected AbstractClassWithCtor(int a)
    {
    }
}

var mock3 = new Mock<AbstractClassWithCtor>();

Expected Result

• Moq1002

Actual Result

No diagnostic

I suggest nbgv, but others work as well. Pick one and use it. :)

It's unclear if this is a bug in the analyzer, bug in the test harness or something else.

However, the namespace shouldn't impact the analyzer. So once our tests are in a good spot, we should investigate.

Repro

"""
- namespace Moq.Analyzers.Test.DataAbstractClass.WithArgsPassed;
-
internal abstract class AbstractGenericClassWithCtor<T>
{

• Pick a style guide and how it should be
• Set .editconfig to match
• Remove legacy code formatting configuration

When using the result of an async operation (returning generic Task<>), rule Moq1200 fires indicating setup should only be used for overridable types. This is technically true because Task<> is abstract, however, the message is not helpful / actionable by the developer.

Example

public class AsyncClient
{
    public virtual Task<string> GenericAsyncWithConcreteReturn() => Task.FromResult(string.Empty);
}

var mock = new Mock<AsyncClient>();

// Error 1200
mock.Setup(c => c.GenericAsyncWithConcreteReturn().Result);

// Expected 
mock.Setup(c => c.GenericAsyncWithConcreteReturn())
                .ReturnsAsync(string.Empty);

Propose adding a new rule, Moq1201, that is triggered when the setup method includes a Task that calls in to .Result. The error message reflects the guidance from Moq, which is to use the .ReturnsAsync method for setup.

There is mixed use of implicit (var) and explicit types within the code base. Since we cannot use implicit types everywhere, and using implicit types makes things difficult during refactoring, switch to explicit types.

• Update code to explicit types
• Set code analysis rule to prevent use of var keyword

The tests use ApprovalTests, which is no longer maintained. We should use Verify instead.

Add a CI/CD pipeline to validate changes and ensure no regressions.

The analyzer targets netstandard1.3, which is no longer supported. We should target netstandard2.0 for maximum compatibility.

These are all "I'm pretty sure", but we should double check:

• Should be marked as dev dependency?
• Remove netstandard2.0 as a package dependency
• Remove lib/ folder
• Swap <licenseUrl> to <licenseExpression>
• Add package readme
• Deterministic build
• Symbols available

Use existing analyzer packages such as:

• https://nuget.info/packages/xunit.analyzers/1.14.0
• https://nuget.info/packages/Roslynator.Analyzers/4.12.3

as guides.

Related to #26