Aspnetcore: Le déploiement échoue en raison d'un fichier en cours d'utilisation

J'ai remarqué un problème similaire avec le verrouillage des fichiers IIS sur les machines virtuelles Azure qui empêchait le déploiement de WebDeploy. Ma solution consiste à émettre trois commandes WebDeploy : arrêter l'AppPool, déployer, redémarrer l'AppPool. Voir mon script ; et si vous avez la possibilité d'exécuter trois commandes WebDeploy, vous pourrez peut-être faire quelque chose de similaire avec Azure Apps.

Obtenir ce problème en beta6.

Pareil ici! Cela provoque le gel de mon Visual Studio 2015 - lors de la publication de mon application vNext (à la fois beta6 et beta7 je pense).

Utilisez-vous les scripts fournis par Microsoft pour effectuer le déploiement ? Si c'est le cas, vous pouvez simplement ajouter une ligne dans le PublishAspNet5Website.ps1 pour redémarrer l'application Web :

Restart-AzureWebsite -Name $websiteName

J'ai mes modifications de script de construction décrites dans ce post : Résoudre un problème de déploiement ASP.NET 5 sur Azure Web App Slot

@brandonmartinez , Redémarrer un site Web n'aidera pas, car un site Web de production continuera à recevoir des demandes, ce qui reverrouillera donc les fichiers. Le seul moyen fiable, actuellement, de mettre à jour les sites Web IIS et Azure consiste à fermer le pool d'applications du site Web, puis à mettre à jour les fichiers, puis à redémarrer le site Web. Suivez simplement le lien de @GuardRex pour plus de détails.

Cependant, nous ne devrions pas avoir à nous soucier des scripts de déploiement personnalisés lorsque nous travaillons dans des conditions par défaut avec VS2015.

J'espère que la nouvelle infrastructure HttpPlatformHandler (qui n'a plus besoin d'AspNet.Loader.dll) sera un peu plus indulgente, mais je ne retiens pas mon souffle ici. Nous aurons probablement un autre fichier .dll verrouillé.

@rubenprins C'est la solution de contournement que j'utilise également, via les outils Azure SDK dans VS.

Il existe des commandes PS pour le faire si vous pouvez obtenir un accès PS à la VM. https://github.com/GuardRex/net5-iis-ps-publish/blob/7623122dbfdc55a7c53c8edd2e97443e0eea22c9/net5-iis-ps-publish.ps1#L389 -L396

aspnet/vsweb-publish est également très intéressant ; cependant, il semble qu'il utilise offline-template.html , et j'ai pensé qu'il avait été découvert que cette méthode n'empêcherait pas le problème de verrouillage dll ... seulement arrêter l'AppPool, déployer et redémarrer l'AppPool a été stable, approche de travail.

nous ne devrions pas avoir à nous soucier des scripts de déploiement personnalisés lorsque nous travaillons dans des conditions par défaut avec VS2015

Une chose m'est cependant venue à l'esprit : pouvoir utiliser "Publier sur le système de fichiers" et accrocher un script juste après la publication contenant des bits MSDeploy a permis une histoire de déploiement très simple et utile pour plusieurs machines virtuelles. Étant donné que le script est exécuté de manière séquentielle, il va simplement de VM à VM tout au long de la ligne. Fait une bonne pause café. :le sourire:

J'ai une question dans Commencer à configurer un équilibreur de charge accessible sur Internet à l'aide d'Azure Resource Manager avec l'équipe Azure Resource Manager pour savoir comment indiquer à l'équilibreur de charge d'arrêter temporairement d'envoyer du trafic vers la machine virtuelle pendant le déploiement.

Quoi qu'il en soit ... revenons au sujet à portée de main que @pekkah a soulevé. Puisque nous savons que les commandes PS fonctionnent, vérifiez les options pour les exécuter dans une version VSO :

Microsoft/vso-agent-tâches
Exécutez un script dans votre processus de génération
Exécution de scripts de pré-construction dans Team Foundation Service (Visual Studio Online) pour le processus de génération de déploiement continu Azure
Nouvelles fonctionnalités d'automatisation de la construction dans Visual Studio Online

... ouais ... quelque chose comme ça devrait fonctionner pour vous.

Même problème ici...

Toujours en attente d'une solution officielle

Bruno

Cela sera résolu par https://github.com/aspnet/IISIntegration/issues/81.

@moozzyk , ce problème ne résoudra que le déploiement via des outils dédiés comme msdeploy. Le déploiement de Xcopy/File sync ne serait toujours pas possible, ce qui bloquera/entravera également de nombreux scénarios CI qui fonctionnent uniquement avec ASP.NET v1-4.

Le problème existe toujours dans ASP.NET Core 1.0 RC2 avec Visual Studio 2015.2 MSDeploy vers IIS 8 sur Windows 2012 R2 avec les derniers outils pour le serveur. L'arrêt du processus dotnet.exe ou le recyclage du pool d'applications résout le problème. Mais cela nécessite un accès de bureau à distance au serveur et ce n'est pas exactement un processus fluide.

@dg9ngf - c'est un bogue dans web.deploy maintenant. Ils ont ajouté la fonctionnalité app_offline.htm pour Azure, mais elle est désactivée par défaut lorsque vous déployez localement. Essayez d'ouvrir votre profil de publication (PublishProfiles->*.pubxml) et modifiez :

<EnableMSDeployAppOffline>False</EnableMSDeployAppOffline>

pour

<EnableMSDeployAppOffline>True</EnableMSDeployAppOffline>

Si cela ne fonctionne pas, demandez à @vijayrkn

Si vous utilisez les outils VS pour publier à l'aide d'un profil msdeploy, cette propriété est automatiquement ajoutée à votre pubxml.

<EnableMSDeployAppOffline>True</EnableMSDeployAppOffline>

Dans votre fenêtre de sortie, vous devriez voir une commande msdeploy similaire à celle-ci.

"C:\Program Files (x86)\IIS\Microsoft Web Deploy V3\msdeploy.exe" -source:manifest='C:\Users\vramak\AppData\Local\Temp\PublishTemp\obj\SourceManifest.xml' -dest:manifest='C:\Users\vramak\AppData\Local\Temp\PublishTemp\obj\DestManifest.xml',ComputerName='https://netcoreappwithdb.scm.azurewebsites.net/msdeploy.axd',UserName='$netcoreappwithdb',Password='{PASSWORD-REMOVED-FROM-LOG}',IncludeAcls='False',AuthType='Basic' -verb:sync -enablerule:AppOffline -enableRule:DoNotDeleteRule -retryAttempts:20

-e nablerule:AppOffline dans la commande doit prendre soin d'ajouter l'appOffline lors du déploiement.

Si un contenu appOffline personnalisé est nécessaire, vous pouvez définir cette propriété dans pubxml.

<AppOfflineTemplate>Path to app offline</AppOfflineTemplate>

Cette propriété n'était _pas_ présente dans le fichier .pubxml créé par Visual Studio. Je l'ai donc ajouté mais ça n'a rien changé. L'argument -e permettrerule:AppOffline n'apparaît _pas_ dans la fenêtre de sortie.

Pouvez-vous partager la ligne de commande msdeploy affichée dans la fenêtre de sortie ?

Pouvez-vous également confirmer que le pubxml a WebPublishMethod comme 'MSDeploy'.
<WebPublishMethod>MSDeploy</WebPublishMethod>

Non, le fichier a ceci à la place : <WebPublishMethod>FileSystem</WebPublishMethod>

Voici la ligne de commande de la fenêtre de sortie : Executing command ["C:\Program Files (x86)\IIS\Microsoft Web Deploy V3\msdeploy.exe" -source:manifest='C:\Users\yves\AppData\Local\Temp\PublishTemp\obj\SourceManifest.xml' -dest:manifest='C:\Users\yves\AppData\Local\Temp\PublishTemp\obj\DestManifest.xml' -verb:sync -enableRule:DoNotDeleteRule -retryAttempts:20 -disablerule:BackupRule]

Je déploie à l'aide de la tâche "Azure Web App Deployment" dans VSTS, comme décrit dans cet article de blog : http://donovanbrown.com/post/2016/05/30/DevOps-for-ASPNET-Core-RC2

Existe-t-il un moyen de spécifier le <EnableMSDeployAppOffline>True</EnableMSDeployAppOffline> en utilisant cette méthode ?

Salut, j'ai eu le même problème chez Azure, j'ai résolu de cette façon https://github.com/davidebbo/WAWSDeploy/issues/14

@dg9ngf Dans la version actuelle du script powershell, nous prenons en charge appOffline uniquement pour WebPublishMethod - 'MSDeploy'.

La prise en charge d'AppOffline pour la publication du système de fichiers sera disponible dans la prochaine version.

@bojingo Je suis dans la même situation. Avez-vous compris cela?

@davenewza : Si vous visitez à nouveau ce blog, la solution est dans les commentaires.
http://donovanbrown.com/post/2016/05/30/DevOps-for-ASPNET-Core-RC2

Fondamentalement, vous devez ajouter des étapes VSTS pour arrêter/démarrer le site. Très loin d'être une solution idéale (en fait, assez boiteuse), d'autant plus que je n'utilise pas d'emplacements de déploiement, mais cela fonctionne bien pour notre environnement de développement/test.

Il existe une nouvelle version ARM d'aperçu de la tâche VSTS de déploiement d'applications Web qui est basée sur msdeploy et promet de le réparer, mais je n'ai pas eu de chance car j'avais besoin que le client crée un principal de service pour l'abonnement, et que était un problème. Peut-être que vous pouvez faire fonctionner cela:
https://github.com/Microsoft/vsts-tasks/tree/master/Tasks/AzureRmWebAppDeployment

@vijayrkn La boîte de dialogue Publier le Web dans VS2015 ne contient aucune option pour définir msdeploy - ne donne que les options pour WebPublishMethod=FileSystem.

Pouvez-vous fournir un exemple de .pubxml pour WebPublishMethod=msdeploy s'il vous plaît ?

