I think it's possible to use the System.Configuration.ConfigXmlDocument
class to load a config file other than my application's, but I doubt
that's the recommended way since that class is documented as "not
intended to be used directly from your code".

In 2.0, there is a bunch of new stuff in the System.Configuration
namespace but nothing that looks like what I need.

Is there a proper way to do this?

You could always try just the good ol' XmlDocument class since it is an XML
file.


"Brad Wood" <bradley|.wood|@ndsu|.edu> wrote in message
news:(E-Mail Removed)...
>I think it's possible to use the System.Configuration.ConfigXmlDocument
>class to load a config file other than my application's, but I doubt that's
>the recommended way since that class is documented as "not intended to be
>used directly from your code".
>
> In 2.0, there is a bunch of new stuff in the System.Configuration
> namespace but nothing that looks like what I need.
>
> Is there a proper way to do this?

I don't know much about your application, however it seems that the
applications are separated for a reason. So if one application wants
information from the other application, then the other application
should offer an interface to access that information. Don't go behind
the scenes. If this does not make sense? Can you describe your
applications or needs more? Or, let me know if you need advice on
creating the proper interface, service, ect.

Yeah, but I'm trying to avoid the DRY principle.

JV wrote:
> You could always try just the good ol' XmlDocument class since it is an XML
> file.

That makes sense in general, but in my situation it's just a matter of a
test suite needing access to some string literals (and I'd rather keep
them in one place).
Providing an interface for the test code would not be appropriate IMO.

(E-Mail Removed) wrote:
> I don't know much about your application, however it seems that the
> applications are separated for a reason. So if one application wants
> information from the other application, then the other application
> should offer an interface to access that information. Don't go behind
> the scenes. If this does not make sense? Can you describe your
> applications or needs more? Or, let me know if you need advice on
> creating the proper interface, service, ect.
>

Brad Wood wrote:
> That makes sense in general, but in my situation it's just a matter
> of a test suite needing access to some string literals (and I'd
> rather keep them in one place).
> Providing an interface for the test code would not be appropriate IMO.

If they are shared values then they should go in machine.config.

The idea behind the application config file (which has weaknesses as
well as strengths) is that it allows you to have XCOPY deployment, that
is, you deploy the app simply by copying its files.

If you share values between application files then you break XCOPY
deployment. Indeed, if you put those values in machine.config then XCOPY
deployment is also broken, but at least you know where the values should
be.

Richard
--
http://www.grimes.demon.co.uk/workshops/fusionWS.htm
http://www.grimes.demon.co.uk/workshops/securityWS.htm