Trying to implement autofac with my WebApi ... but having some issues with lifetime for my objects...
My startup webapi class:
var builder = new ContainerBuilder();
builder.RegisterApiControllers(Assembly.GetExecutingAssembly()).InstancePerRequest();
container.RegisterType<MyConcreteClass>().As<IMyInterface>().InstancePerRequest();
var container = builder.Build();
app.UseAutofacMiddleware(container);
app.UseAutofacWebApi(config);
var csl = new AutofacServiceLocator(container);
ServiceLocator.SetLocatorProvider(() => csl);
config.DependencyResolver = new AutofacWebApiDependencyResolver(container);
But not works
Unable to resolve the type 'IMyInterface' because the lifetime scope it belongs in can't be located. The following services are exposed by this registration:
- IMyInterface
Details ---> No scope with a tag matching 'AutofacWebRequest' is visible from the scope in which the instance was requested.
If you see this during execution of a web application, it generally indicates that a component registered as per-HTTP request is being requested by a SingleInstance() component (or a similar scenario). Under the web integration always request dependencies from the dependency resolver or the request lifetime scope, never from the container itself. (See inner exception for details.)
Removing this part .InstancePerRequest(); , then works, but the object is not disposing.
What am i doing wrong ?
Thanks!
I strongly suspect the problem lies with the following code:
var csl = new AutofacServiceLocator(container);
ServiceLocator.SetLocatorProvider(() => csl);
The error message indicates you must resolve dependencies using the dependency resolver, but this is bypassing that and using the container itself.
On a side note, using a service locator is anti-pattern. You should be injecting dependencies into your controllers and other MVC extension points rather than using this approach.
Related
I am working in Multi-tenant solution primarily there are 2 type of applications
WebAPI
Console app to process message from queue
I have implemented dependency injection to inject all services. I have crated TenantContext class where I am resolving tenant information from HTTP header and it's working fine for API, but console application getting tenant information with every message (tenant info is part of queue message) so I am calling dependency injection register method on every incoming message which is not correct, do you have any suggestion/solution here?
The way I am resolving ITenantContext in API
services.AddScoped<ITenantContext>(serviceProvider =>
{
//Get Tenant from JWT token
if (string.IsNullOrWhiteSpace(tenantId))
{
//1. Get HttpAccessor and processor settings
var httpContextAccessor =
serviceProvider.GetRequiredService<IHttpContextAccessor>();
//2. Get tenant information (temporary code, we will get token from JWT)
tenantId = httpContextAccessor?.HttpContext?.Request.Headers["tenant"]
.FirstOrDefault();
if (string.IsNullOrWhiteSpace(tenantId))
//throw bad request for api
throw new Exception($"Request header tenant is missing");
}
var tenantSettings =
serviceProvider.GetRequiredService<IOptionsMonitor<TenantSettings>>();
return new TenantContext(tenantId, tenantSettings );
});
Create two different ITenantContext implementations. One for your Web API, and one for your Console application.
Your Web API implementation than might look as follows:
public class WebApiTenantContext : ITenantContext
{
private readonly IHttpContextAccessor accessor;
private readonly IOptionsMonitor<TenantSettings> settings;
public WebApiTenantContext(
IHttpContextAccessor accessor,
IOptionsMonitor<TenantSettings> settings)
{
// Notice how the dependencies are not used in this ctor; this is a best
// practice. For more information about this, see Mark's blog:
// https://blog.ploeh.dk/2011/03/03/InjectionConstructorsshouldbesimple/
this.accessor = accessor;
this.settings = settings;
}
// This property searches for the header each time its called. If needed,
// it can be optimized by using some caching, e.g. using Lazy<string>.
public string TenantId =>
this.accessor.HttpContext?.Request.Headers["tenant"].FirstOrDefault()
?? throw new Exception($"Request header tenant is missing");
}
Notice that this implementation might be a bit naive for your purposes, but hopefully you'll get the idea.
This class can be registered in the Composition Root of the Web API project as follows:
services.AddScoped<ITenantContext, WebApiTenantContext>();
Because the WebApiTenantContext has all its dependencies defined in the constructor, you can do a simple mapping between the ITenantContext abstraction and the WebApiTenantContext implementation.
For the Console application, however, you need a very different approach. The WebApiTenantContext, as shown above, is currently stateless. It is able to pull in the required data (i.e. TenantId) from its dependencies. This probably won't work for your Console application. In that case, you will likely need to manually wrap the execution of each message from the queue in a IServiceScope and initialize the ConsoleTenantContext at the beginning of that request. In that case, the ConsoleTenantContext would look merely as follows:
public class ConsoleTenantContext : ITentantContext
{
public string TenantId { get; set; }
}
Somewhere in the Console application's Composition Root, you will have to pull messages from the queue (logic that you likely already have), and that's the point where you do something as follows:
var envelope = PullInFromQueue();
using (var scope = this.serviceProvider.CreateScope())
{
// Initialize the tenant context
var context = scope.ServiceProvider.GetRequiredService<ConsoleTenantContext>();
content.TenantId = envelope.TenantId;
// Forward the call to the message handler
var handler = scope.ServiceProvider.GetRequiredService<IMessageHandler>();
handler.Handle(envelope.Message);
}
The Console application's Composition Root will how have the following registrations:
services.AddScoped<ConsoleTenantContext>();
services.AddScoped<ITenentContext>(
c => c.GetRequiredServices<ConsoleTenantContext>());
With the registrations above, you register the ConsoleTenantContext as scoped. This is needed, because the previous message infrastructure needs to pull in ConsoleTenantContext explicitly to configure it. But the rest of the application will depend instead on ITenantContext, which is why it needs to be registered as well. That registration just forwards itself to the registered ConsoleTenantContext to ensure that both registrations lead to the same instance within a single scope. This wouldn't work when there would be two instances.
Note that you could use the same approach for Web API as demonstrated here for the Console application, but in practice it's harder to intervene in the request lifecycle of Web API compared to doing that with your Console application, where you are in full control. That's why using an ITenantContext implementation that is itself responsible of retrieving the right values is in this case an easier solution for a Web API, compared to the ITenantContext that is initialized from the outside.
What you saw here was a demonstration of different composition models that you can use while configuring your application. I wrote extensively about this in my series on DI Composition Models on my blog.
How do I instantiate a logger implementing Microsoft.Extensions.Logging.ILogger<out TCategoryName> that will output logs to my Serilog logger, when I cannot do it via standard ASP.NET Core dependency injection?
I have Serilog configured in my ASP.NET Core project, and the standard dependency injection set up is correctly injecting loggers into my controllers and services. The output from these loggers is correctly written to the file as specified in my Serilog configuration.
However, I need to pass a logger to an object that is instantiated during Startup.ConfigureServices(...), so I cannot resolve it via DI. I can instantiate a Serilog.Logger, but since I want to avoid direct dependencies on Serilog outside of my configuration code, I am forced to use my own adaptor. I would expect there to be some existing adaptor that would use Microsoft.Extensions.Logging.ILogger<out TCategoryName>, but I can't work out how to do it.
The precise use case is to inject a logger into a DbCommandInterceptor, which I am trying to do inside Startup.ConfigureServices(...):
var databaseConfiguration = this.Configuration
.GetSection(nameof(DatabaseConfiguration))
.Get<DatabaseConfiguration>();
var interceptor = new LoggingDbCommandInterceptor(
warning => Log.Logger.Warning("{Warning}", warning),
error => Log.Logger.Error("{Error}", error),
databaseConfiguration);
var dbConfiguration = new MyDbConfiguration(interceptor);
DbConfiguration.SetConfiguration(dbConfiguration);
I found the answer, and a bunch of other helpful tips here:
https://blog.rsuter.com/logging-with-ilogger-recommendations-and-best-practices/
var loggerFactory = (ILoggerFactory)new LoggerFactory();
loggerFactory.AddSerilog(serilogLogger);
var logger = loggerFactory.CreateLogger<TCategoryName>();
Is there a way to map all my repository objects to its interfaces in a single line. I don´t want to repeat my self in declarations like these:
services.AddScoped<Repository.Interfaces.IModeloRepository, Repository.ModeloRepository>();
services.AddScoped<Repository.Interfaces.IMunicipioRepository, Repository.MunicipioRepository>();
services.AddScoped<Repository.Interfaces.IPeriodoRepository, Repository.PeriodoRepository>();
services.AddScoped<Repository.Interfaces.IPlanRepository, Repository.PlanRepository>();
Here is a declaration of one of these repositories:
public interface IChatRepository : IRepository<Models.Chat>
I already tried something like this:
services.AddScoped(typeof(Repository.Common.IRepository<>), typeof(Repository.Common.BaseRepository<>));
But gets the following error:
Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware[0]
An unhandled exception has occurred: Unable to resolve service for type 'SqlExpress.Repository.Interfaces.IChatRepository' while attempting to activate 'SqlExpress.Helpers.LessonTagHelper'.
System.InvalidOperationException: Unable to resolve service for type 'SqlExpress.Repository.Interfaces.IChatRepository' while attempting to activate '
SqlExpress.Helpers.LessonTagHelper'.
at Microsoft.Extensions.Internal.ActivatorUtilities.GetService(IServiceProvider sp, Type type, Type requiredBy, Boolean isDefaultParameterRequired)
at lambda_method(Closure , IServiceProvider , Object[] )
Unfortunately, the built in DI container in ASP.NET Core is relatively simplistic. If you would like to use more advanced features like these, then you will need to use a different container.
The example below uses StructureMap as that's what I'm familiar with, but it is probably also possible with Autofac, Ninject etc.
Add the StructureMap library to project.json
"StructureMap.Dnx": "0.5.1-rc2-final"
Configure the DI container to use StructureMap, with naming conventions:
public IServiceProvider ConfigureServices(IServiceCollection services)
{
// Add framework services.
services.AddMvc().AddControllersAsServices();
// other service configuration
// Create a new StructureMap container
var container = new Container();
container.Configure(config =>
{
//add all the services that are already configured
config.Populate(services);
config.Scan(_ =>
{
_.WithDefaultConventions();
_.AssemblyContainingType<Startup>();
_.ConnectImplementationsToTypesClosing(typeof(IRepository<>));
});
});
//set ASP.NET Core to use the StructureMap container to build types
return container.GetInstance<IServiceProvider>();
}
It is worth checking our the documentation to see exactly how this works, but the default convention is to automatically register interface types such as IMyInterestingType with their implementation called MyInterestingType.
By using ConnectImplementationsToTypesClosing, each IRepository<> should also be registered to it's implementation.
I have a project with both Mvc Controllers and Web Api controllers.
Everything is wired up using autofac 3 :
var builder = new ContainerBuilder();
builder.Register(x => NHibernateConfigurator.BuildSessionFactory()).SingleInstance();
builder.Register(x => x.Resolve<ISessionFactory>().OpenSession()).InstancePerHttpRequest();
builder.RegisterSource(new AnyConcreteTypeNotAlreadyRegisteredSource());
builder.Register(x => new WebApiTransactionAttribute()).PropertiesAutowired();
builder.RegisterControllers(Assembly.GetExecutingAssembly());
builder.RegisterApiControllers(Assembly.GetExecutingAssembly());
builder.RegisterType<ExtensibleActionInvoker>().As<IActionInvoker>();
builder.RegisterWebApiFilterProvider(config);
var container = builder.Build();
DependencyResolver.SetResolver(new AutofacDependencyResolver(container));
config.DependencyResolver = new AutofacWebApiDependencyResolver(container);
The problem is that when I add the [Authorize] attribute (the one from System.Web.Http) I get :
Cannot choose between multiple constructors with equal length 1 on type 'System.String'.
Select the constructor explicitly, with the UsingConstructor() configuration method, when the component is registered.
Can someone point me in the right direction ?
Thanks.
Apologies, this is somewhat of a guess but the AnyConcreteTypeNotAlreadyRegisteredSource here looks like it may be too broad a registration:
Provides registrations on-the-fly for any concrete type not already registered with the container.
The Autofac Filter Provider could then be registering all kinds of framework concrete types and getting in a muddle.
It may be if you take this out and put in more targeted registrations it will help, perhaps register by convention instead.
I've a service operation which I marked with the Authenticate attribute
[Authenticate]
[Route("/route/to/service", "POST")]
public class OperationA: IReturn<OperationAResponse>
{
...
}
The method IsAuthorized of the AuthProvider is called correctly when I call the service using the REST URL or using JsonServiceClient inside a unit test but is not called if I call the service from ASP.NET code behind (not MVC controller).
I don't use IoC to resolve the service inside my code behind but I use this code...
MyService service = AppHostBase.Instance.Container.TryResolve<MyService>();
service.Post(operationA);
Is there something I'm missing?
Thank you for your attention.
Just to clarify:
I don't use IoC to resolve the service inside my code behind but I use this code...
MyService service = AppHostBase.Instance.Container.TryResolve<MyService>();
You are using the IOC here, i.e. resolving an auto-wired instance of MyService from ServiceStack's IOC.
If you're service doesn't make use of the HTTP Request or Response objects than you can treat it like any normal class and call C# methods. If the service does (e.g. Auth/Registration) then you will also need to inject the current HTTP Request Context as well.
The CustomAuthenticationMvc UseCase project has an example of how to do this:
var helloService = AppHostBase.Resolve<HelloService>();
helloService.RequestContext = System.Web.HttpContext.Current.ToRequestContext();
var response = (HelloResponse)helloService.Any(new Hello { Name = "World" });