Aspnetcore: A implantação falha devido ao arquivo em uso

Percebi um problema semelhante com o bloqueio de arquivo do IIS nas VMs do Azure que impediu a implantação do WebDeploy. Minha solução é emitir três comandos WebDeploy: pare o AppPool, implante, reinicie o AppPool. Veja meu roteiro ; e se você tiver a capacidade de executar três comandos WebDeploy, poderá fazer algo semelhante com os Aplicativos do Azure.

Obtendo este problema em beta6.

Mesmo aqui! Na verdade, isso faz com que meu Visual Studio 2015 congele - ao publicar meu aplicativo vNext (beta6 e beta7, acho).

Você está usando os scripts fornecidos pela Microsoft para fazer a implantação? Nesse caso, você pode simplesmente adicionar uma linha no PublishAspNet5Website.ps1 para reiniciar o aplicativo da web:

Restart-AzureWebsite -Name $websiteName

Eu tenho minhas modificações de script de compilação descritas nesta postagem: Resolver um problema de implantação do ASP.NET 5 no slot do aplicativo Web do Azure

@brandonmartinez , Reiniciar um site não ajudará, pois um site de produção continuará recebendo solicitações, o que, portanto, bloqueará os arquivos. Atualmente, a única maneira confiável de atualizar sites do IIS e do Azure é desligar o pool de aplicativos do site, atualizar os arquivos e reiniciar o site. Basta seguir o link do @GuardRex para mais detalhes.

No entanto, não devemos nos preocupar com scripts de implantação personalizados ao trabalhar em condições padrão com o VS2015.

Espero que a nova infraestrutura HttpPlatformHandler (que não precisa mais de um AspNet.Loader.dll) seja um pouco mais tolerante, mas não estou prendendo a respiração aqui. Provavelmente teremos outro .dll bloqueado.

@rubenprins Essa é a solução alternativa que uso também, por meio das ferramentas do SDK do Azure no VS.

Existem comandos PS para fazer isso se você puder obter acesso PS à VM. https://github.com/GuardRex/net5-iis-ps-publish/blob/7623122dbfdc55a7c53c8edd2e97443e0eea22c9/net5-iis-ps-publish.ps1#L389 -L396

aspnet/vsweb-publish também é muito interessante; no entanto, parece que ele usa offline-template.html , e eu pensei que foi descoberto que esse método não impediria o problema de bloqueio de dll ... apenas parando o AppPool, implantando e reiniciando o AppPool foi estável, abordagem de trabalho.

não precisamos mexer com scripts de implantação personalizados ao trabalhar em condições padrão com o VS2015

Porém, uma coisa me ocorreu: ser capaz de usar 'Publicar no sistema de arquivos' e conectar um script logo após a publicação que contém bits do MSDeploy permitiu uma história de implantação muito simples e útil para várias VMs. Como o script é executado sequencialmente, ele vai de VM para VM logo abaixo. Faz uma boa pausa para o café. :sorrir:

Tenho uma pergunta em Introdução à configuração de um balanceador de carga voltado para a Internet usando o Azure Resource Manager com a equipe do Azure Resource Manager perguntando sobre como dizer ao balanceador de carga para parar temporariamente de enviar tráfego para a VM enquanto você está implantando.

Enfim... voltando ao assunto que @pekkah levantou. Como sabemos que os comandos PS funcionam, verifique as opções para executá-los em uma compilação do VSO:

Microsoft/vso-agent-tasks
Execute um script em seu processo de compilação
Executando scripts de pré-compilação no Team Foundation Service (Visual Studio Online) para o processo de compilação de implantação contínua do Azure
Novos recursos de automação de compilação no Visual Studio Online

... sim ... algo assim deve funcionar para você.

Mesmo problema aqui...

Ainda aguardando uma solução oficial

Bruno

Isso será resolvido por https://github.com/aspnet/IISIntegration/issues/81.

@moozzyk , Esse problema só corrigirá a implantação por meio de ferramentas dedicadas, como msdeploy. A implantação de sincronização de Xcopy/File ainda não seria possível, o que também bloqueará/impedirá muitos cenários de CI que funcionam apenas com ASP.NET v1-4.

O problema ainda existe no ASP.NET Core 1.0 RC2 com Visual Studio 2015.2 MSDeploy para IIS 8 no Windows 2012 R2 com as ferramentas mais recentes para servidor. Matar o processo dotnet.exe ou reciclar o pool de aplicativos resolve o problema. Mas isso precisa de acesso remoto da área de trabalho ao servidor e não é exatamente um processo tranquilo.

@dg9ngf - este é um bug no web.deploy agora. Eles adicionaram a funcionalidade app_offline.htm para o Azure, mas está desabilitada por padrão quando você implanta localmente. Tente abrir seu perfil de publicação (PublishProfiles->*.pubxml) e altere:

<EnableMSDeployAppOffline>False</EnableMSDeployAppOffline>

para

<EnableMSDeployAppOffline>True</EnableMSDeployAppOffline>

Se isso não funcionar, pergunte a @vijayrkn

Se você estiver usando as ferramentas do VS para publicar usando um perfil msdeploy, essa propriedade será adicionada automaticamente ao seu pubxml.

<EnableMSDeployAppOffline>True</EnableMSDeployAppOffline>

Na sua janela de saída, você deve ver um comando msdeploy semelhante 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 no comando deve cuidar de adicionar o appOffline durante a implantação.

Se o conteúdo appOffline personalizado for necessário, você poderá definir essa propriedade em pubxml.

<AppOfflineTemplate>Path to app offline</AppOfflineTemplate>

Essa propriedade _não_ estava presente no arquivo .pubxml que o Visual Studio criou. Então eu adicionei, mas não mudou nada. O argumento -e nablerule:AppOffline _não_ aparece na janela de saída.

Você pode compartilhar a linha de comando msdeploy exibida na janela de saída?

Além disso, você pode confirmar se o pubxml tem WebPublishMethod como 'MSDeploy'.
<WebPublishMethod>MSDeploy</WebPublishMethod>

Não, o arquivo tem isso: <WebPublishMethod>FileSystem</WebPublishMethod>

Aqui está a linha de comando da janela de saída: 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]

Estou implantando usando a tarefa "Azure Web App Deployment" no VSTS, conforme descrito nesta postagem do blog: http://donovanbrown.com/post/2016/05/30/DevOps-for-ASPNET-Core-RC2

Existe uma maneira de especificar o <EnableMSDeployAppOffline>True</EnableMSDeployAppOffline> usando esse método?

Oi, eu tive o mesmo problema no Azure, resolvi desta forma https://github.com/davidebbo/WAWSDeploy/issues/14

@dg9ngf Na versão atual do script powershell, oferecemos suporte a appOffline apenas para WebPublishMethod - 'MSDeploy'.

O suporte AppOffline para publicação do sistema de arquivos estará disponível na próxima versão.

@bojingo estou na mesma situação. Você descobriu isso?

@davenewza : Se você visitar aquela postagem no blog novamente, a solução está nos comentários.
http://donovanbrown.com/post/2016/05/30/DevOps-for-ASPNET-Core-RC2

Basicamente, você precisa adicionar etapas VSTS para parar/iniciar o site. Muito longe de ser uma solução ideal (na verdade, muito ruim), especialmente porque não estou usando slots de implantação, mas funciona bem para nosso ambiente de desenvolvimento/teste.

Há uma nova versão ARM de visualização da tarefa VSTS de implantação de aplicativo da Web que é baseada em msdeploy e promete corrigi-la, mas não tive sorte com isso porque precisava que o cliente criasse uma entidade de serviço para a assinatura e isso foi um aborrecimento. Talvez você consiga fazer isso funcionar:
https://github.com/Microsoft/vsts-tasks/tree/master/Tasks/AzureRmWebAppDeployment

@vijayrkn A caixa de diálogo Publicar Web no VS2015 não contém nenhuma opção para definir msdeploy - apenas fornece as opções para WebPublishMethod=FileSystem.

Você pode fornecer um exemplo de .pubxml para WebPublishMethod=msdeploy, por favor?

@tomfanning Para um aplicativo de console ASP.NET core, a única opção de publicação disponível atualmente é o sistema de arquivos. Você está tentando publicar um aplicativo de console? Para um aplicativo da web, todas essas 4 opções devem estar disponíveis (webdeploy, pacote de implantação da web, sistema de arquivos e ftp).
Exemplo de webdeploy pubxml - https://github.com/dotnetpublish/AspNetCoreBlogList/tree/master/src/AspNetCoreBlogList/Properties/PublishProfiles

