Add Roslyn analyzers to help with common Autofac usage issues

[tillig]

xunit ships with a set of Roslyn analyzers that help with common testing errors. This might be a good thing for common Autofac usage issues, too. Things we might be able to include:

• Only register IStartable and AutoActivate() things as singletons to avoid multiple instantiations or start executions.
• Missing .As<T>() on delegate registrations.

Unclear if this may be overkill, but it could turn into something pretty handy if we can help address some of the challenges seen in StackOverflow.

[tillig]

The way xunit does it, it's a separate package that is brought in as a dependency. I don't know if we want that or if we want to allow the analyzers to be an optional thing the developer has to bring in manually. The automated nature of it "magically" showing up for xunit has some value but I don't know off hand if that's a desired behavior for an IoC library.

[babrekel]

My two-cents:

Roslyn analyzers have a negative impact on Visual Studio general performance, depending on how they are written. They can be manually disabled through the Analyzers references menu in Visual Studio. Bugs in Analyzers will generate a warning popup in the top of the text editor menu, which prompts the user to disable the analyzers. This means they should be designed with care and performance in mind.

It might be a good idea to include them by default, since it can greatly help developers especially when they are new to Autofac or the concept of IOC.

There is a lot to be gained from this -- in addition to finding common mistakes, analyzers could even verify the integrity of the IoC container, think about missing registrations, incorrectly defined component lifetimes. However, for large systems this might introduce a large amount of undesirable overhead.

[pardahlman]

I think this makes a lot of sense 👍 . Serilog are planning to do this, too - perhaps that discussion can help decide how to split the packages!

[alistairjevans]

I'm planning to pick this up. I think it would be a good feature to add to Autofac, and now feels like a good time.

Proposal is:

• Create an Autofac.Analyzers repo.
• Move this issue to that repo.
• Create a set of base classes/helpers to make it easier for us to execute & test Autofac-specific analyzers.
• Create a couple of sample analyzers, for example, the two @tillig mentioned in the initial comments.
• Generate a NuGet package for Autofac.Analyzers.
• When ready, we can add a package reference for Autofac.Analyzers to the main Autofac package, that will pull in the analyzers for everyone who upgrades Autofac.
• Write some guides for adding new analyzers. Performance of analyzers is very important, so guidelines will be very necessary.

If there are any other analyzers people think would be valuable, we can mention them here, then raise them as feature requests in the new repo.

Also, I will try to remember to spell Analyzers with a 'z' everywhere....

[alistairjevans]

@tillig, would you mind creating a new Autofac.Analyzers repo? I don't have permissions on the org to do that.

[tillig]

https://github.com/autofac/Autofac.Analyzers

[alistairjevans]

Thanks :)

[tillig]

I can create an AppVeyor project for it, too, when you're ready.

[alistairjevans]

Yeah, when we get there. Are there some additional security changes on that repo? I don't think I have admin rights to it.

[tillig]

Oh, damn, yeah, forgot to add to the group. One sec

[tillig]

OK. I:

• Added Leadership as admins on that repo
• Created a new Autofac.Analyzers team for contributors who aren't admins
• Added that Autofac.Analyzers team to the repo at Triage level - basically everything but write access.

[alistairjevans]

Sweet; first commit is in. Thanks. I'm going to move this issue now.

[tillig]

Repo's created, AppVeyor project is in place, and it looks like proposed initial analyzers are being tracked in #2. I'm going to close this one.