Last post Jan 18, 2006 06:45 PM by akashenk
Jan 06, 2006 06:12 PM|akashenk|LINK
Does anyone know of a good way to store connnection strings centrally and share them accross several ASP.NET apps? It seams the web.config file is app-specific and I don't have access to the machine.config file in a shared hosting environment. I suppose
I could store them in a database, but I would still have to store the same connection string to connect to the database in multiple places!
I like how the .NET configuration framework works with inheritance (machin.config to web.config) but it would be nice for multiple applications to be able to share some portion of a config file (like the connectionstrings in my example), by specifying some
sort of intermediate file between machine.config and the application-level files.
Jan 06, 2006 06:41 PM|josere|LINK
The solution is to store the connection strings on the web.config of the parent web app. Note that the web site root is also an app, so you can store
a web.config in there (i.e. c:\inetpub\wwwroot\web.config) which will be inherited by all apps under it.
c:\inetpub\wwwroot\web.config -> common configuration.
c:\inetpub\wwwroot\app1\web.config -> configuration for app1
c:\inetpub\wwwroot\app2\web.config -> configuration for app2.
In the case the default web site root is off limits, you can create a root app to contain all other apps and store the common configuration there.
c:\inetpub\wwwroot\myrootapp\web.config -> common configuration.
c:\inetpub\wwwroot\myrootapp\app1\web.config -> configuration for app1
c:\inetpub\wwwroot\myrootapp\app2\web.config -> configuration for app2.
Jan 06, 2006 07:30 PM|akashenk|LINK
Thanks for the reply. A couple questions...
Do the child apps still operate under there own application space, in other words, are their Application and Cache state bags still separate?
Also, how does the child's web.config know whether to "append" or "replace" a given configurationSectionElement. For instance, if I have a connectionString called "TestDB" in the parent web.config, can I add a connecitonString called "TestDB" in the child
which replaces the parent or can I only append to the existing collection? If elements can't be replaced, what about entire sections?
Jan 06, 2006 09:19 PM|josere|LINK
Yes, all apps run in ther own app domain.
The merging of the configuration may vary for different sections. As a rule, the configuration closer to the page being requested will prevail over all the values set above on the configuration hierarchy. Settings can be locked on upper levels though.
For instance, if you have this section on the root app (c:\inetpub\wwwroot\web.config):
<httpRuntime executionTimeout="100" />
and your app overrides this with (c:\inetpub\wwwroot\myapp1\web.config):
<httpRuntime executionTimeout="200" />
The value of 200 for the timeout will prevail for all pages on the myapp1 application.
With collections, the merging is little bit more complicated. The merging depends on the collection type and some collections may have overridden the way they are merged. For more information on this I suggest searching the Configuration API documentation.
In the particular case of the connection strings, if the section finds an item that already exist on the parents configuration, it will throw an exception (Parser Error Message: The entry 'TestDB' has already been added.) If you want to modify a connection
on the upper levels you can use:
<remove name="TestDB" />
<add name="TestDB" connectionString="new connection string here…"/>
Jan 06, 2006 09:26 PM|akashenk|LINK
Jan 09, 2006 04:04 PM|akashenk|LINK
Jan 09, 2006 05:48 PM|josere|LINK
There are two important pieces of information missing from you post above. One is the section name that generated the exception. The other is the path to the web.config where
that section is contained. Both pieces of data should be included in the exception (500) page. Can you please tell be what they are? Can you request the page outside VS?
Jan 09, 2006 06:14 PM|akashenk|LINK
The section was the authentication section and the error pointed to the web.config file in one of the children.
Anyway, I tried removing all the apps from my solution and adding them back and it seems to be compiling now. I haven't had the time to see if the authentication is working on the child apps but will do so soon. In general does using a parent or root app
allow for child apps to either share the parent's authentication scheme or overwrite with there own? I would think this would be one way of setting up a Single-Sign On type of a system.
Would the following work?
I could set up Forms Authentication in the root app and deny access to two of the three child apps and allow it to the other. In this way, the two that are denied will require login according to the parent's authentication settings (in essence SSO). The
other app would not require login unless it had its own authentication configuration. I imagine this might work... one queston would be how the child apps access the IPrincipal User object created by FormAuthentication configuration of the parent App.
Jan 12, 2006 06:03 PM|josere|LINK
Yes, that's the idea of the merging configuration. You can setup a parent with configuration that applies to must of your apps, and override only where it differs. This is somehow similar to object oriented inheritance.
Note though that since they are different apps (or instances you may say), they share the same configuration (DNA you may say) but separate app domains. That is internal app data structure will be probably different (i.e. Cache, etc).
Jan 16, 2006 01:16 AM|akashenk|LINK
Jan 17, 2006 06:05 PM|barrywadsworth|LINK
I am trying to do something similar. I have DotNetNuke 4.0 and a slightly modified version of the .NET 2.0 TimeTracker application called ProjectTracker. ProjectTracker ran fine before I moved it under DNN. My goal is single-sign on and streamlined administration. Intranet
users that sign into the DNN portal will be able to access the ProjectTracker and other applications without having to relogin. DNN compiles after adding ProjectTracker as an existing project under it. When I try to access
www.mydomain.com/bssPortal/ProjectTracker, I get the following error:
An error occurred during the processing of a configuration file required to service this request. Please review the specific error details below and modify your configuration file appropriately.
Parser Error Message: It is an error to use a section registered as allowDefinition='MachineToApplication' beyond application level. This error can be caused by a virtual directory not being configured as an application in IIS.
Line 9: </connectionStrings>
Line 10: <system.web>
Line 11: <siteMap defaultProvider="AspNetXmlSiteMapProvider" enabled="true">
Line 12: <providers>
Line 13: <clear />
Line 9: </connectionStrings>
Source File: C:\bw\bssPortal\Website\projecttracker\web.config Line:
Do I need to change the <siteMap defaultProvider to the DNNSQLMembershipProvider? There is also a DNN role provider and a DNN profile provider. ProjectTracker seems to be using AspNetXmlSiteMapProvider for everything. Any ideas on how
to configure this? Thanks!!
Jan 18, 2006 04:01 PM|jhouse|LINK
Does anyone know of a good way to store connnection strings centrally and share them accross several ASP.NET apps?
Another global place you can store connection strings is in the registry, it is pretty straight forward with .net - using Microsoft.Win32 namespace
Jan 18, 2006 04:14 PM|akashenk|LINK
Jan 18, 2006 05:58 PM|jhouse|LINK
Are you still having issues with conflicting configuration files?
if so I would just like to throw another idea out there, this is not an ideal solution, but could work
create a webservice, store your connection strings in the web.config of the webservice, have your code call the webservice to get the connection string, then cache the value in your web application so that you do not need to call the webservice everytime you
connect to a database.
this has a lot of downsides though - you will need to password protect the webservice, ideally you would not even want calls accessing it from anywhere but your web applications
might be more trouble than its worth?
Jan 18, 2006 06:45 PM|akashenk|LINK