Aspnetcore: La implementación falla debido a un archivo en uso

Noté un problema similar con el bloqueo de archivos IIS en máquinas virtuales de Azure que impedía la implementación de WebDeploy. Mi solución es emitir tres comandos de WebDeploy: detenga AppPool, implemente y reinicie AppPool. Ver mi guión ; y si tiene la capacidad de ejecutar tres comandos WebDeploy, es posible que pueda hacer algo similar con Azure Apps.

Conseguir este problema en beta6.

¡Aquí igual! Hace que mi Visual Studio 2015 se congele en realidad, al publicar mi aplicación vNext (tanto beta6 como beta7, creo).

¿Está utilizando los scripts proporcionados por Microsoft para realizar la implementación? Si es así, simplemente puede agregar una línea en PublishAspNet5Website.ps1 para reiniciar la aplicación web:

Restart-AzureWebsite -Name $websiteName

Tengo mis modificaciones del script de compilación descritas en esta publicación: Resolver un problema de implementación de ASP.NET 5 en la ranura de la aplicación web de Azure

@brandonmartinez , Reiniciar un sitio web no ayudará, ya que un sitio web de producción seguirá recibiendo solicitudes, lo que, por lo tanto, volverá a bloquear los archivos. Actualmente, la única forma confiable de actualizar un sitio web tanto de IIS como de Azure es cerrar el grupo de aplicaciones del sitio web, luego actualizar los archivos y luego reiniciar el sitio web. Simplemente siga el enlace de @GuardRex para obtener más detalles.

Sin embargo, no deberíamos necesitar perder el tiempo con scripts de implementación personalizados cuando trabajamos en condiciones predeterminadas con VS2015.

Con suerte, la nueva infraestructura HttpPlatformHandler (que ya no necesita un AspNet.Loader.dll) será un poco más indulgente, pero no estoy conteniendo la respiración aquí. Probablemente obtengamos otro .dll bloqueado.

@rubenprins Esa es la solución que uso también, a través de las herramientas de Azure SDK en VS.

Hay comandos PS para hacerlo si puede obtener acceso PS a la VM. https://github.com/GuardRex/net5-iis-ps-publish/blob/7623122dbfdc55a7c53c8edd2e97443e0eea22c9/net5-iis-ps-publish.ps1#L389 -L396

aspnet/vsweb-publish también es muy interesante; sin embargo, parece que usa offline-template.html , y pensé que se descubrió que ese método no evitaría el problema de bloqueo de dll... solo detener AppPool, implementar y reiniciar AppPool ha sido estable, enfoque de trabajo.

no deberíamos necesitar perder el tiempo con scripts de implementación personalizados cuando trabajamos en condiciones predeterminadas con VS2015

Sin embargo, se me ocurrió una cosa: poder usar 'Publicar en el sistema de archivos' y conectar un script justo después de la publicación que tiene bits de MSDeploy ha permitido una historia de implementación muy simple y útil para múltiples máquinas virtuales. Dado que el script se ejecuta secuencialmente, simplemente va de máquina virtual a máquina virtual en la línea. Hace un buen descanso para tomar café. :sonreír:

Tengo una pregunta en Introducción a la configuración de un equilibrador de carga orientado a Internet mediante Azure Resource Manager con el equipo de Azure Resource Manager preguntando cómo decirle al equilibrador de carga que deje de enviar tráfico a la máquina virtual temporalmente mientras realiza la implementación.

En fin... volviendo al tema que nos ocupa que planteó @pekkah . Como sabemos que los comandos de PS funcionan, busque opciones para ejecutarlos en una compilación de VSO:

Microsoft/vso-agent-tareas
Ejecute un script en su proceso de compilación
Ejecución de scripts preconstruidos en Team Foundation Service (Visual Studio Online) para el proceso de compilación de Azure Continuous Deployment
Nuevas funciones de automatización de compilaciones en Visual Studio Online

... sí ... algo así debería funcionar para ti.

El mismo problema aqui...

Sigo esperando una solución oficial.

Bruno

Esto se resolverá mediante https://github.com/aspnet/IISIntegration/issues/81.

@moozzyk , ese problema solo solucionará la implementación a través de herramientas dedicadas como msdeploy. La implementación de Xcopy/File sync aún no sería posible, lo que también bloqueará/obstaculizará muchos escenarios de CI que solo funcionan con ASP.NET v1-4.

El problema aún existe en ASP.NET Core 1.0 RC2 con Visual Studio 2015.2 MSDeploy para IIS 8 en Windows 2012 R2 con las herramientas más recientes para el servidor. Matar el proceso dotnet.exe o reciclar el grupo de aplicaciones resuelve el problema. Pero eso necesita acceso de escritorio remoto al servidor y no es exactamente un proceso fluido.

@dg9ngf : este es un error en web.deploy ahora. Agregaron la funcionalidad app_offline.htm para Azure, pero está deshabilitada de forma predeterminada cuando se implementa localmente. Intente abrir su perfil de publicación (PublishProfiles->*.pubxml) y cambie:

<EnableMSDeployAppOffline>False</EnableMSDeployAppOffline>

para

<EnableMSDeployAppOffline>True</EnableMSDeployAppOffline>

Si esto no funciona, pregunta a @vijayrkn

Si utiliza herramientas de VS para publicar con un perfil de msdeploy, esta propiedad se agrega automáticamente a su pubxml.

<EnableMSDeployAppOffline>True</EnableMSDeployAppOffline>

En su ventana de salida, debería ver un comando msdeploy similar a este.

"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 en el comando debe encargarse de agregar appOffline durante la implementación.

Si se necesita contenido appOffline personalizado, puede establecer esta propiedad en pubxml.

<AppOfflineTemplate>Path to app offline</AppOfflineTemplate>

Esa propiedad _no_ estaba presente en el archivo .pubxml que creó Visual Studio. Así que lo agregué pero no cambió nada. El argumento -e nablerule:AppOffline _no_ aparece en la ventana de resultados.

¿Puede compartir la línea de comandos de msdeploy que se muestra en la ventana de salida?

Además, ¿puede confirmar que pubxml tiene WebPublishMethod como 'MSDeploy'?
<WebPublishMethod>MSDeploy</WebPublishMethod>

No, el archivo tiene esto en su lugar: <WebPublishMethod>FileSystem</WebPublishMethod>

Aquí está la línea de comando de la ventana de resultados: 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]

Estoy implementando usando la tarea "Azure Web App Deployment" en VSTS, como se describe en esta publicación de blog: http://donovanbrown.com/post/2016/05/30/DevOps-for-ASPNET-Core-RC2

¿Hay alguna manera de especificar el <EnableMSDeployAppOffline>True</EnableMSDeployAppOffline> usando ese método?

Hola, tuve el mismo problema en Azure, lo resolví de esta manera https://github.com/davidebbo/WAWSDeploy/issues/14

@dg9ngf En la versión actual del script de PowerShell, admitimos appOffline solo para WebPublishMethod - 'MSDeploy'.

La compatibilidad con AppOffline para la publicación del sistema de archivos estará disponible en la próxima versión.

@bojingo estoy en la misma situacion. ¿Te diste cuenta de esto?

@davenewza : Si vuelve a visitar esa publicación de blog, la solución está en los comentarios.
http://donovanbrown.com/post/2016/05/30/DevOps-for-ASPNET-Core-RC2

Básicamente, debe agregar pasos VSTS para detener/iniciar el sitio. Muy lejos de ser una solución ideal (en realidad, bastante aburrida), especialmente porque no estoy usando ranuras de implementación, pero funciona bien para nuestro entorno de desarrollo/prueba.

Hay una nueva versión ARM de vista previa de la tarea VSTS de implementación de aplicaciones web que está basada en msdeploy y promete solucionarlo, pero no tuve suerte porque necesitaba que el cliente creara una entidad de servicio para la suscripción, y eso fue una molestia. Tal vez puedas hacer que funcione:
https://github.com/Microsoft/vsts-tasks/tree/master/Tasks/AzureRmWebAppDeployment

@vijayrkn El cuadro de diálogo Publicar web en VS2015 no contiene ninguna opción para configurar msdeploy; solo brinda las opciones para WebPublishMethod=FileSystem.

¿Puede proporcionar un .pubxml de muestra para WebPublishMethod=msdeploy, por favor?

@tomfanning Para una aplicación de consola central de ASP.NET, la única opción de publicación actualmente disponible es el sistema de archivos. ¿Está intentando publicar una aplicación de consola? Para una aplicación web, estas 4 opciones deberían estar disponibles (webdeploy, paquete de implementación web, sistema de archivos y ftp).
Muestra webdeploy pubxml: https://github.com/dotnetpublish/AspNetCoreBlogList/tree/master/src/AspNetCoreBlogList/Properties/PublishProfiles

