Appropriate way of dealing with settings in my app?

[Linda]

In classic ASP I used to have a file called settings.asp included on every
page of my web, it consisted of a number of different settings unique to
this application, among them the database path etc.
I used to set some of the values contidional to which server executed the
script (see listing below). This way I could download the files, edit and
test run them locally, then put them back on the production server again
without having to worry about changing the paths each time.

My question now is: What would be the appropriate way of dealing with this
in .net?

/ Linda



-- partial content of settings.asp --

'--- Locally--------------------
If InStr(Request.ServerVariables("SERVER_NAME"), "mydevserver") Then
DBPATH = "DRIVER={Microsoft Access Driver (*.mdb)};
DBQ=D:\inetpub\wwwroot\customer\db\survey.mdb;"
BASE_URL = "http://mydevserver/customer/survey/"
FILE_FOLDER = "/files/"
'--- In production--------------
ElseIf InStr(Request.ServerVariables("SERVER_NAME"),
"customerserver.com") Then
DBPATH = "DRIVER={Microsoft Access Driver (*.mdb)};
DBQ=E:\webhotel\customers\customerserver.com\db\survey.mdb;"
BASE_URL = "http://www.customerserver.com/survey"
FILE_FOLDER = "/virtualfiledir/"
End If

 

[Scott Allen]

Hi Linda,

Use the app settings section in your web.config file:

<appSettings>
<add key="FileFolder" value="/foo" />
</appSettings>


You can read the settings with a little bit of code:
string fileFolder =
ConfigurationSettings.AppSettings["FileFolder"];

And you can pull environment specific settings into an external file
and reference the file from web.config:

<appSettings file="devsettings.config"/>

Where devsettings.config would contain an <appSettings> element.

http://odetocode.com/Articles/345.aspx

HTH,

 

[Brock Allen]