@tomfanning Pour une application de console principale ASP.NET, la seule option de publication actuellement disponible est le système de fichiers. Essayez-vous de publier une application console ? Pour une application Web, toutes ces 4 options doivent être disponibles (webdeploy, package de déploiement Web, système de fichiers et ftp).
Exemple de webdeploy pubxml - https://github.com/dotnetpublish/AspNetCoreBlogList/tree/master/src/AspNetCoreBlogList/Properties/PublishProfiles

S'il s'agit d'une application Web et que vous ne voyez que l'option de publication du système de fichiers, pouvez-vous vérifier le xproj pour voir s'il l'importe ?
<Import Project="$(VSToolsPath)\DotNet.Web\Microsoft.DotNet.Web.targets" Condition="'$(VSToolsPath)' != ''" />

@bojingo J'ai pu configurer le principal du service, il existe plusieurs tutoriels sur le net. Je n'ai pas les liens ici mais je peux les chercher si vous avez besoin. Maintenant, mon problème est que la tâche nécessite un fichier parameters.xml qui n'est pas généré sur la publication ASP Net Core... :(

J'ai TFS 2015 sur site et cela reste un problème incroyablement ennuyeux.

Je rencontre également ce problème...

Ma solution était de garder mon emplacement intermédiaire que je déployais à l'arrêt, puis de le publier (l'échange automatique fonctionne). Le redémarrage, puis le déploiement n'ont pas fonctionné (déploiement avec VSTS)

J'utilise Octopus avec Azure Web Apps, qui ne présente pas d'option pour les emplacements intermédiaires. Cependant, la vérification des options suivantes semble avoir fonctionné :

• Réduisez en toute sécurité le domaine de l'application avec app_offline.html vide à la racine.
• Supprimer les fichiers sur la destination qui ne font pas partie du déploiement

J'utilise Visual Studio 2015 Update 3 pour publier un site asp.net core 1.1 / .net framework 4.5.2 sur IIS. Il descend App_Offline.htm ce qui ne supprime pas le site. Si je le renomme sur le serveur en app_offline.htm , le site tombe en panne.

Par cette app_offline.htm doit être insensible à la casse.

https://github.com/aspnet/IISIntegration/issues/81

Le déployeur télécharge app_offline.htm (insensible à la casse)

Je viens de publier à nouveau et je vois App_Offline.htm abandonné et mon site n'est pas tombé en panne et j'obtiens le fichier en erreur d'utilisation. Lorsque je le change en app_offline.htm , mon site tombe en panne et je peux publier sans erreur.

J'héberge sur un chemin UNC partagé - je ne sais pas si cela fait une différence.

@Tratcher - savez-vous pourquoi la casse de App_Offline.htm ferait une différence ici ?

jayvijayrkn voir https://github.com/aspnet/AspNetCoreModule/issues/50

J'ai pu résoudre ce problème en ajoutant un paramètre d'application Azure de

MSDEPLOY_RENAME_LOCKED_FILES = 1

... comme décrit ici :
https://github.com/Microsoft/vsts-tasks/issues/1607#issuecomment -260946957

YMMV

@BenBarreth Existe-t-il quelque chose de similaire applicable aux non-Azure ?

pas que je sache désolé @jdshkolnik

Il semble qu'il puisse y avoir des problèmes avec MSDEPLOY_RENAME_LOCKED_FILES = 1. Cela aide le déploiement à réussir, mais peut signifier que les nouvelles DLL ne sont pas récupérées lors de l'exécution :
https://github.com/Azure/azure-webjobs-sdk-script/issues/569#issuecomment -264490818

Cela ne me semble pas être une "solution" appropriée. Il masque simplement l'échec du déploiement.

Le vrai correctif peut éventuellement être décrit dans ce problème :
https://github.com/Azure/azure-webjobs-sdk-script/issues/1023

Vraiment à la recherche d'une solution à cela. Il semblait que la tâche VSTS de déploiement Web RM s'en occupait avec l'option "Mettre l'application hors ligne" sélectionnée, mais depuis ce week-end, nous recevons constamment des erreurs. Nous sommes revenus à l'arrêt de l'emplacement de déploiement, au déploiement et au redémarrage.

De même chez nous, ce problème est apparu vendredi la semaine dernière et nous a empêché de nous déployer depuis...

Pareil ici. On dirait que cela n'affecte que les sites avec Always On = true, mais ce n'est pas sûr.

J'ai toujours ce problème même en définissant MSDEPLOY_RENAME_LOCKED_FILES = 1 dans ma configuration. Il est presque impossible de mettre à jour la version sur mon serveur maintenant. Cela a commencé à se produire il y a quelques jours.

Le même problème a commencé à se produire pour moi cette semaine. Jusqu'à cette semaine, le déploiement d'un service d'application AzureRM dans VSTS avec le paramètre Take App Offline = true fonctionnait systématiquement. Maintenant, ce paramètre semble être ignoré ou le service n'est pas déconnecté à temps. Je dois redémarrer manuellement ou arrêter/démarrer le service d'application lors de l'exécution de la version pour qu'il dépasse également.

Même problème ici. AzureRm a fonctionné pendant des mois et s'est soudainement arrêté. Mon dernier déploiement a eu lieu il y a deux semaines le 12/5 et maintenant le 12/20, il génère le Error_File_In_Use. Très ennuyé de devoir revenir au démarrage/arrêt manuel.

Voici notre solution de contournement dans Powershell que nous utilisons pour l'instant dans le cadre de notre processus CI/build. Un merci spécial aux gars de @appveyor pour leur aide :

$username = $env:deployusername
$password = $env:deploypassword
$base64AuthInfo = [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes(("{0}:{1}" -f $username,$password)))
$Headers = @{
  'Authorization' = ('Basic {0}' -f $base64AuthInfo)
  'If-Match'      = '*'
}
$apiUrl = "https://YourAzureWebsite.scm.azurewebsites.net/api/vfs/site/wwwroot/app_offline.htm"
$filePath = "app_offline_tmp.htm"
Invoke-RestMethod -Uri $apiUrl -Headers $Headers -Method PUT -InFile $filePath -ContentType "multipart/form-data"

Cela utilise l' API Kudu REST pour HTTP PUT le fichier app_offline.htm correctement casé en place. WebDeploy est configuré pour supprimer tous les fichiers qui ne sont pas dans le déploiement, il supprime donc automatiquement le fichier dans le cadre du déploiement. Vous devrez peut-être répéter l'étape en utilisant un HTTP DELETE pour supprimer le fichier une fois votre déploiement terminé si vous n'utilisez pas ce mode.

L'ajout d'un Trackyon Stop avant la tâche AzureRM et d'une tâche Trackyon Start après fonctionne bien pour moi. Cela ne devrait pas être nécessaire avec le TakeAppOffline = true mais cela fonctionne et cela évite le manuel ou les scripts. Ajoutez simplement la tâche à la définition de release. Les marches Trackyon sont faciles à installer

Le 21 décembre 2016, à 00h10, Chad T < [email protected] [email protected] > a écrit :

Voici notre solution de contournement dans Powershell que nous utilisons pour l'instant dans le cadre de notre processus CI/build. Un merci spécial à @appveyor https://github.com/appveyor les gars pour leur aide :

$username = $ env:deployusername
$password = $ env:deploypassword
$base64AuthInfo = [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes(("{0}:{1}" -f $username,$password)))
$En-têtes = @{
'Autorisation' = ('Basic {0}' -f $base64AuthInfo)
'Si-Correspondance' = '*'
}
$apiUrl = " https://VotresiteWebAzure.scm.azurewebsites.net/api/vfs/site/wwwroot/app_offline.htm "
$filePath = "app_offline_tmp.htm"
Invoke-RestMethod -Uri $apiUrl -Headers $Headers -Method PUT -InFile $filePath -ContentType "multipart/form-data"

Cela utilise l'API Kudu REST https://github.com/projectkudu/kudu/wiki/REST-API pour HTTP METTRE le fichier app_offline.htm correctement casé en place. WebDeploy est configuré pour supprimer tous les fichiers qui ne sont pas dans le déploiement, il supprime donc automatiquement le fichier dans le cadre du déploiement. Vous devrez peut-être répéter l'étape à l'aide d'un HTTP DELETE pour supprimer le fichier une fois votre déploiement terminé si vous n'utilisez pas ce mode.

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub https://github.com/aspnet/Home/issues/694#issuecomment-268436959 ou désactivez le fil de discussion https://github.com/notifications/unsubscribe-auth/AID9WoUdbuBnFoXR2K5o8AiUtv8nE9dRks5rKLTcgaJpZM4FJp_R .

Ce message n'est pas public et peut contenir des informations privilégiées, exclusives ou confidentielles. Si vous l'avez reçu par erreur, veuillez en informer immédiatement l'expéditeur et supprimer toutes les copies de l'original. Toute autre utilisation de l'e-mail par vous est interdite. Toute copie, stockage, utilisation ou divulgation non autorisée du contenu de ce message n'est pas autorisée et peut être illégale. Lorsque la législation locale l'autorise, les communications électroniques avec Lithero peuvent être surveillées et analysées par nos systèmes à des fins de sécurité des informations et d'évaluation de la conformité interne aux politiques de Lithero et aux lois applicables.

/ cc @davidebbo

Essayez de définir MSDEPLOY_RENAME_LOCKED_FILES=1 dans les paramètres de l'application Azure pour votre application.

@davidebbo cela ne semble pas résoudre les choses.

Je suppose que cela est lié à un changement du côté azur de la clôture ? Beaucoup de gens (en particulier sur le canal aspnet slack) ont eu ce problème en même temps.

Un changement dans Azure n'expliquerait pas pourquoi nous voyons cela sur site avec TFS. Serait-ce l'agent ?

Nous constatons le même problème. App_Offline.htm n'est pas récupéré. Bizarrement, si nous déployons à partir de VS, cela fonctionne bien.

Bizarrement, pour moi ça ne marche pas depuis VS, comme décrit ici : #1883

Mon équipe rencontre également ce problème, presque à chaque fois que le déploiement échoue en raison d'un fichier verrouillé. Doit redémarrer chaque application dans Azure et relancer le déploiement. Nous utilisons Octopus Deploy.