Si es una aplicación web y solo ve la opción de publicación del sistema de archivos, ¿puede verificar el xproj para ver si importa esto?
<Import Project="$(VSToolsPath)\DotNet.Web\Microsoft.DotNet.Web.targets" Condition="'$(VSToolsPath)' != ''" />

@bojingo Pude configurar el principal del servicio, hay varios tutoriales en la red. No tengo los enlaces aquí, pero puedo buscarlos si los necesitas. Ahora mi problema es que la tarea requiere un archivo de parámetros.xml que no se genera en la publicación de ASP Net Core... :(

Tengo TFS 2015 local y sigue siendo un problema increíblemente molesto.

Yo también me estoy encontrando con este problema...

Mi solución fue mantener detenido el espacio de ensayo que implemento y luego publicarlo (el intercambio automático funciona). Reiniciar y luego implementar no funcionó (implementar con VSTS)

Estoy usando Octopus con Azure Web Apps, que no presenta una opción para las ranuras de ensayo. Sin embargo, la comprobación de las siguientes opciones parece haber funcionado:

• Desactive de forma segura el dominio de la aplicación con app_offline.html en blanco en la raíz.
• Eliminar archivos en el destino que no forman parte de la implementación

Estoy usando Visual Studio 2015 Update 3 para publicar un sitio asp.net core 1.1/.net framework 4.5.2 en IIS. Se despliega App_Offline.htm que no elimina el sitio. Si cambio el nombre en el servidor a app_offline.htm el sitio se cae.

Según este app_offline.htm no debe distinguir entre mayúsculas y minúsculas.

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

El implementador carga app_offline.htm (no distingue entre mayúsculas y minúsculas)

Acabo de publicar de nuevo y veo que se cayó App_Offline.htm y mi sitio no se cayó y aparece el error de archivo en uso. Cuando lo cambio a app_offline.htm mi sitio deja de funcionar y puedo publicarlo sin errores.

Estoy alojando en una ruta UNC compartida; no sé si eso hace la diferencia.

@Tratcher : ¿sabe por qué la carcasa de App_Offline.htm marcaría la diferencia aquí?

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

Pude resolver este problema agregando una configuración de Azure de

MSDEPLOY_RENAME_LOCKED_FILES = 1

... como se describe aquí:
https://github.com/Microsoft/vsts-tasks/issues/1607#issuecomment-260946957

YMMV

@BenBarreth ¿Hay algo similar aplicable a los que no son de Azure?

no que yo sepa lo siento @jdshkolnik

Parece que puede haber problemas con MSDEPLOY_RENAME_LOCKED_FILES = 1. Ayuda a que la implementación tenga éxito, pero puede significar que las nuevas DLL no se detectan en tiempo de ejecución:
https://github.com/Azure/azure-webjobs-sdk-script/issues/569#issuecomment-264490818

Eso no me parece una "solución" adecuada. Simplemente oculta el error de implementación.

Es posible que se describa una solución verdadera en este problema:
https://github.com/Azure/azure-webjobs-sdk-script/issues/1023

Realmente buscando una solución a esto. Parecía que la tarea VSTS de implementación web de RM se encargó de esto con la opción "Take App Offline" seleccionada, pero a partir de este fin de semana recibimos errores constantemente. Hemos vuelto a detener la ranura de implementación, implementar y comenzar de nuevo.

Del mismo modo, este problema surgió el viernes de la semana pasada y nos ha impedido desplegar desde entonces...

Aquí igual. Parece que solo afecta a los sitios con Siempre activado = verdadero, pero eso no es seguro.

Todavía tengo este problema incluso cuando configuro MSDEPLOY_RENAME_LOCKED_FILES = 1 en mi configuración. Es casi imposible actualizar la compilación en mi servidor ahora. Esto acaba de empezar a suceder hace unos días.

El mismo problema ha comenzado a ocurrir para mí esta semana. Hasta esta semana, la implementación de un servicio de aplicaciones de AzureRM en VSTS con la configuración Desconectar la aplicación = verdadero funcionó de manera consistente. Ahora, esta configuración parece ignorarse o el servicio no se desconecta a tiempo. Tengo que reiniciar manualmente o detener/iniciar el servicio de la aplicación mientras ejecuto la versión para que exceda demasiado.

Mismo problema aquí. AzureRm estuvo funcionando durante meses y de repente se detuvo. Mi última implementación fue hace dos semanas el 5/12 y ahora el 20/12 está generando el Error_File_In_Use. Muy molesto por tener que volver al inicio/parada manual.

Esta es nuestra solución alternativa en Powershell que estamos usando por ahora como parte de nuestro proceso de compilación/CI. Un agradecimiento especial a los chicos de @appveyor por ayudar con esto:

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

Esto hace uso de la API REST de Kudu para HTTP PUT el archivo app_offline.htm correctamente en mayúsculas en su lugar. Tenemos WebDeploy configurado para eliminar cualquier archivo que no esté en la implementación, por lo que elimina automáticamente el archivo como parte de la implementación. Es posible que deba repetir el paso usando un HTTP DELETE para eliminar el archivo después de que su implementación haya finalizado si no está usando este modo.

Agregar una parada de Trackyon antes de la tarea de AzureRM y una tarea de inicio de Trackyon después funciona bien para mí. Esto no debería ser necesario con TakeAppOffline = true, pero funciona y evita las secuencias de comandos o manuales. Simplemente agregue la tarea a la definición de lanzamiento. Los pasos de Trackyon son fáciles de configurar

El 21 de diciembre de 2016, a las 00:10, Chad T < [email protected] [email protected] > escribió:

Esta es nuestra solución alternativa en Powershell que estamos usando por ahora como parte de nuestro proceso de compilación/CI. Un agradecimiento especial a @appveyor https://github.com/appveyor chicos por ayudar con esto:

$nombre de usuario = $ env:deployusername
$contraseña = $ env:contraseña de implementación
$base64AuthInfo = [Convertir]::ToBase64String([Texto.Codificación]::ASCII.GetBytes(("{0}:{1}" -f $nombre de usuario,$contraseña)))
$Encabezados = @{
'Autorización' = ('Básico {0}' -f $base64AuthInfo)
'Si-Coincide' = '*'
}
$apiUrl = " https://SuSitioWebAzure.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"

Esto hace uso de la API REST de Kudu https://github.com/projectkudu/kudu/wiki/REST-API para HTTP PONER el archivo app_offline.htm correctamente en mayúsculas en su lugar. Tenemos WebDeploy configurado para eliminar cualquier archivo que no esté en la implementación, por lo que elimina automáticamente el archivo como parte de la implementación. Es posible que deba repetir el paso con HTTP DELETE para eliminar el archivo después de que finalice la implementación si no está utilizando este modo.

-
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub https://github.com/aspnet/Home/issues/694#issuecomment-268436959 , o silencie el hilo https://github.com/notifications/unsubscribe-auth/AID9WoUdbuBnFoXR2K5o8AiUtv8nE9dRks5rKLTcgaJpZM4FJp_R .

Este mensaje no es público y puede contener información privilegiada, patentada o confidencial. Si lo ha recibido por error, notifique al remitente de inmediato y elimine todas las copias del original. Cualquier otro uso del correo electrónico por su parte está prohibido. Cualquier copia, almacenamiento, uso o divulgación no autorizados del contenido de este mensaje no está permitido y puede ser ilegal. Donde lo permita la ley local, las comunicaciones electrónicas con Lithero pueden ser monitoreadas y escaneadas por nuestros sistemas con el fin de garantizar la seguridad de la información y evaluar el cumplimiento interno de las políticas de Lithero y las leyes aplicables.

/ cc @davidebbo

Intente establecer MSDEPLOY_RENAME_LOCKED_FILES=1 en la configuración de la aplicación de Azure para su aplicación.

@davidebbo esto no parece resolver las cosas.

¿Supongo que esto está relacionado con un cambio en el lado de Azure de la valla? Muchas personas (especialmente en el canal de slack de aspnet) han tenido este problema al mismo tiempo.

Un cambio en Azure no explicaría por qué vemos esto en las instalaciones con TFS. ¿Podría ser el agente?

Estamos viendo el mismo problema. App_Offline.htm no se recoge. Por extraño que parezca, si implementamos desde VS, funciona bien.

Curiosamente, para mí no funciona desde VS, como se describe aquí: #1883

Mi equipo también se encuentra con este problema, casi cada vez que falla la implementación debido a un archivo bloqueado. Debe reiniciar todas las aplicaciones en Azure y volver a ejecutar la implementación. Estamos usando Octopus Deploy.

Mi equipo encontró este problema esta mañana. ¿Algún comentario del equipo de Microsoft? La tubería de lanzamiento es fundamental para nuestra productividad, esto impide los lanzamientos a los sitios de producción. ¡Gracias!

@bmoscao - app_offline.html distingue entre mayúsculas y minúsculas.

Este problema también me ha aparecido en Azure. Nada de lo que he hecho por mi parte para causarlo.

Estoy teniendo este problema también. El problema es que EnableMSDeployAppOffline está configurado en true , y el resultado del proyecto muestra -enablerule:AppOffline como parte del comando que ejecuta Visual Studio. No estoy seguro de qué hacer... Empecé a tener este problema recientemente...

Nuestra solución para esto fue detener el grupo de aplicaciones, implementar y luego reiniciar el grupo de aplicaciones. Estamos utilizando Release Manager y el complemento PowerShell en línea para lograr esto.

Detener:

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

Comienzo:

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

Sin embargo, definitivamente agradecería algunos aportes de Microsoft, esto solía funcionar muy bien con solo habilitar la regla appOffline en el paso de implementación de RM Azure.

@davidebbo Usamos ASP.NET Core, VSTS Release Manager y AzureRmWebApp con ranuras.

@davidebbo gracias! Esto funciona para mi ;)

