Aspnetcore: Die Bereitstellung schlägt aufgrund einer verwendeten Datei fehl

Ich habe ein ähnliches Problem mit der Sperrung von IIS-Dateien auf Azure-VMs festgestellt, das die Bereitstellung von WebDeploy verhinderte. Meine Problemumgehung besteht darin, drei WebDeploy-Befehle auszugeben: Stoppen Sie den AppPool, stellen Sie ihn bereit, starten Sie den AppPool neu. Siehe mein Skript ; und wenn Sie die Möglichkeit haben, drei WebDeploy-Befehle auszuführen, können Sie möglicherweise etwas Ähnliches mit Azure Apps tun.

Bekomme dieses Problem in Beta6.

Hier gilt das gleiche! Es führt dazu, dass mein Visual Studio 2015 tatsächlich einfriert - wenn ich meine vNext-App veröffentliche (sowohl Beta6 als auch Beta7, glaube ich).

Verwenden Sie für die Bereitstellung die von Microsoft bereitgestellten Skripts ? Wenn dies der Fall ist, können Sie einfach eine Zeile in PublishAspNet5Website.ps1 hinzufügen, um die Web-App neu zu starten:

Restart-AzureWebsite -Name $websiteName

Ich habe meine Build-Skriptänderungen in diesem Beitrag beschrieben: Resolve an ASP.NET 5 Deployment Issue to Azure Web App Slot

@brandonmartinez , Das Neustarten einer Website hilft nicht, da eine Produktionswebsite weiterhin Anfragen erhält, wodurch die Dateien erneut gesperrt werden. Die derzeit einzig zuverlässige Möglichkeit, sowohl IIS- als auch Azure-Websites zu aktualisieren, besteht darin, den Anwendungspool der Website herunterzufahren, dann die Dateien zu aktualisieren und dann die Website neu zu starten. Folgen Sie einfach dem Link von @GuardRex für weitere Details.

Wir sollten uns jedoch nicht mit benutzerdefinierten Bereitstellungsskripts herumschlagen müssen, wenn wir unter Standardbedingungen mit VS2015 arbeiten.

Hoffentlich ist die neue HttpPlatformHandler-Infrastruktur (die keine AspNet.Loader.dll mehr benötigt) etwas nachsichtiger, aber ich halte hier nicht den Atem an. Wir werden wahrscheinlich eine weitere gesperrte .dll bekommen.

@rubenprins Das ist die Problemumgehung, die ich auch über die Azure SDK-Tools in VS verwende.

Es gibt PS-Befehle, um dies zu tun, wenn Sie PS-Zugriff auf die VM erhalten können. https://github.com/GuardRex/net5-iis-ps-publish/blob/7623122dbfdc55a7c53c8edd2e97443e0eea22c9/net5-iis-ps-publish.ps1#L389 -L396

aspnet/vsweb-publish ist auch sehr interessant; Es sieht jedoch so aus, als würde es offline-template.html verwenden, und ich dachte, es wurde entdeckt, dass diese Methode das DLL-Sperrproblem nicht verhindern würde ... nur das Stoppen des AppPools, das Bereitstellen und Neustarten des AppPools war eine stabile, Arbeitsweise.

Wir sollten uns nicht mit benutzerdefinierten Bereitstellungsskripts herumschlagen müssen, wenn wir unter Standardbedingungen mit VS2015 arbeiten

Eine Sache ist mir jedoch aufgefallen: Die Möglichkeit, „Im Dateisystem veröffentlichen“ zu verwenden und ein Skript direkt nach der Veröffentlichung einzubinden, das MSDeploy-Bits enthält, hat eine sehr einfache und nützliche Bereitstellungsgeschichte für mehrere VMs ermöglicht. Da das Skript sequentiell ausgeführt wird, geht es einfach von VM zu VM auf der ganzen Linie. Macht eine schöne Kaffeepause. :Lächeln:

Ich habe eine Frage unter Erste Schritte beim Konfigurieren eines mit dem Internet verbundenen Lastenausgleichs mithilfe von Azure Resource Manager beim Azure Resource Manager-Team, in der Sie fragen, wie Sie dem Lastenausgleich mitteilen, dass er während der Bereitstellung vorübergehend keinen Datenverkehr mehr an die VM senden soll.

Wie auch immer ... um auf das Thema zurückzukommen, das @pekkah angesprochen hat. Da wir wissen, dass PS-Befehle funktionieren, suchen Sie nach Optionen, um sie in einem VSO-Build auszuführen:

Microsoft/vso-agent-tasks
Führen Sie ein Skript in Ihrem Build-Prozess aus
Ausführen von vorgefertigten Skripts in Team Foundation Service (Visual Studio Online) für den Azure Continuous Deployment-Buildprozess
Neue Buildautomatisierungsfeatures in Visual Studio Online

... ja ... so etwas sollte für Sie funktionieren.

Selbes Problem hier...

Warte immer noch auf eine offizielle Lösung

Bruno

Dies wird durch https://github.com/aspnet/IISIntegration/issues/81 behoben.

@moozzyk , Dieses Problem behebt die Bereitstellung nur über dedizierte Tools wie msdeploy. Die Bereitstellung von Xcopy/Dateisynchronisierung wäre immer noch nicht möglich, was auch viele CI-Szenarien blockiert/hindert, die nur mit ASP.NET v1-4 funktionieren.

Das Problem besteht weiterhin in ASP.NET Core 1.0 RC2 mit Visual Studio 2015.2 MSDeploy auf IIS 8 unter Windows 2012 R2 mit den neuesten Tools für Server. Das Beenden des dotnet.exe-Prozesses oder das Recycling des Anwendungspools löst das Problem. Aber das erfordert Remote-Desktop-Zugriff auf den Server und ist nicht gerade ein reibungsloser Prozess.

@dg9ngf - Dies ist jetzt ein Fehler in web.deploy. Sie haben die app_offline.htm-Funktionalität für Azure hinzugefügt, sie ist jedoch standardmäßig deaktiviert, wenn Sie sie lokal bereitstellen. Versuchen Sie, Ihr Veröffentlichungsprofil zu öffnen (PublishProfiles->*.pubxml) und ändern Sie Folgendes:

<EnableMSDeployAppOffline>False</EnableMSDeployAppOffline>

zu

<EnableMSDeployAppOffline>True</EnableMSDeployAppOffline>

Wenn dies nicht funktioniert, fragen Sie @vijayrkn

Wenn Sie VS-Tools zum Veröffentlichen mit einem msdeploy-Profil verwenden, wird diese Eigenschaft automatisch zu Ihrer pubxml hinzugefügt.

<EnableMSDeployAppOffline>True</EnableMSDeployAppOffline>

In Ihrem Ausgabefenster sollten Sie einen ähnlichen msdeploy-Befehl sehen.

"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 im Befehl sollte sich um das Hinzufügen von appOffline während der Bereitstellung kümmern.

Wenn benutzerdefinierte appOffline-Inhalte benötigt werden, können Sie diese Eigenschaft in pubxml festlegen.

<AppOfflineTemplate>Path to app offline</AppOfflineTemplate>

Diese Eigenschaft war in der von Visual Studio erstellten .pubxml-Datei _nicht_ vorhanden. Also habe ich es hinzugefügt, aber es hat nichts geändert. Das Argument -e nablerule:AppOffline erscheint _nicht_ im Ausgabefenster.

Können Sie die im Ausgabefenster angezeigte msdeploy-Befehlszeile freigeben?

Können Sie auch bestätigen, dass das pubxml WebPublishMethod als „MSDeploy“ hat.
<WebPublishMethod>MSDeploy</WebPublishMethod>

Nein, die Datei hat stattdessen Folgendes: <WebPublishMethod>FileSystem</WebPublishMethod>

Hier ist die Befehlszeile aus dem Ausgabefenster: 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]

Ich verwende die Aufgabe „Azure Web App Deployment“ in VSTS, wie in diesem Blogbeitrag beschrieben: http://donovanbrown.com/post/2016/05/30/DevOps-for-ASPNET-Core-RC2

Gibt es eine Möglichkeit, <EnableMSDeployAppOffline>True</EnableMSDeployAppOffline> mit dieser Methode anzugeben?

Hallo, ich hatte das gleiche Problem bei Azure, ich habe es auf diese Weise gelöst https://github.com/davidebbo/WAWSDeploy/issues/14

@dg9ngf In der aktuellen Version des Powershell-Skripts unterstützen wir appOffline nur für WebPublishMethod – „MSDeploy“.

AppOffline-Unterstützung für Dateisystemveröffentlichungen wird in der nächsten Version verfügbar sein.

@bojingo Ich bin in der gleichen Situation. Hast du das herausgefunden?

@davenewza : Wenn Sie diesen Blogbeitrag erneut besuchen, finden Sie die Lösung in den Kommentaren.
http://donovanbrown.com/post/2016/05/30/DevOps-for-ASPNET-Core-RC2

Grundsätzlich müssen Sie VSTS-Schritte hinzufügen, um die Site zu stoppen/starten. Sehr weit von einer idealen Lösung entfernt (eigentlich ziemlich lahm), zumal ich keine Bereitstellungsslots verwende, aber es funktioniert in Ordnung für unsere Entwicklungs-/Testumgebung.

Es gibt eine neue Vorschau-ARM-Version der VSTS-Aufgabe zur Bereitstellung von Web-Apps, die auf msdeploy basiert und verspricht, sie zu beheben, aber ich hatte kein Glück damit, weil ich den Client brauchte, um einen Dienstprinzipal für das Abonnement zu erstellen, und so weiter war ein Ärger. Vielleicht kannst du das zum Laufen bringen:
https://github.com/Microsoft/vsts-tasks/tree/master/Tasks/AzureRmWebAppDeployment

@vijayrkn Das Dialogfeld Web veröffentlichen in VS2015 enthält keine Option zum Festlegen von msdeploy – gibt nur die Optionen für WebPublishMethod=FileSystem an.

Können Sie bitte eine .pubxml-Beispieldatei für WebPublishMethod=msdeploy bereitstellen?

@tomfanning Für eine ASP.NET Core-Konsolenanwendung ist die einzige derzeit verfügbare Veröffentlichungsoption das Dateisystem. Versuchen Sie, eine Konsolenanwendung zu veröffentlichen? Für eine Webanwendung sollten alle diese 4 Optionen verfügbar sein (webdeploy, web deploy package, file system und ftp).
Beispiel für webdeploy pubxml – https://github.com/dotnetpublish/AspNetCoreBlogList/tree/master/src/AspNetCoreBlogList/Properties/PublishProfiles