In web.config you can use the <appSettings> section to store your custom
application settings (note that it's case sensitive):

<configuration>
<appSettings>
<add key="SomeKey" value="SomeValue" />
</appSettings>
</configuration>

Then in you app:

string val = System.Configuration.ConfigurationSettings.AppSettings["SomeKey"];
// use val here....

 

[Juan T. Llibre]

Set all the constants/properties in a class file which
you compile to an assembly and place in the /bin
directory of your application.

It's easy to call any constant/property from that .dll

In classic ASP I used to have a file called settings.asp included on every
page of my web, it consisted of a number of different settings unique to
this application, among them the database path etc.

 

[Linda]

You guys are quick, thanks!!

I have looked briefly into the world of app settings before, and it solves
most of my problem, at least as long as I am the only developer involved.
But at some point there will be other developers, designers etc involved,
who have the bad habit of always downloading/uploading the entire app, of
course resulting in the exact same files in both (or all) locations.
Is there a way to solve that, other than educating my co-workers
Is there a way to force the use of different app setting-files for different
locations. Or maybe it is posible to refer to an app setting file in a
directory outside of the actual application folder, where those co-workers
would never think to look?

/ Linda

Hi Linda,

Use the app settings section in your web.config file:

<appSettings>
<add key="FileFolder" value="/foo" />
</appSettings>


You can read the settings with a little bit of code:
string fileFolder =
ConfigurationSettings.AppSettings["FileFolder"];

And you can pull environment specific settings into an external file
and reference the file from web.config:

<appSettings file="devsettings.config"/>

Where devsettings.config would contain an <appSettings> element.

http://odetocode.com/Articles/345.aspx

HTH,

--
Scott
http://www.OdeToCode.com/blogs/scott/

In classic ASP I used to have a file called settings.asp included on every
page of my web, it consisted of a number of different settings unique to
this application, among them the database path etc.
I used to set some of the values contidional to which server executed the
script (see listing below). This way I could download the files, edit and
test run them locally, then put them back on the production server again
without having to worry about changing the paths each time.

My question now is: What would be the appropriate way of dealing with this
in .net?

/ Linda



-- partial content of settings.asp --

'--- Locally--------------------
If InStr(Request.ServerVariables("SERVER_NAME"), "mydevserver") Then
DBPATH = "DRIVER={Microsoft Access Driver (*.mdb)};
DBQ=D:\inetpub\wwwroot\customer\db\survey.mdb;"
BASE_URL = "http://mydevserver/customer/survey/"
FILE_FOLDER = "/files/"
'--- In production--------------
ElseIf InStr(Request.ServerVariables("SERVER_NAME"),
"customerserver.com") Then
DBPATH = "DRIVER={Microsoft Access Driver (*.mdb)};
DBQ=E:\webhotel\customers\customerserver.com\db\survey.mdb;"
BASE_URL = "http://www.customerserver.com/survey"
FILE_FOLDER = "/virtualfiledir/"
End If

 

[Brock Allen]

I have a sample of building your own custom configuration sections which
uses the XmlSerializer. This is a very common technique in v1.x:

http://staff.develop.com/ballen/samples/ConfigSample.zip

You guys are quick, thanks!!

I have looked briefly into the world of app settings before, and it
solves
most of my problem, at least as long as I am the only developer
involved.
But at some point there will be other developers, designers etc
involved,
who have the bad habit of always downloading/uploading the entire app,
of
course resulting in the exact same files in both (or all) locations.
Is there a way to solve that, other than educating my co-workers
Is there a way to force the use of different app setting-files for
different
locations. Or maybe it is posible to refer to an app setting file in a
directory outside of the actual application folder, where those
co-workers
would never think to look?
/ Linda

Hi Linda,

Use the app settings section in your web.config file:

<appSettings>
<add key="FileFolder" value="/foo" />
</appSettings>
You can read the settings with a little bit of code: string
fileFolder = ConfigurationSettings.AppSettings["FileFolder"];

And you can pull environment specific settings into an external file
and reference the file from web.config:

<appSettings file="devsettings.config"/>

Where devsettings.config would contain an <appSettings> element.

http://odetocode.com/Articles/345.aspx

HTH,

--
Scott
http://www.OdeToCode.com/blogs/scott/

In classic ASP I used to have a file called settings.asp included on

every

page of my web, it consisted of a number of different settings
unique to
this application, among them the database path etc.
I used to set some of the values contidional to which server
executed the
script (see listing below). This way I could download the files,
edit and
test run them locally, then put them back on the production server
again
without having to worry about changing the paths each time.
My question now is: What would be the appropriate way of dealing
with

this

in .net?

/ Linda

-- partial content of settings.asp --

'--- Locally--------------------
If InStr(Request.ServerVariables("SERVER_NAME"), "mydevserver") Then
DBPATH = "DRIVER={Microsoft Access Driver (*.mdb)};
DBQ=D:\inetpub\wwwroot\customer\db\survey.mdb;"
BASE_URL = "http://mydevserver/customer/survey/"
FILE_FOLDER = "/files/"
'--- In production--------------
ElseIf InStr(Request.ServerVariables("SERVER_NAME"),
"customerserver.com") Then
DBPATH = "DRIVER={Microsoft Access Driver (*.mdb)};
DBQ=E:\webhotel\customers\customerserver.com\db\survey.mdb;"
BASE_URL = "http://www.customerserver.com/survey"
FILE_FOLDER = "/virtualfiledir/"
End If

 

[Kevin Spencer]

I agree with both schools of thought (web.config and class). There are uses
for both. For example, you can only store text data in the web.config. You
can store objects in a class. On the other hand, the web.config is read into
memory and remains memory-resident for the life of the app. A class can have
static methods that don't require instantiation, but often will require
instantiation. So, keep in mind what your options are, and use the
appropriate method.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.

 

[JV]

One way might be to encapsulate it into a Web User control. They are easy
to make though they don't have much visual representation at design time.
In your case that's no big deal.

Also, keep in mind that straight ASP techniques generally still work in
ASP.NET. They just might be the "old way" of doing things.

You could perhaps put a script block into each web form. They look
something like:

<script language=C# runat=server>
(code here)
</script>

You might try using the "src" attribute to refer to your asp include file.
I've never tried combining "runat=server" with a "src" attribute, but I
imagine it should work.

-jv

 

[JV]

Actually, now that I reread your post, I would recommend putting the
settings in your WEB.CONFIG file and using the folllowing collection object
to retrieve them in each page:

System.Configuration.ConfigurationSettings.AppSettings

Search for "Introduction to Dynamic Properties" in the online help for
details.

 

[David Alpert]

A couple of options occur off the top of my head:

a) configure your team's FTP software to ignore "web.config" files
(Dreamweaver does it with "cloaking", NAnt and other tools with
regular expressions of some sort)

