3

I joined a project where .NET Windows Forms application is using Settings mechanism (Project > Properties > Settings) to preserve both user settings and application settings. I have created command-line tool which uses LoadAssembly(<main application EXE file>) to perform some functionalities of main app. Upon invoking of main app's methods everything works fine except when comes to Settings – of course, because they were not loaded – settings loader was skipped.

But the application heavily relies on settings so I need to call that settings loader explicitly. But I can't find it: I have analyzed all files of blank .NET project with Settings added and loading routine is nowhere to find.

I think at worst I can workaround the problem and implement

  • locating settings file
  • explicit loading of its content

but I do not like re-inventing the wheel and especially I don't like non-transparent handling of loading of settings on .NET platform.
Is there any way to invoke built-in code used by .NET framework to load My.Settings on application start-up?

Note: Application is written in VB.NET but I think for C# the thing is the same, so do not hesitate to present C# way of thinking, if you want to.

miroxlav
  • 11,796
  • 5
  • 58
  • 99
  • If this is the settings presented as part of the project properties tab, then [this might help](http://stackoverflow.com/questions/6961929/load-project-settings-from-net-assembly). – Adam Houldsworth May 02 '14 at 10:31

2 Answers2

0

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.

Community
  • 1
  • 1
miroxlav
  • 11,796
  • 5
  • 58
  • 99
-1

System.Configuration.Configuration config = ConfigurationManager.OpenExeConfiguration (ConfigurationUserLevel.None);

PhillipH
  • 6,182
  • 1
  • 15
  • 25
  • I'm playing with this but it still looks like a small step on a longer way to go. It actually addresses part of first point (*locate settings file*) of **workaround** I proposed. As far as I undestand, the result needs to be converted to configuration file, its sections should be checked read and the all content then needs to be transferred to `My.Settings` by sort of shallow copy. In this state I cannot accept or upvote this as an answer. (1) It is indirect answer. (2) If you can leave some experience or information rather than this single-liner without any info, I'll appreciate that. Thanks! – miroxlav May 02 '14 at 15:00
  • Ok, I understand. This has some more detail here |http://stackoverflow.com/questions/1049868/how-to-load-config-file-programmatically, and here http://stackoverflow.com/questions/505566/loading-custom-configuration-files. In terms of preventing the sideways copy override the string accessor this[string propertyName] in the Settings.cs generated by vs.net and get your settings value from whatever source you see fit - the default will get from a configuration file stream, but you can override and supply from any source. – PhillipH May 02 '14 at 15:18
  • – finally I found this cannot be achieved by some trivial trick. Way is to write own settings provider always pointing to the same settings storage (and then handling read/writing of settings). – miroxlav May 03 '14 at 18:36