ASP.NET déploiement web à 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 de Visual Studio 2010. Pour plus d’informations sur la série, consultez le premier didacticiel de la série.

Aperçu

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 dans les 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 en direct. 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 appropriées soient incluses lors du déploiement.

Rappel : Si vous recevez un message d'erreur ou si quelque chose ne fonctionne pas lors du suivi du tutoriel, veillez à consulter la page de dépannage.

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 assuré que l’application se comportera de la même façon en production, avec quelques exceptions pour les fonctionnalités qui varient entre les éditions de 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é d’instance utilisateur dans SQL Server Express vous permet également d’utiliser des fichiers .mdf , mais la fonctionnalité d’instance utilisateur est déconseillée. Par conséquent, LocalDB est recommandé pour utiliser 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’un des prérequis dans le premier tutoriel de cette série.

Pour plus d’informations sur les éditions de 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 elle n’est pas incluse dans le .NET Framework :

Étant donné que ce logiciel est inclus dans les packages NuGet, le projet est déjà configuré afin 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, veillez à utiliser Entity Framework 5.0 ou une version ultérieure. Les versions antérieures de Code First Migrations 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 la sécurité de confiance moyenne, consultez le didacticiel Déployer sur IIS en tant qu'environnement de test.

Configurer les migrations Code First pour le déploiement de base de données d’application

La base de données d’application Contoso University est gérée par Code First et vous allez la déployer à l’aide de Code First Migrations. Pour obtenir une vue d’ensemble du déploiement de base de données à l’aide de Code First Migrations, consultez le premier didacticiel de cette série.

Lorsque vous déployez une base de données d’application, en général, vous ne déployez 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’il contient sont probablement présentes uniquement à des fins de test. Par exemple, les noms des étudiants dans une base de données de test sont fictifs. En revanche, vous ne pouvez souvent pas déployer uniquement la structure de base de données sans aucune donnée dans celle-ci. Certaines données de votre base de données de test peuvent être des données réelles et doivent être là lorsque les utilisateurs commencent à utiliser l’application. Par exemple, votre base de données peut avoir une table qui contient des valeurs de classe valides ou des noms de service réels.

Pour simuler ce scénario courant, vous allez configurer une méthode Code First Migrations Seed qui insère dans la base de données uniquement les données que vous souhaitez y 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 sortie des migrations, il était courant que les méthodes Seed insèrent également des données de test, car avec chaque changement de modèle durant le développement, la base de données devait être totalement supprimée et recréée depuis le début. Avec Code First Migrations, les données de test sont conservées après les modifications de base de données, de sorte que l’inclusion des données de test dans la Seed méthode n’est pas nécessaire. 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 les 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 :

Schéma_de_base_de_données_scolaire

Pour ces didacticiels, vous supposerez que les tables Student et Enrollment doivent être vides lorsque le site est déployé pour la première fois. Les autres tables contiennent des données qui doivent être préchargées lorsque l'application est mise en ligne.

Désactiver l’initialiseur

Étant donné que vous utiliserez Code First Migrations, vous n’avez pas besoin d’utiliser l’initialiseur DropCreateDatabaseIfModelChanges Code First. Le code de cet initialiseur se trouve dans le fichier SchoolInitializer.cs dans le 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 l’application Web.config fichier et supprimez ou commentez l’élément add qui spécifie la classe d’initialiseur Code First. L’élément appSettings ressemble maintenant à ceci :

<appSettings>
  <add key="Environment" value="Dev" />
</appSettings>

Note

Une autre façon de spécifier une classe d’initialiseur est de le faire en appelant Database.SetInitializer dans la méthode dans le Application_Start 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.

Note

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 la liste des 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 sélectionnez Résoudre pour ajouter les instructions using là où elles sont nécessaires. Enfin, remplacez toutes les occurrences de System.Data.EntityState par System.Data.Entity.EntityState.

