Share via

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

  • Article

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 Visual Studio 2010. Pour plus d’informations sur la série, consultez le premier tutoriel 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 chacune d’elles, une ou plusieurs causes possibles et des solutions correspondantes sont fournies.

Les scénarios présentés s’appliquent à Azure et aux fournisseurs d’hébergement tiers. Pour en savoir plus sur la résolution des applications web dans le Service d’application Microsoft Azure, consultez les ressources suivantes :

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

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 qui 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étaillées sur les erreurs 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étaillées sur les erreurs lorsque votre application web est accessible au public sur Internet, car les pirates informatiques peuvent être en mesure d’utiliser ces informations pour détecter des vulnérabilités dans l’application. Toutefois, lorsque vous déployez un site ou des mises à jour sur un site, il arrive que quelque chose se passe mal et que 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 afin de désactiver le mode customErrors, redéployer l’application et réexécutez l’application :

  1. Si le fichier Web.config application a un élément customErrors dans l’élément system.web, remplacez l’attribut mode par « off ». Sinon, ajoutez un élément customErrors dans l’élément system.web avec l’attribut 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 tout ce que vous avez fait précédemment à l’origine de l’erreur. Vous pouvez maintenant voir quel est le message d’erreur réel.

  4. Une fois l’erreur résolue, restaurez le paramètre customErrors d’origine et redéployez l’application.

Impossible de créer/d’effectuer un cliché instantané « 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 semblable à l’exemple suivant :

Erreur de serveur dans l’application « / ». Impossible de créer/d’effectuer un cliché instantané « ContosoUniversity » lorsque ce fichier existe déjà.

Cause et solution possibles

Attendez 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 SERVICE RÉSEAU sur le serveur doit être en mesure de lire les fichiers binaires natifs SQL Service Compact qui se trouvent dans le dossier bin\amd64 ou bin\x86 , mais il ne dispose 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 semblable à 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 la 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 semblable à 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, puis sélectionnez l’onglet Connexions. Dans la boîte de dialogue Propriétés Internet, cliquez sur Paramètres LAN. Dans la boîte de dialogue Paramètres du réseau local (LAN), désactivez la case à cocher 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 déployez 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 ne l’est peut-être pas 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 .NET Framework du pool d’applications par défaut. Pour plus d’informations, consultez le tutoriel Déploiement sur IIS en tant qu’environnement de test de 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 de la publication en un clic, lorsque vous exécutez une page qui accède à la base de données, vous recevez 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 case activée pour voir 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 pour toutes les configurations de build :

<AutoParameterizationWebConfigConnectionStrings>False</AutoParameterizationWebConfigConnectionStrings>

Redéployez ensuite l’application.

Erreur interne du serveur 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 l’une des causes possibles si vous suivez ces tutoriels est que vous placez un élément XML au mauvais emplacement dans l’un des fichiers de transformation Web.config. Par exemple, vous obtiendrez cette erreur si vous placez la transformation qui insère un <élément location> sous <system.web> plutôt que directement sous <la configuration>. Vous pouvez utiliser la fonctionnalité d’aperçu de transformation Web.config pour vérifier que les transformations fonctionnent comme prévu. Si vous trouvez une transformation mal codée, la solution consiste à corriger le fichier de transformation et à redéployer. Si une erreur n’est pas évidente, essayez de commenter les transformations et de redéployer pour voir laquelle est à l’origine de l’erreur 500.

Erreur interne du serveur 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 interne du serveur. 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 inscrit 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 .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 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 qu’elle pointe vers une base de données SQL Server Express en tant que fichier .mdf dans votre dossier App_Data. 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 a déjà existé 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 du fichierWeb.config pour qu’elle pointe 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 a déjà été utilisé sur votre ordinateur, une base de données existe peut-être déjà avec certaines tables. Sélectionnez un nouveau nom qui n’a pas été utilisé sur votre ordinateur auparavant et modifiez le fichier Web.configpour qu’il pointe pour utiliser ce nouveau nom de base de données. Vous pouvez également utiliser SQL Server Express Utility 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 les commandes Créer un utilisateur ou Créer un rôle, et l’exécution du 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 Publication web plutôt que dans 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 un déploiement n’est pas autorisé à créer des utilisateurs ou des rôles. Par exemple, la société d’hébergement peut attribuer les rôles db_datareader, db_datawriter et db_ddladmin au compte d’utilisateur qu’elle configure pour vous. Elles 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 inclue 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.

SQL Server erreur de délai d’expiration 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 quand Web Deploy les exécute, ils expirent.

Cause et solution possibles

L’exécution de plusieurs scripts avec différents modes de transaction peut entraîner des erreurs de délai d’attente. Par défaut, les scripts générés automatiquement s’exécutent dans une transaction, mais pas les scripts personnalisés. Si vous sélectionnez l’option Extraire les données et/ou le schéma d’une 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 afin que tous soient identiques, mais que vous obtenez 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/Publication SQL, désactivez la zone Inclure case activée pour le script qui provoque l’erreur de délai d’expiration, puis publiez le projet. Revenez ensuite dans la grille Scripts de base de données, sélectionnez la zone Inclure case activée de ce script, puis désactivez les zones Inclure case activée pour les autres scripts. Ensuite, publiez à nouveau le projet. Cette fois, lorsque vous publiez, seul le script personnalisé sélectionné s’exécute.

