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.
Related
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
I am trying to unit test an Orchestrator.
//Arrange
var containter = new WindsorContainer();
var Orch = containter.Resolve<ApiOrchestrator>();// Exception Thrown here
The Constructor for the Orchestrator is:
public ApiOrchestrator(IApiWrap[] apiWraps)
{
_apiWraps = apiWraps;
}
The registration is
public class IocContainer : IWindsorInstaller
{
public void Install(IWindsorContainer container, IConfigurationStore store)
{
container.Register(Component.For<FrmDataEntry>().LifestyleTransient());
container.Register(Component.For<ApiOrchestrator>().LifestyleTransient());
container.Register(Component.For<IApiWrap>().ImplementedBy<ClassA>().LifestyleTransient());
container.Register(Component.For<IApiWrap>().ImplementedBy<ClassB>().LifestyleTransient());
}
}
The IocContainer is in the project being tested but the namespace is referenced and I can new up an Orchestrator. I want it to just give me the array of all registered IApiWrap.
Being new to Castle I don't understand what's missing. Code fix would be nice, but I'd really like to know why the container doesn't seem to have the orchestrator registered.
OK so 3 things are missing
A reference to Castle.Windsor.Installer
A call from container to installer to 'go look for' all of the registered classes.
The installer also needed to add a sub resolver to make a collection of the classes since a specific collection was not registered and a Collection of IApiWrap is required by the orchestrator.
The Installer change
public class IocContainer : IWindsorInstaller
{
public void Install(IWindsorContainer container, IConfigurationStore store)
{
//New Line
container.Kernel.Resolver.AddSubResolver(
new CollectionResolver(container.Kernel, true));
container.Register(Component.For<FrmDataEntry>().LifestyleTransient());
container.Register(Component.For<ApiOrchestrator>().LifestyleTransient());
container.Register(Component.For<IApiWrap>().ImplementedBy<SettledCurveImportCommodityPriceWrap>().LifestyleTransient());
container.Register(Component.For<IApiWrap>().ImplementedBy<ForwardCurveImportBalmoPriceWrap>().LifestyleTransient());
}
}
The Test / Resolving Change
//Arrange
var container = new WindsorContainer();
//New Line
container.Install(FromAssembly.InDirectory(new AssemblyFilter("","EkaA*") ));
var Orch = container.Resolve<ApiOrchestrator>();
Now it works, though any further explanation or correction of what the code is doing is welcome.
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
I'm currently using SOA, I've a bunch of Service, (ArticleService, CommentService, UserService, etc..)
I also have a ConfigurationService which is filled from an XML configuration file.
I'm using Zend Framework.
THis configuration service is needed in some of my service, and I'm using dependency injection, is it a good practice, to add ConfigurationService in constructor of most my Service to be able to fetch global configuration?
Thank you for your feedbacks.
I would say, no, don't pass the config container - neither as a service nor as an array nor a Zend_Config instance - in the constructor of your other services. I would keep the injection (whether by constructor or by setter) for those services focused on the actual objects/collaborators/data they actually need.
So, for example, an ArticleService might depend upon an ArticleRepository interface/object or on an ArticleMapper or on a db adapter. Let the constructor/setter signatures for the ArticleService reflect what it truly needs.
Instead, what I would do is during Bootstrap, create some kind of factory object - perhaps as an application resource - that accepts in its constructor your config data/object/service (or even better, the bootstrap instance itself, from which you could get, not just your config data, but also any application resources, like a db adapter, that were created during the bootstrap process). Then write methods on your factory object that create/deliver the other services you need. Internally, the factory maintains a registry of already created services so that it can lazy-create instances where required.
A snippet of what I have in mind might be as follows:
Bootstrap snippet:
class Bootstrap extends Zend_Application_Bootstrap_Bootstrap
{
protected function _initFactory()
{
$factory = new My_Factory($this);
return $factory;
}
}
Then the factory:
class My_Factory
{
protected $_registry;
protected $_bootstrap;
public function __constructor($bootstrap)
{
$this->_bootstrap = $bootstrap;
}
public function getDbAdapter()
{
if (!isset($this->_registry['dbAdapter']){
$this->_bootstrap->bootstrap('db'); // probably using app resource
$this->_registry['dbAdapter'] = $This->_bootstrap->getResource('db');
}
return $this->_registry['dbAdapter'];
}
public function getArticleService()
{
if (!isset($this->_registry['articleService']){
$dbAdapter = $this->getDbAdapter();
$this->_registry['articleService'] = new My_ArticleService($dbAdapter);
}
return $this->_registry['articleService'];
}
public function getTwitterService()
{
if (!isset($this->_registry['twitterService']){
$options = $this->_bootstrap->getOptions();
$user = $options['twitter']['user'];
$pass = $options['twitter']['pass'];
$this->_registry['twitterService'] = new My_TwitterService($user, $pass);
}
return $this->_registry['twitterService'];
}
}
Then in a controller, you could grab an ArticleService instance:
class SomeController extends Zend_Controller_Action
{
protected $_factory;
public function init()
{
$this->_factory = $this->getInvokeArg('bootstrap')->getResource('factory');
}
public function someAction()
{
$articleService = $this->_factory->getArticleService();
$this->view->articles = $articleService->getRecentArticles(5); // for example
}
}
The upshot here is that each service explicitly identifies the collaborators it needs and the factory is a single place that takes care of creating/injecting all those collaborators.
Finally, I confess that I am just spitballing here. To me, this is essentially a rudimentary dependency injection container; in that sense, using a fully-featured DIC - perhaps the Symfony DIC or the new Zend\Di package in ZF2 - might be better. But after many months of struggling with all the best-practice recommendations to inject your dependencies, this is what I have come up with. If it's goofy or just plain wrong, please (please!) straighten me out. ;-)
I downloaded the fairly new Ninject 2.0 and Ninject.Web.Mvc (targeting mvc2) sources today, and successfully built them against .NET 4 (release configuration). When trying to run an application using Ninject 2.0, i keep getting 404 errors and I can't figure out why.
This is my global.asax.cs (slightly shortified, for brevity):
using ...
using Ninject;
using Ninject.Web.Mvc;
using Ninject.Modules;
namespace Booking.Web
{
public class MvcApplication : NinjectHttpApplication
{
protected override void OnApplicationStarted()
{
Booking.Models.AutoMapperBootstrapper.Initialize();
RegisterAllControllersIn(Assembly.GetExecutingAssembly());
base.OnApplicationStarted();
}
protected void RegisterRoutes(RouteCollection routes)
{
...
routes.MapRoute(
"Default",
"{controller}/{action}/{id}",
new { controller = "Entry", action = "Index", id = "" }
);
}
protected override IKernel CreateKernel()
{
INinjectModule[] mods = new INinjectModule[] {...};
return new StandardKernel(mods);
}
}
}
The EntryController exists, and has an Index method that simply does a return View(). I have debugged, and verified that the call to RegisterAllControllersIn() is executed. I have also tried to use Phil Haacks Routing debugger but I still get a 404.
What do I do to find the cause of this?
Are your routes being registered? Is that being called from the base class?
Also make sure that you are registering your controllers properly. I'm not sure how Ninject's controller factory expects it, but it might require a specific name or something.