feat(TypeAdapterConfig): Add IHostBuilder and IServiceCollection extensions for global configuration via appsettings right in the Hostbuilder

[DevTKSS]

PR Type:

• ✨ Feature
• 📚 Documentation content changes

What is the current behavior? 🤔

• The User needs to handle TypeAdapterConfig registation and config himself.
• Loading from Configuration is not implemented yet and would require manual actions of each user

What is the new behavior? 🚀

• Added MapsterOptions reflecting all current TypeAdapterConfig properties

• IServiceCollection.AddMapsterOptions:

  • MapsterOptions will be loaded from Configuration and are not breaking build when not provided
  • Default Section name is Mapster but can be overwritten up from UseMapster
  • When more detailed Configs are needed, the User can use Func<HostBuilderContext, IConfiguration>? configuration to provide his options section manually.

• IServiceCollection.AddTypeAdapterConfig:

  • By setting useGlobalConfig we will start with TypeAdapterConfig.GlobalSettings or if false, use a new Instance just like he would be able to do manually by now.
  • If the user inserts a TypeAdapterConfig before calling UseMapster or AddTypeAdapterConfig (both added) he can tell the extension to rather useExisting and (if found) this will be used instead
  • on the eventually found MapsterOptions will then be applyed on the evaluated instance of TypeAdapterConfig
  • the Func<TypeAdapterConfig,TypeAdapterConfig> configuration option, allows to future configure the Config and do the .NewConfig<T1,T2> like we can do by now.

• Only the first call of the added ServiceCollectionExtensions will be executed, UseMapster can be called multiple times, but up from second time only the Action<HostBuilderContext,IServiceCollection> will get executed, allowing future registration of Mapping relevant Services when needed.

PR Checklist ✅

Please check if your PR fulfills the following requirements:

• 📝 Commits must be following the Conventional Commits specification.
• 🧪 Added MS tests for the changes have been added (for features)
• 📚 Docs have been added/updated which fit documentation template (features)
• 🖼️ Validated PR Screenshots Compare Test Run results.
• ❗ Contains NO breaking changes

Other information ℹ️

Eventually we want to merge the new Docs to the existing ones. Kept them seperated so far.

[DocSvartz]

@DevTKSS 👍

By setting useGlobalConfig we will start with TypeAdapterConfig.GlobalSettings or if false, use a new Instance just like he would be able to do manually by now.

Is this a feature or a side effect?
Subtly changing a global static field doesn't seem like a good idea.

With the current approach, we can at least find what we're referencing on the globalconfig using code search.

var config = new TypeAdapterConfig();
// Or
// var config = TypeAdapterConfig.GlobalSettings;

If this is a planned feature, it needs to be described separately in the documentation, with a warning that it will change the global config, which can be called without DI, and a description of the benefits it provides.

[DevTKSS]

By setting useGlobalConfig we will start with TypeAdapterConfig.GlobalSettings or if false, use a new Instance just like he would be able to do manually by now.

Is this a feature or a side effect?
Subtly changing a global static field doesn't seem like a good idea.

var config = new TypeAdapterConfig();
// Or
// var config = TypeAdapterConfig.GlobalSettings;

I did read the docs, and they are currently instructing, to either set it with the GlobalSettings or provide a new own instance, so all this does is to enable doing the same integrated.
What do you mean by this:

With the current approach, we can at least find what we're referencing on the globalconfig using code search.

Is your point on Intellisense support? Because a Func<TypeAdapterConfig,TypeAdapterConfig> does have it just the same 🤔

If this is a planned feature, it needs to be described separately in the documentation, with a warning that it will change the global config, which can be called without DI, and a description of the benefits it provides.

No, this is one of the core features of the feature provided by the Extension, so I would appreciate if you could explain what you see me missing 👍
I did align the MapsterOptions with the defaults of the TypeAdapterConfig, which is why I would also be happier if we can find a way to (if this could be wanted, since you make me assume that it might be not the case?) map from a found existing in the IServiceCollection TypeAdapterConfig as left as ToDo on the Registration 🤔

[DocSvartz]

No, this is one of the core features of the feature provided by the Extension, so I would appreciate if you could explain what you see me missing 👍

Then you are missing tests where you use global configuration via
.UseMapster(useGlobalConfig: true)
.services.AddTypeAdapterConfig(ctx, useGlobalConfig: true, configure: config =>

Is your point on Intellisense support? Because a Func<TypeAdapterConfig,TypeAdapterConfig> does have it just the same 🤔

Taking into account the description in the wiki and the existing tests,
The default behavior assumes that you register a new TypeAdapterConfig instance in the DI or explicitly specify that you will use GlobalConfig.
In your solution the default behavior is to use the global configuration.

Therefore, the default behavior here should be the same:
useGlobalConfig = false, and if you really need to register GlobalConfig, you must specify it manually: useGlobalConfig: true

[DocSvartz]

@DevTKSS I'm talking about the following problem.

Example You didn't get the result you expected.:

class Poco
{
    string Name {get;set;} = "John" 
    string LastName {get;set;} = "Doe"
}

var result = IMapper.Map<Poco, Dto>(poco);

result.Name.ShouldBe(poco.Name) // fail Name equal Doe

if you register as GlobalConfig = false,

In this case, you will be looking for a mapping problem where you configured the DI container.

if you register as GlobalConfig = true,

In addition to the place indicated above, you will need to check the entire program code for calls:

TypeAdapterConfig<Poco, Dto>.NewConfig();
TypeAdapterConfig<Poco, Dto>.ForType();
TypeAdapterConfig.GlobalSettings.NewConfig<Poco, Dto>();
TypeAdapterConfig.GlobalSettings.NewConfig(typeof(Poco), typeof(Dto));
TypeAdapterConfig.GlobalSettings.ForType<Poco,Dto>();
TypeAdapterConfig.GlobalSettings.ForType(typeof(Poco), typeof(Dto));

// Actually, there is another way through RuleMap or Rule, i don't remember exactly anymore 😅