Mon équipe a rencontré ce problème ce matin. Des commentaires de l'équipe Microsoft ? Le pipeline de versions est essentiel à notre productivité, ce qui empêche les versions vers les sites de production. Merci!

@bmoscao - app_offline.html est sensible à la casse.

Ce problème est également apparu pour moi sur Azure. Rien de ce que j'ai fait de mon côté pour le provoquer.

J'ai aussi ce problème. Le fait est que EnableMSDeployAppOffline est défini sur true - et la sortie du projet affiche -enablerule:AppOffline dans le cadre de la commande exécutée par Visual Studio. Je ne sais pas quoi faire... Je n'ai commencé à avoir ce problème que récemment...

Notre solution de contournement consistait à arrêter le pool d'applications, à déployer, puis à redémarrer le pool d'applications. Nous utilisons Release Manager et le plugin powershell en ligne pour y parvenir.

Arrêter:

param( [string]$webApp, [string]$subscriptionName, [string]$resourcegroupName );  
Select-AzureRmSubscription -SubscriptionName $subscriptionName; 
Stop-AzureRmWebapp -Name $webApp -ResourceGroupName $resourcegroupName

Démarrer:

param( [string]$webApp, [string]$subscriptionName, [string]$resourcegroupName );  
Select-AzureRmSubscription -SubscriptionName $subscriptionName; 
Start-AzureRmWebapp -Name $webApp -ResourceGroupName $resourcegroupName

Cependant, nous apprécierions certainement une contribution de Microsoft, cela fonctionnait très bien en activant simplement la règle appOffline sur l'étape de déploiement RM Azure.

@davidebbo Nous utilisons ASP.NET Core, VSTS Release Manager et AzureRmWebApp avec des emplacements.

@davidebbo merci ! Ça marche pour moi ;)

Cela nous arrive également - msdeploy sur Azure. Content de voir que ça a commencé mystérieusement pour plusieurs personnes en même temps - et il n'y a pas que nous - mais pas hyper rassurant dans l'ensemble !

Je ne pense pas que les gens de MS aient besoin de confirmation pour cela, ils savent probablement bien quel est le problème. En tout cas, pareil ici. Déploiement à partir de VSTS, arrêté de travailler début décembre. Pour le moment, j'utilise la tâche trackyon pour arrêter/démarrer.

En parcourant ce fil, pour chaque entrée, ce n'est pas toujours clair :

1. si le problème fait référence à Azure App Service ou à un autre hébergement
2. si les gens ont essayé de changer la casse app_offline comme indiqué ci-dessus. Il semble que plusieurs personnes y aient rapporté du succès.
3. si MSDEPLOY_RENAME_LOCKED_FILES a été essayé. Encore une fois, plusieurs personnes semblent avoir réussi avec cela.

Si vous rencontrez ce problème, veuillez indiquer très clairement votre scénario et ce que vous avez essayé, afin que nous puissions comprendre cela. Merci!

@davidebbo

Je reçois le message ERROR_FILE_IN_USE lorsque j'essaie de déployer à l'aide de Visual Studio/MSBuild. La tâche crée un fichier App_Offline.htm sur le serveur mais n'arrête pas l'application.

La création d'un fichier app_offline.htm à l'aide de Web Deploy supprime l'application.

Voici ma configuration :

• Serveur : IIS 8, .NET Core Windows Server Hosting 1.1.0 et Web Deploy 3.6
• Ma machine : Visual Studio 2015 Update 3 et .NET Core 1.0.1 Tools Preview 2
• Publier le profil :

<?xml version="1.0" encoding="utf-8"?>

<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <_SavePWD>False</_SavePWD>
    <ADUsesOwinOrOpenIdConnect>False</ADUsesOwinOrOpenIdConnect>
    <AllowUntrustedCertificate>True</AllowUntrustedCertificate>
    <DeployIisAppPath>...</DeployIisAppPath>
    <EnableMSDeployAppOffline>True</EnableMSDeployAppOffline>
    <EnableMSDeployBackup>True</EnableMSDeployBackup>
    <EnvironmentName>Production</EnvironmentName>
    <ExcludeApp_Data>False</ExcludeApp_Data>
    <LastUsedBuildConfiguration>Release</LastUsedBuildConfiguration>
    <LastUsedPlatform>Any CPU</LastUsedPlatform>
    <LaunchSiteAfterPublish>True</LaunchSiteAfterPublish>
    <MSDeployPublishMethod>WMSVC</MSDeployPublishMethod>
    <MSDeployServiceURL>...</MSDeployServiceURL>
    <PublishFramework>netcoreapp1.1</PublishFramework>
    <PublishRuntime>win81-x64</PublishRuntime>
    <RemoteSitePhysicalPath />
    <SiteUrlToLaunchAfterPublish />
    <SkipExtraFilesOnServer>False</SkipExtraFilesOnServer>
    <UsePowerShell>True</UsePowerShell>
    <UserName>...</UserName>
    <WebPublishMethod>MSDeploy</WebPublishMethod>
  </PropertyGroup>
</Project>

@davidebbo

