Customizing Autofac in Azure mobile app results in 'No service registered for ITableControllerConfigProvider type' exception - autofac

I'm trying to customize an Azure Web app application that was created with Visual Studio. I've added an AccountsController to help with user registration using the Owin membership tables. I want to add Owin to the site, so I'm customizing the WebApiConfig.cs file with this method:
public static void Register(HttpConfiguration config)
{
// Use this class to set configuration options for your mobile service
var options = new ConfigOptions();
var configBuilder = new ConfigBuilder(options, (configuration, builder) =>
{
var executingAssembly = Assembly.GetExecutingAssembly();
var file = FileHelper.GetLoggingConfigFile(executingAssembly);
// startup the logging
_logger = new Logger(MethodBase.GetCurrentMethod().DeclaringType, file);
//builder.RegisterInstance(new CustomOwinAppBuilder(configuration))
// .As<IOwinAppBuilder>();
//configure the Autofac IoC container
AutofacBuilder.Configure(executingAssembly, _logger, builder, new MvcModule(),
new TaskModule());
});
var defaultConfig = ServiceConfig.Initialize(configBuilder);
// Make sure this is after ServiceConfig.Initialize
// Otherwise ServiceConfig.Initialize will overwrite your changes
StartupOwinAppBuilder.Initialize(app =>
{
// Configure the db context and user manager to use a single instance per request
app.CreatePerOwinContext(TrainMobileContext.Create);
app.CreatePerOwinContext<ApplicationUserManager>(ApplicationUserManager.Create);
// app.UseFacebookAuthentication("", "");
});
defaultConfig.Routes.MapHttpRoute(
name: "DefaultApi",
routeTemplate: "api/{controller}/{id}",
defaults: new { id = RouteParameter.Optional }
);
// To display errors in the browser during development, uncomment the following
// line. Comment it out again when you deploy your service for production use.
// config.IncludeErrorDetailPolicy = IncludeErrorDetailPolicy.Always;
Database.SetInitializer(new MobileServiceInitializer());
}
The AutofacBuilder handles a lot of the registration with statements like so:
builder.RegisterType<RepositoryProvider>().As<IRepositoryProvider>().InstancePerHttpRequest();
builder.RegisterType<DataManager>().As<IDataManager>().InstancePerHttpRequest();
builder.RegisterType<Logger>().As<ILogger>().InstancePerLifetimeScope();
// new TrainMobileUserStore(context.Get<SpaceLinxContext>())
builder.RegisterControllers(assembly).InstancePerHttpRequest();
builder.RegisterApiControllers(assembly);
builder.RegisterModelBinders(assembly).InstancePerHttpRequest();
builder.RegisterType<LogAttribute>().PropertiesAutowired();
builder.RegisterFilterProvider();
// Needed to allow property injection in custom action filters.
builder.RegisterType<ExtensibleActionInvoker>().As<IActionInvoker>();
builder.RegisterControllers(assembly).InjectActionInvoker();
When I've made these changes however, two things happen:
Firstly, the default azure mobile app default helper page disappears and I get a default page with this:
HTTP Error 403.14 - Forbidden
The Web server is configured to not list the contents of this directory.
Secondly, when I attempt to call the Help pages or AccountsController directly, a runtime exception is raised:
System.InvalidOperationException occurred
HResult=-2146233079
Message=No service registered for type 'ITableControllerConfigProvider'.Please ensure that the dependency resolver has been configured correctly.
Source=Microsoft.WindowsAzure.Mobile.Service
StackTrace:
at System.Web.Http.DependencyScopeExtensions.GetServiceOrThrow[TService](IDependencyScope services)
at Microsoft.WindowsAzure.Mobile.Service.Tables.TableControllerConfigAttribute.Initialize(HttpControllerSettings controllerSettings, HttpControllerDescriptor controllerDescriptor)
at System.Web.Http.Controllers.HttpControllerDescriptor.InvokeAttributesOnControllerType(HttpControllerDescriptor controllerDescriptor, Type type)
at System.Web.Http.Controllers.HttpControllerDescriptor.InvokeAttributesOnControllerType(HttpControllerDescriptor controllerDescriptor, Type type)
at System.Web.Http.Controllers.HttpControllerDescriptor..ctor(HttpConfiguration configuration, String controllerName, Type controllerType)
at System.Web.Http.Dispatcher.DefaultHttpControllerSelector.InitializeControllerInfoCache()
at System.Lazy`1.CreateValue()
at System.Lazy`1.LazyInitValue()
at System.Lazy`1.get_Value()
at System.Web.Http.Dispatcher.DefaultHttpControllerSelector.GetControllerMapping()
at System.Web.Http.Description.ApiExplorer.InitializeApiDescriptions()
at System.Lazy`1.CreateValue()
at System.Lazy`1.LazyInitValue()
at System.Lazy`1.get_Value()
at System.Web.Http.Description.ApiExplorer.get_ApiDescriptions()
at MyMobileApp.Mvc.Areas.HelpPage.Controllers.HelpController.Index() in C:\tfs\MyMobileApp\dotNET\Web\MyMobileApp.Mvc\Areas\HelpPage\Controllers\HelpController.cs:line 31
InnerException:
Does anyone know what the problem with this could be? Do I need to explicitly register the mobile service assemblies and if so, what's the best way of doing that?

