ASP.NET Core startup code follows regular patterns that are suitable for code analysis and enhancements to the coding experience through analyzers, code fixes, and smarter scaffolding.
What things that analyzers could provide would be most valuable?
Things that analyzers can easily understand:
- What services are registered? (ex:
AddMvc()
includesAddRouting()
) - What options are set? (ex:
AddMvcOptions(options => options.EnableEndpointRouting = false)
- What middleware do you have? (ex:
UseHealthChecks()
) - What order are middleware in? (ex: is
UseStaticFiles()
before routing?) - What routes/endpoints are registered? (ex:
MapHealthChecks()
)
Here are some examples of the kinds of things we can do.
I did actually implement these - they aren't canned demos - it's prototype status. They don't yet have code fixes, but you could image that as well.
Have you ever forgotten to register something in DI?
This is generic functionality and can be driven from attributes or a text file shipped with the analyzer/SDK. If based on attributes, it can be extensible.
Middleware try to be flexible, but there are some cases that are always a mistake.
This is generic functionality and can be driven from attributes or a text file shipped with the analyzer/SDK. If based on attributes, it can be extensible.
What happens when things change?
This is an example of something highly tailored. If we deliver migration guidance and code fixes we recommend the more modern way to using the framework without the need for breaking compatibility and breaking APIs. This is a softer/nicer way to evolve ASP.NET Core.
Leave a comment here, open an issue at https://github.com/aspnet/AspNetCore or tweet @aVerySpicyBoi. The POWER IS YOURS!
Things I've heard so far that I like:
- Validating DI config at build-time is valuable, anything we can do here would help.
- Provide the same level of support for generic-host or the Program.cs equivalents of Startup code.
- Analyze all of my code! Not just startup.
- The other way around would be nice: “Authentication was added using AddAuthentication but no authentication middleware is invoked”.
- Calling app inside a lamda declared for another app call is probably a bug: app.MyBranchHelper(a=>app.BadCall());
@rynowak Great! I have no specific idea about Startup: I don't write new projects evey day, so in my opinion I don't expect Microsoft spends too much time too create tools to help users :-).