Integrate Simple Injector with optional ASP.NET Core Web API











up vote
1
down vote

favorite












I followed this guide https://simpleinjector.org/aspnetcore for getting a basic app up and running. And it works great.



My needs now are a bit different, however. The Web API in my app is basically an optional endpoint that may not be started. I want to use the Simple Injector for DI across the entire application, however.



In my Program.cs I have the following lines:



// REST API
if (Config.ReadSettingBool("StartRestEndpoint", false))
{
LogManager.Info("Starting REST Endpoint...");
try
{
_httpHost = new HttpHost(
Config.ReadSetting("HttpHost", "localhost"),
Config.ReadSetting("HttpPort", 8081),
Config.ReadSetting("RestEnvironment", "Development"));
_httpHost.Start();
LogManager.Info("REST Endpoint started");
}
catch (Exception e)
{
LogManager.Error($"Failed to start REST endpoint: {e}");
}
}


Now, inside the HttpHost this happens:



_webHost = WebHost.CreateDefaultBuilder()
.UseUrls()
.UseUrls(_url)
.UseStartup<Startup>()
.UseEnvironment(_environment)
.Build();
_webHost.Start();


and inside the StartUp is the same code that I linked.



My problem is that the SimpleInjector container is kept (and setup) inside the StartUp and I have no way of getting at it. What I really want is to setup all the non-aspnet core related dependency tree prior to executing the StartUp routine and integrating with aspnet core.



That is, the "add application services" part in the below excerpt:



private void InitializeContainer(IApplicationBuilder app) {
// Add application presentation components:
container.RegisterMvcControllers(app);
container.RegisterMvcViewComponents(app);

// Add application services. For instance:
container.Register<IUserService, UserService>(Lifestyle.Scoped);

// Allow Simple Injector to resolve services from ASP.NET Core.
container.AutoCrossWireAspNetComponents(app);
}


The reason for wanting this is that this app is not a pure Web Api centered around Http. It is a legacy application containing a lot of background threads doing separate work, not all of which should somehow be exposed within an web api. In some environments, the web api should not even be started. You might argue that the application should somehow be split up but given the constraints I have that is simply not an option.



In short: it solves my goal of wanting to use the same DI container, relying on the same services, persistence access and more, across the entire application, with my REST resources being able to utilize parts of the legacy application functionality.



Is this possible, and how can I accomplish that? Or am I using these tools "the wrong way"?










share|improve this question
























  • "What I really want is to setup all the non-aspnet core related dependency tree prior to executing the StartUp". What problem does that solve? Why do you want that?
    – Steven
    Nov 8 at 9:28










  • Tried to answer this in a more elaborate way in my edit.
    – UmaN
    Nov 8 at 9:50






  • 1




    So, why not have 2 separate container instances? Must the application run, per se, with one single Container instance? Would it be okay if the Web API got its own container, isolated from the code that runs on background threads?
    – Steven
    Nov 8 at 10:01






  • 1




    "code duplication for the parts that are shared". Why would that be? Why can't you use the same Bootstrap(Container container) method that is called from both inside Startup as from the location where the background application is configured?
    – Steven
    Nov 8 at 10:13






  • 1




    A component registered as Singleton will only have one instance per container instance. This shouldn't be a problem in most cases, especially as you already stated that "the application should somehow be split up", which will inherently mean multiple app domains and thus multiple instances. For those few registrations where this actually is a problem, create them yourself, once, and feed them to the container using RegisterInstance.
    – Steven
    Nov 8 at 10:16















up vote
1
down vote

favorite












I followed this guide https://simpleinjector.org/aspnetcore for getting a basic app up and running. And it works great.



My needs now are a bit different, however. The Web API in my app is basically an optional endpoint that may not be started. I want to use the Simple Injector for DI across the entire application, however.



In my Program.cs I have the following lines:



// REST API
if (Config.ReadSettingBool("StartRestEndpoint", false))
{
LogManager.Info("Starting REST Endpoint...");
try
{
_httpHost = new HttpHost(
Config.ReadSetting("HttpHost", "localhost"),
Config.ReadSetting("HttpPort", 8081),
Config.ReadSetting("RestEnvironment", "Development"));
_httpHost.Start();
LogManager.Info("REST Endpoint started");
}
catch (Exception e)
{
LogManager.Error($"Failed to start REST endpoint: {e}");
}
}


