I want register type, than resolve type, and then register instance using resolved values. Something like this:
//Register type:
builder.RegisterType<ValidateImportMandatoryColumns>().Named<IValidateImport>("MandatoryColumn").As<IValidateImport>();
builder.RegisterType<ValidateImportNonMandatoryColumns>().Named<IValidateImport>("NonMandatoryColumns").As<IValidateImport>();
//Resolve
var t1 = Container.ResolveNamed<IValidateImport>("MandatoryColumn");
var t2 = Container.ResolveNamed<IValidateImport>("NonMandatoryColumns");
//Create list with resolved values:
List<IValidateImport> allValidators = new List<IValidateImport>(){t1,t2};
//Register Instance:
builder.RegisterInstance(allValidators).As<List<IValidateImport>>();
This is not working. I can't resolve and than register again. Do you know how to do this with Autofac? Maybe is approach wrong, so please tell me if you have better idea. Goal is to inject list of validators with different types that use same interface.
Autofac has built in support for collection. If you want to resolve all IValidateImport, you can resolve IEnumerable<IValidateImport>
var allValidators = container.Resolve<IEnumerable<IValidateImport>>();
See Implicit Relationship Types for more information for more information.
By the way, if you want to update a container, which is not required here, you can use the following piece of code.
var builder = new ContainerBuilder();
// do some registration
var container = builder.Build();
var updater = new ContainerBuilder();
// do other registraitons
// update the container
updater.Update(container);
Related
Please checkout the below codes
using Microsoft.Extensions.DependencyInjection;
IServiceProviderFactory<IServiceCollection> serviceProviderFactory =
new DefaultServiceProviderFactory(new ServiceProviderOptions {
ValidateOnBuild = true,
ValidateScopes = true
});
IServiceCollection oldServiceCollection = new ServiceCollection();
IServiceCollection newServiceCollection =
serviceProviderFactory.CreateBuilder(oldServiceCollection);
Assert.IsTrue(oldServiceCollection == newServiceCollection);
I wanted to create a newServiceCollection base on the oldServiceCollection (then modify the newServiceCollection). However (big surprise) the ServiceProviderFactory, despite being a "Factory" with "Create.." methods, it did not create anything...
The newServiceCollection IS the oldServiceCollection. (If I modified the newServiceCollection then the oldServiceCollection will be modified as well).
I think that "DefaultServiceProviderFactory" (of Microsoft) is at fault here, do anybody know a better implementation which can help me clone the oldServiceCollection to make a newServiceCollection?
This is by design. The DefaultServiceProviderFactory isn't useful and only exists for other DI Containers to intercept the creation of IServiceCollection instances.
To make a copy, you'll have to iterate the old collection and add all ServiceDescriptors to the new one:
var newServiceCollection = new ServiceCollection();
foreach (var descriptor in oldServiceCollection)
{
newServiceCollection.Add(descriptor);
}
I'm using SolrNet with Autofac DI in my web application like this:
var solrNetModule = new SolrNetModule(ConfigurationManager.ConnectionStrings["solr"].ConnectionString);
solrNetModule.HttpWebRequestFactory = new BasicAuthHttpWebRequestFactory("****", "****");
builder.RegisterModule(solrNetModule);
My queries are quite long and sometimes end up with a 404 in Jetty, I'm pretty sure this happens because the length of the URL.
I've been reading about the SolrPostConnection and that sounds like a proper solution to my problem, but I'm having trouble implementing it in my Autofac setup.
I know the Autofac SolrNetModule integration internally uses
builder.RegisterInstance(solrConnectionInstance).As<ISolrConnection>();
But I can't figure out how to override it or .Register Autofac to use the SolrPostConnection instead.
Looks like you need to override registration for interface ISolrConnection. The main problem is that SolrNetModule doesn't provide mapping of SolrConnection to itself. Try out the example below. I added another registration of SolrConnection to make it available for injecting to contructor of PostSolrConnection without dependency loops
[Test]
public void SolrRegistrationOverride()
{
// Arrange
var builder = new ContainerBuilder();
var serverUrl = ConfigurationManager.ConnectionStrings["solr"].ConnectionString;
var httpWebRequestFactory = new BasicAuthHttpWebRequestFactory("****", "****");
var solrNetModule = new SolrNetModule(serverUrl);
solrNetModule.HttpWebRequestFactory = httpWebRequestFactory;
builder.RegisterModule(solrNetModule);
builder.RegisterType<SolrConnection>().AsSelf()
.WithParameter(new NamedParameter("serverURL", serverUrl))
.WithProperty("HttpWebRequestFactory", httpWebRequestFactory).AsSelf()
.SingleInstance();
builder.RegisterType<PostSolrConnection>().As<ISolrConnection>()
.WithParameters(new Parameter[]
{
new ResolvedParameter((prm, сtx) => prm.Name == "conn", (prm, ctx) => ctx.Resolve<SolrConnection>()),
new NamedParameter("serverUrl", serverUrl)
});
var container = builder.Build();
// Act
var conn = container.Resolve<ISolrConnection>();
// Assert
Assert.IsInstanceOf<PostSolrConnection>(conn);
}
Hope it helps.
I'm developing a WinForm application and I'm using Repository Pattern , I'm using Servicestack OrmLite for data access and Simple Injector for IoC.
In my program.cs I have 2 register 2 different OrmLiteConnectionFactory but currently I'm not able to since I can't register named... with FunQ I can do this with
container.Register<IDbConnectionFactory>("db1", _ => new OrmLiteConnectionFactory(
ConfigurationManager.ConnectionStrings["db1"].ConnectionString,
SqlServerDialect.Provider));
container.Register<IDbConnectionFactory>("db2", _ => new OrmLiteConnectionFactory(
ConfigurationManager.ConnectionStrings["db2"].ConnectionString,
SqlServerDialect.Provider));
here is mine program.cs Bootstrap method
private static void Bootstrap()
{
// Create the container as usual.
Container = new Container();
string conn1 = ConfigurationManager.ConnectionStrings["dbconn1"].ConnectionString;
string conn2 = ConfigurationManager.ConnectionStrings["dbconn2"].ConnectionString;
OrmLiteConnectionFactory connectionFactory = new OrmLiteConnectionFactory(conn1,
ServiceStack.OrmLite.SqlServer.SqlServerOrmLiteDialectProvider.Instance);
Container.RegisterSingle<OrmLiteConnectionFactory>(connectionFactory1);
OrmLiteConnectionFactory connectionFactory2 = new OrmLiteConnectionFactory(conn2,
ServiceStack.OrmLite.SqlServer.SqlServerOrmLiteDialectProvider.Instance);
// how do I register this one without a name?
Container.RegisterSingle<OrmLiteConnectionFactory>(connectionFactory2);
Container.Register<MainForm>();
}
Thanks in advance
Since you have have two different databases with each a different schema, the different OrmLiteConnectionFactory aren't interchangable. This means that if you swap them around, your system will stop working. That's an indication that you are breaking the Liskov Substitution Principle. So the general solution in that case is to give each factory its own interface and let each repository depend on that particular interface. That allows you to register them uniquely and let the container resolve the object graph without doubt.
If giving each factory its own abstraction is not an option, or convenient, another option is to register your repositories without auto-wiring. By registering your repository with a delegate, you are completely in control over what to inject into your repository. For instance:
container.Register<IOrderRepository>(() => new SqlOrderRepo(connectionFactory1));
container.Register<IUserRepository>(() => new SqlUserRepo(
connectionFactory2,
container.GetInstance<ILogger>()));
A third option is to use context based injection, were you do the following:
var f1 = Lifestyle.Singleton.CreateRegistration<IDbConnectionFactory>(
() => new OrmLiteConnectionFactory(
conn1,
ServiceStack.OrmLite.SqlServer.SqlServerOrmLiteDialectProvider.Instance),
container);
var f2 = Lifestyle.Singleton.CreateRegistration<IDbConnectionFactory>(
() => new OrmLiteConnectionFactory(
conn2,
ServiceStack.OrmLite.SqlServer.SqlServerOrmLiteDialectProvider.Instance),
container);
container.RegisterConditional(typeof(IDbConnectionFactory), f1, InjectedInto<SqlOrderRepo>);
container.RegisterConditional(typeof(IDbConnectionFactory), f2, InjectedInto<SqlUserRepo>);
// Helper method.
static bool InjectedInto<T>(PredicateContext c) =>
c.Consumer.ImplementationType == typeof(T);
Out of the box Simple Injector does not support registering keyed registrations, but there are several ways to do this as explained on this page. That page also explains why there is no built-in support for this. This is a deliberate design decision.
I have found what I think may be a bug in Autofac, but I wanted to see if anybody had a possible solution or workaround so I can make this work.
Basically I have set up a generic decorator, which works fine. The problem is that as soon as I call BeginLifetimeScope() with a configuration delegate, it erroneously resolves multiple components of the same type. If I don't use a configuration delegate with BeginLifetimeScope(), then it works correctly. Unfortunately, I need to add additional dependencies to my child scope, so not using a configuration delegate is not an option.
Here is an example that demostrates the problem:
var builder = new ContainerBuilder();
builder.RegisterType<Dependency>()
.Named<IDependency<object>>("service");
builder.RegisterGenericDecorator(
typeof(Decorator<>), typeof(IDependency<>), "service", "decorated");
var container = builder.Build();
// Returns 1
var scope1 = container.BeginLifetimeScope();
Console.WriteLine(
scope1.ResolveNamed<IEnumerable<IDependency<object>>>("decorated").Count());
// Returns 2 - notice the configAction doesn't even have to do anything
var scope2 = container.BeginLifetimeScope(r => { });
Console.WriteLine(
scope2.ResolveNamed<IEnumerable<IDependency<object>>>("decorated").Count());
And here are my fake types:
interface IDependency<T> { }
class Dependency : IDependency<object> { }
class Decorator<T> : IDependency<T> {}
Any help would be greatly appreciated!
It does just seem like a bug. As a workaround, I ended up doing the following:
var param = new TypedParameter(typeof(IDecoratorDependency), new DecoratorDependency());
var decorated = scope.ResolveNamed<IEnumerable<IDependency<object>>>("decorated", param);
That was good enough for my use case. However, this method is inflexible because it only allows me to supply parameters to the root object, in this case Decorator<T>, but not any of its dependencies.
With the new fluent MEF programming model, if I have multiple catalogs:
To which catalog do I pass my RegistrationBuilder to???
Do I need to pass RegistrationBuilder to SatisfyImportsOnce call?
Which of SatisfyImportsOnce or ComposeParts do I use? (has anything changed with this in fluent mef?)
E.g. Here is an example to llustrate my confusion (see comments on the r.h.s):
// Get pre-wired registration builder
RegistrationBuilder rb = new MefCompositionRoot().CommonRegistrationBuilder();
// Register this WCF service class
rb.ForType<LogService>().Export<LogService>();
var assembly = typeof (LogService).Assembly;
var assemblyCatalog = new AssemblyCatalog(assembly, rb); // <-- HERE?
var dirCatalog = new DirectoryCatalog("bin", rb); // <-- and HERE?
// Combine catalogs
var catalog = new AggregateCatalog();
catalog.Catalogs.Add(dirCatalog);
catalog.Catalogs.Add(assemblyCatalog);
var container = new CompositionContainer(catalog);
container.SatisfyImportsOnce(this, rb);// THIS?
container.ComposeParsts(this); ///or THIS?
You can put the RegistrationBuilder to any of the catalogs you want to use MEF Conventions with. If you want to use only the Conventions Model, then use it in all catalogs. If the DirectoryCatalog in your sample code, will load assemblies containing only Attributed exports/imports then you do not need the RegistrationBuilder. Note that both models (Attributed and Contentions) can coexist. So, you could add the RegistrationBuilder to all catalogs unless there might be a type that satisfies a rule (configured using the RegistrationBuilder) that you do not want to use in your CompositionContainer.
This overload of SatisfyImportsOnce is a riddle. From the documentation (and from a quick look at MEF's source) it looks like you can use a specific RegistrationBuilder ad-hoc. In reality I have only managed to use it with the code sample that follows.
SatisfyImportsOnce disables recomposition. Check out this excellent answer on this subject.
Sample using SatisfyImportsOnce(Object, ReflectionContext)
private static void TestLateRegistration_SameBuilder_Ok()
{
var rb = new RegistrationBuilder();
var assemblyCatalog = new AssemblyCatalog(typeof(LogService).Assembly, rb);
using (var container = new CompositionContainer(assemblyCatalog))
{
rb.ForType<LogService>().Export();
var server = new TypeImportingLogService();
//Use the same RegistrationBuilder.
container.SatisfyImportsOnce(server, rb);
}
}