I have recently found, that default way how settings are handled does not allow nor even support my scenario. Evaluation of
ConfigurationManager.OpenExeConfiguration(
ConfigurationUserLevel.PerUserRoamingAndLocal).FilePath
gives different local settings directory when invoked from original application and when invoked from loaded assembly. Compare outputs of the same method:
When called directly:
C:\Users\Miroxlav\AppData\Local\WindowsApplication1\WindowsApplicationSetting_Url_za1afclumj0mqqjsghdpysdumjr5jd21\1.0.0.0\user.config
When called as part of loaded assembly invoked from another app:
C:\Users\Miroxlav\AppData\Local\WindowsApplication1\TestWindowsApplicationSet_Url_cxikfslvgbja50yw4lvnvugko41ou5jz\1.0.0.0\user.config
So with default settings provider even location of config file cannot be determined directly. This basically renders void all potential subsequent steps of direct retrieval of My.Settings of loaded assembly (without helper files, additional workarounds utilizing fixed settings etc. – while keeping default settings provider)
The way out can be to write custom settings provider which stores settings at universally accessible location although it is much greater overhead than I expected I will find.
Update: As a quick workaround I have implemented helper file to save config location on start of the main application. When main application's code is launched as loaded assembly, I'm restoring My.Settings from the config file found at location saved in helper file.