Wenn es sich um eine Web-App handelt und Sie nur die Option zum Veröffentlichen des Dateisystems sehen, können Sie das xproj überprüfen, um zu sehen, ob es dies importiert?
<Import Project="$(VSToolsPath)\DotNet.Web\Microsoft.DotNet.Web.targets" Condition="'$(VSToolsPath)' != ''" />

@bojingo Ich konnte den Dienstprinzipal einrichten, es gibt mehrere Tutorials im Internet. Ich habe die Links hier nicht, aber ich kann sie suchen, wenn Sie brauchen. Jetzt ist mein Problem, dass die Aufgabe eine parameters.xml-Datei erfordert, die nicht auf ASP Net Core veröffentlicht wird ... :(

Ich habe TFS 2015 On-Prem und das bleibt ein unglaublich ärgerliches Problem.

Ich beschäftige mich auch mit diesem Problem...

Meine Lösung bestand darin, meinen Staging-Slot, den ich bereitstelle, anzuhalten und dann darin zu veröffentlichen (automatischer Austausch funktioniert). Neustart, dann Bereitstellung hat nicht funktioniert (Bereitstellung mit VSTS)

Ich verwende Octopus mit Azure-Web-Apps, die keine Option zum Staging von Slots bieten. Das Überprüfen der folgenden Optionen scheint jedoch funktioniert zu haben:

• Bringen Sie die App-Domain sicher herunter, indem Sie die Datei app_offline.html im Stammverzeichnis leer lassen.
• Entfernen Sie Dateien auf dem Ziel, die nicht Teil der Bereitstellung sind

Ich verwende Visual Studio 2015 Update 3, um eine asp.net Core 1.1/.net Framework 4.5.2-Site in IIS zu veröffentlichen. Es fällt App_Offline.htm herunter, was die Site nicht herunterfährt. Wenn ich es auf dem Server in app_offline.htm umbenenne, wird die Site heruntergefahren.

Dementsprechend sollte app_offline.htm Groß- und Kleinschreibung nicht beachten.

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

Deployer lädt app_offline.htm hoch (Groß-/Kleinschreibung wird nicht beachtet)

Ich habe gerade erneut veröffentlicht und sehe, dass App_Offline.htm ausgefallen ist, und meine Website ist nicht ausgefallen, und ich erhalte die Fehlermeldung „Datei wird verwendet“. Wenn ich es auf app_offline.htm ändere, geht meine Website aus und ich kann ohne Fehler veröffentlichen.

Ich hoste auf einem gemeinsamen UNC-Pfad - ich weiß nicht, ob das einen Unterschied macht.

@Tratcher - wissen Sie, warum die Großschreibung von App_Offline.htm hier einen Unterschied machen würde?

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

Ich konnte dieses Problem lösen, indem ich eine Azure-App-Einstellung von hinzufügte

MSDEPLOY_RENAME_LOCKED_FILES = 1

... wie hier beschrieben:
https://github.com/Microsoft/vsts-tasks/issues/1607#issuecomment -260946957

YMMV

@BenBarreth Gibt es etwas Ähnliches, das für Nicht-Azure gilt?

nicht dass ich wüsste sorry @jdshkolnik

Es scheint, dass es Probleme mit MSDEPLOY_RENAME_LOCKED_FILES = 1 gibt. Es hilft bei der erfolgreichen Bereitstellung, kann aber bedeuten, dass die neuen DLLs zur Laufzeit nicht abgeholt werden:
https://github.com/Azure/azure-webjobs-sdk-script/issues/569#issuecomment -264490818

Das scheint mir keine angemessene "Lösung" zu sein. Es verbirgt nur den Bereitstellungsfehler.

True Fix kann möglicherweise in diesem Problem beschrieben werden:
https://github.com/Azure/azure-webjobs-sdk-script/issues/1023

Suche wirklich nach einer Lösung dafür. Es sah so aus, als ob die RM-Webbereitstellungs-VSTS-Aufgabe dies mit der ausgewählten Option „Take App Offline“ erledigt hätte, aber seit diesem Wochenende erhalten wir ständig die Fehler. Wir sind wieder dazu übergegangen, den Bereitstellungsslot zu stoppen, bereitzustellen und neu zu starten.

Auch bei uns ist dieses Problem am Freitag letzter Woche aufgetreten und hat uns seitdem daran gehindert, bereitzustellen ...

Hier gilt das gleiche. Sieht so aus, als ob es nur Websites mit Always On = true betrifft, aber das ist nicht sicher.

Ich habe dieses Problem immer noch, selbst wenn ich in meiner Konfiguration MSDEPLOY_RENAME_LOCKED_FILES = 1 setze. Es ist fast unmöglich, den Build auf meinem Server jetzt zu aktualisieren. Das hat erst vor ein paar Tagen angefangen.

Bei mir tritt seit dieser Woche das gleiche Problem auf. Bis zu dieser Woche hat die Bereitstellung eines AzureRM-App-Diensts in VSTS mit der Einstellung App offline nehmen = wahr durchgängig funktioniert. Jetzt scheint diese Einstellung entweder ignoriert zu werden oder der Dienst wird nicht rechtzeitig offline genommen. Ich muss den App-Dienst manuell neu starten oder stoppen / starten, während die Freigabe dafür ausgeführt wird, um ihn zu überschreiten.

Dasselbe Problem hier. AzureRm hat monatelang gearbeitet und plötzlich aufgehört. Meine letzte Bereitstellung war vor zwei Wochen am 5.12. und jetzt am 20.12. generiert sie die Error_File_In_Use. Sehr genervt wieder auf manuellen Start/Stopp zurückgreifen zu müssen.

Hier ist unsere Problemumgehung in Powershell, die wir derzeit als Teil unseres CI/Build-Prozesses verwenden. Besonderer Dank geht an @appveyor Jungs für die Hilfe dabei:

$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"

Dabei wird die Kudu-REST-API verwendet, um HTTP PUT die korrekt formatierte app_offline.htm -Datei an Ort und Stelle zu platzieren. Wir haben WebDeploy so konfiguriert, dass alle Dateien entfernt werden, die nicht in der Bereitstellung enthalten sind, sodass die Datei automatisch als Teil der Bereitstellung entfernt wird. Möglicherweise müssen Sie den Schritt mit einem HTTP DELETE wiederholen, um die Datei nach Abschluss der Bereitstellung zu entfernen, wenn Sie diesen Modus nicht verwenden.

Das Hinzufügen eines Trackyon Stop vor der AzureRM-Aufgabe und einer Trackyon Start-Aufgabe danach funktioniert gut für mich. Dies sollte mit TakeAppOffline = true nicht erforderlich sein, aber es funktioniert und vermeidet manuelles oder Skripting. Fügen Sie einfach die Aufgabe zur Release-Definition hinzu. Die Trackyon Steps sind einfach aufzubauen

Am 21. Dezember 2016 um 00:10 Uhr schrieb Chad T < [email protected] [email protected] >:

Hier ist unsere Problemumgehung in Powershell, die wir derzeit als Teil unseres CI/Build-Prozesses verwenden. Besonderer Dank geht an @appveyor https://github.com/appveyor Jungs für die Hilfe dabei:

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

Dies nutzt die Kudu-REST-API https://github.com/projectkudu/kudu/wiki/REST-API , um die korrekt formatierte app_offline.htm-Datei per HTTP PUT zu platzieren. Wir haben WebDeploy so konfiguriert, dass alle Dateien entfernt werden, die nicht in der Bereitstellung enthalten sind, sodass die Datei automatisch als Teil der Bereitstellung entfernt wird. Möglicherweise müssen Sie den Schritt mit HTTP DELETE wiederholen, um die Datei nach Abschluss der Bereitstellung zu entfernen, wenn Sie diesen Modus nicht verwenden.

-
Sie erhalten dies, weil Sie kommentiert haben.
Antworten Sie direkt auf diese E-Mail, zeigen Sie sie auf GitHub https://github.com/aspnet/Home/issues/694#issuecomment-268436959 an oder schalten Sie den Thread stumm https://github.com/notifications/unsubscribe-auth/AID9WoUdbuBnFoXR2K5o8AiUtv8nE9dRks5rKLTcgaJpZM4FJp_R .

Diese Nachricht ist nicht öffentlich und kann privilegierte, geschützte oder vertrauliche Informationen enthalten. Sollten Sie es irrtümlich erhalten haben, benachrichtigen Sie bitte umgehend den Absender und löschen Sie alle Kopien des Originals. Jede andere Verwendung der E-Mail durch Sie ist untersagt. Jegliches unbefugte Kopieren, Speichern, Verwenden oder Weitergeben des Inhalts dieser Nachricht ist nicht gestattet und kann rechtswidrig sein. Wo dies nach lokalem Recht zulässig ist, kann die elektronische Kommunikation mit Lithero von unseren Systemen zum Zwecke der Informationssicherheit und der Bewertung der internen Einhaltung der Lithero-Richtlinien und geltenden Gesetze überwacht und gescannt werden.

/ cc @davidebbo

Versuchen Sie, MSDEPLOY_RENAME_LOCKED_FILES=1 in den Azure-App-Einstellungen für Ihre App festzulegen.

@davidebbo das scheint die Dinge nicht zu lösen.

Ich nehme an, das hängt mit einer Änderung auf der Azure-Seite des Zauns zusammen? Bei vielen Leuten (insbesondere im Aspnet-Slack-Kanal) ist dieses Problem gleichzeitig aufgetreten.

Eine Änderung in Azure würde nicht erklären, warum wir dies lokal mit TFS sehen. Könnte es der Agent sein?

Wir sehen das gleiche Problem. App_Offline.htm wird nicht abgeholt. Seltsamerweise funktioniert es gut, wenn wir von VS aus bereitstellen.

Seltsamerweise funktioniert es bei mir nicht von VS aus, wie hier beschrieben: #1883

Mein Team stößt auch auf dieses Problem, fast jedes Mal, wenn die Bereitstellung aufgrund einer gesperrten Datei fehlschlägt. Muss jede App in Azure neu starten und die Bereitstellung erneut ausführen. Wir verwenden Octopus Deploy.

Mein Team ist heute Morgen auf dieses Problem gestoßen. Irgendwelche Kommentare vom Microsoft-Team? Die Release-Pipeline ist entscheidend für unsere Produktivität, sie verhindert Releases an Produktionsstandorte. Danke!

@bmoscao - app_offline.html unterscheidet zwischen Groß- und Kleinschreibung.

Dieses Problem ist bei mir auch auf Azure aufgetreten. Nichts, was ich an meinem Ende getan habe, um es zu verursachen.

Ich habe dieses Problem auch. Die Sache ist, dass EnableMSDeployAppOffline auf true gesetzt ist - und die Projektausgabe zeigt -enablerule:AppOffline als Teil des Befehls, der von Visual Studio ausgeführt wird. Ich bin mir nicht sicher, was ich tun soll ... Ich habe dieses Problem erst seit kurzem.

Unsere Problemumgehung bestand darin, den App-Pool zu stoppen, bereitzustellen und dann den App-Pool neu zu starten. Wir verwenden Release Manager und das Inline-Powershell- Plugin, um dies zu erreichen.

Stoppen:

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

Start:

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

Ich würde mich auf jeden Fall über einige Beiträge von Microsoft freuen, dies funktionierte früher hervorragend, wenn nur die appOffline-Regel im RM-Azure-Bereitstellungsschritt aktiviert wurde.

@davidebbo Wir verwenden ASP.NET Core, VSTS Release Manager und AzureRmWebApp mit Slots.

@davidebbo danke! Für mich geht das ;)

