nblumhardt / autofac-analysis

Log and analyze runtime operations on an Autofac container.

Autofac.Analysis

Log and analyze runtime operations on an Autofac container.

This project can:

• Detect common usage problems, including patterns that lead to unbounded memory growth,
• Provide a detailed view of how and where an Autofac container is being used within an application, and
• Surface component graph information, such as the sharing relationships between components.

Analysis has a significant impact on the host application; it's advisable to perform analysis during development and testing rather than on a live production system.

Getting started

1. Install the Autofac.Analysis NuGet package

dotnet add package Autofac.Analysis

2. Construct a Serilog ILogger to receive analysis events

Serilog supports a large range of sinks; here, we send analysis to the console/STDOUT, but you will see more detailed information if you choose a sink that can receive structured data.

// dotnet add package Serilog.Sinks.Console
var logger = new LoggerConfiguration()
    .WriteTo.Console()
	.CreateLogger();

If your application already uses Serilog, you may choose to send analysis events through the same pipeline. There are a lot of them, though! Setting a minimum level override can help to control the noise:

var logger = new LoggerConfiguration()
    .MinimumLevel.Override("Autofac.Analysis", LogEventLevel.Warning)
	// ...

3. Register the module in your Autofac container

builder.RegisterModule(new AnalysisModule(logger));

The module has a significant performance impact and should not be registered in normal production settings. You should consider including the registration conditionally in DEBUG builds.

Analyses

A001 - A lifetime scope was disposed after its parent

Since components in the child scope can see components in the parent scope, this may lead to problems including ObjectDisposedExceptions at runtime.

A002 - A non-root lifetime scope was active for more than 15 seconds

Long-lived scopes may indicate a failure to properly dispose the scope after use, in which case tracked components may not be disposed, and work to clean up unmanaged resources may be forced onto the finalizer thread.

A003 - A non-singleton (InstancePerDependency) component was resolved multiple times directly from the container

This usage pattern can lead to memory leaks when tracked/IDisposable components are introduced.

A004 - A non-singleton tracked/IDisposable component was resolved directly from the container

This usage pattern often indicates memory leaks; instances of the component will remain in memory for the life of the container.

autofac-analysis's Issues

unable to identify the type System.Linq.Enumerable+WhereSelectArrayIterator

Hello,

First of all thank you for the amazing work you're doing on autofac and autofac.Analysis!
I have a component registered with something like the following code (which works fine)

var list = new List<double> {1.0, 2.0, 3.5};
var containerBuilder = new ContainerBuilder();
containerBuilder.RegisterInstance(list.Where(x => x != 1.0)).As<IEnumerable<double>>();

When using Autofac.Analysis the above type is not handeled correctly and an exception is thrown when parsing the type. In fact, the following code fails

var list = new List<double> {1.0, 2.0, 3.5};
var type = list.Where(x => x!= 1.0).GetType().AssemblyQualifiedName;
_parsed = TypeIdentifier.Parse(type);

The issue is probably a Sprache issue and not a Autofac.Analysis one.

kind regards,

Kaïs Bejaoui

Plan of action!

Here's where we are today:

Here's what folks effectively want:

http://stackoverflow.com/questions/18578942/how-can-i-log-all-resolve-requests-to-autofac-container

This thread might be a good place to start a new plan. CC @gkinsman