Hi Barry,
I believe you may find your answer here:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/p
ersistappsettnet.asp
I have not done this, but from what I read, it seems that you can access the
ApplicationSettings via the Application class. The Application class is
public and static, so you should be able to do it.

Signature
HTH,
Kevin Spencer
Microsoft MVP
Professional Chicken Salad Alchemist
What You Seek Is What You Get.
> Hi,
>
[quoted text clipped - 32 lines]
> thanks
> Barry Mossman
Barry Mossman - 18 Jul 2006 00:52 GMT
> Hi Barry,
>
[quoted text clipped - 5 lines]
> the ApplicationSettings via the Application class. The Application class
> is public and static, so you should be able to do it.
Thanks Kevin,
The reference seems to relate to roll your own config handling mechanisms. I
was trying to use the new facilities that came with V2
(ApplicationSettingBase and
ConfigurationManager classes), however it does seem that they extend to my
situation.
I have found a solution now by following Norman Yuan's from suggestion
elsewhere in this thread.
regards
Barry Mossman
You should not read exe's app settings directly from inside dll's code.
DLL, by its nature, is code module that seperates from exe code with
consideration that it could be used by other exes (of course that are other
reasons to use dll).
If you do the app.cofg reading inside dll code, you physically tie the dll
with certain exe, the dll's reuseability is go partially or completely, even
different version of the same exe may break the dll.
Of course you can make the dll to read some type of *.cofg/settings of
certain, or predefined format, say, you can assume there are always certain
settings exist and you would handle the absence of expeted but missing
settings properly. It sounds not elegent at all and I'd never do it, but you
can do it if insist. In this case, you only need pass a file path from the
calling exe app and do you file read, maybe (write) yourself.
Again, I'd never read user/app config in dll. If you need to process
information from *.config in the dll code, you can always read them from the
calling exe app and pass the data itself to a dll object to process it (and
return back the changed data and save to *.config by the exe). In your
example,
Properties.Settings settings =
MyNameSpace.Properties.Settings.Default;
MessageBox.Show(settings.MyProperty);
MyBOObject obj=new MyBOObject()
//assign setting value to the BO object
obj.Property1=setting.MyPropertiy
//Or process the setting value
obj.TheMethod(setting.MyProperty)
> Hi,
>
[quoted text clipped - 32 lines]
> thanks
> Barry Mossman
Barry Mossman - 18 Jul 2006 00:47 GMT
>You should not read exe's app settings directly from inside dll's code.
>DLL, by its nature, is code module that seperates from exe code with
>consideration that it could be used by other exes (of course that are other
>reasons to use dll).
>If you do the app.cofg reading inside dll code, you physically tie the dll
>with certain exe, the dll's reuseability is go partially or completely,
>even different version of the same exe may break the dll.
Thanks for your help Norman.
As you say there are many reasons to use DLL's, and not all of them are
aimed at achieving reuse. I am trying to isolate my BO's from the
unnecessary risk that could be caused by all the minor expected changes to
the UI. Tying this dll to the exe isn't a great concern to me.
If I printed all the helptext associated with the new v2 user config
facilities (ApplicationSettingBase and ConfigurationManager classes and all
their members etc) I am sure that it would take more than a ream of paper.
It seems a deficiency to me that the new facilities don't allow for a dll to
easily access and update it's caller's config information. I did get
OpenMappedExeConfiguration method going, but can't get at the config
information in a type safe manner, and I got confused about permission and
locking considerations.
> Again, I'd never read user/app config in dll. If you need to process
> information from *.config in the dll code, you can always read them from
> the calling exe app and pass the data itself to a dll object to process it
> (and return back the changed data and save to *.config by the exe).
I implemented your suggestion re an interface class. I am quite pleased with
it, although my UI now has to include some complexity that I was hoping to
encapsulate into the BO dll. I guess that I will thank you if I ever reuse
the dll.
Thanks again for your help.
Barry Mossman