Aspnetcore: IIS -> Verrouiller le fichier DLL de l'application .NET Core

Voir app_offline.htm: https://docs.asp.net/en/latest/hosting/aspnet-core-module.html#asp -net-core-module-app-offline-htm

Si vous souhaitez une manière PowerShell de le faire, vous pouvez utiliser les applets de commande IIS Admin: https://technet.microsoft.com/en-us/library/ee790599.aspx

Stop-WebAppPool -Name $appPoolName

... deploy ...

Start-WebAppPool -Name $appPoolName

Merci pour l'explication @Tratcher .
Je ne sais pas si cela fait partie de vos plans, mais cela a fonctionné pour le précédent ASP.NET MVC, je pense?
Avez-vous l'intention de mettre en œuvre cette fonctionnalité ou non?

@GuardRex Je ne peux pas le faire car il s'agit d'un environnement d'hébergement partagé et je n'ai pas l'autorisation d'arrêter AppPool

Pouvez-vous faire fonctionner simplement avec msdeploy.exe et Azure? Si je comprends bien, le site Web doit être redémarré pour éviter le verrouillage des fichiers. -enableRule:AppOffline fonctionne mais l'ensemble du site Web est hors ligne pendant quelques minutes, ce qui n'est pas une excellente expérience utilisateur, d'autant plus que nous déployons quelques fois par jour.

Voir également http://stackoverflow.com/q/40276582/14131

@chuchuva peut-être, mais toute magie a un coût. Les versions précédentes d'ASP.NET effectuaient des clichés instantanés compliqués pour contourner les problèmes de verrouillage de fichiers.

Magique ou pas, ça a bien fonctionné. Cela me manque un peu maintenant après la migration vers ASP.NET Core ...

D'accord avec @HarelM. Nous avons rencontré des problèmes avec cela, de nos déploiements automatisés à l'expérience de l'utilisateur final. Nous sommes passés du déploiement d'environ 10 fois par jour avec l'ancien MVC à peut-être un déploiement quotidien la nuit et en acceptant que les personnes utilisant l'application Core soient ennuyées lorsque nous la mettrons hors ligne. Bien que ce ne soit pas un obstacle au spectacle, cela ajoute des frictions à l'adoption de Core.

👍

Ne pas soutenir le recyclage avec chevauchement est une régression.

Est-il prévu de revoir cette fonctionnalité et de la mettre sur la feuille de route? Il est très peu pratique / peu convivial d'exiger de tout le monde qui déploie un site Web .Net Core de mettre en œuvre manuellement une stratégie de créneau intermédiaire s'il souhaite prendre en charge les déploiements sans temps d'arrêt.

Cette fonctionnalité rendrait la transition vers les sites Web .Net Core beaucoup plus fluide pour de nombreuses personnes et permettrait une adoption plus rapide des sites Web .Net Core.

Nous aimerions également le savoir. Mettre un app_offline.htm dans le répertoire des applications ne fonctionne pas.

Je viens juste de réaliser cette «fonctionnalité» après avoir déplacé un certain nombre de sites vers AspNetCore. Je ne peux pas croire qu'il soit jugé acceptable de mettre vos sites hors ligne pendant quelques minutes à chaque fois que vous souhaitez publier!

C'est déjà assez pour moi en tant que chef d'une petite équipe - ceux qui pratiquent l'intégration continue à grande échelle évitent-ils AspNetCore? Il n'y a aucun moyen qu'ils puissent mettre leur site hors ligne pendant des minutes toutes les heures pour le republier!

Déployez-vous utiliser FTP ou xcopying? Ou utilisez-vous webdeploy?

Je publie via webdeploy sur IIS.

Nous travaillons actuellement à ce problème en supprimant d'abord le fichier web.config (en tuant effectivement l'application), mais ce n'est pas vraiment une solution acceptable à long terme.

@DaleMckeown idéalement avec un flux de travail d'intégration continue, vous auriez plusieurs serveurs derrière un équilibreur de charge. Vous tiriez ensuite un serveur, le mettiez à jour, le remettiez en place et passiez au suivant. Bien sûr, ce n'est pas toujours possible (comme dans notre cas), vous devrez donc vivre avec quelques minutes d'arrêt. Dans notre cas, l'application est sauvegardée dans les 30 secondes, ce n'est donc pas vraiment un problème.

@DaleMckeown

Je publie via webdeploy sur IIS.

Il existe quelques options qui peuvent être utilisées pour que le déploiement à l'aide de webdeploy fonctionne correctement (il prend en charge le changement de nom des fichiers verrouillés et la suppression automatique de l'application hors ligne). Est-ce le cas par défaut @shirhatti ?

@ajeckmans

Nous travaillons actuellement à ce problème en supprimant d'abord le fichier web.config (en tuant effectivement l'application), mais ce n'est pas vraiment une solution acceptable à long terme.

Cela signifie-t-il que vous effectuez un déploiement xcopy?

Il existe quelques options qui peuvent être utilisées pour que le déploiement à l'aide de webdeploy fonctionne correctement (il prend en charge le changement de nom des fichiers verrouillés et la suppression automatique de l'application hors ligne). Est-ce le cas par défaut @shirhatti ?