Se for um aplicativo da web e você estiver vendo apenas a opção de publicação do sistema de arquivos, você pode verificar o xproj para ver se ele importa isso?
<Import Project="$(VSToolsPath)\DotNet.Web\Microsoft.DotNet.Web.targets" Condition="'$(VSToolsPath)' != ''" />

@bojingo Consegui configurar o principal de serviço, existem vários tutoriais na rede. Não tenho os links aqui, mas posso procurar se precisar. Agora meu problema é que a tarefa requer um arquivo parameters.xml que não é gerado na publicação ASP Net Core... :(

Eu tenho o TFS 2015 no local e isso continua sendo um problema incrivelmente irritante.

Também estou passando por esse problema...

Minha solução foi manter meu slot de preparação parado parado e, em seguida, publicar nele (funciona a troca automática). Reiniciar e implantar não funcionou (implantar com VSTS)

Estou usando o polvo com aplicativos Web do Azure, que não apresenta uma opção para slots de preparo. No entanto, verificar as seguintes opções parece ter funcionado:

• Desative o domínio do aplicativo com segurança com app_offline.html em branco na raiz.
• Remova os arquivos no destino que não fazem parte da implantação

Estou usando o Visual Studio 2015 Update 3 para publicar um site asp.net core 1.1/.net framework 4.5.2 no IIS. Ele desce App_Offline.htm que não derruba o site. Se eu renomeá-lo no servidor para app_offline.htm o site cai.

Por este app_offline.htm não deve diferenciar maiúsculas de minúsculas.

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

O implantador carrega app_offline.htm (não diferencia maiúsculas de minúsculas)

Acabei de publicar novamente e vejo App_Offline.htm cair e meu site não caiu e recebo o arquivo em erro de uso. Quando mudo para app_offline.htm meu site cai e posso publicar sem erros.

Estou hospedando em um caminho UNC compartilhado - não sei se isso faz diferença.

@Tratcher - você sabe por que o uso de App_Offline.htm faria diferença aqui?

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

Consegui resolver esse problema adicionando um appsetting do Azure de

MSDEPLOY_RENAME_LOCKED_FILES = 1

... como descrito aqui:
https://github.com/Microsoft/vsts-tasks/issues/1607#issuecomment -260946957

YMMV

@BenBarreth Existe algo semelhante aplicável a não-Azure?

não que eu saiba desculpe @jdshkolnik

Parece que pode haver problemas com MSDEPLOY_RENAME_LOCKED_FILES = 1. Isso ajuda a implantação bem-sucedida, mas pode significar que as novas DLLs não são selecionadas em tempo de execução:
https://github.com/Azure/azure-webjobs-sdk-script/issues/569#issuecomment -264490818

Isso não me parece uma "correção" apropriada. Ele apenas oculta a falha de implantação.

A correção verdadeira pode ser descrita neste problema:
https://github.com/Azure/azure-webjobs-sdk-script/issues/1023

Realmente procurando resolução para isso. Parecia que a tarefa VSTS de implantação da Web do RM cuidou disso com a opção "Take App Offline" selecionada, mas neste fim de semana estamos constantemente recebendo os erros. Voltamos a interromper o slot de implantação, implantar e iniciar novamente.

Da mesma forma conosco, esse problema surgiu na sexta-feira da semana passada e nos impediu de implantar desde então ...

Mesmo aqui. Parece que isso afeta apenas sites com Always On = true, mas isso não é certo.

Ainda tenho esse problema mesmo ao definir o MSDEPLOY_RENAME_LOCKED_FILES = 1 na minha configuração. É quase impossível atualizar a compilação no meu servidor agora. Isso começou a acontecer há poucos dias.

O mesmo problema começou a ocorrer para mim esta semana. Até esta semana, a implantação de um serviço de aplicativo AzureRM no VSTS com a configuração Colocar o aplicativo offline = true funcionou de forma consistente. Agora, essa configuração parece ser ignorada ou o serviço não é retirado da linha a tempo. Eu tenho que reiniciar manualmente ou parar/iniciar o serviço de aplicativo enquanto executo o lançamento para que ele também exceda.

Mesma questão aqui. AzureRm estava funcionando há meses e parou de repente. Minha última implantação foi há duas semanas em 5/12 e agora em 20/12 está gerando o Error_File_In_Use. Muito chateado por ter que voltar ao start/stop manual.

Aqui está nossa solução alternativa no Powershell que estamos usando por enquanto como parte de nosso processo de CI/compilação. Agradecimentos especiais aos caras do @appveyor pela ajuda com isso:

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

Isso faz uso da API REST Kudu para HTTP PUT o arquivo app_offline.htm corretamente colocado. Temos o WebDeploy configurado para remover quaisquer arquivos que não estejam na implantação, portanto, ele remove automaticamente o arquivo como parte da implantação. Talvez seja necessário repetir a etapa usando um HTTP DELETE para remover o arquivo após a conclusão da implantação, se você não estiver usando esse modo.

Adicionar um Trackyon Stop antes da tarefa do AzureRM e uma tarefa Trackyon Start depois está funcionando bem para mim. Isso não deve ser necessário com o TakeAppOffline = true, mas está funcionando e evita manual ou script. Basta adicionar a tarefa à definição de versão. As etapas do Trackyon são fáceis de configurar

Em 21 de dezembro de 2016, às 12h10, Chad T < [email protected] [email protected] > escreveu:

Aqui está nossa solução alternativa no Powershell que estamos usando por enquanto como parte de nosso processo de CI/compilação. Agradecimentos especiais a @appveyor https://github.com/appveyor pessoal pela ajuda com isso:

$username = $ env:deployusername
$senha = $ env:deploypassword
$base64AuthInfo = [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes(("{0}:{1}" -f $username,$password))))
$Cabeçalhos = @{
'Autorização' = ('Basic {0}' -f $base64AuthInfo)
'Se-Correspondência' = '*'
}
$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"

Isso faz uso da API REST do Kudu https://github.com/projectkudu/kudu/wiki/REST-API para HTTP COLOCAR o arquivo app_offline.htm com maiúsculas e minúsculas corretamente no lugar. Temos o WebDeploy configurado para remover quaisquer arquivos que não estejam na implantação, portanto, ele remove automaticamente o arquivo como parte da implantação. Talvez seja necessário repetir a etapa usando um HTTP DELETE para remover o arquivo após a conclusão da implantação, caso não esteja usando esse modo.

-
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub https://github.com/aspnet/Home/issues/694#issuecomment-268436959 ou silencie o tópico https://github.com/notifications/unsubscribe-auth/AID9WoUdbuBnFoXR2K5o8AiUtv8nE9dRks5rKLTcgaJpZM4FJp_R .

Esta mensagem não é pública e pode conter informações privilegiadas, proprietárias ou confidenciais. Se você o recebeu por engano, notifique imediatamente o remetente e exclua todas as cópias do original. Qualquer outro uso do e-mail por você é proibido. Qualquer cópia, armazenamento, uso ou divulgação não autorizados do conteúdo desta mensagem não é permitido e pode ser ilegal. Quando permitido pela lei local, as comunicações eletrônicas com a Lithero podem ser monitoradas e escaneadas por nossos sistemas para fins de segurança da informação e avaliação da conformidade interna com as políticas da Lithero e leis aplicáveis.

/cc @davidebbo

Tente definir MSDEPLOY_RENAME_LOCKED_FILES=1 nas configurações de aplicativo do Azure para seu aplicativo.

@davidebbo isso não parece resolver as coisas.

Presumo que isso esteja relacionado a uma alteração no lado do Azure da cerca? Muitas pessoas (especialmente no canal aspnet slack) tiveram esse problema ao mesmo tempo.

Uma alteração no Azure não explicaria por que estamos vendo isso no local com o TFS. Seria o agente?

Estamos vendo o mesmo problema. App_Offline.htm não é selecionado. Estranhamente, se implantarmos a partir do VS, funcionará bem.

Curiosamente, para mim não funciona no VS, conforme descrito aqui: #1883

Minha equipe também encontra esse problema, quase sempre que a implantação falha devido a um arquivo bloqueado. Precisa reiniciar todos os aplicativos no Azure e executar novamente a implantação. Estamos usando o Octopus Deploy.

Minha equipe encontrou esse problema esta manhã. Algum comentário da equipe da Microsoft? O pipeline de liberação é fundamental para nossa produtividade, pois está impedindo liberações para locais de produção. Obrigado!

