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

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

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.

Scenario

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

var mock3 = new Mock<AbstractClassWithCtor>();

Expected Result

• Moq1002

Actual Result

No diagnostic

Related to #26

• 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

• Package icon
• README badges
• Add README to package

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

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

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.

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

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

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

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 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?

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.

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

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

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

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

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

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>
{

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

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