b) if your deployments are to known servers with predictable and
stable URLs, you could hard code the settings into an assembly (dll)
with a static accessor that does some sort of switching on the current
URL.

b.1) depending on how complicated your configuration is, you may even
draft an Interface and then derive an actual configuration class for
each deployment.

then again, these 'b' options may result in deploying lots of extra
code with each setup, so a simpler solution, depending on your
toolset, would be 'a'.

David.

 

[jasonkester]

My question now is: What would be the appropriate way of dealing with this
in .net?

I'm surprised that nobody here has mentioned the Registry. ASP.NET Web
Applications are software, running in a Windows environment. The
Registry is intended as a place for software to store configuration
data.

You will be deploying your project on a number of development, test and
production servers. Each of which could be pointed at its own Database
Server, document repository, etc. If you hardcode these settings into
a web.config file in your project, you will have to A) leave them out
of source control, B) trick your deploy script into not moving .config
files, or C) hand edit them each time you deploy. Any of these is a
recipe for disaster. Sooner or later, one of your junior devs will
inadvertantly push his local copy of web.config, and suddenly you'll
find the production site pointed at your development database.

With your configuration settings in the registry, you need only set the
box up once. Set it to point at its target database, and forget it.

As to compiling settings into a class? Yikes!!! As in you need to
recompile the project just to flip the database from Test to
Production??? No thanks!

Jason
http://www.expatsoftware.com

 

[Brock Allen]

I'm surprised that nobody here has mentioned the Registry. ASP.NET

Web Applications are software, running in a Windows environment. The
Registry is intended as a place for software to store configuration
data.

Actually the registry isn't a great place for daemon software like IIS and
ASP.NET for three reasons: 1) The worker process for ASP.NET runs under an
identity whose profile isn't fully loaded, therefore HKEY_CURRENT_USER isn't
available and 2) Since HKEY_CURRENT_USER isn't available then you'd need
to have greater permissions to write to HKEY_LOCAL_MACHINE and for security
reasons we don't want this. 3) It difficult to have the admin configure this
because you'd need to have the app running. But if the app requires the settings
to be configured prior to running then how do you configure them? It's sort
of a chicken and the egg problem...

 

[Juan T. Llibre]

re:

I'm surprised that nobody here has mentioned the Registry.

Accessing the Registry is a fairly slow process.

While fine when checking to see if a user is a registered
user of an WinForms app or a Win32 application,
unless you have proof to the contrary, it seems that
checking a Registry seeting is going to have an adverse
effect on your web application's performance.

re:

As to compiling settings into a class? Yikes!!! As in you
need to recompile the project just to flip the database
from Test to Production?

I don't know what "database" you're talking about.

Maybe we are talking about different scenarios.

If you are "testing" a Web app, you compile it as a "Debug"
application and, if you are deploying your application after it
has been debugged, then you'd compile it as a "Release" application.

If you know how to change from a "Debug" environment
to a "Release" environment without recompiling, please let
us know how that can be done.

 

[jasonkester]

Accessing the Registry is a fairly slow process.

Indeed. But if you use a static constructor for your
ConnectionFactory, you only need to read from it once per IISRESET.

I don't know what "database" you're talking about.

Maybe we are talking about different scenarios.