Now, inside the HttpHost this happens:



_webHost = WebHost.CreateDefaultBuilder()
.UseUrls()
.UseUrls(_url)
.UseStartup<Startup>()
.UseEnvironment(_environment)
.Build();
_webHost.Start();


and inside the StartUp is the same code that I linked.



My problem is that the SimpleInjector container is kept (and setup) inside the StartUp and I have no way of getting at it. What I really want is to setup all the non-aspnet core related dependency tree prior to executing the StartUp routine and integrating with aspnet core.



That is, the "add application services" part in the below excerpt:



private void InitializeContainer(IApplicationBuilder app) {
// Add application presentation components:
container.RegisterMvcControllers(app);
container.RegisterMvcViewComponents(app);

// Add application services. For instance:
container.Register<IUserService, UserService>(Lifestyle.Scoped);

// Allow Simple Injector to resolve services from ASP.NET Core.
container.AutoCrossWireAspNetComponents(app);
}


The reason for wanting this is that this app is not a pure Web Api centered around Http. It is a legacy application containing a lot of background threads doing separate work, not all of which should somehow be exposed within an web api. In some environments, the web api should not even be started. You might argue that the application should somehow be split up but given the constraints I have that is simply not an option.



In short: it solves my goal of wanting to use the same DI container, relying on the same services, persistence access and more, across the entire application, with my REST resources being able to utilize parts of the legacy application functionality.



Is this possible, and how can I accomplish that? Or am I using these tools "the wrong way"?










share|improve this question
























  • "What I really want is to setup all the non-aspnet core related dependency tree prior to executing the StartUp". What problem does that solve? Why do you want that?
    – Steven
    Nov 8 at 9:28










  • Tried to answer this in a more elaborate way in my edit.
    – UmaN
    Nov 8 at 9:50






  • 1




    So, why not have 2 separate container instances? Must the application run, per se, with one single Container instance? Would it be okay if the Web API got its own container, isolated from the code that runs on background threads?
    – Steven
    Nov 8 at 10:01






  • 1




    "code duplication for the parts that are shared". Why would that be? Why can't you use the same Bootstrap(Container container) method that is called from both inside Startup as from the location where the background application is configured?
    – Steven
    Nov 8 at 10:13






  • 1




    A component registered as Singleton will only have one instance per container instance. This shouldn't be a problem in most cases, especially as you already stated that "the application should somehow be split up", which will inherently mean multiple app domains and thus multiple instances. For those few registrations where this actually is a problem, create them yourself, once, and feed them to the container using RegisterInstance.
    – Steven
    Nov 8 at 10:16













up vote
1
down vote

favorite









up vote
1
down vote

favorite











I followed this guide https://simpleinjector.org/aspnetcore for getting a basic app up and running. And it works great.



My needs now are a bit different, however. The Web API in my app is basically an optional endpoint that may not be started. I want to use the Simple Injector for DI across the entire application, however.



In my Program.cs I have the following lines:



// REST API
if (Config.ReadSettingBool("StartRestEndpoint", false))
{
LogManager.Info("Starting REST Endpoint...");
try
{
_httpHost = new HttpHost(
Config.ReadSetting("HttpHost", "localhost"),
Config.ReadSetting("HttpPort", 8081),
Config.ReadSetting("RestEnvironment", "Development"));
_httpHost.Start();
LogManager.Info("REST Endpoint started");
}
catch (Exception e)
{
LogManager.Error($"Failed to start REST endpoint: {e}");
}
}


Now, inside the HttpHost this happens:



_webHost = WebHost.CreateDefaultBuilder()
.UseUrls()
.UseUrls(_url)
.UseStartup<Startup>()
.UseEnvironment(_environment)
.Build();
_webHost.Start();


and inside the StartUp is the same code that I linked.



My problem is that the SimpleInjector container is kept (and setup) inside the StartUp and I have no way of getting at it. What I really want is to setup all the non-aspnet core related dependency tree prior to executing the StartUp routine and integrating with aspnet core.



That is, the "add application services" part in the below excerpt:



