In 1.0, I did have the access to settings encapsulated in my own
accessors, however in the formal 2.0 architecture studio generates the
code for you, so I didn't feel the need to encapsulate that again!
I do like some of the new features the 2.0 achitecture brings, but it
also has its anoying points. I guess this always happens when things
change :-(
Could you explain how to use the factory model for the new .net
settings architecture? Would this be done by ignoring the code studio
creates and re-writing access to the underlying settings using my own
settings factory?
It also doesn't resolve the fact that, in asp.net, it seems I cannot
use "off the shelf" dlls which have user settings, as they will throw
exceptions when trying to access those settings.
Tony
bruce barker (sqlwork.com) wrote:
if you had coded all access to settings was handled thru a common method
(this is a good example of why you should use abstraction), then you would
only need one if statement. also the factory model for settings is a common
choice by professional coders.
-- bruce (sqlwork.com)
"Tigger" <to**@grunt.tv> wrote in message
news:11**********************@m73g2000cwd.googlegr oups.com... I've just found out that asp.net will not allow the use of UserSettings
in its config file.
This seems to mean that I cannot use any dlls which have
UserSettings!!!!
It makes sense that asp.net does not provide the means for users to
modify settings, but it does not make sense that my application cannot
still use them.
I have a whole bunch of dlls which I use in both a windows app and
asp.net. In windows it makes sense that I provide the ability to alter
settings on a per user bases, so my apps have user settings. However
this means I cannot use those dlls in aps.net now!!!! Argh!
Is there any way around this or will I have to convert all my settings
back to application level and then add duplicates at user level and put
try/catches around the access attempts.
Tony