Merci David - sonne mieux que ce que je fais actuellement (arrêt manuel du site et du pool d'applications dans IIS). Pouvez-vous indiquer quelques ressources pour que je puisse étudier les implications de ces approches?

@DaleMckeown quelques informations jusqu'à ce que je trouve la source de la vérité https://github.com/Microsoft/vsts-tasks/issues/5259#issuecomment -346202503

@davidfowl Nous utilisons webdeploy pour déployer sur notre serveur de tests (qui btw ne nous pose jamais de problèmes), à partir de là, nous copions les fichiers sur nos serveurs en direct en utilisant robocopy

@ajeckmans

Nous travaillons actuellement à ce problème en supprimant d'abord le fichier web.config

Lorsque le fichier web.config est supprimé du déploiement, IIS servira les fichiers sensibles du déploiement. Un attaquant pourrait simplement demander des fichiers en continu jour et nuit jusqu'à ce que la fenêtre de la trentaine s'ouvre.

@DaleMckeown

En suivant les conseils de https://github.com/guardrex/aspnetcore-iis-ps-publish ... mais regardez simplement cela comme un exemple expérimental et non comme un script de qualité de production. Je n'ai pas joué avec ça depuis un moment, mais ça devrait (en théorie) toujours fonctionner.

@guardrex vous avez raison. Nous copions d'abord un app_offline.htm dans le répertoire, puis nous remivons le web.config, copions sur l'application, remettons le web.config et supprimons l'app_offline (le tout avec un script ofc). Malheureusement, le simple fait de placer le fichier app_offline dans le répertoire des sites Web ne rompt pas le verrou sur les dll. Nous devons supprimer le web.config, une action que nous n'avons pas besoin de faire pour les anciennes applications complètes asp.net (comme les anciens formulaires Web, etc.)

@ajeckmans Cela ne devrait pas fonctionner. Lorsque le fichier web.config est supprimé, IIS sélectionne immédiatement ce changement, il doit donc demander par défaut au module de fichier statique et commencer à servir les fichiers. Essayez-le et voyez si c'est ce qui se passe ...

1. Ajoutez app_offline.htm .
2. Confirmez que le site sert app_offline.htm .
3. Extrayez le fichier web.config .
4. Demandez un fichier sensible (par exemple, http://localhost:<PORT>/<ASSEMBLY_NAME>.deps.json ... en remplaçant le PORT et le ASSEMBLY_NAME).
5. Vous devriez obtenir le fichier deps.json servi si votre module de fichier statique fonctionne correctement.

Je ne ferais pas confiance à la simple suppression du module avec ...

<configuration> 
 <system.webServer> 
   <modules> 
     <remove name="StaticFileModule" /> 
   </modules> 
 </system.webServer> 
</configuration>

... puisque d'autres modules resteraient et présenteraient éventuellement d'autres vecteurs d'attaque. On pourrait peut-être supprimer tous les modules non essentiels, mais nous entrons dans des eaux inexplorées avec un mouvement comme celui-là juste pour couvrir un déploiement via la suppression de web.config . Cela n'a jamais été une option sous la direction officielle, et elle n'est donc pas du tout prise en charge. Je recommande le script PS, par exemple, pour supprimer AppPool, ou une autre stratégie.

Je suppose que je devrais ajouter une note de sympathie à cela ... cela a soulevé quelques sourcils du point de vue de la sécurité. Lorsque ce changement de disposition de déploiement a été effectué, il a été discuté, y compris la remise du fichier dans wwwroot , voir ...

Discussion pour: Publier pour les modifications IIS à l'emplacement web.config (IISIntegration 158)
Head-check sur le déplacement de web.config vers wwwroot (IISIntegration 164)

[EDIT] C'est peut-être votre solution de contournement (non prise en charge): déplacez le web.config vers wwwroot , puis continuez ce que vous faites. Encore ... un peu effrayant de casser l'application pour la mettre hors ligne comme ça.

Cela me laisse encore plus confus sur ce que nous devrions faire dans cette situation.

Quelle est la recommandation actuelle pour la publication de sites AspNetCore sur IIS via un déploiement Web de manière à éviter les verrouillages de fichiers?

J'aimerais aussi savoir. Cela devient un obstacle majeur à l'adoption du noyau .net dans mon organisation.

Lorsque mon application Web principale .net est en cours d'exécution et que j'essaie de publier une nouvelle version, cela me donne une erreur indiquant que les DLL sont en cours d'utilisation. Je dois donc arrêter le pool d'applications, puis mettre à jour les DLL et démarrer le pool d'applications.

Existe-t-il une solution de contournement dans .Net Core par laquelle je peux publier la nouvelle version / DLL sans arrêter le pool d'applications?

Ceci est pris en charge par défaut dans le framework .Net à l'aide du mécanisme de cliché instantané. Malheureusement, cela fait 2 ans depuis le lancement de .Net core et il semble qu'il n'y ait toujours pas de support pour ces fonctionnalités très basiques et requises. Y a-t-il même des plans pour résoudre ce problème à l'avenir?

Merci d'avance pour votre aide.

@guardrex, il est en effet effrayant de casser l'application pour que IIS (ou tout ce qui retient le verrou) libère les dll, mais il est encore plus effrayant de ne pas pouvoir pousser les correctifs sur un produit. Pour le moment, casser l'application est la seule chose que nous pouvons faire, mais nous examinons souvent d'autres approches plus modernes pour gérer cela :)

@ shahjay748 ne
Lequel ofc ne nous aide pas qui sont, pour le moment, coincés avec d'anciens processus :)

Ce que je fais (je ne sais pas si c'est une bonne façon de le faire), c'est télécharger le site dans un autre répertoire et changer de chemin dans iis

Nous avons mené une enquête interne sur ce problème. D'après ce que je peux dire, ANCM ne contient aucun fichier / descripteur dans l'application déployée. Cela semble être un problème avec webdeploy lui-même, et le déploiement échoue de manière saccadée. Je n'ai jamais fait échouer systématiquement le déploiement de l'application après avoir réessayé plusieurs fois une fois que app_offline a été supprimé.

Ajout d'une note d'accompagnement PowerShell rapide à cela: le verrou sur l'assembly de l'application est toujours libéré ... Je n'ai jamais eu de problème ( encore! Lol).

@ bpetersen1 ... Votre approche de "mise en scène" a le doux effet secondaire d'offrir une option de restauration rapide si le nouveau déploiement échoue. Cela devrait être facile à écrire si nécessaire.

C'est toujours ennuyeux à l'extérieur ... nous avons décidé de chercher une solution de docker afin de laisser IIS derrière.

Je vais expérimenter une solution. Restez à l'écoute.

J'ai également ce problème en utilisant FTP.

Quel est le conseil de Microsoft à ce sujet?!

J'ai également ce problème en utilisant FTP.

Quel est le conseil de Microsoft à ce sujet?!

Déposez un fichier appoffline.htm, puis ftp puis supprimez-le.

@davidfowl Oui, c'est ce que je fais en ce moment avec un fichier batch. Il faut quelques secondes à IIS pour libérer le verrou, puis copier les fichiers.

Merci - par intérêt comment exécutez-vous le fichier batch?

Aussi un lien vers la documentation de MIcrosoft sur ce sujet apprécié; Je ne le trouve pas sur google. Merci.

@ niico100 Fondamentalement, le fichier de commandes copie simplement les fichiers dans le répertoire du projet, et je crée un dossier de sauvegarde avant de le faire. Avant de copier les fichiers, placez appoffline.htm dans le dossier du projet.
Cause le problème de verrouillage de fichier, la copie effectuera une nouvelle tentative. J'utilise robcopy
https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/robocopy

Si quelqu'un est intéressé, le script suivant télécharge le fichier de déploiement depuis appveyor, arrête le site, copie les fichiers requis et rétablit le site:
https://github.com/IsraelHikingMap/Site/blob/master/Scripts/Deploy.ps1
Il nécessite cependant d'être exécuté en tant qu'administrateur. j'espère que docker résoudra tout ce non-sens une fois que nous aurons migré ...
il utilise les commandes Stop-WebAppPool et Start-WebAppPool powershell.

Pour le développement local, WebDeploy n'a pas fonctionné pour moi. J'ai essayé de l'utiliser contre mon IIS local et il se plaignait toujours de fichiers verrouillés. J'ai ensuite essayé d'utiliser les commandlets PowerShell ci-dessus à partir d'événements VS Pre / Post build, mais cela n'a pas fonctionné pour moi non plus, probablement parce que PowerShell 32 bits ne peut pas modifier les paramètres IIS 64 bits? Quoi qu'il en soit, ce qui semble bien fonctionner, ce sont les événements pré / post build suivants dans mon projet ASP.Net Core:

Événement de pré-construction:
echo "App Offline" /a > $(ProjectDir)app_offline.htm

Événement post-construction:
del $(ProjectDir)app_offline.htm

J'ai parcouru brièvement les plaintes ici, et il semble que cela puisse être lié. J'ai déplacé les déploiements CI pour nous du déploiement d'octopus qui généralement "juste fonctionné", à l'utilisation des versions azure devops avec les tâches de gestion iis, et j'ai encore assez souvent des problèmes pour déployer de nouveaux fichiers car même après l'arrêt de l'application web, l'arrêt du domaine d'application, les fichiers sont toujours en cours utilisation.

Il s'agit probablement d'au moins 1 déploiement sur 3 et je n'ai rien trouvé qui semble améliorer la situation ou qui se déploie plus fiable.

@Tratcher @ronnyek Cela semble être lié à Application Insights; après avoir ajouté l'extension App Insights, ma DLL d'application Web est soudainement très difficile à mettre à jour, aucun problème avant.

Cela aurait du sens étant donné qu'App Insights doit connecter le profileur au processus d'application et aux DLL.

Je suis toujours confronté à ce problème. J'utilise le drapeau -e nableRule: AppOffline , parfois cela fonctionne bien mais la plupart du temps, le déploiement échoue en saing "ERROR_FILE_IN_USE".

Après avoir démarré une version, je surveille le dossier de l'application Web et vois le App_Offline.html déposé par msdeploy. Ensuite, la version a échoué avec le message ci-dessus et notez le fichier App_Offline toujours dans le dossier, je relance la version, cette fois cela fonctionne bien car le module voit le fichier dans le dossier.

dernier runtime asp.net core installé -> aspnetcore.dll 12.1.18263.2

Des idées ? Encore un bug?

@dhtek Si vous essayez de remplacer les fichiers immédiatement après avoir placé le app_offline.htm , alors le serveur n'a tout simplement pas eu le temps d'arrêter l'application. Vous devriez attendre un peu avant d'essayer de remplacer les fichiers.

Ok, je comprends mais j'utilise l' option -e

Je vois toujours ce problème aussi. Mes fichiers de projet font référence à Microsoft.NET.Sdk.Web , mais il ne supprime pas automatiquement un fichier app_offline.htm , comme indiqué dans la documentation.

Salut les gars. Ce problème ennuyeux est toujours présent avec Core 2.1 avec le dernier VS 2017. J'utilise appoffline, toujours la DLL du projet principal est toujours utilisée et nécessite un arrêt complet du site Web lors de la publication. Cela rend le déploiement Web presque inutile.

Si vous ne pouvez pas mettre votre hôte hors ligne derrière l'équilibreur de charge et que vous souhaitez le faire plus rapidement, voici un moyen avec des liens symboliques et des PowerShell.
Je pensais faire quelque chose comme ça.

C'est plus rapide, car vous n'avez pas à arrêter le pool d'applications pendant la copie + recyclage, c'est mieux qu'un arrêt brutal car cela permet aux demandes actuelles de se terminer, donc moins de temps d'arrêt.

# Setup
Import-Module WebAdministration
# create 2 site root directories
$a = 'C:\inetpub\AspNetCoreSampleA'
$b = 'C:\inetpub\AspNetCoreSampleB'
$siteRoot = 'C:\inetpub\aspnetcoresample'
$siteName = 'AspNetCoreSample'
$poolName = "aspnetcore"
New-Item -Type Directory $a
New-Item -Type Directory $b
# create a symlink to targeting one side
New-Item -Type SymbolicLink -Path $siteRoot -Target $a
# point the site root to the symlink
Set-ItemProperty "IIS:\Sites\$siteName" -name physicalPath -value $siteRoot
# make sure it get's picked up
Restart-WebAppPool -Name $poolName

# this tells you the active side
Get-Item -Path $siteRoot | Select-Object -ExpandProperty target

# Flip the symlink
$current = (Get-Item -Path $siteRoot).Target
$newTarget = if ($current -eq $a) {$b} else {$a}
New-Item -Type SymbolicLink -Path $siteRoot -Target $newTarget -Force
# at this point w3wp.exe still locks the current target folder until it's getting recycled
# Deploy new version to the symlink which is now pointing to the other side which should have no locks
robocopy \\myshare\myapp $siteRoot /mir
# recycle app pool, so it picks up the new files
Restart-WebAppPool -Name $poolName

# bonus point: rollback is easy
$current = (Get-Item -Path $siteRoot).Target
$newTarget = if ($current -eq $a) {$b} else {$a}
New-Item -Type SymbolicLink -Path $siteRoot -Target $newTarget -Force
Restart-WebAppPool -Name $poolName

Voici l'essentiel
https://gist.github.com/csharmath/b2af0f50700ce9fbdd8c5c3e582fd41b

Restart-WebAppPool est essentiellement un recyclage, ce qui est utile si le recyclage avec chevauchement est activé (par défaut) car il engendrera un nouveau w3wp.exe et toutes les nouvelles demandes seront servies par ce nouveau processus pendant que celles en cours d'exécution seront terminées par l'ancien w3wp.exe.
De cette façon, ils se chevauchent jusqu'à ce que l'ancien soit terminé avec les demandes, vous vous retrouvez avec un seul w3wp.exe pointant vers la nouvelle version et il n'y a pas de problème de verrouillage.

C'est un peu similaire à la copie d'ombre, mais pas à 100% car cela fournit un scénario de xcopy beaucoup plus agréable et transparent.

Jusqu'à présent, cela semble être la meilleure approche à laquelle je puisse penser si vous deviez rester en ligne pendant une sortie.

@csharmath ou il y a aussi docker je suppose. Aucun verrouillage de fichier de cette façon, et il peut faire des mises à jour progressives via swarm / k8s / okd

Bien sûr, c'est encore mieux, bien sûr. soupir, tous les endroits ne l'ont pas encore.
Pour le reste des configurations oldschool, vous devez le raser jusqu'à ce qu'il fonctionne pour vous avec un temps d'arrêt nul ou minimal.

@csharmath D'accord, mais à ce stade, étant donné qu'il s'agit d'un problème non résolu depuis _ans_, autant s'adapter et rechercher des solutions qui fonctionnent au lieu d'attendre un miracle ...

J'ai utilisé ci-dessous le script power shell et il a planté l'IIS et a même affecté l'autre pool d'applications et je dois redémarrer la machine pour tout récupérer ... ce processus je l'ai obtenu à partir du document officiel et c'était un désastre, donc mon conseil est de NE PAS UTILISER LE app_offline.htm mieux utiliser le script qui arrête le pool d'applications et le redémarrer, celui que j'ai trouvé dans ce fil https://github.com/IsraelHikingMap/Site/blob/master/Scripts/Deploy .ps1

$pathToApp = 'G:\prod_web_core'
$pathToAppOfflineHtml = 'G:\prod_web_core\app_offline.htm'
# Stop the AppPool 
New-Item -Path $pathToApp -Name app_offline.htm
# Provide script commands here to deploy the app
Copy-Item "G:\prod_web_core_temp\*" -Destination $pathToApp -Recurse -Force
# Restart the AppPool 
Remove-Item -Path $pathToAppOfflineHtml
Get-ChildItem -Path "G:\prod_web_core_temp" -Recurse | Remove-Item -Force

Je suis obligé d'arrêter AppPool pour réussir le déploiement, des progrès pour résoudre ce problème?!

Nous venons de rencontrer ce problème de verrouillage de fichier pour la première fois aujourd'hui, car dotnet core est nouveau pour nous. J'ai été vraiment pris au dépourvu par cela. C'est drôle que la première raison pour laquelle je suis passé d'ASP classique à .Net Framework alors qu'il était encore en version bêta (~ 2001) soit parce que je pouvais faire des déploiements à chaud sans verrouillage de fichiers. C'était génial! Presque 18 ans plus tard et maintenant je suis de retour là où j'ai commencé. Oh bien, vous gagnez certains, vous perdez un peu.

Je viens de faire référence à mon problème ... dans mon cas, le déploiement de solutions Blazor Server Side ...
Il y a quelques jours, c'était un cauchemar ... J'ai appliqué l'app_offline.htm, fermé les pools d'applications et même redémarré des instances IIS entières pour déverrouiller des fichiers. La prochaine étape aurait été de redémarrer tout le serveur, heureusement après 5 minutes, les .dll se sont déverrouillés.

2019, même problème pour moi ... et ce problème a été créé en 2016 ... toujours pas de solution?

2020, même problème pour moi. La plus grande régression jamais réalisée. .Net 4.6 vous remplacez les fichiers dll et l'application se recharge sur la nouvelle version. Le noyau .Net verrouille tout.

@bladefist Votre meilleur pari à ce jour est d'utiliser des conteneurs Docker: /

@kanadaj merci, mais Dockers est un autre niveau de maux de tête à gérer. J'ai finalement trouvé un travail autour duquel utiliser App_offline.htm, puis attendre une minute et espérer que les fichiers sont libres. 99% du temps qu'ils le sont, il vous suffit d'attendre, je suppose que mon application met un certain temps à s'éteindre.

Fini le temps de .net 4.6 où vous venez de copier vos dll et votre application est automatiquement recyclée. Je suppose que c'était trop simple. Ce qui est doublement frustrant, c'est que ce n'est pas un problème sous Linux. Vous pouvez remplacer les fichiers utilisés sous linux.

Eh bien oui je suppose, mais cette méthode n'est pas très simple dans un environnement de production. Sans HA, votre application finira par ne pas répondre pendant une minute, et avec HA, vous recevrez des demandes erronées aléatoires jusqu'à ce que l'équilibreur de charge comprenne que l'application est en panne ... À moins que vous ne cycliez manuellement les hôtes de votre équilibreur de charge. Mais cela semble encore plus difficile à mettre en place.

@kanadaj oui , nous utilisons un équilibreur de charge et il met à jour linéairement les serveurs. Pas de temps d'arrêt.

Nous avons eu du succès avec

• Utilisation d'un lien symbolique pour le répertoire de l'application
• Déployer une nouvelle version du site dans un autre répertoire
• Mettre à jour le lien symbolique
• Redémarrez le pool d'applications à l'aide de l'utilitaire appcmd fourni avec IIS.

@davidglassborow c'est une solution créative. Merci. Cependant, des solutions créatives ne devraient pas être nécessaires.

D'après mon expérience, l'ancien mécanisme n'était de toute façon pas fiable lorsque le site était sous charge, nous avons fini par mettre de toute façon des proxys inverses pour les sites à fort trafic.

Bon, les déploiements sur place n'étaient jamais fiables ou atomiques, si vous aviez de la chance ou que vous n'aviez pas beaucoup de trafic, ce serait bien. Je suppose que la majorité des plaintes concernent ces scénarios. Nous examinerons l'amélioration des choses dans le délai .NET 5.0. Quelques mises en garde:

• Nous chercherons à améliorer les choses pour les applications dépendant du framework. Si vous déployez autonome, vous n'avez pas de chance. Il verrouille les fichiers natifs et gérés dans le dossier de sortie. Le problème de verrouillage des DLL natives a toujours existé et ne sera pas résolu par les mesures d'atténuation que nous mettons en place.
• Nous prévoyons d'examiner le chargement des assemblys d'applications en mémoire sous forme d'octets au lieu de les charger à partir du disque et de verrouiller le fichier. Cela devrait convenir dans la plupart des cas, mais peut entraîner une utilisation plus importante de la mémoire dans certains cas.
• Afin de recycler l'application, vous devez toujours ajouter et supprimer un fichier appoffline. L'ajout du fichier appoffline est un moyen de signaler que vous souhaitez que l'application redémarre à la suite du déploiement.

@davidfowl Le plan que vous avez décrit pour la version 5.0 sonne bien. Nous utilisons le framework dépendant comme je suis sûr que la plupart le font.

Respectueusement en désaccord sur la fiabilité des déploiements en place. Je le fais depuis des années sur des sites avec une charge extrêmement élevée, je n'ai jamais eu de problème, pas une seule fois. Le premier changement détecté provoque la réinitialisation de l'application, l'équilibreur de charge voit que l'instance ne répond pas, la met hors ligne, une fois que toutes les DLL sont remplacées, l'équilibreur de charge effectue une vérification de l'état et il revient en ligne. Maintenant, s'il n'y avait pas de vérification de l'état de l'équilibreur de charge, alors oui, c'est un pari, mais je veux dire qui remplace les DLL en production sous une charge élevée sans proxy quelconque? Concentrons-nous sur la règle et non sur l'exception. Sans proxy, je ne vois aucun moyen de mettre à jour l'application sans provoquer de panne. Même si vous preniez en charge le rechargement à chaud, certaines demandes se bloqueraient ou échoueraient probablement.

Respectueusement en désaccord sur la fiabilité des déploiements en place. Je le fais depuis des années sur des sites avec une charge extrêmement élevée, je n'ai jamais eu de problème, pas une seule fois. Le premier changement détecté provoque la réinitialisation de l'application, l'équilibreur de charge voit que l'instance ne répond pas, la met hors ligne, une fois que toutes les DLL sont remplacées, l'équilibreur de charge effectue une vérification de l'état et il revient en ligne. Maintenant, s'il n'y avait pas de vérification de l'état de l'équilibreur de charge, alors oui, c'est un pari, mais je veux dire qui remplace les DLL en production sous une charge élevée sans proxy quelconque? Concentrons-nous sur la règle et non sur l'exception. Sans proxy, je ne vois aucun moyen de mettre à jour l'application sans provoquer de panne. Même si vous preniez en charge le rechargement à chaud, certaines demandes se bloqueraient ou échoueraient probablement.

Vous disposez d'un équilibreur de charge. Beaucoup de gens n'ont pas d'équilibreur de charge et ne font que remplacer les fichiers sur le disque en place et s'attendent à la magie 😄

@davidfowl Droit mais trafic élevé + pas de lb = imprudent

De plus, le problème avec app_offline.htm est qu'à partir d'un processus ci / cd, vous ne savez pas quand le processus s'arrête. Nous avons dû ajouter une énorme commande de mise en veille entre la création de ce fichier et l'envoi des DLL, car notre processus d'arrêt peut durer de 1 à 1 minute. Lorsque vous équilibrez la charge de tonnes d'instances, ces mises en veille s'additionnent à un cycle de déploiement très long.

Le chargement des fichiers en mémoire résout tout cela.

@davidfowl Droit mais trafic élevé + pas de lb = imprudent

👍

De plus, le problème avec app_offline.htm est qu'à partir d'un processus ci / cd, vous ne savez pas quand le processus s'arrête. Nous avons dû ajouter une énorme commande de mise en veille entre la création de ce fichier et l'envoi des DLL, car notre processus d'arrêt peut durer de 1 à 1 minute. Lorsque vous équilibrez la charge de tonnes d'instances, ces mises en veille s'additionnent à un cycle de déploiement très long.

Bon, le problème est que la suppression de ce fichier ne vous dit pas quand il est correct de démarrer le déploiement car les fichiers sont toujours verrouillés jusqu'à ce que la notification soit reçue par ANCM.

De plus, le problème avec app_offline.htm est qu'à partir d'un processus ci / cd, vous ne savez pas quand le processus s'arrête.

À droite, l'éditeur VS utilise des mises en veille courtes et plusieurs tentatives.

• Afin de recycler l'application, vous devez toujours ajouter et supprimer un fichier appoffline. L'ajout du fichier appoffline est un moyen de signaler que vous souhaitez que l'application redémarre à la suite du déploiement.

Serait-il possible d'avoir un fichier "apprestart" pour marquer l'application à recycler sans avoir à supprimer le fichier appoffline par la suite?

@Socolin pourquoi est-ce?

@Socolin pourquoi est-ce?

Si je comprends bien (dites-moi si je me trompe), ce que vous prévoyez est de supprimer le verrou, mais nous devrons toujours créer appoffline pour signaler à IIS de recycler l'application une fois la compilation terminée?

Pour ce faire, nous devrons créer le fichier appoffline, puis le supprimer. Ce fichier peut-il être supprimé immédiatement après sa création? ou devrions-nous attendre qu'IIS le détecte? S'il faut attendre un peu, je préférerais avoir un fichier comme "apprestart" qu'IIS écoutera, puis supprimera une fois qu'il le détectera et commencera à recycler.

Aussi, j'ai une autre question en tête. Il s'agit de l'optimisation IDE lors de la construction.

Actuellement, je travaille sur un projet qui utilise des dépendances, nous avons un projet pour la couche Web et un autre projet pour la logique et les données. Lorsque je travaille dans la couche Web (ASP.NET Core) pendant la génération, je crée un fichier appoffline avant la génération, puis je le supprime après la génération et cela fonctionne.

Mais quand je travaille dans l'une des dépendances, quand je les construis à partir de Rider (je pense que ça fait la même chose sur VS car il utilise msbuild) quand je regarde ce que fait msbuild, une fois la construction du projet terminée, le dll est copié directement dans le répertoire .Web / bin sans reconstruire le projet .Web. Et comme la DLL est verrouillée, elle échoue silencieusement et je dois redémarrer manuellement le serveur ou déclencher manuellement la construction du projet .Web.

Avez-vous une solution pour cela?
Jusqu'à présent, la solution de contournement que j'ai trouvée est d'écrire un petit programme exécuté en arrière-plan qui recherche le / bin de mon projet .Web. Lorsqu'un fichier change, il crée un fichier appoffline dans le répertoire où IIS écoute, puis copie les fichiers modifiés, puis supprime le fichier appoffline. Mais cela semble un peu piraté, mais jusqu'à présent, c'est le seul moyen que j'ai trouvé pour pouvoir construire, puis appuyez sur F5 et testez mes modifications.

Pour ce faire, nous devrons créer le fichier appoffline, puis le supprimer. Ce fichier peut-il être supprimé immédiatement après sa création? ou devrions-nous attendre qu'IIS le détecte? S'il faut attendre un peu, je préférerais avoir un fichier comme "apprestart" qu'IIS écoutera, puis supprimera une fois qu'il le détectera et commencera à recycler.

Comment IIS saurait-il que vous avez terminé de copier des fichiers? Comment éviter l'état déchiré? Vous devez essentiellement signaler le début et la fin d'une transaction. La création du fichier signale le début et la suppression signale la fin.

Avez-vous une solution pour cela?
Jusqu'à présent, la solution de contournement que j'ai trouvée est d'écrire un petit programme exécuté en arrière-plan qui recherche le / bin de mon projet .Web. Lorsqu'un fichier change, il crée un fichier appoffline dans le répertoire où IIS écoute, puis copie les fichiers modifiés, puis supprime le fichier appoffline. Mais cela semble un peu piraté, mais jusqu'à présent, c'est le seul moyen que j'ai trouvé pour pouvoir construire, puis appuyez sur F5 et testez mes modifications.

VS gère cela en tuant le processus avant de démarrer un nouveau fichier pour tout ce qui pourrait avoir un impact sur la construction de ce projet.

Pour ce faire, nous devrons créer le fichier appoffline, puis le supprimer. Ce fichier peut-il être supprimé immédiatement après sa création? ou devrions-nous attendre qu'IIS le détecte? S'il faut attendre un peu, je préférerais avoir un fichier comme "apprestart" qu'IIS écoutera, puis supprimera une fois qu'il le détectera et commencera à recycler.

Comment IIS saurait-il que vous avez terminé de copier des fichiers? Comment éviter l'état déchiré? Vous devez essentiellement signaler le début et la fin d'une transaction. La création du fichier signale le début et la suppression signale la fin.

S'il n'y a pas de verrou, pourquoi notifier IIS lorsque la construction démarre? Ne pouvons-nous pas simplement signaler que tous les fichiers sont mis à jour et que l'application doit être recyclée? Je pense que j'ai mal compris quelque chose.

S'il n'y a pas de verrou, pourquoi notifier IIS lorsque la construction démarre? Ne pouvons-nous pas simplement signaler que tous les fichiers sont mis à jour et que l'application doit être recyclée? Je pense que j'ai mal compris quelque chose.

Oui, cela fonctionnerait. Je pensais que vous décriviez l'état actuel de la technique. Il pourrait même être possible de le faire aujourd'hui avec web.config. Si vous touchez le fichier, l'application redémarrera.

J'ai eu du succès avec le déploiement sur place (https://flukefan.github.io/ZipDeploy/), en:

1. Renommer les fichiers d'assemblage (apparemment, vous pouvez renommer même si vous ne pouvez pas supprimer / écraser);
2. Copiez dans les nouveaux assemblages;
3. Appuyez sur la configuration Web pour redémarrer l'application;
4. Supprimez les anciens assemblys renommés.

Pas d'équilibrage de charge; instance IIS unique; aucun changement IIS. YMMV.

@FlukeFan Comment éviter les déploiements déchirés ou n'est-ce pas un problème pour vous? Par déchiré, je veux dire qu'il existe une fenêtre dans laquelle l'ancienne application charge un nouvel assemblage avant de redémarrer l'application.

Je ne touche pas le web.config tant que tous les assemblys ne sont pas renommés / mis à jour. Je suppose qu'il y a une petite chance que quelque chose d'autre puisse provoquer le recyclage d'un pool d'applications pendant ce temps, mais ce n'est pas encore arrivé.

Je désactive généralement toutes les autres options de recyclage automatique et je désactive également le recyclage superposé dans les paramètres du pool d'applications IIS.

@FlukeFan n'est pas un recyclage mais si vous n'avez pas encore chargé l'assembly qui a été remplacé. Par exemple, disons que vous avez un assembly A.dll et B.dll. Disons que B est utilisé lorsque vous accédez à la page des paramètres, il est donc chargé. Si vous êtes allé à la page des paramètres lorsque B.dll a été remplacé par le nouveau, vous pourriez vous retrouver avec l'ancienne application en cours d'exécution avec un nouveau B.dll.

Je me demande si nous devrions créer un outil global dotnet pour aider à ce type de déploiement. L'outil pourrait essentiellement faire toutes les choses difficiles que les gens ont mentionnées sur ce fil.

Pensées?

@FlukeFan n'est pas un recyclage mais si vous n'avez pas encore chargé l'assembly qui a été remplacé. Par exemple, disons que vous avez un assembly A.dll et B.dll. Disons que B est utilisé lorsque vous accédez à la page des paramètres, il est donc chargé. Si vous êtes allé à la page des paramètres lorsque B.dll a été remplacé par le nouveau, vous pourriez vous retrouver avec l'ancienne application en cours d'exécution avec un nouveau B.dll.

Donc je ne gère pas cette affaire pour le moment. https://github.com/FlukeFan/ZipDeploy/blob/master/ZipDeploy/ZipDeploy.cs#L55

Je suppose que je pourrais faire les choses dans un ordre différent, toucher d'abord web.config, attendre la fin de toutes les `` autres '' requêtes, puis enfin faire le remplacement juste avant la fin de la dernière requête (pendant qu'IIS met en file d'attente les nouvelles requêtes pour le about-to- recycle app-pool), mais ce que j'ai fonctionne pour moi tout à l'heure.

Ce n'est probablement pas actuellement assez robuste pour le scénario que vous décrivez (mais je n'ai rien fait d'extraordinaire avec le chargement d'assemblage dynamique autre qu'au démarrage).

Est-il prévu de revoir cette fonctionnalité et de la mettre sur la feuille de route? Il est très peu pratique / peu convivial d'exiger de tout le monde qui déploie un site Web .Net Core de mettre en œuvre manuellement une stratégie de créneau intermédiaire s'il souhaite prendre en charge les déploiements sans temps d'arrêt.

Cette fonctionnalité rendrait la transition vers les sites Web .Net Core beaucoup plus fluide pour de nombreuses personnes et permettrait une adoption plus rapide des sites Web .Net Core.

Je n'ai jamais pensé à ça. Mais vous pouvez très bien avoir frappé le clou sur la tête. Cela pourrait être une décision commerciale néfaste de forcer les gens à utiliser des machines à sous azur. Si cela était possible dans le passé, pourquoi a-t-il fallu si longtemps pour «réparer» maintenant? Ce n'est pas rompu d'un point de vue commercial ce que cela à l'esprit. Peut-être que je suis un peu cynique. Mais j'ai lentement regardé les fonctionnalités azur qui étaient auparavant gratuites et sont passées à des niveaux plus chers.

Je me demande si nous devrions créer un outil global dotnet pour aider à ce type de déploiement. L'outil pourrait essentiellement faire toutes les choses difficiles que les gens ont mentionnées sur ce fil.

Pensées?

C'est pour fonctionner sur le serveur CI, disons? Comment pousserait-il les binaires / package vers le serveur de destination?

Je n'ai jamais pensé à ça. Mais vous pouvez très bien avoir frappé le clou sur la tête. Cela pourrait être une décision commerciale néfaste de forcer les gens à utiliser des machines à sous azur. Si cela était possible dans le passé, pourquoi a-t-il fallu si longtemps pour «réparer» maintenant? Ce n'est pas rompu d'un point de vue commercial ce que cela à l'esprit. Peut-être que je suis un peu cynique. Mais j'ai lentement regardé les fonctionnalités azur qui étaient auparavant gratuites et sont passées à des niveaux plus chers.

Les déploiements en place sans coordination sont fondamentalement peu fiables pour les raisons mentionnées ci-dessus. Nous n'allons plus jamais implémenter le cliché instantané, car cette fonctionnalité n'a pas toujours été fiable et a causé de nombreux problèmes dans ASP.NET sur .NET Framework. Il ne fonctionne également que pour un type de déploiement spécifique, dépendant du framework, qui est entièrement pris en charge par .NET Framework. .NET core prend en charge un fichier autonome et unique, ce qui le rend beaucoup plus difficile à prendre en charge. Même la suggestion ci-dessus ne couvre pas ces cas.

Nous pensons toujours que les déploiements sur place devraient être aussi atomiques que possible et que de nombreux problèmes sur ce problème proviennent de bogues et du manque de fiabilité de la détection et du recyclage app_offline, nous avons donc passé beaucoup de temps à résoudre ce problème (et le verrouillage pdb également).

Le déploiement Web est le seul outil aujourd'hui qui incarne le flux avec lequel nous pensons qu'il est logique de déployer, mais il est piégé dans cette technologie, donc cela n'aide pas si vous déployez ftp sur vos serveurs ou copiez sur un partage de fichiers (même si pourrait).

Un outil global dotnet pourrait être une réponse ici.

C'est pour fonctionner sur le serveur CI, disons? Comment pousserait-il les binaires / package vers le serveur de destination?

Je ne pense pas. Il prendrait probablement en charge FTP et une copie directe. Tout autre chose que cela est probablement un protocole propriétaire.

J'espère que quand vous dites FTP, vous voulez dire aussi ftp sur ssh. Un tel outil serait très précieux.

J'espère que quand vous dites FTP, vous voulez dire aussi ftp sur ssh. Un tel outil serait très précieux.

Non, je voulais dire ftp. Mais nous ferions tout ce qui aurait du sens. Il est peut-être préférable d'être un outil de copie que vous devez exécuter sur la machine cible. Cela nous évite de devoir envoyer des bits n'importe où.

Êtes-vous également en SSH sur vos machines Windows pour le déployer sur IIS?

@davidfowl Veuillez ajouter (opt-in) la prise en charge des emplacements de déploiement.
https://github.com/dotnet/aspnetcore/issues/3719#issuecomment -473183712
https://github.com/dotnet/aspnetcore/issues/3793#issuecomment -335666414

Nous prévoyons d'examiner le chargement des assemblys d'applications en mémoire sous forme d'octets au lieu de les charger à partir du disque et de verrouiller le fichier. Cela devrait convenir dans la plupart des cas, mais peut entraîner une utilisation plus importante de la mémoire dans certains cas .

De plus, cela ne nous permettra pas d'atteindre aucun temps d'arrêt.

Il n'y a aucun moyen d'investir dans une telle fonctionnalité avec le module.

J'espère que quand vous dites FTP, vous voulez dire aussi ftp sur ssh. Un tel outil serait très précieux.

Non, je voulais dire ftp. Mais nous ferions tout ce qui aurait du sens. Il est peut-être préférable d'être un outil de copie que vous devez exécuter sur la machine cible. Cela nous évite de devoir envoyer des bits n'importe où.

Êtes-vous également en SSH sur vos machines Windows pour le déployer sur IIS?

Oui. Nous utilisons CI / CD et déployons à la fois sur les systèmes Linux et Windows, il était donc beaucoup plus facile d'installer openssh sur les fenêtres.

$ appPool = 'par défaut'
Stop-WebAppPool -Nom $ appPool -Passthru
... déployer...

Start-WebAppPool -Nom $ appPool -Passthru
...déployer.....

ou

$ appPool = 'par défaut'
Stop-WebAppPool -Name $ appPool
while ((Get-WebAppPoolState -Name $ appPool) .Value -ne 'Stop') {
dormir 1 # seconde
}
... déployer...

Start-WebAppPool -Name $ appPool
while ((Get-WebAppPoolState -Name $ appPool) .Value -ne 'Start') {
dormir 1 # seconde
}

...déployer.....

Emplacements de déploiement des pauvres hommes
Il y a environ un an, j'ai publié un article sur la création de 2 dossiers racine de site et j'ai un point de lien symbolique vers l'un d'eux configuré pour le site IIS.
L'avantage est que votre temps d'arrêt est moins comparé aux autres solutions plus simples.
Si le recyclage avec chevauchement est activé, aucun temps d'arrêt, seulement une pénalité de préchauffage pour la première demande, ce qui est le cas de toute façon.

Si l'opération de déploiement / copie prend N secondes pour se terminer, vous n'avez pas besoin d'arrêter le pool d'applications pendant N secondes.
Pas de problème avec l'application douteuse hors ligne.
Copiez simplement dans le dossier inactif, échangez le lien symbolique lorsque les fichiers sont là, puis recyclez le pool d'applications.
Déploiement atomique, pas de temps d'arrêt juste une première requête plus lente que d'habitude.

https://github.com/dotnet/aspnetcore/issues/3793#issuecomment -459870870

Quelqu'un a-t-il essayé ça?
Si quelque chose comme cela fonctionne, cela pourrait être transformé en service avec un outil de déploiement côté client.

• client -> serveur quel est le dossier / partage inactif?
• S: ici
• C: ok déployé / copié
• S: lien symbolique échangé et recyclé
• C: thx, http get / healthcheck (facultatif)
• C: ugh j'ai foiré, pls de retour en arrière
• S: échange de lien symbolique, recyclage (retour aux affaires)
• C: rincer répéter jusqu'à ce que fonctionne

J'ai donc également des problèmes avec les fichiers verrouillés de déploiement. dans l'hébergement d'applications. J'ai essayé d'arrêter le pool d'applications, mais les fichiers restent verrouillés. J'ai essayé de pousser le app_offline.htm mais pas de chance non plus.
De plus, si vous souhaitez gérer la suppression du fichier app_offline.htm, vous pouvez facilement le faire en démarrant l'application dans program.cs. De cette façon, nous savons quand il démarre, il devient en ligne.

Le problème actuel auquel je suis confronté est que les dll sont bloquées et même si vous renommez puis copiez les fichiers, l'ancien processus est toujours en cours d'exécution sur les fichiers renommés. Ainsi, lorsque nous tenterons de déployer à nouveau, nous devrons renommer à nouveau les fichiers. Je suppose que nous pourrions utiliser une date quelconque comme remplacement du nom de fichier.
Nous utilisons dotnet core 3.1.4 pour cela sur le serveur IIS Windows 2012 R2

@foxjazz Comment les fichiers sont-ils toujours verrouillés si le pool / processus d'applications est arrêté? Peux-tu élaborer?

@foxjazz Comment les fichiers sont-ils toujours verrouillés si le pool / processus d'applications est arrêté? Peux-tu élaborer?

Lorsque vous essayez de supprimer les DLL utilisées, l'image indique qu'elles sont utilisées par un autre processus.
Le pool d'applications est hors ligne depuis un certain temps.

Vérifiez le gestionnaire de tâches pour voir si le processus est toujours en cours d'exécution. Appuyer sur le bouton d'arrêt ne signifie pas qu'il se termine immédiatement.

Vérifiez le gestionnaire de tâches pour voir si le processus est toujours en cours d'exécution. Appuyer sur le bouton d'arrêt ne signifie pas qu'il se termine immédiatement.

l'image ci-dessus provient du gestionnaire de tâches. Je ne sais pas de quoi il s'agit, mais si je les supprime, le fichier sera libéré. Je suppose que je peux utiliser handle pour déterminer le pid à terminer. Je ne pensais pas que je devrais aller à ces longueurs pour le déploiement. Handle indique que les processus w3wp.exe 2 ont l'un des fichiers verrouillés. même si le pool d'applications correspondant est arrêté.

Ce qui serait vraiment bien, c'est d'avoir une route pour arrêter le processus.
api \ KillDeathKill
{
Program.KillProcess ()
}

C'est peu probable. Le fichier est verrouillé par un processus. Si w3wp est ce processus, il n'a jamais été tué au départ ou un nouveau a été lancé avec un pid différent verrouillant le même fichier. C'est pourquoi vous devez d'abord vous assurer que l'application hors ligne est arrêtée pour vous assurer qu'il n'y a pas de nouveau processus pour verrouiller le fichier, tuer le processus existant, déployer de nouveaux bits, supprimer l'application hors ligne

C'est peu probable. Le fichier est verrouillé par un processus. Si w3wp est ce processus, il n'a jamais été tué au départ ou un nouveau a été lancé avec un pid différent verrouillant le même fichier. C'est pourquoi vous devez d'abord vous assurer que l'application hors ligne est arrêtée pour vous assurer qu'il n'y a pas de nouveau processus pour verrouiller le fichier, tuer le processus existant, déployer de nouveaux bits, supprimer l'application hors ligne

lorsque vous dites que app_offline.htm est en premier. Oui, c'était le cas. J'ai un chemin de statut que je peux vérifier via une demande d'obtention, et il est définitivement hors ligne. Également arrêté le pool d'applications manuellement. Mais le processus w3wp bloquait toujours le fichier.

Ensuite, le processus n'a pas été arrêté

Ensuite, le processus n'a pas été arrêté

Alors, pourquoi est-ce que l'arrêt du pool d'applications, et non le processus?

Le pool d'applications représente le processus et si vous arrêtez le pool d'applications, le processus sera interrompu. Le fichier ne peut pas être verrouillé s'il n'y a pas de processus pour le verrouiller, donc l'une de ces autres théories semble plus probable.

Le pool d'applications représente le processus et si vous arrêtez le pool d'applications, le processus sera interrompu. Le fichier ne peut pas être verrouillé s'il n'y a pas de processus pour le verrouiller, donc l'une de ces autres théories semble plus probable.

hah vous avez dit merde. Je ne veux pas avoir l'air de vous punir. Je dis que l'arrêt du pool d'applications ne fonctionne PAS comme annoncé dans toute la documentation. Le processus n'est pas interrompu, même après 90 secondes, il est toujours en cours d'exécution. Le fichier est verrouillé même lorsque vous pouvez voir clairement que le pool d'applications a été arrêté. Le processus contient un singleton pour obtenir des données. Et d'autres contrôleurs. Ce serait bien d'avoir un script qui arrêterait le processus en fonction du fichier verrouillé. Je pourrais alors me déployer sans crainte. Le changement de nom peut également fonctionner. Les fichiers peuvent être renommés. (dotnet core 3.1.4) saveur

Il y a environ un an, j'ai publié un article sur la création de 2 dossiers racine de site et j'ai un point de lien symbolique vers l'un d'eux configuré pour le site IIS.

Quelqu'un a-t-il essayé ça?
Si quelque chose comme cela fonctionne, cela pourrait être transformé en service avec un outil de déploiement côté client.

@CJHarmath - J'ai fait un essai et j'ai le code modifié que j'utilise ci-dessous. Fonctionne très bien, merci!

Si je publiais davantage de mises à jour, je pourrais envisager un outil de déploiement client, mais en réalité, je peux simplement envoyer un shell distant dans le serveur IIS et exécuter le script PowerShell pour le retourner.
psexec.exe \\IIS_SERVER cmd /c "powershell -noninteractive -file C:\FlipSymLink.ps1"

# FlipSymLink.ps1

Import-Module WebAdministration # run as admin
# create 2 site root directories
$a = 'C:\Websites\MySiteA'
$b = 'C:\Websites\MySiteB'
$appRoot  = 'C:\Websites\MySite'
$appName  = 'MyAppName'
$siteName = 'MySiteName'
$poolName = "MyPoolName"
New-Item -Type Directory $a -ErrorAction SilentlyContinue
New-Item -Type Directory $b -ErrorAction SilentlyContinue

# create a symlink to targeting one side
New-Item -Type SymbolicLink -Path $appRoot -Target $a -Name A -ErrorAction SilentlyContinue
New-Item -Type SymbolicLink -Path $appRoot -Target $b -Name B -ErrorAction SilentlyContinue

# point the site root to the symlink
$currentPath = (Get-ItemProperty "IIS:\Sites\$siteName\$appName" -name physicalPath)
if ($currentPath -eq "$appRoot\A") {
    Write-Host "Switched to B"
    New-Item $b\active.txt
    Remove-Item $a\active.txt
    Set-ItemProperty "IIS:\Sites\$siteName\$appName" -name physicalPath -value $appRoot\B
} else {
    Write-Host "Switched to A"
    New-Item $a\active.txt
    Remove-Item $b\active.txt
    Set-ItemProperty "IIS:\Sites\$siteName\$appName" -name physicalPath -value $appRoot\A
}
Restart-WebAppPool -Name $poolName

psexec.exe \\IIS_SERVER cmd /c "powershell -noninteractive -file C:\FlipSymLink.ps1"

Cela pourrait également être transformé en un point de terminaison JEA , vous pouvez donc exécuter flip tant qu'utilisateur non élevé (par exemple à partir d'une étape de déploiement du serveur CI / CD)
Invoke-Command -ComputerName IIS_SERVER -ConfigurationName IIS-Flip -ScriptBlock { Switch-SymlinkTarget -SiteName MySite}
Utilisé Switch au lieu de Flip car c'est un verbe approuvé.

Utilisé Switch au lieu de Flip car c'est un verbe approuvé.

Swap est le verbe utilisé lorsqu'il s'agit de slots - serait-il logique de le réutiliser ici semble-t-il?

ayant le même problème que décrit il y a 4 ans.
Une mise à jour pour ceci?
Je ne veux pas ouvrir le bureau à distance pour simplement télécharger un nouveau fichier dll.

Lorsque j'essaie de remplacer le fichier DLL d'application .NET Core à l'aide de FTP sur le serveur de production IIS, le fichier est verrouillé et ne peut pas être écrasé.

Pour déployer une nouvelle version, je dois arrêter l'application dans IIS (ouverture de RDP) pour déverrouiller, puis écraser.
Il n'est pas possible de déployer sans arrêter l'application.

Une solution pour ça? Merci

Si vous ne pouvez pas mettre votre hôte hors ligne derrière l'équilibreur de charge et que vous souhaitez le faire plus rapidement, voici un moyen avec des liens symboliques et des PowerShell.
Je pensais faire quelque chose comme ça.

C'est plus rapide, car vous n'avez pas à arrêter le pool d'applications pendant la copie + recyclage, c'est mieux qu'un arrêt brutal car cela permet aux demandes actuelles de se terminer, donc moins de temps d'arrêt.

# Setup
Import-Module WebAdministration
# create 2 site root directories
$a = 'C:\inetpub\AspNetCoreSampleA'
$b = 'C:\inetpub\AspNetCoreSampleB'
$siteRoot = 'C:\inetpub\aspnetcoresample'
$siteName = 'AspNetCoreSample'
$poolName = "aspnetcore"
New-Item -Type Directory $a
New-Item -Type Directory $b
# create a symlink to targeting one side
New-Item -Type SymbolicLink -Path $siteRoot -Target $a
# point the site root to the symlink
Set-ItemProperty "IIS:\Sites\$siteName" -name physicalPath -value $siteRoot
# make sure it get's picked up
Restart-WebAppPool -Name $poolName

# this tells you the active side
Get-Item -Path $siteRoot | Select-Object -ExpandProperty target

# Flip the symlink
$current = (Get-Item -Path $siteRoot).Target
$newTarget = if ($current -eq $a) {$b} else {$a}
New-Item -Type SymbolicLink -Path $siteRoot -Target $newTarget -Force
# at this point w3wp.exe still locks the current target folder until it's getting recycled
# Deploy new version to the symlink which is now pointing to the other side which should have no locks
robocopy \\myshare\myapp $siteRoot /mir
# recycle app pool, so it picks up the new files
Restart-WebAppPool -Name $poolName

# bonus point: rollback is easy
$current = (Get-Item -Path $siteRoot).Target
$newTarget = if ($current -eq $a) {$b} else {$a}
New-Item -Type SymbolicLink -Path $siteRoot -Target $newTarget -Force
Restart-WebAppPool -Name $poolName

Voici l'essentiel
https://gist.github.com/csharmath/b2af0f50700ce9fbdd8c5c3e582fd41b

Voici quelque chose dont je pense avoir réglé les problèmes. Je n'ai essayé qu'avec ASP.NET, mais j'imagine que cela fonctionnerait de la même manière avec le module d'hébergement pour net core. La première exécution arrête un peu le site, vous voudrez peut-être l'ajuster un peu.

param(
    [Parameter(Mandatory = $true)]
    [string] $iisRootPath,
    [Parameter(Mandatory = $true)]
    [string] $siteName,
    [Parameter(Mandatory = $true)]
    [string] $artifactPath,
    [Parameter(Mandatory = $false)]
    [string] $siteFolderName,
    [Parameter(Mandatory = $false)]
    [string] $appPoolName
)
Import-Module WebAdministration

#populate optional parameters
if (!($PSBoundParameters.ContainsKey('siteFolderName'))) { $siteFolderName = $siteName }
if (!($PSBoundParameters.ContainsKey('appPoolName'))) { $appPoolName = $siteName }

#set A, B and C paths
$a = "$iisRootPath\$siteFolderName" + 'A'
$b = "$iisRootPath\$siteFolderName" + 'B'
$c = "$iisRootPath\$siteFolderName"

#existence test
$cName = Get-Item -Path $c -ErrorAction SilentlyContinue | Select-Object -ExpandProperty name -ErrorAction SilentlyContinue
$bName = Get-Item -Path $b -ErrorAction SilentlyContinue | Select-Object -ExpandProperty name -ErrorAction SilentlyContinue

#get the shudown timeout for the app pool
$shutdownTimeout = Get-WebConfigurationProperty -Filter 'system.web/httpRuntime' -PSPath "IIS:\Sites\$siteName" -Name shutdownTimeout | Select-Object -ExpandProperty Value

#create symlink, if symlink source is an existing directory, rename existing 
if($cName -eq $null) 
{
    Write-Output "Creating SymbolicLink $c -> $a" 
    New-Item -Type SymbolicLink -Path $c -Target $a
} 
else
{
    #directories don't have a target property
    $cTarget = Get-Item -Path $c | Select-Object -ExpandProperty target -ErrorAction SilentlyContinue

    #this is a directory, rename and create symlink
    if($cTarget -eq $null)
    {
        #restart AppPool first so no locked files
        #Write-Output "Restarting AppPool $appPoolName" 
        #Restart-WebAppPool -Name $appPoolName

        #stop AppPool first so no locked files
        Write-Output "Stopping AppPool $appPoolName" 
        Stop-WebAppPool -Name $appPoolName

        #sleep for shutdownTimeout
        Write-Output "Sleeping for $shutdownTimeout" 
        Start-Sleep -Seconds (([System.TimeSpan]::Parse("$shutdownTimeout").TotalSeconds) * 1.1)

        try {
             #if the rename fails, there are files in use. stop the script
            $newName = $siteFolderName + 'A'
            Write-Output "Renaming $c to $newName" 
            Rename-Item -Path $c -NewName $newName -ErrorAction Stop
        }
        catch {
            Write-Error -Message "Failed to rename $c to $newName due to files in use."

            #start AppPool 
            Write-Output "Starting AppPool $appPoolName due to failed folder rename. Consider trying again durring a time with reduced traffic." 
            Start-WebAppPool -Name $appPoolName

        }

        #create symlink
        Write-Output "Creating SymbolicLink $c -> $a" 
        New-Item -Type SymbolicLink -Path $c -Target $a

        #start AppPool 
        Write-Output "Starting AppPool $appPoolName" 
        Start-WebAppPool -Name $appPoolName

        #copy a to b to pick up directory permissions
        if($bName -eq $null) 
        {
            Write-Output "Copying Directory $a to $b"  
            robocopy $a $b /e /sec /sl
        }
    }
}

#existence test
$aName = Get-Item -Path $a -ErrorAction SilentlyContinue | Select-Object -ExpandProperty name -ErrorAction SilentlyContinue
$bName = Get-Item -Path $b -ErrorAction SilentlyContinue | Select-Object -ExpandProperty name -ErrorAction SilentlyContinue

#create if needed
if($aName -eq $null) 
{
    Write-Output "Creating Directory $a"  
    New-Item -Type Directory $a 
}
if($bName -eq $null) 
{
    Write-Output "Creating Directory $b"  
    New-Item -Type Directory $b 
}

#make sure site pointing to symlink
Write-Output "Pointing Website $siteName to Path $c" 
Set-ItemProperty "IIS:\Sites\$siteName" -name physicalPath -value $c

#restart so we know it's loading from symlink
Write-Output "Restarting AppPool $appPoolName" 
Restart-WebAppPool -Name $appPoolName

#sleep for shutdownTimeout 
Write-Output "Sleeping for $shutdownTimeout" 
Start-Sleep -Seconds ([System.TimeSpan]::Parse("$shutdownTimeout").TotalSeconds)

#get current symlink target and set new target
Get-Item -Path $c | Select-Object -ExpandProperty target
$current = (Get-Item -Path $c).Target
$newTarget = if ($current -eq $a) {$b} else {$a}

$fileOrDirectoryName = Get-Item $artifactPath | Select-Object -ExpandProperty name

#test for .zip
if(($fileOrDirectoryName).ToLower().EndsWith(".zip") -eq $true)
{
    #copy to temp location
    $guid = [System.Guid]::NewGuid()
    $tempPath = "$iisRootPath\temp-$guid"
    $tempDest = "$iisRootPath\temp-dest-$guid"

    Write-Output "Creating temp directory $tempPath" 
    New-Item -Type Directory $tempPath

    $artifactDirectory = [System.IO.Path]::GetDirectoryName($artifactPath)
    $artifactFile = [System.IO.Path]::GetFileName($artifactPath);

    #TODO: first robocopy arg needs to be a directory, not a file
    Write-Output "Copying archive from $artifactPath to $tempPath" 
    robocopy $artifactDirectory $tempPath $artifactFile

    #extract to temp destination (seems a failed extract can leave empty folders)
    Write-Output "Extracting archive to $tempDest" 
    Expand-Archive -Path "$tempPath\$fileOrDirectoryName" -DestinationPath $tempDest -Force

    #copy from temp destination to destination
    Write-Output "Copying files from $tempDest to $newTarget" 
    robocopy $tempDest $newTarget /e

    #delete temp directory
    Write-Output "Removing temp directory $tempPath" 
    Remove-Item -Path $tempPath -Recurse -Force

    #delete temp directory
    Write-Output "Removing temp directory $tempDest" 
    Remove-Item -Path $tempDest -Recurse -Force
}
else 
{
    #copy new files
    Write-Output "Copying files from $artifactPath to $newTarget" 
    robocopy $artifactPath $newTarget /e
}

#swap symlink
Write-Output "Pointing SymbolicLink $c -> $newTarget" 
New-Item -Type SymbolicLink -Path $c -Target $newTarget -Force

#restart so it loads from newly swapped symlink
Write-Output "Restarting AppPool $appPoolName" 
Restart-WebAppPool -Name $appPoolName

@LucidObscurity qu'est-ce que c'est? un code cmd? où dois-je ajouter ce code?
Merci

Qu'en est-il de l'idée d'augmenter le nombre de tentatives (paramètre: -retryAttempts:X ) ou l'intervalle de temps de nouvelle tentative (paramètre: -retryInterval:XXXX ) pour la commande msdeploy , jusqu'à ce que le processus libère le verrou de fichier?

Je pense que @davidfowl a raison, le processus est toujours là et verrouille les fichiers. Même Reset IIS n'aide pas , il attend toujours le processus jusqu'à l'expiration du délai. Si vous supprimez app_offline.htm et attendez 90 secondes (paramètre de délai d'expiration par défaut pour arrêter AppPool), et réessayez, vous verrez que cela fonctionne.
Pour moi en local, je ne veux pas attendre aussi longtemps, j'ai donc mis à jour cette limite de temps d'arrêt (secondes) à 5 et mettre à jour le fichier de projet pour générer app_offline.htm avant la construction, supprimez-le après la construction. Ça marche bien.
Pour le serveur, j'utilise msdeploy pour supprimer app_offline.htm, synchroniser la nouvelle version, puis supprimer app_offline.htm. Avec msdeploy, il réessaye si les fichiers sont verrouillés mais parfois abandonnés avant 90 secondes, je dois donc déclencher à nouveau le déploiement, puis cela fonctionne à la deuxième tentative

Une mise à jour à ce sujet? Quand cette nouvelle version sera-t-elle prête?

Merci de nous avoir contacté.
Nous déplaçons ce numéro vers le jalon Next sprint planning pour une évaluation / considération future. Nous évaluerons la demande lors de la planification des travaux pour la prochaine étape. Pour en savoir plus sur ce à quoi vous attendre et comment ce problème sera traité, vous pouvez en savoir plus sur notre processus de triage ici .

J'ai découvert ce problème cette semaine, après avoir converti une application .NET 4.5.2 en .NET 5.0. J'ai une autre approche pour surmonter cela. J'ai créé un service Windows qui s'exécute sur le serveur IIS. Sur ce service, j'ai un simple serveur HTTP fonctionnant sur un port personnalisé. L'application Web peut effectuer une post-demande auprès de ce serveur pour lancer une mise à niveau. Il arrête le pool d'applications et s'assure de tuer tous les processus de cette application, de créer une sauvegarde de la version actuelle, de supprimer la version actuelle, de télécharger le package de mise à niveau et de l'extraire. Puis redémarre le pool d'applications.

J'ai créé une application Windows Forms simple, pour créer des packages de mise à niveau qui sont poussés vers un référentiel à partir duquel le service Windows mentionné ci-dessus extrait.