Das passiert uns auch - msdeploy to Azure. Ich bin froh zu sehen, dass es für eine Reihe von Menschen gleichzeitig auf mysteriöse Weise begonnen hat – und es sind nicht nur wir – aber insgesamt nicht sehr beruhigend!

Ich glaube nicht, dass die Leute bei MS dafür eine Bestätigung brauchen, wahrscheinlich wissen sie gut, wo das Problem liegt. Jedenfalls auch hier. Bereitstellen von VSTS, wurde Anfang Dezember eingestellt. Im Moment verwende ich die Trackyon-Aufgabe zum Stoppen / Starten.

Beim Durchgehen dieses Threads ist für jeden Eintrag nicht immer klar:

1. ob sich das Problem auf Azure App Service oder ein anderes Hosting bezieht
2. ob die Leute versucht haben, die app_offline-Schreibweise wie oben beschrieben zu ändern. Scheint, dass mehrere Leute dort Erfolge gemeldet haben.
3. ob MSDEPLOY_RENAME_LOCKED_FILES versucht wurde. Auch hier scheinen mehrere Leute erfolgreich gewesen zu sein.

Wenn Sie auf dieses Problem stoßen, machen Sie bitte sehr deutlich, was Ihr Szenario ist und was Sie versucht haben, damit wir es verstehen können. Danke!

@davidebbo

Ich erhalte die Meldung ERROR_FILE_IN_USE, wenn ich versuche, mithilfe von Visual Studio/MSBuild bereitzustellen. Die Aufgabe erstellt eine App_Offline.htm-Datei auf dem Server, aber die App wird nicht heruntergefahren.

Durch das Erstellen einer app_offline.htm-Datei mit Web Deploy wird die App heruntergefahren.

Dies ist mein Setup:

• Server: IIS 8, .NET Core Windows Server Hosting 1.1.0 und Webbereitstellung 3.6
• Mein Computer: Visual Studio 2015 Update 3 und .NET Core 1.0.1 Tools Preview 2
• Profil veröffentlichen:

<?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

Ich habe diesen Fehler in einem ähnlichen Thread kommentiert und musste meine Azure-Web-App jedes Mal stoppen und neu starten, wenn ich sie erneut bereitstellen wollte (nur in der Entwicklungsumgebung). Musste das vor dieser Woche noch nie machen. Ich habe mich entschieden, im Grunde eine Visual Studio 2015 .net Core-Web-App aus der Vorlage ohne Änderungen zu erstellen.

Ich habe die Web-App auf dem lokalen Host ausgeführt, überhaupt kein Problem.
Ich veröffentliche die neue App problemlos in meinem Azure Web App Service-Plan, und der Browser hat die Website sofort ohne Probleme aufgerufen.
Ich habe Azure Dashboard überprüft und überhaupt keine Probleme.

Ich habe dann die Web-App erneut veröffentlicht, ohne etwas zu ändern - Code oder Einstellungen, und der folgende Fehler tritt auf.

Von da an muss ich die Web-App stoppen, in Azure veröffentlichen und dann die Web-App starten. Das ist mir noch nie passiert. Dies ist eine sehr einfache Bereitstellung der Microsoft-Vorlage.

Ich habe diesen gesamten Prozess aufgezeichnet und dieses Feedback innerhalb des Microsoft 2015 VS-Feedbacksystems gesendet. Ich hoffe, Sie können diese Aufnahme finden. Oder ich könnte es wahrscheinlich wieder tun.

Gruß Peter

@davidebbo

ob sich das Problem auf Azure App Service oder ein anderes Hosting bezieht

Azure-App-Service.

ob die Leute versucht haben, die app_offline-Schreibweise wie oben beschrieben zu ändern. Scheint, dass mehrere Leute dort Erfolge gemeldet haben.

Das Ändern von App_Offline in app_offline behebt das Problem – diese Datei wird über webdeploy automatisch mit der Schreibweise „App_Offline“ als Teil der Bereitstellung erstellt, was der Kern des Problems ist.

@davidebbo
Genau das gleiche wie @ctolkien.

@davidebbo

ob sich das Problem auf Azure App Service oder ein anderes Hosting bezieht

In meinem Fall stelle ich Azure App Service bereit. Kenne kein anderes Hosting.

ob die Leute versucht haben, die app_offline-Schreibweise wie oben beschrieben zu ändern. Scheint, dass mehrere Leute dort Erfolge gemeldet haben.

Ich verwende die Aufgabe „Azurerm-Web-App bereitstellen“ von VSTS (https://aka.ms/azurermwebdeployreadme). Es gibt eine Option "Mit Web Deploy veröffentlichen" <- aktiviert und "App offline nehmen" <- aktiviert, die früher funktionierte, bis sich irgendwo etwas änderte und sie nicht mehr funktionierte.
Der "Info"-Tooltip weist explizit darauf hin, "app_offline.htm" mit Kleinbuchstaben "a" zu platzieren.
Ich bin mir nicht sicher, wie ich es mit diesem Skript ändern soll, es sollte bereits Kleinbuchstaben sein.

ob MSDEPLOY_RENAME_LOCKED_FILES versucht wurde. Auch hier scheinen mehrere Leute erfolgreich gewesen zu sein.

Nicht probiert. Ich weiß nicht, wie man das macht. Aber auf jeden Fall würde ich es vorziehen, die App offline zu nehmen, anstatt den Inhalt gesperrter Dateien zu ändern.

Danke an alle. Es klingt also klar, dass das Hauptproblem die Schreibweise von app_offline.htm ist und nichts mit Azure App Service zu tun hat (das ist die Seite, von der ich komme). Und dies wird von https://github.com/aspnet/AspNetCoreModule/issues/50 verfolgt.

Ich würde vorschlagen, dieses Thema zu schließen und das andere zu behalten. Ich überlasse es den ASP.NET-Experten, es sei denn, es gibt Grund zu der Annahme, dass Azure Web App teilweise schuld ist (unwahrscheinlich, dass @fabiano außerhalb von Azure dasselbe berichtet).

Tatsächlich sieht dies wie eine Regression bei den Tools aus, bei denen anscheinend damit begonnen wurde, App_Offline.html anstelle von app_offline.html zu erstellen. @mlorbetske , @vijayrkn - hast du eine Idee, was es sein könnte?

Ich verstehe, Sie sagen also, dass die Kernlaufzeit (AspNetCoreModule) immer zwischen Groß- und Kleinschreibung unterschieden hat, aber dass dies früher kein Problem war, weil VS die passende Groß- und Kleinschreibung verwendet hat und jetzt nicht mehr?

Trotzdem würde ich argumentieren, dass die Laufzeit hier nicht zwischen Groß- und Kleinschreibung unterscheiden sollte, daher gibt es zwei mögliche Wege, um das Problem zu lösen.

@davidebbo - das ist richtig. Ich glaube, AspNetCoreModule war immer case sensitive.

@davidebbo

und nichts im Zusammenhang mit Azure App Service (das ist die Seite, von der ich komme)

Ich denke, der Grund für die Einbeziehung von Azure AppService in die Diskussion ist, dass die Dinge ohne Änderungen in unserem Namen einfach zu scheitern begannen und wir keine unserer Paketversionen geändert haben. Wurde die ANCM-Revision in App Services überarbeitet?

@ctolkien ja, ich denke, es wurde tatsächlich aktualisiert. Es könnte also durchaus sein, dass die obige Schlussfolgerung nicht richtig ist. Stattdessen lautet die neue Theorie:

• Beim älteren ANCM (7.1.1965.0) wurde die Groß- und Kleinschreibung nicht beachtet.
• Bei der neueren (7.1.1970.0) wird zwischen Groß- und Kleinschreibung unterschieden.
• Auf der VS-Veröffentlichungsseite hat sich nichts geändert, und die Schreibweise war immer App_Offline.htm .

@moozzyk denkst du, dass das eine Möglichkeit ist, oder bist du dir sicher, dass immer zwischen Groß- und Kleinschreibung unterschieden wurde?

@moozzyk @davidebbo – Es gab keine Änderung in den VS-Tools für die app_offline-Gehäuse. VS-Tools rufen msdeploy mit der appoffline-Regel (-enablerule:AppOffline) auf und msdeploy löscht App_Offline.htm.

Dieses Problem scheint eine Verhaltensänderung in ANCM zu sein. Basierend auf dem ersten Kommentar hier sollte app_offline Groß- und Kleinschreibung beachten (https://github.com/aspnet/IISIntegration/issues/81).

@ctolkien

Das Ändern von App_Offline in app_offline behebt das Problem

Wo ändere ich das? Ich mache MSDEPLOY direkt von Visual Studio zu Azure.

@oyvindvol

Wo ändere ich das? Ich mache MSDEPLOY direkt von Visual Studio zu Azure.

Soweit ich weiß, können Sie die Groß- und Kleinschreibung von App_Offline von MSDEPLOY nicht ändern. Sie müssen vorerst eine benutzerdefinierte Skriptlösung erstellen. Sie können das Powershell-Skript, das ich oben gepostet habe, als Ausgangspunkt verwenden.

Um alle auf den neuesten Stand zu bringen, haben wir bestätigt, dass die obige Theorie richtig ist: Der Fehler bei der Berücksichtigung der Groß-/Kleinschreibung ist eine Regression in der neueren Version von ANCM, und diese Version wurde im Dezember in Azure App Service bereitgestellt, was dazu führte, dass Benutzer plötzlich darauf stießen.

Es ist geplant, einen ANCM-Fix vom ASP.NET Core-Team zu erhalten und ihn in App Service bereitzustellen. Es gibt noch keine ETA, aber es sollte irgendwann im Januar passieren.

Danke!

@davidebbo werden wir in der Lage sein, ANCM herunterzuladen, um es auf unserem eigenen Server mit iis zu installieren und auch diesen speziellen Fehler zu treffen?

@Pictuel Ich denke schon. Beachten Sie, dass mein Blickwinkel hier ausschließlich Azure App Service ist, daher lasse ich das Core-Team Kommentare zu Nicht-Azure-Szenarien abgeben.

Danke für die Warnung :)

@Pictuel Ja, wir werden sicherstellen, dass eine aktualisierte Version des Windows-Hosting-Installationsprogramms für .NET Core veröffentlicht wird, die das Update für ANCM enthält.

@shihatti

@shirhatti Ich überwache hier, wann das aktualisierte Installationsprogramm verfügbar ist, um Dokumentlinks zu aktualisieren.

Nachdem ich diesen Thread durchgegangen bin, bin ich mir nicht sicher, was genau die Problemumgehung für App Services ist. Ist es die App-Einstellung oder wird ein benutzerdefiniertes Bereitstellungsskript verwendet oder die Site gestoppt und gestartet?

Wenn es die App-Einstellung ist, habe ich einen anderen Kommentar gelesen, der besagt, dass die Website die neuen DLLs nicht aufnimmt.

Wenn ich das richtig verstanden habe, gibt es auf unserer Seite keine Problemumgehung, bis ein Update auf ANCM verfügbar ist (https://github.com/aspnet/AspNetCoreModule/issues/50). App-Dienste sollten vom Azure-Team aktualisiert werden.

Ich denke, Sie setzen am besten auf App Service, indem Sie die App stoppen/starten, wie von @dtmnash hier beschrieben.

@davidebbo „Der Plan ist, einen ANCM-Fix vom ASP.NET Core-Team zu erhalten und ihn für App Service bereitzustellen. Es gibt noch keine ETA, aber es sollte irgendwann im Januar geschehen.“ -- Lassen Sie uns wissen, wenn eine ETA dazu bereit ist :)

Die voraussichtliche Ankunftszeit für die Bereitstellung liegt zwischen dem 24. und 30. Die Bereitstellung erfolgt schrittweise über die vielen Skalierungseinheiten, sodass nicht jeder die Lösung genau zur gleichen Zeit erhält.

Danke, bei mir hat es gerade erst funktioniert :-)

