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"?
c# asp.net asp.net-core .net-core simple-injector
|
show 2 more comments
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"?
c# asp.net asp.net-core .net-core simple-injector
"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 singleContainer
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 sameBootstrap(Container container)
method that is called from both insideStartup
as from the location where the background application is configured?
– Steven
Nov 8 at 10:13
1
A component registered asSingleton
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 usingRegisterInstance
.
– Steven
Nov 8 at 10:16
|
show 2 more comments
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"?
c# asp.net asp.net-core .net-core simple-injector
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
c# asp.net asp.net-core .net-core simple-injector
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 singleContainer
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 sameBootstrap(Container container)
method that is called from both insideStartup
as from the location where the background application is configured?
– Steven
Nov 8 at 10:13
1
A component registered asSingleton
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 usingRegisterInstance
.
– Steven
Nov 8 at 10:16
|
show 2 more comments
"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 singleContainer
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 sameBootstrap(Container container)
method that is called from both insideStartup
as from the location where the background application is configured?
– Steven
Nov 8 at 10:13
1
A component registered asSingleton
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 usingRegisterInstance
.
– 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
|
show 2 more comments
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.
add a comment |
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.
add a comment |
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.
add a comment |
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.
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.
answered Nov 8 at 13:34
UmaN
52411227
52411227
add a comment |
add a comment |
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
"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 insideStartup
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 usingRegisterInstance
.– Steven
Nov 8 at 10:16