This is now resolved.
Just to wrap this up, the basic problem was that I'd changed the WebApiConfig.Register method so that it was non standard. I'd changed it from this
public static void Register()
to this
public static void Register(HttpConfiguration config)
and was attempting to use it like one would a standard Mvc webapi configuration from Global.asax.cs
Once I changed it back, I was able to register objects using autofac in the method like this:
builder.RegisterType<ApplicationUserManager>().AsSelf().InstancePerRequest();
builder.RegisterType<ApplicationSignInManager>().AsSelf().InstancePerRequest();
builder.Register(c => new UserStore<ApplicationUser>(c.Resolve<ApplicationContext>())).AsImplementedInterfaces().InstancePerRequest();
builder.Register(c => HttpContext.Current.GetOwinContext().Authentication).As<IAuthenticationManager>();
builder.Register(c => new IdentityFactoryOptions<ApplicationUserManager>
{
DataProtectionProvider = new Microsoft.Owin.Security.DataProtection.DpapiDataProtectionProvider("Application​")
});
without any problem
thanks

Related

Why dont I need to call services.AddMediatr()?

I have an Web API application that uses both Mediatr and Autofac.
In my Startup.ConfigureServices method I have:
void ConfigureServices(IServiceCollection services)
{
var executingAssembly = Assembly.GetExecutingAssembly();
services.AddMediatR(executingAssembly);
}
In my Startup.ConfigureContainer() I have:
builder.RegisterModule(new MediatorModule());
builder.RegisterModule(new ApplicationModule("Connection String"));
In my MediatorModule based on Autofac I have:
protected override void Load(ContainerBuilder builder)
{
Guard.Against.Null(builder, nameof(builder));
builder.RegisterAssemblyTypes(typeof(IMediator).GetTypeInfo().Assembly)
.AsImplementedInterfaces();
// Register Repository class
builder.RegisterAssemblyTypes(typeof(IJobSeekerRepository<JobSeeker>).GetTypeInfo().Assembly)
.AsImplementedInterfaces();
// Register Event Service
builder.RegisterAssemblyTypes(typeof(IJobSeekerMgmtEventService).GetTypeInfo().Assembly)
.AsImplementedInterfaces();
// Commands Handlers
builder.RegisterAssemblyTypes(typeof(AddCreditCardCommand).GetTypeInfo().Assembly)
.AsClosedTypesOf(typeof(IRequestHandler<,>));
// Domain Events
builder.RegisterAssemblyTypes(typeof(JobSeekerRegisteredDomainEventRelayHandler).GetTypeInfo().Assembly)
.AsClosedTypesOf(typeof(INotificationHandler<>));
// Register Service Factory
builder.Register<ServiceFactory>(context =>
{
var componentContext = context.Resolve<IComponentContext>();
return t => { return componentContext.TryResolve(t, out var o) ? o : null; };
});
}
And my ApplicationModule is:
protected override void Load(ContainerBuilder builder)
{
builder.RegisterType(typeof(JobSeekerRepository<JobSeeker>))
.As(typeof(IJobSeekerRepository<JobSeeker>))
.InstancePerLifetimeScope();
builder.RegisterType<RequestManager>()
.As<IRequestManager>()
.InstancePerLifetimeScope();
builder.RegisterType<JobSeekerContextSeed>().InstancePerLifetimeScope();
builder.RegisterType(typeof(JobSeekerMgmtEventService))
.As(typeof(IJobSeekerMgmtEventService))
.InstancePerLifetimeScope();
// AddCreditCardCommand
builder.RegisterType(typeof(IdentifiedCommandHandler<AddCreditCardCommand, CreditCardModel>))
.As<IRequestHandler<IdentifiedCommand<AddCreditCardCommand, CreditCardModel>, CreditCardModel>>()
.AsImplementedInterfaces();
}
When I do the above and publish an event using Mediatr, it publishes the same event three times. So then I commented out the JobSeekerRegisteredDomainEventRelayHandler registration in MediatorModule. Once I did this then it only published the event twice.
I then commented out services.AddMediatr() and everything worked correctly - the event only got published once.
So now I am really confused - why does Mediatr still work even though I commented out AddMediatr()? Why did it publish the event twice when it is uncommented?
IMediatr is still available because you (also) register it via below call in your code.
builder.RegisterAssemblyTypes(typeof(IMediator).GetTypeInfo().Assembly)
.AsImplementedInterfaces();
The Mediatr GitHub wiki provides the steps to follow when e.g. using Autofac.
There's also a full example which is using the code above to register IMediatr.
That wiki shows you should make use of AddMediatr in case you're using the ASP.NET Core DI container, which you are not.
You are also making multiple calls to Autofacs RegisterAssemblyTypes method, which is a scanning one, meaning it registers all types in the corresponding assembly.
When you do that more than once for the same assembly, its IMediatr related types - e.g. command and notification handlers - fire more than once.
Make sure to make that call only once per assembly.

