Hi,
currently, Implementation/ConfigurationRepository.cs is statically used by NConfigurator.config.
ConfigurationRepository.cs caches files so they are parsed only once. You cannot flush this cache.
By this, you cannot reload your merged configuration without restarting your application.
Currently there is an IO-Operation (File.Exists) within the repository - this is counter-intuitive, as all other changes to the file are ignored.
I propose the removal of the file-cache.
For the performance-argument: as the merging of the configuration files is already quite costly, at least while using DeepMerger. We should focus on caching the resulting (merged) configuration instead or let the user decide whether to cache alltogether.
At least in our applications we are caching the merged sections, because as the (Deep-)Merger is called for each GetSection() that calculation is in itself a massive performance-drainage.
MFG (sincerly)
HeikoStudt
Hi,
currently, Implementation/ConfigurationRepository.cs is statically used by NConfigurator.config.
ConfigurationRepository.cs caches files so they are parsed only once. You cannot flush this cache.
By this, you cannot reload your merged configuration without restarting your application.
Currently there is an IO-Operation (File.Exists) within the repository - this is counter-intuitive, as all other changes to the file are ignored.
I propose the removal of the file-cache.
For the performance-argument: as the merging of the configuration files is already quite costly, at least while using DeepMerger. We should focus on caching the resulting (merged) configuration instead or let the user decide whether to cache alltogether.
At least in our applications we are caching the merged sections, because as the (Deep-)Merger is called for each GetSection() that calculation is in itself a massive performance-drainage.
MFG (sincerly)
HeikoStudt