Activation de Code First Migrations

  1. Vérifiez que le projet ContosoUniversity (et non ContosoUniversity.DAL) est défini comme projet de démarrage. Dans l’Explorateur de solutions, cliquez avec le bouton droit sur le projet ContosoUniversity, puis sélectionnez Définir comme projet de démarrage. Code First Migrations recherche dans le projet de démarrage la chaîne de connexion de base de données.

  2. Dans le menu Outils, choisissez Gestionnaire de package NuGet>Console du Gestionnaire de package.

    Sélection de la console du gestionnaire de packages

  3. 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 ».

    commande enable-migrations

    (Si vous obtenez une erreur indiquant que la commande enable-migrations n’est pas reconnue, entrez la commande update-package EntityFramework -Réinstaller et 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.

    Dossier migrations

    Vous avez sélectionné le projet DAL dans la liste déroulante Projet par défaut de la console 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, Code First Migrations recherche la chaîne de connexion de base de données dans le projet de démarrage de 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 commande get-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 à laisser Migrations créer la base de données. Pour ce faire, utilisez l’Explorateur de serveurs ou l’Explorateur d’objets SQL Server pour supprimer la base de données ContosoUniversity avant d’activer les 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 méthode de la Seed classe Code First Migrations Configuration . Code First Migrations appelle la Seed méthode après chaque migration.

Étant donné que la Seed méthode s’exécute après chaque migration, il existe 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 s’ils n’existent pas encore. La AddOrUpdate méthode peut ne pas être 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.

  1. 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();

  2. Les références à List ont des lignes rouges ondulées sous elles, car vous n'avez pas encore d'instruction using pour son espace de nommage. Cliquez avec le bouton droit sur l’une des instances de List et cliquez sur Résoudre, puis cliquez sur System.Collections.Generic.

    Résoudre avec l’instruction using

    Cette sélection de menu ajoute le code suivant aux using instructions situées en haut du fichier.

    using System.Collections.Generic;

  3. Appuyez sur Ctrl-SHIFT-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’exécutez et 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.

Note

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 code aux méthodes Up et Down de chaque classe de migration. Les méthodes Up et Down contiennent du code qui implémente les modifications de base de données. Vous verrez des exemples d’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 souhaitez initialiser tous les budgets de 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 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 se trouvent dans le rôle Administrateur.

Exécutez l’application, puis cliquez sur Cours, puis sur Mettre à jour les crédits.

Cliquez sur Mettre à jour les crédits

La page Connexion s’affiche, car la page Mettre à jour les crédits nécessite des privilèges d’administration.

Entrez l’administrateur comme nom d’utilisateur et devpwd comme mot de passe, puis cliquez sur Se connecter.

Page De connexion

La page Mettre à jour les crédits s’affiche.

Mettre à jour la page des crédits

Les informations d’utilisateur et de rôle se trouve 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’est pas gérée par Entity Framework Code First. Vous ne pouvez donc pas utiliser migrations pour le 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 des données initiales dans des tables de base de données.

Note

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 Code First Migrations pour déployer les deux. L’exemple d’application utilise le système d’appartenance ASP.NET antérieur, qui ne peut pas être déployé à l’aide de Code First Migrations. 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 souhaitez généralement pas les mêmes données en production que celles que vous avez en développement. Lorsque vous déployez un site pour la première fois, il est courant d’exclure la plupart ou l’ensemble des comptes d’utilisateur que vous créez pour les tests. 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 des utilisateurs de production. Pour ce tutoriel, les noms d’utilisateurs sont identiques dans les deux bases de données : administrateur et non administrateur. Les deux utilisateurs ont le devpwd de mot de passe 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 en préproduction et en production. Pour ce faire, vous allez créer deux scripts SQL dans ce didacticiel, un pour le développement et un pour la production, et dans les didacticiels ultérieurs, vous allez configurer le processus de publication pour les exécuter.

Note

La base de données d’appartenance stocke un hachage de mots de passe de compte. Pour déployer des comptes d’un ordinateur vers 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 les 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 manuellement des scripts de déploiement de données à l’aide de SQL Server Management Studio (SSMS) ou à l’aide d’un outil tiers. Ce reste de ce tutoriel vous montre comment le faire dans SSMS, mais si vous ne souhaitez pas installer et utiliser SSMS, vous pouvez obtenir les scripts à partir de la version terminée du projet et passer à la section où 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 la mauvaise option pour votre système, il échouera à s'installer, et vous pourrez 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 Nouvelle installation autonome de SQL Server ou ajoutez 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

  1. Exécutez SSMS.

  2. Dans la boîte de dialogue Se connecter au serveur , entrez (localdb)\v11.0 comme nom du serveur, laissez l’authentification définie sur l’authentification Windows, puis cliquez sur Se connecter.

    SSMS Se connecter au serveur

  3. 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 cliquez sur Générer des scripts.

    Générer des scripts SSMS

  4. 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 script l’intégralité de la base de données et tous les objets de base de données, et c'est ce que vous voulez.

  5. Cliquez sur Avancé.

    Options de script SSMS

  6. Dans la boîte de dialogue Options de script avancées , faites défiler jusqu’à Types de données vers le script, puis cliquez sur l’option Données uniquement dans la liste déroulante.

  7. Modifiez script USE DATABASE sur False. Les instructions USE ne sont pas valides pour Azure SQL Database et ne sont pas nécessaires pour le déploiement vers SQL Server Express dans l’environnement de test.

    Données de script SSMS uniquement, aucune instruction USE

  8. Cliquez sur OK.

  9. Dans la boîte de dialogue Générer et publier des scripts , la zone Nom de fichier spécifie l’emplacement de création du script. Modifiez le chemin d’accès à votre dossier de solution (le dossier contenant votre fichier ContosoUniversity.sln) et le nom de fichier pour aspnet-data-dev.sql.

  10. Cliquez sur Suivant pour accéder à l’onglet Résumé , puis cliquez à nouveau sur Suivant pour créer le script.

    Script SSMS créé

  11. Cliquez sur Terminer.

Créer le script de base de données de production

Étant donné que vous n’avez pas encore exécuté le projet avec la base de données de production, il n’est pas encore attaché à l’instance LocalDB. Par conséquent, vous devez d’abord attacher la base de données.

  1. Dans l’Explorateur d’objets SSMS, cliquez avec le bouton droit sur Bases de données , puis cliquez sur Attacher.

    Attachement SSMS

  2. 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 .

    SSMS Ajouter .mdf fichier à joindre

  3. Cliquez sur OK.

  4. Suivez la même procédure que celle 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 disposez de deux scripts de déploiement de données dans votre dossier de solution.

Scripts de déploiement de données

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.

Plus d’informations

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 quand il est installé. (Par exemple, il peut configurer transformations Web.config, configurer des scripts PowerShell à exécuter au moment de la génération, etc.) Pour en savoir plus sur le fonctionnement de NuGet, consultez Création et publication d’un package et Transformations de fichier de configuration et de code source.

PrécédentSuivant

  • Last updated on