ASP.NET déploiement web à l’aide de Visual Studio : Résolution des problèmes

par Tom Dykstra

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.

Cette page décrit certains problèmes courants qui peuvent survenir lorsque vous déployez une application web ASP.NET à l’aide de Visual Studio. Pour chacun d’eux, une ou plusieurs causes possibles et des solutions correspondantes sont fournies.

Les scénarios présentés s’appliquent à la fois aux fournisseurs d’hébergement Azure et tiers. Pour plus d’informations sur la résolution des problèmes liés aux applications web dans Azure App Service, consultez les ressources suivantes :

Erreur du serveur dans l’application « / » - Les paramètres d’erreur personnalisés actuels empêchent les détails de l’erreur d’être consultés à distance

Scénario

Après avoir déployé un site sur un hôte distant, vous obtenez un message d’erreur qui mentionne le paramètre customErrors dans le fichier Web.config, mais n’indique pas la cause réelle de l’erreur :

Server Error in '/' Application.
Runtime Error 

Description: An application error occurred on the server. The current custom error settings 
for this application prevent the details of the application error from being viewed remotely 
(for security reasons). It could, however, be viewed by browsers running on the local server 
machine. 

Details: To enable the details of this specific error message to be viewable on remote machines,
please create a <customErrors> tag within a "web.config" configuration file located in the
root directory of the current web application. This <customErrors> tag should then have its
"mode" attribute set to "Off".

Cause et solution possibles

Par défaut, ASP.NET affiche des informations d’erreur détaillées uniquement lorsque votre application web s’exécute sur l’ordinateur local. En règle générale, vous ne souhaitez pas afficher d’informations d’erreur détaillées lorsque votre application web est publiquement disponible sur Internet, car les pirates peuvent être en mesure d’utiliser ces informations pour rechercher des vulnérabilités dans l’application. Toutefois, lorsque vous déployez un site ou des mises à jour sur un site, un problème se produit parfois et vous devez obtenir le message d’erreur réel.

Pour permettre à l’application d’afficher des messages d’erreur détaillés lorsqu’elle s’exécute sur l’hôte distant, modifiez le fichier Web.config pour désactiver le mode CustomErrors, redéployer l’application et réexécutez l’application :

  1. Si l’application Web.config fichier a un élément customErrors dans l’élément system.web, remplacez l’attribut de mode par « off ». Sinon, ajoutez un élément customErrors dans l’élément system.web avec l’attribut de mode défini sur « off », comme illustré dans l’exemple suivant :

    <configuration>
  <system.web>
    <customErrors mode="off"/>
  </system.web>
</configuration>

  2. Déployez l’application.

  3. Exécutez l’application et répétez ce que vous avez fait précédemment à l’origine de l’erreur. Vous pouvez maintenant voir le message d’erreur réel.

  4. Lorsque vous avez résolu l’erreur, restaurez le paramètre customErrors d’origine et redéployez l’application.

Impossible de créer/copier de l'ombre « ContosoUniversity » lorsque ce fichier existe déjà.

Scénario

Lorsque vous essayez d’exécuter un projet dans Visual Studio, vous obtenez une page d’erreur avec un message comme dans l’exemple suivant :

Erreur du serveur dans l’application « / ». Impossible de créer/copier instantanément « ContosoUniversity » alors que ce fichier existe déjà.

Cause et solution possibles

Patientez une minute et actualisez le navigateur, ou recompilez le site et réessayez de l’exécuter.

L’accès est refusé dans une page web qui utilise SQL Server Compact

Scénario

Lorsque vous déployez un site qui utilise SQL Server Compact et que vous exécutez une page dans le site déployé qui accède à la base de données, le message d’erreur suivant s’affiche :

L’accès est refusé. (Exception de HRESULT : 0x80070005 (E_ACCESSDENIED))

Cause et solution possibles

Le compte NETWORK SERVICE sur le serveur doit pouvoir lire les fichiers binaires natifs SQL Service Compact qui se trouvent dans le dossier bin\amd64 ou bin\x86 , mais il n’a pas d’autorisations de lecture pour ces dossiers. Définissez l’autorisation de lecture pour NETWORK SERVICE sur le dossier bin , en veillant à étendre les autorisations aux sous-dossiers.

Impossible de lire le fichier de configuration en raison d’autorisations insuffisantes

Scénario

