web.config question 2.0


E

eagle

I have a web.config in my application that contains the connection strings
to all my datasources. I want to move these connection strings to another
web config up the folder hierarchy so that all my apps can use the same
connection strings. That is supposed to be how it's done, no? Instead of
the web.config being in c:\inetpub\wwwroot\myApp\web.config, I have it in
c:\inetpub\wwwroot\web.config. However, I get an "Object reference not set
to an instance of an object" error when I do this. This used to work fine
in Visual Studio 2003 .net 1.0.

My connection string is fine:

<connectionStrings>
<add name="myDB" connectionString="Data Source=mySvr;Initial
Catalog=myDB;Integrated Security=True "/>
</connectionStrings>

And this is how I retrieve in in the web app:

_sSQLConn =
System.Configuration.ConfigurationManager.ConnectionStrings("myDB").ToString

What am I doing wrong?

Thanks for your help.
 
Ad

Advertisements

N

Nathan Sokalski

Try using the complete path for the Data Source section of your
connectionstring, because you are using a relative Data Source changing the
location of your Web.config might cause a problem.
 
J

Juan T. Llibre

re:
!> I want to move these connection strings to another web config up the
!> folder hierarchy so that all my apps can use the same connection strings.

Yes, you can do that.

re:
!> That is supposed to be how it's done, no?

Not sure if that's how it's *supposed* to be, but it *can* be done.

I suppose it's a developer choice whether you do that, or not,
or whether you store each app's connection strings in each app's web.config.

re:
!>My connection string is fine:

!> <connectionStrings>
!> <add name="myDB" connectionString="Data Source=mySvr;Initial
!> Catalog=myDB;Integrated Security=True "/>
!> </connectionStrings>

Yes, that's fine...for a connection string in your app's web.config,'
but not for a web.config up the folder hierarchy.

re:
!> What am I doing wrong?

You are not configuring the root web.config as the one to retrieve the value from.

Try this :

Dim configPath As String = "/"
' this gets the root web.config
Dim config As ConnectionStringsSection = WebConfigurationManager.GetWebApplicationSection("connectionStrings")
' this declares the connectionStrings section as the one you want to retrieve the value from
Dim value as String = "The configured connectionStrings connection is : " & config.connectionstrings("myDB").ToString()
' this retrieves the value for the connection string "myDB"
 
M

Mark Rae [MVP]

I suppose it's a developer choice whether you do that, or not,
or whether you store each app's connection strings in each app's
web.config.

I always go for the latter...
Dim configPath As String = "/"
Dim config As ConnectionStringsSection =
WebConfigurationManager.GetWebApplicationSection("connectionStrings")
Dim value as String = "The configured connectionStrings connection is : "
& config.connectionstrings("myDB").ToString()

Are you sure about this? You're declaring a configPath variable to point to
the root web.config, but then not actually using it anywhere...
 
J

Juan T. Llibre

re:
!> I always go for the latter...

Indeed, that's my preference, too.

I supplied the alternative only because the OP requested the solution
for accessing a root web.config from an application down the wwwroot hierarchy.

There's an additional caveat about storing all the connection strings in the root.

You can't mix 1.1 and 2.0 apps in your site.
You *must* have either all apps being 2.0, or all apps being 1.1.

Mixing 1.1 and 2.0 apps will bring the inevitable "configuration section not recognized" error.

re:
!> Are you sure about this?

Try it... ;-)
....but only if you don't mix 1.1 and 2.0 apps in your wwwroot hierarchy.

re;
!> You're declaring a configPath variable to point to
!> the root web.config, but then not actually using it anywhere...

Here's what happened...

I tried using :

Dim configPath As String = "/"
Dim config As Configuration = WebConfigurationManager.OpenWebConfiguration(configPath)
Dim config2 As ConnectionStringsSection = WebConfigurationManager.GetWebApplicationSection("connectionStrings")
Dim value as String = "The configured connectionStrings connection is : " & config2.connectionstrings("myDB").ToString()

....but when I removed
Dim config As Configuration = WebConfigurationManager.OpenWebConfiguration(configPath)

....and used :
Dim configPath As String = "/"
Dim config As ConnectionStringsSection = WebConfigurationManager.GetWebApplicationSection("connectionStrings")
Dim value as String = "The configured connectionStrings connection is : " & config.connectionstrings("myDB").ToString()

....it *still* worked.

I did some more digging, after I posted the solution, and the answer is that,
if configPath is a null reference, the root Web.config file is opened!

So, actually, Dim configPath As String = "/" is *not* needed if you want to open the root web.config.

If retrieving a web.config in *any* virtual directory, you'll need to use :

Dim configPath As String = "/someVirtualApp"
Dim config As Configuration = WebConfigurationManager.OpenWebConfiguration(configPath)
Dim config2 As ConnectionStringsSection = WebConfigurationManager.GetWebApplicationSection("connectionStrings")
Dim value as String = "The configured connectionStrings connection is : " & config2.connectionstrings("myDB").ToString()

