app.config

[Dick]

Visual Studio saves lots of values in the project's app.config file
(connection strings for datasets, My.settings, etc.), but as far as I can
see, if the project is in the middle teir, these values aren't made available
to the user because only the exe's app.config file is copied to the
application's bin folder. Is this the case or am I missing something?

For instance, I have a connection string and some directory paths that I
want the user to be able to change but which is only used by the middle teir
project. I don't really want to store them twice but I can't see another way.

[Morten Wennevik]

Re: app.config

Hi Dick,

I fear you are stuck with copying the middle tier settings to your exe.config.


On Fri, 07 Jul 2006 13:36:01 +0200, Dick <Richard.Giles@ nospam.nospamwr ote:

Visual Studio saves lots of values in the project's app.config file
(connection strings for datasets, My.settings, etc.), but as far as I can
see, if the project is in the middle teir, these values aren't made available
to the user because only the exe's app.config file is copied to the
application's bin folder. Is this the case or am I missing something?
>
For instance, I have a connection string and some directory paths that I
want the user to be able to change but which is only used by the middle teir
project. I don't really want to store them twice but I can't see another way.
>

--
Happy coding!
Morten Wennevik [C# MVP]

[Franklin M. Gauer III]

Re: app.config


It would be interesting to hear how you are implementing your 'middle tier'.
Is it rich client to webservices to datastore - or some other implementation?

--
Franklin M. Gauer III
Applications Development Manager
Integrated Companies, Inc.


"Morten Wennevik" wrote:

Hi Dick,
>
I fear you are stuck with copying the middle tier settings to your exe.config.
>
>
On Fri, 07 Jul 2006 13:36:01 +0200, Dick <Richard.Giles@ nospam.nospamwr ote:
>

Visual Studio saves lots of values in the project's app.config file
(connection strings for datasets, My.settings, etc.), but as far as I can
see, if the project is in the middle teir, these values aren't made available
to the user because only the exe's app.config file is copied to the
application's bin folder. Is this the case or am I missing something?

For instance, I have a connection string and some directory paths that I
want the user to be able to change but which is only used by the middle teir
project. I don't really want to store them twice but I can't see another way.

>
>
>
--
Happy coding!
Morten Wennevik [C# MVP]
>

[Morten Wennevik]

Re: app.config

I was thinking of libraries, within the same directory as the executable. No such thing as dll.config.


On Fri, 07 Jul 2006 19:25:02 +0200, Franklin M. Gauer III <FranklinMGauer III@discussions .microsoft.comw rote:

>
It would be interesting to hear how you are implementing your 'middle tier'.
Is it rich client to webservices to datastore - or some other implementation?
>

--
Happy coding!
Morten Wennevik [C# MVP]

[Steven Cheng[MSFT]]

Re: app.config

Thanks for all others' inputs!

Hi Richard,

As for the exe.config or web.config(for ASP.NET application), they're all
the configuration file targeting .net framework based applications. So far
..net framework doesn't provide support on assembly/dll level configuration
file. However, in .net framework 2.0, the both front-end
applications(AS P.NET or winform) or class library projects add the "project
settings" feature which can help store some configuration information.
Though the "project settings" still rely on the app.config file, those
values we define in the class library project can be easily override in the
consumer applications' app.config file(if the consumer app want to change
the original default values).

So I'm also wondering how is your middle tier components or services
currently developed. Through class library projects or webservice projects?
If it is of class library project type, you can use the consumer
application's app.config file to override any settings that are originally
configured in class library project's project settings(app.co nfig). If it
is of webservice project type, it has own web.config file for such storage.

Anyway, please feel free to post here if you have any other consideration
or ideas on this or if the scenario is quite different from the ones we've
mentioned.

Regards,

Steven Cheng
Microsoft MSDN Online Support Lead


=============== =============== =============== =====

When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.

=============== =============== =============== =====


This posting is provided "AS IS" with no warranties, and confers no rights.



Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

[Steven Cheng[MSFT]]

Re: app.config

Hi Richard,

Have you got any further idea on this issue or does our reply help you a
little on this? If there is anything else we can help, please feel free to
post here.

Regards,

Steven Cheng
Microsoft MSDN Online Support Lead


=============== =============== =============== =====

When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.

=============== =============== =============== =====


This posting is provided "AS IS" with no warranties, and confers no rights.



Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

[Dick]

Re: app.config

Hi Steven (Morten and Franklin)

Apologies, until now I had not seen your responses, maybe I forgot to check
the “Notify” box, anyway, thanks.

My middle tier projects are class libraries.

Steven, just to clarify, I assume by “project settings” you mean the
“Settings” designer accessible by opening “My Project” and selecting the
“Settings” tab - doing so also creates the “MySettings† class within the “My”
namespace. You say such values are “easily” overridden in the consumer
application’s app.config file. Do you mean there is an elegant mechanism to
achieve this or do you mean to simply duplicate them and pass them from exe
to dll as part of (for instance) “MyApplicatio n.Startup”?

The middle tier I’m working on (simplistically ) looks in a given directory,
opens the files found there and inserts the data contained therein into a
database. So I need to cache the path to the search directory and the
database connection string. The Visual Studio DataSet designer will add the
connection string to the “project settings” automatically, and saving the
path in the same place seems very sensible. So all I need now is an elegant
way to make these settings available to the application’s user.

[Steven Cheng[MSFT]]

Re: app.config

Thanks for your response Richard,

=============== ========
You say such values are ¡°easily¡± overridden in the consumer
application¡¯s app.config file. Do you mean there is an elegant mechanism
to
achieve this or do you mean to simply duplicate them and pass them from exe
to dll as part of (for instance) ¡°MyApplication .Startup¡±?
=============== =============

Here I mean we can simply copy those setting xml element from the class
library project's "app.config " into our client consumer project's
app.config file(if need overriding, we can modify it as our need).


=============== ===========
The Visual Studio DataSet designer will add the
connection string to the ¡°project settings¡± automatically, and saving the
path in the same place seems very sensible. So all I need now is an elegant
way to make these settings available to the application¡¯s user.
=============== =============
Yes, the DataSet/tableAdapter is an built-in example that use the project
settings(actual ly link to the configuration elements in the app.config) to
store some datas such as connectionstrin gs. And at the development time,
those data are stored in the class library project's app.config file. After
the class library assembly is used by a certain client application(win form
or asp.net), the classes in the class library(suppose it is a TableAdapter)
will use the following data(originally stored in class library project's
app.config file:

1. If we do not override the connection strings in consumer application's
app.config file, the TableAdapter will still use its original
connectionstrin g value(which is compiled into assembly).

2. If we override the connection string in consumer application's
app.config file as below, the TableAdapter class(in the class library
assembly) will use the updated value from the consumer application's
app.config:

<connectionStri ngs>
<add name="clslib1.P roperties.Setti ngs.NorthwindCo nnectionString"
connectionStrin g=" new connection string
value.......... ..........."
providerName="S ystem.Data.SqlC lient" />
</connectionStrin gs>

This make the settings used by class library components easy to override in
the final consumer application( at least much better than the support in
..net framework 1.1/vs 2003).

Regards,

Steven Cheng
Microsoft MSDN Online Support Lead


=============== =============== =============== =====

When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.

=============== =============== =============== =====


This posting is provided "AS IS" with no warranties, and confers no rights.



Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

[Dick]

Re: app.config

Thanks Steven, that’s not a bad solution, not perfect, but not bad either. I
tried something similar but can now see the element naming conventions must
refer to the dll project and not the exe. Obvious once you know! Thanks for
your help.

[Steven Cheng[MSFT]]

Re: app.config

Thanks for your followup Richard,

Yes, due to the current .net framework configuration design and model, the
2.0's projectSettings (rely on the app.config) would be the most appropriate
choice here though it is still far from perfect. And you're right on that
"the element naming conventions must refer to the dll project and not the
exe", this is because the classes in class library project(assembl y) only
be aware of the naming convention defined in the class library project, but
not the final consumer application.

As always, if you meet any further problem or anything we can help, please
don't hesitate to post here.

Regards,

Steven Cheng
Microsoft MSDN Online Support Lead


=============== =============== =============== =====

When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.

=============== =============== =============== =====


This posting is provided "AS IS" with no warranties, and confers no rights.



Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)