También nos está pasando a nosotros: msdeploy to Azure. Me alegra ver que misteriosamente comenzó para varias personas al mismo tiempo, y no somos solo nosotros, ¡pero no es muy tranquilizador en general!

No creo que la gente de MS necesite confirmación para esto, probablemente saben bien cuál es el problema. En cualquier caso, lo mismo aquí. Desplegando desde VSTS, dejó de funcionar a principios de diciembre. En este momento estoy usando la tarea trackyon para detener/iniciar.

Al revisar este hilo, para cada entrada, no siempre está claro:

1. si el problema se refiere a Azure App Service o algún otro alojamiento
2. si las personas han intentado cambiar la carcasa app_offline como se discutió anteriormente. Parece que varias personas reportaron éxito allí.
3. si se probó MSDEPLOY_RENAME_LOCKED_FILES . Nuevamente, varias personas parecen haber tenido éxito con eso.

Si se encuentra con este problema, sea muy explícito cuál es su escenario y qué ha intentado, para que podamos entenderlo. ¡Gracias!

@davidebbo

Recibo el mensaje ERROR_FILE_IN_USE cuando intento implementar con Visual Studio/MSBuild. La tarea es crear un archivo App_Offline.htm en el servidor, pero no elimina la aplicación.

La creación de un archivo app_offline.htm mediante Web Deploy elimina la aplicación.

Esta es mi configuración:

• Servidor: IIS 8, .NET Core Windows Server Hosting 1.1.0 y Web Deploy 3.6
• Mi máquina: Visual Studio 2015 Update 3 y .NET Core 1.0.1 Tools Preview 2
• Publicar perfil:

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

He comentado este error en un hilo similar y he tenido que detener y reiniciar mi aplicación web de Azure cada vez que quiero volver a implementar (solo en el entorno de desarrollo). Nunca tuve que hacer esto antes de esta semana. Decidí básicamente crear una aplicación web principal de Visual Studio 2015 .net a partir de la plantilla sin ninguna modificación.

Ejecuté la aplicación web en el host local sin ningún problema.
Publiqué la nueva aplicación en mi Azure Web App Service Plan sin problemas y el navegador abrió inmediatamente el sitio sin problemas.
Revisé Azure Dashboard y no tuve ningún problema.

Luego fui y volví a publicar la aplicación web sin modificar nada, ni el código ni la configuración, y se presenta el siguiente error.

A partir de ese momento, tengo que detener la aplicación web, publicar en Azure y luego iniciar la aplicación web. Esto nunca me había pasado antes. Esta es una implementación muy simple de la plantilla de Microsoft.

Grabé todo este proceso y envié esos comentarios dentro del sistema de comentarios de Microsoft 2015 VS. Espero que puedas encontrar esa grabación. O probablemente podría hacerlo de nuevo.

Saludos Pedro

@davidebbo

si el problema se refiere a Azure App Service o algún otro alojamiento

Servicio de aplicaciones de Azure.

si las personas han intentado cambiar la carcasa app_offline como se discutió anteriormente. Parece que varias personas reportaron éxito allí.

Cambiar App_Offline a app_offline soluciona el problema: este archivo se crea a través de webdeploy automáticamente con la carcasa 'App_Offline' como parte de la implementación, que es el quid del problema.

@davidebbo
Exactamente lo mismo que @ctolkien.

@davidebbo

si el problema se refiere a Azure App Service o algún otro alojamiento

En mi caso, estoy implementando en Azure App Service. No sé acerca de otros alojamientos.

si las personas han intentado cambiar la carcasa app_offline como se discutió anteriormente. Parece que varias personas reportaron éxito allí.

Estoy usando la tarea "Implementar la aplicación web de AzureRM" de VSTS (https://aka.ms/azurermwebdeployreadme). Hay una opción "Publicar usando Web Deploy" <- marcada y "Desconectar la aplicación" <- marcada que solía funcionar, hasta que algo cambió en algún lugar y dejó de funcionar.
La información sobre herramientas "info" informa explícitamente sobre la colocación de "app_offline.htm" con minúsculas "a".
No estoy seguro de cómo cambiarlo usando este script, ya debería estar en minúsculas.

si se probó MSDEPLOY_RENAME_LOCKED_FILES. Nuevamente, varias personas parecen haber tenido éxito con eso.

No probado. No sé cómo hacer eso. Pero en cualquier caso, preferiría desconectar la aplicación en lugar de cambiar el contenido de los archivos bloqueados.

Gracias a todos. Entonces, parece claro que el problema principal es con la carcasa de app_offline.htm , y no con nada relacionado con Azure App Service (que es el lado del que vengo). Y esto es rastreado por https://github.com/aspnet/AspNetCoreModule/issues/50.

Sugiero cerrar este tema y mantener ese otro. Dejaré que los expertos de ASP.NET tomen las cosas a partir de ahí, a menos que haya razones para pensar que Azure Web App tiene parte de la culpa (poco probable según @fabiano informando lo mismo fuera de Azure).

En realidad, esto parece una regresión en las herramientas donde parece haber comenzado a crear App_Offline.html en lugar de app_offline.html. @mlorbetske , @vijayrkn : ¿alguna idea de qué puede ser?

Ya veo, ¿está diciendo que el tiempo de ejecución principal (AspNetCoreModule) siempre distinguía entre mayúsculas y minúsculas, pero que no solía ser un problema porque VS estaba usando el caso coincidente y ahora no lo es?

Aunque independientemente, diría que el tiempo de ejecución no debería distinguir entre mayúsculas y minúsculas aquí, por lo que hay dos caminos posibles para abordar el problema.

@davidebbo - esto es correcto. Creo que AspNetCoreModule siempre fue sensible a mayúsculas y minúsculas.

@davidebbo

y nada relacionado con Azure App Service (que es el lado del que vengo)

Supongo que la razón para traer Azure AppService a la discusión es porque sin ningún cambio en nuestro nombre, las cosas empezaron a fallar, no cambiamos ninguna de las versiones de nuestros paquetes. ¿Se revisó la revisión de ANCM en App Services?

@ctolkien sí, creo que de hecho se actualizó. Así que bien podría ser que la conclusión anterior no sea correcta. En cambio, la nueva teoría es:

• El ANCM más antiguo (7.1.1965.0) no distinguía entre mayúsculas y minúsculas.
• El más nuevo (7.1.1970.0) se volvió sensible a mayúsculas y minúsculas.
• Nada cambió en el lado de la publicación de VS, y la carcasa siempre ha sido App_Offline.htm .

@moozzyk , ¿crees que es una posibilidad, o estás seguro de que siempre se distinguieron entre mayúsculas y minúsculas?

@moozzyk @davidebbo : no hubo cambios en las herramientas VS para la carcasa app_offline. Las herramientas de VS llaman a msdeploy con la regla appoffline (-enablerule:AppOffline) y msdeploy descarta App_Offline.htm.

Este problema parece un cambio de comportamiento en ANCM. Según el primer comentario aquí, app_offline debe distinguir entre mayúsculas y minúsculas (https://github.com/aspnet/IISIntegration/issues/81).

@ctolkien

Cambiar App_Offline a app_offline soluciona el problema

¿Dónde cambio esto? Hago MSDEPLOY directamente desde Visual Studio a Azure.

@oyvindvol

¿Dónde cambio esto? Hago MSDEPLOY directamente desde Visual Studio a Azure.

Hasta donde yo sé, no puede cambiar la carcasa de App_Offline de MSDEPLOY, necesitará una solución de script personalizada por ahora. Puede usar el script de powershell que publiqué anteriormente como punto de partida.

Para actualizar a todos, confirmamos que la teoría anterior es correcta: el error de distinción de mayúsculas y minúsculas es una regresión en la versión más reciente de ANCM, y esa versión se implementó en Azure App Service en diciembre, lo que provocó que los usuarios lo detectaran repentinamente.

El plan es obtener una corrección de ANCM del equipo de ASP.NET Core e implementarla en App Service. Todavía no hay ETA, pero debería suceder en algún momento de enero.

¡Gracias!

@davidebbo , ¿podremos descargar ANCM para instalarlo en nuestro propio servidor usando iis y encontrar este error en particular también?

@Pictuel , creo que sí. Tenga en cuenta que mi punto de vista aquí es estrictamente el Servicio de aplicaciones de Azure, por lo que dejaré que el equipo central comente sobre escenarios que no sean de Azure.

Gracias por el aviso :)

@Pictuel sí, nos aseguraremos de que se publique una versión actualizada del instalador de hospedaje de Windows para .NET Core que contenga la actualización de ANCM.

@shirhatti

@shirhatti Estoy monitoreando aquí cuando el instalador actualizado está disponible para actualizar los enlaces de documentos.

Después de pasar por ese hilo, no estoy realmente seguro de cuál es exactamente la solución para App Services. ¿Es la configuración de la aplicación o está usando un script de implementación personalizado o está deteniendo e iniciando el sitio?

Si es la configuración de la aplicación, he leído otro comentario que dice que hace que el sitio web no recoja las nuevas DLL.

Si entendí correctamente, no hay una solución alternativa de nuestra parte hasta que haya una actualización disponible en ANCM (https://github.com/aspnet/AspNetCoreModule/issues/50). El equipo de Azure debe actualizar los servicios de la aplicación.

Creo que lo mejor que puede hacer en App Service es detener/iniciar la aplicación como lo describe @dtmnash aquí .

@davidebbo "El plan es obtener una corrección de ANCM del equipo de ASP.NET Core e implementarla en App Service. Todavía no hay ETA, pero debería suceder en algún momento de enero". -- Háganos saber cuando una ETA esté lista en esto :)

El despliegue tentativo ETA es entre el 24 y el 30. La implementación ocurre gradualmente en muchas unidades de escala, por lo que no todos obtendrán la corrección al mismo tiempo.

Gracias, para mí acaba de empezar a funcionar :-)

