déploiement web ASP.NET à l’aide de Visual Studio : préparation du déploiement de base de données
Télécharger le projet de démarrage
Cette série de tutoriels vous montre comment déployer (publier) une application web ASP.NET sur Azure App Service Web Apps ou sur un fournisseur d’hébergement tiers à l’aide de Visual Studio 2012 ou Visual Studio 2010. Pour plus d’informations sur la série, consultez le premier tutoriel de la série.
Vue d’ensemble
Ce tutoriel montre comment préparer le projet pour le déploiement de base de données. La structure de base de données et certaines (pas toutes) des données des deux bases de données de l’application doivent être déployées pour les environnements de test, de préproduction et de production.
En règle générale, lorsque vous développez une application, vous entrez des données de test dans une base de données que vous ne souhaitez pas déployer sur un site actif. Toutefois, vous pouvez également avoir des données de production que vous souhaitez déployer. Dans ce tutoriel, vous allez configurer le projet Contoso University et préparer des scripts SQL afin que les données correctes soient incluses lors du déploiement.
Rappel : si vous recevez un message d’erreur ou si un élément ne fonctionne pas pendant le tutoriel, veillez à case activée la page de résolution des problèmes.
Base de données locale SQL Server Express
L’exemple d’application utilise SQL Server Express LocalDB. SQL Server Express est l’édition gratuite de SQL Server. Il est couramment utilisé pendant le développement, car il est basé sur le même moteur de base de données que les versions complètes de SQL Server. Vous pouvez tester avec SQL Server Express et être sûr que l’application se comportera de la même façon en production, à quelques exceptions près pour les fonctionnalités qui varient d’une édition SQL Server.
LocalDB est un mode d’exécution spécial de SQL Server Express qui vous permet d’utiliser des bases de données en tant que fichiers .mdf. En règle générale, les fichiers de base de données LocalDB sont conservés dans le dossier App_Data d’un projet web. La fonctionnalité instance utilisateur dans SQL Server Express vous permet également d’utiliser des fichiers .mdf, mais l’utilisateur instance fonctionnalité est déconseillée ; par conséquent, LocalDB est recommandé pour l’utilisation des fichiers .mdf.
En règle générale, SQL Server Express n’est pas utilisé pour les applications web de production. LocalDB en particulier n’est pas recommandé pour une utilisation en production avec une application web, car elle n’est pas conçue pour fonctionner avec IIS.
Dans Visual Studio 2012, LocalDB est installé par défaut avec Visual Studio. Dans Visual Studio 2010 et versions antérieures, SQL Server Express (sans LocalDB) est installé par défaut avec Visual Studio; c’est pourquoi vous l’avez installé comme l’une des conditions préalables du premier tutoriel de cette série.
Pour plus d’informations sur les éditions SQL Server, notamment LocalDB, consultez les ressources suivantes Utilisation des bases de données SQL Server.
Entity Framework et Fournisseurs universels
Pour l’accès à la base de données, l’application Contoso University nécessite les logiciels suivants qui doivent être déployés avec l’application, car ils ne sont pas inclus dans le .NET Framework :
- Fournisseurs universels ASP.NET (permet au système d’appartenance ASP.NET d’utiliser Azure SQL Base de données)
- Entity Framework
Étant donné que ce logiciel est inclus dans les packages NuGet, le projet est déjà configuré pour que les assemblys requis soient déployés avec le projet. (Les liens pointent vers les versions actuelles de ces packages, qui peuvent être plus récents que ce qui est installé dans le projet de démarrage que vous avez téléchargé pour ce didacticiel.)
Si vous effectuez un déploiement sur un fournisseur d’hébergement tiers au lieu d’Azure, assurez-vous d’utiliser Entity Framework 5.0 ou version ultérieure. Les versions antérieures de Migrations Code First nécessitent une confiance totale, et la plupart des fournisseurs d’hébergement exécutent votre application en confiance moyenne. Pour plus d’informations sur l’approbation moyenne, consultez le tutoriel Déployer sur IIS en tant qu’environnement de test .
Configurer Migrations Code First pour le déploiement de base de données d’application
La base de données de l’application Contoso University est gérée par Code First et vous allez la déployer à l’aide de Migrations Code First. Pour obtenir une vue d’ensemble du déploiement de base de données à l’aide de Migrations Code First, consultez le premier tutoriel de cette série.
Lorsque vous déployez une base de données d’application, vous ne déployez généralement pas simplement votre base de données de développement avec toutes les données qu’elle contient en production, car la plupart des données qu’elle contient sont probablement uniquement à des fins de test. Par exemple, les noms des étudiants dans une base de données de test sont fictifs. D’un autre côté, vous ne pouvez souvent pas déployer uniquement la structure de base de données sans aucune donnée. Certaines des données de votre base de données de test peuvent être des données réelles et doivent être présentes lorsque les utilisateurs commencent à utiliser l’application. Par exemple, votre base de données peut avoir une table qui contient des valeurs de qualité valides ou des noms de service réels.
Pour simuler ce scénario courant, vous allez configurer une méthode Migrations Code First Seed
qui insère dans la base de données uniquement les données que vous souhaitez trouver en production. Cette Seed
méthode ne doit pas insérer de données de test, car elle s’exécutera en production après que Code First a créé la base de données en production.
Dans les versions antérieures de Code First avant la publication de Migrations, il était courant que les Seed
méthodes insèrent également des données de test, car à chaque changement de modèle pendant le développement, la base de données devait être complètement supprimée et recréée à partir de zéro. Avec Migrations Code First, les données de test sont conservées après les modifications de la base de données. Il n’est donc pas nécessaire d’inclure des données de test dans la Seed
méthode. Le projet que vous avez téléchargé utilise la méthode d’inclusion de toutes les données dans la Seed
méthode d’une classe d’initialiseur. Dans ce tutoriel, vous allez désactiver cette classe d’initialiseur et activer migrations. Ensuite, vous allez mettre à jour la Seed
méthode dans la classe de configuration Migrations afin qu’elle insère uniquement les données que vous souhaitez insérer en production.
Le diagramme suivant illustre le schéma de la base de données d’application :
Pour ces tutoriels, vous allez supposer que les Student
tables et Enrollment
doivent être vides lors du premier déploiement du site. Les autres tables contiennent des données qui doivent être préchargées lorsque l’application est mise en service.
Désactiver l’initialiseur
Étant donné que vous allez utiliser Migrations Code First, vous n’avez pas besoin d’utiliser l’initialiseur DropCreateDatabaseIfModelChanges
Code First. Le code de cet initialiseur se trouve dans le fichier SchoolInitializer.cs du projet ContosoUniversity.DAL. Un paramètre dans l’élément appSettings
du fichier Web.config entraîne l’exécution de cet initialiseur chaque fois que l’application tente d’accéder à la base de données pour la première fois :
<appSettings>
<add key="Environment" value="Dev" />
<add key="DatabaseInitializerForType ContosoUniversity.DAL.SchoolContext, ContosoUniversity.DAL" value="ContosoUniversity.DAL.SchoolInitializer, ContosoUniversity.DAL" />
</appSettings>
Ouvrez le fichier Web.configapplication et supprimez ou commentez l’élément add
qui spécifie la classe d’initialiseur Code First. L’élément appSettings
se présente maintenant comme suit :
<appSettings>
<add key="Environment" value="Dev" />
</appSettings>
Notes
Une autre façon de spécifier une classe d’initialiseur consiste à appeler Database.SetInitializer
la Application_Start
méthode dans le fichier Global.asax . Si vous activez migrations dans un projet qui utilise cette méthode pour spécifier l’initialiseur, supprimez cette ligne de code.
Notes
Si vous utilisez Visual Studio 2013, ajoutez les étapes suivantes entre les étapes 2 et 3 : (a) Dans PMC, entrez « update-package entityframework -version 6.1.1 » pour obtenir la version actuelle d’EF. Ensuite (b) générez le projet pour obtenir une liste d’erreurs de build et corrigez-les. Supprimez les instructions using pour les espaces de noms qui n’existent plus, cliquez avec le bouton droit et cliquez sur Résoudre pour ajouter des instructions using là où elles sont nécessaires, puis remplacez les occurrences de System.Data.EntityState par System.Data.EntityState.
Activation de Code First Migrations
Assurez-vous que le projet ContosoUniversity (et non ContosoUniversity.DAL) est défini comme projet de démarrage. Dans Explorateur de solutions, cliquez avec le bouton droit sur le projet ContosoUniversity et sélectionnez Définir comme projet de démarrage. Migrations Code First recherchez la chaîne de connexion de base de données dans le projet de démarrage.
Dans le menu Outils, choisissezConsole du gestionnaire de packagedu Gestionnaire> de package NuGet.
En haut de la fenêtre Console du Gestionnaire de package, sélectionnez ContosoUniversity.DAL comme projet par défaut, puis, à l’invite
PM>
, entrez « enable-migrations ».(Si vous recevez un message d’erreur indiquant que la commande enable-migrations n’est pas reconnue, entrez la commande EntityFramework -Réinstaller le package de mise à jour , puis réessayez.)
Cette commande crée un dossier Migrations dans le projet ContosoUniversity.DAL et place dans ce dossier deux fichiers : un fichier Configuration.cs que vous pouvez utiliser pour configurer migrations et un fichier InitialCreate.cs pour la première migration qui crée la base de données.
Vous avez sélectionné le projet DAL dans la liste déroulante Projet par défaut de la console du Gestionnaire de package, car la
enable-migrations
commande doit être exécutée dans le projet qui contient la classe de contexte Code First. Lorsque cette classe se trouve dans un projet de bibliothèque de classes, Migrations Code First recherche la chaîne de connexion de base de données dans le projet de démarrage pour la solution. Dans la solution ContosoUniversity, le projet web a été défini comme projet de démarrage. Si vous ne souhaitez pas désigner le projet qui a la chaîne de connexion comme projet de démarrage dans Visual Studio, vous pouvez spécifier le projet de démarrage dans la commande PowerShell. Pour afficher la syntaxe de la commande, entrez la commandeget-help enable-migrations
.La
enable-migrations
commande a créé automatiquement la première migration, car la base de données existe déjà. Une alternative consiste à faire en place à Migrations la création de la base de données. Pour ce faire, utilisez Server Explorer ou SQL Server Explorateur d'objets pour supprimer la base de données ContosoUniversity avant d’activer migrations. Après avoir activé les migrations, créez la première migration manuellement en entrant la commande « add-migration InitialCreate ». Vous pouvez ensuite créer la base de données en entrant la commande « update-database ».
Configurer la méthode Seed
Pour ce tutoriel, vous allez ajouter des données fixes en ajoutant du code à la Seed
méthode de la classe Migrations Code FirstConfiguration
. Migrations Code First appelle la Seed
méthode après chaque migration.
Étant donné que la Seed
méthode s’exécute après chaque migration, il y a déjà des données dans les tables après la première migration. Pour gérer cette situation, vous allez utiliser la AddOrUpdate
méthode pour mettre à jour les lignes qui ont déjà été insérées ou les insérer si elles n’existent pas encore. La AddOrUpdate
méthode n’est peut-être pas le meilleur choix pour votre scénario. Pour plus d’informations, consultez Prendre soin de la méthode AddOrUpdate EF 4.3 sur le blog de Julie Lerman.
Ouvrez le fichier Configuration.cs et remplacez les commentaires dans la
Seed
méthode par le code suivant :var instructors = new List<Instructor> { new Instructor { FirstMidName = "Kim", LastName = "Abercrombie", HireDate = DateTime.Parse("1995-03-11"), OfficeAssignment = new OfficeAssignment { Location = "Smith 17" } }, new Instructor { FirstMidName = "Fadi", LastName = "Fakhouri", HireDate = DateTime.Parse("2002-07-06"), OfficeAssignment = new OfficeAssignment { Location = "Gowan 27" } }, new Instructor { FirstMidName = "Roger", LastName = "Harui", HireDate = DateTime.Parse("1998-07-01"), OfficeAssignment = new OfficeAssignment { Location = "Thompson 304" } }, new Instructor { FirstMidName = "Candace", LastName = "Kapoor", HireDate = DateTime.Parse("2001-01-15") }, new Instructor { FirstMidName = "Roger", LastName = "Zheng", HireDate = DateTime.Parse("2004-02-12") } }; instructors.ForEach(s => context.Instructors.AddOrUpdate(i => i.LastName, s)); context.SaveChanges(); var departments = new List<Department> { new Department { Name = "English", Budget = 350000, StartDate = DateTime.Parse("2007-09-01"), PersonID = 1 }, new Department { Name = "Mathematics", Budget = 100000, StartDate = DateTime.Parse("2007-09-01"), PersonID = 2 }, new Department { Name = "Engineering", Budget = 350000, StartDate = DateTime.Parse("2007-09-01"), PersonID = 3 }, new Department { Name = "Economics", Budget = 100000, StartDate = DateTime.Parse("2007-09-01"), PersonID = 4 } }; departments.ForEach(s => context.Departments.AddOrUpdate(d => d.Name, s)); context.SaveChanges(); var courses = new List<Course> { new Course { CourseID = 1050, Title = "Chemistry", Credits = 3, DepartmentID = 3 }, new Course { CourseID = 4022, Title = "Microeconomics", Credits = 3, DepartmentID = 4 }, new Course { CourseID = 4041, Title = "Macroeconomics", Credits = 3, DepartmentID = 4 }, new Course { CourseID = 1045, Title = "Calculus", Credits = 4, DepartmentID = 2 }, new Course { CourseID = 3141, Title = "Trigonometry", Credits = 4, DepartmentID = 2 }, new Course { CourseID = 2021, Title = "Composition", Credits = 3, DepartmentID = 1 }, new Course { CourseID = 2042, Title = "Literature", Credits = 4, DepartmentID = 1 } }; courses.ForEach(s => context.Courses.AddOrUpdate(s)); context.SaveChanges(); courses[0].Instructors.Add(instructors[0]); courses[0].Instructors.Add(instructors[1]); courses[1].Instructors.Add(instructors[2]); courses[2].Instructors.Add(instructors[2]); courses[3].Instructors.Add(instructors[3]); courses[4].Instructors.Add(instructors[3]); courses[5].Instructors.Add(instructors[3]); courses[6].Instructors.Add(instructors[3]); context.SaveChanges();
Références à
List
avoir des lignes rouges en dessous, car vous n’avez pas encore d’instructionusing
pour son espace de noms. Cliquez avec le bouton droit sur l’une des instances deList
, cliquez sur Résoudre, puis cliquez sur System.Collections.Generic.Cette sélection de menu ajoute le code suivant aux
using
instructions situées en haut du fichier.using System.Collections.Generic;
Appuyez sur Ctrl-Maj+B pour générer le projet.
Le projet est maintenant prêt à déployer la base de données ContosoUniversity . Après avoir déployé l’application, la première fois que vous l’avez exécutée et que vous accédez à une page qui accède à la base de données, Code First crée la base de données et exécute cette Seed
méthode.
Notes
L’ajout de code à la Seed
méthode est l’une des nombreuses façons d’insérer des données fixes dans la base de données. Une alternative consiste à ajouter du Up
code aux méthodes et Down
de chaque classe de migration. Les Up
méthodes et Down
contiennent du code qui implémente les modifications de base de données. Vous en trouverez des exemples dans le didacticiel Déploiement d’une mise à jour de base de données .
Vous pouvez également écrire du code qui exécute des instructions SQL à l’aide de la Sql
méthode . Par exemple, si vous ajoutez une colonne Budget à la table Department et que vous souhaitez initialiser tous les budgets du service à 1 000,00 $ dans le cadre d’une migration, vous pouvez ajouter la ligne de code suivante à la Up
méthode de cette migration :
Sql("UPDATE Department SET Budget = 1000");
Créer des scripts pour le déploiement de la base de données d’appartenance
L’application Contoso University utilise le système d’appartenance ASP.NET et l’authentification par formulaire pour authentifier et autoriser les utilisateurs. La page Mettre à jour les crédits est accessible uniquement aux utilisateurs qui sont dans le rôle Administrateur.
Exécutez l’application, cliquez sur Cours, puis sur Mettre à jour les crédits.
La page Se connecter s’affiche , car la page Mettre à jour les crédits nécessite des privilèges d’administration.
Entrez admin comme nom d’utilisateur et devpwd comme mot de passe, puis cliquez sur Se connecter.
La page Mettre à jour les crédits s’affiche.
Les informations sur l’utilisateur et le rôle se situent dans la base de données aspnet-ContosoUniversity spécifiée par la chaîne de connexion DefaultConnection dans le fichier Web.config .
Cette base de données n’étant pas gérée par Entity Framework Code First, vous ne pouvez pas utiliser migrations pour la déployer. Vous allez utiliser le fournisseur dbDacFx pour déployer le schéma de base de données et configurer le profil de publication pour exécuter un script qui insère les données initiales dans les tables de base de données.
Notes
Un nouveau système d’appartenance ASP.NET (maintenant nommé ASP.NET Identity) a été introduit avec Visual Studio 2013. Le nouveau système vous permet de conserver les tables d’application et d’appartenance dans la même base de données, et vous pouvez utiliser Migrations Code First pour déployer les deux. L’exemple d’application utilise le système d’appartenance ASP.NET précédent, qui ne peut pas être déployé à l’aide de Migrations Code First. Les procédures de déploiement de cette base de données d’appartenance s’appliquent également à tout autre scénario dans lequel votre application doit déployer une base de données SQL Server qui n’est pas créée par Entity Framework Code First.
Ici aussi, vous ne voulez généralement pas les mêmes données en production que celles dont vous disposez en développement. Lorsque vous déployez un site pour la première fois, il est courant d’exclure la plupart ou la totalité des comptes d’utilisateur que vous créez à des fins de test. Par conséquent, le projet téléchargé a deux bases de données d’appartenance : aspnet-ContosoUniversity.mdf avec des utilisateurs de développement et aspnet-ContosoUniversity-Prod.mdf avec les utilisateurs de production. Pour ce tutoriel, les noms d’utilisateur sont les mêmes dans les deux bases de données : administrateur et non administrateur. Les deux utilisateurs ont le mot de passe devpwd dans la base de données de développement et prodpwd dans la base de données de production.
Vous allez déployer les utilisateurs de développement dans l’environnement de test et les utilisateurs de production vers la préproduction et la production. Pour ce faire, vous allez créer deux scripts SQL dans ce didacticiel, l’un pour le développement et l’autre pour la production. Dans les didacticiels ultérieurs, vous allez configurer le processus de publication pour les exécuter.
Notes
La base de données d’appartenance stocke un hachage des mots de passe de compte. Pour déployer des comptes d’un ordinateur à un autre, vous devez vous assurer que les routines de hachage ne génèrent pas de hachages différents sur le serveur de destination que sur l’ordinateur source. Ils génèrent les mêmes hachages lorsque vous utilisez le Fournisseurs universels ASP.NET, tant que vous ne modifiez pas l’algorithme par défaut. L’algorithme par défaut est HMACSHA256 et est spécifié dans l’attribut de validation de l’élément machineKey dans le fichier Web.config.
Vous pouvez créer des scripts de déploiement de données manuellement, à l’aide de SQL Server Management Studio (SSMS) ou d’un outil tiers. Le reste de ce didacticiel vous montre comment procéder dans SSMS, mais si vous ne souhaitez pas installer et utiliser SSMS, vous pouvez obtenir les scripts de la version terminée du projet et passer à la section dans laquelle vous les stockez dans le dossier de solution.
Pour installer SSMS, installez-le à partir du Centre de téléchargement : Microsoft SQL Server 2012 Express en cliquant sur ENU\x64\SQLManagementStudio_x64_ENU.exe ou ENU\x86\SQLManagementStudio_x86_ENU.exe. Si vous choisissez le mauvais pour votre système, il ne pourra pas être installé et vous pouvez essayer l’autre.
(Notez qu’il s’agit d’un téléchargement de 600 mégaoctets. L’installation peut prendre beaucoup de temps et nécessiter un redémarrage de votre ordinateur.)
Dans la première page du Centre d’installation SQL Server, cliquez sur Nouveau SQL Server installation autonome ou ajouter des fonctionnalités à une installation existante, puis suivez les instructions, en acceptant les choix par défaut.
Créer le script de base de données de développement
Exécutez SSMS.
Dans la boîte de dialogue Se connecter au serveur , entrez (localdb)\v11.0 comme nom du serveur, laissez Authentification définie sur Authentification Windows, puis cliquez sur Se connecter.
Dans la fenêtre Explorateur d'objets, développez Bases de données, cliquez avec le bouton droit sur aspnet-ContosoUniversity, cliquez sur Tâches, puis sur Générer des scripts.
Dans la boîte de dialogue Générer et publier des scripts , cliquez sur Définir les options de script.
Vous pouvez ignorer l’étape Choisir des objets , car la valeur par défaut est Scripter la base de données entière et tous les objets de base de données , et c’est ce que vous voulez.
Cliquez sur Avancé.
Dans la boîte de dialogue Options avancées de script , faites défiler jusqu’à Types de données à scripter, puis cliquez sur l’option Données uniquement dans la liste déroulante.
Remplacez script USE DATABASE parFalse. Les instructions USE ne sont pas valides pour Azure SQL Database et ne sont pas nécessaires au déploiement pour SQL Server Express dans l’environnement de test.
Cliquez sur OK.
Dans la boîte de dialogue Générer et publier des scripts , la zone Nom de fichier spécifie où le script sera créé. Remplacez le chemin d’accès au dossier de votre solution (le dossier contenant votre fichier ContosoUniversity.sln) et le nom du fichier par aspnet-data-dev.sql.
Cliquez sur Suivant pour accéder à l’onglet Résumé , puis cliquez à nouveau sur Suivant pour créer le script.
Cliquez sur Terminer.
Créer le script de base de données de production
Étant donné que vous n’avez pas exécuté le projet avec la base de données de production, il n’est pas encore attaché à la instance LocalDB. Par conséquent, vous devez d’abord attacher la base de données.
Dans le Explorateur d'objets SSMS, cliquez avec le bouton droit sur Bases de données, puis cliquez sur Attacher.
Dans la boîte de dialogue Attacher des bases de données , cliquez sur Ajouter , puis accédez au fichier aspnet-ContosoUniversity-Prod.mdf dans le dossier App_Data .
Cliquez sur OK.
Suivez la même procédure que vous avez utilisée précédemment pour créer un script pour le fichier de production. Nommez le fichier de script aspnet-data-prod.sql.
Résumé
Les deux bases de données sont maintenant prêtes à être déployées et vous avez deux scripts de déploiement de données dans votre dossier de solution.
Dans le tutoriel suivant, vous configurez les paramètres de projet qui affectent le déploiement, et vous configurez des transformations automatiques de fichiersWeb.config pour les paramètres qui doivent être différents dans l’application déployée.
Informations complémentaires
Pour plus d’informations sur NuGet, consultez Gérer les bibliothèques de projets avec NuGet et la documentation NuGet. Si vous ne souhaitez pas utiliser NuGet, vous devez apprendre à analyser un package NuGet pour déterminer ce qu’il fait lorsqu’il est installé. (Par exemple, il peut configurer Web.config transformations, configurer des scripts PowerShell pour qu’ils s’exécutent au moment de la génération, etc.) Pour en savoir plus sur le fonctionnement de NuGet, consultez Création et publication d’un fichier de package et de configuration et transformations de code source.