Autofac: Container validation

[shatl]

Please add configuration validate (e.g. AssertConfigurationIsValid) to ContainerBuilder.

[tillig]

This isn't really something we can support due to the flexibility of configuration options and ability for dynamic resolution.

A quick example of why this isn't possible:

var builder = new ContainerBuilder();

// ProdConfiguration requires a connectionString parameter
// because it reads from a database.
builder.RegisterType<ProdConfiguration>().AsSelf();

// Lambda reads the environment and returns the correct
// configuration based on that.
builder.Register(ctx => {
  var env = Environment.GetEnvironmentVariable("ENVIRONMENT");
  switch(env)
  {
    case "Development":
      return new TestConfiguration();
    case "Production":
      return ctx.Resolve<ProdConfiguration>(new NamedParameter("connStr", connectionString));
    default:
      throw new NotSupportedException("Unknown environment name.");
  }
}).As<IConfiguration>();

This raises some questions.

• The ProdConfiguration type needs a connection string parameter that isn't registered in the container. Does that make the container configuration invalid?
• The IConfiguration lambda relies on a particular environment parameter. If it's not set right, it's going to throw. Does that make the container configuration invalid?

Then think about things like...

• Modules that can dynamically attach things to all registrations.
• Registration sources.
• Registration parameters.
• Interceptors, adapters, and decorators.
• Dynamic assembly scanning.

...all of that is very much the tip of the iceberg. Honestly, the best we can do would be to ensure that if you RegisterType<T>().As<U>() that the T type can be cast to U... and we already do that.

[DevOnBike]

u have marked my request as duplicate but it points me to nowhere :( Not a single clue so it is not acceptable to me :( Suggest something or reopen my issue.

[tillig]

@mrychter The issue you filed, #872, is the duplicate. It points you to here, which explains why we can't support the container validation.

[DevOnBike]

@tillig I see what u have written by i don't need this method - it don't have to be in this way. Looking at ServiceRegistrationInfo class it looks that there are collections that are interesting to me like _defaultImplementations. If u could find way to add property to some class describing single registration like bool IsDefault it would be sufficient. Saying this way it doesn't push forward.

[tillig]

We have done a lot of research on things like this when we were working through fixing things for Microsoft.Extensions.DependencyInjection support. Exposing something you could use, count on, and be supported would take a lot of changes to the internals. I actually tried doing that work once and it becomes pretty breaking to the overall API surface because of all the different registration types and ways you can plug in. It seems really simple when you only consider reflection-based registrations. Gets way harder when you factor it all in.

I'm sorry that's not the answer you want, but it's the answer we have. If you can figure it out, if we're missing something, we are open to pull requests.

[ShadowDancer]

@tillig Maybe it would be wise to let people choose whenever they want advanced validation or freedom with dynamic registrations?

[DevOnBike]

i've never said that this kind of validation should be mandatory but i'm pretty sure that there should be api that supports this use case and product owners of library should be able to provide extended support people who would like to diy this logic. frankly speaking validation of automatic registrations is not uncommon requirement in average and larfe systems.

[PS-StuartZahn]

A validate command to ensure all component dependencies have been defined in the container graph would be great to catch errors at the start of a program

[jorgensigvardsson]

How about validating life time type dependencies? I've shot myself in the foot a couple of times with injecting objects with shorter life times into objects with a longer lifetime. Admittedly, I loaded the gun, aimed it at my foot and shot. Nevertheless, it was painful, and I would've appreciated the small gesture in the form of an exception when calling .Build().

[tillig]

That's not always an error. Say you have an in memory cache provider and five singletons that each want their own cache. The cache would be instance-per-dependency, the consumers would be singletons.