I'm writing a plugin user control for an in-house screen management system. My BO layer is built on CSLA, and I'm using CSLA'a ObjectFactory to invoke my data layer. A further bit of complexity is that I'm using the CslaObjectFactoryLoader app setting to have two sets of factory loaders: one for my test data layer and another for my live data layer. This works out nicely for doing TDD as my test project's app.config specifies its own "fake" factory loader while the my screen's app.config specifies the real data factory loader. From there, each loader will provide the appropriate real/fake object factory for the DataPortal to use.
The crux here is that CSLA is hard-coded to look at ConfigurationManager.AppSettings["CslaObjectFactoryLoader"] for the custom factory to use. Because this is a user control, I need to modify the runtime configuration file with the appropriate CslaObjectFactoryLoader value. While debugging the user control in UserControlTestContainer.exe I used a borrowed bit of code to import my CslaObjectFactoryLoader appSetting into UserControlTestContainer's config file. This method did result in saved modifications to the UserControlTestContainer.exe.config file, but I shrugged it off and continued work.
Now that I'm ready to deploy into the production screen manager I don't want to use this same "permanent copy" method because of settings collisions from other plugin screens. Is there a way to temporarily import configuration settings into the runtime configuration file? Can I "redirect" where the default implementation of ConfigurationManager.AppSettings goes?
My plan B here is to skip the custom factory loader, and allow the default ObjectFactoryLoader to invoke my data layer's object factories. I'd then modify my factories to look at an appSetting to instead use the test project's object factories. I really dislike this idea though.
Thanks all for any help.