CSLA custom configuration section (WishList?)

tmg4340 posted on Monday, January 26, 2009

I've noticed that the number of application-configuration entries for CSLA has grown to quite a few.  I'm wondering whether it's time to consider making a custom configuration section just for the CSLA entries.  Maybe it's just too much exposure to the EL, but it's been my philosophy that these non-application settings should be segregated into their own section.  I realize that some of them could be considered "application specific", but I think they fall more into the "framework driver" category.

I know that making one of these was a major PITA on .NET 1.1, but it's been made considerably easier from .NET 2.0 onward - especially considering that the CSLA entries are simple name/value entries.  Plus, developing a custom section could allow for the configuration entries to evolve beyond name/value pairs if necessary.  I'm not suggesting we have to go the whole design-time-configuration route, as the EL configuration allows.  But maybe it's something that could be worked into a release.  It also wouldn't be hard to keep the backwards compatability of allowing the settings to remain in the "AppSettings" section.

Just my $0.02 (probably more like $0.005 in the current economy...)  Thoughts?

- Scott

JoeFallon1 replied on Tuesday, January 27, 2009

Sounds like a reasonable sugestion for a future version. Especially since it allows for evolution beyond name/value pairs. There may not be a need for it now but who knows what the future holds?

RockfordLhotka replied on Tuesday, January 27, 2009

I've thought about doing this, and it does make sense.

The only drawback to it, is that it would force the editing of the config file to add the section definition, even if you otherwise wouldn't have done any configuration.

Right now all the config values have defaults, and if you fall within the defaults you don't even need app.config. But if I use a custom section, you at least have to define the section handler to avoid an exception.

Of course maybe I'm wrong about that, but that's my understanding, and so thus far I've hesitated to put that burden on framework users.

tmg4340 replied on Tuesday, January 27, 2009

Actually, that's not the case.  We developed a custom-configuration section for a version of our database provider, to let other programmers create some infrastructure classes for databases the provider didn't support OOTB.  If you ask the configuration system for an instance of your custom configuration class, and the configuration file doesn't have the custom section (or custom section definition), you just get a null reference back.

HTH

- Scott

RockfordLhotka replied on Tuesday, January 27, 2009

tmg4340 replied on Tuesday, January 27, 2009

I guess that depends on how you see CSLA shaking out configuration-wise.  There are already WPF-related configuration entries, and we've just had a discussion concerning how to handle the divergent WPF/WinForms functionality.  The impression I got from the discussion is that you're not all that keen to develop a separate set of assemblies to manage the change.  Using that line of thinking, I believe that a "single source solution" will likely entail more WPF-related configuration entries (long-term, I think that using compiler directives will break down.)  Presuming that WPF does gain wider adoption, the amount of CSLA-specific configuration information may be more likely to rise - both in amount and what "normal users" have to use.

Aside from that - and this may defeat the purpose altogether - you can allow for both AppSettings-based configuration entries and/or a custom configuration section.  Obviously, it's not recommended that you mix the techniques, but for those folks who only use a single entry, they could still put it in AppSettings.

I certainly agree that a more elegant solution that adds more work does not make a better solution.  And the argument that "Microsoft makes you do it" for such things as the EL is, to be honest, a somewhat flimsy argument.  But presuming that you switched to a custom configuration section, I don't believe the extra XML is terribly onerous.  It's boilerplate for the most part, and a web.config file requires much more boilerplate than this would.  That's certainly not a strong argument - but it's still an argument. 

- Scott

ajj3085 replied on Wednesday, January 28, 2009

See, I'd probably be one of the problem users that would WANT to mix the styles.

Some settings, like CslaAuthentication, would always be the same for me.  But in my configuration setup, I define my own sections (devel, testing, production1, production2, etc) and so there are other settings I would want in the "standard" appSettings (devel is no different than appSettings).  In this case, the configuration of the CslaDataPortal would be different in devel vs. testing vs. production1.

I have my configuration setup this way so that my deployment process can change a single line in my configuration file and be set for the appropriate environment.  This works well for me, even though I need to make Csla use my ConfigurationManager instead of the System.Configuration.ConfigurationManager on each release..

tmg4340 replied on Wednesday, January 28, 2009

Well... I'm not sure we want to tackle trying to fix the myriad issues with configuration files as they currently exist in .NET.    You've obviously developed a custom solution to deal with the biggest problem - though I'm not exactly sure how MS would solve it, to be honest.

Given that you've already customized your configuration options and created your own custom section providers, I'd expect that a custom section for CSLA configuration information would probably not be terribly helpful for you.  So being able to still use AppSettings would, I think, be of some benefit.

I suppose this shoots another hole in my suggestion, but the whole configuration-file concept is pretty difficult to cleanly deal with anyway...

- Scott

ajj3085 replied on Wednesday, January 28, 2009

I have thought about using the Enterprise Blocks for my configuration as well, because I'd rather NOT have to maintain a custom solution (not that it's changed at all since I built it).  The problem is that I geared my handling of config settings to make my deployment program (originally just a nant script) easier.  The less mucking with the .config file, the easier my deployment.  I could change it now... but I"d have to rethink my deployment process.. and I'm hesitent to do that considering how well it's been working thus far.  Not that I'll never change it... just that it's hard to justify finding time to do so.. unlike other Csla changes, which have had a dramatic impact.  Managed properties greatly reduce the amount of code (which was easy to screw up too), Linq to Sql allowed me to ditch my custom DAL solution.