private void InitializeContainer(IApplicationBuilder app) {
// Add application presentation components:
container.RegisterMvcControllers(app);
container.RegisterMvcViewComponents(app);

// Add application services. For instance:
container.Register<IUserService, UserService>(Lifestyle.Scoped);

// Allow Simple Injector to resolve services from ASP.NET Core.
container.AutoCrossWireAspNetComponents(app);
}


The reason for wanting this is that this app is not a pure Web Api centered around Http. It is a legacy application containing a lot of background threads doing separate work, not all of which should somehow be exposed within an web api. In some environments, the web api should not even be started. You might argue that the application should somehow be split up but given the constraints I have that is simply not an option.



In short: it solves my goal of wanting to use the same DI container, relying on the same services, persistence access and more, across the entire application, with my REST resources being able to utilize parts of the legacy application functionality.



Is this possible, and how can I accomplish that? Or am I using these tools "the wrong way"?










share|improve this question















I followed this guide https://simpleinjector.org/aspnetcore for getting a basic app up and running. And it works great.



My needs now are a bit different, however. The Web API in my app is basically an optional endpoint that may not be started. I want to use the Simple Injector for DI across the entire application, however.



In my Program.cs I have the following lines:



// REST API
if (Config.ReadSettingBool("StartRestEndpoint", false))
{
LogManager.Info("Starting REST Endpoint...");
try
{
_httpHost = new HttpHost(
Config.ReadSetting("HttpHost", "localhost"),
Config.ReadSetting("HttpPort", 8081),
Config.ReadSetting("RestEnvironment", "Development"));
_httpHost.Start();
LogManager.Info("REST Endpoint started");
}
catch (Exception e)
{
LogManager.Error($"Failed to start REST endpoint: {e}");
}
}


Now, inside the HttpHost this happens:



_webHost = WebHost.CreateDefaultBuilder()
.UseUrls()
.UseUrls(_url)
.UseStartup<Startup>()
.UseEnvironment(_environment)
.Build();
_webHost.Start();


and inside the StartUp is the same code that I linked.



My problem is that the SimpleInjector container is kept (and setup) inside the StartUp and I have no way of getting at it. What I really want is to setup all the non-aspnet core related dependency tree prior to executing the StartUp routine and integrating with aspnet core.



That is, the "add application services" part in the below excerpt:



private void InitializeContainer(IApplicationBuilder app) {
// Add application presentation components:
container.RegisterMvcControllers(app);
container.RegisterMvcViewComponents(app);

// Add application services. For instance:
container.Register<IUserService, UserService>(Lifestyle.Scoped);

// Allow Simple Injector to resolve services from ASP.NET Core.
container.AutoCrossWireAspNetComponents(app);
}


The reason for wanting this is that this app is not a pure Web Api centered around Http. It is a legacy application containing a lot of background threads doing separate work, not all of which should somehow be exposed within an web api. In some environments, the web api should not even be started. You might argue that the application should somehow be split up but given the constraints I have that is simply not an option.



In short: it solves my goal of wanting to use the same DI container, relying on the same services, persistence access and more, across the entire application, with my REST resources being able to utilize parts of the legacy application functionality.



Is this possible, and how can I accomplish that? Or am I using these tools "the wrong way"?







c# asp.net asp.net-core .net-core simple-injector






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 8 at 9:58









Steven

124k17211325




124k17211325










asked Nov 8 at 8:48









UmaN

52411227