Immer noch ein Problem für mich :(

@hbunjes danke für die Bestätigung!

@rsnj es passiert nach und nach über einen bestimmten Zeitraum. Es sollte alles bis Ende des Monats erledigt sein (es sei denn, wir treffen auf ein Problem).

@davidebbo Deployment scheint für einige meiner Apps zu funktionieren, aber nicht für alle. Das Seltsame ist, dass einige Bereitstellungen fehlschlagen, andere jedoch nicht für Apps, die im selben App Service-Plan ausgeführt werden. Ist es möglich zu sehen, welche Version von ANCM für eine bestimmte Webanwendung ausgeführt wird?

@henningst Siehe https://github.com/aspnet/AspNetCoreModule/issues/50#issuecomment -271381892 für eine Möglichkeit zur Überprüfung.

Hat bei mir gestern nicht funktioniert, aber jetzt IST es. Danke @davidebbo!

Bei mir hat es auch angefangen zu funktionieren. Danke!

Ja, die Bereitstellung ist jetzt abgeschlossen, sodass sie für alle funktionieren sollte.

Auch hier alles gut für mich.

Scheint jetzt zu funktionieren. Laut Bericht hat es über ein Jahr gedauert, bis dies behoben wurde. Ich hätte, obwohl Bereitstellungsprobleme eine höhere Priorität erhalten hätten: p

Wie kann dies für Nicht-Azure behoben werden?

@pekkah Ich denke, es hat verschiedene Probleme gegeben. Die letzte war viel jünger als ein Jahr.

@jdshkolnik für Nicht-Azure, ich denke, Sie müssen nur mit der Verwendung des neuen ANCM beginnen.

@jdshkolnik
Das Update steht unter https://www.microsoft.com/net/download/core#/runtime zum Download bereit
Dies ist ein direkter Link zum Download.

@shirhatti Ich habe das installiert, bekomme aber immer noch diese Fehler.

Ich erhalte immer noch den Fehler in Sao Paulo, Südbrasilien.

@jdshkolnik Welche Version sehen Sie, wenn Sie dies in PowerShell ausführen?

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

@shirhatti 7.1.1971.0

Update : Entschuldigung, das war meine Schuld. Ich habe die Bereitstellungsschritte einer vorhandenen Version überprüft und aktualisiert und nicht die Versionsdefinition. Ich habe aufgehört zu zählen, wie oft ich das schon gemacht habe...

Ich stoße immer noch jedes Mal auf diesen Fehler, wenn ich versuche, bereitzustellen, obwohl meine Version von aspnetcore.dll diejenige ist, die angeblich behoben ist.

aspnetcore.dll-Version : 7.1.1971.0
Bereitgestellt mit : VSTS-Aufgabe Azure App Service Deploy v3.* (Vorschau)
App offline nehmen : Aktiviert
Zusätzliche Dateien am Ziel entfernen : Aktiviert
Gesperrte Dateien umbenennen: Aktiviert
MSDEPLOY_RENAME_LOCKED_FILES App-Einstellung : Nicht hinzugefügt

In diesem Stadium ist mir nicht klar, welche Einstellungen erforderlich sind oder nicht, damit dies funktioniert.

Ich hatte gerade wieder mein erstes Problem mit der verwendeten Datei in den Azure-App-Diensten:

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 Fehlercode: ERROR_FILE_IN_USE

2017-02-14T22:41:34.3837386Z Weitere Informationen: Web Deploy kann die Datei „Ascend.Ammo.Portal.exe“ auf dem Ziel nicht ändern, da sie von einem externen Prozess gesperrt ist. Damit der Veröffentlichungsvorgang erfolgreich ist, müssen Sie möglicherweise entweder Ihre Anwendung neu starten, um die Sperre aufzuheben, oder bei Ihrem nächsten Veröffentlichungsversuch den AppOffline-Regelhandler für .Net-Anwendungen verwenden. Weitere Informationen finden Sie unter: http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_FILE_IN_USE.

2017-02-14T22:41:34.3837386Z Fehleranzahl: 1.

Zu Ihrer Information: Die Dokumente scheinen auf ein Installationsprogramm mit der alten Version (*.1970) zu verlinken: https://docs.microsoft.com/en-us/aspnet/core/publishing/iis#install -the-net-core- Windows-Server-Hosting-Paket.

Außerdem scheint auf der Runtime-Download-Seite nur die LTS-Version das Update zu haben?

@shirhatti ~Lassen Sie mich wissen, wenn der Link zum neuen Hosting-Bundle-Installationsprogramm fertig ist, und ich werde es in die Dokumentation aufnehmen (es befindet sich an einigen Stellen).~

~Ist es dieser hier: https://go.microsoft.com/fwlink/?linkid=837808 ... das ist aber kein aka.ms-Link.~

Ich habe https://github.com/aspnet/Docs/pull/2773 eingerichtet, um dies abzudecken, wenn der fwlink in Ordnung ist.

Passiert auch in Visual Studio, und wie die Optionen zeigen, ist die App-Offline-Regel vorhanden.

@davidebbo kannst du bestätigen, dass das behoben ist? Hören von ziemlich vielen Leuten, dass sie es immer noch schlagen. Hat die Release-Version des Tools eine Lösung dafür oder handelt es sich immer noch um ein Hosting-Problem?

Ich versuche auch herauszufinden, warum und wann es passiert. Ich bin mir fast sicher, dass ich gesehen habe, dass der Prozess im Prozess-Explorer auf der SCM-Site ausgeführt wird und dass er problemlos veröffentlicht wurde.

Ich bin dabei, meine Websites auch auf die neuesten Tools zu aktualisieren, in der Hoffnung, dass das Problem mit alten project.json-Tools zusammenhängt.

Der Fix wurde vor einiger Zeit in Azure App Service bereitgestellt, und mir ist nicht bekannt, dass das Problem danach immer noch bei jemandem auftritt. Benutzer auf Nicht-Azure-Hosts können es natürlich weiterhin sehen, wenn sie nicht aktualisiert wurden.

Wenn Sie Probleme mit Azure haben, testen Sie es bitte wie folgt:

• Gehen Sie zum Kudu-Prozess-Explorer und stellen Sie sicher, dass der Prozess Ihrer App ausgeführt wird (normalerweise dotnet.exe).
• Erstellen Sie manuell eine app_offline.htm -Datei (z. B. führen Sie touch app_offline.htm aus) über den Kudu-Befehl
• Überprüfen Sie den Prozess-Explorer erneut und stellen Sie sicher, dass der Prozess nicht mehr vorhanden ist.

Ich werde noch etwas testen, haben Sie das Bild ein paar Posts weiter oben gesehen, es zeigt deutlich, dass die Datei verwendet wird und die App offline verwendet wird.

Aber ich werde testen, wie Sie gefragt haben.

Außerdem verwenden wir Scaleout + Apps, die für virtuelle Anwendungen bereitgestellt werden – ich weiß nicht, ob sich dadurch etwas ändert.

@pksorensen , wenn Sie dies "manuell" tun, hilft, sich von allem zu isolieren, was WebDeploy möglicherweise tut. dh wenn das einfache Ablegen app_offline.htm den Prozess nicht stoppt, dann wissen wir wirklich, dass es ein Problem gibt, das nicht von WebDeploy verursacht wurde.

Beachten Sie, dass Sie normalerweise mit einem dotnet.exe-Prozess enden, während Sie in Ihrem Fall einen anderen exe-Namen haben. Ich frage mich, ob das irgendwie mit dem Problem zusammenhängt.

1. Gehen Sie zum Kudu-Prozess-Explorer und stellen Sie sicher, dass der Prozess Ihrer App ausgeführt wird (normalerweise dotnet.exe).
   Ich habe dies getan, aber es ist nicht dotnet.exe, sondern unser Name, kompiliert bin Ascend.Ammo.RegistrationTablet.exe

Dann habe ich app_offline.htm berührt, aber das hat den Prozess nicht beendet.

Mache ich etwas falsch, da ich dotnet.exe nicht sehe?

Ich lasse die dotnet / ANCM-Experten diesen Teil kommentieren. Ich weiß, dass bei der Bereitstellung einer zentralen ASP.NET-App standardmäßig dotnet.exe verwendet wird. Ich denke, der Fall, wenn dies nicht der Fall ist, ist, wenn Sie eine eigenständige Bereitstellung verwenden (oder wie auch immer es genannt wird). Aber ich habe keine Ahnung, wie sich das auf ANCM und app_offline.htm auswirkt.

@DamianEdwards wer kann das am besten kommentieren?

Ich vermeide dieses Problem, indem ich Bereitstellungsslots verwende. Funktioniert 100% der Zeit. Stoppen Sie den Slot, bevor Sie Dateien kopieren. Dadurch wird alles aus dem Speicher entfernt, sodass Ihre Kopie ohne gesperrte Dateien funktioniert. Starten Sie dann den Slot und wechseln Sie in die Produktion. Zusätzlicher Vorteil, dass Ihre Kunden die App-Offline-Seite nie sehen. Sie erhalten eine Bereitstellung mit 0 Ausfallzeiten.

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

Der @DarqueWarrior- Slot funktioniert natürlich (und ist aus anderen Gründen gut zu verwenden), aber das Wichtigste in diesem Thread ist zu verstehen, warum app_offline für einige Leute wie @pksorensen beim Herunterfahren des Kernprozesses unwirksam erscheint. Und ich möchte, dass das Core-Team dazu Stellung nimmt.

@davidebbo Um Ihre frühere Frage zu beantworten, hat Portable vs Standalone keinen Einfluss auf das app_offline-Verhalten. Die App-Offlinedatei wird von w3wp.exe (vom ASP.NET Core-Modul) überwacht.

@DarqueWarrior Vielen Dank für den Rat, ein Kommentar jedoch - wenn Sie wie wir mehrere Sites für virtuelle Anwendungen im selben App-Dienst bereitstellen, funktionieren die Slots (wenn ich mich richtig erinnere) für alle diese, sodass Sie zuvor alle Sites bereitstellen müssten tauschen. Das ist mühsam. Im Moment können wir Teile (Microservices) einfach für einzelne virtuelle Anwendungen bereitstellen. Natürlich können wir diese auf separate App-Dienste verteilen, aber dann bräuchten wir Loadbalancer/Gateways davor, damit sie wieder dieselbe Domain teilen, was auch mehr Zeit kostet, als wir im Moment bereit sind zu tun.

Also stimme ich zu, dass das, was Sie vorschlagen, der bevorzugte Weg ist, es passt im Moment einfach nicht zu uns. Hoffen Sie also immer noch auf eine Lösung für das Problem mit der Datei in Gebrauch.

@pksorensen besteht die Möglichkeit, dass Sie eine Repro auf einer Dummy-Site einrichten und ihren Namen teilen können? Grundsätzlich möchte ich es in dem Zustand sehen, in dem Ihre Site ausgeführt wird, und das manuelle Erstellen von app_offline.htm in der Kudu-Konsole führt nicht zum Herunterfahren.

@shirhatti , haben Sie eine Idee, was dazu führen könnte, dass ANCM den Prozess nicht beendet? Wie aggressiv versucht es das?

@davidebbo Es wird ein bisschen dauern, aber ich werde versuchen, etwas auszuarbeiten, um eine Repro zu erstellen.

@davidebbo Ich habe eine neue ASP.NET Core-App und einen neuen Azure App Service erstellt. Ich verwende die Funktion „Kontinuierliche Bereitstellung (Vorschau)“ von Azure und erhalte dieses Problem.

2017-03-30T02:54:36.5648892Z ##[error]App Service konnte nicht bereitgestellt werden.
2017-03-30T02:54:36.5658893Z ##[Fehler]Fehlercode: ERROR_FILE_IN_USE
2017-03-30T02:54:37.1850861Z Weitere Informationen: Web Deploy kann die Datei „myApp.dll“ auf dem Ziel nicht ändern, da sie von einem externen Prozess gesperrt ist. Damit der Veröffentlichungsvorgang erfolgreich ist, müssen Sie möglicherweise entweder Ihre Anwendung neu starten, um die Sperre aufzuheben, oder bei Ihrem nächsten Veröffentlichungsversuch den AppOffline-Regelhandler für .Net-Anwendungen verwenden. Weitere Informationen finden Sie unter: http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_FILE_IN_USE.
2017-03-30T02:54:37.1860517Z Fehleranzahl: 1.
2017-03-30T02:54:37.4179909Z ##[Fehler]Fehler: C:\Programme\IIS\Microsoft Web Deploy V3\msdeploy.exe fehlgeschlagen mit Rückgabecode: 4294967295

Das manuelle Erstellen einer app_offline.htm in D:\home\site\wwwroot stoppt tatsächlich den dotnet.exe-Prozess.

Bedeutet dies also, dass es ein Problem mit „Continuous Delivery (Preview)“ selbst gibt?

Darüber hinaus habe ich dies behoben, indem ich manuell zu VSTS-Releasedefinition, Zusätzliche Bereitstellungsoptionen gegangen bin und „App offline nehmen“ aktiviert habe.

Aber das wirft ein paar Fragen auf:
Warum ist „App offline nehmen“ standardmäßig deaktiviert? Sollte dieses Szenario noch funktionieren (z. B. reduziert es Ausfallzeiten)?

Wenn ja, warum schlägt es dann fehl? Wenn nein, warum bleibt es dann bei "Kontinuierliche Lieferung (Vorschau)" deaktiviert?

So oder so - scheint irgendwo ein Fehler zu sein.

@ Jon12345 : In diesem Thread geht es nur darum, zu diskutieren, ob app_offline.htm korrekt mit Core-Apps funktioniert. Die Tatsache, dass VSTS dies standardmäßig tut oder nicht, ist wirklich eine separate Diskussion, die in einem VSTS-Forum geführt werden sollte (wahrscheinlich https://social.msdn.microsoft.com/Forums/vstudio/en-US/ home?forum=TFService).

An diesem Punkt scheinen die meisten Leute nach dem Fix entsperrt worden zu sein. Es gab einen Bericht von @pksorensen , dass es nicht funktioniert, und wir warten auf eine Repro-App, die wir uns ansehen können.

Ich bekomme das immer noch auf TFS 2017 Update 1.

@jdshkolnik Sind Sie sicher, dass es so eingerichtet ist, dass es die Datei appoffline.htm erstellt? Wenn nicht, liegt es außerhalb des Rahmens dieses Problems. Bitte führen Sie den manuellen appoffline.htm-Test wie oben beschrieben durch.

@davidebbo Ja, das ist es. Es kommt häufig vor, dass die geplante nächtliche Bereitstellung beim ersten Versuch fehlschlägt und ein manueller erneuter Bereitstellungsversuch erforderlich ist, der normalerweise erfolgreich ist.

Zu Ihrer Information, meine Firma ist mit Ihrer verbunden, sodass ich sie Ihnen ganz einfach über die Desktopfreigabe von Skype for Business zeigen kann.

@jdshkolnik Bitte stellen Sie sicher, dass Sie den oben beschriebenen manuellen Test durchführen, da dies hilft, alles andere aus der Gleichung herauszuholen.

Wichtig : Bei diesem Problem geht es nicht darum, Probleme mit VSTS oder anderen Veröffentlichungsworkflows zu untersuchen. Es geht nur um eines: sicherzustellen, dass appoffline.htm funktioniert.

@davidebbo Es geht offline, sobald ich app_offline.htm manuell in den Ordner lege.

Ich weiß nicht, wie ich besser unterscheiden kann, ob ich hier perfekt zum Thema bin. Ich weiß nur, dass es letztes Jahr plötzlich bei Websites auftauchte, die ohne Probleme funktionierten, und seitdem regelmäßig auftaucht.

##[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 Meine beste Vermutung ist, dass dieses Bereitstellungsskript nicht die appoffline.htm erstellt, bevor die Dateien veröffentlicht werden. Es könnte sich um ein VSTS-Konfigurationsproblem oder einen Fehler handeln. Aber aus Sicht von ANCM zeigt der von Ihnen durchgeführte Test, dass die Dinge wie erwartet funktionieren, wenn appoffline erstellt wird.

@davidebbo Ich weiß nicht, dass das, was ich getan habe, ein endgültiger Test war. Schließlich ist der zweite manuelle Versuch, nachdem wir einen Fehler erhalten, normalerweise erfolgreich. Der Bereitstellungsprozess, der app_offline.htm blockieren könnte, wurde nicht ausgeführt.

Ich stoße immer noch auf dieses Problem, bei dem die Groß- und Kleinschreibung am 7.1.1971.0 beachtet wird. Wenn ich versuche, mithilfe von VS bereitzustellen, erhalte ich einen Fehler mit gesperrter Datei, also habe ich nachgesehen, ob die App noch ausgeführt wird, und das war sicher genug. Ich habe die Kudu-Befehlszeile geöffnet, um zu sehen, welche Dateien sich im wwwroot-Verzeichnis und App_Offline.htm im Ordner befanden, aber der Prozess lief noch. Dann habe ich touch app_offline.htm eingegeben und der Prozess wurde wie erwartet beendet. Ich habe die Module doppelt überprüft und meine aspnetcore.dll-Version ist 7.1.1971.0.

@alexgritton das ist seltsam. Scheint darauf hinzudeuten, dass ANCM die Datei ursprünglich nicht erkannt hat. Geschieht das regelmäßig oder zufällig?

Ich habe die Anwendung gerade heute auf Azure App Services erstellt und es passiert den ganzen Tag, also würde ich sagen, ständig. Habt ihr noch andere Ideen woran das liegen könnte?

Nicht wirklich. Ich lasse die ANCM-Experten kommentieren, wie sie Dateiänderungen überwachen und ob ihnen ein Grund einfällt, warum die anfängliche Erstellung nicht erkannt wird.

@davidebbo Ich habe genau das gleiche Problem. Mein Team hat einen gefälschten Build, der eine Datei AppBuild.htm vom Build-Server als app_offline.htm auf die Zielseite kopiert. Wir versuchen dann, msdeploy zu verwenden, um den Ordner zu synchronisieren und den durch einen anderen Prozessfehler geöffneten zu erhalten. Wenn ich die Datei berühre, die Datei von app_offline.htm in app_offline.htm.rename und wieder zurück benenne oder app_offline.htm mit dem Datei-Explorer überschreibe, wird der Vorgang ordnungsgemäß beendet. Es macht keinen Sinn, warum es nicht durch unser Skript funktioniert, aber wenn wir es manuell machen.

Update: Wir haben festgestellt, dass das Aktualisieren der letzten Schreibzeit das Herunterfahren konsequent auszulösen scheint:

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)     
)                