Database Server. Sorry if I was vague. You do all your development on
one database server, all your testing on another, and host your
production data on a third. The original poster was asking how to
manage the fact that your web application will need to use separate
connection strings in each of these three environments.

If you are "testing" a Web app, you compile it as a "Debug"
application and, if you are deploying your application after it
has been debugged, then you'd compile it as a "Release" application.

I beg to differ. If you are developing and debugging a web app, you
use "Debug". Once you throw it over the wall into Test, you want it to
be a Release build, since it will go on to Production if it passes QA.

It sounds like your release process involves recompiling a bunch of
configuration changes into your .dll, flipping it to Release, and
throwing it live, untested. You should probably talk this over with
your QA department. I bet they'll have some words for you!


Jason
http://www.expatsoftware.com

 

[jasonkester]

Actually the registry isn't a great place for daemon software like IIS and
ASP.NET for three reasons[...]
Since HKEY_CURRENT_USER isn't available then you'd need
to have greater permissions to write to HKEY_LOCAL_MACHINE and for security
reasons we don't want this.

Writing configuration data? Remember, we're talking about READING
configuration data here. As in, using the Registry as an alternative
to reading connection strings and such from web.config. So yeah, of
course you'll want to stash things under HKEY_LOCAL_MACHINE. You'll
also want to avoid reading it with every page load, but that's what
static constructors are for.

3) It difficult to have the admin configure this
because you'd need to have the app running.

The Admin will only need to configure this when he is building the box.
Install Windows, Install IIS, run the .REG, and you're good to go
indefinately.

But if the app requires the settings
to be configured prior to running then how do you configure them? It's sort
of a chicken and the egg problem...

We must be talking about different things. Again, this is read-only
stuff that would otherwise be found in web.config. You're not saying
you have applications that modify their own web.config at runtime, are
you?

Jason
http://www.expatsoftware.com

 

[Juan T. Llibre]

re:

I beg to differ. If you are developing and debugging a web app, you
use "Debug". Once you throw it over the wall into Test, you want it to
be a Release build, since it will go on to Production if it passes QA.

Does that mean that, if it *doesn't* pass QA,
it goes back to the "Debug" stage ?

Or, will you continue to "test" new code in Release build mode ?

You have a penchant for semantic hair-splitting.
That's OK, though.

I have a feeling it's the same thought-process which prompted
you to hair-split on the Registry-read process being slower, too.

 

[Juan T. Llibre]

re:

Install Windows, Install IIS, run the .REG,
and you're good to go indefinately.

Until the slightest configuration change
requires that you modify the Windows Registry again.

Why introduce a complexity level which isn't *required* ?

Web.config is a perfectly good place for app settings.

If you're skittish about privacy, an assembly is *also*
a perfectly good place to place app settings.

Taking an application's settings outside an application's
AppDomain introduces retrieval/writing problems which
might be a severe application handicap down the road.

While for Windows Apps registry settings are a good idea,
for ASP.NET web applications they are unneeded and unwanted.

ASP.NET was developed, partly, to get *away* from
having to deal with Registry settings. Why go back now ?

Actually the registry isn't a great place for daemon software like IIS and
ASP.NET for three reasons[...]
Since HKEY_CURRENT_USER isn't available then you'd need
to have greater permissions to write to HKEY_LOCAL_MACHINE and for security
reasons we don't want this.

Writing configuration data? Remember, we're talking about READING
configuration data here. As in, using the Registry as an alternative
to reading connection strings and such from web.config. So yeah, of
course you'll want to stash things under HKEY_LOCAL_MACHINE. You'll
also want to avoid reading it with every page load, but that's what
static constructors are for.

3) It difficult to have the admin configure this
because you'd need to have the app running.

The Admin will only need to configure this when he is building the box.
Install Windows, Install IIS, run the .REG, and you're good to go
indefinately.

But if the app requires the settings
to be configured prior to running then how do you configure them? It's sort
of a chicken and the egg problem...

