I have an application that syncs data from a MySql database to a SQL Server database.
Considering those two DbContext services:
services.AddDbContext<SqlServerContext>(options => options
.UseSqlServer(Configuration.GetConnectionString("SqlServer")));
services.AddDbContext<MySqlContext>(options => options
.UseMySql(Configuration.GetConnectionString("MySql"))
.AddInterceptors(new MySqlInterceptor()));
In the MySqlInterceptor(); I want to inject/resolve/use a Service or even the SqlServerContext, in order to get configurations to modify the CommandText.
Any ideas?
Depending on the method you are going to override you will receive CommandEventData object in the method definition which has the DbContext as property.
As to the services and configurations you can configure the interceptor before registration.
Instead of this:
services.AddDbContext<MySqlContext>(options => options
.UseMySql(Configuration.GetConnectionString("MySql"))
.AddInterceptors(new MySqlInterceptor()));
you can do
var interceptor = new MySqlInterceptor(service1, service2 ... etc);
services.AddDbContext<MySqlContext>(options => options
.UseMySql(Configuration.GetConnectionString("MySql"))
.AddInterceptors(interceptor))
How to resolve the interceptor instance:
If you need to auto-wire the dependencies of the interceptor you can do the following
services.AddTransient<Service1>();
services.AddTransient<Service2>();
services.AddTransient<MySqlInterceptor>();
// resolve the instalce of the interceptor
var serviceProvider = services.BuildServiceProvider();
var interceptor = serviceProvider.GetService<MySqlInterceptor>();
// configure mysql context and interceptor
services.AddDbContext<MySqlContext>(options => options
.UseMySql(Configuration.GetConnectionString("MySql"))
.AddInterceptors(interceptor))
As #vasil mentioned in his answer:
Depending on the method you are going to override, you will receive
CommandEventData object in the method definition which has the
DbContext as property.
In my case though, I wanted to resolve a service that used another DbContext, which proved to be cumbersome; so instead I ended up putting the settings I needed into appsettings.json, and used IConfiguration service to get the setting value and sent it to the Interceptor constructor:
services.AddDbContext<MySqlContext>(options => options
.UseMySql(Configuration.GetConnectionString("MySql"))
.AddInterceptors(new MySqlInterceptor(Configuration["SettingValue"])));
Note: If you landed on this answer and was looking for a way to resolve a service inside the ConfigureService method, without calling BuildServiceProvider which, like David Fowler says on a Github issue, you'd be:
building the container while trying to build it
and you'll end up having:
2 containers and one of them will never be disposed.
You can do what Nkosi suggests in his answer:
services.AddScoped<IService>(x =>
new Service(x.GetRequiredService<IOtherService>(),
x.GetRequiredService<IAnotherOne>(),
""));
Related
I am using the .NET Options pattern to manage my configuration.
This configuration is needed in Controllers (easy with Dependency Injection) but also to configure other services during application startup.
I would have thought that the generic Services.Configure<MyOptionsClass> method would return an instance of MyOptionsClass but unfortunately it returns an IServiceCollection?
Is there a clean way to access a bound instance of MyOptionsClass here during startup?
var builder = WebApplication.CreateBuilder(args);
// Setup MyOptionsClass for DI
var unwantedServiceCollection = builder.Services.Configure<MyOptionsClass>(builder.Configuration.GetSection(MyOptionsClass.ConfigName));
// Already need to be able to access MyOptionsClass here:
builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
.AddJwtBearer(options => { options.Authority = instanceOfMyOptionsClass.Authority; });
I had a similar need in the past and this is what I did:
var configOptions = builder.Configuration.GetSection(MyOptionsClass.ConfigName);
//You can also add data annotations to your config validate it on start
builder.Services
.AddOptions<MyOptionsClass>()
.Bind(configOptions)
.ValidateDataAnnotations()
.ValidateOnStart();
var configInstance = configOptions.Get<MyOptionsClass>();
Alternatively, you can use ServiceProviderServiceExtensions GetService<> or GetRequiredService<> to get the service you need by its type. Also, please be wary of using BuildServiceProvider which may create duplicate services as mentioned here.
Hope this helps.
Is it possible to resolve an instance of ISettingsService from the ConfigureServices method in Startup(.cs) - webapplication?
I've implemented a SettingsService which is able to retrieve the database connectionstring from an external source (secure credentials store). Within the ConfigureServices I need an instance of the ISettingsService in order to get the connectionstring and pass it to the services.AddSqlServer<MyDbContext>(connectionstring) method.
While creating the instance (using var provider = services.BuildServiceProvider(); var settings = provider.GetService<ISettingsProvider>();) Visual Studio displays the next error:
Another developer posted a similar question on StackOverflow and the answer provides a solution in case of AddSingleton/ AddTransient. What is the correct way to apply it on the AddSqlServer call? Or could you provide another solution to avoid the warning/ error message?
The Intellisense comment for .AddSqlServer actually says to use .AddDbContext if you need more control, and that's certainly the correct option.
If you refer to the source code here, you can see that all .AddSqlServer is actually doing is calling .AddDbContext and configuring the options accordingly. We can therefore write our own solution like this:
services.AddDbContext<DbContext>((serviceProvider, options) => {
var settings = serviceProvider.GetService<ISettingsProvider>();
// I don't know what methods your ISettingsProvider makes available
// so adjust accordingly
string connectionString = settings.GetSetting("connectionString");
options.UseSqlServer(connectionString);
});
Of course you can make other changes to the options here, and .UseSqlServer can also take a Action<SqlServerDbContextOptionsBuilder> (options.UseSqlServer(connectionString, opts => opts.EnableRetryOnFailure()), etc.) to further configure it.
I've started to implement health checks in my .NET Core Web API. There are two health checks, one for checking if the SQL Server has any pending migrations and the other is checking if another API is live. Both added within ConfigureServices in Startup class.
In order to do the migration check, I need to access the DbContext which has already been added to DI using AddDbContext and to check the API, I need to get the API base url from configuration which is already in DI using services.Configure<>. I use the following code to get access to the DbContext.
I'm using AspNetCore.HealthChecks.Uris package to use AddUrlGroup health check.
var sp = services.BuildServiceProvider();
var dbContext = sp.GetService<AppDbContext>();
var apis = sp.GetService<IOptions<InternalServicesConfiguration>>().Value;
services.AddHealthChecks().AddCheck("Database", new SqlDatabaseHealthCheck(dbContext), tags: new[] { "ready" })
.AddUrlGroup(new Uri(new Uri(apis.Api1BaseUri), "/health/live"), HttpMethod.Get, "API 1", HealthStatus.UnHealthy, new []{"ready"});
But services.BuildServiceProvider() shows the following warning:
Calling 'BuildServiceProvider' from application code results in an additional copy of singleton services being created. Consider alternatives such as dependency injecting services as parameters to 'Configure'
I can get the api base urls using
_configuration.GetSection("InternalServicesConfiguration").Get(typeof(InternalServicesConfiguration));
But I can't think of an alternative way to access the DbContext.
Any help much appreciated.
You can register your healthcheck like this:
services.AddHealthChecks()
.AddCheck<ExampleHealthCheck>("Database");
And then just inject your DbContext into ExampleHealthCheck class, which has to implement IHealthCheck interface
There are some healthchecks you can use directly for EF in the official docs
But if you want to write any custom or more complex checks, your best bet might be to create a class that implements the IHealthCheck interface, where you can inject anything you want.
Also from the docs about Custom health checks, an example:
public class ExampleHealthCheck : IHealthCheck
{
public Task<HealthCheckResult> CheckHealthAsync(
HealthCheckContext context,
CancellationToken cancellationToken = default(CancellationToken))
{
var healthCheckResultHealthy = true;
if (healthCheckResultHealthy)
{
return Task.FromResult(
HealthCheckResult.Healthy("A healthy result."));
}
return Task.FromResult(
HealthCheckResult.Unhealthy("An unhealthy result."));
}
}
which, as kebek alerady answered, you will register like
services.AddHealthChecks()
.AddCheck<ExampleHealthCheck>("example_health_check");
With regard to accessing IOptions (please see updated health check). Is there another way other than getting it using _configuration.GetSection("").Get<>()
You could register those options in a following way (in ConfigureServices):
services.Configure<InternalServicesConfiguration>(Configuration.GetSection("InternalServicesConfiguration"));
And to get those options, in your class just inject IOptions<InternalServicesConfiguration> options, where the options.Value prop is the configuration value
I am trying to inject AutoMapper into my MainPageModel for my Xamarin.Forms app but it crashes when loading the app.
I am setting it up like this, first init the config and then pass the implementing type to the DI container.
// Init automapper
AutoMapper.Mapper.Initialize(cfg => cfg.AddProfile(new AppProfile()));
// Add automapper to DI
FreshMvvm.FreshIOC.Container.Register<IMapper, AutoMapper.Mapper>();
// Load page (results in crash)
var page = FreshPageModelResolver.ResolvePageModel<MainPageModel> ();
The error message I get is:
TinyIoCResolutionException: Resolve failed: IConfigurationProvider
If I try to inject a regular Service with some IService interface instead, that works perfectly fine so it seems to be an issue with how FreshMvvm instanstiates the AutoMapper instance.
In most examples I have seen with injecting AutoMapper with other DI-containers, an instance is first created together with some configuration and then added to the container. Like this for an regular dot net core app:
public void ConfigureServices(IServiceCollection services)
{
// Crate config instance
var config = new MapperConfiguration(cfg =>
{
cfg.AddProfile(new YourProfile());
});
// Create a mapper from config and add instance as singleton
services.AddSingleton<IMapper>(sp => config.CreateMapper())
}
According to the docs (https://github.com/rid00z/FreshMvvm#ioc-container-lifetime-registration-options) it seems FreshMvvm does not support adding instances though, and singletons are mapped like this:
FreshMvvm.FreshIOC.Container.Register<IService, MySingletonService>();
How can I inject AutoMapper with FreshMvvm? Do I need to create a DI mapping for the IConfigurationProvider provider as well? To which implementation if so?
The documentation is not obvious on this point. It is trivial once you understand how FreshIOC works. It accepts an instance as a parameter to the Register call.
var config = new MapperConfiguration(cfg =>
{
cfg.AddProfile(new AppProfile());
});
FreshMvvm.FreshIOC.Container.Register<IMapper>(config.CreateMapper());
I need to access a service inside ConfigureServices method in Startup.cs and I do this:
services.AddScoped<ICustomService, CustomService>();
var sp = services.BuildServiceProvider();
var service = sp.GetService<ICustomService>(); // this is null
However var service above is always null.
What do i do wrong?
I had this sort of problem - I had a singleton 'settings' service which I wanted to use. I solved it by Actually creating one then registering that exact instance with DI via the overload that lets you specify a 'provider', rather than just registering the class, and adding a nice big comment explaining this:
var settingsService = new SettingsService(_hostingEnvironment);
//Add a concrete settings service which is then registered as the de facto settings service for all time.
//we need to do this as we want to use the settings in this method, and there isn't a satisfactory method to
//pull it back out of the IServiceCollection here (we could build a provider, but then that's not the same provider
//as would be build later... at least this way I have the exact class I'll be using.
services.AddSingleton<ISettingsService, SettingsService>((p) => settingsService);
..
..
..
var thing = settingsService.SomeSettingIWant();
If what you want isn't a singleton but is something transient, then I guess you can just create a concrete class for it right there? I know it probably feels a bit like cheating, but it would work fine...