Mit dem Code, der die Datei app_offline.htm überwacht, scheint definitiv etwas nicht in Ordnung zu sein.

@derekgreer Sie sehen also, dass beim Kopieren der Datei das Herunterfahren nicht ausgelöst wird? Ich kann dies nicht von der Kudu-Konsole aus reproduzieren. z.B

• Gehen Sie zur Kudu-Konsole
• Führen Sie touch app_offline.htm in D:\home\site aus, um eine leere Datei in einem anderen Ordner zu erstellen
• Führen Sie copy app_offline.htm wwwroot . Beachten Sie, dass dadurch die letzte Schreibzeit beibehalten und die Erstellungszeit aktualisiert wird (Standardverhalten beim Kopieren von Dateien).

Ergebnis: Der dotnet.exe-Prozess wird sofort heruntergefahren (Sie können dies mit dem Kudu-Prozess-Explorer überprüfen).

Funktionieren diese Schritte für Sie? Wenn ja, was könnte in Ihrem Repro-Szenario anders sein?

Eigentlich hätte ich auch hinzufügen sollen, dass dieses Problem sporadisch auftritt und dass wir IIS 8 auf Windows Server 2012 verwenden.

Heute Morgen wollte ich sehen, ob ich das Problem mit einem Powershell- oder Batch-Skript reproduzieren kann, bevor ich die Kudu-Konsole einrichte, aber nachdem ich zuerst mit dem Test-Fake-Build-Skript getestet hatte, das mein Team am Freitag verwendet hatte, um die Datei app_offline.htm zu erstellen auf verschiedene Arten (vorhandene Datei kopieren, neue Datei erstellen usw.), es funktioniert derzeit. Dies spiegelt auch das Muster unserer Build-Fehler wider, bei denen der Prozess manchmal heruntergefahren wurde und andere Male nicht. Wenn es anfängt zu versagen, scheint es dies konsequent zu tun. Wir haben am Freitag stundenlang getestet und es hörte durchweg nicht mit einem einfachen gefälschten Build auf, der absolut nichts tat, außer eine neue app_offline.htm-Datei zu erstellen. Ich sollte auch hinzufügen, dass wir die Datei regelmäßig manuell erstellten und sahen, wie der Prozess stoppte, also scheint es keine Situation zu geben, in der der Prozess nach einer längeren Nutzungsdauer nicht heruntergefahren wird.

