An alternative is to abstract the settings that you intend to use.
So instead of changing your app.config on the fly, simply change a mock or the instance values of the configuration object.
For example:
public interface IApplicationConfiguration
{
string MaybeAFolderINeed { get; }
string MyConnectionString { get; }
}
Then you could mock it and return the relevant values.
public class ClassRequiringConfig
{
public ClassRequiringConfig(IApplicationConfiguration configuration) { ... }
public ClassRequiringConfig()
: this(new DefaultApplicationConfigurationImpl()) { ... }
}
Just a thought.
If you are interested in Domain-Driven Design you may be interested in my [Hard Edges](https://www.amazon.com/Hard-Edges-Practical-Domain-Driven-Design-ebook/dp/B076W428NG) book.
I also have a [YouTube channel](https://www.youtube.com/channel/UCtaK4nTyVCs7rc5uEul6zZw) and some repositories over on [GitHub](https://github.com/Shuttle).
Documentation:
- [Shuttle.Esb service bus](http://shuttle.github.io/shuttle-esb/)
- [Shuttle.Core infrastructure / service hosting](http://shuttle.github.io/shuttle-core/)
- [Shuttle.Recall event sourcing (experimental)](http://shuttle.github.io/shuttle-recall/)
I have over 20 years of experience in the professional arena as a developer, consultant, and architect within many industries and have provided strategies and solutions that have contributed to the successful implementation of various systems. I believe firmly in the development of quality software that empowers users to get their job done.
My current focus is on domain-driven design implemented within an event-driven architecture based on message-oriented middle ware.