Quick question
I got a factory that creates settings for me, i would like to register it in a way that i can have them resolved
Currently i got
builder.RegisterType<SettingFactory>().As<ISettingFactory>().SingleInstance();
builder.Register(x => x.Resolve<ISettingFactory>().Create<ApplicationSettings>()).As<ISetting<ApplicationSettings>>();That works fine, the factory itself already own a cashe and just uses it that way.
The only thing i would like to improve is to allow for generics on ISetting
The factory returns an ISetting<SettingType>, with the way my current code works i would need to register every settings type that exists>
Is there anyways to make it so that i can have a depenency on ISetting<SomeType> and that Autofac uses SomeType to create the ISettings, not really caring if it's registered or not (simply said, like a generic)
@alsami Thank you for the reply, and yes i think that is what im looking for. Altho correct me if im wrong.
My current code (that works) functions as follows.
public SomeClass(ISettings<ApplicationSettings> appSettings)
{
// Constructor Code
}So Autofac would have to inject a ISettings with the generic type ( in this case of type ApplicationSettings).
My current Autofac module is setup as follows.
builder.RegisterType<SettingFactory>().As<ISettingFactory>().SingleInstance();
builder.Register(x => x.Resolve<ISettingFactory>().Create<ApplicationSettings>()).As<ISetting<ApplicationSettings>>();I register a single isntance of my SettingsFactory (single as the factory own's its own cashe system).
Then i register the ISetting<ApplicationSettings> through the use of my Factory, the registration resolves my SettingsFactory and then uses it's Create method that creates an ISetting instance based on a given generic type
public ISetting<TSetting> Create<TSetting>() where TSetting : new()
{
// creates or resolves the instance (if cashe exists)
}The only thing i would like to improve is the
builder.Register(x => x.Resolve<ISettingFactory>().Create<ApplicationSettings>()).As<ISetting<ApplicationSettings>>();That the ApplicationSettings could be used as a generic, so i don't have to register every single possible setting's type, but can just say, i want a ISetting of wat ever type and let my own factory deal with the creation.
If i understand that PR correctly that generic usage would be possible in v6?
I have tried it myself with the .Net 5.0 preview:
using System;
using System.Linq;
internal class Test
{
public int TestProp { private get; init; }
public override string ToString()
{
return TestProp.ToString();
}
public static void Main()
{
// Sanity check
Console.WriteLine("Hello World!"); // Hello World!
var test = new Test { TestProp = 69 };
// Check normal way
Console.WriteLine($"Hello {test}!"); // Hello 69!
Type type = typeof(Test);
var propertyInfo = type.GetProperties().First();
var test2 = Activator.CreateInstance<Test>();
propertyInfo.SetValue(test2, 23);
// Check reflection way
Console.WriteLine($"Hello {test2}!"); // Hello 23!
}
}Seems like reflection doesn't distinguish between set and init.
Init-members on properties (C#9.0) could be an opportunity for elegant property injection. Are there any plans to utilize this new language feature in Autofac?
Currently there are no plans for init-properties and C# 9 features. Feel free to open a feature-request.
https://github.com/autofac/Autofac/issues/new?assignees=&labels=&template=feature_request.md&title=
.UseServiceProviderFactory(new AutofacServiceProviderFactory())
.ConfigureServices((hostContext, services) =>
{
services.AddHostedService<SomeService>();
});
I get "An exception was thrown while activating λ:Microsoft.Extensions.Hosting.IHostedService[] . SomeService" . DependencyResolutionException: None of the constructors found with 'Autofac.Core.Activators.Reflection.DefaultConstructorFinder. Any help will be appreciated?
IRegistrationSource for them that is updated after build with additional known concrete types before they are resolved.
@markelli The constructor of MyViewModel is not creating the ILifetimeScope instance, it is receiving a reference to the ILifetimeScope that it is being created in. Because the view model did not create the lifetime scope it should not be disposing it. The lifetime scope should be disposed by the thing that created it.
I would recommend having a read of this blog post from Nick to get a better understanding of lifetime scopes. It written some time ago but remains entirely relevant.
@alexmg If I'm creating that MyViewModel via autofac though then the only object that by default knows about that instance of ILifetimeScope would be the MyViewModel no? So where else would I dispose of it?
In this specific case I have another object like MyFirstViewModel which has a call to scope in it to scope.Resolve<MyViewModel>() but the only way it would know about the scope created for MyViewModel is if that were then exposed as a property or something of that nature.
scope you referred to in MyFirstViewModel a new child lifetime scope? If it is not and MyViewModel is resolved from the root lifetime scope disposing it would not be a good thing. You might need to provide some more example code so we can better understand your scenario.