Adds notes
This commit is contained in:
@@ -20,6 +20,10 @@ namespace Umbraco.Core
|
||||
/// These services are all either created by the runtime or used to construct the runtime
|
||||
/// </remarks>
|
||||
public static void RegisterEssentials(this Composition composition,
|
||||
// TODO: Configs should be here too, the reason is that we only register them before the Core Runtime in aspnetcore
|
||||
// then we pre-resolve them which means that the instance re-resolved later is different... BUT if we register that
|
||||
// pre-resolved instance here again, then it will be the same instance re-resolved later, just like we are doing with
|
||||
// IDbProviderFactoryCreator.
|
||||
ILogger logger, IProfiler profiler, IProfilingLogger profilingLogger,
|
||||
IMainDom mainDom,
|
||||
AppCaches appCaches,
|
||||
|
||||
@@ -183,11 +183,17 @@ namespace Umbraco.Extensions
|
||||
x.GetServices<IEmbeddedDatabaseCreator>()
|
||||
));
|
||||
|
||||
// TODO: We want to avoid pre-resolving a container as much as possible we should not
|
||||
// be doing this any more than we are now. The ugly part about this is that the service
|
||||
// instances resolved here won't be the same instances resolved from the container
|
||||
// later once the true container is built. However! ... in the case of IDbProviderFactoryCreator
|
||||
// it will be the same instance resolved later because we are re-registering this instance back
|
||||
// into the container. This is not true for `Configs` but we should do that too, see comments in
|
||||
// `RegisterEssentials`.
|
||||
var serviceProvider = services.BuildServiceProvider();
|
||||
var configs = serviceProvider.GetService<Configs>();
|
||||
var dbProviderFactoryCreator = serviceProvider.GetRequiredService<IDbProviderFactoryCreator>();
|
||||
|
||||
|
||||
CreateCompositionRoot(services,
|
||||
configs,
|
||||
webHostEnvironment,
|
||||
|
||||
Reference in New Issue
Block a user