Lorsque vous cliquez sur le bouton Publier de Visual Studio pour déployer une application sur IIS sur votre ordinateur local, la publication échoue et la fenêtre Sortie affiche un message d’erreur similaire à celui-ci :

Une erreur s’est produite lors de la lecture du fichier de configuration IIS « MACHINE/REDIRECTION ». L’identité effectuant cette opération était ... Erreur : Impossible de lire le fichier de configuration en raison d’autorisations insuffisantes.

Cause et solution possibles

Pour utiliser une publication en un clic sur IIS sur votre ordinateur local, vous devez exécuter Visual Studio avec des autorisations d’administrateur. Fermez Visual Studio et redémarrez-le avec des autorisations d’administrateur.

Impossible de se connecter à l’ordinateur de destination ... Utilisation du processus spécifié

Scénario

Lorsque vous cliquez sur le bouton Publier de Visual Studio pour déployer une application, la publication échoue et la fenêtre Sortie affiche un message d’erreur similaire à celui-ci :

Web deployment task failed.(Could not connect to the destination computer ("<server URL>") using the specified process
("The Web Management Service"). This can happen if a proxy server is interrupting communication with the destination server. 
Disable the proxy server and try again.) ... The remote server returned an error: (502) Bad Gateway.

Cause et solution possibles

Un serveur proxy interrompt la communication avec le serveur de destination. Dans le Panneau de configuration Windows ou dans Internet Explorer, sélectionnez Options Internet et sélectionnez l’onglet Connexions . Dans la boîte de dialogue Propriétés Internet , cliquez sur Paramètres réseau local. Dans la boîte de dialogue Paramètres du réseau local (LAN),décochez la case Détecter automatiquement les paramètres . Cliquez ensuite à nouveau sur le bouton Publier.

Si le problème persiste, contactez votre administrateur système pour déterminer ce qui peut être fait avec les paramètres de proxy ou de pare-feu. Le problème se produit parce que Web Deploy utilise un port non standard pour le déploiement du service de gestion web (8172) ; pour d’autres connexions, Web Deploy utilise le port 80. Lorsque vous effectuez un déploiement sur un fournisseur d’hébergement tiers, vous utilisez généralement le service de gestion web.

Le pool d’applications .NET 4.0 par défaut n’existe pas

Scénario

Lorsque vous déployez une application qui nécessite .NET Framework 4, le message d’erreur suivant s’affiche :

Le pool d’applications .NET 4.0 par défaut n’existe pas ou l’application n’a pas pu être ajoutée. Vérifiez que ASP.NET 4.0 est installé sur cet ordinateur.

Cause et solution possibles

ASP.NET 4 n’est pas installé dans IIS. Si le serveur sur lequel vous effectuez le déploiement est votre ordinateur de développement et que Visual Studio 2010 est installé sur celui-ci, ASP.NET 4 est installé sur l’ordinateur, mais n’est peut-être pas installé dans IIS. Sur le serveur sur lequel vous effectuez le déploiement, ouvrez une invite de commandes avec élévation de privilèges et installez ASP.NET 4 dans IIS en exécutant les commandes suivantes :

cd %windir%\Microsoft.NET\Framework\v4.0.30319
aspnet_regiis.exe –iru

Vous devrez peut-être également définir manuellement la version du .NET Framework du pool d’applications par défaut. Pour plus d’informations, consultez le didacticiel Déploiement sur IIS en tant qu’environnement de test dans cette série.

Le format de la chaîne d’initialisation n’est pas conforme à la spécification commençant à l’index 0.

Scénario

Après avoir déployé une application à l’aide d’une publication en un clic, lorsque vous exécutez une page qui accède à la base de données, vous obtenez le message d’erreur suivant :

Le format de la chaîne d’initialisation n’est pas conforme à la spécification commençant à l’index 0.

Cause et solution possibles