EF Core Migrations in Azure Function startup

According to https://learn.microsoft.com/en-us/azure/azure-functions/functions-dotnet-dependency-injection the service provider should not be used until AFTER the startup has completed running. Indeed, if I try to get a registered service it will fail.
Example:
[assembly: FunctionsStartup(typeof(Startup))]
namespace Fx {
public sealed class Startup : FunctionsStartup {
public override void Configure(IFunctionsHostBuilder builder) {
var configurationBuilder = new ConfigurationBuilder();
configurationBuilder.AddEnvironmentVariables();
var configuration = configurationBuilder.Build();
builder.Services.AddInfrastructure(configuration);
builder.Services.AddApplication();
var serviceProvider = builder.Services.BuildServiceProvider();
DependencyInjection.AddDatabase(serviceProvider).GetAwaiter().GetResult();
}
}
}
public static class DependencyInjection {
public static async Task AddDatabase(IServiceProvider services) {
using var scope = services.CreateScope();
var serviceProvider = scope.ServiceProvider;
var context = serviceProvider.GetRequiredService<ApplicationDbContext>();
//Error generated here
if (context.Database.IsSqlServer()) {
await context.Database.MigrateAsync();
}
await ApplicationDbContextSeed.SeedSamplePersonnelDataAsync(context);
}
public static IServiceCollection AddInfrastructure(
this IServiceCollection services,
IConfiguration configuration) {
services.AddDbContext<ApplicationDbContext>(options =>
options.UseSqlServer(configuration.GetConnectionString("DefaultConnection"),
b => b.MigrationsAssembly(typeof(ApplicationDbContext).Assembly.FullName)));
services.AddScoped<IApplicationDbContext>(provider => provider.GetService<ApplicationDbContext>());
return services;
}
}
This produces the following error
Microsoft.EntityFrameworkCore: No database provider has been configured for this DbContext. A provider can be configured by overriding the DbContext.OnConfiguring method or by using AddDbContext on the application service provider. If AddDbContext is used, then also ensure that your DbContext type accepts a DbContextOptions<TContext> object in its constructor and passes it to the base constructor for DbContext.
Is there a good option for migrating and seeding during startup?
The easiest way I found to run code after startup was by registering a custom IWebJobsStartup by using the WebJobsStartupAttribute (the FunctionsStartupAttribute actually also inherits from this attribute). In the WebJobsStartup class you'll need to register your extension using the AddExtension where you are able to use dependency injection and seed your database. My code:
[assembly: WebJobsStartup(typeof(DbInitializationService), "DbSeeder")]
namespace Our.Database.Seeder
{
public class DbInitializationService : IWebJobsStartup
{
public void Configure(IWebJobsBuilder builder)
{
builder.AddExtension<DbSeedConfigProvider>();
}
}
[Extension("DbSeed")]
internal class DbSeedConfigProvider : IExtensionConfigProvider
{
private readonly IServiceScopeFactory _scopeFactory;
public DbSeedConfigProvider(IServiceScopeFactory scopeFactory)
{
_scopeFactory = scopeFactory;
}
public void Initialize(ExtensionConfigContext context)
{
using var scope = _scopeFactory.CreateScope();
var dbContext = scope.ServiceProvider.GetService<YourDbContext>();
dbContext.Database.EnsureCreated();
// Further DB seeding, etc.
}
}
}
According to your code, I assume that you're building something aligned to the CleanArchitecture Repository on Github. https://github.com/jasontaylordev/CleanArchitecture
The main difference between this repo and your apporach, is that you're obviously not using ASP.NET, which is not a problem at all, but requires a little bit more configuration work.
The article already mentioned (https://markheath.net/post/ef-core-di-azure-functions) refers another blogpost (https://dev.to/azure/using-entity-framework-with-azure-functions-50aa), which briefly explains that EntityFramework Migrations are not capable of auto-discovering your migrations in an Azure Function. Therefore, you need to implement an instance of IDesignTimeDbContextFactory. I also stumbled upon it in the microsoft docs:
https://learn.microsoft.com/en-us/ef/core/cli/dbcontext-creation?tabs=dotnet-core-cli#from-a-design-time-factory
You could for example place it inside your Infrastructure\Persistence\Configurations folder. (Once again, I'm only assuming that you're following the CleanArchitecture repo structure)
DI in AZURE Functions
Caveats
A series of registration steps run before and after the runtime processes the startup class. Therefore, keep in mind the following items:
The startup class is meant for only setup and registration. Avoid using services registered at startup during the startup process. For instance, don't try to log a message in a logger that is being registered during startup. This point of the registration process is too early for your services to be available for use. After the Configure method is run, the Functions runtime continues to register additional dependencies, which can affect how your services operate.
The dependency injection container only holds explicitly registered types. The only services available as injectable types are what are setup in the Configure method. As a result, Functions-specific types like BindingContext and ExecutionContext aren't available during setup or as injectable types

How get register dbcontext in startup class for reference?

I configure my DbContext with dependency injection in Startup, actually i need send my registered dbcontext to my class handler (EventBusExtension.GetHandlers()) but i dont know how get directly the context registered:
public void ConfigureServices(IServiceCollection services)
{
...
var dbContextOptions = new DbContextOptionsBuilder<cataDBContext>()
.UseSqlServer(Configuration.GetConnectionString("SqlServerConnect"))
.Options;
//*****************************************************************************
services.AddSingleton(dbContextOptions);
// Finally register the DbContextOptions:
services.AddSingleton<cataDBContextOptions>();
// This Factory is used to create the DbContext from the custom DbContextOptions:
services.AddSingleton<IContextDBFactory, ContextDBFactory>();
// Finally Add the Applications DbContext:
services.AddDbContext<cataDBContext>();
services.AddEventBusHandling(EventBusExtension.GetHandlers(Configuration));
...
}
How i can get and send the context to EventBusExtension.GetHandlers() ?
For how to get the instance in the Startup,you could use the following code:
//1.Register the service
services.AddDbContext<MyDbContext>(options =>
options.UseSqlServer(Configuration.GetConnectionString("YourConnnectionString")));
//2.Build an intermediate service provider
var sp = services.BuildServiceProvider();
//3.Resolve the services from the service provider
var myDbContext = sp.GetService<MyDbContext>();
//4.then you could pass the myDbContext to the EventBusExtension.GetHandlers()
The accepted anser works but as mentioned in comments and this microsoft document ASP0000 calling 'BuildServiceProvider' from application code results in an additional copy of singleton services being created.
Calling BuildServiceProvider creates a second container, which can create torn singletons and cause references to object graphs across multiple containers.
A correct way to get LoginPath is to use the options pattern's built-in support for DI.
For example to use your dbContext to get all active Host URLs to apply in CORs instead of using services.AddCors(.... you can use this code :
services.AddOptions<CorsOptions>()
.Configure<ApplicationDbContext>(
(options, db) =>
{
options.AddPolicy("AllowOrigin", builder =>
builder.WithOrigins(db.Set<MyHostsEntity>().Where(e => e.IsActive).Select(e => e.Url).ToArray())
.AllowAnyMethod()
.AllowAnyHeader()
.AllowCredentials()
);
}
);

Add a self hosted SignalR server to a .Net Core Worker Service

I'm trying to extend a .NET Core Worker Service (<Project Sdk="Microsoft.NET.Sdk.Worker">) with SignalR (self hosted web app).
All the examples/tutorials/docs I have found are based on web applications, so they don't fit my case.
This is what I've done until now:
MyService Program.cs:
public class Program
{
public static void Main(string[] args)
{
CreateHostBuilder(args).Build().Run();
}
public static IHostBuilder CreateHostBuilder(string[] args) =>
Host.CreateDefaultBuilder(args)
.UseWindowsService()
.ConfigureServices((hostContext, services) =>
{
services.AddHostedService<Worker>();
DependencyBuilder.Build(hostContext, services); // inject the stuff I need in my service
// create a SignalR Web host
SignalRWebHostCreator.CreateHost(services, "http://localhost:8090", (endpoints) => {
endpoints.MapHub<MyHub>("/result");
});
});
}
and the class I want to use to "extend" the servie with a SignalR server application.
public class SignalRWebHostCreator
{
public static void CreateHost(IServiceCollection services, string serviceUrl, Action<IEndpointRouteBuilder> mapHubs)
{
services.AddSignalR(); // is it ok here ?
WebHost.CreateDefaultBuilder()
.UseUrls(serviceUrl)
.Configure((IApplicationBuilder app) => {
app.UseRouting();
app.Map("/check", config => { // just a test: it works!
config.Run(async context =>
{
context.Response.ContentType = "text/plain";
byte[] data = System.Text.Encoding.UTF8.GetBytes("OK");
await context.Response.Body.WriteAsync(data, 0, data.Length);
await context.Response.Body.FlushAsync();
});
});
app.UseEndpoints(endpoints =>
{
//endpoints.MapHub<ClockHub>("/hubs/clock"); // ERROR
//endpoints.MapHub<PingHub>("/ping"); // ERROR
//mapHubs(endpoints); // ERROR
});
})
.Build().Run();
}
}
(ClockHub is taken from MS example and PingHub is another simple Hub I tried to use instead of my "injected" Hubs)
It starts the web application properly and it responds properly to the url http://localhost:8090/check.
When I uncomment the calls to enpoint.MapHub() or my cusom Actions I have this error:
System.InvalidOperationException: 'Unable to find the required services. Please add all the required services by calling 'IServiceCollection.AddSignalR' inside the call to 'ConfigureServices(...)' in the application startup code.'
2nd try:
Seems like service.AddSignalR() is not doing its job, so I added this in SignalRWebHostCreator:
.Configure((IApplicationBuilder app) => {
app.ApplicationServices = services.BuildServiceProvider();
and now I have this error:
System.InvalidOperationException: 'Unable to resolve service for type 'System.Diagnostics.DiagnosticListener' while attempting to activate 'Microsoft.AspNetCore.Routing.EndpointRoutingMiddleware'.'
that at least has a callstack:
_This exception was originally thrown at this call stack:
Microsoft.Extensions.Internal.ActivatorUtilities.ConstructorMatcher.CreateInstance(System.IServiceProvider)
Microsoft.Extensions.Internal.ActivatorUtilities.CreateInstance(System.IServiceProvider, System.Type, object[])
Microsoft.AspNetCore.Builder.UseMiddlewareExtensions.UseMiddleware.AnonymousMethod__0(Microsoft.AspNetCore.Http.RequestDelegate)
Microsoft.AspNetCore.Builder.ApplicationBuilder.Build()
Microsoft.AspNetCore.Hosting.WebHost.BuildApplication()
Microsoft.AspNetCore.Hosting.WebHost.StartAsync(System.Threading.CancellationToken)
System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(System.Threading.Tasks.Task)
System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(System.Threading.Tasks.Task)
System.Runtime.CompilerServices.TaskAwaiter.GetResult()_
If I add services.AddSingleton(new System.Diagnostics.DiagnosticListener("diagnostic listener")); I can use endpoints.MapHub(..) without errors but now a call to http://8090/check returns a 500 internal error, so I don't think this is the right way to solve the issue.
I found some example using WebApp from Microsoft.Owin.hosting.
It requires Microsoft.Owin.4.1.0, Microsoft.Owin.Hosting.4.1.0 and Owin.1.0.0 and the last one require Net Framework 4.6.1, I don't want this.
I have included Microsoft.AspNetCore.Owin.3.1.2 (100% .NET Core) but that does not offer WebApp or something similar.
I started experiencing same error when I upgraded nuget EFCore package to new version.
I noticed, that in my bin directory, a System.Diagnostics.DiagnosticSource.dll appeared, while when I downgraded - it disappeared.
I suspect, that DiagnosticListener type from old assembly version is registered in DI container, while on activation newer version is expected. Or reverse - I didn't dig that deep.
My solution was to revert EFCore to match Product version of System.Diagnostics.DiagnosticSource.dll so it will not appear in bin folder.

Issue using AutofacWebApiDependencyResolver with OWIN and WebAPI 2.1

I can't seem to use the DependencyResolver in my OAuthAuthorizationServerProvider.
DependencyResolver.Current
returns the MVC one which I don't use, and
GlobalConfiguration.Configuration.DependencyResolver.GetService(typeof(IXXX))
throws the following error:
No scope with a Tag matching 'AutofacWebRequest' is visible from the scope in which the instance was requested. This 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 DependencyResolver.Current or ILifetimeScopeProvider.RequestLifetime, never from the container itself.
Any ideas if I am doing something wrong or I simply can't use a dependency where I'm trying?
This is what my Startup.Auth.cs looks like:
var config = new HttpConfiguration();
config.MapHttpAttributeRoutes();
config.Routes.MapHttpRoute(
name: "DefaultApi",
routeTemplate: "api/{controller}/{action}/{id}",
defaults: new { id = RouteParameter.Optional }
);
config.SuppressDefaultHostAuthentication();
config.Filters.Add(new HostAuthenticationFilter(OAuthDefaults.AuthenticationType));
var builder = new ContainerBuilder();
builder.RegisterApiControllers(Assembly.GetExecutingAssembly());
builder.RegisterType<XXX>().As<IXXX>().InstancePerRequest();
var container = builder.Build();
//I've tried both approached here!
GlobalConfiguration.Configuration.DependencyResolver = new AutofacWebApiDependencyResolver(container);
config.DependencyResolver = new AutofacWebApiDependencyResolver(container);
app.UseAutofacMiddleware(container);
app.UseAutofacWebApi(webApiConfig);
app.UseWebApi(webApiConfig);
And this is my OAuth provider code:
public class SimpleAuthorizationServerProvider : OAuthAuthorizationServerProvider
{
public SimpleAuthorizationServerProvider(string publicClientId)
{
if (publicClientId == null)
throw new ArgumentNullException("publicClientId");
_publicClientId = publicClientId;
}
public IXXX XXX
{
get { return (IXXX)(_xxx??GlobalConfiguration.Configuration.DependencyResolver.GetService(typeof(IXXX))); }
set { _xxx= value; }
}
public override async Task GrantResourceOwnerCredentials(OAuthGrantResourceOwnerCredentialsContext context)
{
//Dependency IXXX used here
}
private readonly string _publicClientId;
private IXXX _xxx;
}
You can use OwinContext.GetAutofacLifetimeScope()
See the nuget package:
http://alexmg.com/owin-support-for-the-web-api-2-and-mvc-5-integrations-in-autofac/
Funnily enough I'm working through a similar problem at the minute and using the following OSS library to achieve this: https://github.com/DotNetDoodle/DotNetDoodle.Owin.Dependencies
This is an IoC container adapter for OWIN middleware, which puts a request level container into the environment dictionary of the OWIN middleware. The container can then be accessed from within your OWIN middleware implementation from which per-request scoped services can be resolved.
This is taken from the documentation from the github repository:
public override async Task Invoke(IOwinContext context)
{
IServiceProvider requestContainer = context.Environment.GetRequestContainer();
IRepository repository = requestContainer.GetService(typeof(IRepository)) as IRepository;
// use repos
}
The following additional links may be useful for you:
A gist discussing this issue: https://gist.github.com/tugberkugurlu/9054704. Specifically this comment: https://gist.github.com/tugberkugurlu/9054704#comment-1172998
The blog entry relating to the DotNetDoodle.Owin.Dependencies library: http://www.tugberkugurlu.com/archive/owin-dependencies--an-ioc-container-adapter-into-owin-pipeline
Hope some of this may be of help to you.