Where to declare my Autofac modules in my modular framework?

See more:

C#

.NET

IOC

modules

Autofac

Hey,

I have a general framework which contains a lot of assemblies, some are common, some are designed for Server applications, and some for Client applications (Each feature has a base-line library while any application-type-specific extensions are defined in a different assembly).

I'm trying to decide where in my framework I should declare Autofac registration modules for the different modules I create.

My code is completely decoupled and the IoC container is not used intrusively at all within my code. Also, other external dependencies (such as serializers, API assemblies, etc...) are referenced only by the modules that expose them to the framework. That causes some assembly-bloating issues because I have (for example) an entire assembly that adapts JSON serialization into my serialization interfaces (hiding it from the rest of my application code).

I thought about several possible solutions:

1. Adding an assembly to adapt with Autofac Modules on top of every "module-exposing" assembly.
- The main advantage is that every assembly will export its modules and all its the "functionalities" will be straight forward available in a modular fashion.
- The main disadvantage is that it probably will double the amount of assemblies I have.

2. Add only several Autofac-aware assemblies that will define different modules (Obviously not randomly), maybe one for containing the modules used for a specific application.
- This solution adds much less excessive assemblies, but is less modular, and causes possibly unwanted dependencies between all the assemblies in the group. Also if modules are created for a specific application repository, there is module reusability only within that repository (and no shared modules between different applications).

3. Create my own module registration "contract" interfaces within my framework and create a contract-consumer for the actual IoC container I'm using in order to adapt.
- The advantage is that every assembly can contain modules without any dependency (assuming the registration interfaces are in my most basic library). The disadvantage is that solution obviously limits the things I can do (similar to the "inner-platform" effect).

Are there any alternatives I'm missing? Are there more advantages/disadvantages that I fail to see? Did anybody experience anything similar dilemmas and the practices they've applied?

Thanks a lot!