autofac / autofac/Autofac.Analyzers
Autofac.Analyzers v1.0
- Dominant language
- C#
- Stars
- 1
- Forks
- 1
- PR merge metrics
- No merged PRs in 30d
Description
I'm going to use this issue to collect the desired behaviour for the first release of the Autofac Analyzers.
Specifically, I'm looking at what analyzers we are going to add and what capabilities they will have.
I'll raise a new issue for tracking discussion on a specific analyzer if required.
## Analyzers
The current list of intended analyzers included in 1.0 is as follows:
- [ ] Delegate Registration Should have As<> call
- [ ] AutoActivation Detection on Non-Singletons.
If anyone wants to propose an analyzer, lets discuss them here initially, then we can create a separate issue to discuss it.
## Categories
The two main categories of analyzer that I can see are:
- Registration - Inspecting registration expressions and detecting problematic registration call combinations.
- Resolution - Inspecting the constructors of components we have been able to detect as registered in Autofac, and raise diagnostics if there is a problem with one or more parameters. This second one may get pretty complicated, but we'll see.
## How Much Analysis?
One question that I'll have to think about as we go further is how far to track Registration objects throughout a code block. A single expression:
```csharp
builder.Register(c => new TestComponent()).As();
```
is a lot less complex from a trackability perspective than:
```csharp
var reg = builder.Register(c => new TestComponent());
reg.As();
```
It may be that we track items until they go out of local scope, but then give up.
There will have to be a line in the sand though on how much of a complex passing-around of a registration builder that we can handle, but I'll know more once I've gone a little deeper.
Contributor guide
Research direction
Start by reviewing the intended analyzer list and the Registration and Resolution categories in this issue. Compare the two registration examples to determine what tracking behavior is in scope, then clarify the analyzer requirements and boundaries before implementation. Done means the v1.0 analyzer set and supported analysis depth have been agreed.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- csharp
- Domain
- tooling
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 20/100