Déploiement d’une application web ASP.NET avec SQL Server Compact à l’aide de Visual Studio ou de Visual Web Developer : migration vers SQL Server - 10 sur 12
par Tom Dykstra
Télécharger le projet de démarrage
Cette série de tutoriels vous montre comment déployer (publier) un projet d’application web ASP.NET qui inclut une base de données SQL Server Compact à l’aide de Visual Studio 2012 RC ou Visual Studio Express 2012 RC for Web. Vous pouvez également utiliser Visual Studio 2010 si vous installez la mise à jour de publication web. Pour une présentation de la série, consultez le premier tutoriel de la série.
Pour obtenir un tutoriel qui présente les fonctionnalités de déploiement introduites après la version RC de Visual Studio 2012, montre comment déployer SQL Server éditions autres que SQL Server Compact et montre comment déployer sur Azure App Service Web Apps, consultez déploiement web ASP.NET à l’aide de Visual Studio.
Vue d’ensemble
Ce tutoriel vous montre comment migrer de SQL Server Compact vers SQL Server. L’une des raisons pour lesquelles vous souhaiterez peut-être tirer parti de SQL Server fonctionnalités que SQL Server Compact ne prend pas en charge, telles que les procédures stockées, les déclencheurs, les vues ou la réplication. Pour plus d’informations sur les différences entre SQL Server Compact et SQL Server, consultez le didacticiel Déploiement de SQL Server Compact.
SQL Server Express par rapport à la SQL Server complète pour le développement
Une fois que vous avez décidé de mettre à niveau vers SQL Server, vous pouvez utiliser SQL Server ou SQL Server Express dans vos environnements de développement et de test. Outre les différences de prise en charge des outils et des fonctionnalités du moteur de base de données, il existe des différences dans les implémentations de fournisseurs entre SQL Server Compact et d’autres versions de SQL Server. Ces différences peuvent entraîner la génération de résultats différents par le même code. Par conséquent, si vous décidez de conserver SQL Server Compact comme base de données de développement, vous devez tester minutieusement votre site dans SQL Server ou SQL Server Express dans un environnement de test avant chaque déploiement en production.
Contrairement à SQL Server Compact, SQL Server Express est essentiellement le même moteur de base de données et utilise le même fournisseur .NET comme SQL Server complète. Lorsque vous effectuez un test avec SQL Server Express, vous pouvez être sûr d’obtenir les mêmes résultats qu’avec SQL Server. Vous pouvez utiliser la plupart des mêmes outils de base de données avec SQL Server Express que vous pouvez utiliser avec SQL Server (une exception notable étant SQL Server Profiler), et il prend en charge d’autres fonctionnalités de SQL Server telles que les procédures stockées, les vues, les déclencheurs et la réplication. (Toutefois, vous devez généralement utiliser des SQL Server complètes dans un site web de production. SQL Server Express peut s’exécuter dans un environnement d’hébergement partagé, mais il n’a pas été conçu pour cela, et de nombreux fournisseurs d’hébergement ne le prennent pas en charge.)
Si vous utilisez Visual Studio 2012, vous choisissez généralement SQL Server Express LocalDB pour votre environnement de développement, car c’est ce qui est installé par défaut avec Visual Studio. Toutefois, LocalDB ne fonctionne pas dans IIS. Par conséquent, pour votre environnement de test, vous devez utiliser SQL Server ou SQL Server Express.
Combinaison de bases de données et maintien de leur séparation
L’application Contoso University a deux bases de données SQL Server Compact : la base de données d’appartenance (aspnet.sdf) et la base de données d’application (School.sdf). Lorsque vous migrez, vous pouvez migrer ces bases de données vers deux bases de données distinctes ou vers une seule base de données. Vous pouvez les combiner afin de faciliter les jointures de bases de données entre votre base de données d’application et votre base de données d’appartenance. Votre plan d’hébergement peut également fournir une raison de les combiner. Par exemple, le fournisseur d’hébergement peut facturer plus pour plusieurs bases de données ou même ne pas autoriser plusieurs bases de données. C’est le cas avec le compte d’hébergement Cytanium Lite utilisé pour ce tutoriel, qui n’autorise qu’une seule base de données SQL Server.
Dans ce tutoriel, vous allez migrer vos deux bases de données de la façon suivante :
- Migrez vers deux bases de données LocalDB dans l’environnement de développement.
- Migrez vers deux bases de données SQL Server Express dans l’environnement de test.
- Migrez vers une base de données SQL Server complète combinée dans l’environnement de production.
Rappel : si vous obtenez un message d’erreur ou si quelque chose ne fonctionne pas pendant le didacticiel, veillez à case activée la page de résolution des problèmes.
Installation de SQL Server Express
SQL Server Express est automatiquement installé par défaut avec Visual Studio 2010, mais par défaut, il n’est pas installé avec Visual Studio 2012. Pour installer SQL Server 2012 Express, cliquez sur le lien suivant
Choisissez ENU/x64/SQLEXPR_x64_ENU.exe ou ENU/x86/SQLEXPR_x86_ENU.exeet, dans l’Assistant Installation, acceptez les paramètres par défaut. Pour plus d’informations sur les options d’installation, consultez Installer SQL Server 2012 à partir de l’Assistant Installation (installation) .
Création de bases de données SQL Server Express pour l’environnement de test
L’étape suivante consiste à créer les bases de données ASP.NET appartenance et School.
Dans le menu Affichage, sélectionnez Server Explorer (Database Explorer in Visual Web Developer), puis cliquez avec le bouton droit sur Data Connections et sélectionnez Create New SQL Server Database ( Créer une base de données SQL Server).
Dans la boîte de dialogue Créer une base de données SQL Server, entrez « .\SQLExpress » dans la zone Nom du serveur et « aspnet-Test » dans la zone Nouveau nom de base de données, puis cliquez sur OK.
Suivez la même procédure pour créer une base de données SQL Server Express School nommée « School-Test ».
(Vous ajoutez « Test » à ces noms de base de données, car plus tard, vous créerez un instance supplémentaire de chaque base de données pour l’environnement de développement, et vous devez être en mesure de différencier les deux ensembles de bases de données.)
Server Explorer affiche désormais les deux nouvelles bases de données.
Création d’un script d’octroi pour les nouvelles bases de données
Lorsque l’application s’exécute dans IIS sur votre ordinateur de développement, l’application accède à la base de données à l’aide des informations d’identification du pool d’applications par défaut. Toutefois, par défaut, l’identité du pool d’applications n’est pas autorisée à ouvrir les bases de données. Vous devez donc exécuter un script pour accorder cette autorisation. Dans cette section, vous créez le script que vous exécuterez ultérieurement pour vous assurer que l’application peut ouvrir les bases de données lorsqu’elle s’exécute dans IIS.
Dans le dossier SolutionFiles de la solution que vous avez créé dans le didacticiel Déploiement dans l’environnement de production , créez un fichier SQL nommé Grant.sql. Copiez les commandes SQL suivantes dans le fichier, puis enregistrez et fermez le fichier :
IF NOT EXISTS (SELECT name FROM sys.server_principals WHERE name = 'IIS APPPOOL\DefaultAppPool')
BEGIN
CREATE LOGIN [IIS APPPOOL\DefaultAppPool]
FROM WINDOWS WITH DEFAULT_DATABASE=[master],
DEFAULT_LANGUAGE=[us_english]
END
GO
CREATE USER [ContosoUniversityUser]
FOR LOGIN [IIS APPPOOL\DefaultAppPool]
GO
EXEC sp_addrolemember 'db_owner', 'ContosoUniversityUser'
GO
Notes
Ce script est conçu pour fonctionner avec SQL Server 2008 et avec les paramètres IIS dans Windows 7, tels qu’ils sont spécifiés dans ce didacticiel. Si vous utilisez une autre version de SQL Server ou de Windows, ou si vous configurez IIS sur votre ordinateur différemment, des modifications de ce script peuvent être nécessaires. Pour plus d’informations sur les scripts SQL Server, consultez SQL Server documentation en ligne.
Notes
Note de sécurité Ce script donne db_owner autorisations à l’utilisateur qui accède à la base de données au moment de l’exécution, ce qui correspond à ce que vous aurez dans l’environnement de production. Dans certains scénarios, vous pouvez spécifier un utilisateur qui dispose d’autorisations complètes de mise à jour du schéma de base de données uniquement pour le déploiement, et spécifier pour l’exécution un autre utilisateur qui dispose uniquement des autorisations de lecture et d’écriture de données. Pour plus d’informations, consultez Examen des modifications automatiques Web.config pour Migrations Code First dans Déploiement sur IIS en tant qu’environnement de test.
Configuration du déploiement de base de données pour l’environnement de test
Ensuite, vous allez configurer Visual Studio afin qu’il effectue les tâches suivantes pour chaque base de données :
- Générez un script SQL qui crée la structure de la base de données source (tables, colonnes, contraintes, etc.) dans la base de données de destination.
- Générez un script SQL qui insère les données de la base de données source dans les tables de la base de données de destination.
- Exécutez les scripts générés et le script Grant que vous avez créé dans la base de données de destination.
Ouvrez la fenêtre Propriétés du projet et sélectionnez l’onglet Package/Publier SQL .
Assurez-vous que Actif (Mise en production) ou Mise en production est sélectionné dans la liste déroulante Configuration .
Cliquez sur Activer cette page.
L’onglet Package/Publier SQL est normalement désactivé, car il spécifie une méthode de déploiement héritée. Pour la plupart des scénarios, vous devez configurer le déploiement de base de données dans l’Assistant Publication web . La migration de SQL Server Compact vers SQL Server ou SQL Server Express est un cas particulier pour lequel cette méthode est un bon choix.
Cliquez sur Importer à partir de Web.config.
Visual Studio recherche des chaînes de connexion dans le fichier Web.config, en trouve une pour la base de données d’appartenance et une pour la base de données School, et ajoute une ligne correspondant à chaque chaîne de connexion dans la table Entrées de base de données. Les chaînes de connexion qu’il trouve concernent les bases de données SQL Server Compact existantes, et l’étape suivante consistera à configurer comment et où déployer ces bases de données.
Vous entrez les paramètres de déploiement de la base de données dans la section Détails de l’entrée de base de données sous la table Entrées de base de données . Les paramètres affichés dans la section Détails de l’entrée de base de données concernent la ligne de la table Entrées de base de données sélectionnée, comme illustré dans l’illustration suivante.
Configuration des paramètres de déploiement pour la base de données d’appartenances
Sélectionnez la ligne DefaultConnection-Deployment dans la table Entrées de base de données afin de configurer les paramètres qui s’appliquent à la base de données d’appartenance.
Dans Chaîne de connexion pour la base de données de destination, entrez un chaîne de connexion qui pointe vers la nouvelle base de données d’appartenance SQL Server Express. Vous pouvez obtenir les chaîne de connexion dont vous avez besoin à partir de Server Explorer. Dans Server Explorer, développez Data Connections et sélectionnez la base de données aspnetTest, puis, dans la fenêtre Propriétés, copiez la valeur Chaîne de connexion.
Le même chaîne de connexion est reproduit ici :
Data Source=.\SQLExpress;Initial Catalog=aspnet-Test;Integrated Security=True;Pooling=False
Copiez et collez cette chaîne de connexion dans Chaîne de connexion pour la base de données de destination sous l’onglet Package/Publier SQL.
Assurez-vous que l’option Extraire les données et/ou le schéma d’une base de données existante est sélectionnée. C’est ce qui entraîne la génération et l’exécution automatique des scripts SQL dans la base de données de destination.
La chaîne de connexion de la valeur de la base de données source est extraite du fichier Web.config et pointe vers la base de données de développement SQL Server Compact. Il s’agit de la base de données source qui sera utilisée pour générer les scripts qui s’exécuteront ultérieurement dans la base de données de destination. Étant donné que vous souhaitez déployer la version de production de la base de données, remplacez « aspnet-Dev.sdf » par « aspnet-Prod.sdf ».
Modifiez les options de script de base de donnéesde Schéma uniquement en Schéma et données, car vous souhaitez copier vos données (comptes d’utilisateur et rôles) ainsi que la structure de la base de données.
Pour configurer le déploiement afin d’exécuter les scripts d’octroi que vous avez créés précédemment, vous devez les ajouter à la section Scripts de base de données . Cliquez sur Ajouter un script et, dans la boîte de dialogue Ajouter des scripts SQL , accédez au dossier dans lequel vous avez stocké le script d’octroi (il s’agit du dossier qui contient votre fichier solution). Sélectionnez le fichier nommé Grant.sql, puis cliquez sur Ouvrir.
Les paramètres de la ligne DefaultConnection-Deployment dans Entrées de base de données ressemblent maintenant à l’illustration suivante :
Configuration des paramètres de déploiement pour la base de données scolaire
Ensuite, sélectionnez la ligne SchoolContext-Deployment dans la table Entrées de base de données afin de configurer les paramètres de déploiement de la base de données School.
Vous pouvez utiliser la même méthode que celle utilisée précédemment pour obtenir les chaîne de connexion de la nouvelle base de données SQL Server Express. Copiez cette chaîne de connexion dans Chaîne de connexion pour la base de données de destination sous l’onglet Package/Publier SQL.
Data Source=.\SQLExpress;Initial Catalog=School-Test;Integrated Security=True;Pooling=False
Assurez-vous que l’option Extraire les données et/ou le schéma d’une base de données existante est sélectionnée.
La chaîne de connexion de la valeur de base de données source est extraite du fichier Web.config et pointe vers la base de données SQL Server Compact développement. Remplacez « School-Dev.sdf » par « School-Prod.sdf » pour déployer la version de production de la base de données. (Vous n’avez jamais créé de fichier School-Prod.sdf dans le dossier App_Data. Vous allez donc copier ce fichier de l’environnement de test vers le dossier App_Data dans le dossier de projet ContosoUniversity ultérieurement.)
Remplacez les options de script de base de données par Schéma et données.
Vous souhaitez également exécuter le script pour accorder l’autorisation de lecture et d’écriture pour cette base de données à l’identité du pool d’applications. Ajoutez donc le fichier de script Grant.sql comme vous l’avez fait pour la base de données d’appartenance.
Lorsque vous avez terminé, les paramètres de la ligne SchoolContext-Deployment dans Entrées de base de données ressemblent à l’illustration suivante :
Enregistrez les modifications dans l’onglet Package/Publier SQL .
Copiez le fichier School-Prod.sdf du dossier c :\inetpub\wwwroot\ContosoUniversity\App_Data vers le dossier App_Data du projet ContosoUniversity.
Spécification du mode transactionné pour le script d’octroi
Le processus de déploiement génère des scripts qui déploient le schéma et les données de base de données. Par défaut, ces scripts s’exécutent dans une transaction. Toutefois, les scripts personnalisés (comme les scripts d’octroi) par défaut ne s’exécutent pas dans une transaction. Si le processus de déploiement combine des modes de transaction, vous risquez d’obtenir une erreur de délai d’attente lorsque les scripts s’exécutent pendant le déploiement. Dans cette section, vous modifiez le fichier projet afin de configurer les scripts personnalisés à exécuter dans une transaction.
Dans Explorateur de solutions, cliquez avec le bouton droit sur le projet ContosoUniversity et sélectionnez Décharger le projet.
Cliquez ensuite avec le bouton droit sur le projet et sélectionnez Modifier ContosoUniversity.csproj.
L’éditeur Visual Studio affiche le contenu XML du fichier projet. Notez qu’il existe plusieurs PropertyGroup
éléments. (Dans l’image, le contenu des PropertyGroup
éléments a été omis.)
La première, qui n’a aucun attribut, concerne Condition
les paramètres qui s’appliquent quelle que soit la configuration de build. Un PropertyGroup
élément s’applique uniquement à la configuration de build Debug (notez l’attribut Condition
), l’un s’applique uniquement à la configuration de build Release et l’autre s’applique uniquement à la configuration de build test. Dans l’élément PropertyGroup
de la configuration de build Release, vous verrez un PublishDatabaseSettings
élément qui contient les paramètres que vous avez entrés sous l’onglet Package/Publier SQL . Il existe un Object
élément qui correspond à chacun des scripts d’octroi que vous avez spécifiés (notez les deux instances de « Grant.sql »). Par défaut, l’attribut Transacted
de l’élément Source
pour chaque script d’octroi est False
.
Remplacez la valeur de l’attribut Transacted
de l’élément Source
par True
.
Enregistrez et fermez le fichier projet, puis cliquez avec le bouton droit sur le projet dans Explorateur de solutions, puis sélectionnez Recharger le projet.
Configuration des transformations Web.Config pour les chaînes de connexion
Les chaînes de connexion pour les nouvelles bases de données SQL Express que vous avez entrées sous l’onglet Package/Publier SQL sont utilisées par Web Deploy uniquement pour mettre à jour la base de données de destination pendant le déploiement. Vous devez toujours configurer Web.config transformations afin que les chaînes de connexion dans le fichier Web.config déployé pointent vers les nouvelles bases de données SQL Server Express. (Lorsque vous utilisez l’onglet Package/Publier SQL , vous ne pouvez pas configurer les chaînes de connexion dans le profil de publication.)
Ouvrez Web.Test.config et remplacez l’élément connectionStrings
par l’élément connectionStrings
dans l’exemple suivant. (Veillez à copier uniquement l’élément connectionStrings, et non le code environnant qui s’affiche ici pour fournir un contexte.)
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
<connectionStrings>
<add name="DefaultConnection"
connectionString="Data Source=.\SQLExpress;Initial Catalog=aspnet-Test;Integrated Security=True;Pooling=False;MultipleActiveResultSets=True"
providerName="System.Data.SqlClient"
xdt:Transform="SetAttributes" xdt:Locator="Match(name)"/>
<add name="SchoolContext"
connectionString="Data Source=.\SQLExpress;Initial Catalog=School-Test;Integrated Security=True;Pooling=False;MultipleActiveResultSets=True"
providerName="System.Data.SqlClient"
xdt:Transform="SetAttributes" xdt:Locator="Match(name)"/>
</connectionStrings>
<!-- appSettings element, comments, and system.web element -->
</configuration>
Ce code entraîne le connectionString
remplacement des attributs et providerName
de chaque add
élément dans le fichier Web.config déployé. Ces chaînes de connexion ne sont pas identiques à celles que vous avez entrées dans l’onglet Package/Publier SQL. Le paramètre « MultipleActiveResultSets=True » leur a été ajouté, car il est requis pour Entity Framework et le Fournisseurs universels.
Installation de SQL Server Compact
Le package NuGet SqlServerCompact fournit les assemblys de moteur de base de données SQL Server Compact pour l’application Contoso University. Mais maintenant, ce n’est pas l’application mais Web Deploy qui doit être en mesure de lire les bases de données SQL Server Compact, afin de créer des scripts à exécuter dans les bases de données SQL Server. Pour permettre à Web Deploy de lire SQL Server Compact bases de données, installez SQL Server Compact sur l’ordinateur de développement à l’aide du lien suivant : Microsoft SQL Server Compact 4.0 SP1.
Déploiement dans l’environnement de test
Pour publier dans l’environnement de test, vous devez créer un profil de publication configuré pour utiliser l’onglet Package/Publier SQL pour la publication de base de données au lieu des paramètres de base de données de publication de profil.
Tout d’abord, supprimez le profil de test existant.
Dans Explorateur de solutions, cliquez avec le bouton droit sur le projet ContosoUniversity, puis cliquez sur Publier.
Sélectionnez l’onglet Profil .
Cliquez sur Manage Profiles (Gérer les profils).
Sélectionnez Test, cliquez sur Supprimer, puis sur Fermer.
Fermez l’Assistant Publier le web pour enregistrer cette modification.
Ensuite, créez un profil de test et utilisez-le pour publier le projet.
Dans Explorateur de solutions, cliquez avec le bouton droit sur le projet ContosoUniversity, puis cliquez sur Publier.
Sélectionnez l’onglet Profil .
Sélectionnez <Nouveau...> dans la liste déroulante, puis entrez « Test » comme nom de profil.
Dans la zone URL du service , entrez localhost.
Dans la zone Site/application , entrez Site web par défaut/ContosoUniversity.
Dans la zone URL de destination , entrez http://localhost/ContosoUniversity/
.
Cliquez sur Suivant.
L’onglet Paramètres vous avertit que l’onglet Package/Publier SQL a été configuré et vous permet de les remplacer en cliquant sur Activer les nouvelles améliorations de publication de base de données. Pour ce déploiement, vous ne souhaitez pas remplacer les paramètres de l’onglet Package/Publier SQL . Il vous suffit donc de cliquer sur Suivant.
Un message sous l’onglet Aperçu indique qu’aucune base de données n’est sélectionnée pour la publication, mais cela signifie uniquement que la publication de base de données n’est pas configurée dans le profil de publication.
Cliquez sur Publier.
Visual Studio déploie l’application et ouvre le navigateur sur la page d’accueil du site dans l’environnement de test. Exécutez la page Instructeurs pour voir qu’elle affiche les mêmes données que celles que vous avez vues précédemment. Exécutez la page Ajouter des étudiants , ajoutez un nouvel étudiant, puis affichez le nouvel étudiant dans la page Étudiants . Cela vérifie que vous pouvez mettre à jour la base de données. Sélectionnez la page Mettre à jour les crédits (vous devez vous connecter) pour vérifier que la base de données d’appartenance a été déployée et que vous y avez accès.
Création d’une base de données SQL Server pour l’environnement de production
Maintenant que vous avez déployé dans l’environnement de test, vous êtes prêt à configurer le déploiement en production. Vous commencez comme vous l’avez fait pour l’environnement de test, en créant une base de données sur laquelle déployer. Comme vous le rappelez dans la vue d’ensemble, le plan d’hébergement Cytanium Lite n’autorise qu’une seule base de données SQL Server. Vous ne configurerez donc qu’une seule base de données, et non deux. Toutes les tables et données des bases de données d’appartenance et school SQL Server Compact seront déployées dans une base de données SQL Server en production.
Accédez au panneau de configuration Cytanium à l’adresse http://panel.cytanium.com. Maintenez la souris sur Bases de données, puis cliquez sur SQL Server 2008.
Dans la page SQL Server 2008, cliquez sur Créer une base de données.
Nommez la base de données « School », puis cliquez sur Enregistrer. (La page ajoute automatiquement le préfixe « contosou », de sorte que le nom effectif sera « contosouSchool ».)
Dans la même page, cliquez sur Créer un utilisateur. Sur les serveurs de Cytanium, au lieu d’utiliser la sécurité Windows intégrée et de laisser l’identité du pool d’applications ouvrir votre base de données, vous allez créer un utilisateur autorisé à ouvrir votre base de données. Vous allez ajouter les informations d’identification de l’utilisateur aux chaînes de connexion qui vont dans le fichier Web.config de production. Dans cette étape, vous créez ces informations d’identification.
Renseignez les champs obligatoires dans la page Propriétés de l’utilisateur SQL :
- Entrez « ContosoUniversityUser » comme nom.
- Entrez un mot de passe.
- Sélectionnez contosouSchool comme base de données par défaut.
- Sélectionnez la zone de case activée contosouSchool.
Configuration du déploiement de base de données pour l’environnement de production
Vous êtes maintenant prêt à configurer les paramètres de déploiement de base de données sous l’onglet Package/Publier SQL , comme vous l’avez fait précédemment pour l’environnement de test.
Ouvrez la fenêtre Propriétés du projet , sélectionnez l’onglet Package/Publier SQL et assurez-vous que Actif (Mise en production) ou Mise en production est sélectionné dans la liste déroulante Configuration .
Lorsque vous configurez les paramètres de déploiement pour chaque base de données, la principale différence entre ce que vous faites pour les environnements de production et de test réside dans la façon dont vous configurez les chaînes de connexion. Pour l’environnement de test, vous avez entré différentes chaînes de connexion de base de données de destination, mais pour l’environnement de production, la chaîne de connexion de destination sera la même pour les deux bases de données. En effet, vous déployez les deux bases de données sur une base de données en production.
Configuration des paramètres de déploiement pour la base de données d’appartenance
Pour configurer les paramètres qui s’appliquent à la base de données d’appartenance, sélectionnez la ligne DefaultConnection-Deployment dans la table Entrées de base de données .
Dans Chaîne de connexion pour la base de données de destination, entrez une chaîne de connexion qui pointe vers la nouvelle base de données SQL Server de production que vous venez de créer. Vous pouvez obtenir les chaîne de connexion à partir de votre e-mail de bienvenue. La partie pertinente de l’e-mail contient l’exemple de chaîne de connexion suivant :
Data Source=vserver01.cytanium.com;Initial Catalog={myDataBase};User Id={myUsername};Password={myPassword};
Après avoir remplacé les trois variables, la chaîne de connexion dont vous avez besoin ressemble à cet exemple :
Data Source=vserver01.cytanium.com;Initial Catalog=contosouSchool;User Id=ContosoUniversityUser;Password=Password;
Copiez et collez cette chaîne de connexion dans Chaîne de connexion pour la base de données de destination sous l’onglet Package/Publier SQL.
Assurez-vous que l’option Extraire des données et/ou un schéma d’une base de données existante est toujours sélectionnée, et que les options de script de base de données sont toujours schéma et données.
Dans la zone Scripts de base de données, désactivez la zone case activée en regard du script Grant.sql.
Configuration des paramètres de déploiement pour la base de données scolaire
Ensuite, sélectionnez la ligne SchoolContext-Deployment dans la table Entrées de base de données afin de configurer les paramètres de la base de données Scolaire.
Copiez les mêmes chaîne de connexion dans Chaîne de connexion pour la base de données de destination que vous avez copiée dans ce champ pour la base de données d’appartenance.
Assurez-vous que l’option Extraire des données et/ou un schéma d’une base de données existante est toujours sélectionnée, et que les options de script de base de données sont toujours schéma et données.
Dans la zone Scripts de base de données, désactivez la zone case activée en regard du script Grant.sql.
Enregistrez les modifications dans l’onglet Package/Publier SQL .
Configuration des transformations Web.Config pour les chaînes de connexion aux bases de données de production
Ensuite, vous allez configurer Web.config transformations afin que les chaînes de connexion dans le fichier Web.config déployé pointent vers la nouvelle base de données de production. Le chaîne de connexion que vous avez entré sous l’onglet Package/Publier SQL pour Web Deploy à utiliser est identique à celui que l’application doit utiliser, à l’exception de l’ajout de l’optionMultipleResultSets
.
Ouvrez Web.Production.config et remplacez l’élément connectionStrings
par un connectionStrings
élément qui ressemble à l’exemple suivant. (Copiez uniquement l’élément connectionStrings
, pas les balises environnantes fournies pour afficher le contexte.)
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
<connectionStrings>
<add name="DefaultConnection"
connectionString="Data Source=vserver01.cytanium.com;Initial Catalog=contosouSchool;User Id=ContosoUniversityUser;Password=Password;MultipleActiveResultSets=True"
providerName="System.Data.SqlClient"
xdt:Transform="SetAttributes" xdt:Locator="Match(name)"/>
<add name="SchoolContext"
connectionString="Data Source=vserver01.cytanium.com;Initial Catalog=contosouSchool;User Id=ContosoUniversityUser;Password=Password;MultipleActiveResultSets=True"
providerName="System.Data.SqlClient"
xdt:Transform="SetAttributes" xdt:Locator="Match(name)"/>
</connectionStrings>
<!-- appSettings element, comments, and system.web element -->
</configuration>
Vous voyez parfois des conseils qui vous indiquent de toujours chiffrer les chaînes de connexion dans le fichier Web.config . Cela peut être approprié si vous déployiez sur des serveurs sur le réseau de votre propre entreprise. Toutefois, lorsque vous déployez dans un environnement d’hébergement partagé, vous faites confiance aux pratiques de sécurité du fournisseur d’hébergement et il n’est pas nécessaire ou pratique de chiffrer les chaînes de connexion.
Déploiement dans l’environnement de production
Vous êtes maintenant prêt à déployer en production. Web Deploy lit les bases de données SQL Server Compact dans le dossier App_Data de votre projet et recrée toutes leurs tables et données dans la base de données SQL Server de production. Pour publier à l’aide des paramètres de l’onglet Package/Publier le web , vous devez créer un profil de publication pour la production.
Tout d’abord, supprimez le profil de production existant, comme vous l’avez fait précédemment pour le profil de test.
Dans Explorateur de solutions, cliquez avec le bouton droit sur le projet ContosoUniversity, puis cliquez sur Publier.
Sélectionnez l’onglet Profil .
Cliquez sur Manage Profiles (Gérer les profils).
Sélectionnez Production, cliquez sur Supprimer, puis sur Fermer.
Fermez l’Assistant Publier le web pour enregistrer cette modification.
Ensuite, créez un profil de production et utilisez-le pour publier le projet.
Dans Explorateur de solutions, cliquez avec le bouton droit sur le projet ContosoUniversity, puis cliquez sur Publier.
Sélectionnez l’onglet Profil .
Cliquez sur Importer, puis sélectionnez le fichier .publishsettings que vous avez téléchargé précédemment.
Sous l’onglet Connexion , remplacez l’URL de destination par l’URL temporaire correcte, qui est http://contosouniversity.com.vserver01.cytanium.com
dans cet exemple .
Renommez le profil en Production. (Sélectionnez l’onglet Profil , puis cliquez sur Gérer les profils pour ce faire).
Fermez l’Assistant Publier le web pour enregistrer vos modifications.
Dans une application réelle dans laquelle la base de données a été mise à jour en production, vous devez maintenant effectuer deux étapes supplémentaires avant de publier :
- Chargez app_offline.htm, comme indiqué dans le didacticiel Déploiement dans l’environnement de production .
- Utilisez la fonctionnalité Gestionnaire de fichiers du panneau de configuration Cytanium pour copier les fichiers aspnet-Prod.sdf et School-Prod.sdf du site de production vers le dossier App_Data du projet ContosoUniversity. Cela garantit que les données que vous déployez dans la nouvelle base de données SQL Server incluent les dernières mises à jour apportées par votre site web de production.
Dans la barre d’outils Web One Click Publier , vérifiez que le profil de production est sélectionné, puis cliquez sur Publier.
Si vous avez chargé app_offline.htm avant la publication, vous devez utiliser l’utilitaire Gestionnaire de fichiers dans le panneau de configuration Cytanium pour supprimer app_offline.htm avant de tester. Vous pouvez également supprimer en même temps les fichiers .sdf du dossier App_Data .
Vous pouvez maintenant ouvrir un navigateur et accéder à l’URL de votre site public pour tester l’application comme vous l’avez fait après le déploiement dans l’environnement de test.
Basculer vers SQL Server Express LocalDB dans le développement
Comme expliqué dans vue d’ensemble, il est généralement préférable d’utiliser le même moteur de base de données en développement que celui que vous utilisez dans le test et la production. (N’oubliez pas que l’avantage d’utiliser SQL Server Express dans le développement est que la base de données fonctionnera de la même façon dans vos environnements de développement, de test et de production.) Dans cette section, vous allez configurer le projet ContosoUniversity pour utiliser SQL Server Express LocalDB lorsque vous exécutez l’application à partir de Visual Studio.
Le moyen le plus simple d’effectuer cette migration consiste à laisser Code First et le système d’appartenance créer les deux bases de données de développement pour vous. L’utilisation de cette méthode pour migrer nécessite trois étapes :
- Modifiez les chaînes de connexion pour spécifier de nouvelles bases de données SQL Express LocalDB.
- Exécutez l’outil d’administration de site web pour créer un utilisateur administrateur. Cela crée la base de données d’appartenance.
- Utilisez la commande Migrations Code First update-database pour créer et amorcer la base de données d’application.
Mise à jour des chaînes de connexion dans le fichier Web.config
Ouvrez le fichier Web.config et remplacez l’élément connectionStrings
par le code suivant :
<connectionStrings>
<add name="DefaultConnection" connectionString="Data Source=(LocalDb)\v11.0;Integrated Security=SSPI;AttachDBFilename=|DataDirectory|\aspnet-Dev.mdf;MultipleActiveResultSets=True;" providerName="System.Data.SqlClient" />
<add name="SchoolContext" connectionString="Data Source=(LocalDb)\v11.0;Integrated Security=SSPI;AttachDBFilename=|DataDirectory|\School-Dev.mdf;MultipleActiveResultSets=True;" providerName="System.Data.SqlClient" />
</connectionStrings>
Création de la base de données d’appartenance
Dans Explorateur de solutions, sélectionnez le projet ContosoUniversity, puis cliquez sur ASP.NET configuration dans le menu Projet.
Sélectionnez l'onglet Sécurité.
Cliquez sur Créer ou Gérer des rôles, puis créez un rôle Administrateur.
Revenez à l’onglet Sécurité.
Cliquez sur Créer un utilisateur, puis sélectionnez la zone Administrateur case activée et créez un utilisateur nommé administrateur.
Fermez l’outil d’administration de site web.
Création de la base de données scolaire
Ouvrez la fenêtre Console du Gestionnaire de package.
Dans la liste déroulante Projet par défaut , sélectionnez le projet ContosoUniversity.DAL.
Entrez la commande suivante :
update-database
Migrations Code First applique la migration initiale qui crée la base de données, puis applique la migration AddBirthDate, puis exécute la méthode Seed.
Exécutez le site en appuyant sur Ctrl-F5. Comme vous l’avez fait pour les environnements de test et de production, exécutez la page Ajouter des étudiants , ajoutez un nouvel étudiant, puis affichez le nouvel étudiant dans la page Étudiants . Cela vérifie que la base de données School a été créée et initialisée et que vous disposez d’un accès en lecture et en écriture.
Sélectionnez la page Mettre à jour les crédits et connectez-vous pour vérifier que la base de données d’appartenance a été déployée et que vous y avez accès. Si vous n’avez pas migré vos comptes d’utilisateur, créez un compte d’administrateur, puis sélectionnez la page Mettre à jour les crédits pour vérifier qu’il fonctionne.
Nettoyage des fichiers SQL Server Compact
Vous n’avez plus besoin de fichiers et de packages NuGet inclus pour prendre en charge SQL Server Compact. Si vous le souhaitez (cette étape n’est pas obligatoire), vous pouvez propre fichiers et références inutiles.
Dans Explorateur de solutions, supprimez les fichiers .sdf du dossier App_Data et les dossiers amd64 et x86 du dossier bin.
Dans Explorateur de solutions, cliquez avec le bouton droit sur la solution (et non sur l’un des projets), puis cliquez sur Gérer les packages NuGet pour la solution.
Dans le volet gauche de la boîte de dialogue Gérer les packages NuGet , sélectionnez Packages installés.
Sélectionnez le package EntityFramework.SqlServerCompact , puis cliquez sur Gérer.
Dans la boîte de dialogue Sélectionner des projets , les deux projets sont sélectionnés. Pour désinstaller le package dans les deux projets, désactivez les deux zones case activée, puis cliquez sur OK.
Dans la boîte de dialogue qui vous demande si vous souhaitez également désinstaller les packages dépendants, cliquez sur Non. L’un d’entre eux est le package Entity Framework que vous devez conserver.
Suivez la même procédure pour désinstaller le package SqlServerCompact . (Les packages doivent être désinstallés dans cet ordre, car le package EntityFramework.SqlServerCompact dépend du package SqlServerCompact .)
Vous avez maintenant correctement migré vers SQL Server Express et SQL Server complets. Dans le tutoriel suivant, vous allez apporter une autre modification à la base de données et vous verrez comment déployer des modifications de base de données lorsque vos bases de données de test et de production utilisent SQL Server Express et SQL Server complète.