Sigue siendo un problema para mí :(

@hbunjes gracias por confirmar!

@rsnj está sucediendo progresivamente durante un período de tiempo. Todo debería estar listo para fin de mes (a menos que tengamos un problema).

@davidebbo La implementación parece funcionar para algunas de mis aplicaciones, pero no para todas. Lo extraño es que algunas implementaciones fallan pero otras no para aplicaciones que se ejecutan en el mismo plan de servicio de aplicaciones. ¿Es posible ver qué versión de ANCM se está ejecutando para una aplicación web en particular?

@henningst Consulte https://github.com/aspnet/AspNetCoreModule/issues/50#issuecomment -271381892 para conocer una forma de verificar.

Ayer no me funcionó, pero ahora sí. ¡Gracias @davidebbo!

Me empezó a funcionar a mí también. ¡Gracias!

Sí, la implementación ya está completa, por lo que debería funcionar para todos.

Todo bien para mí aquí también.

Parece estar funcionando ahora. Según el informe, se necesitaron más de un año para solucionar este problema. Hubiera pensado que los problemas de implementación tienen mayor prioridad: p

¿Cómo solucionar esto para los que no son de Azure?

@pekkah Creo que pasó por distintos problemas. El último fue mucho más reciente que un año.

@jdshkolnik para personas que no sean de Azure, supongo que solo necesita comenzar a usar el nuevo ANCM.

@jdshkolnik
La actualización ha estado disponible para su descarga en https://www.microsoft.com/net/download/core#/runtime
Este es un enlace directo a la descarga.

@shirhatti Instalé esto pero sigo recibiendo estos errores.

Sigo recibiendo el error en Sao Paulo, Sur de Brasil.

@jdshkolnik ¿Qué versión ve cuando ejecuta esto en PowerShell?

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

@shirhatti 7.1.1971.0

Actualización : lo siento, esto fue mi culpa. Estaba revisando y actualizando los pasos de implementación de una versión existente en lugar de la definición de la versión. He perdido la cuenta de cuantas veces he hecho esto...

Todavía me encuentro con este error cada vez que intento implementar, aunque mi versión de aspnetcore.dll es la que supuestamente está arreglada.

aspnetcore.dll versión : 7.1.1971.0
Implementado con : tarea VSTS Azure App Service Deploy v3.* (versión preliminar)
Desconectar la aplicación : marcado
Eliminar archivos adicionales en el destino : Marcado
Renombrar archivos bloqueados : marcado
Configuración de la aplicación MSDEPLOY_RENAME_LOCKED_FILES : no agregada

En esta etapa, no me queda claro qué configuraciones se requieren o no para que esto funcione.

Acabo de tener mi primer problema de archivo en uso nuevamente ahora en los servicios de aplicaciones de Azure:

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 Código de error: ERROR_FILE_IN_USE

2017-02-14T22:41:34.3837386Z Más información: Web Deploy no puede modificar el archivo 'Ascend.Ammo.Portal.exe' en el destino porque está bloqueado por un proceso externo. Para permitir que la operación de publicación tenga éxito, es posible que deba reiniciar su aplicación para liberar el bloqueo o usar el controlador de reglas AppOffline para aplicaciones .Net en su próximo intento de publicación. Obtenga más información en: http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_FILE_IN_USE.

2017-02-14T22:41:34.3837386Z Recuento de errores: 1.

FYI: los documentos parecen vincularse a un instalador con la versión anterior (*.1970): https://docs.microsoft.com/en-us/aspnet/core/publishing/iis#install -the-net-core- Paquete de alojamiento de servidor de Windows.

Además, ¿parece que en la página de descargas en tiempo de ejecución solo la versión LTS tiene la solución?

@shirhatti ~Avísame cuando el nuevo enlace del instalador del paquete de alojamiento esté listo, y lo enviaré a los documentos (está en algunos lugares).~

~Es este: https://go.microsoft.com/fwlink/?linkid=837808 ... ese no es un enlace aka.ms aunque.~

Configuré https://github.com/aspnet/Docs/pull/2773 para cubrir esto si el fwlink está bien.

También ocurre en Visual Studio y, como muestran las opciones, la regla sin conexión de la aplicación está presente.

@davidebbo , ¿podría confirmar si esto está solucionado? Escuchando de bastantes personas que todavía lo están golpeando. ¿La versión de lanzamiento de las herramientas tuvo alguna solución para esto o sigue siendo un problema de alojamiento?

También estoy tratando de averiguar por qué y cuándo sucede. Estoy casi seguro de haber visto que el proceso se está ejecutando en el explorador de procesos en el sitio scm y se publicó correctamente.

También estoy en el proceso de actualizar mis sitios a las herramientas más nuevas, con la esperanza de que el problema esté relacionado con las herramientas antiguas de project.json.

La solución se implementó en Azure App Service hace un tiempo y no tengo conocimiento de que nadie siga viendo el problema después. Por supuesto, los usuarios de hosts que no son de Azure pueden seguir viéndolo si no se han actualizado.

Para Azure, si tiene problemas, pruébelo de la siguiente manera:

• Vaya al explorador de procesos de Kudu y asegúrese de que el proceso de su aplicación se esté ejecutando (por lo general, dotnet.exe)
• Cree manualmente un archivo app_offline.htm (por ejemplo, ejecute touch app_offline.htm ) desde el comando Kudu
• Verifique nuevamente el explorador de procesos y asegúrese de que ese proceso ya no esté allí.

Probaré un poco más, ¿viste la imagen algunas publicaciones? Muestra claramente que el archivo está en uso y usa la aplicación sin conexión.

Pero probaré como me pediste.

Además, estamos usando escalabilidad + aplicaciones implementadas en aplicaciones virtuales; no sé si eso cambia algo.

@pksorensen hacerlo 'manualmente' ayudará a aislarse de cualquier cosa que WebDeploy pueda estar haciendo. es decir, si el simple hecho de soltar app_offline.htm no detiene el proceso, entonces realmente sabemos que hay un problema que no es causado por WebDeploy.

Tenga en cuenta que normalmente termina con un proceso dotnet.exe, mientras que en su caso tiene un nombre de exe diferente. Me pregunto si eso de alguna manera se relaciona con el problema.

1. Vaya al explorador de procesos de Kudu y asegúrese de que el proceso de su aplicación se esté ejecutando (por lo general, dotnet.exe)
   Hice esto, pero no es dotnet.exe sino nuestro nombre compilado bin Ascend.Ammo.RegistrationTablet.exe

Luego toqué app_offline.htm, pero esto no eliminó el proceso.

¿Estoy haciendo algo mal ya que no veo dotnet.exe?

Dejaré que los expertos de dotnet/ANCM comenten sobre esa parte. Sé que, de forma predeterminada, al implementar una aplicación ASP.NET central, utiliza dotnet.exe. Creo que el caso cuando no es así es cuando usas la implementación independiente (o como se llame). Pero no tengo idea de cómo afecta eso a ANCM y app_offline.htm.

@DamianEdwards , ¿quién puede comentar mejor sobre esto?

Evito ese problema usando ranuras de implementación. Funciona el 100% del tiempo. Detenga la ranura antes de copiar archivos. Esto eliminará todo lo que esté fuera de la memoria para que su copia funcione sin archivos bloqueados. Luego inicie la tragamonedas y cambie a producción. Beneficio agregado: sus clientes nunca ven la página sin conexión de la aplicación. Obtienen una implementación de tiempo de inactividad de 0.

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

La tragamonedas @DarqueWarrior funciona, por supuesto (y es buena para usar por otras razones), pero la clave en este hilo es entender por qué app_offline parece ineficaz para cerrar el proceso Core para algunas personas como @pksorensen. Y me gustaría que el equipo Core comentara sobre eso.

@davidebbo Para responder a su pregunta anterior, portátil frente a independiente no influye en el comportamiento de app_offline. El archivo sin conexión de la aplicación es supervisado por w3wp.exe (por el módulo ASP.NET Core).

@DarqueWarrior Gracias por el consejo, sin embargo, un comentario: si usted, como nosotros, está implementando múltiples sitios en aplicaciones virtuales en el mismo servicio de aplicaciones, las ranuras (si recuerdo bien) funcionan en todos esos, por lo que tendría que implementar todos los sitios antes intercambio Esto es una molestia. En este momento, podemos implementar fácilmente partes (microservicios) en aplicaciones virtuales individuales. Por supuesto, podemos distribuirlos en servicios de aplicaciones separados, pero luego necesitaríamos equilibradores de carga/puertas de enlace para que compartan el mismo dominio nuevamente, lo que también cuesta más tiempo del que estamos dispuestos a hacer en este momento.

Así que estoy de acuerdo en que lo que sugieres es la forma preferible, simplemente no encaja con nosotros en este momento. Así que todavía espero una resolución sobre el problema del archivo en uso.

@pksorensen , ¿hay alguna posibilidad de que pueda configurar una reproducción en un sitio ficticio y compartir su nombre? Básicamente, me gustaría verlo en el estado en el que se ejecuta su sitio, y la creación manual de app_offline.htm en la consola de Kudu no hace que se apague.

@shirhatti , ¿alguna idea de qué podría causar que ANCM no cierre el proceso? ¿Cuán agresivamente trata de hacer eso?

@davidebbo Me llevará un poco de tiempo, pero intentaré encontrar algo para crear una reproducción.

@davidebbo Creé una nueva aplicación ASP.NET Core y un nuevo Azure App Service. Estoy usando la función "Entrega continua (versión preliminar)" de Azure y tengo este problema.

2017-03-30T02:54:36.5648892Z ##[error]Error al implementar App Service.
2017-03-30T02:54:36.5658893Z ##[error]Código de error: ERROR_FILE_IN_USE
2017-03-30T02:54:37.1850861Z Más información: Web Deploy no puede modificar el archivo 'myApp.dll' en el destino porque está bloqueado por un proceso externo. Para permitir que la operación de publicación tenga éxito, es posible que deba reiniciar su aplicación para liberar el bloqueo o usar el controlador de reglas AppOffline para aplicaciones .Net en su próximo intento de publicación. Obtenga más información en: http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_FILE_IN_USE.
2017-03-30T02:54:37.1860517Z Recuento de errores: 1.
2017-03-30T02:54:37.4179909Z ##[error]Error: C:\Program Files\IIS\Microsoft Web Deploy V3\msdeploy.exe falló con el código de retorno: 4294967295

La creación manual de un app_offline.htm en D:\home\site\wwwroot detiene el proceso dotnet.exe.

Entonces, ¿esto significa que hay un problema con "Entrega continua (vista previa)" en sí?

Además de lo anterior, arreglé esto yendo manualmente a Definición de versión de VSTS, Opciones de implementación adicionales, marcando "Take App Offline".

Pero esto plantea algunas preguntas:
¿Por qué "Desconectar la aplicación" no está marcado de forma predeterminada? ¿Debería seguir funcionando este escenario (por ejemplo, reduce el tiempo de inactividad)?

Si es así, ¿por qué está fallando? Si no, ¿por qué "Entrega continua (vista previa)" no la marca?

De cualquier manera, parece que hay un error en alguna parte.

@ Jon12345 : este hilo solo trata de discutir si app_offline.htm funciona correctamente con las aplicaciones Core. Entonces, el hecho de que VSTS pueda o no estar haciendo esto de forma predeterminada es realmente una discusión separada, que debería tenerse en un foro de VSTS (probablemente https://social.msdn.microsoft.com/Forums/vstudio/en-US/ home?forum=TFService).

En este punto, la mayoría de las personas parecen haber sido desbloqueadas después de la corrección. Ha habido un informe de que no funciona por parte de @pksorensen , y estamos esperando una aplicación de reproducción para ver.

Todavía obtengo esto en TFS 2017 Update 1.

@jdshkolnik ¿Está seguro de que está configurado para crear el archivo appoffline.htm? Si no, está fuera del alcance de este problema. Realice la prueba manual appoffline.htm como se describe anteriormente.

@davidebbo Sí, lo es. Suele ocurrir que la implementación nocturna programada falla en su primer intento y requiere un intento de reimplementación manual que generalmente tiene éxito.

Para su información, mi empresa está federada con la suya, por lo que puedo mostrarle fácilmente a través del uso compartido de escritorio de Skype Empresarial.

@jdshkolnik , asegúrese de realizar la prueba manual mencionada anteriormente, ya que esto ayuda a eliminar todo lo demás de la ecuación.

Importante : este problema no se trata de investigar ningún problema con VSTS u otros flujos de trabajo de publicación. Se trata de una sola cosa: asegurarse de que appoffline.htm esté funcionando.

@davidebbo Se desconecta tan pronto como coloco manualmente app_offline.htm en la carpeta.

No sé cómo distinguir mejor si estoy perfectamente en el tema aquí. Todo lo que sé es que surgió de repente el año pasado para los sitios que funcionaban sin problemas y desde entonces ha aparecido regularmente.

##[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 Mi mejor suposición es que lo que sea que esté haciendo este script de implementación no es crear appoffline.htm antes de publicar los archivos. Podría ser un problema o error de configuración de VSTS. Pero desde el punto de vista de ANCM, la prueba que realizó muestra que las cosas funcionan como se esperaba cuando se crea la aplicación sin conexión.

@davidebbo No sé si lo que hice fue una prueba definitiva. Después de todo, el segundo intento manual después de recibir un error suele ser exitoso. El proceso de implementación que podría bloquear app_offline.htm no se estaba ejecutando.

Todavía me encuentro con este problema de mayúsculas y minúsculas en 7.1.1971.0. Cuando trato de implementar usando VS, aparece un error de archivo bloqueado, así que miré para ver si la aplicación aún se estaba ejecutando y, efectivamente, lo estaba. Abrí la línea de comandos de Kudu para ver qué archivos estaban en el directorio wwwroot y App_Offline.htm estaba en la carpeta, pero el proceso aún se estaba ejecutando. Luego escribí touch app_offline.htm y el proceso dejó de ejecutarse como se esperaba. Revisé dos veces los módulos y mi versión de aspnetcore.dll es 7.1.1971.0.

@alexgritton eso es extraño. Parecería implicar que ANCM inicialmente no detectó el archivo. ¿Eso sucede consistentemente o al azar?

Acabo de crear la aplicación hoy en Azure App Services y ha estado ocurriendo todo el día, por lo que diría que es constante. ¿Tiene alguna otra idea de lo que podría estar causando esto?

Realmente no. Dejaré que los expertos de ANCM comenten cómo monitorean los cambios de archivos y si pueden pensar en una razón por la cual no se detecta la creación inicial.

@davidebbo Tengo exactamente el mismo problema. Mi equipo tiene una compilación falsa que copia un archivo AppBuild.htm del servidor de compilación al sitio de destino como app_offline.htm. Luego intentamos usar msdeploy para sincronizar la carpeta y abrirla con otro error de proceso. Si toco el archivo, cambio el nombre del archivo de app_offline.htm a app_offline.htm.rename y viceversa, o sobrescribo app_offline.htm usando el Explorador de archivos, entonces el proceso se detiene correctamente. No tiene mucho sentido por qué no funciona a través de nuestro script, pero sí lo hace si lo hacemos manualmente.

Actualización: Descubrimos que actualizar el último tiempo de escritura parece desencadenar constantemente el apagado:

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

Definitivamente parece haber algo con el código que monitorea el archivo app_offline.htm.

@derekgreer Entonces, lo que está viendo es que cuando copia el archivo, ¿no se activa el apagado? No puedo reproducir esto desde la consola de Kudu. p.ej

• Ir a la Consola Kudu
• Ejecute touch app_offline.htm en D:\home\site para crear un archivo vacío en una carpeta diferente
• Ejecute copy app_offline.htm wwwroot . Tenga en cuenta que esto conserva la última hora de escritura y actualiza la hora de creación (comportamiento estándar de copia de archivos).

Resultado: el proceso dotnet.exe se cierra instantáneamente (puede verificar usando el explorador de procesos Kudu).

¿Te funcionan estos mismos pasos? Si es así, ¿qué podría ser diferente en su escenario de reproducción?

En realidad, también debería haber agregado que este problema ha sido intermitente y que estamos usando IIS 8 en Windows Server 2012.

Mi intención esta mañana era ver si podía reproducir el problema con un PowerShell o un script por lotes antes de configurar la consola Kudu, pero después de haber probado primero con el script de compilación falso de prueba que mi equipo estaba usando el viernes para crear el archivo app_offline.htm en varias formas (copiar archivo existente, crear archivo nuevo, etc.), actualmente está funcionando. Esto también refleja el patrón de nuestras fallas de compilación donde a veces se cerraba el proceso y otras veces no. Cuando comienza a fallar, parece hacerlo constantemente. Probamos durante horas el viernes y consistentemente no se detuvo con una compilación falsa simple que no hizo absolutamente nada excepto crear un nuevo archivo app_offline.htm. También debo agregar que periódicamente crearíamos el archivo manualmente y veríamos que el proceso se detiene, por lo que no parecería ser ningún tipo de situación en la que el proceso no se cerraría después de un período prolongado de uso.

Cuando pueda volver a reproducir el problema, veré si la creación del archivo con PowerShell y/o el archivo por lotes aún refleja el problema.

@davidebbo Bueno, mierda... Acabo de darme cuenta de que olvidé comentar una línea que estaba actualizando la hora de la última actualización, por lo que sigue mostrando el mismo comportamiento. Probaré con powershell y un archivo por lotes ahora y te actualizaré.

@davidebbo

Perdón por la confusion. Bien, esto es lo que he encontrado:

El uso de un archivo por lotes con los siguientes contenidos parece hacer que el proceso se cierre de manera confiable:

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

El uso de un script bash equivalente también hace que el proceso se cierre de manera confiable:

#!/bin/bash

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

El uso de un script de PowerShell con los siguientes contenidos parece que nunca hace que el proceso se cierre:

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

Dado que tanto Fake como Powershell se ejecutan bajo CLR mientras que el comando de copia de DOS, bash y Kudu Console no lo hacen, esto parece apuntar a algo relacionado con el archivo que se crea a través de CLR.

Lo extraño es que no veo diferencias en las marcas de tiempo de creación/actualización del archivo resultante entre las distintas versiones.

@derekgreer Oh, entonces no está ejecutando Azure App Service en absoluto. Ese es mi punto de vista en toda esta saga, así que dejaré que la gente de ASP.NET comente más sobre esto.

Aunque por lo que vale, no pude reproducir en App Service:

• Use la consola PowerShell de Kudu
• Ir a la carpeta site\wwwroot
• Ejecutar New-Item app_offline.htm -type file

@moozzyk , ¿puedes ayudar a investigar el servicio de aplicaciones externas de reproducción de @derekgreer ?

Informacion adicional:

Dado que la creación, copia, cambio de nombre, etc. a través del Explorador de archivos ha funcionado constantemente, decidí ver si una aplicación de explorador de archivos basada en .Net reflejaba los mismos resultados que estoy viendo con Fake y PowerShell. Hay un explorador de archivos basado en .Net llamado "Nomad" que terminé descargando y probando y los resultados fueron consistentes con Fake y PowerShell. Al crear un archivo app_offline.htm, el proceso no se detuvo. Luego cambié el nombre del archivo y lo cambié de nuevo a app_offline.htm nuevamente y el proceso Core luego se apagó.

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

Creo que este método querría incluir el indicador "FILE_NOTIFY_CHANGE_CREATION".

Me pregunto si la API de .Net común a Fake, PowerShell y Nomad no activa estos otros indicadores de la misma manera que la creación normal de archivos.

@shirhatti , ¿puede asegurarse de que alguien investigue este posible problema de ANCM?

@davidebbo Ack. lo estamos investigando

Estoy teniendo un problema muy similar. Si copio un archivo app_offline.htm en el Explorador de Windows, detiene correctamente el proceso, pero si lo creo usando COPY app_offline.htm \server\share\siteapp_offline.htm desde mi servidor de compilación, entonces no se detiene y los archivos permanecen bloqueados .

@gulbanana Tengo exactamente el mismo problema que tú. ¿Ya lo resolviste? @shirhatti ¿ Alguna actualización sobre su investigación? Esto vuelve loco al equipo porque la canalización de CI falla todo el tiempo debido a fallas en la copia de archivos que, a su vez, son causadas por dotnet.exe que app_offline.htm no cierra.

Resolví el problema usando algo similar a echo "<html>page content</html>" > \\server\share\app_offline.htm . Creo que @derekgreer tiene razón en que el error se trata de que ANCM observe solo algunos métodos de creación de archivos, y detecta este.

@derekgreer
Estoy investigando el problema ahora. Con uno de sus comandos de repro en mi máquina de prueba, pude reproducir este problema. Utilicé el siguiente comando. (NOTA: el siguiente comando creará un archivo vacío (tamaño de archivo cero).

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

Una cosa interesante es que si agrego algún contenido de archivo al crear el archivo app_offline.htm, no hay problema. Eso se puede hacer simplemente agregando el parámetro -value "test" de la siguiente manera:

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

¿Puede confirmar si ve el mismo síntoma en su entorno de reproducción?
Si es así, creo que este problema solo ocurre cuando se crea app_offline.htm vacío de alguna manera especial, como usar el comando powershell new-item.

@gulbanana
No puedo reproducir este problema con el comando Copiar. ¿Puedes explicar más detalladamente lo de tu reproducción? Sería genial si pudiera encontrar algunos pasos de reproducción con los que pueda reproducir el mismo problema en mi máquina de prueba.

Puedo confirmar que no está relacionado con si el archivo app_offline.htm está vacío sin ejecutar esos comandos, ya que nuestra experiencia ha sido copiar un archivo con el contenido deseado en la carpeta de implementación. Según mi experiencia, supongo que el segundo comando podría estar causando un evento de cambio de archivo si realmente funciona. Quizás crea el archivo y posteriormente lo actualiza con contenidos. Independientemente, todos los procesos relacionados con .net que he usado para crear el archivo con o sin contenido no logran activar el cierre del proceso.

@shirhatti ¿ Alguna actualización? ¿Pudiste confirmar que tu código debería usar el indicador "FILE_NOTIFY_CHANGE_CREATION"?

@derekgreer Estamos escuchando todas las banderas válidas, excepto cambiar el último acceso y cambiar los atributos.
FILE_NOTIFY_VALID_MASK & ~FILE_NOTIFY_CHANGE_LAST_ACCESS & ~FILE_NOTIFY_CHANGE_ATTRIBUTES

Así que sí, ya estamos escuchando FILE_NOTIFY_CHANGE_CREATION .

cc: @pan-wang

@shirhatti Ah, ahora entiendo. No sabía que la bandera cubría la creación de cambios. Tengo curiosidad, ¿has podido reproducir el problema?

Supuestamente se solucionó el no reaccionar a app_offline.htm vacío: https://github.com/aspnet/IISIntegration/issues/174

@moozzyk @derekgreer Gracias por la confirmación. Bien, también descubrí que el problema no está directamente relacionado con el contenido del archivo vacío. Lo actualizaré después de descubrir la causa raíz.

@jhkimnew ya no tengo la configuración rota exacta, pero puedo describir los detalles:

• IIS ejecutándose en Windows Server 2008 r2, hospedando una aplicación central de asp.net usando ANCM
• el servidor de compilación también es 2008r2, en el mismo dominio
• El servidor IIS tiene el directorio físico de su sitio web compartido mediante el uso compartido de Windows
• el usuario del dominio (la cuenta del servidor de compilación) ejecuta un script de PowerShell en el servidor de compilación
  si esta secuencia de comandos usa el comando de copia de Windows para copiar en una app_offline desde un archivo existente en otro directorio, entonces el proceso de hospedaje no se cierra. si el script usa "echo" (que puede ser el /bin/echo de una instalación de mingw, no estoy seguro), entonces el proceso de hospedaje se cierra.

sospecho que el problema tiene que ver precisamente con qué atributos de archivo se actualizan o no mediante ese tipo de copia remota

@gulbanana Para que quede claro, ¿probó con el comando de copia de dos y no con el comando power shell copy-item? No creo que haya probado la copia regular de dos, pero descubrí que cualquier aplicación basada en .net que usé no funcionó.

a menos que powershell tenga un alias para eso, fue copia dos

En mi caso, la copia de PowerShell no cerrará el proceso dotnet.exe, pero el eco, que es un alias de Out-Content, sí funciona. Siento que es poco probable que sea un problema de .NET, pero más sobre por qué una copia de red no funciona

Investigué si había algún problema en la notificación de cambio de aspnetcore.dll (ANCM), pero no pude reproducir el problema cuando traté de soltar app_offline.htm manualmente usando el cmdlet de powershell o el comando DOS. Y encontré un punto faltante que no se discutió aquí.
Eso es sobre el cierre elegante. A diferencia de HttpPlatformHandler, ANCM admite el apagado correcto, lo que significa que cuando app_offline.htm se coloca en el directorio raíz, ANCM envía una señal Crtrl-C/Break al proceso de back-end y espera hasta 10 segundos para permitir que ocurra el apagado correcto.
Los 10 segundos es el valor predeterminado y los usuarios pueden ajustar el valor con el límite de tiempo de apagado de los ajustes de configuración de ANCM. Si el proceso de back-end no se cierra en el shutdownTimeLimit configurado, se supone que ANCM debe eliminar el proceso de back-end.

Mientras comprobaba cómo se relaciona la publicación de MSDeploy con el apagado correcto de ANCM, finalmente encontré un paso de reproducción consistente, que consiste en aumentar el tiempo de apagado (5 segundos) y noté que MSDeploy vuelve a intentarlo solo 2 veces de forma predeterminada y espera solo 2 segundos y finalmente no puede publicar porque no espera el tiempo de apagado elegante.

@vijayrkn
Después de poner 5 segundos de retraso en el lugar de inicio y finalización de la aplicación web aspnetcore, pude reproducir el mismo error, que se informó en este problema, en la segunda prueba de publicación de la aplicación web aspnetcore en el servidor IIS local. Adjunté el perfil de publicación que usé a continuación también.
¿Podría explicar por qué sucede esto y dar una guía correcta sobre cómo solucionar este problema de publicación? Y haga un nuevo problema sobre esto por separado para que su equipo realice un seguimiento de este problema para mejorar la experiencia del usuario.

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

MSDeploy intenta implementarse justo después de que se elimine app_offline. Si hay un retraso en la detención del proceso, la implementación podría fallar.

El recuento de reintentos para la implementación se puede establecer mediante esta propiedad de msbuild (https://github.com/aspnet/websdk/blob/dev/src/Publish/Microsoft.NET.Sdk.Publish.Targets/netstandard1.0/PublishTargets/Microsoft .NET.Sdk.Publish.MSDeploy.objetivos#L67)

por ejemplo, establecer esta propiedad en 10 garantizará que msdeploy vuelva a intentarlo 10 veces con un retraso de un segundo en el medio.
<RetryAttemptsForDeployment>10</RetryAttemptsForDeployment>

@vijayrkn

Gracias por la información. Después de agregar las dos líneas a continuación, no veo ningún problema con el mismo entorno de reproducción.
<EnableMSDeployAppOffline>True</EnableMSDeployAppOffline> <RetryAttemptsForDeployment>10</RetryAttemptsForDeployment>

Por lo tanto, cualquier persona que se encuentre con un problema similar deberá aumentar el recuento de RetryAttemptsForDeployment con el valor apropiado e intentar nuevamente si eso puede resolver el problema.

NOTA: La razón por la que agregué EnableMSDeployAppOffline es porque está deshabilitado de forma predeterminada cuando se usa el servidor IIS local como destino de la publicación de una aplicación web aspnetcore. Por lo tanto, si no está seguro de si eso está habilitado o no en su entorno, también deberá agregar la línea y es por eso que la agregué aquí para su información.

Solo para garantizar que el problema original no se pierda debido a las discusiones más recientes, el problema que experimentó mi equipo definitivamente no es un problema de tiempo. Hemos probado la creación manual del archivo app_offline.htm a través de Powershell, Fake y un explorador de archivos basado en .Net llamado "Nomad" y el proceso no se cierra sin importar cuánto tiempo espere. La creación del archivo a través del Explorador de archivos, un archivo por lotes de DOS o un script bash (es decir, procesos no basados ​​en bibliotecas .Net) hace que el proceso se cierre en 1 o 2 segundos.

Esto parecería indicar:

1. El problema no está relacionado con la red (todas las pruebas se realizaron en un recurso compartido de archivos remoto)
2. No es un problema de tiempo/apagado elegante

El hecho de que 3 métodos que no sean .Net para crear el archivo app_offline.htm cierren el proceso de manera confiable y rápida y que 3 métodos basados ​​en la biblioteca .Net para crear el archivo nunca den como resultado que el proceso se cierre en nuestras pruebas parece ser realmente , realmente un gran indicador para mí.

@derekgreer
No puedo reproducir el problema incluso con "Nomad".
Esto es lo que hice en mi máquina con Windows 10 (amd64).

1. Instalar IIS
2. Instalar Visual Studio 2017
3. Cree una aplicación web AspnetCore e impleméntela en el servidor IIS local con MSDeploy
4. Instale Nomad v3.2.0.2890 (http://www.nomad-net.info/downloads)
5. Enviar una solicitud a la aplicación web
6. Abra el Administrador de tareas y confirme que el proceso dotnet.exe se está ejecutando
7. Abra Nomad y cree un nuevo archivo llamado app_offline.htm en el directorio raíz de la aplicación web
8. Consulte el Administrador de tareas y verifique que el proceso dotnet.exe haya desaparecido cuando se cree el archivo app_offline.htm

¿Me daría los pasos de reproducción exactos para que pueda seguir para reproducir el problema?

Aparte del hecho de que nuestra aplicación .Net Core es en realidad una aplicación de consola .Net 4.5.2 estándar creada en VS 2015 que hace referencia a los ensamblajes ASP.Net Core, no veo ninguna diferencia. El proyecto tiene aproximadamente un año y se configuró de esa manera en ese momento debido a las limitaciones con los tipos de proyecto de plantilla central de referencia de los tipos de proyecto de plantilla de marco .Net y varios tipos de soporte de biblioteca de prueba para .Net core.

Identificamos un par de problemas: 1) soltar el archivo app_offline.htm (usando alguna herramienta) a veces solo activaba una notificación de cambio de propiedad del archivo que ANCM filtraba. 2) ANCM podría fallar al leer app_offline.htm ya que este último estaba en manos de la herramienta de copia de archivos. 3) el apagado correcto provocó un retraso en la finalización del proceso de back-end.
Abordaremos los dos primeros problemas en la próxima versión. Para el caso de apagado correcto, el usuario debe volver a intentarlo.

suena bien. mi caso definitivamente no se trataba de un tiempo de espera de apagado elegante: cuando se detiene, se detiene de inmediato.

¿Alguna actualización sobre este tema?
Obtener al intentar implementar una aplicación ASP.NET Core 1.1 en una ranura de aplicación web de Azure mediante VSTS

• Tengo el MSDEPLOY_RENAME_LOCKED_FILES=1 establecido en la configuración de la aplicación
• La tarea Manage App Service está configurada para desconectar la aplicación
• La tarea Implementar App Service _estaba_ configurada para desconectar la aplicación, pero tampoco funcionó

El problema central es que la DLL está en uso:

@ChuckkNorris , consulte https://github.com/Microsoft/vsts-tasks/issues/1607 para conocer las últimas novedades.

@davidebbo Gracias por tu respuesta, David. Vi ese hilo y ahí es donde descubrí muchas de las soluciones que probé.

Como este problema aún está abierto y el error aún prevalece, esperaba que pudiera haber una solución pronto, no otra solución. Después de todo, este problema ha estado abierto durante más de dos años.

@ChuckkNorris aunque el síntoma es el mismo, este no es el mismo problema:

• Problema original relacionado con la carcasa de app_offline.htm , lo que provocó que se ignorara por completo. Eso ha sido arreglado por un tiempo.
• Este nuevo problema comenzó hace aproximadamente una semana y ocurre porque ahora Core tarda más en apagarse cuando se crea app_offline.htm y msdeploy de forma predeterminada no espera lo suficiente. La solución consiste en aumentar el recuento de reintentos.

Acabo de actualizar VS 2017 a 15.3 e instalé .NET core 2.0 SDK. Creó una aplicación MVC simple en VS: estaba dirigida a netcoreapp1.1. Publiqué en Azure y todo estuvo bien. Actualicé a newcoreapp2.0 y luego actualicé todos los paquetes nuget a 2.0 (Microsoft.AspNetCore, Microsoft.AspNetCore.Mvc, etc.)

Cuando intento publicar en Azure (es decir, sobrescribir el 1.1), obtengo esto

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

Tuve que deshabilitar MvcViewComplication para que mis aplicaciones 2.0 se implementen a través de git y evitar problemas de archivos en uso.

https://github.com/Microsoft/vsts-tasks/issues/5259
https://github.com/Microsoft/vsts-tasks/issues/1607#issuecomment-349115532
@davidebbo , ¿Podemos cerrar este problema?
A pesar de agregar un asistente de reintento para la implementación web, este problema persiste.

Solo quería señalar lo obvio, que esto también afecta la publicación FTP.

@jeremycook FTP es un poco diferente, ya que no tiene automatización para usar App_Offline. Debería crear manualmente ese archivo para que el proceso se cierre, después de lo cual podría copiar archivos.

@davidebbo es bastante justo, pero parece que si publico a través de FTP usando la función de publicación de Visual Studio, debería funcionar. ¿Quizás estoy publicando en el lugar equivocado?

@jeremycook , francamente, no estoy seguro de qué hace VS cuando realiza la implementación de FTP. Tal vez otros puedan brillar, pero parece más una pregunta de VS que de ASP.NET.

Aunque para aislar, sería interesante probar si la implementación es exitosa si crea manualmente App_Offline.html y luego publica FTP desde VS.

@vijayrkn ¿Puede comentar sobre el comportamiento de VS durante la implementación de FTP?

La publicación FTP desde VS al servicio de aplicaciones no es compatible con App_Offline.

@vijayrkn ok, para fines prácticos, podemos decir que la implementación de .NET Core a través de FTP no es compatible, a menos que el usuario detenga explícitamente el sitio antes de la implementación. ¿Derecha?

@davidebbo - Sí, eso es correcto.

Solucionar este problema al implementar la aplicación web asp.net core 2.0 en IIS desde la versión VSTS utilizando la plantilla de implementación web de IIS. La eliminación falla debido a que el archivo está en uso. La opción de aplicación fuera de línea está habilitada.

@davidebbo @vijayrkn @shirhatti todo esto es un poco deprimente. ¿Hay planes para que FTP/XCOPY funcione? ¿Debería abrirse un nuevo problema que se centre en implementar las formas antiguas a través de FTP/XCOPY/ROBOCOPY/etc.?

Llegué tarde a esta fiesta, pero aquí hay algunas cosas que quiero informar:
VS 2017 Empresa
asp.net 4.6.xx
el servidor es IIS 8.5 en el servidor 2012 R2
Los dlls de tipo de servidor SQL están bloqueados y el bloqueo es tal que cuando un desarrollador diferente realiza una publicación con msdeploy, reciben un error y el sitio web ahora está dañado ya que solo se ejecutó una parte de la implementación.

los tipos de sql dlls están bloqueados en la carpeta bin de la aplicación y solo ellos.
cambie el nombre de los archivos dll y luego puedo publicar.
el paquete de tipos sql tiene un código caned para cargar los dll no administrados.
parece que eso debería cambiarse para no bloquearlos. si eso se puede hacer.

He visto gente hablando sobre formas de reiniciar el sitio o desconectarlo, pero no he encontrado una configuración en msdeploy para ello. el xml que he visto no está en mis archivos.

se debe agregar una mejor orientación al paquete de tipos sql que publica microsoft.

Publicando sobre este tema, ya que parece más directamente relacionado con el mío. También seguí el siguiente problema sobre el mismo tema, aunque es para VSTS. Estoy publicando directamente desde Visual Studio.

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

Este ha sido un problema intermitente para mí, pero recientemente volvió en vigor y en uno de mis sitios de servicio de aplicaciones recibo este error en casi todos los intentos de publicación. Este sitio está alojado en un servicio de nivel "básico", por lo que no tengo ranuras que uso en otras aplicaciones para solucionar este problema.

Esto es para una aplicación .net core 2 mvc.

Una idea: algunos archivos que forman parte de una aplicación web no cambian en cada publicación (como los tipos sql)
pero ms deployment intenta reemplazarlos en cada implementación.
parece que debería realizarse algún tipo de verificación para no volver a copiar un archivo que no ha cambiado y eso haría que la actualización fuera más pequeña y más rápida y menos necesaria para meterse con el bloqueo del archivo.
Múltiples beneficios si eso se puede hacer.

la otra cosa es identificar mejor qué está bloqueando el archivo y por qué y cómo deshacer eso.
y obtenga eso como parte de la canalización de implementación estándar.

@figuerres Llevo un par de meses queriendo tratar ese tema. Los problemas de bloqueo normalmente se evitan debido a Shadow Copying, pero al cargar esas DLL nativas desde ~/bin , se crea un problema de bloqueo. Tengo una solución potencial, pero no estoy seguro de si es una solución completamente segura: https://stackoverflow.com/questions/47796553/is-it-safe-to-manually-copy-native-dlls-to- un directorio de copia oculta

Acepto que la documentación del paquete NuGet debería proporcionar un mejor método, uno que no cause problemas de bloqueo.

@figuerres FYI, implementé lo anterior, vea la pregunta de desbordamiento de pila para el código.

Matar dotnet.exe en el Administrador de tareas

¿Cuál es el estado aquí? 3 años después, todavía no está arreglado. Tengo que ir manualmente al servidor y detener el sitio web.

¿3 años? El problema se informó en agosto de 2017. Desactivado por 1 como whoa.
El lunes 23 de abril de 2018 a las 20:56 Oliver Janik [email protected]
escribió:

¿Cuál es el estado aquí? 3 años después, todavía no está arreglado. tengo que ir manualmente
al servidor y detener el sitio web.

—
Estás recibiendo esto porque estás suscrito a este hilo.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/aspnet/Home/issues/694#issuecomment-383768450 , o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/AAXhfrhOTvZn2qb4kU-Y1Kg9I-IQKD9yks5trnhXgaJpZM4FJp_R
.

La primera publicación dice "pekkah abrió este número el 23 de junio de 2015"

Estás bien. Mi culpa. Solo vi la última marca de tiempo en la cadena de correo electrónico.
El lunes 23 de abril de 2018 a las 21:06 Oliver Janik [email protected]
escribió:

La primera publicación dice "pekkah comentó el 23 de junio de 2015"

—
Estás recibiendo esto porque comentaste.

Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/aspnet/Home/issues/694#issuecomment-383769982 , o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/AAXhfgwYG-jLjnoJF7MCMtzbbfxSZkt2ks5trnqXgaJpZM4FJp_R
.

Cerrando porque esto es tan viejo como la suciedad 😄

@Eilon Lo siento, pero ¿por qué se cerró esto? ¿Sigue sin resolverse?

Cerrando porque esto es tan viejo como la suciedad 😄

Pero sigue siendo un problema .. ? (incluso en implementaciones que no sean de Azure)

Creó un nuevo problema (#3719) para aumentar la visibilidad.