52411227












  • "What I really want is to setup all the non-aspnet core related dependency tree prior to executing the StartUp". What problem does that solve? Why do you want that?
    – Steven
    Nov 8 at 9:28










  • Tried to answer this in a more elaborate way in my edit.
    – UmaN
    Nov 8 at 9:50






  • 1




    So, why not have 2 separate container instances? Must the application run, per se, with one single Container instance? Would it be okay if the Web API got its own container, isolated from the code that runs on background threads?
    – Steven
    Nov 8 at 10:01






  • 1




    "code duplication for the parts that are shared". Why would that be? Why can't you use the same Bootstrap(Container container) method that is called from both inside Startup as from the location where the background application is configured?
    – Steven
    Nov 8 at 10:13






  • 1




    A component registered as Singleton will only have one instance per container instance. This shouldn't be a problem in most cases, especially as you already stated that "the application should somehow be split up", which will inherently mean multiple app domains and thus multiple instances. For those few registrations where this actually is a problem, create them yourself, once, and feed them to the container using RegisterInstance.
    – Steven
    Nov 8 at 10:16


















  • "What I really want is to setup all the non-aspnet core related dependency tree prior to executing the StartUp". What problem does that solve? Why do you want that?
    – Steven
    Nov 8 at 9:28










  • Tried to answer this in a more elaborate way in my edit.
    – UmaN
    Nov 8 at 9:50






  • 1




    So, why not have 2 separate container instances? Must the application run, per se, with one single Container instance? Would it be okay if the Web API got its own container, isolated from the code that runs on background threads?
    – Steven
    Nov 8 at 10:01






  • 1




    "code duplication for the parts that are shared". Why would that be? Why can't you use the same Bootstrap(Container container) method that is called from both inside Startup as from the location where the background application is configured?
    – Steven
    Nov 8 at 10:13






  • 1




    A component registered as Singleton will only have one instance per container instance. This shouldn't be a problem in most cases, especially as you already stated that "the application should somehow be split up", which will inherently mean multiple app domains and thus multiple instances. For those few registrations where this actually is a problem, create them yourself, once, and feed them to the container using RegisterInstance.
    – Steven
    Nov 8 at 10:16
















"What I really want is to setup all the non-aspnet core related dependency tree prior to executing the StartUp". What problem does that solve? Why do you want that?
– Steven
Nov 8 at 9:28




"What I really want is to setup all the non-aspnet core related dependency tree prior to executing the StartUp". What problem does that solve? Why do you want that?
– Steven
Nov 8 at 9:28












Tried to answer this in a more elaborate way in my edit.
– UmaN
Nov 8 at 9:50




Tried to answer this in a more elaborate way in my edit.
– UmaN
Nov 8 at 9:50




1




1




So, why not have 2 separate container instances? Must the application run, per se, with one single Container instance? Would it be okay if the Web API got its own container, isolated from the code that runs on background threads?
– Steven
Nov 8 at 10:01




So, why not have 2 separate container instances? Must the application run, per se, with one single Container instance? Would it be okay if the Web API got its own container, isolated from the code that runs on background threads?
– Steven
Nov 8 at 10:01




1




1




"code duplication for the parts that are shared". Why would that be? Why can't you use the same Bootstrap(Container container) method that is called from both inside Startup as from the location where the background application is configured?
– Steven
Nov 8 at 10:13




"code duplication for the parts that are shared". Why would that be? Why can't you use the same Bootstrap(Container container) method that is called from both inside Startup as from the location where the background application is configured?
– Steven
Nov 8 at 10:13




1




1




A component registered as Singleton will only have one instance per container instance. This shouldn't be a problem in most cases, especially as you already stated that "the application should somehow be split up", which will inherently mean multiple app domains and thus multiple instances. For those few registrations where this actually is a problem, create them yourself, once, and feed them to the container using RegisterInstance.
– Steven
Nov 8 at 10:16




A component registered as Singleton will only have one instance per container instance. This shouldn't be a problem in most cases, especially as you already stated that "the application should somehow be split up", which will inherently mean multiple app domains and thus multiple instances. For those few registrations where this actually is a problem, create them yourself, once, and feed them to the container using RegisterInstance.
– Steven
Nov 8 at 10:16












1 Answer
1






active

oldest

votes

















up vote
0
down vote













For anyone interested. I did the solution suggested by Steven. Thank you very much.



Basically the application becomes:



            LogManager.Info("Starting REST Endpoint...");
try
{
_httpHost = new HttpHost(
Config.ReadSetting("HttpHost", "localhost"),
Config.ReadSetting("HttpPort", 8081),
Config.ReadSetting("RestEnvironment", "Development"));
_httpHost.Start();
LogManager.Info("REST Endpoint started");
}
catch (Exception e)
{
LogManager.Error($"Failed to start REST endpoint: {e}");
}


LogManager.Info("Starting Monitors...");
// Set up dependency tree.
Container _container = new Container();
BootstrapDependencyInjectionTree.Bootstrap(_container);
_container.Verify();

_monitors = new Monitors(_container.GetInstance<IMonitorDefinitionRepository>());
_monitors.RegisterMonitors();
_monitors.StartContinuousMonitors();