....that will open the web.config in /someVirtualApp and retrieve the "myDB" connection string.

If you just use :

Dim config As ConnectionStringsSection = WebConfigurationManager.GetWebApplicationSection("connectionStrings")
Dim value as String = "The configured connectionStrings connection is : " & config.connectionstrings("myDB").ToString()

....it will open the root web.config and retrieve the "myDB" connection string.

Finally, if you use :
Dim configPath As String = ""
Dim config As Configuration = WebConfigurationManager.OpenWebConfiguration(configPath)
Dim config2 As ConnectionStringsSection = WebConfigurationManager.GetWebApplicationSection("connectionStrings")
Dim value as String = "The configured connectionStrings connection is : " & config2.connectionstrings("myDB").ToString()

....it will retrieve the current app's web.config and retrieve the "myDB" connection string.

Of course, there's easier ways of accessing the current app's web.config.

These contortions are only needed when accessing
a web.config in a different application, or in the root.
 
M

Mark Rae [MVP]

You can't mix 1.1 and 2.0 apps in your site.
You *must* have either all apps being 2.0, or all apps being 1.1.
Mixing 1.1 and 2.0 apps will bring the inevitable "configuration section
not recognized" error.

Ah yes - it's all coming back to me now...
I did some more digging, after I posted the solution, and the answer is
that,
if configPath is a null reference, the root Web.config file is opened!

Ah - I didn't know that...
Dim configPath As String = "/someVirtualApp"
Dim config As Configuration =
WebConfigurationManager.OpenWebConfiguration(configPath)
Dim config2 As ConnectionStringsSection =
WebConfigurationManager.GetWebApplicationSection("connectionStrings")
Dim value as String = "The configured connectionStrings connection is : "
& config2.connectionstrings("myDB").ToString()

That's what I was expecting to see...
Of course, there's easier ways of accessing the current app's web.config.

These contortions are only needed when accessing
a web.config in a different application, or in the root.

Indeed. Because of all the hoops you have to jump through, I guess you've
got to have a *really* good reason for wanting to do this...
 
Ad

Advertisements

E

eagle

Thanks so much! It's now working! The reason we want all our apps to use
one set of connection strings is because we have several different domains
and dev, test and production servers on each of them, all with different
server names. Inevitably someone forgets to change the web.config when the
upgrade 15 different servers; best case the app gets an error, worse case
someone is hitting a test server database without realizing it. Of course,
this shouldn't happen, but it did, so we're putting as much into place as we
can to prevent that. We're starting with a main web.config on each server
to contain the connection strings for all our apps to use.
 
G

Guest

The problem you may have here is that if the folder containing your
web.config is marked as an application in IIS, that's the web.config that
takes precedence for this folder. If you were to undo the application here,
remove the web.config, and ensure that all the required items are in the one
in the parent folder, then it may work.
Peter
 
J

Juan T. Llibre

re:
!> If you were to undo the application here, remove the web.config, and ensure
!> that all the required items are in the one in the parent folder, then it may work.

....unless there's web applications running more than one version of the .Net Framework.

In that case, it's a shifty proposition, given that there's incompatible versions
of some web.config properties which will crash when implemented.
 
J

Juan T. Llibre

I should have added, Peter, that System.Configuration.ConfigurationManager
can only retrieve connection strings from within the current application.

To retrieve configuration settings from a different application, you need :
WebConfigurationManager.OpenWebConfiguration.

What you're proposing would remove the application's configuration as an application,
which might be troublesome for some application properties, if they're configured in the root application.

See my replies to Mark, in this same thread, for more explanatory concepts...and sample code.

The bottom-line answer is : always use the *current* application's
web.config to store/retrieve connection strings.
 
Ad

Advertisements

E

eagle

Thanks for all the comments, I now have a lot of information to decide what
we're going to do. We do use the current app's web.config for anything that
is specific to that application, but we've been talking about changing that
too. Others in my group want to put all the assemblies into the root
web.config, and I disagree. If you change the reference to an assembly in
the root reference newer versions of that assembly, then it could break
everything. Their argument is that we should be updating all our
applications when we get new versions. Who the heck has that kind of time.
Same argument for mixing 1.0/2.0, they think we should upgrade all our 1.0
apps.

This leads me to another question since it sounds like you all have some
better organization ideas: some in our group say the same thing about our
proprietary components, that when we get a new component, we should upgrade
all our thousands of apps to that new component. Again, who has the time.
What happens is we'll have an older app that has a bug, and it breaks when
we attempt to use the new component; however, in many cases we have no idea
what version of that component the app was originally created with, and many
times couldn't find the older one even if we knew which one we needed. All
of our apps are stored in source safe. In order to prevent this in the
future, others in our group think we should store the dll's in source safe
with the application, then we could upgrade it when we can, rather than when
we have to fix a bug that will take 30 seconds and the director is standing
over your shoulder. I've heard that storing dll's in source safe is not a
good idea. What do most people do?
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top