Wenn ich das Problem erneut reproduzieren kann, werde ich sehen, ob das Erstellen der Datei mit Powershell und/oder Batch-Datei das Problem immer noch widerspiegelt.

@davidebbo Nun, Mist ... Ich habe gerade bemerkt, dass ich vergessen habe, eine Zeile zu kommentieren, die die letzte Aktualisierungszeit aktualisiert hat, also zeigt sie tatsächlich immer noch das gleiche Verhalten. Ich werde es jetzt mit Powershell und einer Batch-Datei versuchen und Sie aktualisieren.

@davidebbo

Sorry für die Verwirrung. Okay, hier ist, was ich gefunden habe:

Die Verwendung einer Batchdatei mit folgendem Inhalt scheint den Prozess zuverlässig zu beenden:

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

Auch die Verwendung eines entsprechenden Bash-Skripts führt zuverlässig zum Herunterfahren des Prozesses:

#!/bin/bash

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

Die Verwendung eines Powershell-Skripts mit den folgenden Inhalten scheint niemals dazu zu führen, dass der Prozess heruntergefahren wird:

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

Angesichts der Tatsache, dass sowohl Fake als auch Powershell unter der CLR ausgeführt werden, während der DOS-Kopierbefehl, bash und die Kudu-Konsole dies nicht tun, scheint dies auf etwas hinzuweisen, das mit der Datei zusammenhängt, die über die CLR erstellt wird.

Das Seltsame ist, dass ich keine Unterschiede in den Erstellungs-/Aktualisierungszeitstempeln der resultierenden Datei zwischen den verschiedenen Versionen sehe.

@derekgreer Oh, Sie führen also überhaupt keinen Azure App Service aus. Das ist mein Blickwinkel in dieser ganzen Saga, also lasse ich die ASP.NET-Leute weiter kommentieren.

Obwohl ich für das, was es wert ist, nicht in App Service reproduzieren konnte:

• Verwenden Sie die PowerShell-Konsole von Kudu
• Gehen Sie zum Ordner site\wwwroot
• Führen Sie New-Item app_offline.htm -type file

@moozzyk kannst du helfen, den externen App-Dienst von @derekgreer zu untersuchen?

Weitere Infos:

Da das Erstellen, Kopieren, Umbenennen usw. über den Datei-Explorer durchgehend funktioniert hat, habe ich mich entschieden zu sehen, ob eine .Net-basierte Datei-Explorer-App die gleichen Ergebnisse widerspiegelt wie ich mit Fake und PowerShell sehe. Es gibt einen .Net-basierten Datei-Explorer namens „Nomad“, den ich schließlich heruntergeladen und getestet habe, und die Ergebnisse stimmten mit Fake und PowerShell überein. Beim Erstellen einer app_offline.htm-Datei wurde der Prozess nicht angehalten. Ich habe dann die Datei umbenannt und wieder zurück in app_offline.htm umbenannt und den Core-Prozess dann heruntergefahren.

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

Ich würde denken, dass diese Methode das Flag "FILE_NOTIFY_CHANGE_CREATION" enthalten möchte.

Ich frage mich, ob die .Net-API, die Fake, PowerShell und Nomad gemeinsam haben, diese anderen Flags nicht auf die gleiche Weise auslöst wie die normale Dateierstellung.

@shirhatti können Sie bitte sicherstellen, dass jemand dieses potenzielle ANCM-Problem untersucht?

@davidebbo Ack. Wir prüfen es

Ich habe ein sehr ähnliches Problem. Wenn ich eine app_offline.htm-Datei in Windows Explorer kopiere, wird der Prozess korrekt beendet, aber wenn ich sie mit COPY app_offline.htm \server\share\siteapp_offline.htm von meinem Build-Server erstelle, wird sie nicht angehalten und die Dateien bleiben gesperrt .

@gulbanana Ich habe genau das gleiche Problem wie du. Hast du es schon gelöst? @shirhatti Irgendwelche Neuigkeiten zu Ihrer Untersuchung? Dieser macht das Team verrückt, weil die CI-Pipeline ständig aufgrund von Fehlern beim Kopieren von Dateien fehlschlägt, die wiederum dadurch verursacht werden, dass dotnet.exe nicht von app_offline.htm heruntergefahren wird.

Ich habe das Problem umgangen, indem ich etwas in der Art von echo "<html>page content</html>" > \\server\share\app_offline.htm verwendet habe. Ich denke, @derekgreer hat Recht, dass es bei dem Fehler darum geht, dass ANCM nur einige Methoden der Dateierstellung überwacht, und es fängt diese ab.