@bmoscao - app_offline.html diferencia maiúsculas de minúsculas.

Esse problema também apareceu para mim no Azure. Nada que eu fiz no meu fim para causá-lo.

Estou com esse problema também. O problema é que EnableMSDeployAppOffline está definido como true - e a saída do projeto mostra -enablerule:AppOffline como parte do comando sendo executado pelo visual studio. Eu não sei o que fazer... Eu só comecei a ter esse problema recentemente..

Nossa solução para isso foi parar o pool de aplicativos, implantar e reiniciar o pool de aplicativos. Estamos usando o Release Manager e o plug- in powershell embutido para fazer isso.

Pare:

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

Começar:

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

Definitivamente, gostaria de receber algumas informações da Microsoft, isso costumava funcionar muito bem apenas habilitando a regra appOffline na etapa de implantação do RM Azure.

@davidebbo Estamos usando ASP.NET Core, VSTS Release Manager e AzureRmWebApp com slots.

@davidebbo obrigado! Funciona para mim ;)

Acontecendo conosco também - msdeploy to Azure. Fico feliz em ver que começou misteriosamente para várias pessoas ao mesmo tempo - e não somos apenas nós - mas não é super reconfortante em geral!

Eu não acho que as pessoas da MS precisam de confirmação para isso, provavelmente eles sabem bem qual é o problema. De qualquer forma, o mesmo aqui. Implantando do VSTS, parou de funcionar no início de dezembro. No momento estou usando a tarefa trackyon para parar/iniciar.

Passando por este tópico, para cada entrada, nem sempre fica claro:

1. se o problema se refere ao Serviço de Aplicativo do Azure ou a alguma outra hospedagem
2. se as pessoas tentaram alterar a caixa app_offline conforme discutido acima. Parece que várias pessoas relataram sucesso lá.
3. se MSDEPLOY_RENAME_LOCKED_FILES foi tentado. Novamente, várias pessoas parecem ter sido bem sucedidas com isso.

Se você estiver enfrentando esse problema, deixe bem explícito qual é o seu cenário e o que você tentou, para que possamos entender isso. Obrigado!

@davidebbo

Estou recebendo a mensagem ERROR_FILE_IN_USE quando tento implantar usando o Visual Studio/MSBuild. A tarefa está criando um arquivo App_Offline.htm no servidor, mas não está desativando o aplicativo.

A criação de um arquivo app_offline.htm usando o Web Deploy desativa o aplicativo.

Esta é a minha configuração:

• Servidor: IIS 8, .NET Core Windows Server Hosting 1.1.0 e Web Deploy 3.6
• Minha máquina: Visual Studio 2015 Update 3 e .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

Eu comentei sobre esse erro em um thread semelhante e tive que parar e reiniciar meu aplicativo Web do Azure toda vez que quero reimplantar (apenas no ambiente de desenvolvimento). Nunca tive que fazer isso antes desta semana. Eu decidi basicamente criar um aplicativo da Web .net core do Visual Studio 2015 a partir do modelo sem nenhuma modificação.

Eu executei o aplicativo da web no host local sem nenhum problema.
Eu publico o novo aplicativo no meu Plano de Serviço de Aplicativo Web do Azure sem problemas e o navegador imediatamente abriu o site sem problemas.
Verifiquei o Azure Dashboard e não tive nenhum problema.

Em seguida, republicei o aplicativo da web sem modificar nada - código ou configurações e o seguinte erro se apresenta.

A partir de então, tenho que parar o aplicativo Web, publicar no Azure e iniciar o aplicativo Web. Isso nunca aconteceu comigo antes. Esta é uma implantação muito simples do modelo da Microsoft.

Gravei todo esse processo e enviei esse feedback no sistema de feedback do Microsoft 2015 VS. Espero que você possa encontrar essa gravação. Ou eu provavelmente poderia fazer isso de novo.

Atenciosamente Pedro

@davidebbo

se o problema se refere ao Serviço de Aplicativo do Azure ou a alguma outra hospedagem

Serviço de Aplicativo do Azure.

se as pessoas tentaram alterar a caixa app_offline conforme discutido acima. Parece que várias pessoas relataram sucesso lá.

Alterar App_Offline para app_offline corrige o problema - este arquivo é criado via webdeploy automaticamente com a caixa 'App_Offline' como parte da implantação, que é o cerne do problema.

@davidebbo
Exatamente o mesmo que @ctolkien.

@davidebbo

se o problema se refere ao Serviço de Aplicativo do Azure ou a alguma outra hospedagem

No meu caso, estou implantando no Serviço de Aplicativo do Azure. Não sei sobre outras hospedagens.

se as pessoas tentaram alterar a caixa app_offline conforme discutido acima. Parece que várias pessoas relataram sucesso lá.

Estou usando a tarefa "Implantar AzureRM Web App" do VSTS (https://aka.ms/azurermwebdeployreadme). Existe uma opção "Publish using Web Deploy" <- marcada e "Take App Offline" <- marcada que costumava funcionar, até que algo mudou em algum lugar e parou de funcionar.
A dica de ferramenta "info" fala explicitamente sobre como colocar "app_offline.htm" com "a" minúsculo.
Não tenho certeza de como alterá-lo usando este script, já deve ser minúsculo.

se MSDEPLOY_RENAME_LOCKED_FILES foi tentado. Novamente, várias pessoas parecem ter sido bem sucedidas com isso.

Não tentei. Não sei como fazer isso. Mas, de qualquer forma, prefiro deixar o aplicativo offline em vez de alterar o conteúdo dos arquivos bloqueados.

Obrigado a todos. Portanto, parece claro que o principal problema é com a caixa de app_offline.htm , e não com nada relacionado ao Serviço de Aplicativo do Azure (que é o lado de onde venho). E isso é rastreado por https://github.com/aspnet/AspNetCoreModule/issues/50.

Sugiro fechar este tópico e manter o outro. Vou deixar os especialistas em ASP.NET seguirem a partir daí, a menos que haja motivos para pensar que o Azure Web App é parcialmente culpado (improvável com base no @fabiano relatando o mesmo fora do Azure).

Na verdade, isso parece uma regressão nas ferramentas, onde parece ter começado a criar App_Offline.html em vez de app_offline.html. @mlorbetske , @vijayrkn - alguma ideia do que pode ser?

Entendo, então você está dizendo que o tempo de execução do núcleo (AspNetCoreModule) sempre fazia distinção entre maiúsculas e minúsculas, mas que não costumava ser um problema porque o VS estava usando o caso correspondente e agora não é?

Embora, independentemente disso, eu argumentaria que o tempo de execução não deve diferenciar maiúsculas de minúsculas aqui, portanto, há dois caminhos possíveis para resolver o problema.

@davidebbo - isso está correto. Eu acredito que o AspNetCoreModule sempre foi sensível a maiúsculas e minúsculas.

@davidebbo

e nada relacionado ao Azure App Service (que é o lado de onde venho)

Acho que o motivo de trazer o Azure AppService para a discussão é porque, sem nenhuma alteração em nosso nome, as coisas começaram a falhar, não alteramos nenhuma de nossas versões de pacote. A revisão do ANCM foi revisada nos App Services?

@ctolkien sim, acho que foi realmente atualizado. Portanto, pode muito bem ser que a conclusão acima não esteja correta. Em vez disso, a nova teoria é:

• O ANCM mais antigo (7.1.1965.0) não fazia distinção entre maiúsculas e minúsculas.
• O mais novo (7.1.1970.0) tornou-se sensível a maiúsculas e minúsculas.
• Nada mudou no lado da publicação do VS, e a caixa sempre foi App_Offline.htm .

@moozzyk você acha que é uma possibilidade, ou você tem certeza de que sempre foi sensível a maiúsculas e minúsculas?

@moozzyk @davidebbo - Não houve alteração nas ferramentas do VS para o invólucro app_offline. As ferramentas do VS chamam msdeploy com a regra appoffline (-enablerule:AppOffline) e msdeploy descarta App_Offline.htm.

Esse problema parece uma mudança de comportamento no ANCM. Com base no primeiro comentário aqui app_offline deve diferenciar maiúsculas de minúsculas (https://github.com/aspnet/IISIntegration/issues/81).

@ctolkien

Alterar App_Offline para app_offline corrige o problema

Onde eu mudo isso? Faço MSDEPLOY diretamente do Visual Studio para o Azure.

@oyvindvol

Onde eu mudo isso? Faço MSDEPLOY diretamente do Visual Studio para o Azure.

Você não pode alterar a caixa de App_Offline do MSDEPLOY até onde eu sei, você precisará personalizar o script de uma solução por enquanto. Você pode usar o script powershell que postei acima como ponto de partida.

Para atualizar todos, confirmamos que a teoria acima está correta: o bug de diferenciação de maiúsculas e minúsculas é uma regressão na versão mais recente do ANCM, e essa versão foi implantada no Serviço de Aplicativo do Azure em dezembro, fazendo com que os usuários atingissem isso repentinamente.

O plano é obter uma correção ANCM da equipe ASP.NET Core e implantá-la no Serviço de Aplicativo. Ainda não há previsão de chegada, mas deve acontecer em algum momento de janeiro.

Obrigado!

@davidebbo seremos capazes de baixar o ANCM para instalar em nosso próprio servidor usando iis e atingir esse bug específico também?

@Pictuel eu acho que sim. Observe que meu ângulo aqui é estritamente o Serviço de Aplicativo do Azure, portanto, deixarei a equipe do Core comentar sobre cenários não Azure.

obrigado pela atenção :)

@Pictuel sim, garantiremos que uma versão atualizada do instalador de hospedagem do Windows para .NET Core seja lançada contendo a atualização para o ANCM.

@shirhatti

@shirhatti Estou monitorando aqui quando o instalador atualizado estiver disponível para atualizar os links doc.

Depois de passar por esse encadeamento, não tenho certeza de qual é exatamente a solução alternativa para os Serviços de Aplicativos. É a configuração do aplicativo ou está usando um script de implantação personalizado ou parando e iniciando o site?

Se for a configuração do aplicativo, li outro comentário dizendo que isso faz com que o site não pegue as novas DLLs.

Se entendi corretamente, não há solução alternativa do nosso lado até que uma atualização esteja disponível no ANCM (https://github.com/aspnet/AspNetCoreModule/issues/50). Os serviços de aplicativo devem ser atualizados pela equipe do Azure.

Acho que a melhor aposta no App Service é parar/iniciar o aplicativo conforme descrito por @dtmnash aqui .

@davidebbo "O plano é obter uma correção ANCM da equipe ASP.NET Core e implantá-la no Serviço de Aplicativo. Ainda não há ETA, mas deve acontecer em janeiro." -- Avise-nos quando um ETA estiver pronto para isso :)

O ETA de implantação provisória está entre os dias 24 e 30. A implantação acontece gradualmente nas várias unidades de escala, portanto, nem todos obterão a correção exatamente ao mesmo tempo.

Obrigado, para mim, apenas começou a funcionar :-)

