Is that having Autofac IoC in my library project is a good practice, if not, how to replace it? If yes, how to resolve dependencies?

Question

I ran out of ideas, so I decided to ask for some in here. Currenty I am workig on a .Net class library, and I decided to split the library class into a service classes too (it uses IO, config).

Inside of the library I am using Autofac IoC for DI. But anyway, as it turned out, after adding the library into my project, where the project has his own Autofac IoC, I am getting exceptions from my ViewModelLocator:

Cannot resolve parameter 'G_Hoover.Services.Logging.IFileService fileService' of constructor 'Void .ctor (...)

NOTE: IFileService is a dependency of the library, not application project. Inside of the lib I am registering:

public static IContainer BootStrap()
        {
            var builder = new ContainerBuilder();

            builder.RegisterType<FileService>()
              .As<IFileService>().SingleInstance();

            //other services

            return builder.Build();
        }

What means, that IoC of the project wants to resolve dependencies from my class library.

After doing some research, I found this andswer, where was suggested to resolve dependencies internally in my library, where the project does not know about them. But how to do it?

Currently my approach is, that from application project I am calling exposed initial property of the library, according to this article about async init, and with this property I am trigerring RunConfigAsync() in my library, where I try to resolve my library dependencies:

private async Task RunConfigAsync()
        {
            IContainer container = BootStrapper.BootStrap();
            container.Resolve<IConfigService>();
            container.Resolve<IFileService>();
            container.Resolve<IStringService>();

            ConfigModel config = _configService.GetConfig();

            //do some other config and init stuff
        }

BUT the problem is, as I belive, that my ViewModelLocator in application project is calling my ViewModel, which has my library as a dependency, before dependencies in my library are resolved. So I tryed to resolve my library at the beginning in VMLocator, like this:

public class ViewModelLocator
    {
        IContainer _container;

        public ViewModelLocator()
        {
            _container = BootStrapper.BootStrap();

            _container.Resolve<IParamsLogger>();
        }

        public BrowserViewModel BrowserViewModel
        {
            get
            {
                return _container.Resolve<BrowserViewModel>();
            }
        }
        // other viewmodels below
    }

Unfortunatelly I am still getting the same exception like before. Right now I have no idea how to resolve dependencies internally inside of a library, when using Autofac (or other IoC framework), and we arrived to the point, where I need to ask more experienced devs for an advice.

Answer 1

UPDATE

Inspired with this article and this SO answer I made up kind of solution. Please correct me if I am wrong.

All here is about hiding library dependencies from the sight of application project. Otherwise application project will cry with exceptions that libraries dependencies were not registered in his IoC. But they are registered already in libraries IoC and we do not want to do it again. Right? Currently the problem was, that they were injected into libraries public constructor and were seen also by application project.

As someone adviced, facade pattern comes here for rescue. We supposed to hide dependencies inside, and Resolve facade in library class somewhere at initialization. Simple example I made up below, showing how I registered library services in librarys IoC as a singletons:

public class Booter
    {
        public static IContainer BootStrap()
        {
            var builder = new ContainerBuilder();

            builder.RegisterType<FilesService>()
              .As<IFilesService>().SingleInstance();

            builder.RegisterType<ControlsService>()
              .As<IControlsService>().SingleInstance();

            builder.RegisterType<Facade>()
              .AsSelf().SingleInstance();

            return builder.Build();
        }
    }

Into facade we are injecting library dependencies:

public class Facade
    {
        IFilesService _fileService;
        IControlsService _controlsService;
        public Facade(IFilesService filesService, IControlsService controlsService)
        {
            _fileService = filesService;
            _controlsService = controlsService;

            FilesService = _fileService;
            ControlsService = _controlsService;
        }

        public IFilesService FilesService { get; }

        public IControlsService ControlsService { get; }
    }

Next, in our lib, at first need to call Initialize, and Resolve inside facade, and to interfaces we declare facade properties that they are actually injected services:

public class MainService : IMainService
    {
        IFilesService _fileService;
        IControlsService _controlsService;
        IContainer _container;
        public MainService()
        {
            Initialize();
        }

        public void Initialize()
        {
            _container = Booter.BootStrap();

            var aggregator = _container.Resolve<Facade>();

            _fileService = aggregator.FilesService;
            _controlsService = aggregator.ControlsService;
        }

        public UiControlsModel SwitchOff()
        {
            return _controlsService.SwitchOff();
        }

        public UiControlsModel SwitchOn()
        {
            return _controlsService.SwitchOn();
        }
    }

I really hope that it is not any anti-pattern.