Best way to manage connection strings in a project containing both Classic ASP and ASP.Net 1.1 code?

I have a project that I have inherited that is primarily a Classic ASP application; however, intermixed in the the application are a handful of ASP.net pages. Some of the ASP.net pages are 1.1 and do not use a code behind model.

The classic ASP 开发者_StackOverflow中文版pages have a number of /include directories where there's a file for database connections. The ASP.Net pages have the connection string hard coded in in their code.

I'm trying to clean up this mess of connection strings so it's easier to manage across development environments.

Does anyone have any recommendations on how I may be able to effectively do this that will work for both Classic ASP and ASP.Net pages?

Thanks

Put a web.config file at the root of the asp classic site. ASP.net pages with no code behind (and assuming no virtual directories/applications anywhere) will use that web.config file. You can put connection strings in there. You will likely end up having two sets of strings, but that's better than many more. And if you really want to, you can write some asp classic code to read that config file.

This way is focusing at isolating connection string file from webroot for source code version control system(like svn).

Files:

c:\inetpub\config\config.xml
c:\inetpub\wwwroot\global.asa
c:\inetpub\wwwroot\onInit.asp

config.xml:

<?xml version="1.0" encoding="utf-8" ?>
<root>
  <database
      ip="XXXX"
      catalog="XXXX"
      id="XXXX"
      password="XXXX"
    />
</root>

global.asa:

<script runat="Server" language="VBScript">
    Sub Application_OnStart()        
        server.execute("/onInit.asp")
    End Sub

    Sub Application_OnEnd()
    End Sub
</script>

onInit.asp:

<% 

    dim xmlDoc, xmlPath, objNodes
    set xmlDoc = server.CreateObject("microsoft.xmldom")
    xmlDoc.async = false        
    xmlPath = Server.MapPath("/")
    xmlPath = left(xmlPath, inStrRev(xmlPath, "\")) & "config\config.xml"
    xmlDoc.load xmlPath

    set objNodes = xmlDoc.selectNodes("//database") 

    application("connectionString") = "Provider=SQLOLEDB.1;Persist Security Info=True;"_
        & "Data Source="     & objNodes.item(0).getAttribute("ip") & ";"_ 
        & "Initial Catalog=" & objNodes.item(0).getAttribute("catalog") & ";"_
        & "User ID="         & objNodes.item(0).getAttribute("id") & ";"_
        & "Password="        & objNodes.item(0).getAttribute("password")

    set objNodes = nothing
    set xmlDoc = nothing  

%>

Hmm. Guess I'm not the only one with a mess like this to clean up.

I don't have a very useful answer for you, but here's the strategy we came up with. It goes beyond your question, but hopefully it answers questions you haven't thought to ask yet. The task before you is huge, and I'd like to give you as many tips as I can on the whole process, not just the connection strings.

• completely reorganize our source code
• Completely reorganize the file structure on our web
• fix code as we need to modify it, rather than attempt to do it all at once as a big project.
• make it a stated objective to convert classic asp to asp.net (and got buy-in from our manager by justifying the project with labor savings via quicker development/maintenance.)
• created and documented standards for storing connection strings, common files, shared CSS files, etc.
• as a part of our reorganization, we have a global shared folder that we can reference from any of our projects. This contains common images, CSS, etc that is used across multiple individual project web sites, etc.
• we also specified that every web site will have a common folder with a CSS, script, and img sub-folder so that every project we work on is consistent.
• once we got our first web app re-write completed, we created a project template to make starting a new web site project very simple.

As a side effect of all the work we've done, we've gone through two upgrades in Visual Studio very painlessly simply by using the Conversion wizards. Going from VS 2003 to VS 2005, and then to VS2008 was painless.

Also, our choice in source control was made based on how we wanted to fix the mess. We were using TFS, but were limited by the relationship between TFS projects and VS solutions. We found that using Subversion allowed us greater flexibility than TFS, so we were able to lay out our source code directory structure in a much more manageable way than TFS would have allowed.