@derekgreer
Ich schaue jetzt in Problem. Mit einem Ihrer Repro-Befehle in meiner Testmaschine konnte ich dieses Problem reproduzieren. Ich habe den folgenden Befehl verwendet. (HINWEIS: Der folgende Befehl erstellt eine leere Datei (Dateigröße Null).

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

Eine interessante Sache ist, wenn ich beim Erstellen der Datei app_offline.htm etwas Dateiinhalt hinzufüge, gibt es kein Problem. Dies kann durch einfaches Hinzufügen des Parameters -value "test" wie folgt erreicht werden:

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

Können Sie bestätigen, ob Sie das gleiche Symptom in Ihrer Reproumgebung sehen?
Wenn ja, denke ich, dass dieses Problem nur auftritt, wenn eine leere app_offline.htm auf eine spezielle Weise erstellt wird, z. B. mit dem Powershell-Befehl new-item.

@gulbanana
Ich kann dieses Problem mit dem Befehl Kopieren nicht reproduzieren. Können Sie Ihre Repro genauer erklären? Es wäre toll, wenn Sie einige Repro-Schritte finden könnten, mit denen ich das gleiche Problem auf meiner Testmaschine reproduzieren kann.

Ich kann bestätigen, dass es nicht damit zusammenhängt, ob die Datei app_offline.htm leer ist, ohne diese Befehle auszuführen, da unsere Erfahrung darin besteht, eine Datei mit dem gewünschten Inhalt in den Bereitstellungsordner zu kopieren. Aufgrund meiner Erfahrung würde ich vermuten, dass der zweite Befehl möglicherweise ein Dateiänderungsereignis verursacht, wenn er tatsächlich funktioniert. Möglicherweise erstellt es die Datei und aktualisiert sie anschließend mit Inhalten. Unabhängig davon kann jeder .net-bezogene Prozess, den ich zum Erstellen der Datei mit oder ohne Inhalt verwendet habe, das Herunterfahren des Prozesses nicht auslösen.

@shirhatti Irgendein Update? Konnten Sie bestätigen, dass Ihr Code das Flag „FILE_NOTIFY_CHANGE_CREATION“ verwenden sollte?

@derekgreer Wir hören auf jedes gültige Flag, außer den letzten Zugriff zu ändern und Attribute zu ändern.
FILE_NOTIFY_VALID_MASK & ~FILE_NOTIFY_CHANGE_LAST_ACCESS & ~FILE_NOTIFY_CHANGE_ATTRIBUTES

Also ja, wir hören bereits auf FILE_NOTIFY_CHANGE_CREATION .

cc: @pan-wang

@shirhatti Ah, jetzt verstehe ich. Mir war nicht bewusst, dass das Flag die Erstellung von Änderungen abdeckt. Mich würde interessieren, konntest du das Problem reproduzieren?

Das Nichtreagieren auf leere app_offline.htm wurde angeblich behoben: https://github.com/aspnet/IISIntegration/issues/174

@moozzyk @derekgreer Danke für die Bestätigung. Okay, ich habe auch festgestellt, dass das Problem nicht direkt mit dem leeren Dateiinhalt zusammenhängt. Ich werde Sie aktualisieren, nachdem ich die Ursache herausgefunden habe.

@jhkimnew Ich habe nicht mehr das genaue kaputte Setup, aber ich kann die Besonderheiten beschreiben:

• IIS läuft auf Windows Server 2008 r2 und hostet eine asp.net-Kernanwendung mit ANCM
• Build-Server ist ebenfalls 2008r2 in derselben Domäne
• Der IIS-Server hat sein physisches Website-Verzeichnis über die Windows-Freigabe freigegeben
• Domänenbenutzer (das Konto des Build-Servers) führt ein Powershell-Skript auf dem Build-Server aus
  Wenn dieses Skript den Windows-Kopierbefehl verwendet, um eine app_offline aus einer vorhandenen Datei in einem anderen Verzeichnis zu kopieren, wird der Hosting-Prozess nicht heruntergefahren. Wenn das Skript stattdessen "echo" verwendet (was /bin/echo aus einer Mingw-Installation sein kann, bin ich mir nicht sicher), wird der Hosting-Prozess heruntergefahren.

Ich vermute, dass das Problem genau damit zu tun hat, welche Dateiattribute durch diese Art von Remote-Kopie aktualisiert werden oder nicht

@gulbanana Nur um das klarzustellen, Sie haben es mit dem Befehl dos copy versucht und nicht mit dem Commandlet power shell copy-item? Ich glaube nicht, dass ich die reguläre DOS-Kopie ausprobiert habe, aber ich habe festgestellt, dass jede .net-basierte App, die ich verwendet habe, nicht funktioniert hat.

es sei denn, Powershell hat einen Alias ​​​​dafür, es war dos copy

In meinem Fall fährt die PowerShell-Kopie den dotnet.exe-Prozess nicht herunter, aber das Echo, das ein Alias ​​von Out-Content ist, funktioniert. Ich halte es für unwahrscheinlich, dass es sich um ein .NET-Problem handelt, aber mehr darüber, warum eine Netzwerkkopie nicht funktioniert

Ich habe untersucht, ob es ein Problem in der Änderungsbenachrichtigung von aspnetcore.dll (ANCM) gibt, aber ich konnte das Problem nicht reproduzieren, als ich versuchte, app_offline.htm manuell entweder mit dem Powershell-Cmdlet oder dem DOS-Befehl zu löschen. Und ich habe einen fehlenden Punkt gefunden, der hier nicht diskutiert wurde.
Das ist ungefähr das ordnungsgemäße Herunterfahren. Im Gegensatz zum HttpPlatformHandler" unterstützt ANCM das ordnungsgemäße Herunterfahren, was bedeutet, dass, wenn app_offline.htm im Stammverzeichnis abgelegt wird, ANCM ein Strg-C/Break-Signal an den Backend-Prozess sendet und 10 Sekunden lang wartet, damit das ordnungsgemäße Herunterfahren erfolgt.
Die 10 Sekunden sind der Standardwert und Benutzer können den Wert mit dem shutdownTimeLimit der ANCM-Konfigurationseinstellungen anpassen. Wenn der Backend-Prozess nicht innerhalb des konfigurierten shutdownTimeLimit heruntergefahren wird, soll ANCM den Backend-Prozess beenden.

Als ich überprüfte, wie die Veröffentlichung von MSDeploy mit dem ordnungsgemäßen Herunterfahren von ANCM zusammenhängt, fand ich schließlich einen konsistenten Repro-Schritt, der darin besteht, die Herunterfahrzeit (5 Sekunden) zu verlängern, und bemerkte, dass MSDeploy standardmäßig nur 2 Wiederholungsversuche unternahm und nur 2 Sekunden wartete und schließlich nicht veröffentlicht werden konnte weil es nicht auf die ordnungsgemäße Abschaltzeit wartet.

@vijayrkn
Nachdem ich sowohl beim Starten als auch beim Beenden der Aspnetcore-Webanwendung 5 Sekunden Verzögerung gesetzt hatte, konnte ich den gleichen Fehler, der in diesem Problem gemeldet wurde, im zweiten Versuch der Veröffentlichung der Aspnetcore-Webanwendung auf dem lokalen IIS-Server reproduzieren. Ich habe auch das unten verwendete Veröffentlichungsprofil angehängt.
Würden Sie erklären, warum dies passiert, und eine korrekte Anleitung zur Behebung dieses Veröffentlichungsproblems geben? Und bitte erstellen Sie separat ein neues Problem, damit Ihr Team dieses Problem verfolgt, um die Benutzererfahrung zu verbessern.

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

MSDeploy versucht, direkt nach dem Löschen von app_offline bereitzustellen. Wenn es beim Stoppen des Prozesses zu einer Verzögerung kommt, kann die Bereitstellung fehlschlagen.

Die Wiederholungsanzahl für die Bereitstellung kann mithilfe dieser msbuild-Eigenschaft festgelegt werden (https://github.com/aspnet/websdk/blob/dev/src/Publish/Microsoft.NET.Sdk.Publish.Targets/netstandard1.0/PublishTargets/Microsoft .NET.Sdk.Publish.MSDeploy.targets#L67)

Wenn Sie diese Eigenschaft beispielsweise auf 10 setzen, wird sichergestellt, dass msdeploy zehn Wiederholungen mit einer Verzögerung von einer Sekunde dazwischen durchführt.
<RetryAttemptsForDeployment>10</RetryAttemptsForDeployment>

@vijayrkn

Danke für die Auskunft. Nachdem ich die beiden Zeilen unten hinzugefügt habe, sehe ich kein Problem mit derselben Repro-Umgebung.
<EnableMSDeployAppOffline>True</EnableMSDeployAppOffline> <RetryAttemptsForDeployment>10</RetryAttemptsForDeployment>

Jeder, der auf ein ähnliches Problem stößt, müsste also die Anzahl der RetryAttemptsForDeployment mit dem entsprechenden Wert erhöhen und es erneut versuchen, wenn das Problem dadurch gelöst werden kann.

HINWEIS: Der Grund, warum ich EnableMSDeployAppOffline hinzugefügt habe, ist, dass dies standardmäßig deaktiviert ist, wenn der lokale IIS-Server als Ziel für die Veröffentlichung einer Aspnetcore-Webanwendung verwendet wird. Wenn Sie sich also nicht sicher sind, ob dies in Ihrer Umgebung aktiviert ist oder nicht, müssen Sie die Zeile ebenfalls hinzufügen, und deshalb habe ich sie hier zu Ihrer Information hinzugefügt.

Nur um sicherzustellen, dass das ursprüngliche Problem nicht aufgrund der letzten Diskussionen verloren geht, ist das Problem, das mein Team erlebt hat, definitiv kein Zeitproblem. Wir haben die manuelle Erstellung der Datei app_offline.htm sowohl mit Powershell, Fake als auch mit einem .Net-basierten Datei-Explorer namens „Nomad“ getestet und der Prozess wird nicht beendet, egal wie lange Sie warten. Das Erstellen der Datei über den Datei-Explorer, eine DOS-Stapeldatei oder ein Bash-Skript (dh nicht auf einer .Net-Bibliothek basierende Prozesse) führt dazu, dass der Prozess innerhalb von 1-2 Sekunden heruntergefahren wird.

Dies scheint darauf hinzudeuten:

1. Das Problem ist nicht netzwerkbezogen (alle Tests wurden mit einer Remote-Dateifreigabe durchgeführt)
2. Es ist kein ordnungsgemäßes Herunterfahren / Timing-Problem

Die Tatsache, dass 3 Nicht-.Net-Methoden zum Erstellen der app_offline.htm-Datei den Prozess zuverlässig und schnell beenden und dass 3 .Net-Bibliothek-basierte Methoden zum Erstellen der Datei in unseren Tests niemals dazu führen, dass der Prozess beendet wird, scheint wirklich zu sein , wirklich großer Indikator für mich.

@derekgreer
Ich kann das Problem auch mit "Nomad" nicht reproduzieren.
Folgendes habe ich auf meinem Windows 10 (amd64)-Computer gemacht.

1. IIS installieren
2. Installieren Sie Visual Studio 2017
3. Erstellen Sie eine AspnetCore-Webanwendung und stellen Sie sie mit MSDeploy auf dem lokalen IIS-Server bereit
4. Installieren Sie Nomad v3.2.0.2890 (http://www.nomad-net.info/downloads)
5. Senden Sie eine Anfrage an die Webanwendung
6. Öffnen Sie den Task-Manager und bestätigen Sie, dass der dotnet.exe-Prozess ausgeführt wird
7. Öffnen Sie Nomad und erstellen Sie eine neue Datei namens app_offline.htm im Stammverzeichnis der Webanwendung
8. Rufen Sie den Task-Manager auf und vergewissern Sie sich, dass der dotnet.exe-Prozess nicht mehr vorhanden ist, wenn die Datei app_offline.htm erstellt wird

Würden Sie die genauen Repro-Schritte angeben, damit ich das Problem reproduzieren kann?

Abgesehen von der Tatsache, dass unsere .Net Core-Anwendung tatsächlich eine standardmäßige .Net 4.5.2-Konsolenanwendung ist, die in VS 2015 erstellt wurde und auf ASP.Net Core-Assemblys verweist, sehe ich keinen Unterschied. Das Projekt ist jetzt etwa ein Jahr alt und wurde damals aufgrund von Einschränkungen beim Verweisen auf Core-Vorlagenprojekttypen von .Net-Framework-Vorlagenprojekttypen und verschiedenen Arten von Testbibliotheksunterstützung für .Net Core so eingerichtet.

Wir haben einige Probleme identifiziert: 1) Das Löschen der Datei app_offline.htm (mit einem Tool) löste manchmal nur eine Benachrichtigung über die Änderung von Dateieigenschaften aus, die von ANCM herausgefiltert wurde. 2) ANCM kann app_offline.htm möglicherweise nicht lesen, da letzteres vom Dateikopiertool gespeichert wurde. 3) Das ordnungsgemäße Herunterfahren verursachte eine Verzögerung beim Beenden des Back-End-Prozesses.
Wir werden die ersten beiden Probleme in der nächsten Version behandeln. Für den Fall des ordnungsgemäßen Herunterfahrens muss der Benutzer es erneut versuchen.

klingt gut. In meinem Fall ging es definitiv nicht um eine ordnungsgemäße Zeitüberschreitung beim Herunterfahren - wenn es stoppt, stoppt es sofort.

Irgendwelche Updates zu diesem Thema?
Beim Versuch, eine ASP.NET Core 1.1-App mithilfe von VSTS in einem Azure-Web-App-Slot bereitzustellen

