In Asp.net core, inside the Startup class, I configured a class AccountService as an injection inside this method:
public void ConfigureServices(IServiceCollection services)
{
...
services.AddScoped(typeof(CharacterService));
}
I can successfully inject it on another class, but I want to also access CharacterService inside the Configure() method of Startup, because I want to call a method on the event of shut down of the server. Is it possible?
public void Configure(IApplicationBuilder app, IWebHostEnvironment env, IHostApplicationLifetime hostApplicationLifetime)
{
...
// var temp = app.ApplicationServices.GetService<CharacterService>();
hostApplicationLifetime.ApplicationStopping.Register(() =>
{
//CharacterService.Instance.SaveMemoryInDatabase();
});
}
How can I access CharacterService inside the Configure method?
Thanks,
You can access service using app.ApplicationServices.
In some cases you need to create a scope for services that are added scoped or transient. It often depends on where they were added. In case of the normal setup through ConfigureServices you need to create a scope. (Another place where services can be added is the host builder, which is often in the Program class.)
public void ConfigureServices(IServiceCollection services)
{
...
services.AddScoped<CharacterService>();
}
public void Configure(IApplicationBuilder app,
IWebHostEnvironment env,
IHostApplicationLifetime hostApplicationLifetime)
{
using var scope = app.ApplicationServices.CreateScope();
var characterService = scope.ServiceProvider.GetRequiredService<CharacterService>();
hostApplicationLifetime.ApplicationStopping.Register(() =>
{
characterService.Instance.SaveMemoryInDatabase();
});
}
CreateScope returns an IServiceScope which is disposable. All IDisposable services that are created for a scope, such as scoped and transient services, will be disposed when the IServiceScope is disposed.
Related
I'm trying to register a singleton class, providing the constructor parameters in Startup.ConfigureServices method.
After several tries, I'm still not able to make the dbContext injection working
public void ConfigureServices(IServiceCollection services)
{
services.AddGrpc();
services.AddDbContext<EFContext>();
services.AddSingleton<OPCClient>(x =>
{
string endpointURL = "opc.tcp://xxx.yyy.zzz.nnn:12345";
bool autoAccept = false;
int stopTimeout = Timeout.Infinite;
var efContext = x.GetService<EFContext>();
OPCClient client = new OPCClient(endpointURL, autoAccept, stopTimeout, efContext);
client.Run();
return client;
});
}
public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
if (env.IsDevelopment())
{
app.UseDeveloperExceptionPage();
}
// warmup
app.ApplicationServices.GetService<OPCClient>();
app.UseRouting();
app.UseEndpoints(endpoints =>
{
endpoints.MapGrpcService<OPCService>();
endpoints.MapGet("/", async context =>
{
await context.Response.WriteAsync("Communication with gRPC endpoints must be made through a gRPC client. To learn how to create a client, visit: https://go.microsoft.com/fwlink/?linkid=2086909");
});
});
When var efContext = x.GetService<EFContext>(); is executed, I'm getting the exception
System.InvalidOperationException: 'Cannot resolve scoped service 'EFContext' from root provider.'
Thanks for any help in injecting the DbContext in OPCClient class
It is not a good choice to use a scoped service (the EFContext) inside a singleton.
The DI container creates a new instance of a scoped service for every request, while it creates a singleton only once and this can lead to inconsistent states for your objects. Documentation here
I suggest to change the lifetime of OPCClient to scoped - using services.AddScoped instead of services.AddSingleton. If you cannot do this, pass a reference of IServiceProvider rather than EFContext and resolve that service from the container each time you need to use it:
public class OPCClient
{
private IServicePrivder _serviceProvider;
public OPCClient (IServiceProvider serviceProvider)
{
_serviceProvider = serviceProvider;
}
public void DoSomething() {
EfContext efContext = _serviceProvider.GetRequiredService<EfContext>();
}
}
I'm developing a web app using ASP.net Core MVC 2.2, and in my Startup class I'm registering a dependency injection of type MyService, like so:
public void ConfigureServices(IServiceCollection services)
{
//Inject dependency
services.AddSingleton<MyService>();
//...other stuff...
}
This works correctly. However, I need to retrieve the instance of MyService during application shutdown, in order to do some cleanup operations before the app terminates.
So I tried doing this - first I injected IServiceProvider in my startup class, so it is available:
public Startup(IConfiguration configuration, IServiceProvider serviceProvider)
{
ServiceProvider = serviceProvider;
Configuration = configuration;
}
and then, in the Configure method, I configured a hook to the ApplicationStopping event, to intercept shutdown and call the OnShutdown method:
public void Configure(IApplicationBuilder app, IHostingEnvironment env, IApplicationLifetime applicationLifetime)
{
//Register app termination event hook
applicationLifetime.ApplicationStopping.Register(OnShutdown);
//...do stuff...
}
finally, in my OnShutdown method I try obtaining my dependency and using it:
private void OnShutdown()
{
var myService = ServiceProvider.GetService<MyService>();
myService.DoSomething(); //NullReference exception, myService is null!
}
However, as you can see from the comment in the code, this doesn't work: the returned dependency is always null. What am I doing wrong here?
I was able to make it work by explicitly passing your application services to your shutdown method like so.
public void Configure(IApplicationBuilder app, IHostingEnvironment env, IApplicationLifetime applicationLifetime)
{
//Register app termination event hook
applicationLifetime.ApplicationStopping.Register(() => OnShutdown(app.ApplicationServices));
//...do stuff...
}
private void OnShutdown(IServiceProvider serviceProvider)
{
var myService = serviceProvider.GetService<MyService>();
myService.DoSomething();
}
Bare in mind that this will work for singleton services - you may have to CreateScope() if you want to resolve scoped services.
I am looking to inject a kafka producer as a singleton in my app. It currently has two steps required when disposing the instance. First, you must flush the buffer, second call dispose. To increase performance, this should only happen when messages are no longer being processed.
My solution for ASP.NET core, is to use the AddSingleton() method in DI and then use ApplicationLifetime.ApplicationStopping.Register to register a callback that will flush and dispose the producer. I followed the tutorial found here:https://andrewlock.net/four-ways-to-dispose-idisposables-in-asp-net-core/
putting together a quick test I did the following in my Startup class:
public void ConfigureServices(IServiceCollection services)
{
var producerConfig = new Dictionary<string, object>
{
{ "bootstrap.servers", "192.168.99.100:9092" },
{ "client.id", Dns.GetHostName() },
{ "api.version.request", true }
};
services.AddSingleton(new Producer<Null, string>(producerConfig, null, new StringSerializer(Encoding.UTF8)));
services.AddMvc();
}
public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory, IApplicationLifetime lifetime)
{
loggerFactory.AddConsole();
app.UseMvc();
app.UseWebSockets();
if (env.IsDevelopment())
{
app.UseDeveloperExceptionPage();
}
lifetime.ApplicationStopping.Register(flushAndDispose, app.ApplicationServices.GetRequiredService<Producer>());
}
but when it runs I get the following error:
An exception of type 'System.InvalidOperationException' occurred in
Microsoft.Extensions.DependencyInjection.Abstractions.dll but was not
handled in user code: 'No service for type 'Confluent.Kafka.Producer'
has been registered.'
The assumption is also that Producer<T1,T2> is derived from Producer
you did not explicitly register a Producer with the service collection so the provider is unaware of how to resolve it.
services.AddSingleton<Producer>(
c => new Producer<Null, string>(producerConfig, null,
new StringSerializer(Encoding.UTF8)));
This question already has answers here:
Access the current HttpContext in ASP.NET Core
(7 answers)
Closed 6 years ago.
We are currently rewriting/converting our ASP.NET WebForms application using ASP.NET Core. Trying to avoid re-engineering as much as possible.
There is a section where we use HttpContext in a class library to check the current state. How can I access HttpContext.Current in .NET Core 1.0?
var current = HttpContext.Current;
if (current == null)
{
// do something here
// string connection = Configuration.GetConnectionString("MyDb");
}
I need to access this in order to construct current application host.
$"{current.Request.Url.Scheme}://{current.Request.Url.Host}{(current.Request.Url.Port == 80 ? "" : ":" + current.Request.Url.Port)}";
As a general rule, converting a Web Forms or MVC5 application to ASP.NET Core will require a significant amount of refactoring.
HttpContext.Current was removed in ASP.NET Core. Accessing the current HTTP context from a separate class library is the type of messy architecture that ASP.NET Core tries to avoid. There are a few ways to re-architect this in ASP.NET Core.
HttpContext property
You can access the current HTTP context via the HttpContext property on any controller. The closest thing to your original code sample would be to pass HttpContext into the method you are calling:
public class HomeController : Controller
{
public IActionResult Index()
{
MyMethod(HttpContext);
// Other code
}
}
public void MyMethod(Microsoft.AspNetCore.Http.HttpContext context)
{
var host = $"{context.Request.Scheme}://{context.Request.Host}";
// Other code
}
HttpContext parameter in middleware
If you're writing custom middleware for the ASP.NET Core pipeline, the current request's HttpContext is passed into your Invoke method automatically:
public Task Invoke(HttpContext context)
{
// Do something with the current HTTP context...
}
HTTP context accessor
Finally, you can use the IHttpContextAccessor helper service to get the HTTP context in any class that is managed by the ASP.NET Core dependency injection system. This is useful when you have a common service that is used by your controllers.
Request this interface in your constructor:
public MyMiddleware(IHttpContextAccessor httpContextAccessor)
{
_httpContextAccessor = httpContextAccessor;
}
You can then access the current HTTP context in a safe way:
var context = _httpContextAccessor.HttpContext;
// Do something with the current HTTP context...
IHttpContextAccessor isn't always added to the service container by default, so register it in ConfigureServices just to be safe:
public void ConfigureServices(IServiceCollection services)
{
services.AddHttpContextAccessor();
// if < .NET Core 2.2 use this
//services.TryAddSingleton<IHttpContextAccessor, HttpContextAccessor>();
// Other code...
}
Necromancing.
YES YOU CAN, and this is how.
A secret tip for those migrating large junks chunks of code:
The following method is an evil carbuncle of a hack which is actively engaged in carrying out the express work of satan (in the eyes of .NET Core framework developers), but it works:
In public class Startup
add a property
public IConfigurationRoot Configuration { get; }
And then add a singleton IHttpContextAccessor to DI in ConfigureServices.
// This method gets called by the runtime. Use this method to add services to the container.
public void ConfigureServices(IServiceCollection services)
{
services.AddSingleton<Microsoft.AspNetCore.Http.IHttpContextAccessor, Microsoft.AspNetCore.Http.HttpContextAccessor>();
Then in Configure
public void Configure(
IApplicationBuilder app
,IHostingEnvironment env
,ILoggerFactory loggerFactory
)
{
add the DI Parameter IServiceProvider svp, so the method looks like:
public void Configure(
IApplicationBuilder app
,IHostingEnvironment env
,ILoggerFactory loggerFactory
,IServiceProvider svp)
{
Next, create a replacement class for System.Web:
namespace System.Web
{
namespace Hosting
{
public static class HostingEnvironment
{
public static bool m_IsHosted;
static HostingEnvironment()
{
m_IsHosted = false;
}
public static bool IsHosted
{
get
{
return m_IsHosted;
}
}
}
}
public static class HttpContext
{
public static IServiceProvider ServiceProvider;
static HttpContext()
{ }
public static Microsoft.AspNetCore.Http.HttpContext Current
{
get
{
// var factory2 = ServiceProvider.GetService<Microsoft.AspNetCore.Http.IHttpContextAccessor>();
object factory = ServiceProvider.GetService(typeof(Microsoft.AspNetCore.Http.IHttpContextAccessor));
// Microsoft.AspNetCore.Http.HttpContextAccessor fac =(Microsoft.AspNetCore.Http.HttpContextAccessor)factory;
Microsoft.AspNetCore.Http.HttpContext context = ((Microsoft.AspNetCore.Http.HttpContextAccessor)factory).HttpContext;
// context.Response.WriteAsync("Test");
return context;
}
}
} // End Class HttpContext
}
Now in Configure, where you added the IServiceProvider svp, save this service provider into the static variable "ServiceProvider" in the just created dummy class System.Web.HttpContext (System.Web.HttpContext.ServiceProvider)
and set HostingEnvironment.IsHosted to true
System.Web.Hosting.HostingEnvironment.m_IsHosted = true;
this is essentially what System.Web did, just that you never saw it (I guess the variable was declared as internal instead of public).
// This method gets called by the runtime. Use this method to configure the HTTP request pipeline.
public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory, IServiceProvider svp)
{
loggerFactory.AddConsole(Configuration.GetSection("Logging"));
loggerFactory.AddDebug();
ServiceProvider = svp;
System.Web.HttpContext.ServiceProvider = svp;
System.Web.Hosting.HostingEnvironment.m_IsHosted = true;
app.UseCookieAuthentication(new CookieAuthenticationOptions()
{
AuthenticationScheme = "MyCookieMiddlewareInstance",
LoginPath = new Microsoft.AspNetCore.Http.PathString("/Account/Unauthorized/"),
AccessDeniedPath = new Microsoft.AspNetCore.Http.PathString("/Account/Forbidden/"),
AutomaticAuthenticate = true,
AutomaticChallenge = true,
CookieSecure = Microsoft.AspNetCore.Http.CookieSecurePolicy.SameAsRequest
, CookieHttpOnly=false
});
Like in ASP.NET Web-Forms, you'll get a NullReference when you're trying to access a HttpContext when there is none, such as it used to be in Application_Start in global.asax.
I stress again, this only works if you actually added
services.AddSingleton<Microsoft.AspNetCore.Http.IHttpContextAccessor, Microsoft.AspNetCore.Http.HttpContextAccessor>();
like I wrote you should.
Welcome to the ServiceLocator pattern within the DI pattern ;)
For risks and side effects, ask your resident doctor or pharmacist - or study the sources of .NET Core at github.com/aspnet, and do some testing.
Perhaps a more maintainable method would be adding this helper class
namespace System.Web
{
public static class HttpContext
{
private static Microsoft.AspNetCore.Http.IHttpContextAccessor m_httpContextAccessor;
public static void Configure(Microsoft.AspNetCore.Http.IHttpContextAccessor httpContextAccessor)
{
m_httpContextAccessor = httpContextAccessor;
}
public static Microsoft.AspNetCore.Http.HttpContext Current
{
get
{
return m_httpContextAccessor.HttpContext;
}
}
}
}
And then calling HttpContext.Configure in Startup->Configure
public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory, IServiceProvider svp)
{
loggerFactory.AddConsole(Configuration.GetSection("Logging"));
loggerFactory.AddDebug();
System.Web.HttpContext.Configure(app.ApplicationServices.
GetRequiredService<Microsoft.AspNetCore.Http.IHttpContextAccessor>()
);
There is a solution to this if you really need a static access to the current context.
In Startup.Configure(….)
app.Use(async (httpContext, next) =>
{
CallContext.LogicalSetData("CurrentContextKey", httpContext);
try
{
await next();
}
finally
{
CallContext.FreeNamedDataSlot("CurrentContextKey");
}
});
And when you need it you can get it with :
HttpContext context = CallContext.LogicalGetData("CurrentContextKey") as HttpContext;
I hope that helps. Keep in mind this workaround is when you don’t have a choice. The best practice is to use de dependency injection.
I'm using Asp.Net Core RC1, and I've to access to an HttpContext instance from instances generated by a model generator (from interceptors of Castle.Core, for be exact). Model generator has to be a single instance through the entire application.
I need to create an instance of ModelGenerator into startup file, because it is used into static lambdas needed to configure some serializers. Serializers are statically registered, so I have to write into startup:
var modelGenerator = new ModelGenerator();
Serializers.Configure(modelGenerator); // static use of model generator instance
I also add modelGenerator as singleton instance for other uses with DI.
services.AddInstance<IModelGenerator>(modelGenerator);
What I would have done with DI is to take a IHttpContextAccessor interface from ModelGenerator's constructor, but into this context I can't because I don't have an instance on startup. I need something like a ServiceLocator to call from ModelGenerator, or some other patter that I ignore.
How can reach an updated HttpContext instance, with information of current request, from interceptors generated by ModelGenerator?
It appears that there is no way to get an instance of HttpContext in application startup. This makes sense - in previous versions of MVC this wasn't possible in IIS integrated mode or OWIN.
So what you have are 2 issues:
How do you get the IHttpContextAccessor into your serializer?
How do you ensure the HttpContext is not accessed until it is available?
The first issue is pretty straightforward. You just need to use constructor injection on IHttpContextAccessor.
public interface ISerializer
{
void Test();
}
public class ModelGenerator : ISerializer
{
private readonly IHttpContextAccessor httpContextAccessor;
public ModelGenerator(IHttpContextAccessor httpContextAccessor)
{
this.httpContextAccessor = httpContextAccessor;
}
public void Test()
{
var context = this.httpContextAccessor.HttpContext;
// Use the context
}
}
And to register...
// This method gets called by the runtime. Use this method to add services to the container.
public void ConfigureServices(IServiceCollection services)
{
// Other code...
// Add the model generator
services.AddTransient<ISerializer, ModelGenerator>();
}
// This method gets called by the runtime. Use this method to configure the HTTP request pipeline.
public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
{
var serializers = app.ApplicationServices.GetServices<ISerializer>();
foreach (var serializer in serializers)
{
Serializers.Configure(serializer);
}
// Other code...
}
The second issue can be resolved by moving whatever initialization calls that you require HttpContext in into a global filter.
public class SerializerFilter : IAuthorizationFilter
{
public void OnAuthorization(AuthorizationContext context)
{
// TODO: Put some kind of if condition (possibly a
// global static variable) here to ensure this
// only runs when needed.
Serializers.Test();
}
}
And to register the filter globally:
public void ConfigureServices(IServiceCollection services)
{
// Other code...
// Add the global filter for the serializer
services.AddMvc(options =>
{
options.Filters.Add(new SerializerFilter());
});
// Other code...
}
If your Serializers.Configure() method requires HttpContext to work, then you will need to move that call into the global filter.