J'ai commenté cette erreur sur un fil similaire et j'ai dû arrêter et redémarrer mon application Web Azure chaque fois que je voulais me redéployer (uniquement dans l'environnement de développement). Je n'ai jamais eu à le faire avant cette semaine. J'ai décidé de créer essentiellement une application Web principale Visual Studio 2015 .net à partir du modèle sans aucune modification.

J'ai exécuté l'application Web sur l'hôte local sans aucun problème.
Je publie la nouvelle application sur mon plan de service Azure Web App sans problème et le navigateur a immédiatement affiché le site sans problème.
J'ai vérifié Azure Dashboard et aucun problème.

Je suis ensuite allé republier l'application Web sans rien modifier - code ou paramètres et l'erreur suivante se présente.

À partir de là, je dois arrêter l'application Web, publier sur Azure, puis démarrer l'application Web. Cela ne m'était jamais arrivé auparavant. Il s'agit d'un déploiement très simple du modèle Microsoft.

J'ai enregistré tout ce processus et envoyé ces commentaires dans le système de commentaires Microsoft 2015 VS. J'espère que vous pourrez trouver cet enregistrement. Ou je pourrais probablement le refaire.

Cordialement Pierre

@davidebbo

si le problème fait référence à Azure App Service ou à un autre hébergement

Service d'applications Azure.

si les gens ont essayé de changer la casse app_offline comme indiqué ci-dessus. Il semble que plusieurs personnes y aient rapporté du succès.

Changer App_Offline en app_offline résout le problème - ce fichier est créé automatiquement via webdeploy avec la casse 'App_Offline' dans le cadre du déploiement, qui est au cœur du problème.

@davidebbo
Exactement le même que @ctolkien.

@davidebbo

si le problème fait référence à Azure App Service ou à un autre hébergement

Dans mon cas, je déploie sur Azure App Service. Je ne connais pas les autres hébergements.

si les gens ont essayé de changer la casse app_offline comme indiqué ci-dessus. Il semble que plusieurs personnes y aient rapporté du succès.

J'utilise la tâche "Déployer AzureRM Web App" de VSTS (https://aka.ms/azurermwebdeployreadme). Il existe une option "Publier à l'aide de Web Deploy" <- cochée et "Mettre l'application hors ligne" <- cochée qui fonctionnait, jusqu'à ce que quelque chose change quelque part et que cela cesse de fonctionner.
L'infobulle "info" indique explicitement le placement de "app_offline.htm" avec un "a" minuscule.
Je ne sais pas comment le changer en utilisant ce script, il devrait déjà être en minuscules.

si MSDEPLOY_RENAME_LOCKED_FILES a été essayé. Encore une fois, plusieurs personnes semblent avoir réussi avec cela.

Pas essayé. Je ne sais pas comment faire ça. Mais dans tous les cas, je préférerais mettre l'application hors ligne au lieu de modifier le contenu des fichiers verrouillés.

Merci a tous. Il semble donc clair que le principal problème concerne la casse de app_offline.htm , et non tout ce qui concerne Azure App Service (d'où je viens). Et cela est suivi par https://github.com/aspnet/AspNetCoreModule/issues/50.

Je te conseille de fermer ce sujet et de garder l'autre. Je laisserai les experts ASP.NET partir de là, à moins qu'il y ait des raisons de penser qu'Azure Web App est en partie à blâmer (peu probable sur la base de @fabiano signalant la même chose en dehors d'Azure).

En fait, cela ressemble à une régression dans l'outillage où il semble avoir commencé à créer App_Offline.html au lieu de app_offline.html. @mlorbetske , @vijayrkn - avez-vous une idée de ce que cela peut être ?

Je vois, donc vous dites que le runtime principal (AspNetCoreModule) était toujours sensible à la casse, mais que cela ne posait pas de problème car VS utilisait la casse correspondante et maintenant ce n'est pas le cas?

Quoi qu'il en soit, je dirais que le runtime ne devrait pas être sensible à la casse ici, il y a donc deux voies possibles pour résoudre le problème.

@davidebbo - c'est exact. Je crois qu'AspNetCoreModule était toujours sensible à la casse.

@davidebbo

et rien en rapport avec Azure App Service (d'où je viens)

Je suppose que la raison de l'introduction d'Azure AppService dans la discussion est que sans aucun changement de notre part, les choses ont juste commencé à échouer, nous n'avons modifié aucune de nos versions de package. La révision de l'ANCM a-t-elle été révisée sur App Services ?

@ctolkien oui, je pense qu'il a bien été mis à jour. Il se pourrait donc très bien que la conclusion ci-dessus ne soit pas correcte. Au lieu de cela, la nouvelle théorie est la suivante :

• L'ancien ANCM (7.1.1965.0) n'était pas sensible à la casse.
• Le plus récent (7.1.1970.0) est devenu sensible à la casse.
• Rien n'a changé du côté de la publication VS, et la casse a toujours été App_Offline.htm .

@moozzyk pensez-vous que c'est une possibilité, ou êtes-vous sûr que c'était toujours sensible à la casse ?

@moozzyk @davidebbo - Il n'y a eu aucun changement dans l'outillage VS pour la casse app_offline. Les outils VS appellent msdeploy avec la règle appoffline (-enablerule:AppOffline) et msdeploy supprime App_Offline.htm.

Ce problème ressemble à un changement de comportement dans ANCM. Sur la base du premier commentaire ici, app_offline doit être sensible à la casse (https://github.com/aspnet/IISIntegration/issues/81).

@ctolkien

Changer App_Offline en app_offline résout le problème

Où puis-je changer cela ? Je fais MSDEPLOY directement de Visual Studio vers Azure.

@oyvindvol

Où puis-je changer cela ? Je fais MSDEPLOY directement de Visual Studio vers Azure.

Pour autant que je sache, vous ne pouvez pas modifier la casse de App_Offline à partir de MSDEPLOY, vous devrez personnaliser une solution pour le moment. Vous pouvez utiliser le script powershell que j'ai posté ci-dessus comme point de départ.

Pour mettre à jour tout le monde, nous avons confirmé que la théorie ci-dessus est correcte : le bogue de sensibilité à la casse est une régression dans la nouvelle version d'ANCM, et cette version a été déployée sur Azure App Service en décembre, ce qui a soudainement amené les utilisateurs à y accéder.

Le plan consiste à obtenir un correctif ANCM auprès de l'équipe ASP.NET Core et à le déployer sur App Service. Il n'y a pas encore d'ETA, mais cela devrait arriver courant janvier.

Merci!

@davidebbo pourrons-nous télécharger ANCM pour l'installer sur notre propre serveur en utilisant iis et en frappant également ce bogue particulier ?

@Pictuel Je pense que oui. Notez que mon angle ici est strictement Azure App Service, donc je laisserai l'équipe Core commenter les scénarios non-Azure.

Merci pour l'information :)

@Pictuel Oui, nous veillerons à ce qu'une version mise à jour du programme d'installation de l'hébergement Windows pour .NET Core soit publiée, contenant la mise à jour de l'ANCM.

@shirhatti

@shirhatti Je surveille ici lorsque le programme d'installation mis à jour est disponible pour mettre à jour les liens de documentation.

Après avoir parcouru ce fil, je ne sais pas vraiment quelle est exactement la solution de contournement pour App Services. S'agit-il des paramètres de l'application ou utilise-t-il un script de déploiement personnalisé ou arrête et démarre le site ?

S'il s'agit du paramètre de l'application, j'ai lu un autre commentaire disant que le site Web ne récupère pas les nouvelles DLL.

Si j'ai bien compris, il n'y a pas de solution de contournement de notre côté jusqu'à ce qu'une mise à jour soit disponible sur ANCM (https://github.com/aspnet/AspNetCoreModule/issues/50). Les services d'application doivent être mis à jour par l'équipe Azure.

Je pense que vous feriez mieux de parier sur App Service est d'arrêter/démarrer l'application comme décrit par @dtmnash ici .

@davidebbo "Le plan est d'obtenir un correctif ANCM de l'équipe ASP.NET Core et de le déployer sur App Service. Il n'y a pas encore d'ETA, mais cela devrait arriver en janvier." -- Faites-nous savoir quand un ETA est prêt à ce sujet :)

L'ETA de déploiement provisoire se situe entre le 24 et le 30. Le déploiement se produit progressivement sur les nombreuses unités d'échelle, de sorte que tout le monde ne recevra pas le correctif exactement au même moment.

Merci, pour moi ça vient de commencer :-)

Toujours un problème pour moi :(

@hbunjes merci pour la confirmation !

@rsnj , cela se produit progressivement sur une certaine période de temps. Tout devrait être fait d'ici la fin du mois (sauf si nous rencontrons un problème).

@davidebbo Le déploiement semble fonctionner pour certaines de mes applications mais pas pour toutes. Ce qui est étrange, c'est que certains déploiements échouent, mais pas d'autres pour les applications exécutées dans le même plan App Service. Est-il possible de voir quelle version d'ANCM est en cours d'exécution pour une application Web particulière ?

@henningst Voir https://github.com/aspnet/AspNetCoreModule/issues/50#issuecomment -271381892 pour un moyen de vérifier.

Ne fonctionnait pas pour moi hier, mais c'est maintenant. Merci @davidebbo!

Cela a commencé à fonctionner pour moi aussi. Merci!

Oui, le déploiement est maintenant terminé, il devrait donc fonctionner pour tout le monde.

Tout va bien pour moi ici aussi.

Semble fonctionner maintenant. D'après le rapport, il a fallu plus d'un an pour résoudre ce problème. J'aurais bien que les problèmes de déploiement aient une priorité plus élevée :p

Comment résoudre ce problème pour les non-Azure ?

@pekkah Je pense que cela a traversé des problèmes distincts. Le dernier était bien plus récent qu'un an.

@jdshkolnik pour les non-Azure, je suppose qu'il vous suffit de commencer à utiliser le nouvel ANCM.

@jdshkolnik
La mise à jour est disponible en téléchargement sur https://www.microsoft.com/net/download/core#/runtime
Ceci est un lien direct vers le téléchargement.

@shirhatti J'ai installé ceci mais j'obtiens toujours ces erreurs.

Je reçois toujours l'erreur à Sao Paulo, dans le sud du Brésil.

@jdshkolnik Quelle version voyez-vous lorsque vous l'exécutez dans PowerShell ?

[System.Diagnostics.FileVersionInfo]::GetVersionInfo("C:\Windows\System32\inetsrv\aspnetcore.dll").FileVersion

@shirhatti 7.1.1971.0

Mise à jour : désolé, c'était de ma faute. J'examinais et mettais à jour les étapes de déploiement d'une version existante plutôt que la définition de la version. Je ne compte plus le nombre de fois où j'ai fait ça...

Je rencontre toujours cette erreur chaque fois que j'essaie de déployer même si ma version d'aspnetcore.dll est celle qui est censée être corrigée.

version aspnetcore.dll : 7.1.1971.0
Déployé à l'aide de : tâche VSTS Azure App Service Deploy v3.* (préversion)
Mettre l'application hors ligne : coché
Supprimer les fichiers supplémentaires à destination : coché
Renommer les fichiers verrouillés : coché
Paramètre d'application MSDEPLOY_RENAME_LOCKED_FILES : non ajouté

À ce stade, je ne sais pas quels paramètres sont nécessaires ou non pour que cela fonctionne.

Je viens d'avoir à nouveau mon premier problème de fichier en cours d'utilisation sur les services d'application azur :

2017-02-14T22:41:10.4400186ZC:\Program Files (x86)\IIS\Microsoft Web Deploy V3\msdeploy.exe - source:IisApp= 'D:/a/r1/a/Ascend Ammo Portal/drop/apps /artifacts/AmmoPortal' - dest:IisApp= 'core-asyoz77ajoed4/ammo-preview',ComputerName=' https://core-asyoz77ajoed4.scm.azurewebsites.net/msdeploy.axd?site=core-asyoz77ajoed4/ammo -preview ',UserName='$core-asyoz77ajoed4',Password=' * * ',IncludeAcls='False',AuthType='Basic' - verb:sync -retryAttempts=20 -verbose -e nablerule:AppOffline

2017-02-14T22:41:34.3837386Z Code d'erreur : ERROR_FILE_IN_USE

2017-02-14T22:41:34.3837386Z Plus d'informations : Web Deploy ne peut pas modifier le fichier « Ascend.Ammo.Portal.exe » sur la destination car il est verrouillé par un processus externe. Afin de permettre à l'opération de publication de réussir, vous devrez peut-être soit redémarrer votre application pour libérer le verrou, soit utiliser le gestionnaire de règles AppOffline pour les applications .Net lors de votre prochaine tentative de publication. En savoir plus sur : http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_FILE_IN_USE.

2017-02-14T22:41:34.3837386Z Nombre d'erreurs : 1.

Pour votre information : la documentation semble être liée à un programme d'installation avec l'ancienne version (*.1970) : https://docs.microsoft.com/en-us/aspnet/core/publishing/iis#install -the-net-core- bundle d'hébergement de serveur Windows.

En outre, il semble que sur la page des téléchargements d'exécution, seule la version LTS ait le correctif ?

@shirhatti ~Faites-moi savoir quand le nouveau lien d'installation du pack d'hébergement est prêt, et je le mettrai dans la documentation (il se trouve à quelques endroits).~

~ Est-ce celui-ci : https://go.microsoft.com/fwlink/?linkid=837808 ... ce n'est pas un lien aka.ms.~

J'ai configuré https://github.com/aspnet/Docs/pull/2773 pour couvrir cela si le fwlink est correct.

Se produit également dans Visual Studio et, comme le montrent les options, la règle hors ligne de l'application est présente.

@davidebbo pourriez-vous confirmer que cela est résolu ? Entendre pas mal de gens dire qu'ils le frappent toujours. La version finale de l'outillage a-t-elle corrigé ce problème ou s'agit-il toujours d'un problème d'hébergement ?

J'essaie aussi de comprendre pourquoi et quand cela se produit. Je suis presque sûr d'avoir vu que le processus s'exécute dans l'explorateur de processus sur le site scm et qu'il est très bien publié.

Je suis également en train de mettre à jour mes sites avec les outils les plus récents, en espérant que le problème est lié à l'ancien outil project.json.

Le correctif a été déployé sur Azure App Service il y a quelque temps, et je ne sais pas si quelqu'un voit encore le problème par la suite. Bien sûr, les utilisateurs sur des hôtes non-Azure peuvent toujours le voir s'ils n'ont pas été mis à jour.

Pour Azure, si vous rencontrez un problème, veuillez le tester comme suit :

• Accédez à l'explorateur de processus Kudu et assurez-vous que le processus de votre application est en cours d'exécution (généralement dotnet.exe)
• Créez manuellement un fichier app_offline.htm (par exemple, exécutez touch app_offline.htm ) à partir de la commande Kudu
• Vérifiez à nouveau l'explorateur de processus et assurez-vous que le processus n'est plus là.

Je vais tester un peu plus, avez-vous vu l'image quelques messages plus haut, cela montre clairement que le fichier est en cours d'utilisation et qu'il utilise l'application hors ligne.

Mais je vais tester comme vous l'avez demandé.

De plus, nous utilisons des applications scaleout + déployées sur des applications virtuelles - je ne sais pas si cela change quelque chose.

@pksorensen le faire "manuellement" aidera à isoler de tout ce que WebDeploy pourrait faire. c'est-à-dire que si le simple fait de supprimer app_offline.htm n'arrête pas le processus, nous savons vraiment qu'il existe un problème qui n'est pas causé par WebDeploy.

Notez que normalement, vous vous retrouvez avec un processus dotnet.exe, alors que dans votre cas, vous avez un nom d'exe différent. Je me demande si cela a un lien avec le problème.

1. Accédez à l'explorateur de processus Kudu et assurez-vous que le processus de votre application est en cours d'exécution (généralement dotnet.exe)
   Je l'ai fait, mais ce n'est pas dotnet.exe mais notre nom compilé bin Ascend.Ammo.RegistrationTablet.exe

Ensuite, j'ai touché app_offline.htm, mais cela n'a pas tué le processus.

Est-ce que je fais quelque chose de mal puisque je ne vois pas dotnet.exe ?

Je laisserai les experts dotnet / ANCM commenter cette partie. Je sais que par défaut, lors du déploiement d'une application ASP.NET principale, elle utilise dotnet.exe. Je pense que le cas où ce n'est pas le cas, c'est lorsque vous utilisez un déploiement autonome (ou quel que soit son nom). Mais je n'ai aucune idée de la façon dont cela affecte ANCM et app_offline.htm.

@DamianEdwards qui peut le mieux commenter cela ?

J'évite ce problème en utilisant des emplacements de déploiement. Fonctionne 100% du temps. Arrêtez la fente avant de copier des fichiers. Cela supprimera tout ce qui manque à la mémoire afin que votre copie ne fonctionne pas avec les fichiers verrouillés. Ensuite, démarrez la machine à sous et passez en production. L'avantage supplémentaire est que vos clients ne voient jamais la page hors ligne de l'application. Ils obtiennent un déploiement sans temps d'arrêt.

http://donovanbrown.com/post/MicrosoftCodeAnalysisCSharpdll-Locked-Problem-Fix

@DarqueWarrior slot fonctionne bien sûr (et est bon à utiliser pour d'autres raisons), mais l'essentiel dans ce fil est de comprendre pourquoi app_offline semble inefficace pour arrêter le processus Core pour certaines personnes comme @pksorensen. Et j'aimerais que l'équipe Core commente cela.

@davidebbo Pour répondre à votre question précédente, portable vs autonome n'a aucune incidence sur le comportement app_offline. Le fichier hors ligne de l'application est surveillé par w3wp.exe (par le module ASP.NET Core).

@DarqueWarrior Merci pour le conseil, un commentaire cependant - si vous, comme nous, déployez plusieurs sites vers des applications virtuelles dans le même service d'application, les emplacements (si je me souviens bien) fonctionnent sur tous ceux-ci, vous devrez donc déployer tous les sites avant échange. C'est un problème. À l'heure actuelle, nous pouvons facilement déployer des parties (microservices) sur des applications virtuelles individuelles. Bien sûr, nous pouvons les répartir dans des services d'application distincts, mais nous aurions alors besoin d'équilibreurs de charge/passerelles en amont pour qu'ils partagent à nouveau le même domaine, ce qui coûte également plus de temps que nous ne sommes prêts à le faire maintenant.

Je suis donc d'accord que ce que vous suggérez est la voie préférable, cela ne nous convient tout simplement pas pour le moment. Espérons donc toujours une résolution sur le problème du fichier en cours d'utilisation.

@pksorensen avez-vous la possibilité de créer une reproduction sur un site factice et de partager son nom ? Fondamentalement, j'aimerais le voir dans l'état où votre site est en cours d'exécution, et la création manuelle de app_offline.htm dans la console Kudu ne provoque pas sa fermeture.

@shirhatti avez-vous une idée de ce qui pourrait empêcher l'ANCM d'arrêter le processus ? Avec quelle agressivité essaie-t-il de le faire?

@davidebbo Cela me prendra un peu de temps mais je vais essayer de trouver quelque chose pour créer une reproduction.

@davidebbo J'ai créé une nouvelle application ASP.NET Core et un nouvel Azure App Service. J'utilise la fonctionnalité "Livraison continue (préversion)" d'Azure et je rencontre ce problème.

2017-03-30T02:54:36.5648892Z ##[error]Impossible de déployer App Service.
2017-03-30T02:54:36.5658893Z ##[error]Code d'erreur : ERROR_FILE_IN_USE
2017-03-30T02:54:37.1850861Z Plus d'informations : Web Deploy ne peut pas modifier le fichier « myApp.dll » sur la destination car il est verrouillé par un processus externe. Afin de permettre à l'opération de publication de réussir, vous devrez peut-être soit redémarrer votre application pour libérer le verrou, soit utiliser le gestionnaire de règles AppOffline pour les applications .Net lors de votre prochaine tentative de publication. En savoir plus sur : http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_FILE_IN_USE.
2017-03-30T02:54:37.1860517Z Nombre d'erreurs : 1.
2017-03-30T02:54:37.4179909Z ##[error]Erreur : C:\Program Files\IIS\Microsoft Web Deploy V3\msdeploy.exe a échoué avec le code de retour : 4294967295

La création manuelle d'un app_offline.htm dans D:\home\site\wwwroot arrête en effet le processus dotnet.exe.

Cela signifie-t-il donc qu'il y a un problème avec la "livraison continue (aperçu)" elle-même ?

Suite à ce qui précède, j'ai résolu ce problème en accédant manuellement à la définition de la version VSTS, aux options de déploiement supplémentaires, en cochant "Mettre l'application hors ligne".

Mais cela soulève quelques questions :
Pourquoi "Mettre l'application hors ligne" n'est-il pas coché par défaut ? Ce scénario devrait-il toujours fonctionner (par exemple, réduit-il les temps d'arrêt) ?

Si oui, alors pourquoi échoue-t-il ? Si non, pourquoi "Livraison continue (Aperçu)" n'est-il pas coché ?

Quoi qu'il en soit, il semble qu'il y ait un bug quelque part.

@ Jon12345 : ce fil de discussion concerne uniquement la question de savoir si app_offline.htm fonctionne correctement avec les applications Core. Donc, le fait que le VSTS puisse ou non le faire par défaut est vraiment une discussion distincte, qui devrait avoir lieu sur un forum VSTS (probablement https://social.msdn.microsoft.com/Forums/vstudio/en-US/ home?forum=TFService).

À ce stade, la plupart des gens semblent avoir été débloqués après le correctif. Il y a eu un rapport indiquant que cela ne fonctionnait pas par @pksorensen , et nous attendons une application de reproduction à examiner.

Je reçois toujours ceci sur la mise à jour 1 de TFS 2017.

@jdshkolnik Êtes-vous sûr qu'il est configuré pour créer le fichier appoffline.htm ? Si ce n'est pas le cas, cela sort du cadre de ce problème. Veuillez effectuer le test manuel appoffline.htm comme indiqué ci-dessus.

@davidebbo Oui, ça l'est. Il arrive souvent que le déploiement nocturne planifié échoue à sa première tentative et nécessite une tentative de redéploiement manuel qui réussit généralement.

Pour info, mon cabinet est fédéré avec le vôtre donc je peux facilement vous montrer via le partage de bureau Skype Entreprise.

@jdshkolnik , assurez-vous de faire le test manuel décrit ci-dessus, car cela aide à éliminer tout le reste de l'équation.

Important : Ce problème ne concerne pas l'examen d'un problème avec VSTS ou d'autres workflows de publication. Il ne s'agit que d'une chose : s'assurer que appoffline.htm fonctionne.

@davidebbo Il se déconnecte dès que je place manuellement app_offline.htm dans le dossier.

Je ne sais pas comment mieux distinguer si je suis parfaitement sur le sujet ici. Tout ce que je sais, c'est qu'il est soudainement apparu l'année dernière pour des sites qui fonctionnaient sans problème et qui a régulièrement relevé la tête depuis.

##[section]Starting: Deploy IIS App: \\usserver\Deploy\CD_146_QA\Installer\Install\Web\App.Web.zip
==============================================================================
Task         : WinRM - IIS Web App Deployment
Description  : Connect via WinRM, to deploy Web project locally on IIS, using Web Deploy
Version      : 1.4.3
Author       : Microsoft Corporation
Help         : [More Information](http://aka.ms/IISWebDeploy)
==============================================================================

Preparing task execution handler.

Executing the powershell script: I:\Agent\_work\_tasks\IISWebAppDeploy_50acc50f-7d15-470b-83c1-578b3f3eeba2\1.4.3\Main.ps1
name='db-Web.config Connection String',value='Data Source=dbserver;Database=Internal_QA;Type System Version=SQL Server 2012;User ID=xxx;Password=yyy;Persist Security Info=True')

Starting deployment of IIS Web Deploy Package : \\usserver\Deploy\CD_146_QA\Installer\Install\Web\App.Web.zip

Performing deployment in sequentially on all machines.

Deployment started for machine: usserver with port 5985.

Deployment status for machine usserver : Failed

##[error]Microsoft.PowerShell.Commands.WriteErrorException: System.Exception: Error Code: ERROR_FILE_IN_USE

For more info please refer to http://aka.ms/iisextnreadme

##[error]PowerShell script completed with 1 errors.

##[section]Finishing: Deploy IIS App: \\usserver\Deploy\CD_146_QA\Installer\Install\Web\App.Web.zip

@jdshkolnik Ma meilleure supposition est que quoi que fasse ce script de déploiement, il ne crée pas le fichier appoffline.htm avant de publier les fichiers. Il peut s'agir d'un problème de configuration VSTS ou d'un bogue. Mais du point de vue de l'ANCM, le test que vous avez effectué montre que les choses fonctionnent comme prévu lors de la création d'appoffline.

@davidebbo Je ne sais pas si ce que j'ai fait était un test définitif. Après tout, la deuxième tentative manuelle après avoir reçu une erreur réussit généralement. Le processus de déploiement susceptible de bloquer app_offline.htm n'était pas en cours d'exécution.

Je rencontre toujours ce problème sensible à la casse le 7.1.1971.0. Lorsque j'essaie de déployer à l'aide de VS, j'obtiens une erreur de fichier verrouillé, j'ai donc cherché à voir si l'application était toujours en cours d'exécution et bien sûr, c'était le cas. J'ai ouvert la ligne de commande Kudu pour voir quels fichiers se trouvaient dans le répertoire wwwroot et App_Offline.htm était dans le dossier, mais le processus était toujours en cours d'exécution. Ensuite, j'ai tapé touch app_offline.htm et le processus s'est arrêté comme prévu. J'ai vérifié les modules et ma version aspnetcore.dll est 7.1.1971.0.

@alexgritton c'est bizarre. Cela semblerait impliquer que l'ANCM n'a pas initialement détecté le fichier. Est-ce que cela se produit régulièrement ou au hasard?

Je viens de créer l'application aujourd'hui sur Azure App Services et cela s'est passé toute la journée, donc je dirais de manière cohérente. Avez-vous d'autres idées de ce qui pourrait causer cela?

Pas vraiment. Je laisserai les experts de l'ANCM commenter la façon dont ils surveillent les changements de fichiers et s'ils peuvent penser à une raison pour laquelle la création initiale n'est pas détectée.

@davidebbo J'ai exactement le même problème. Mon équipe a une version Fake qui copie un fichier AppBuild.htm du serveur de génération vers le site cible en tant que app_offline.htm. Nous essayons ensuite d'utiliser msdeploy pour synchroniser le dossier et obtenir l'ouverture par une autre erreur de processus. Si je touche le fichier, renommez le fichier de app_offline.htm à app_offline.htm.rename et vice-versa, ou écrasez app_offline.htm à l'aide de l'explorateur de fichiers, puis le processus s'arrête correctement. Il n'est pas tout à fait logique que cela ne fonctionne pas via notre script, mais si nous le faisons manuellement.

Mise à jour : nous avons constaté que la mise à jour de la dernière heure d'écriture semble déclencher systématiquement l'arrêt :

Target "StopApi" (fun _ ->                                    
    trace "Deployment - Stopping Api"                 

    for folder in apiWebDeployShare do                        
        let offlineFile = folder @@ "app_offline.htm"         
        let offlineFileSource = folder @@ "AppOffline.htm"    
        CopyFile offlineFile offlineFileSource                
        File.SetLastWriteTime (offlineFile, DateTime.Now)     
)                

Il semble définitivement y avoir quelque chose avec le code qui surveille le fichier app_offline.htm.

@derekgreer Donc, ce que vous voyez, c'est que lorsque vous copiez le fichier, l'arrêt n'est pas déclenché ? Je ne suis pas en mesure de reproduire cela à partir de la console Kudu. par exemple

• Accédez à la console Kudu
• Exécutez touch app_offline.htm dans D:\home\site pour créer un fichier vide dans un dossier différent
• Exécutez copy app_offline.htm wwwroot . Notez que cela préserve l'heure de la dernière écriture et met à jour l'heure de création (comportement standard de copie de fichier).

Résultat : le processus dotnet.exe s'arrête instantanément (vous pouvez vérifier à l'aide de l'explorateur de processus Kudu).

Ces mêmes étapes fonctionnent-elles pour vous ? Si oui, qu'est-ce qui pourrait être différent dans votre scénario de reproduction ?

En fait, j'aurais également dû ajouter que ce problème était intermittent et que nous utilisons IIS 8 sur Windows Server 2012 .

Mon intention ce matin était de voir si je pouvais reproduire le problème avec un script powershell ou batch avant de configurer la console Kudu, mais après avoir d'abord testé avec le test Fake build script mon équipe utilisait vendredi pour créer le fichier app_offline.htm dans de différentes manières (copier un fichier existant, créer un nouveau fichier, etc.), cela fonctionne actuellement. Cela reflète également le modèle de nos échecs de construction où il arrêtait parfois le processus et d'autres fois non. Quand il commence à échouer, il semble le faire de manière cohérente. Nous avons testé pendant des heures vendredi et cela ne s'arrêtait pas avec une simple construction Fake qui ne faisait absolument rien sauf créer un nouveau fichier app_offline.htm. Je devrais également ajouter que nous créions périodiquement le fichier manuellement et que le processus s'arrêtait, de sorte qu'il ne semblerait pas y avoir de situation dans laquelle le processus ne s'arrêterait pas après une longue période d'utilisation.

Lorsque je pourrai reproduire à nouveau le problème, je verrai si la création du fichier à l'aide de powershell et/ou d'un fichier batch reflète toujours le problème.

@davidebbo Eh bien, merde ... Je viens de remarquer que j'ai oublié de commenter une ligne qui mettait à jour l'heure de la dernière mise à jour, donc elle affiche toujours le même comportement. Je vais essayer avec powershell et un fichier batch maintenant et vous mettre à jour.

@davidebbo

Désolé pour la confusion. Bon, voici ce que j'ai trouvé :

L'utilisation d'un fichier de commandes avec le contenu suivant semble provoquer l'arrêt du processus de manière fiable :

echo "" > \\testserver\e$\Site.Api\app_offline.htm

L'utilisation d'un script bash équivalent provoque également l'arrêt fiable du processus :

#!/bin/bash

echo "" > //testserver/e$/Site.Api/app_offline.htm

L'utilisation d'un script powershell avec le contenu suivant semble ne jamais provoquer l'arrêt du processus :

New-Item \\testserver\e$\Site.Api\app_offline.htm -type file

Étant donné que Fake et Powershell s'exécutent sous le CLR alors que la commande de copie DOS, bash et la console Kudu ne le font pas, cela semble indiquer quelque chose lié au fichier créé via le CLR.

La chose étrange est que je ne vois aucune différence dans les horodatages de création/mise à jour du fichier résultant entre les différentes versions.

@derekgreer Oh, donc vous n'exécutez pas du tout Azure App Service. C'est mon angle dans toute cette saga, donc je laisserai les gens d'ASP.NET commenter davantage à ce sujet.

Bien que pour ce que ça vaut, je n'ai pas pu reproduire dans App Service :

• Utiliser la console PowerShell de Kudu
• Accédez au dossier site\wwwroot
• Courez New-Item app_offline.htm -type file

@moozzyk pouvez-vous aider à enquêter sur le service d'application externe repro de @derekgreer ?

Plus d'infos:

Étant donné que la création, la copie, le changement de nom, etc. via l'explorateur de fichiers a toujours fonctionné, j'ai décidé de voir si une application d'explorateur de fichiers basée sur .Net reflétait les mêmes résultats que ceux que je vois avec Fake et PowerShell. Il existe un explorateur de fichiers basé sur .Net nommé "Nomad" que j'ai fini par télécharger et tester et les résultats étaient cohérents avec Fake et PowerShell. Lors de la création d'un fichier app_offline.htm, le processus ne s'est pas arrêté. J'ai ensuite renommé le fichier et l'ai renommé à nouveau en app_offline.htm et le processus Core s'est ensuite arrêté.

https://github.com/aspnet/AspNetCoreModule/blob/93ace1b84bd79382233cb39b858611d2db05552e/src/AspNetCore/Src/filewatcher.cxx#L321

Je pense que cette méthode voudrait inclure le drapeau "FILE_NOTIFY_CHANGE_CREATION".

Je me demande si l'API .Net commune à Fake, PowerShell et Nomad ne déclenche pas ces autres indicateurs de la même manière que la création de fichiers normale.

@shirhatti pouvez-vous s'il vous plaît vous assurer que quelqu'un enquête sur ce problème potentiel de l'ANCM ?

@davidebbo Ack. Nous l'étudions

J'ai un problème très similaire. Si je copie dans un fichier app_offline.htm dans l'Explorateur Windows, le processus s'arrête correctement, mais si je le crée à l'aide de COPY app_offline.htm \server\share\siteapp_offline.htm à partir de mon serveur de build, il ne s'arrête pas et les fichiers restent verrouillés. .

@gulbanana J'ai exactement le même problème que vous. L'avez-vous déjà résolu ? @shirhatti Des mises à jour sur votre enquête ? Celui-ci rend l'équipe folle parce que le pipeline CI échoue tout le temps en raison d'échecs de copie de fichiers qui à leur tour sont causés par le fait que dotnet.exe n'est pas arrêté par app_offline.htm.

J'ai contourné le problème en utilisant quelque chose comme echo "<html>page content</html>" > \\server\share\app_offline.htm . Je pense que @derekgreer a raison de dire que le bogue concerne l'ANCM qui ne surveille que certaines méthodes de création de fichiers, et il attrape celui-ci.

@derekgreer
J'examine le problème maintenant. Avec l'une de vos commandes repro dans ma machine de test, j'ai pu reproduire ce problème. J'ai utilisé la commande ci-dessous. (REMARQUE : la commande ci-dessous créera un fichier vide (taille de fichier nulle).

new-item \\iisdist\privates\jhkim\temp\PublishOutput\app_offline.htm -ItemType file

Une chose intéressante est que si j'ajoute du contenu de fichier lors de la création du fichier app_offline.htm, il n'y a pas de problème. Cela peut être fait en ajoutant simplement le paramètre -value "test" comme suit :

new-item \\iisdist\privates\jhkim\temp\PublishOutput\app_offline.htm -ItemType file -value "test"

Pouvez-vous confirmer si vous voyez le même symptôme sur votre environnement de reproduction ?
Si tel est le cas, je pense que ce problème ne se produit que lorsque le fichier app_offline.htm vide est créé avec une méthode spéciale, telle que l'utilisation de la commande powershell new-item.

@gulbanana
Je ne peux pas reproduire ce problème avec la commande Copier. Pouvez-vous expliquer plus en détail la chose de votre repro? Ce serait formidable si vous pouviez trouver des étapes de reproduction avec lesquelles je peux reproduire le même problème sur ma machine de test.

Je peux confirmer que cela n'est pas lié au fait que le fichier app_offline.htm est vide sans exécuter ces commandes, car notre expérience a été de copier un fichier avec le contenu souhaité dans le dossier de déploiement. D'après mon expérience, je suppose que la deuxième commande pourrait provoquer un événement de modification de fichier si cela fonctionne effectivement. Peut-être qu'il crée le fichier et le met ensuite à jour avec son contenu. Quoi qu'il en soit, chaque processus lié à .net que j'ai utilisé pour créer simplement le fichier avec ou sans contenu ne parvient pas à déclencher l'arrêt du processus.

@shirhatti Une mise à jour ? Avez-vous pu confirmer que votre code doit utiliser l'indicateur "FILE_NOTIFY_CHANGE_CREATION" ?

@derekgreer Nous écoutons tous les indicateurs valides, sauf modifier le dernier accès et modifier les attributs.
FILE_NOTIFY_VALID_MASK & ~FILE_NOTIFY_CHANGE_LAST_ACCESS & ~FILE_NOTIFY_CHANGE_ATTRIBUTES

Alors oui, nous écoutons déjà FILE_NOTIFY_CHANGE_CREATION .

cc : @pan-wang

@shirhatti Ah, je comprends maintenant. Je ne savais pas que le drapeau couvrait la création de changement. Je suis curieux, avez-vous réussi à reproduire le problème ?

Ne pas réagir à app_offline.htm vide a été soi-disant corrigé : https://github.com/aspnet/IISIntegration/issues/174

@moozzyk @derekgreer Merci pour la confirmation. D'accord, j'ai également constaté que le problème n'était pas directement lié au contenu du fichier vide. Je vous mettrai à jour après avoir déterminé la cause première.

@jhkimnew je n'ai plus la configuration cassée exacte, mais je peux décrire les détails :

• IIS s'exécutant sur Windows Server 2008 r2, hébergeant une application principale asp.net utilisant ANCM
• le serveur de build est également 2008r2, sur le même domaine
• Le serveur IIS partage son répertoire physique de site Web à l'aide du partage Windows
• l'utilisateur du domaine (le compte du serveur de build) exécute un script powershell sur le serveur de build
  si ce script utilise la commande de copie de Windows pour copier dans un app_offline à partir d'un fichier existant dans un autre répertoire, le processus d'hébergement ne s'arrête pas. si le script utilise à la place "echo" (qui peut être le /bin/echo d'une installation mingw, je ne suis pas sûr), le processus d'hébergement s'arrête.

je soupçonne que le problème est lié précisément aux attributs de fichier qui sont ou ne sont pas mis à jour par ce type de copie à distance

@gulbanana Juste pour être clair, vous avez essayé avec la commande dos copy et non la commande power shell copy-item? Je ne pense pas avoir essayé la copie DOS habituelle, mais j'ai constaté que toutes les applications basées sur .net que j'utilisais ne fonctionnaient pas.

à moins que powershell n'ait un alias pour cela, c'était une copie dos

Dans mon cas, la copie PowerShell n'arrêtera pas le processus dotnet.exe, mais l'écho, qui est un alias de Out-Content, fonctionne. Je pense qu'il est peu probable qu'il s'agisse d'un problème .NET, mais plus sur la raison pour laquelle une copie réseau ne fonctionne pas

J'ai recherché s'il y avait un problème dans la notification de modification aspnetcore.dll (ANCM), mais je n'ai pas pu reproduire le problème lorsque j'ai essayé de supprimer app_offline.htm manuellement à l'aide de la cmdlet powershell ou de la commande DOS. Et j'ai trouvé un point manquant qui n'a pas été discuté ici.
C'est à propos de l'arrêt gracieux. Contrairement à HttpPlatformHandler", ANCM prend en charge l'arrêt progressif, ce qui signifie que lorsque app_offline.htm est déposé sur le répertoire racine, ANCM envoie un signal Crtrl-C/Break au processus principal et attend jusqu'à 10 secondes pour permettre l'arrêt progressif.
Les 10 secondes sont la valeur par défaut et les utilisateurs peuvent ajuster la valeur avec le shutdownTimeLimit des paramètres de configuration ANCM. Si le processus backend n'est pas arrêté dans le shutdownTimeLimit configuré, ANCM est supposé tuer le processus backend.

Tout en vérifiant comment la publication de MSDeploy est liée à l'arrêt gracieux de l'ANCM, j'ai finalement trouvé une étape de reproduction cohérente, qui consiste à augmenter le temps d'arrêt (5 secondes) et j'ai remarqué que MSDeploy réessaie seulement 2 fois par défaut et n'attend que 2 secondes et échoue finalement à publier car il n'attend pas le temps d'arrêt gracieux.

@vijayrkn
Après avoir mis 5 secondes de retard à la fois au démarrage et à la fin de l'application Web aspnetcore, j'ai pu reproduire la même erreur, qui a été signalée dans ce numéro, lors du deuxième essai de publication de l'application Web aspnetcore sur le serveur IIS local. J'ai également joint le profil de publication que j'ai utilisé ci-dessous.
Pourriez-vous expliquer pourquoi cela se produit et donner une directive correcte sur la façon de résoudre ce problème de publication ? Et veuillez créer un nouveau problème à ce sujet séparément afin que votre équipe suive ce problème pour améliorer l'expérience utilisateur.

... <Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> <PropertyGroup> <EnableMSDeployAppOffline>True</EnableMSDeployAppOffline> <WebPublishMethod>MSDeploy</WebPublishMethod> ...

MSDeploy tente de se déployer juste après la suppression de app_offline. S'il y a un retard dans l'arrêt du processus, le déploiement peut échouer.

Le nombre de tentatives pour le déploiement peut être défini à l'aide de cette propriété msbuild (https://github.com/aspnet/websdk/blob/dev/src/Publish/Microsoft.NET.Sdk.Publish.Targets/netstandard1.0/PublishTargets/Microsoft .NET.Sdk.Publish.MSDeploy.targets#L67)

par exemple, définir cette propriété sur 10 garantira que msdeploy réessaie 10 fois avec un délai d'une seconde entre les deux.
<RetryAttemptsForDeployment>10</RetryAttemptsForDeployment>

@vijayrkn

Merci pour l'information. Après avoir ajouté les deux lignes ci-dessous, je ne vois aucun problème avec le même environnement de reproduction.
<EnableMSDeployAppOffline>True</EnableMSDeployAppOffline> <RetryAttemptsForDeployment>10</RetryAttemptsForDeployment>

Ainsi, toute personne rencontrant le même problème devrait augmenter le nombre de tentatives de déploiement avec la valeur appropriée et réessayer si cela peut résoudre le problème.

REMARQUE : la raison pour laquelle j'ai ajouté EnableMSDeployAppOffline est que cela est désactivé par défaut lors de l'utilisation du serveur IIS local comme destination de publication d'une application Web aspnetcore. Donc, si vous n'êtes pas sûr que cela soit activé ou non dans votre environnement, il vous suffira d'ajouter également la ligne et c'est pourquoi je l'ai ajoutée ici pour votre information.

Juste pour s'assurer que le problème d'origine ne soit pas perdu en raison des discussions les plus récentes, le problème rencontré par mon équipe n'est certainement pas un problème de timing. Nous avons testé la création manuelle du fichier app_offline.htm via Powershell, Fake et un explorateur de fichiers basé sur .Net nommé "Nomad" et le processus ne s'arrête pas, peu importe le temps que vous attendez. La création du fichier via l'explorateur de fichiers, un fichier de commandes DOS ou un script bash (c'est-à-dire des processus non basés sur une bibliothèque .Net) entraîne l'arrêt du processus en 1 à 2 secondes.

Cela semblerait indiquer :

1. Le problème n'est pas lié au réseau (tous les tests ont été effectués sur un partage de fichiers distant)
2. Ce n'est pas un problème d'arrêt / de synchronisation gracieux

Le fait que 3 méthodes non .Net de création du fichier app_offline.htm arrêtent le processus de manière fiable et rapide et que 3 méthodes basées sur .Net-library de création du fichier n'entraînent jamais l'arrêt du processus dans nos tests semble être un très , vraiment gros indicateur pour moi.

@derekgreer
Je ne peux pas reproduire le problème même avec "Nomad".
Voici ce que j'ai fait sur ma machine Windows 10 (amd64).

1. Installer IIS
2. Installer Visual Studio 2017
3. Créez une application Web AspnetCore et déployez-la sur le serveur IIS local avec MSDeploy
4. Installez Nomad v3.2.0.2890 (http://www.nomad-net.info/downloads)
5. Envoyer une demande à l'application Web
6. Ouvrez le Gestionnaire des tâches et confirmez que le processus dotnet.exe est en cours d'exécution
7. Ouvrez Nomad et créez un nouveau fichier nommé app_offline.htm dans le répertoire racine de l'application Web
8. Consultez le gestionnaire de tâches et vérifiez que le processus dotnet.exe a disparu lorsque le fichier app_offline.htm est créé

Pourriez-vous donner les étapes de reproduction exactes afin que je puisse suivre pour reproduire le problème ?

Mis à part le fait que notre application .Net Core est en fait une application console .Net 4.5.2 standard créée dans VS 2015 qui fait référence aux assemblages ASP.Net Core, je ne vois aucune différence. Le projet a environ un an maintenant et a été configuré de cette façon à l'époque en raison de limitations liées au référencement des types de projet de modèle de base à partir des types de projet de modèle de framework .Net et de divers types de prise en charge de la bibliothèque de test pour le noyau .Net.

Nous avons identifié quelques problèmes : 1) la suppression du fichier app_offline.htm (à l'aide d'un outil) ne déclenchait parfois qu'une notification de changement de propriété de fichier qui était filtrée par l'ANCM. 2) ANCM peut ne pas lire app_offline.htm car ce dernier était détenu par l'outil de copie de fichiers. 3) l'arrêt gracieux a causé un retard dans la fin du processus backend.
Nous aborderons les deux premiers problèmes dans la prochaine version. Dans le cas d'un arrêt progressif, l'utilisateur doit réessayer.

ça a l'air bien. mon cas ne concernait certainement pas un délai d'arrêt gracieux - quand il s'arrête, il s'arrête immédiatement.

Une mise à jour sur ce problème ?
Obtention lors de la tentative de déploiement d'une application ASP.NET Core 1.1 sur un emplacement Azure Web App à l'aide de VSTS

• J'ai le MSDEPLOY_RENAME_LOCKED_FILES=1 défini dans les paramètres de l'application
• La tâche Gérer App Service est configurée pour mettre l'application hors ligne
• La tâche Déployer App Service _était_ configurée pour mettre l'application hors ligne, mais cela n'a pas fonctionné non plus

Le problème principal est que la DLL est en cours d'utilisation :

@ChuckkNorris , veuillez consulter https://github.com/Microsoft/vsts-tasks/issues/1607 pour les dernières informations à ce sujet.

@davidebbo Merci pour votre réponse, David. J'ai vu ce fil et c'est là que j'ai découvert de nombreuses solutions de contournement que j'ai essayées.

Comme ce problème est toujours ouvert et que l'erreur est toujours répandue, j'espérais qu'il pourrait y avoir un correctif bientôt, pas une autre solution de contournement. Ce problème est ouvert depuis plus de deux ans maintenant après tout.

@ChuckkNorris bien que le symptôme soit le même, ce n'est pas le même problème :

• Problème d'origine lié à la casse de app_offline.htm , ce qui l'a complètement ignoré. C'est réglé depuis un moment.
• Ce nouveau problème a commencé il y a à peine une semaine environ et se produit parce que Core prend plus de temps à s'arrêter lorsque app_offline.htm est créé, et msdeploy par défaut n'attend pas assez longtemps. La solution consiste à augmenter le nombre de tentatives.

Je viens de mettre à jour VS 2017 vers 15.3 et d'installer le SDK .NET core 2.0. Création d'une application MVC simple dans VS - elle ciblait netcoreapp1.1. J'ai publié sur Azure, et tout allait bien. J'ai mis à niveau vers newcoreapp2.0, puis mis à niveau tous les packages nuget vers 2.0 (Microsoft.AspNetCore, Microsoft.AspNetCore.Mvc, etc.)

Lorsque j'essaie de publier sur Azure (c'est-à-dire écraser le 1.1), j'obtiens ceci

Error : Web deployment task failed. (Web Deploy cannot modify the file 'Microsoft.ApplicationInsights.AspNetCore.dll' on the destination because it is locked by an external process. In order to allow the publish operation to succeed, you may need to either restart your application to release the lock, or use the AppOffline rule handler for .Net applications on your next publish attempt. Learn more at: http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_FILE_IN_USE.)

@DaveSlinn , veuillez consulter https://github.com/Azure/app-service-announcements/issues/24

J'ai dû désactiver MvcViewComplication pour déployer mes applications 2.0 via git et éviter les problèmes d'utilisation de fichiers.

https://github.com/Microsoft/vsts-tasks/issues/5259
https://github.com/Microsoft/vsts-tasks/issues/1607#issuecomment -349115532
@davidebbo , Pouvons-nous conclure sur ce problème ?
Malgré l'ajout d'un assistant de nouvelle tentative pour le déploiement Web, ce problème persiste.

Je voulais juste souligner l'évidence, que cela affecte également la publication FTP.

@jeremycook FTP est un peu différent, car il n'a pas d'automatisation pour utiliser App_Offline. Vous devrez créer manuellement ce fichier pour que le processus s'arrête, après quoi vous pourrez copier des fichiers.

@davidebbo assez juste, mais il semble que si je publie via FTP en utilisant la fonction de publication de Visual Studio, cela devrait fonctionner. Peut-être que je poste au mauvais endroit ?

@jeremycook franchement, je ne sais pas ce que fait VS lors du déploiement FTP. Peut-être que d'autres peuvent briller, mais cela ressemble plus à une question VS qu'à ASP.NET.

Bien que pour isoler, il serait intéressant de tester si le déploiement réussit si vous créez manuellement App_Offline.html, puis publiez via FTP à partir de VS.

@vijayrkn Pouvez-vous commenter le comportement de VS lors du déploiement FTP ?

La publication FTP de VS vers le service App ne prend pas en charge App_Offline.

@vijayrkn ok, donc à toutes fins pratiques, nous pouvons dire que le déploiement de .NET Core via FTP n'est pas pris en charge, sauf si l'utilisateur arrête explicitement le site avant le déploiement. Droit?

@davidebbo - Oui, c'est exact.

Problème rencontré lors du déploiement de l'application Web asp.net core 2.0 sur IIS à partir de la version VSTS à l'aide du modèle de déploiement Web IIS. La suppression échoue en raison du fichier en cours d'utilisation. L'option hors ligne de l'application est activée.

@davidebbo @vijayrkn @shirhatti tout cela est un peu déprimant. Est-il prévu de faire fonctionner FTP/XCOPY ? Un nouveau problème devrait-il être ouvert qui se concentre sur le déploiement des méthodes à l'ancienne via FTP/XCOPY/ROBOCOPY/etc. ?

je suis en retard à cette fête mais voici quelques éléments que je veux signaler :
VS 2017 Entreprise
asp.net 4.6.xx
le serveur est IIS 8.5 sur le serveur 2012 R2
Les dll de types de serveur sql sont verrouillées et le verrouillage est tel qu'un développeur différent publie avec msdeploy, il obtient une erreur et le site Web est maintenant interrompu car seule une partie du déploiement a été exécutée.

les dll de types sql sont verrouillés dans le dossier bin de l'application et uniquement eux.
renommer les fichiers dll et ensuite je peux publier.
l'emballage des types sql a un code canné pour charger les dll non gérées.
semble que cela devrait être changé pour ne pas les verrouiller. si cela peut être fait.

J'ai vu des gens parler de façons de redémarrer le site ou de le mettre hors ligne, mais je n'ai pas trouvé de paramètre dans msdeploy pour cela. le xml que j'ai vu n'est pas dans mes fichiers.

de meilleurs conseils devraient être ajoutés au package sql types que Microsoft publie.

Message sur ce problème car il semble plus directement lié au mien. J'ai également suivi le problème ci-dessous sur le même sujet bien que ce soit pour VSTS. Je publie directement depuis Visual Studio.

https://github.com/Microsoft/vsts-tasks/issues/5259#issuecomment -350940342

Cela a été un problème d'activation et de désactivation pour moi, mais il est récemment revenu en force et sur l'un de mes sites de service d'application, j'obtiens cette erreur sur presque toutes les tentatives de publication. Ce site est hébergé sur un service de niveau "basique", donc je n'ai pas d'emplacements que j'utilise sur d'autres applications pour contourner ce problème.

Ceci est pour une application .net core 2 mvc.

Une réflexion : certains fichiers qui font partie d'une application Web ne changent pas à chaque publication (comme les types sql)
mais le déploiement de ms essaie de les remplacer à chaque déploiement.
il semble qu'une sorte de vérification devrait se produire pour ne pas recopier un fichier qui n'a pas changé et cela rendrait la mise à jour plus petite et plus rapide et moins besoin de gâcher le verrouillage du fichier.
avantages multiples si cela peut être fait.

l'autre chose est de mieux identifier ce qui verrouille le fichier et pourquoi et comment l'annuler.
et obtenez cela dans le cadre du pipeline de déploiement standard.

@figuerres Je voulais régler ce problème depuis quelques mois maintenant. Les problèmes de verrouillage sont normalement évités grâce au cliché instantané, mais en chargeant ces DLL natives à partir de ~/bin , un problème de verrouillage est créé. J'ai une solution potentielle, mais je ne sais pas si c'est une solution complètement sûre: https://stackoverflow.com/questions/47796553/is-it-safe-to-manually-copy-native-dlls-to- un répertoire de copie fantôme

Je suis d'accord que la documentation du package NuGet devrait fournir une meilleure méthode, qui ne cause pas de problèmes de verrouillage.

@figuerres FYI, j'ai implémenté ce qui précède, voir la question Stack Overflow pour le code.

Tuez dotnet.exe dans le Gestionnaire des tâches

Quel est le statut ici ? 3 ans plus tard, toujours pas réparé. Je dois accéder manuellement au serveur et arrêter le site Web.

3 années? Le problème a été signalé en août 2017. Off par 1 comme whoa.
Le lundi 23 avril 2018 à 20h56 Oliver Janik [email protected]
a écrit:

Quel est le statut ici ? 3 ans plus tard, toujours pas réparé. je dois y aller manuellement
au serveur et arrêter le site Web.

—
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/aspnet/Home/issues/694#issuecomment-383768450 , ou muet
le fil
https://github.com/notifications/unsubscribe-auth/AAXhfrhOTvZn2qb4kU-Y1Kg9I-IQKD9yks5trnhXgaJpZM4FJp_R
.

Le tout premier post dit "pekkah a ouvert ce numéro le 23 juin 2015"

Tu as raison. Ma faute. Je n'ai vu que le dernier horodatage dans la chaîne de messagerie.
Le lundi 23 avril 2018 à 21h06 Oliver Janik [email protected]
a écrit:

Le tout premier post dit "pekkah a commenté le 23 juin 2015"

—
Vous recevez ceci parce que vous avez commenté.

Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/aspnet/Home/issues/694#issuecomment-383769982 , ou muet
le fil
https://github.com/notifications/unsubscribe-auth/AAXhfgwYG-jLjnoJF7MCMtzbbfxSZkt2ks5trnqXgaJpZM4FJp_R
.

Fermeture car c'est aussi vieux que la saleté 😄

@Eilon Désolé, mais pourquoi cela a-t-il été fermé ? C'est toujours pas résolu ?

Fermeture car c'est aussi vieux que la saleté 😄

Mais c'est toujours un problème ..? (même sur les déploiements sans azur)

Création d'un nouveau numéro (#3719) pour augmenter la visibilité.