Warning AD0001 : Analyzer 'Microsoft.AspNetCore.Analyzers.RouteHandlers.RouteHandlerAnalyzer' NullReferenceException due to generics in minimal API

[madskonradsen]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

AspNetCore Analyzer throws warning due to usage of generics in minimal API:

1>CSC: Warning AD0001 : Analyzer 'Microsoft.AspNetCore.Analyzers.RouteHandlers.Route HandlerAnalyzer' threw an exception of type 'System.NullReferenceException' with message 'Object reference not set to an instance of an object.'.

Expected Behavior

This all works fine when running it, the analyzer is just not pleased with the usage of generics. Switching TEndpointInput to a concrete type such as DummyEndpointInput of course also make the warning disappear.

Steps To Reproduce

https://github.com/madskonradsen/minimal-reproducibles/tree/main/dotnet-analyzer-warning-minimalapi-generics/MinimalAPIGenericsWarning

Or simply:

var builder = WebApplication.CreateBuilder(args);

var app = builder.Build();

static void UseEndpoint<TEndpointInput>(WebApplication app) where TEndpointInput : class
{
    app.MapPost("/test", (TEndpointInput data) => Results.Ok(data));
}

UseEndpoint<DummyEndpointInput>(app);

app.Run();

public class DummyEndpointInput
{
}

Exceptions (if any)

No response

.NET Version

8.0.303

Anything else?

No response

[captainsafia]

@madskonradsen Thanks for reporting this issue! I resolved the stack trace for this and it looks like the DisallowNonParsableComplexTypesOnParameters analyzer is throwing this particular error.

at Microsoft.AspNetCore.Analyzers.RouteHandlers.RouteHandlerAnalyzer.<DisallowNonParsableComplexTypesOnParameters>g__ResovleParameterTypeSymbol|8_2(IParameterSymbol parameterSymbol)

I suspect the issue is in this chunk of code, which doesn't handle the fact that the type associated with TEndpointInput might not have passed the INamedTypeSymbol check.

aspnetcore/src/Framework/AspNetCoreAnalyzers/src/Analyzers/RouteHandlers/DisallowNonParsableComplexTypesOnParameters.cs

Lines 125 to 131 in e31445e

	else if (parameterSymbol.Type is INamedTypeSymbol namedTypeSymbol)
	{
	parameterTypeSymbol = namedTypeSymbol;
	}
	// If it is nullable, unwrap it.
	if (parameterTypeSymbol!.ConstructedFrom.SpecialType == SpecialType.System_Nullable_T)

Would you be interested in opening a PR with a fix for this? I'm happy to provide guidance on how to test/fix this.

[madskonradsen]

Sure! Seems like a nice small task :)

[captainsafia]

@madskonradsen Great! You can check out the build from source document for instructions on how to set up the repo for local development. You might run into issues here since our repo does unique things (relies on a nightly build of the .NET SDK, builds IIS if you're on Windows, etc) but I can hopefully get it working with any issues that you run into here.

After that, you can copy the code from your repro into a new test case in this file and that should get you setup to be able to debug and apply a fix.

[madskonradsen]

@captainsafia Sooo getting the environment up and running was pretty breezy. Roslyn analyzers on the other hand. But they are still fun to work with :)
I feel like I've gone in the wrong direction: main...madskonradsen:aspnetcore:mads/56831

I would have expected methodSymbol.TypeParameters to not be empty, but seems like I'm missing something. Any pointers? :)

[captainsafia]

@madskonradsen Yes, I believe the issue here is the fact that methodSymbol actually refers to the lambda expression based as an argument to the MapPost call ( (TEndpointInput data) => Results.Ok(data)) which has no type parameters itself but has a parameter that is a type parameter.

I believe what you might actually want to do here is iterate through methodSymbol.Parameters and check if the SymbolKind associated with each parameters is a TypeParameter.

[KennethHoff]

This has annoyed me more-or-less ever since .Net 8 launched, but never understood what causes it to happen nor found any issues on it, so I just ignored the warning and went on with my life. Good to see it's not just me experiencing this. Generic handlers would be a logical denominator. Quite niche after all.

[madskonradsen]

Take 2: main...madskonradsen:aspnetcore:mads/56831-2

This is not finished, but it just feels like the wrong direction to go in, but based on the current API, I'm having a hard time seeing other ways around it, and how I should be able to achieve it by just looking at the Parameters. The code above passes 2/3 tests so far. But I just can't shake the feeling that there must be a better way.

@captainsafia

[jofford]

Any progress on this? The warning still exists in dotnet cli 9.0.100. It doesn't seem to appear when building in Visual Studio 17.12 though.

[madskonradsen]

I haven't had much luck with the patch apart from the code above, and haven't heard any feedback from the dotnet team.