• Ich habe die MSDEPLOY_RENAME_LOCKED_FILES=1 in den Anwendungseinstellungen eingestellt
• Die Aufgabe „App Service verwalten“ ist so konfiguriert, dass die App offline geschaltet wird
• Die Aufgabe „App Service bereitstellen“ _war_ so konfiguriert, dass die App offline geschaltet wird, aber auch das hat nicht funktioniert

Das Kernproblem ist, dass die DLL verwendet wird:

@ChuckkNorris siehe https://github.com/Microsoft/vsts-tasks/issues/1607 für die neuesten Informationen dazu.

@davidebbo Danke für deine Antwort, David. Ich habe diesen Thread gesehen und dort viele der Problemumgehungen entdeckt, die ich ausprobiert habe.

Da dieses Problem noch offen ist und der Fehler immer noch weit verbreitet ist, hatte ich gehofft, dass es bald eine Lösung geben könnte, nicht eine weitere Problemumgehung. Immerhin ist dieses Thema nun schon seit über zwei Jahren offen.

@ChuckkNorris , obwohl das Symptom dasselbe ist, ist dies nicht dasselbe Problem:

• Ursprüngliches Problem im Zusammenhang mit der Schreibweise von app_offline.htm , was dazu führte, dass es vollständig ignoriert wurde. Das ist seit einiger Zeit behoben.
• Dieses neue Problem trat erst vor ungefähr einer Woche auf und tritt auf, weil Core jetzt länger zum Herunterfahren braucht, wenn app_offline.htm erstellt wird, und msdeploy standardmäßig nicht lange genug wartet. Die Problemumgehung besteht darin, die Anzahl der Wiederholungen zu erhöhen.

Ich habe gerade VS 2017 auf 15.3 aktualisiert und .NET Core 2.0 SDK installiert. Erstellte eine einfache MVC-App in VS - sie zielte auf netcoreapp1.1 ab. Ich habe auf Azure veröffentlicht und alles war in Ordnung. Ich habe auf newcoreapp2.0 aktualisiert und dann alle Nuget-Pakete auf 2.0 aktualisiert (Microsoft.AspNetCore, Microsoft.AspNetCore.Mvc usw.).

Beim Versuch, in Azure zu veröffentlichen (dh 1.1 zu überschreiben), erhalte ich dies

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 finden Sie unter https://github.com/Azure/app-service-announcements/issues/24

Ich musste MvcViewComplication deaktivieren, damit meine 2.0-Apps über Git bereitgestellt werden und Probleme mit der Verwendung von Dateien vermieden werden.

https://github.com/Microsoft/vsts-tasks/issues/5259
https://github.com/Microsoft/vsts-tasks/issues/1607#issuecomment -349115532
@davidebbo , können wir dieses Problem abschließen?
Obwohl ein Wiederholungshelfer für die Webbereitstellung hinzugefügt wurde, besteht dieses Problem weiterhin.

Ich wollte nur auf das Offensichtliche hinweisen, dass dies auch das FTP-Publishing betrifft.

@jeremycook FTP ist etwas anders, da es keine Automatisierung für die Verwendung von App_Offline hat. Sie müssten diese Datei manuell erstellen, damit der Prozess beendet wird, wonach Sie Dateien kopieren könnten.

@davidebbo fair genug, aber es scheint, als ob es einfach funktionieren sollte, wenn ich mit der Veröffentlichungsfunktion von Visual Studio über FTP veröffentliche. Vielleicht poste ich an der falschen Stelle?

@jeremycook Ehrlich gesagt bin ich mir nicht sicher, was VS bei der FTP-Bereitstellung macht. Vielleicht können andere glänzen, aber es scheint eher eine VS-Frage als ASP.NET zu sein.

Um zu isolieren, wäre es jedoch interessant zu testen, ob die Bereitstellung erfolgreich ist, wenn Sie App_Offline.html manuell erstellen und dann von VS per FTP veröffentlichen.

@vijayrkn Können Sie das VS-Verhalten während der FTP-Bereitstellung kommentieren?

Die FTP-Veröffentlichung von VS zum App-Dienst unterstützt App_Offline nicht.

@vijayrkn ok, also können wir aus praktischen Gründen sagen, dass die .NET Core-Bereitstellung über FTP nicht unterstützt wird, es sei denn, der Benutzer stoppt die Website ausdrücklich vor der Bereitstellung. Rechts?

@davidebbo - Ja, das ist richtig.

Dieses Problem tritt auf, wenn die asp.net Core 2.0-Web-App in IIS von der VSTS-Version mithilfe der IIS-Webbereitstellungsvorlage bereitgestellt wird. Das Löschen schlägt aufgrund einer verwendeten Datei fehl. App-Offline-Option ist aktiviert.

@davidebbo @vijayrkn @shirhatti das ist alles ein bisschen deprimierend. Gibt es Pläne, FTP/XCOPY zum Laufen zu bringen? Sollte ein neues Thema eröffnet werden, das sich auf die Bereitstellung der altmodischen Methoden über FTP/XCOPY/ROBOCOPY/etc. konzentriert?

Ich bin zu spät zu dieser Party, aber hier sind ein paar Dinge, die ich berichten möchte:
GEGEN 2017 Enterprise
asp.net 4.6.xx
Server ist IIS 8.5 auf Server 2012 R2
SQL-Servertypen DLLs sind gesperrt und die Sperre ist so, wenn ein anderer Entwickler eine Veröffentlichung mit msdeploy durchführt, erhalten sie eine Fehlermeldung und die Website ist jetzt defekt, da nur ein Teil der Bereitstellung ausgeführt wurde.

Die SQL-Typ-DLLs sind im App-Bin-Ordner gesperrt und nur sie.
Benennen Sie die DLL-Dateien um und dann kann ich veröffentlichen.
Das SQL-Types-Paket enthält Code zum Laden der nicht verwalteten DLLs.
Scheint so, als ob das geändert werden sollte, um sie nicht zu sperren. wenn das geht.

Ich habe gesehen, wie Leute über Möglichkeiten gesprochen haben, die Site neu zu starten oder sie offline zu schalten, aber ich habe keine Einstellung in msdeploy dafür gefunden. Das XML, das ich gesehen habe, ist nicht in meinen Dateien.

Eine bessere Anleitung sollte dem von Microsoft veröffentlichten SQL Types-Paket hinzugefügt werden.

Posting zu diesem Thema, da es direkter mit meinem zu tun zu haben scheint. Ich habe auch das folgende Problem zum selben Thema verfolgt, obwohl es für VSTS gilt. Ich veröffentliche direkt aus Visual Studio.

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

Dies war ein ein- und ausgeschaltetes Problem für mich, ist aber kürzlich wieder in Kraft getreten, und auf einer meiner App-Service-Sites erhalte ich diesen Fehler bei fast allen Veröffentlichungsversuchen. Diese Website wird auf einem „Basis“-Level-Service gehostet, daher habe ich keine Slots, die ich in anderen Apps verwende, um dieses Problem zu umgehen.

Dies ist für eine .net Core 2 mvc-Anwendung.

Ein Gedanke: Einige Dateien, die Teil einer Web-App sind, ändern sich nicht bei jeder Veröffentlichung (wie die SQL-Typen).
aber die MS-Bereitstellung versucht, sie bei jeder Bereitstellung zu ersetzen.
Es scheint, als ob eine Art Überprüfung stattfinden sollte, um eine Datei, die sich nicht geändert hat, nicht erneut zu kopieren, und das würde das Update kleiner und schneller machen und weniger mit der Dateisperre herumspielen müssen.
mehrere Vorteile, wenn dies möglich ist.

Die andere Sache ist, besser zu identifizieren, was die Datei sperrt und warum und wie dies rückgängig gemacht werden kann.
und erhalten Sie dies als Teil der standardmäßigen Bereitstellungspipeline.

@figuerres Ich wollte mich schon seit ein paar Monaten mit diesem Problem befassen. Sperrprobleme werden normalerweise durch Schattenkopien vermieden, aber durch das Laden dieser nativen DLLs aus ~/bin entsteht ein Sperrproblem. Ich habe eine mögliche Lösung, bin mir aber nicht sicher, ob es eine absolut sichere Lösung ist: https://stackoverflow.com/questions/47796553/is-it-safe-to-manually-copy-native-dlls-to- ein-Schattenkopie-Verzeichnis

Ich stimme zu, dass die Dokumentation für das NuGet-Paket eine bessere Methode bereitstellen sollte, die keine Sperrprobleme verursacht.

@figuerres FYI, ich habe das Obige implementiert, siehe Stack Overflow-Frage für den Code.

Beenden Sie dotnet.exe im Task-Manager

Wie ist hier der Stand? 3 Jahre später immer noch nicht behoben. Ich muss manuell zum Server gehen und die Website stoppen.

3 Jahre? Das Problem wurde im August 2017 gemeldet. Off by 1 like whoa.
Am Mo, 23. April 2018 um 20:56 Uhr Oliver Janik [email protected]
schrieb:

Wie ist hier der Stand? 3 Jahre später immer noch nicht behoben. Ich muss manuell gehen
zum Server und stoppen Sie die Website.

—
Sie erhalten dies, weil Sie diesen Thread abonniert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/aspnet/Home/issues/694#issuecomment-383768450 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/AAXhfrhOTvZn2qb4kU-Y1Kg9I-IQKD9yks5trnhXgaJpZM4FJp_R
.

Der allererste Post sagt: „pekkah hat diese Ausgabe am 23. Juni 2015 geöffnet“

Du hast recht. Mein Fehler. Ich habe nur den letzten Zeitstempel in der E-Mail-Kette gesehen.
Am Mo, 23. April 2018 um 21:06 Uhr Oliver Janik [email protected]
schrieb:

Der allererste Beitrag sagt "pekkah kommentierte am 23. Juni 2015"

—
Sie erhalten dies, weil Sie kommentiert haben.

Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/aspnet/Home/issues/694#issuecomment-383769982 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/AAXhfgwYG-jLjnoJF7MCMtzbbfxSZkt2ks5trnqXgaJpZM4FJp_R
.

Schließung, weil das so alt wie Dreck ist 😄

@Eilon Entschuldigung, aber warum wurde das geschlossen? Es ist immer noch ungelöst?

Schließung, weil das so alt wie Dreck ist 😄

Aber es ist immer noch ein Problem .. ? (sogar bei Nicht-Azure-Bereitstellungen)

Erstellte eine neue Ausgabe (#3719), um die Sichtbarkeit zu erhöhen.