[Mono-dev] [PATCH] System.Configuration.ConfigurationManager

[Elliott Draper]

Hi Chris,

Thanks for the response - I saw your plethora of commits, so am about to do a fresh checkout, give it a whirl, and I'll let you know ;-)

As for the Assembly.GetCallingAssembly() stuff, when I was looking at it and cooked up that patch, the assembly passed in to OpenExeConfigurationInternal was only used by the "user.config" stuff, and I couldn't see where that was ever actually being called anywhere else (but then again I didn't even realise you could have "user.config" files in your application data folder, so I left that bit well alone :-P).

That's interesting that it looks like web.config and exe.config handling is separate, I didn't realise that, as the MS implementation hides it quite nicely. I can't think of anything of the top of my head to resolve the usage of Assembly.GetCallingAssembly()/GetEntryAssembly(), however if I do think of anything I'll let you know.

In the meantime, I'll give the fixes you applied yesterday a go, and keep you posted as to how I get on :-)

Cheers,
Elliott


On Thu, 26 Jan 2006 23:47:01 -0500, Chris Toshok <toshok at hungry.com> wrote:
> Hey Elliott,
> 
> This was definitely something I knew was broken (and so did many others,
> who were bugging me to fix it :)
> 
> I ran a few tests on MS's implementation, raised exceptions at the right
> place, and found that most likely the web.config handling was completely
> divorced from from exe.config handling.  I've made some commits tonight
> that should fix most/all of the issues.
> 
> I'm still very unhappy with the
> Assembly.GetCallingAssembly()/GetEntryAssembly() crap..  there needs to
> be a better way to do this, but coming up with tests of MS's behavior is
> very hard.
> 
> Chris
> 
> On Thu, 2006-01-26 at 01:22 +0000, Elliott Draper wrote:
>> Hi guys,
>>
>> Attached is a patch for the System.Configuration.ConfigurationManager
> class, that fixes a bug I've found when using the NET-2.0 profile with the
> new configuration objects in a web application. The problem appeared to be
> with how the configuration file name was worked out internally within the
> ConfigurationManager - it appeared to correctly find configuration files
> for console apps etc, but couldn't work out the path to the web.config
> file for a web application. This seemed to result in it simply returning a
> null for custom configuration sections and app settings within web apps.
>>
>> The patch tidies that code up a bit, and uses
> AppDomain.CurrentDomain.SetupInformation.ConfigurationFile to retrieve the
> path to the configuration file. I've tested it with a test web app, which
> now can correctly retrieve custom configuration sections, app settings and
> the like. I've also tested a very simple console app to ensure that still
> works, which it does.
>>
>> As always, comments welcome, I haven't supplied a test case for this bug
> as it's reproducable by simply trying to retrieve an app setting or
> configuration section when using the NET-2.0 profile
> (xsp2/mod-mono-server2) on the latest version of Mono from svn head,
> however if anyone really wants my test code then give me a shout and I'll
> wrap it up for use elsewhere.
>>
>> Oh, and I'm aware that Chris Toshok is actively working on the
> Configuration 2.0 API, and so Chris, if your reading this, your probably
> the most knowledgable person when it comes to this particular bit of code
> - if you've got any comments, if I've missed the point, or if this was
> something that you knew was broken/was broken for a reason/you've fixed
> but haven't checked in yet, then let me know :-)
>>
>> Cheers,
>> Elliott
>> _______________________________________________ Mono-devel-list mailing
> list Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list