Ainda é um problema para mim :(

@hbunjes obrigado por confirmar!

@rsnj está acontecendo progressivamente ao longo de algum período de tempo. Tudo deve ser feito até o final do mês (a menos que encontremos um problema).

@davidebbo A implantação parece funcionar para alguns dos meus aplicativos, mas não para todos. O estranho é que algumas implantações falham, mas outras não para aplicativos executados no mesmo Plano de Serviço de Aplicativo. É possível ver qual versão do ANCM está sendo executada para um determinado aplicativo da web?

@henningst Consulte https://github.com/aspnet/AspNetCoreModule/issues/50#issuecomment -271381892 para obter uma maneira de verificar.

Não estava funcionando para mim ontem, mas é agora. Obrigado @davidebbo!

Começou a funcionar para mim também. Obrigado!

Sim, a implantação agora está concluída, portanto, deve funcionar para todos.

Tudo de bom para mim aqui também.

Parece estar funcionando agora. A partir do relatório, levou mais de um ano para corrigir isso. Eu diria que os problemas de implantação têm maior prioridade :p

Como corrigir isso para não-Azure?

@pekkah acho que passou por problemas distintos. O último era muito mais recente do que um ano.

@jdshkolnik para não-Azure, acho que você só precisa começar a usar o novo ANCM.

@jdshkolnik
A atualização está disponível para download em https://www.microsoft.com/net/download/core#/runtime
Este é um link direto para o download.

@shirhatti Eu instalei isso, mas ainda estou recebendo esses erros.

Ainda estou recebendo o erro em São Paulo, sul do Brasil.

@jdshkolnik Qual versão você vê quando executa isso no PowerShell?

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

@shirhatti 7.1.1971.0

Atualização : desculpe, foi minha culpa. Eu estava revisando e atualizando as etapas de implantação de uma versão existente em vez da definição da versão. Já perdi as contas de quantas vezes fiz isso...

Ainda estou me deparando com esse erro toda vez que tento implantar, embora minha versão do aspnetcore.dll seja a que supostamente foi corrigida.

versão aspnetcore.dll: 7.1.1971.0
Implantado usando : tarefa VSTS Azure App Service Deploy v3.* (versão prévia)
Colocar o aplicativo off -line: Verificado
Remover arquivos adicionais no destino : Verificado
Renomear arquivos bloqueados : Marcado
Configuração do aplicativo MSDEPLOY_RENAME_LOCKED_FILES : não adicionado

Neste estágio, não está claro para mim quais configurações são ou não necessárias para que isso funcione.

Acabei de ter meu primeiro problema de arquivo em uso novamente agora nos serviços de aplicativos do 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 erro: ERROR_FILE_IN_USE

2017-02-14T22:41:34.3837386Z Mais informações: O Web Deploy não pode modificar o arquivo 'Ascend.Ammo.Portal.exe' no destino porque está bloqueado por um processo externo. Para permitir que a operação de publicação seja bem-sucedida, talvez seja necessário reiniciar seu aplicativo para liberar o bloqueio ou usar o manipulador de regras AppOffline para aplicativos .Net em sua próxima tentativa de publicação. Saiba mais em: http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_FILE_IN_USE.

2017-02-14T22:41:34.3837386Z Contagem de erros: 1.

FYI: os documentos parecem vincular a um instalador com a versão antiga (*.1970): https://docs.microsoft.com/en-us/aspnet/core/publishing/iis#install -the-net-core- pacote de hospedagem de servidor windows.

Além disso, parece que na página de downloads do tempo de execução apenas a versão LTS tem a correção?

@shirhatti ~Deixe-me saber quando o novo link do instalador do pacote de hospedagem estiver pronto, e eu o colocarei nos documentos (está em alguns lugares).~

~É este: https://go.microsoft.com/fwlink/?linkid=837808 ... esse não é um link aka.ms.~

Eu configurei https://github.com/aspnet/Docs/pull/2773 para cobrir isso se o fwlink estiver ok.

Também acontece no visual studio e, como mostram as opções - a regra offline do aplicativo está presente.

@davidebbo você poderia confirmar se isso foi corrigido? Ouvindo de muitas pessoas que eles ainda estão acertando. A versão de lançamento das ferramentas tem alguma correção para isso ou ainda é um problema de hospedagem?

Também estou tentando descobrir por que e quando isso acontece. Tenho quase certeza de que vi que o processo está sendo executado no process explorer no site scm e foi publicado muito bem.

Estou no processo de atualizar meus sites para as ferramentas mais recentes também, esperando que o problema esteja relacionado às ferramentas antigas do project.json.

A correção foi implantada no Serviço de Aplicativo do Azure há algum tempo e não tenho conhecimento de ninguém ainda vendo o problema depois. Obviamente, os usuários em hosts que não são do Azure ainda poderão vê-lo se não tiverem sido atualizados.

Para o Azure, se você estiver com problemas, teste-o da seguinte maneira:

• Vá para o explorador de processos do Kudu e verifique se o processo do seu aplicativo está em execução (normalmente dotnet.exe)
• Crie manualmente um arquivo app_offline.htm (por exemplo, execute touch app_offline.htm ) a partir do comando Kudu
• Verifique o explorador de processos novamente e certifique-se de que o processo não esteja mais lá.

Vou testar um pouco mais, você viu a imagem alguns posts acima, mostra claramente que o arquivo está em uso e usa o aplicativo offline.

Mas vou testar como você pediu.

Além disso, estamos usando scaleout + aplicativos implantados em aplicativos virtuais - não sei se isso muda alguma coisa.

@pksorensen fazendo isso 'manualmente' ajudará a isolar de qualquer coisa que o WebDeploy possa estar fazendo. ou seja, se simplesmente soltar app_offline.htm não parar o processo, então realmente sabemos que há um problema não causado pelo WebDeploy.

Observe que normalmente, você acaba com um processo dotnet.exe, enquanto no seu caso você tem um nome exe diferente. Eu me pergunto se isso de alguma forma se relaciona com o problema.

1. Vá para o explorador de processos do Kudu e verifique se o processo do seu aplicativo está em execução (normalmente dotnet.exe)
   Eu fiz isso, mas não é dotnet.exe, mas nosso nome compilado bin Ascend.Ammo.RegistrationTablet.exe

Então eu toquei app_offline.htm, mas isso não matou o processo.

Estou fazendo algo errado, pois não vejo dotnet.exe?

Vou deixar os especialistas dotnet/ANCM comentarem sobre essa parte. Eu sei que, por padrão, ao implantar um aplicativo ASP.NET principal, ele usa dotnet.exe. Eu acho que o caso quando não é quando você usa a implantação autônoma (ou o que quer que seja chamado). Mas não tenho ideia de como isso afeta o ANCM e o app_offline.htm.

@DamianEdwards quem pode comentar melhor sobre isso?

Evito esse problema usando slots de implantação. Funciona 100% do tempo. Pare o slot antes de copiar os arquivos. Isso removerá tudo da memória para que sua cópia funcione sem arquivos bloqueados. Em seguida, inicie o slot e troque para produção. Benefício adicional que seus clientes nunca veem a página offline do aplicativo. Eles obtêm uma implantação de tempo de inatividade 0.

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

O slot @DarqueWarrior funciona é claro (e é bom usar por outros motivos), mas o principal neste tópico é entender por que app_offline parece ineficaz em desligar o processo Core para algumas pessoas como @pksorensen. E eu gostaria que a equipe Core comentasse sobre isso.

@davidebbo Para responder à sua pergunta anterior, portátil vs autônomo não tem influência no comportamento app_offline. O arquivo offline do aplicativo é monitorado por w3wp.exe (pelo módulo ASP.NET Core).

@DarqueWarrior Obrigado pelo conselho, mas um comentário - se você, como nós, estiver implantando sites multiplicados para aplicativos virtuais no mesmo serviço de aplicativo, os slots (se bem me lembro) funcionam em todos eles, então você teria que implantar todos os sites antes trocando. Este é um incômodo. No momento, podemos implantar facilmente partes (micro serviços) em aplicativos virtuais individuais. Claro que podemos espalhar isso em serviços de aplicativos separados, mas precisaríamos de balanceadores de carga/gateways na frente para fazê-los compartilhar o mesmo domínio novamente, também custa mais tempo do que estamos dispostos a fazer agora.

Então, eu concordo que o que você está sugerindo é o caminho preferível, mas não se encaixa conosco agora. Portanto, ainda espero uma resolução sobre o problema do arquivo em uso.

@pksorensen alguma chance de você configurar uma reprodução em um site fictício e compartilhar seu nome? Basicamente, eu gostaria de vê-lo no estado em que seu site está sendo executado e criar manualmente app_offline.htm no console Kudu não faz com que ele seja encerrado.

@shirhatti alguma ideia do que poderia fazer com que o ANCM não encerrasse o processo? Quão agressivamente ele tenta fazer isso?

@davidebbo Levará um pouco de tempo, mas tentarei criar algo para criar uma reprodução.

@davidebbo Criei um novo aplicativo ASP.NET Core e um novo Serviço de Aplicativo do Azure. Estou usando o recurso "Entrega Contínua (Visualização)" do Azure e estou recebendo esse problema.

2017-03-30T02:54:36.5648892Z ##[erro]Falha ao implantar o Serviço de Aplicativo.
2017-03-30T02:54:36.5658893Z ##[erro]Código de erro: ERROR_FILE_IN_USE
2017-03-30T02:54:37.1850861Z Mais informações: O Web Deploy não pode modificar o arquivo 'myApp.dll' no destino porque está bloqueado por um processo externo. Para permitir que a operação de publicação seja bem-sucedida, talvez seja necessário reiniciar seu aplicativo para liberar o bloqueio ou usar o manipulador de regras AppOffline para aplicativos .Net em sua próxima tentativa de publicação. Saiba mais em: http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_FILE_IN_USE.
2017-03-30T02:54:37.1860517Z Contagem de erros: 1.
2017-03-30T02:54:37.4179909Z ##[erro]Erro: C:\Program Files\IIS\Microsoft Web Deploy V3\msdeploy.exe falhou com código de retorno: 4294967295

Criar manualmente um app_offline.htm em D:\home\site\wwwroot realmente interrompe o processo dotnet.exe.

Então, isso significa que há um problema com a própria "Entrega Contínua (Visualização)"?

Além do que foi dito acima, consertei isso indo manualmente para VSTS Release Definition, Additional Deployment Options, marcando "Take App Offline".

Mas isso levanta algumas questões:
Por que "Take App Offline" está desmarcado por padrão? Esse cenário ainda deve funcionar (por exemplo, reduz o tempo de inatividade)?

Se sim, então por que está falhando? Se não, por que a "Entrega Contínua (Visualização)" a deixa desmarcada?

De qualquer forma - parece que há um bug em algum lugar.

@ Jon12345 : este tópico é apenas para discutir se o app_offline.htm está funcionando corretamente com os aplicativos Core. Portanto, o fato de o VSTS pode ou não estar fazendo isso por padrão é realmente uma discussão separada, que deve ser realizada em um fórum do VSTS (provavelmente https://social.msdn.microsoft.com/Forums/vstudio/en-US/ home?forum=TFService).

Neste ponto, a maioria das pessoas parece ter sido desbloqueada após a correção. Houve um relatório de que não está funcionando por @pksorensen , e estamos aguardando um aplicativo de reprodução para analisar.

Ainda recebo isso no TFS 2017 Update 1.

@jdshkolnik Tem certeza de que está configurado para criar o arquivo appoffline.htm? Se não, está fora do escopo desta questão. Faça o teste manual do appoffline.htm conforme descrito acima.

@davidebbo Sim, é. Muitas vezes, a implantação noturna agendada falha em sua primeira tentativa e exige uma tentativa de reimplantação manual que geralmente é bem-sucedida.

Para sua informação, minha empresa é federada com a sua para que eu possa mostrar facilmente através do compartilhamento de área de trabalho do Skype for Business.

@jdshkolnik , certifique-se de fazer o teste manual discutido acima, pois isso ajuda a tirar todo o resto da equação.

Importante : este problema não se trata de investigar qualquer problema com o VSTS ou outros fluxos de trabalho de publicação. Trata-se apenas de uma coisa: certificar-se de que appoffline.htm está funcionando.

@davidebbo Ele fica offline assim que eu coloco manualmente app_offline.htm na pasta.

Eu não sei como distinguir melhor se estou perfeitamente no tópico aqui. Tudo o que sei é que, de repente, surgiu no ano passado para sites que estavam funcionando sem problemas e, desde então, voltou a aparecer 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 Meu melhor palpite é que o que quer que esse script de implantação esteja fazendo não está criando o appoffline.htm antes de publicar os arquivos. Pode ser um problema ou bug de configuração do VSTS. Mas do ponto de vista da ANCM, o teste que você fez mostra que as coisas estão funcionando conforme o esperado quando o appoffline é criado.

@davidebbo Não sei se o que fiz foi um teste definitivo. Afinal, a segunda tentativa manual após recebermos um erro geralmente é bem-sucedida. O processo de implantação que pode bloquear app_offline.htm não estava em execução.

Ainda estou enfrentando esse problema que diferencia maiúsculas de minúsculas em 7.1.1971.0. Quando tento implantar usando o VS, recebo um erro de arquivo bloqueado, então olhei para ver se o aplicativo ainda estava em execução e com certeza estava. Abri a linha de comando do Kudu para ver quais arquivos estavam no diretório wwwroot e App_Offline.htm estava na pasta, mas o processo ainda estava em execução. Em seguida, digitei touch app_offline.htm e o processo parou de ser executado conforme o esperado. Eu verifiquei os módulos e minha versão aspnetcore.dll é 7.1.1971.0.

@alexgritton isso é estranho. Parece implicar que a ANCM não detectou inicialmente o arquivo. Isso acontece de forma consistente ou aleatória?

Acabei de criar o aplicativo hoje no Azure App Services e está acontecendo o dia todo, então eu diria consistentemente. Você tem alguma outra ideia do que pode estar causando isso?

Na verdade. Vou deixar os especialistas da ANCM comentarem como eles fazem o monitoramento de alterações de arquivos e se eles conseguem pensar em uma razão pela qual a criação inicial não é detectada.

@davidebbo Estou tendo exatamente o mesmo problema. Minha equipe tem uma compilação Fake que copia um arquivo AppBuild.htm do servidor de compilação para o site de destino como app_offline.htm. Em seguida, tentamos usar o msdeploy para sincronizar a pasta e abri-la por outro erro de processo. Se eu tocar no arquivo, renomear o arquivo de app_offline.htm para app_offline.htm.rename e vice-versa, ou sobrescrever app_offline.htm usando o Explorador de Arquivos, o processo será interrompido corretamente. Não faz muito sentido por que não funciona através do nosso script, mas funciona se o fizermos manualmente.

Atualização: descobrimos que atualizar a última hora de gravação parece acionar consistentemente o desligamento:

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 haver algo com o código que monitora o arquivo app_offline.htm.

@derekgreer Então o que você está vendo é que quando você copia o arquivo, o desligamento não é acionado? Não consigo reproduzir isso no console Kudu. por exemplo

• Vá para o console do Kudu
• Execute touch app_offline.htm em D:\home\site para criar um arquivo vazio em uma pasta diferente
• Corra copy app_offline.htm wwwroot . Observe que isso preserva a última hora de gravação e atualiza a hora de criação (comportamento padrão de cópia de arquivo).

Resultado: o processo dotnet.exe é encerrado instantaneamente (você pode verificar usando o explorador de processos Kudu).

Esses mesmos passos funcionam para você? Em caso afirmativo, o que pode ser diferente em seu cenário de reprodução?

Na verdade, eu também deveria ter acrescentado que esse problema tem sido intermitente e que estamos usando o IIS 8 no Windows Server 2012 .

Minha intenção esta manhã era ver se eu poderia reproduzir o problema com um powershell ou script em lote antes de configurar o Kudu Console, mas tendo testado primeiro com o script de construção Fake de teste que minha equipe estava usando na sexta-feira para criar o arquivo app_offline.htm em várias maneiras (copiar arquivo existente, criar novo arquivo, etc.), está funcionando atualmente. Isso reflete o padrão de nossas falhas de compilação, onde às vezes estava encerrando o processo e outras vezes não. Quando começa a falhar, parece fazê-lo de forma consistente. Testamos por horas na sexta-feira e ele consistentemente não parava com uma simples compilação Fake que não fazia absolutamente nada, exceto criar um novo arquivo app_offline.htm. Também devo acrescentar que criamos periodicamente o arquivo manualmente e vemos o processo parar, então não parece haver nenhum tipo de situação em que o processo não seja encerrado após um longo período de uso.

Quando eu puder reproduzir o problema novamente, verei se a criação do arquivo usando powershell e/ou arquivo em lote ainda reflete o problema.

@davidebbo Bem, droga... Acabei de notar que esqueci de comentar uma linha que estava atualizando a hora da última atualização, então de fato ainda está mostrando o mesmo comportamento. Vou tentar com powershell e um arquivo de lote agora e atualizá-lo.

@davidebbo

Desculpe pela confusão. Ok, aqui está o que eu encontrei:

O uso de um arquivo em lote com o seguinte conteúdo parece fazer com que o processo seja encerrado de maneira confiável:

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

O uso de um script bash equivalente também faz com que o processo seja encerrado:

#!/bin/bash

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

Usar um script powershell com o seguinte conteúdo parece nunca fazer com que o processo seja encerrado:

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

Dado que tanto o Fake quanto o Powershell são executados no CLR, enquanto o comando de cópia do DOS, o bash e o Kudu Console não, isso parece apontar para algo relacionado ao arquivo que está sendo criado por meio do CLR.

O estranho é que não vejo diferenças nos timestamps de criação/atualização do arquivo resultante entre as várias versões.

@derekgreer Ah, então você não está executando no Azure App Service. Esse é o meu ponto de vista em toda essa saga, então vou deixar o pessoal do ASP.NET comentar mais sobre isso.

Embora, vale a pena, não consegui reproduzir no Serviço de Aplicativo:

• Use o console do PowerShell do Kudu
• Vá para a pasta site\wwwroot
• Correr New-Item app_offline.htm -type file

@moozzyk você pode ajudar a investigar a reprodução fora do serviço de aplicativo de @derekgreer ?

Mais informações:

Como criar, copiar, renomear etc. por meio do Explorador de Arquivos funcionou consistentemente, decidi ver se um aplicativo explorador de arquivos baseado em .Net refletia os mesmos resultados que estou vendo com Fake e PowerShell. Há um explorador de arquivos baseado em .Net chamado "Nomad" que acabei baixando e testando e os resultados foram consistentes com Fake e PowerShell. Ao criar um arquivo app_offline.htm, o processo não parou. Em seguida, renomeei o arquivo e o renomeei novamente para app_offline.htm e o processo Core foi encerrado.

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

Eu acho que esse método gostaria de incluir o sinalizador "FILE_NOTIFY_CHANGE_CREATION".

Gostaria de saber se a API .Net comum ao Fake, PowerShell e Nomad não aciona esses outros sinalizadores da mesma forma que a criação normal de arquivos.

@shirhatti , você pode garantir que alguém investigue esse possível problema do ANCM?

@davidebbo Ack. Estamos analisando isso

Estou com um problema muito parecido. Se eu copiar em um arquivo app_offline.htm no Windows Explorer, ele interromperá corretamente o processo, mas se eu criá-lo usando COPY app_offline.htm \server\share\siteapp_offline.htm do meu servidor de compilação, ele não será interrompido e os arquivos permanecerão bloqueados .

@gulbanana Eu tenho exatamente o mesmo problema que você. Você já resolveu? @shirhatti Alguma atualização sobre sua investigação? Este deixa a equipe louca porque o pipeline de CI falha o tempo todo devido a falhas de cópia de arquivo que, por sua vez, são causadas pelo dotnet.exe não ser desligado pelo app_offline.htm.

Contornei o problema usando algo echo "<html>page content</html>" > \\server\share\app_offline.htm . Eu acho que @derekgreer está correto que o bug é sobre o ANCM observando apenas alguns métodos de criação de arquivos, e ele pega este.

@derekgreer
Estou analisando a questão agora. Com um de seus comandos de reprodução em minha máquina de teste, consegui reproduzir esse problema. Usei o comando abaixo. (NOTA: o comando abaixo criará um arquivo vazio (tamanho do arquivo zero).

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

Uma coisa interessante é que se eu adicionar algum conteúdo de arquivo ao criar o arquivo app_offline.htm, não há problema. Isso pode ser feito simplesmente adicionando o parâmetro -value "test" da seguinte forma:

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

Você pode confirmar se vê o mesmo sintoma em seu ambiente de reprodução?
Nesse caso, acho que esse problema só acontece quando app_offline.htm vazio é criado de alguma maneira especial, como usar o comando new-item powershell.

@gulbanana
Não consigo reproduzir esse problema com o comando Copiar. Você pode explicar mais detalhadamente a sua reprodução? Seria ótimo se você pudesse encontrar algumas etapas de reprodução com as quais eu possa reproduzir o mesmo problema na minha máquina de teste.

Posso confirmar que não está relacionado ao fato de o arquivo app_offline.htm estar vazio sem executar esses comandos, pois nossa experiência foi copiar um arquivo com o conteúdo desejado para a pasta de implantação. Com base na minha experiência, acho que o segundo comando pode estar causando um evento de alteração de arquivo se estiver realmente funcionando. Talvez ele crie o arquivo e, posteriormente, o atualize com o conteúdo. Independentemente disso, todos os processos relacionados a .net que usei apenas para criar o arquivo com ou sem conteúdo falham ao acionar o desligamento do processo.

@shirhatti Alguma atualização? Você conseguiu confirmar que seu código deveria estar usando o sinalizador "FILE_NOTIFY_CHANGE_CREATION"?

@derekgreer Estamos ouvindo todos os sinalizadores válidos, exceto alterar o último acesso e alterar os atributos.
FILE_NOTIFY_VALID_MASK & ~FILE_NOTIFY_CHANGE_LAST_ACCESS & ~FILE_NOTIFY_CHANGE_ATTRIBUTES

Então, sim, já estamos ouvindo FILE_NOTIFY_CHANGE_CREATION .

cc: @pan-wang

@shirhatti Ah, entendi agora. Eu não sabia que o sinalizador cobria a criação de alterações. Estou curioso, você conseguiu reproduzir o problema?

Não reagir a app_offline.htm vazio foi supostamente corrigido: https://github.com/aspnet/IISIntegration/issues/174

@moozzyk @derekgreer Obrigado pela confirmação. Ok, também descobri que o problema não está diretamente relacionado ao conteúdo do arquivo vazio. Vou atualizá-lo depois de descobrir a causa raiz.

@jhkimnew eu não tenho mais a configuração exata quebrada, mas posso descrever os detalhes:

• IIS em execução no Windows Server 2008 r2, hospedando um aplicativo principal asp.net usando ANCM
• servidor de compilação também é 2008r2, no mesmo domínio
• O servidor IIS tem seu diretório físico do site compartilhado usando o compartilhamento do Windows
• usuário de domínio (a conta do servidor de compilação) executa um script powershell no servidor de compilação
  se esse script usar o comando windows copy para copiar em um app_offline de um arquivo existente em outro diretório, o processo de hospedagem não será encerrado. se o script usar "echo" (que pode ser o /bin/echo de uma instalação do mingw, não tenho certeza), o processo de hospedagem será encerrado.

eu suspeito que o problema tem a ver precisamente com quais atributos de arquivo são ou não atualizados por esse tipo de cópia remota

@gulbanana Só para ficar claro, você tentou com o comando dos copy e não com o commandlet copy-item do power shell? Acho que não tentei a cópia regular dos DOS, mas descobri que qualquer aplicativo baseado em .net que usei não funcionou.

a menos que o powershell tenha um alias para isso, foi dos copy

No meu caso, a cópia do PowerShell não encerrará o processo dotnet.exe, mas o echo, que é um alias de Out-Content, funciona. Eu sinto que é improvável um problema .NET, mas mais sobre por que uma cópia de rede não funciona

Investiguei se há algum problema na notificação de alteração aspnetcore.dll (ANCM), mas não consegui reproduzir o problema quando tentei descartar app_offline.htm manualmente usando o cmdlet powershell ou o comando DOS. E encontrei um ponto que faltava que não foi discutido aqui.
Isso é sobre o desligamento gracioso. Ao contrário do HttpPlatformHandler", o ANCM suporta desligamento normal, o que significa que quando app_offline.htm é descartado no diretório raiz, o ANCM envia um sinal Crtrl-C/Break para o processo de back-end e aguarda até 10 segundos permitindo que o desligamento normal aconteça.
Os 10 segundos são o valor padrão e os usuários podem ajustar o valor com o shutdownTimeLimit das definições de configuração do ANCM. Se o processo de back-end não for encerrado no shutdownTimeLimit configurado, o ANCM deverá encerrar o processo de back-end.

Ao verificar como a publicação do MSDeploy está relacionada ao desligamento normal do ANCM, finalmente encontrei uma etapa de reprodução consistente, que é aumentar o tempo de desligamento (5 segundos) e notei que o MSDeploy tenta novamente apenas 2 vezes por padrão e espera apenas 2 segundos e, eventualmente, não publica porque não espera o tempo de desligamento normal.

@vijayrkn
Depois de colocar 5 segundos de atraso no local de início e término do aplicativo da Web aspnetcore, consegui reproduzir o mesmo erro, relatado neste problema, na segunda tentativa de publicar o aplicativo da Web aspnetcore no servidor IIS local. Anexei o perfil de publicação que usei abaixo também.
Você explicaria por que isso acontece e daria uma orientação correta sobre como corrigir esse problema de publicação? E, por favor, crie um novo problema separadamente para que sua equipe acompanhe esse problema para aprimorar a experiência do usuário.

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

O MSDeploy tenta implantar logo após o app_offline ser descartado. Se houver um atraso na interrupção do processo, a implantação poderá falhar.

A contagem de novas tentativas para a implantação pode ser definida usando esta propriedade msbuild (https://github.com/aspnet/websdk/blob/dev/src/Publish/Microsoft.NET.Sdk.Publish.Targets/netstandard1.0/PublishTargets/Microsoft .NET.Sdk.Publish.MSDeploy.targets#L67)

por exemplo, definir essa propriedade como 10 garantirá que o msdeploy tente novamente por 10 vezes com um atraso de um segundo entre elas.
<RetryAttemptsForDeployment>10</RetryAttemptsForDeployment>

@vijayrkn

Obrigado pela informação. Depois de adicionar as duas linhas abaixo, não vejo nenhum problema com o mesmo ambiente de reprodução.
<EnableMSDeployAppOffline>True</EnableMSDeployAppOffline> <RetryAttemptsForDeployment>10</RetryAttemptsForDeployment>

Portanto, qualquer pessoa que se deparar com o problema semelhante precisaria aumentar a contagem de RetryAttemptsForDeployment com o valor apropriado e tentar novamente se isso puder resolver o problema.

NOTA: A razão pela qual eu adicionei EnableMSDeployAppOffline é porque isso é desabilitado por padrão ao usar o servidor IIS local como destino de publicação de um aplicativo da web aspnetcore. Então, se você não tem certeza se isso está ativado ou não em seu ambiente, você só precisará adicionar a linha também e é por isso que a adicionei aqui para sua informação.

Apenas para garantir que o problema original não se perca devido às discussões mais recentes, o problema que minha equipe enfrentou definitivamente não é um problema de tempo. Testamos manualmente a criação do arquivo app_offline.htm por meio de Powershell, Fake e um explorador de arquivos baseado em .Net chamado "Nomad" e o processo não é encerrado, não importa quanto tempo você espere. A criação do arquivo por meio do Explorador de Arquivos, um arquivo em lote DOS ou um script bash (ou seja, processos não baseados em biblioteca .Net) faz com que o processo seja encerrado em 1-2 segundos.

Isso parece indicar:

1. O problema não está relacionado à rede (todos os testes foram realizados em um compartilhamento de arquivo remoto)
2. Não é um problema de desligamento / temporização gracioso

O fato de que 3 métodos não-.Net para criar o arquivo app_offline.htm encerram o processo de forma confiável e rápida e que 3 métodos baseados em biblioteca .Net para criar o arquivo nunca resultam no encerramento do processo em nossos testes parece ser realmente , indicador muito grande para mim.

@derekgreer
Não consigo reproduzir o problema mesmo com "Nomad".
Aqui está o que eu fiz na minha máquina Windows 10 (amd64).

1. Instalar o IIS
2. Instale o Visual Studio 2017
3. Crie um aplicativo Web AspnetCore e implante no servidor IIS local com o MSDeploy
4. Instale o Nomad v3.2.0.2890 (http://www.nomad-net.info/downloads)
5. Enviar uma solicitação para o aplicativo da web
6. Abra o Gerenciador de Tarefas e confirme se o processo dotnet.exe está em execução
7. Abra o Nomad e crie um novo arquivo chamado app_offline.htm no diretório raiz do aplicativo da web
8. Consulte o Gerenciador de Tarefas e verifique se o processo dotnet.exe desapareceu quando o arquivo app_offline.htm foi criado

Você daria as etapas de reprodução exatas para que eu possa seguir para reproduzir o problema?

Além do fato de que nosso aplicativo .Net Core é na verdade um aplicativo de console .Net 4.5.2 padrão criado no VS 2015 que faz referência a assemblies ASP.Net Core, não vejo diferença. O projeto tem cerca de um ano agora e foi configurado dessa forma na época devido a limitações com referência a tipos de projeto de modelo de núcleo de tipos de projeto de modelo de estrutura .Net e vários tipos de suporte de biblioteca de teste para .Net core.

Identificamos alguns problemas: 1) descartar o arquivo app_offline.htm (usando alguma ferramenta) às vezes apenas acionava a notificação de alteração da propriedade do arquivo que era filtrada pelo ANCM. 2) O ANCM pode falhar ao ler app_offline.htm, pois este último foi mantido pela ferramenta de cópia de arquivos. 3) o desligamento normal causou atraso no encerramento do processo de back-end.
Abordaremos os dois primeiros problemas na próxima versão. Para caso de desligamento normal, o usuário precisa tentar novamente.

parece bom. meu caso definitivamente não era sobre um tempo limite de desligamento gracioso - quando ele para, para imediatamente.

Alguma atualização sobre este assunto?
Obtendo ao tentar implantar um aplicativo ASP.NET Core 1.1 em um slot do Azure Web App usando VSTS

• Eu tenho o MSDEPLOY_RENAME_LOCKED_FILES=1 definido nas configurações do aplicativo
• Gerenciar Tarefa do Serviço de Aplicativo está configurado para colocar o aplicativo offline
• A tarefa de implantação do serviço de aplicativo _was_ configurada para colocar o aplicativo offline, mas isso também não funcionou

A questão principal é que a DLL está em uso:

@ChuckkNorris , consulte https://github.com/Microsoft/vsts-tasks/issues/1607 para obter informações mais recentes sobre isso.

@davidebbo Obrigado pela sua resposta, David. Eu vi esse tópico e foi aí que descobri muitas das soluções alternativas que tentei.

Como esse problema ainda está em aberto e o erro ainda prevalece, eu esperava que houvesse uma correção em breve, não outra solução alternativa. Esta questão está aberta há mais de dois anos, afinal.

@ChuckkNorris enquanto o sintoma é o mesmo, este não é o mesmo problema:

• Problema original relacionado ao uso de maiúsculas e minúsculas de app_offline.htm , fazendo com que ele fosse completamente ignorado. Isso foi corrigido por um tempo.
• Esse novo problema começou há apenas uma semana e acontece porque agora o Core demora mais para desligar quando app_offline.htm é criado, e o msdeploy, por padrão, não espera o suficiente. A solução é aumentar a contagem de novas tentativas.

Acabei de atualizar o VS 2017 para 15.3 e instalar o SDK do .NET core 2.0. Criei um aplicativo MVC simples no VS - tinha como alvo o netcoreapp1.1. Publiquei no Azure e estava tudo bem. Eu atualizei para newcoreapp2.0 e, em seguida, atualizei todos os pacotes nuget para 2.0 (Microsoft.AspNetCore, Microsoft.AspNetCore.Mvc, etc)

Ao tentar publicar no Azure (ou seja, substituir o 1.1), estou recebendo isso

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

Eu tive que desabilitar o MvcViewComplication para que meus aplicativos 2.0 fossem implantados via git e evitem problemas de arquivo em uso.

https://github.com/Microsoft/vsts-tasks/issues/5259
https://github.com/Microsoft/vsts-tasks/issues/1607#issuecomment -349115532
@davidebbo , Podemos encerrar esse problema?
Apesar de adicionar um auxiliar de repetição para implantação na Web, esse problema persiste.

Só queria apontar o óbvio, que isso afeta a publicação FTP também.

O FTP do @jeremycook é um pouco diferente, pois não possui automação para usar o App_Offline. Você precisaria criar manualmente esse arquivo para encerrar o processo, após o qual você poderia copiar os arquivos.

@davidebbo é justo, mas parece que se eu publicar via FTP usando o recurso de publicação do Visual Studio, ele deveria funcionar. Talvez eu esteja postando no lugar errado?

@jeremycook francamente, não tenho certeza do que o VS faz ao fazer a implantação do FTP. Talvez outros possam brilhar, mas parece mais uma questão VS do que ASP.NET.

Embora para isolar, seria interessante testar se a implantação é bem-sucedida se você criar manualmente App_Offline.html e, em seguida, publicar via FTP a partir do VS.

@vijayrkn Você pode comentar sobre o comportamento do VS durante a implantação do FTP?

A publicação FTP do serviço VS para App não oferece suporte a App_Offline.

@vijayrkn ok, então para todos os propósitos práticos, podemos dizer que a implantação do .NET Core via FTP não é suportada, a menos que o usuário pare explicitamente o site antes da implantação. Certo?

@davidebbo - Sim, está correto.

Atingir esse problema ao implantar o aplicativo Web asp.net core 2.0 para IIS da versão VSTS usando o modelo de implantação da Web do IIS. A exclusão falha devido ao arquivo em uso. A opção off-line do aplicativo está ativada.

@davidebbo @vijayrkn @shirhatti tudo isso é um pouco deprimente. Existem planos para que o FTP/XCOPY funcione? Deve ser aberto um novo problema que se concentre na implantação das formas antigas via FTP/XCOPY/ROBOCOPY/etc.?

estou atrasado para esta festa, mas aqui estão alguns bits que quero relatar:
VS 2017 Enterprise
asp.net 4.6.xx
servidor é IIS 8.5 no servidor 2012 R2
sql server types dlls são bloqueados e o bloqueio é tal quando um desenvolvedor diferente faz uma publicação com msdeploy, eles recebem um erro e o site agora está quebrado, pois apenas parte da implantação foi executada.

as dlls dos tipos sql estão bloqueadas na pasta bin do aplicativo e apenas elas.
renomeie os arquivos dll e então eu posso publicar.
a embalagem de tipos sql tem código caned para carregar as dlls não gerenciadas.
parece que isso deve ser alterado para não bloqueá-los. se isso pode ser feito.

Eu vi pessoas falando sobre maneiras de reiniciar o site ou colocá-lo offline, mas não encontrei uma configuração no msdeploy para isso. o xml que eu vi não está nos meus arquivos.

melhor orientação deve ser adicionada ao pacote de tipos sql que a microsoft publica.

Postando sobre este problema, pois parece mais diretamente relacionado ao meu. Eu também segui o problema abaixo no mesmo tópico, embora seja para VSTS. Estou publicando diretamente do visual studio.

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

Este tem sido um problema ligado e desligado para mim, mas recentemente voltou em vigor e em um dos meus sites de serviço de aplicativo recebo esse erro em quase todas as tentativas de publicação. Este site está hospedado em um serviço de nível 'básico', então não tenho slots que uso em outros aplicativos para contornar esse problema.

Isto é para um aplicativo .net core 2 mvc.

Um pensamento: alguns arquivos que fazem parte de um aplicativo da web não estão mudando em cada publicação (como os tipos sql)
mas o ms deploy está tentando substituí-los em cada deploy.
parece que algum tipo de verificação deve acontecer para não re-copiar um arquivo que não foi alterado e isso tornaria a atualização menor e mais rápida e menos precisaria mexer no bloqueio do arquivo.
múltiplos benefícios se isso puder ser feito.

a outra coisa é identificar melhor o que está bloqueando o arquivo e por que e como desfazer isso.
e obtenha isso como parte do pipeline de implantação padrão.

@figuerres Estou querendo lidar com esse problema há alguns meses. Problemas de bloqueio são normalmente evitados devido à cópia de sombra, mas ao carregar essas DLLs nativas de ~/bin , um problema de bloqueio é criado. Eu tenho uma solução em potencial, mas não tenho certeza se é uma solução completamente segura: https://stackoverflow.com/questions/47796553/is-it-safe-to-manually-copy-native-dlls-to- um-diretório-cópia-sombra

Concordo que a documentação do pacote NuGet deve fornecer um método melhor, que não cause problemas de bloqueio.

@figuerres FYI, eu implementei o acima, veja a pergunta do Stack Overflow para o código.

Mate o dotnet.exe no Gerenciador de Tarefas

Qual é a situação aqui? 3 anos depois, ainda não corrigido. Eu tenho que ir manualmente para o servidor e parar o site.

3 anos? O problema foi relatado em agosto de 2017. Off por 1 like whoa.
Em segunda-feira, 23 de abril de 2018 às 20h56 Oliver Janik [email protected]
escrevi:

Qual é a situação aqui? 3 anos depois, ainda não corrigido. eu tenho que ir manualmente
para o servidor e pare o site.

—
Você está recebendo isso porque está inscrito neste tópico.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/aspnet/Home/issues/694#issuecomment-383768450 ou silenciar
o segmento
https://github.com/notifications/unsubscribe-auth/AAXhfrhOTvZn2qb4kU-Y1Kg9I-IQKD9yks5trnhXgaJpZM4FJp_R
.

O primeiro post diz "pekkah abriu esta edição em 23 de junho de 2015"

Você está certo. Minha culpa. Só vi o último carimbo de data/hora na cadeia de e-mail.
Em segunda-feira, 23 de abril de 2018 às 21h06 Oliver Janik [email protected]
escrevi:

O primeiro post diz "pekkah comentou em 23 de junho de 2015"

—
Você está recebendo isso porque comentou.

Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/aspnet/Home/issues/694#issuecomment-383769982 ou silenciar
o segmento
https://github.com/notifications/unsubscribe-auth/AAXhfgwYG-jLjnoJF7MCMtzbbfxSZkt2ks5trnqXgaJpZM4FJp_R
.

Fechando porque isso é tão antigo quanto a sujeira 😄

@Eilon Desculpe, mas por que isso foi fechado? Ainda não está resolvido?

Fechando porque isso é tão antigo quanto a sujeira 😄

Mas ainda é um problema .. ? (mesmo em implantações não azure)

Criei uma nova edição (#3719) para aumentar a visibilidade.