DbContext is not injected in Generic Repository

Mar 31, 2014 at 6:00 AM
Edited Mar 31, 2014 at 6:05 AM

I'm trying to get running my onion architecture project, I have the following folder skeleton:
|..Domain.Entities (project)
|..Infrastructure.Data (project)
MyContext.cs // Implements DbContext after EF 6.0 reverse engeneering
        internal DbContext context;
        internal IDbSet<TEntity> dbSet;

        public GenericRepository(DbContext context)    // Or MyContext ??
            this.context = context;
            this.dbSet = context.Set<TEntity>();
App.config // Here my connectionStrings for the database.

|..Infrastructure.DependencyResolution (project)
SimpleInjectorWebCommon.cs // SimpleInjector stuff.

And I have the following settings..
            container.RegisterPerWebRequest<DbContext, MyContext>();

// At GenericRepository.cs I'm using DbContext, am I oki with this? or should I use MyContext ?

                new WebRequestLifestyle());
            DependencyResolver.SetResolver(new SimpleInjectorDependencyResolver(container));
|.. Web.UI (project)
        private readonly IGenericRepository<table1> _table1Repository;

        public HomeController(IGenericRepository<table1> table1Repository)
            _table1Repository = table1Repository;
And well, on debugging the application I'm getting this:
Additional information: No connection string named 'MyContext' could be found in the application config file.

Why am I getting this ? should I follow this approach (http://simpleinjector.codeplex.com/discussions/406271) if so, how can I do it into my project? (should GenericRepository call to IConnectionManager) ?

Thanks in advance for your feedback.
-- JR
Mar 31, 2014 at 6:14 AM
Your MyContext class has probably a default constructor and that constructor passes the "MyContext" string value onto the base constructor. This value is the key of the connection string in the application config file. Make sure you have a "MyContext" entry in the <connectionStrings> section of your web.config
Marked as answer by dot_NET_Junkie on 4/15/2014 at 1:49 AM
Apr 1, 2014 at 3:37 PM
Thanks, it works perfect, before response this, I've been testing many alternatives most of them worked, but there was just one reason to keep it as you suggested, most of the projects are class libraries (app.config), and just one project defined as the root (web app in my case - web.config), then this project is in charge to call the rest and its configuration has the highest priority. If you guys has another reason please let me know.

Thank you folks.
-- JR