Fichiers de site Web sous contrôle de code source
Mise à jour : novembre 2007
Certains fichiers que vous utilisez dans un site Web nécessitent une attention particulière lorsque vous travaillez avec le contrôle de code source.
Fichier Web.config
Puisque le fichier Web.config est un magasin central pour les paramètres de configuration au niveau de l'application, il est plus probable que ce fichier, plutôt que des pages individuelles, soit extrait pour plusieurs développeurs simultanément. Tant que plusieurs développeurs ne modifient pas les mêmes paramètres en même temps, la fonctionnalité de fusion du système de contrôle de code source peut intégrer des modifications pendant le processus d'archivage.
Vous pouvez ouvrir manuellement le fichier Web.config pour le modifier. Dans ce cas, vous pouvez extraire d'abord le fichier explicitement ou prévoir une extraction implicite lorsque vous modifiez le fichier, comme vous le feriez avec une page ASP.NET. En outre, plusieurs utilitaires dans Visual Web Developer apportent des modifications au fichier Web.config. Par exemple, si vous utilisez la boîte de dialogue Ajouter une référence de Visual Web Developer pour créer une référence à un projet client, un service Web ou un assembly dans le Global Assembly Cache (GAC), la nouvelle référence est stockée dans le fichier Web.config. Dans la plupart des cas, Visual Web Developer extraira automatiquement le fichier Web.config, si nécessaire. Par exemple, si vous ajoutez une nouvelle référence à votre application Web et si le fichier Web.config n'a pas été extrait, la commande Ajouter une référence extraira le fichier Web.config et ajoutera la référence.
Toutefois, tous les processus qui affectent le fichier Web.config n'entraînent pas l'extraction automatique de ce fichier. Vous trouverez ci-dessous une liste des utilitaires qui nécessitent l'extraction du fichier Web.config avant de modifier la configuration de votre application :
L'outil Administration de site Web (commande Configuration ASP.NET dans le menu Site Web) n'extrait pas automatiquement le fichier Web.config. Si vous essayez d'enregistrer des modifications dans cet outil sans avoir au préalable extrait le fichier Web.config, l'outil affiche une erreur indiquant que le fichier Web.config est en lecture seule. La solution est d'extraire explicitement le fichier Web.config avant d'utiliser l'outil Administration de site Web.
Le composant logiciel enfichable MMC d'ASP.NET n'extrait pas automatiquement le fichier Web.config et il affichera une erreur si vous essayez d'enregistrer des modifications de configuration avant d'avoir extrait le fichier.
Sections chiffrées du fichier Web.config
Si vous avez configuré le fichier Web.config avec des sections chiffrées, la fusion n'est plus possible. Déchiffrez les paramètres de configuration avant de procéder à la fusion.
Pour plus d'informations sur le chiffrement des sections du fichier Web.config, consultez Chiffrement des informations de configuration à l'aide de la configuration protégée.
Fichier Global.asax
Tout comme le fichier Web.config, le fichier Global.asax stocke des informations qui s'appliquent au site Web entier et sont localisées dans la racine du site Web. Plus précisément, le fichier Global.asax contient le code de gestion des événements déclenchés pour l'application ou la session. En général, plusieurs développeurs peuvent extraire le fichier Global.asax en toute sécurité et compter sur la fonctionnalité de fusion proposée par le fournisseur de contrôle de code source pour résoudre des conflits lors de l'archivage.
Fichiers de ressources
Les fichiers de ressources (.resx) stockent des informations au format XML. Ils peuvent se situer soit au niveau local sur une page, soit au niveau global pour l'application Web. Un fichier de ressources local pour une page est stocké dans le fichier App_LocalResources avec un nom basé sur celui de la page à laquelle il est associé. Par exemple, la page Default.aspx aura un fichier de ressources local correspondant nommé Default.aspx.resx. Les fichiers de ressources globaux sont stockés dans le fichier App_GlobalResources. Vous pouvez assigner le nom de votre choix à ces fichiers à condition qu'ils aient l'extension .resx.
Les fichiers de ressources locaux ne sont pas extraits automatiquement quand vous extrayez une page. Par conséquent, vous devez extraire le fichier de ressources correspondant, de manière explicite ou implicite, avant de le modifier. L'utilisation des fichiers de ressources globaux est similaire, mais les risques de conflits entre développeurs peuvent être plus importants. Avant d'extraire une page qui repose sur un fichier de ressources global, vérifiez le contrôle de code source pour voir si quelqu'un d'autre a extrait ce fichier.
Dans les deux cas, comme le fichier de ressources est au format XML, les conflits pendant l'archivage peuvent être résolus lors de la fusion.
Base de données des services d'application
Si vous utilisez l'appartenance (membership) d'ASP.NET, la gestion des rôles ou les profils, les informations d'application pour ces services sont stockées dans une base de données. Par défaut, la base de données est locale pour l'application Web et elle est stockée en tant que fichier de base de données dans le dossier App_Data de votre application Web. Les services nécessitent également des entrées dans le fichier Web.config. Pour plus d'informations, consultez Création et configuration de la base de données des services d'application pour SQL Server.
Si votre site Web est sous contrôle de code source, le stockage des données d'application dans une base de données locale peut provoquer des problèmes pour les raisons suivantes :
Chaque développeur doit extraire le fichier de base de données lorsque l'application est déboguée localement. Vous ne pouvez pas déboguer votre application si le fichier de base de données est en lecture seule, car cela provoque des erreurs d'exécution.
La base de données est stockée dans le référentiel de contrôle de code source en tant que fichier binaire. Par conséquent, le système de contrôle de code source ne peut pas fusionner les modifications si plusieurs développeurs ont extrait le fichier de base de données. Au lieu de cela, l'archivage effectué par chaque développeur remplace la version précédente.
Lorsque vous travaillez avec une application Web qui est sous contrôle de code source, il est recommandé d'utiliser un fichier de base de données partagé qui n'est pas sous contrôle de code source pour stocker les données des services d'application. Par exemple, vous pouvez utiliser un serveur central exécutant Microsoft SQL Server pour les données d'application. Tous les développeurs travaillent alors avec les données actives. Ensuite, vous pouvez également utiliser les fonctionnalités de sauvegarde de la base de données pour gérer les données d'application. Pour plus d'informations sur la sélection d'une base de données pour les données d'application, consultez Création et configuration de la base de données des services d'application pour SQL Server.
Fichiers d'assembly
Vous pouvez ajouter des assemblys (fichiers .dll) au dossier Bin de votre site Web, puis référencer ces assemblys dans votre code. Vous n'avez pas besoin d'extraire un fichier .dll sauf si vous souhaitez le remplacer par une version plus récente.
Les systèmes de contrôle de code source ne peuvent pas fusionner les modifications si deux ou plusieurs développeurs modifient le fichier .dll binaire en même temps. Par conséquent, il est recommandé de ne pas autoriser d'extractions multiples sur un fichier .dll si vous projetez de mettre à jour le fichier et de le réarchiver. Vous pouvez définir une option pendant l'extraction pour empêcher les autres utilisateurs d'extraire le fichier pendant que vous l'utilisez.
Références aux projets clients ou Bibliothèque de classes
Lorsque vous utilisez votre application Web, vous pouvez ajouter un projet client ou Bibliothèque de classes à la solution et créer des composants compilables dans le projet de bibliothèque. Vous pouvez ensuite créer une référence entre projets dans votre application Web pour référencer la sortie compilée du projet de bibliothèque. Par exemple, lors de la création d'un projet Bibliothèque de classes, vous pouvez créer un assembly avec les classes d'utilitaires ou les contrôles personnalisés dans le projet, puis référencer ces assemblys dans votre application Web.
Lorsque vous créez une référence à un autre projet, Visual Web Developer copie la sortie compilée de ce projet s'il existe. Pour cette raison, vous devez générer un projet avant de pouvoir lui créer une référence à partir d'un autre projet. La sortie compilée de projets clients n'est pas sous contrôle de code source ; par conséquent, les développeurs n'ont pas à se préoccuper de la suppression des anciennes versions des fichiers binaires, ni de la génération et du remplacement des versions sous contrôle de code source.
Voir aussi
Concepts
Vue d'ensemble du contrôle de code source de site Web
Autres ressources
Création et configuration de la base de données des services d'application pour SQL Server