Les données de flux du manifeste de site ne sont pas encore disponibles

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 lors de l’exécution de la commande en mode test.

Cette application nécessite ManagedRuntimeVersion v4.0

Scénario

Lorsque vous essayez 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é dessus, ASP.NET 4 est installé sur l’ordinateur, mais peut ne pas l’être 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 des services Internet à 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 le déploiement en important un package, case activée 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 des services Internet 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 déployez peut avoir 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 avoir uniquement Web Deploy 2.0 installé. 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 974247 de la Base de connaissances.

Cause et solution possibles

Le site déployé n’a pas de sous-dossiers amd64 et x86 contenant les assemblys natifs dans le dossier bin de l’application. Sur un ordinateur sur lequel SQL Server Compact installés, 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 corrects 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 qu’ils soient déployés, vous devez les inclure manuellement dans le projet. Pour plus d’informations, consultez le didacticiel Déploiement SQL Server Compact.

Erreur « Le chemin d’accès n’est pas valide » après le déploiement d’une application Entity Framework Code First

Scénario

Vous déployez une application qui utilise Migrations Entity Framework Code First 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 Migrations Code First configuré 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 semblable à 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. Soit vous n’aviez aucun fichier dans le dossier App_Data lorsque vous avez déployé, soit vous avez sélectionné Exclure App_Data sous l’onglet Package/Publier le web de l’Fenêtre Propriétés de 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 les 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 , assurez-vous que l’option Exclure App_Data n’est pas sélectionnée, puis redéployez-la.

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

Scénario

Vous avez utilisé 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 demande d’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 tout ce qui est nécessaire pour résoudre cette erreur.

Le déploiement échoue, car les informations d’identification utilisateur utilisées pour la publication n’ont pas d’autorité setACL

Scénario

La publication échoue avec une erreur indiquant que vous n’avez pas l’autorité pour définir les autorisations de dossier (le compte d’utilisateur que vous utilisez n’a pas l’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’ont pas besoin d’être définies, vous pouvez désactiver ce comportement en ajoutant <IncludeSetACLProviderOn Destination>False</IncludeSetLProviderOnDestination> au fichier de profil de publication (pour affecter un profil unique) 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).

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

Scénario

Votre application effectue des erreurs 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 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 l’accès en lecture seule sur le dossier racine en ajoutant <IncludeSetACLProviderOn Destination>False</IncludeSetACLProviderOnDestination> au fichier de profil de publication (pour affecter un profil unique) 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 correctement 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 les versions 4.0 et ultérieures 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 évidence 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 dans la même destination, sélectionnez la zone Supprimer des fichiers supplémentaires à l’case activée de destination sous l’onglet Paramètres de l’Assistant Publier le web. Si vous ne sélectionnez pas Supprimer des fichiers supplémentaires à destination, vous continuez à obtenir la page Erreur de configuration.

Les fenêtres Propriétés du projet incluent une liste déroulante Framework cible, mais vous ne pouvez pas résoudre ce problème en remplaçant simplement .NET Framework 4.5 en .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 version antérieure. Pour plus d’informations, consultez Ciblage .NET Framework pour les sites web.

Erreurs de confiance moyenne

Scénario

Lorsque vous exécutez votre application en production, une erreur liée à l’approbation moyenne s’affiche.

Cause et solution possibles

De nombreux fournisseurs d’hébergement tiers exécutent votre site web en confiance moyenne, ce qui signifie qu’il n’est pas autorisé à faire certaines choses. Par exemple, le code d’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 de 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 échouent lorsque vous la déployez en production.

Vous pouvez configurer l’application pour qu’elle s’exécute en confiance moyenne dans l’environnement IIS local afin de résoudre les problèmes. Pour ce faire, ouvrez le fichier deWeb.config d’application 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 en confiance moyenne dans IIS, même sur votre ordinateur local.

N’effectuez pas cette opération si vous déployez sur Azure App Service, car Azure ne nécessite pas d’approbation moyenne. Au moment de l’écriture de ce didacticiel en février 2012, l’utilisation de cette méthode pour exécuter votre application en niveau de confiance moyenne entraîne une erreur dans Azure.

Si vous utilisez Migrations Entity Framework Code First et que vous effectuez un déploiement sur un fournisseur d’hébergement qui exécute votre application en confiance 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 approbation 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 pris en charge par le gestionnaire de fichiers statiques.

Cause et solution possibles

ASP.NET 4.5 n’est peut-être pas installé sur votre ordinateur. Consultez les étapes du tutoriel Déploiement sur IIS en tant qu’environnement de test de cette série qui expliquent comment installer ASP.NET 4.5.

Précédent