We must be talking about different things. Again, this is read-only
stuff that would otherwise be found in web.config. You're not saying
you have applications that modify their own web.config at runtime, are
you?

Jason
http://www.expatsoftware.com

 

[jasonkester]

re:

Until the slightest configuration change
requires that you modify the Windows Registry again.

I think we're using different definitions of "Configuration". I'm
talking about SERVER configuration. As in, "I am the Production
WebServer. I point at a database server named DB_LIVE." This is
information that must be set up once per box, and will never change.

Perhaps you are talking Application configuration. As in,
"HomePage=/index.aspx", "SomeAppGlobal=6", etc. This is information
that gets pushed out with every build, to every box. And yes, I'd
agree that it should be compiled into a .dll.

The nice thing about keeping your Server Configuration out of
web.config (or anything in the project) is that it's hard to
accidentily overwrite it. We've all worked with junior devs. This is
my safeguard against getting called in on a Saturday night to roll back
their mistakes.

Jason Kester
Expat Software Consulting Services
http://www.expatsoftware.com/

 

[Brock Allen]

Alright, after seeing your replies to Juan, I see what you're getting at
here. Sure, the registry would work for the things you're talking about.
But nothing says you can't make web.config read-only via DACLs. Neither one
is impervious to Junior Engineer Jimmy[1], though. My only question is why
go against the grain when the .config model is obviously the preferred method
in ASP.NET and the CLR? How would you then configure several different application
on the same machine? Or even several different sites? Not that you couldn't
with the registry, of course. It's only software, so anything's possible.
It's just that with the .config model those sorts of issues are non-issues.

As for the perf of reading, again, the existing model already caches these
settings in memory so it's unnecessary for you to build your own caching
mechanism. Or your own reload mechanism once the settings are changed. It's
myopic to think that settings never change, BTW.

I think your point of view is obviously a strong one based upon personal
experience, so if it works for your environment then that's great. There's
nothing wrong with it but I don't see enough compelling reasons in it to
recommend it to other people as a necessarily superior technique.



[1] Apologies to Mike Woodring [http://www.bearcanyon.com] (he's not Jimmy,
BTW)

Actually the registry isn't a great place for daemon software like

IIS and

ASP.NET for three reasons[...]
Since HKEY_CURRENT_USER isn't available then you'd need
to have greater permissions to write to HKEY_LOCAL_MACHINE and for security

reasons we don't want this.

Writing configuration data? Remember, we're talking about READING
configuration data here. As in, using the Registry as an alternative
to reading connection strings and such from web.config. So yeah, of
course you'll want to stash things under HKEY_LOCAL_MACHINE. You'll
also want to avoid reading it with every page load, but that's what
static constructors are for.

3) It difficult to have the admin configure this
because you'd need to have the app running.

The Admin will only need to configure this when he is building the
box.
Install Windows, Install IIS, run the .REG, and you're good to go
indefinately.

But if the app requires the settings
to be configured prior to running then how do you configure them?

It's sort

of a chicken and the egg problem...

We must be talking about different things. Again, this is read-only
stuff that would otherwise be found in web.config. You're not saying
you have applications that modify their own web.config at runtime, are
you?

Jason http://www.expatsoftware.com

 

[Juan T. Llibre]

re:

I think we're using different definitions of "Configuration".

Indeed, we are.

re:

The nice thing about keeping your Server Configuration
out of web.config...is that it's hard to accidentily overwrite it.

Normally, whatever server configuration is allowable, from within
the .NET Framework, is taken care of at the machine.config level,
not at the web.config level.

As a Server Admin, you can set things up so that sensitive
machine.config settings cannot be overwritten by junior users.

Junior users shouldn't be developing
at the web server console, anyway. ;-)

Although, in your particular development environment, writing
to the Registry simply works, I'd hesitate before making that
the preferred method of setting server-wide settings.

We left ASP for ASP.NET so that
we wouldn't have to deal with the Registry.

I wouldn't recommend going back to it,
though it might work for you.