Je remarque qu'il y a fréquemment un dossier aspnet_client sous la structure standard du dossier web IIS. À quoi cela sert-il? Est-ce nécessaire?
Il apparaît pour vous rappeler comment ne plus faire ce genre de choses... :)
Je remarque qu'il y a fréquemment un dossier aspnet_client sous la structure standard du dossier web IIS. À quoi cela sert-il? Est-ce nécessaire?
À l'époque de .NET 1.1 et avant, ce dossier fournissait à ASP.NET son support JavaScript pour les contrôles de validation et autres fonctionnalités. Si vous n'avez pas de site .NET 1.1 ou plus ancien en cours d'exécution, il devrait être sûr de le supprimer. Je le renommerais d'abord pour m'assurer qu'il ne cause aucun problème.
Même si vous êtes désormais sorti de l'époque .Net 1.1, vous pouvez toujours utiliser Crystal Reports, qui malheureusement utilise toujours le dossier mentionné (et il y a probablement d'autres logiciels qui ont le même comportement). Donc, au moins, faites une sauvegarde avant de supprimer le dossier.
En plus de ce que les autres ont dit, il est généralement créé par l'outil aspnet_regiis, qui peut être exécuté (ou réexécuté) par des éléments tels que Windows Update/Ajouter ou supprimer des composants Windows/IIS. Donc parfois même si vous le supprimez, il peut revenir aléatoirement. Il peut y avoir un moyen d'arrêter ce comportement, mais je ne l'ai pas trouvé (peut-être que changer la version de l'application en .NET 2 le ferait en réalité).
Donc, sauf si vous utilisez certaines fonctionnalités de .NET 1.0/1.1 (validation, navigation intelligente, etc.), vous pouvez le supprimer sans aucun problème, mais ne soyez pas trop surpris s'il revient!
Je trouve que cela revient périodiquement. Ce qui est le plus frustrant à ce sujet, c'est qu'à chaque fois que cela revient, cela casse WebDeploy car le compte sous lequel il s'exécute n'a pas accès pour supprimer le dossier aspnet_client créé!
@RussCam J'ai exactement le même problème. Cela casse le WebDeploy pour la même raison. Est-ce que quelqu'un a trouvé un moyen d'empêcher la création aléatoire de ce dossier ?
Je viens d'innocemment installer DotNet Framework 4.5 et peu de temps après, notre déploiement WebDeploy (déclenché via TeamCity) s'est cassé pour la MÊME raison. Le fichu dossier est revenu à nouveau suite à l'installation de 4.5. Quelqu'un, s'il vous plaît, faites que ça s'arrête.
Aspnet_client est un dossier pour "des ressources qui doivent être servies via HTTP, mais qui sont installées sur une base par serveur, plutôt que sur une base par application".
Certaines utilisations d'aspnet_client incluent le stockage de ressources (par exemple JavaScript, images) pour :
Probablement, il y a/aura d'autres (ab)usages de ce dossier à l'avenir. Il va sans dire que, puisqu'il contient des choses qui sont "nécessaires pour que l'application fonctionne correctement" mais qui "ne sont pas censées être déployées par l'application", il restera quelque chose de cauchemardesque tant pour les développeurs que pour les administrateurs système.
Il semble que le 'prototype' pour le contenu du dossier se trouve dans C:\inetpub\wwwroot, et il semble raisonnable de supposer que si un site web IIS donné ne contient pas de ressource /aspnet_client, alors IIS essaiera de faire ce qu'il faut et... en dernier recours... de créer un dossier physique dans le dossier racine du site web, et de copier les fichiers là-bas. Il semble qu'IIS fera au moins cela lorsque "ASPNET_regiis /c" est invoqué sur un serveur donné - ce qui se produit probablement automatiquement à certains moments critiques... comme lorsque des mises à jour du framework .NET sont appliquées à un serveur qui a le rôle IIS.
Les stratégies pour gérer le répertoire aspnet_client comprennent :
Probablement le plus important, en tant que développeur, vous devriez bien comprendre et documenter les dépendances de vos applications par rapport au dossier aspnet_client, et vous assurer que votre procédure d'installation contient des instructions pertinentes pour vous assurer que le dossier existe. Cependant, vous ne devriez probablement pas vous donner la peine de fournir réellement le dossier en tant que partie de votre application web empaquetée ou de votre site web - comment pourriez-vous le faire pour chaque version du framework .NET que le serveur verra au cours de la durée de vie de votre application ?!
Quelques liens sur lesquels je reviendrai plus tard :
Oui, j'ai découvert cela à la dure. J'ai déplacé notre instance Ripplestone d'un répertoire virtuel sous le Default Web Site vers son propre site web, et tout a commencé à se casser de manière étrange dans Ripplestone. J'ai regardé la console javascript et j'ai vu qu'elle cherchait des choses sous C:\inetpub\wwwroot\aspnet_client\system_web\4_0_30319\crystalreportviewers13
Pas sûr si c'était la bonne chose à faire ou non, mais j'ai simplement copié l'intégralité du dossier aspnet_client de la racine vers le répertoire où se trouvait mon instance Ripplestone.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.