How the registered services in Setup module are OFF after the installation

[hishamco]

@jtkech could you please tell me how the registered services are in OC.Setup module are removed from DI after the installation process is done. Say for instance ILocalizationFileLocationProvider

[ns8482e]

You mean after setup?

Site is configure based on setup recipe. Services are not available if module is not enabled by setup recipe.

If localization feature is not enabled by recipe then related services will not be available in the site.

[jtkech]

When a tenant is Uninitialized we create a setup context, for example here.

OrchardCore/src/OrchardCore/OrchardCore/Shell/ShellHost.cs

Line 369 in edccca0

return _shellContextFactory.CreateSetupContextAsync(settings);

This context is built with a MinimumShellDescriptor() which is only composed of the ShellFeatures (no recipe) that was registered at the host level including OC.Setup and that below we resolve through _shellFeatures.

OrchardCore/src/OrchardCore/OrchardCore/Shell/Builders/ShellContextFactory.cs

Lines 99 to 108 in edccca0

	private ShellDescriptor MinimumShellDescriptor()
	{
	// Load default features from the list of registered ShellFeature instances in the DI
	return new ShellDescriptor
	{
	SerialNumber = -1,
	Features = new List<ShellFeature>(_shellFeatures)
	};
	}

To register the setup feature we use .AddSetupFeatures("OrchardCore.Setup") which is called in AddOrchardCms().

OrchardCore/src/OrchardCore/OrchardCore/Modules/Extensions/OrchardCoreBuilderExtensions.cs

Lines 47 to 55 in edccca0

	public static OrchardCoreBuilder AddSetupFeatures(this OrchardCoreBuilder builder, params string[] featureIds)
	{
	foreach (var featureId in featureIds)
	{
	builder.ApplicationServices.AddTransient(sp => new ShellFeature(featureId));
	}
	return builder;
	}

So, if the tenant is Uninitialized the shell descriptor will have the setup feature whose startup will be executed, then when the tenant is setup a new shell descriptor is built including the features of the setup recipe.

As @ns8482e said here it depends on the setup recipe that you have used, for example if OC.Setup is part of the recipe features, its startup will be still executed, otherwise not.

When a tenant is running (has been setup) we still use the ShellFeatures registered in the DI but we only use those that are marked AlwaysEnabled, which is not the case of OC.Setup when it is added by .AddSetupFeatures() but which is the case when features are added for example by AddGlobalFeatures().

[hishamco]

You mean after setup?

After the setup process is completed

Site is configure based on setup recipe. Services are not available if module is not enabled by setup recipe.

If localization feature is not enabled by recipe then related services will not be available in the site.

I knew I was not talking about recipes here. Let me clarify OC.Setup allow users to choose the language - even the localization module is not enabled - that's because there's a services light up to enable the localization, my question is how the ILocalizationFileLocationProvider service for instance is not in DI after the tenant is ready?

@jtketch thanks for the clarification, but seems my question wasn't clear before, please refer to the above paragraph

[hishamco]

You mean after setup?

After the setup process is completed

Site is configure based on setup recipe. Services are not available if module is not enabled by setup recipe.

If localization feature is not enabled by recipe then related services will not be available in the site.

I knew I was not talking about recipes here. Let me clarify OC.Setup allow users to choose the language - even the localization module is not enabled - that's because there's a services light up to enable the localization, my question is how the ILocalizationFileLocationProvider service for instance is not in DI after the tenant is ready?

@jtketch thanks for the clarification, but seems my question wasn't clear before, please refer to the above paragraph

[jtkech]

As I understand the question both @ns8482e and me already answered, after the setup the Tenant is rebuilt but without the OC.Setup feature whose startup is not executed, so the related services are no longer part of the Tenant container.

[hishamco]

after the setup the Tenant is rebuilt but without the OC.Setup feature whose startup is not executed, so the related services are no longer part of the Tenant container.

Thanks, JT maybe the answer wasn't clear to me at the beginning :) could you please point me where the tenant is rebuilt

[jtkech]

At the end of SetupInternalAsync() => _shellHost.UpdateShellSettingsAsync() => ReloadShellContextAsync() => which replaces the current context in _shellContexts by a new ShellContext.PlaceHolder { Settings = settings }.

A PlaceHolder is not a fully built shell context but it is marked as Released, so in a subsequent request/redirection it will be built by using the shell settings that are up to date (e.g. tenant is running) and by using the shell descriptor retrieved from the database, so not a MinimumShellDescriptor but the one that was updated during the setup.

[hishamco]

Thanks a lot