Ouvrez le fichier Web.config dans le site déployé et vérifiez si les valeurs de chaîne de connexion commencent par $(ReplaceableToken_, comme dans l’exemple suivant :

<connectionStrings>
  <add name="DefaultConnection" connectionString="$(ReplaceableToken_DefaultConnection-Web.config Connection String_0)" providerName="System.Data.SqlServerCe.4.0" />
  <add name="SchoolContext" connectionString="$(ReplaceableToken_SchoolContext-Web.config Connection String_0)" providerName="System.Data.SqlServerCe.4.0" />
</connectionStrings>

Si les chaînes de connexion ressemblent à cet exemple, modifiez le fichier projet et ajoutez la propriété suivante à l’élément PropertyGroup correspondant à toutes les configurations de build :

<AutoParameterizationWebConfigConnectionStrings>False</AutoParameterizationWebConfigConnectionStrings>

Redéployez ensuite l’application.

Erreur du serveur interne HTTP 500

Scénario

Lorsque vous exécutez le site déployé, le message d’erreur suivant s’affiche sans informations spécifiques indiquant la cause de l’erreur :

Erreur HTTP 500 - Erreur interne du serveur.

Cause et solution possibles

Il existe de nombreuses causes d’erreurs 500, mais une cause possible, si vous suivez ces didacticiels, est que vous avez placé un élément XML au mauvais endroit dans l'un des fichiers de transformation Web.config. Par exemple, vous obtenez cette erreur si vous placez la transformation qui insère un <élément d’emplacement> sous <system.web> au lieu d’être directement sous <configuration>. Vous pouvez utiliser la fonctionnalité d’aperçu de transformation Web.config pour vérifier que les transformations fonctionnent comme prévu. La solution si vous trouvez une transformation qui a été codée de manière incorrecte consiste à corriger le fichier de transformation et à redéployer. Si une erreur n’est pas évidente, essayez de commenter les transformations et de la redéployer pour voir laquelle est à l’origine de l’erreur 500.

Erreur de serveur interne HTTP 500.21

Scénario

Lorsque vous exécutez le site déployé, le message d’erreur suivant s’affiche :

Erreur HTTP 500.21 - Erreur du serveur interne. Le gestionnaire « PageHandlerFactory-Integrated » a un module incorrect « ManagedPipelineHandler » dans sa liste de modules.

Cause et solution possibles

Le site que vous avez déployé cible ASP.NET 4, mais ASP.NET 4 n'est pas enregistré dans IIS sur le serveur. Sur le serveur, ouvrez une invite de commandes avec élévation de privilèges et inscrivez ASP.NET 4 en exécutant les commandes suivantes :

cd %windir%\Microsoft.NET\Framework\v4.0.30319
aspnet_regiis.exe –iru

Vous devrez peut-être également définir manuellement la version du .NET Framework du pool d’applications par défaut. Pour plus d’informations, consultez le didacticiel Déploiement sur IIS en tant qu’environnement de test dans cette série.

Échec de la connexion lors de l’ouverture de la base de données SQL Server Express dans App_Data

Scénario

Vous avez mis à jour la chaîne de connexion de fichier Web.config pour pointer vers une base de données SQL Server Express en tant que fichier .mdf dans votre dossier App_Data , et la première fois que vous exécutez l’application, le message d’erreur suivant s’affiche :

System.Data.SqlClient.SqlException : Impossible d’ouvrir la base de données « DatabaseName » demandée par la connexion. La connexion a échoué.

Cause et solution possibles

Le nom du fichier .mdf ne peut pas correspondre au nom d’une base de données SQL Server Express qui existe déjà sur votre ordinateur, même si vous avez supprimé le fichier .mdf de la base de données existante précédemment. Remplacez le nom du fichier .mdf par un nom qui n’a jamais été utilisé comme nom de base de données et modifiez le fichier Web.config pour utiliser le nouveau nom. Vous pouvez également utiliser SQL Server Management Studio Express pour supprimer des bases de données SQL Server Express existantes.

Impossible de vérifier la compatibilité du modèle

Scénario

Vous avez mis à jour la chaîne de connexion de fichierWeb.config pour pointer vers une nouvelle base de données SQL Server Express et la première fois que vous exécutez l’application, le message d’erreur suivant s’affiche :

Impossible de vérifier la compatibilité du modèle, car la base de données ne contient pas de métadonnées de modèle. Vérifiez que IncludeMetadataConvention a été ajouté aux conventions DbModelBuilder.

Cause et solution possibles

Si le nom de la base de données que vous avez placé dans le fichier Web.config n’a jamais été utilisé sur votre ordinateur, une base de données peut déjà exister avec certaines tables. Sélectionnez un nouveau nom qui n’a pas été utilisé sur votre ordinateur avant et modifiez le fichier Web.config pour qu’il pointe vers l’utilisation de ce nouveau nom de base de données. Vous pouvez également utiliser l’utilitaire SQL Server Express ou SQL Server Management Studio Express pour supprimer la base de données existante.

Erreur SQL lorsqu’un script tente de créer des utilisateurs ou des rôles

Scénario

Vous utilisez le déploiement de base de données configuré sous l’onglet Package/Publier SQL , les scripts SQL qui s’exécutent pendant le déploiement incluent des commandes Créer un utilisateur ou créer un rôle, et l’exécution de script échoue lorsque ces commandes sont exécutées. Vous pouvez voir des messages plus détaillés, tels que les suivants :

The approximate location of the error was between lines '1' and '3' of the script. 
The verbose log may have more information about the error. The command started with:
CREATE USER [user2] FOR LOGIN [user2] WITH DEFAULT
Error: User does not have permission to perform this action.

Si cette erreur se produit lorsque vous avez configuré le déploiement de base de données dans l’Assistant Publier le web plutôt que l’onglet Package/Publier SQL , créez un thread dans le forum Configuration et Déploiement , et la solution sera ajoutée à cette page de résolution des problèmes.

Cause et solution possibles

Le compte d’utilisateur que vous utilisez pour effectuer le déploiement n’est pas autorisé à créer des utilisateurs ou des rôles. Par exemple, l’entreprise d’hébergement peut affecter les rôles db_datareader, db_datawriter et db_ddladmin au compte d’utilisateur qu’elle configure pour vous. Celles-ci sont suffisantes pour créer la plupart des objets de base de données, mais pas pour créer des utilisateurs ou des rôles. Une façon d’éviter l’erreur consiste à exclure les utilisateurs et les rôles du déploiement de base de données. Pour ce faire, modifiez l’élément PreSource pour le script généré automatiquement de la base de données afin qu’il inclut les attributs suivants :

CopyAllUsers=false, CopyAllRoles=false

Pour plus d’informations sur la modification de l’élément PreSource dans le fichier projet, consultez Guide pratique pour modifier les paramètres de déploiement dans le fichier projet. Si les utilisateurs ou les rôles de votre base de données de développement doivent se trouver dans la base de données de destination, contactez votre fournisseur d’hébergement pour obtenir de l’aide.

Erreur de délai d’expiration SQL Server lors de l’exécution de scripts personnalisés pendant le déploiement

Scénario

Vous avez spécifié des scripts SQL personnalisés à exécuter pendant le déploiement et lorsque Web Deploy les exécute, ils expirent.

Cause et solution possibles

Exécuter plusieurs scripts ayant différents modes de transaction peut entraîner des erreurs de temporisation. Par défaut, les scripts générés automatiquement s’exécutent dans une transaction, mais les scripts personnalisés ne le font pas. Si vous sélectionnez les données et/ou le schéma d’extraction à partir d’une option de base de données existante sous l’onglet Package/Publier SQL , et si vous ajoutez un script SQL personnalisé, vous devez modifier les paramètres de transaction sur certains scripts afin que tous les scripts utilisent les mêmes paramètres de transaction. Pour plus d’informations, consultez Guide pratique pour déployer une base de données avec un projet d’application web.

Si vous avez configuré les paramètres de transaction de sorte que tous soient identiques mais obtiennent toujours cette erreur, une solution de contournement possible consiste à exécuter les scripts séparément. Dans la grille Scripts de base de données de l’onglet Package/Publier SQL, désactivez la case à cocher Inclure pour le script qui provoque l’erreur de délai d’expiration, puis publiez le projet. Revenez ensuite à la grille Scripts de base de données , activez la case à cocher Inclure de ce script, puis désactivez les cases à cocher Inclure pour les autres scripts. Publiez ensuite à nouveau le projet. Cette fois que vous publiez, seul le script personnalisé sélectionné s’exécute.

Le flux de données du manifeste de site n’est pas encore disponible

Scénario

Lorsque vous installez un package à l’aide du fichier deploy.cmd avec l’option t (test), le message d’erreur suivant s’affiche :

Erreur : les données de flux de « sitemanifest/dbFullSql[@path='C :\TEMP\AdventureWorksGrant.sql']/sqlScript » ne sont pas encore disponibles.

Cause et solution possibles

Le message d’erreur signifie que la commande ne peut pas produire de rapport de test. Toutefois, la commande peut s’exécuter si vous utilisez l’option y (installation réelle). Le message indique uniquement qu’il existe un problème lié à l’exécution de la commande en mode test.

Cette application nécessite ManagedRuntimeVersion v4.0

Scénario

Lorsque vous tentez de déployer, le message d’erreur suivant s’affiche :

Le pool d’applications que vous essayez d’utiliser a la propriété « managedRuntimeVersion » définie sur « v2.0 ». Cette application nécessite « v4.0 ».

Cause et solution possibles

ASP.NET 4 n’est pas installé dans IIS. Si le serveur sur lequel vous effectuez le déploiement est votre ordinateur de développement et que Visual Studio 2010 est installé sur celui-ci, ASP.NET 4 est installé sur l’ordinateur, mais n’est peut-être pas installé dans IIS. Sur le serveur sur lequel vous effectuez le déploiement, ouvrez une invite de commandes avec élévation de privilèges et installez ASP.NET 4 dans IIS en exécutant les commandes suivantes :

cd %windir%\Microsoft.NET\Framework\v4.0.30319
aspnet_regiis.exe –i

Impossible de caster Microsoft.Web.Deployment.DeploymentProviderOptions

Scénario

Lorsque vous déployez un package, le message d’erreur suivant s’affiche :

Impossible de convertir l’objet de type « Microsoft.Web.Deployment.DeploymentProviderOptions » en « Microsoft.Web.Deployment.DeploymentProviderOptions ».

Cause et solution possibles

Vous essayez de déployer à partir du Gestionnaire IIS à l’aide de l’interface utilisateur Web Deploy 1.1 sur un serveur sur lequel Web Deploy 2.0 est installé. Si vous utilisez l’outil d’administration à distance IIS pour déployer en important un package, cochez la boîte de dialogue Nouvelles fonctionnalités disponibles lorsque vous établissez la connexion. (Cette boîte de dialogue ne peut s’afficher qu’une seule fois lorsque la connexion est établie pour la première fois. Pour effacer la connexion et recommencer, fermez le Gestionnaire IIS et recommencez-le en entrant inetmgr /reset à l’invite de commandes.) Si l’une des fonctionnalités répertoriées est l’interface utilisateur web Deploy et qu’elle a un numéro de version inférieur à 8, le serveur sur lequel vous effectuez le déploiement peut avoir à la fois les versions 1.1 et 2.0 de Web Deploy installées. Pour effectuer un déploiement à partir d’un client sur lequel la version 2.0 est installée, le serveur doit uniquement avoir installé Web Deploy 2.0. Vous devrez contacter votre fournisseur d’hébergement pour résoudre ce problème.

Impossible de charger les composants natifs de SQL Server Compact

Scénario

Lorsque vous exécutez le site déployé, le message d’erreur suivant s’affiche :

Impossible de charger les composants natifs de SQL Server Compact correspondant au fournisseur ADO.NET de la version 8482. Installez la version correcte de SQL Server Compact. Pour plus d’informations, consultez l’article de la Base de connaissances 974247.

Cause et solution possibles

Le site déployé n’a pas de sous-dossiers amd64 et x86 avec les assemblys natifs dans ceux-ci sous le dossier bin de l’application. Sur un ordinateur sur lequel SQL Server Compact est installé, les assemblys natifs se trouvent dans C :\Program Files\Microsoft SQL Server Compact Edition\v4.0\Private. La meilleure façon d’obtenir les fichiers appropriés dans les dossiers appropriés dans un projet Visual Studio consiste à installer le package NuGet SqlServerCompact. L’installation du package ajoute un script post-build pour copier les assemblys natifs dans amd64 et x86. Toutefois, pour que ces éléments soient déployés, vous devez les inclure manuellement dans le projet. Pour plus d’informations, consultez le didacticiel Déploiement de SQL Server Compact .

Erreur « Chemin d’accès non valide » après le déploiement d’une application Entity Framework Code First

Scénario

Vous déployez une application qui utilise Entity Framework Code First Migrations et un SGBD tel que SQL Server Compact qui stocke sa base de données dans un fichier dans le dossier App_Data. Vous avez configuré Code First Migrations pour créer la base de données après votre premier déploiement. Lorsque vous exécutez l’application, vous obtenez un message d’erreur comme dans l’exemple suivant :

Le chemin d’accès n’est pas valide. Vérifiez le répertoire de la base de données. [Path = c:\inetpub\wwwroot\App_Data\DatabaseName.sdf]

Cause et solution possibles

Code First tente de créer la base de données, mais le dossier App_Data n’existe pas. Vous n’avez pas de fichiers dans le dossier App_Data lorsque vous avez déployé, ou vous avez sélectionné Exclure App_Data sous l’onglet Package/Publier le web de la fenêtre Propriétés du projet. Le processus de déploiement ne crée pas de dossier sur le serveur s’il n’y a aucun fichier dans le dossier à copier sur le serveur. Si vous avez déjà configuré la base de données dans le site, le processus de déploiement supprime les fichiers et le dossier App_Data lui-même si vous avez sélectionné Supprimer des fichiers supplémentaires à la destination dans le profil de publication. Pour résoudre le problème, placez un fichier d’espace réservé tel qu’un fichier .txt dans le dossier App_Data , vérifiez que vous n’avez pas exclu App_Data sélectionné et redéployez.

« L’objet COM qui a été séparé de son RCW sous-jacent ne peut pas être utilisé. »

Scénario

Vous avez réussi à utiliser la publication en un clic pour déployer votre application, puis vous commencez à obtenir cette erreur :

Échec de la tâche de déploiement web. (Impossible de terminer la requête à l’URL de l’agent distant '<https://serverurl.com/msdeploy.axd?site=sitename>'.)
Impossible de terminer la requête à l’URL de l’agent distant '<https://url/msdeploy.axd?site=sitename>'.
La demande a été abandonnée : la demande a été annulée.
L’objet COM qui a été séparé de son RCW sous-jacent ne peut pas être utilisé.

Cause et solution possibles

La fermeture et le redémarrage de Visual Studio sont généralement nécessaires pour résoudre cette erreur.

Échec du déploiement, car les informations d’identification utilisateur utilisées pour la publication n'ont pas l'autorisation setACL.

Scénario

La publication échoue avec une erreur qui indique que vous n’avez pas l’autorisation de définir les autorisations de dossier (le compte d’utilisateur que vous utilisez n’a pas d’autorité setACL).

Cause et solution possibles

Par défaut, Visual Studio définit les autorisations de lecture sur le dossier racine du site et les autorisations d’écriture sur le dossier App_Data. Si vous savez que les autorisations par défaut sur les dossiers de site sont correctes et n’avez pas besoin d’être définies, vous désactivez ce comportement en ajoutant <IncludeSetACLProviderOn Destination>False</IncludeSetACLProviderOnDestination> au fichier de profil de publication (pour affecter un seul profil) ou dans le fichier wpp.targets (pour affecter tous les profils). Pour plus d’informations sur la modification de ces fichiers, consultez Guide pratique pour modifier les paramètres de déploiement dans les fichiers de profil (.pubxml).

Erreurs d’accès refusées lorsque l’application tente d’écrire dans un dossier d’application

Scénario

Votre application échoue lorsqu’elle tente de créer ou de modifier un fichier dans l’un des dossiers d’application, car elle n’a pas d’autorité d’écriture pour ce dossier.

Cause et solution possibles

Par défaut, Visual Studio définit les autorisations de lecture sur le dossier racine du site et les autorisations d’écriture sur le dossier App_Data. Si votre application a besoin d’un accès en écriture à un sous-dossier, vous pouvez définir des autorisations pour ce dossier, comme indiqué dans les didacticiels Définition des autorisations de dossier et déploiement dans les didacticiels sur l’environnement de production de cette série. Si votre application a besoin d’un accès en écriture au dossier racine du site, vous devez l’empêcher de définir un accès en lecture seule sur le dossier racine en ajoutant <IncludeSetACLProviderOn Destination>False</IncludeSetACLProviderOnDestination> au fichier de profil de publication (pour affecter un seul profil) ou au fichier wpp.targets (pour affecter tous les profils). Pour plus d’informations sur la modification de ces fichiers, consultez Guide pratique pour modifier les paramètres de déploiement dans les fichiers de profil (.pubxml).

Erreur de configuration : l’attribut targetFramework fait référence à une version ultérieure à la version installée du .NET Framework

Scénario

Vous avez publié un projet web qui cible ASP.NET 4.5, mais lorsque vous exécutez l’application (avec le mode customErrors défini sur « désactivé » dans le fichier Web.config), vous obtenez l’erreur suivante :

L’attribut « targetFramework » dans l’élément <de compilation> du fichier Web.config est utilisé uniquement pour cibler la version 4.0 et ultérieure du .NET Framework (par exemple, «< compilation targetFramework="4.0 "> »). L’attribut « targetFramework » fait actuellement référence à une version ultérieure à la version installée du .NET Framework. Spécifiez une version cible valide du .NET Framework ou installez la version requise du .NET Framework.

La zone Erreur source de la page d’erreur met en surbrillance la ligne suivante de Web.config comme cause de l’erreur :

<compilation targetFramework="4.5" />

Cause et solution possibles

Le serveur ne prend pas en charge ASP.NET 4.5. Contactez le fournisseur d’hébergement pour déterminer quand et si la prise en charge de ASP.NET 4.5 peut être ajoutée. Si la mise à niveau du serveur n’est pas une option, vous devez déployer un projet web qui cible ASP.NET 4 ou une version antérieure à la place.

Si vous déployez un projet web ASP.NET 4 ou antérieur sur la même destination, activez la case à cocher Supprimer des fichiers supplémentaires à la destination sous l’onglet Paramètres de l’Assistant Publier le web . Si vous ne sélectionnez pas Supprimer des fichiers supplémentaires à la destination, vous continuerez à obtenir la page d’erreur de configuration.

Les fenêtres Propriétés du projet incluent une liste déroulante pour le cadre cible, mais vous ne pouvez pas résoudre ce problème en le changeant simplement de .NET Framework 4.5 à .NET Framework 4. Si vous remplacez l’infrastructure cible par une version antérieure de l’infrastructure, le projet aura toujours des références aux assemblys de la version de framework ultérieure et ne s’exécutera pas. Vous devez modifier manuellement ces références ou créer un projet qui cible .NET Framework 4 ou une version antérieure. Pour plus d’informations, consultez .NET Framework Targeting for Web Sites.

Erreurs de confiance moyenne

Scénario

Lorsque vous exécutez votre application en production, elle rencontre une erreur liée à la confiance intermédiaire.

Cause et solution possibles

De nombreux fournisseurs d’hébergement tiers exécutent votre site web en confiance moyenne, ce qui signifie qu’il existe certaines choses qu’il n’est pas autorisé à faire. Par exemple, le code de l’application ne peut pas accéder au Registre Windows et ne peut pas lire ou écrire des fichiers qui se trouvent en dehors de la hiérarchie des dossiers de votre application. Par défaut, votre application s’exécute en toute confiance sur votre ordinateur local, ce qui signifie que l’application peut être en mesure d’effectuer des opérations qui échoueraient lorsque vous la déployez en production.

Vous pouvez configurer l’application pour qu’elle s’exécute dans un niveau de confiance moyen dans l’environnement IIS local afin de résoudre les problèmes. Pour ce faire, ouvrez l’application Web.config fichier et ajoutez un élément d’approbation dans l’élément system.web , comme illustré dans cet exemple.

<configuration>
  <!-- Settings -->
  <system.web>
    <trust level="Medium" />
    <!-- Settings -->
  </system.web>
</configuration>

L’application s’exécute désormais dans une confiance moyenne dans IIS même sur votre ordinateur local.

Ne faites pas cela si vous effectuez un déploiement sur Azure App Service, car Azure ne nécessite pas de confiance moyenne. Au moment où ce tutoriel est écrit en février 2012, l’utilisation de cette méthode pour que votre application s’exécute dans une confiance moyenne entraîne une erreur dans Azure.

Si vous utilisez Entity Framework Code First Migrations et que vous effectuez un déploiement sur un fournisseur d’hébergement qui exécute votre application dans une approbation moyenne, vérifiez que vous disposez de la version 5.0 ou ultérieure. Dans Entity Framework version 4.3, les migrations nécessitent une confiance totale pour mettre à jour le schéma de base de données.

Erreur HTTP 404.17 introuvable

Scénario

Lorsque vous exécutez le site déployé sur votre ordinateur de développement dans IIS, le message d’erreur suivant indique que le serveur ne peut pas traiter Default.aspx :

Erreur HTTP 404.17 - Introuvable

Le contenu demandé semble être un script et ne sera pas servi par le gestionnaire de fichiers statique.

Cause et solution possibles

ASP.NET 4.5 peut ne pas être installé sur votre ordinateur. Consultez les étapes décrites dans le didacticiel Déploiement sur IIS en tant qu’environnement de test dans cette série qui expliquent comment installer ASP.NET 4.5.

Précédent

  • Last updated on