with another container instance being created inside the aspnetcore StartUp type and set up as:



    private void InitializeContainer(IApplicationBuilder app)
{
// Add application presentation components:
_container.RegisterMvcControllers(app);
_container.RegisterMvcViewComponents(app);

// Add application services.
// This creates an object dependency graph that is used to populate all constructor arguments using DI.
BootstrapDependencyInjectionTree.Bootstrap(_container);

// Web api only dependencies.
_container.RegisterSingleton<IMonitorMetaDataProvider, MonitorMetaDataProvider>();

// Allow Simple Injector to resolve services from ASP.NET Core.
_container.AutoCrossWireAspNetComponents(app);
}


This works as I would expect it.






share|improve this answer





















    Your Answer






    StackExchange.ifUsing("editor", function () {
    StackExchange.using("externalEditor", function () {
    StackExchange.using("snippets", function () {
    StackExchange.snippets.init();
    });
    });
    }, "code-snippets");

    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "1"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    convertImagesToLinks: true,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: 10,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });














     

    draft saved


    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53204216%2fintegrate-simple-injector-with-optional-asp-net-core-web-api%23new-answer', 'question_page');
    }
    );

    Post as a guest
































    1 Answer
    1






    active

    oldest

    votes








    1 Answer
    1






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes








    up vote
    0
    down vote













    For anyone interested. I did the solution suggested by Steven. Thank you very much.



    Basically the application becomes:



                LogManager.Info("Starting REST Endpoint...");
    try
    {
    _httpHost = new HttpHost(
    Config.ReadSetting("HttpHost", "localhost"),
    Config.ReadSetting("HttpPort", 8081),
    Config.ReadSetting("RestEnvironment", "Development"));
    _httpHost.Start();
    LogManager.Info("REST Endpoint started");
    }
    catch (Exception e)
    {
    LogManager.Error($"Failed to start REST endpoint: {e}");
    }


    LogManager.Info("Starting Monitors...");
    // Set up dependency tree.
    Container _container = new Container();
    BootstrapDependencyInjectionTree.Bootstrap(_container);
    _container.Verify();

    _monitors = new Monitors(_container.GetInstance<IMonitorDefinitionRepository>());
    _monitors.RegisterMonitors();
    _monitors.StartContinuousMonitors();


    with another container instance being created inside the aspnetcore StartUp type and set up as:



        private void InitializeContainer(IApplicationBuilder app)
    {
    // Add application presentation components:
    _container.RegisterMvcControllers(app);
    _container.RegisterMvcViewComponents(app);

    // Add application services.
    // This creates an object dependency graph that is used to populate all constructor arguments using DI.
    BootstrapDependencyInjectionTree.Bootstrap(_container);

    // Web api only dependencies.
    _container.RegisterSingleton<IMonitorMetaDataProvider, MonitorMetaDataProvider>();

    // Allow Simple Injector to resolve services from ASP.NET Core.
    _container.AutoCrossWireAspNetComponents(app);
    }


    This works as I would expect it.






    share|improve this answer

























      up vote
      0
      down vote













      For anyone interested. I did the solution suggested by Steven. Thank you very much.



      Basically the application becomes:



                  LogManager.Info("Starting REST Endpoint...");
      try
      {
      _httpHost = new HttpHost(
      Config.ReadSetting("HttpHost", "localhost"),
      Config.ReadSetting("HttpPort", 8081),
      Config.ReadSetting("RestEnvironment", "Development"));
      _httpHost.Start();
      LogManager.Info("REST Endpoint started");
      }
      catch (Exception e)
      {
      LogManager.Error($"Failed to start REST endpoint: {e}");
      }


      LogManager.Info("Starting Monitors...");
      // Set up dependency tree.
      Container _container = new Container();
      BootstrapDependencyInjectionTree.Bootstrap(_container);
      _container.Verify();

      _monitors = new Monitors(_container.GetInstance<IMonitorDefinitionRepository>());
      _monitors.RegisterMonitors();
      _monitors.StartContinuousMonitors();


      with another container instance being created inside the aspnetcore StartUp type and set up as:



          private void InitializeContainer(IApplicationBuilder app)
      {
      // Add application presentation components:
      _container.RegisterMvcControllers(app);
      _container.RegisterMvcViewComponents(app);

      // Add application services.
      // This creates an object dependency graph that is used to populate all constructor arguments using DI.
      BootstrapDependencyInjectionTree.Bootstrap(_container);

      // Web api only dependencies.
      _container.RegisterSingleton<IMonitorMetaDataProvider, MonitorMetaDataProvider>();

      // Allow Simple Injector to resolve services from ASP.NET Core.
      _container.AutoCrossWireAspNetComponents(app);
      }


      This works as I would expect it.






      share|improve this answer























        up vote
        0
        down vote










        up vote
        0
        down vote









        For anyone interested. I did the solution suggested by Steven. Thank you very much.



        Basically the application becomes:



                    LogManager.Info("Starting REST Endpoint...");
        try
        {
        _httpHost = new HttpHost(
        Config.ReadSetting("HttpHost", "localhost"),
        Config.ReadSetting("HttpPort", 8081),
        Config.ReadSetting("RestEnvironment", "Development"));
        _httpHost.Start();
        LogManager.Info("REST Endpoint started");
        }
        catch (Exception e)
        {
        LogManager.Error($"Failed to start REST endpoint: {e}");
        }


        LogManager.Info("Starting Monitors...");
        // Set up dependency tree.
        Container _container = new Container();
        BootstrapDependencyInjectionTree.Bootstrap(_container);
        _container.Verify();

        _monitors = new Monitors(_container.GetInstance<IMonitorDefinitionRepository>());
        _monitors.RegisterMonitors();
        _monitors.StartContinuousMonitors();


        with another container instance being created inside the aspnetcore StartUp type and set up as:



            private void InitializeContainer(IApplicationBuilder app)
        {
        // Add application presentation components:
        _container.RegisterMvcControllers(app);
        _container.RegisterMvcViewComponents(app);

        // Add application services.
        // This creates an object dependency graph that is used to populate all constructor arguments using DI.
        BootstrapDependencyInjectionTree.Bootstrap(_container);

        // Web api only dependencies.
        _container.RegisterSingleton<IMonitorMetaDataProvider, MonitorMetaDataProvider>();

        // Allow Simple Injector to resolve services from ASP.NET Core.
        _container.AutoCrossWireAspNetComponents(app);
        }


        This works as I would expect it.






        share|improve this answer












        For anyone interested. I did the solution suggested by Steven. Thank you very much.



        Basically the application becomes:



                    LogManager.Info("Starting REST Endpoint...");
        try
        {
        _httpHost = new HttpHost(
        Config.ReadSetting("HttpHost", "localhost"),
        Config.ReadSetting("HttpPort", 8081),
        Config.ReadSetting("RestEnvironment", "Development"));
        _httpHost.Start();
        LogManager.Info("REST Endpoint started");
        }
        catch (Exception e)
        {
        LogManager.Error($"Failed to start REST endpoint: {e}");
        }


        LogManager.Info("Starting Monitors...");
        // Set up dependency tree.
        Container _container = new Container();
        BootstrapDependencyInjectionTree.Bootstrap(_container);
        _container.Verify();

        _monitors = new Monitors(_container.GetInstance<IMonitorDefinitionRepository>());
        _monitors.RegisterMonitors();
        _monitors.StartContinuousMonitors();


        with another container instance being created inside the aspnetcore StartUp type and set up as:



            private void InitializeContainer(IApplicationBuilder app)
        {
        // Add application presentation components:
        _container.RegisterMvcControllers(app);
        _container.RegisterMvcViewComponents(app);

        // Add application services.
        // This creates an object dependency graph that is used to populate all constructor arguments using DI.
        BootstrapDependencyInjectionTree.Bootstrap(_container);

        // Web api only dependencies.
        _container.RegisterSingleton<IMonitorMetaDataProvider, MonitorMetaDataProvider>();

        // Allow Simple Injector to resolve services from ASP.NET Core.
        _container.AutoCrossWireAspNetComponents(app);
        }


        This works as I would expect it.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Nov 8 at 13:34









        UmaN

        52411227




        52411227






























             

            draft saved


            draft discarded



















































             


            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53204216%2fintegrate-simple-injector-with-optional-asp-net-core-web-api%23new-answer', 'question_page');
            }
            );

            Post as a guest




















































































            Popular posts from this blog

            Schultheiß

            Liste der Kulturdenkmale in Wilsdruff

            Android Play Services Check