Le meilleur moyen de gérer les chaînes de connexion dans un projet contenant à la fois du code Classic ASP et ASP.Net 1.1?

Question

J'ai un projet dont j'ai hérité qui est principalement une application ASP classique; Cependant, l'application contient une poignée de pages ASP.net. Certaines des pages ASP.net sont 1.1 et n’utilisent pas de code après modèle.

Les pages ASP classiques possèdent un certain nombre de répertoires / include contenant un fichier pour les connexions à la base de données. La chaîne de connexion des pages ASP.Net est codée en dur dans leur code.

J'essaie de nettoyer ce fouillis de chaînes de connexion afin qu'il soit plus facile à gérer dans les environnements de développement.

Quelqu'un at-il des recommandations sur la manière dont je pourrais être capable de le faire efficacement et qui fonctionneraient à la fois pour les pages ASP classiques et ASP.Net?

Merci

Answer 1

Placez un fichier web.config à la racine du site asp classique. Les pages ASP.net sans code derrière (et en supposant qu'il n'y ait aucun répertoire ou application virtuelle) utiliseront ce fichier web.config. Vous pouvez y mettre des chaînes de connexion. Vous finirez probablement par avoir deux jeux de chaînes, mais c'est mieux que beaucoup d'autres. Et si vous voulez vraiment, vous pouvez écrire du code asp classique pour lire ce fichier de configuration.

Answer 2

Cette façon de faire consiste à isoler le fichier de chaîne de connexion de la racine Web pour le système de contrôle de version du code source (comme svn).

Fichiers:

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  

%>

Answer 3

Hmm. Je suppose que je ne suis pas le seul à avoir un gâchis comme ça à nettoyer.

Je n'ai pas de réponse très très utile pour vous, mais voici la stratégie que nous avons mise au point. Cela va au-delà de votre question, mais j'espère que cela répond à des questions que vous n'avez pas encore pensé à poser. La tâche qui vous attend est énorme et je voudrais vous donner autant de conseils que possible sur l'ensemble du processus, pas seulement les chaînes de connexion.

• réorganiser complètement notre code source
• Réorganisez complètement la structure de fichier sur notre site Web
• corrigez le code car nous devons le modifier , plutôt que d'essayer de tout faire en même temps en tant que grand projet.
• fixez pour objectif déclaré de convertir un asp classique en asp.net (et obtenez l’assentiment de notre responsable en justifiant le projet par des économies de main-d’œuvre via un développement / une maintenance plus rapide.)
• normes créées et documentées pour le stockage des chaînes de connexion, des fichiers communs, des fichiers CSS partagés, etc.
• dans le cadre de notre réorganisation, nous disposons d'un dossier partagé global que nous pouvons référencer à partir de n'importe lequel de nos projets. Il contient des images communes, CSS, etc. utilisées sur plusieurs sites Web de projets individuels, etc.
• nous avons également spécifié que chaque site Web aura un dossier commun avec un sous-dossier CSS, script et img, de manière à ce que chaque projet sur lequel nous travaillons soit cohérent.
• une fois que notre première application Web a été réécrite, nous avons créé un modèle de projet pour simplifier le démarrage d'un nouveau projet de site Web.

Comme effet secondaire de tout le travail que nous avons effectué, nous avons effectué deux mises à niveau dans Visual Studio en toute simplicité, simplement à l'aide des assistants de conversion. Passer de VS 2003 à VS 2005, puis à VS2008 s’est fait sans douleur.

De plus, notre choix en matière de contrôle de code source a été fait en fonction de la manière dont nous voulions réparer le désordre. Nous utilisions TFS, mais nous étions limités par la relation entre les projets TFS et les solutions VS. Nous avons constaté que l’utilisation de Subversion nous permettait une plus grande flexibilité que TFS. Nous avons donc été en mesure de structurer notre structure de répertoires de code source de façon beaucoup plus simple à gérer que ce que TFS aurait permis.