Aspnetcore: 由于文件正在使用，部署失败

我注意到 Azure VM 上的 IIS 文件锁定存在类似问题，阻止了 WebDeploy 部署。 我的解决方法是发出三个 WebDeploy 命令：停止 AppPool、部署、重新启动 AppPool。 看我的剧本； 如果您能够运行三个 WebDeploy 命令，则可能可以使用 Azure 应用程序执行类似的操作。

在 beta6 中遇到这个问题。

同样在这里！ 它实际上导致我的 Visual Studio 2015 冻结 - 在发布我的 vNext 应用程序时（我认为是 beta6 和 beta7）。

您是否使用Microsoft 提供的脚本进行部署？ 如果是这样，您可以在PublishAspNet5Website.ps1中添加一行来重新启动 Web 应用程序：

Restart-AzureWebsite -Name $websiteName

我在这篇文章中概述了我的构建脚本修改： Resolve an ASP.NET 5 Deployment Issue to Azure Web App Slot

@brandonmartinez ，重新启动网站无济于事，因为生产网站将继续接收请求，因此将重新锁定文件。 目前，同时更新 IIS 和 Azure 网站的唯一可靠方法是关闭网站的应用程序池，然后更新文件，然后重新启动网站。 只需关注@GuardRex的链接了解更多详情。

但是，在使用 VS2015 在默认条件下工作时，我们不需要处理自定义部署脚本。

希望新的 HttpPlatformHandler 基础设施（不再需要 AspNet.Loader.dll）会更宽容一些，但我不会在这里屏住呼吸。 我们可能会得到另一个锁定的.dll。

@rubenprins这也是我使用的解决方法，通过 VS 中的 Azure SDK 工具。

如果您可以获得对 VM 的 PS 访问权限，则可以使用 PS 命令执行此操作。 https://github.com/GuardRex/net5-iis-ps-publish/blob/7623122dbfdc55a7c53c8edd2e97443e0eea22c9/net5-iis-ps-publish.ps1#L389 -L396

aspnet/vsweb-publish也很有趣； 但是，它看起来像使用offline-template.html ，并且我认为发现该方法不会阻止 dll 锁定问题......仅停止 AppPool，部署和重新启动 AppPool 一直是稳定的，工作方法。

在使用 VS2015 在默认条件下工作时，我们不需要使用自定义部署脚本

不过，我想到了一件事：能够使用“发布到文件系统”并在发布后立即挂钩包含 MSDeploy 位的脚本，这为多个 VM 启用了非常简单且有用的部署故事。 由于脚本是按顺序执行的，因此它只是在 VM-to-VM 下进行。 做一个不错的咖啡休息时间。 ：微笑：

在开始使用 Azure 资源管理器配置面向 Internet 的负载均衡器时，我有一个问题，Azure 资源管理器团队询问如何告诉负载均衡器在部署时暂时停止向 VM 发送流量。

无论如何...回到@pekkah提出的主题。 由于我们知道 PS 命令有效，因此请检查在 VSO 构建中执行它们的选项：

微软/vso-agent-tasks
在构建过程中运行脚本
在 Team Foundation Service (Visual Studio Online) 中为 Azure 持续部署构建过程运行预构建脚本
Visual Studio Online 中的新构建自动化功能

......是的......类似的东西应该适合你。

这里同样的问题...

还在等官方解决

布鲁诺

这将由https://github.com/aspnet/IISIntegration/issues/81 解决。

@moozzyk ，该问题只会通过 msdeploy 等专用工具修复部署。 Xcopy/File 同步部署仍然是不可能的，这也将阻止/阻碍许多仅适用于 ASP.NET v1-4 的 CI 场景。

ASP.NET Core 1.0 RC2 中仍然存在问题，Visual Studio 2015.2 MSDeploy to IIS 8 on Windows 2012 R2 和最新的服务器工具。 终止 dotnet.exe 进程或回收应用程序池可解决此问题。 但这需要对服务器进行远程桌面访问，这并不是一个顺利的过程。

@dg9ngf - 这是 web.deploy 现在的一个错误。 他们为 Azure 添加了 app_offline.htm 功能，但在本地部署时默认禁用。 尝试打开您的发布配置文件 (PublishProfiles->*.pubxml) 并更改：

<EnableMSDeployAppOffline>False</EnableMSDeployAppOffline>

到

<EnableMSDeployAppOffline>True</EnableMSDeployAppOffline>

如果这不起作用，请询问@vijayrkn

如果您使用 VS 工具通过 msdeploy 配置文件进行发布，则此属性会自动添加到您的 pubxml。

<EnableMSDeployAppOffline>True</EnableMSDeployAppOffline>

在您的输出窗口中，您应该会看到与此类似的 msdeploy 命令。

"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命令中的应注意在部署期间添加 appOffline。

如果需要自定义 appOffline 内容，可以在 pubxml 中设置该属性。

<AppOfflineTemplate>Path to app offline</AppOfflineTemplate>

该属性_不_存在于 Visual Studio 创建的 .pubxml 文件中。 所以我添加了它，但它没有改变任何东西。 -e nablerule:AppOffline参数_not_ 不会出现在输出窗口中。

您可以共享输出窗口中显示的 msdeploy 命令行吗？

另外，您能否确认 pubxml 的 WebPublishMethod 为“MSDeploy”。
<WebPublishMethod>MSDeploy</WebPublishMethod>

不，文件有这个： <WebPublishMethod>FileSystem</WebPublishMethod>

这是输出窗口中的命令行： 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]

我正在使用 VSTS 中的“Azure Web 应用程序部署”任务进行部署，如本文所述：http: //donovanbrown.com/post/2016/05/30/DevOps-for-ASPNET-Core-RC2

有没有办法使用该方法指定<EnableMSDeployAppOffline>True</EnableMSDeployAppOffline> ？

嗨，我在 Azure 遇到了同样的问题，我通过这种方式解决了https://github.com/davidebbo/WAWSDeploy/issues/14

@dg9ngf在当前版本的 powershell 脚本中，我们仅对 WebPublishMethod - 'MSDeploy' 支持 appOffline。

AppOffline 对文件系统发布的支持将在下一个版本中提供。

@bojingo我也有同样的情况。 你想通了吗？

@davenewza ：如果您再次访问该博客文章，解决方案在评论中。
http://donovanbrown.com/post/2016/05/30/DevOps-for-ASPNET-Core-RC2

基本上你需要添加 VSTS 步骤来停止/启动站点。 与理想的解决方案相去甚远（实际上，相当蹩脚），特别是因为我没有使用部署槽，但它适用于我们的开发/测试环境。

Web 应用程序部署 VSTS 任务有一个新的预览 ARM 版本，它基于 msdeploy 并承诺修复它，但我没有运气，因为我需要客户端为订阅创建服务主体，并且很麻烦。 也许你可以让它工作：
https://github.com/Microsoft/vsts-tasks/tree/master/Tasks/AzureRmWebAppDeployment

@vijayrkn VS2015中的“发布 Web”对话框不包含任何设置 msdeploy 的选项 - 仅提供 WebPublishMethod=FileSystem 的选项。

你能为 WebPublishMethod=msdeploy 提供一个示例 .pubxml 吗？

@tomfanning对于 ASP.NET 核心控制台应用程序，当前唯一可用的发布选项是文件系统。 您是否正在尝试发布控制台应用程序？ 对于 web 应用程序，所有这 4 个选项都应该可用（webdeploy、web 部署包、文件系统和 ftp）。
示例 webdeploy pubxml - https://github.com/dotnetpublish/AspNetCoreBlogList/tree/master/src/AspNetCoreBlogList/Properties/PublishProfiles

如果它是一个 Web 应用程序并且您只看到文件系统发布选项，您可以检查 xproj 以查看它是否导入了这个选项？
<Import Project="$(VSToolsPath)\DotNet.Web\Microsoft.DotNet.Web.targets" Condition="'$(VSToolsPath)' != ''" />

@bojingo我已经能够设置服务主体，网上有几个教程。 我这里没有链接，但如果需要，我可以查找它们。 现在我的问题是该任务需要一个不在 ASP Net Core 发布上生成的 parameters.xml 文件... :(

我有 TFS 2015 on-prem，这仍然是一个非常烦人的问题。

我也遇到了这个问题...

我的解决方案是让我部署到的暂存槽停止，然后发布到它（自动交换有效）。 重新启动，然后部署不起作用（使用 VSTS 部署）

我将章鱼与 Azure Web 应用程序一起使用，它没有提供暂存槽的选项。 但是，检查以下选项似乎有效：

• 在根目录中使用空白 app_offline.html 安全地关闭应用程序域。
• 删除目标上不属于部署的文件

我正在使用 Visual Studio 2015 Update 3 将 asp.net core 1.1 / .net framework 4.5.2 站点发布到 IIS。 它会下拉App_Offline.htm ，但不会关闭该网站。 如果我在服务器上将其重命名为app_offline.htm ，则该站点将关闭。

根据这个 app_offline.htm 应该不区分大小写。

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

Deployer 上传 app_offline.htm（不区分大小写）

我刚刚再次发布，看到App_Offline.htm被删除，我的网站没有关闭，我得到文件正在使用错误。 当我将其更改为app_offline.htm时，我的网站出现故障，我可以毫无错误地发布。

我在共享的 UNC 路径上托管 - 我不知道这是否会有所不同。

@Tratcher - 你知道为什么 App_Offline.htm 的外壳会在这里有所作为吗？

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

我能够通过添加 Azure 应用设置来解决这个问题

MSDEPLOY_RENAME_LOCKED_FILES = 1

...如此处所述：
https://github.com/Microsoft/vsts-tasks/issues/1607#issuecomment -260946957

YMMV

@BenBarreth是否有类似的东西适用于非 Azure？

不是我知道对不起@jdshkolnik

似乎 MSDEPLOY_RENAME_LOCKED_FILES = 1 可能存在问题。它有助于部署成功，但可能意味着新的 DLL 在运行时不会被拾取：
https://github.com/Azure/azure-webjobs-sdk-script/issues/569#issuecomment -264490818

对我来说，这似乎不是一个合适的“修复”。 它只是隐藏了部署失败。

真正的修复可能会在这个问题中描述：
https://github.com/Azure/azure-webjobs-sdk-script/issues/1023

真的在寻找解决方案。 看起来 RM web deploy VSTS 任务在选择“Take App Offline”选项的情况下解决了这个问题，但截至本周末，我们不断收到错误消息。 我们已恢复为停止部署槽、部署并重新开始。

与我们一样，这个问题在上周五出现，从那时起就阻止了我们进行部署......

同样在这里。 看起来它只影响 Always On = true 的站点，但这并不确定。

即使在我的配置中设置 MSDEPLOY_RENAME_LOCKED_FILES = 1，我仍然有这个问题。 现在几乎不可能更新我的服务器上的构建。 这只是几天前才开始发生的。

本周我开始出现同样的问题。 直到本周，在 VSTS 中部署 AzureRM 应用服务，设置 Take App Offline = true 一直有效。 现在这个设置似乎要么被忽略，要么服务没有及时下线。 我必须在运行版本时手动重新启动或停止/启动应用程序服务，因为它超出了。

这里同样的问题。 AzureRm 工作了几个月，突然停止了。 我的最后一次部署是在两周前的 12 月 5 日，现在在 12 月 20 日，它正在生成 Error_File_In_Use。 不得不回到手动启动/停止非常恼火。

这是我们在 Powershell 中的解决方法，我们现在将其用作 CI/构建过程的一部分。 特别感谢@appveyor伙计们提供的帮助：

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

这利用Kudu REST API来HTTP PUT正确放置app_offline.htm文件。 我们已将 WebDeploy 配置为删除不在部署中的任何文件，因此它会自动删除该文件作为部署的一部分。 如果您不使用此模式，您可能需要在部署完成后使用HTTP DELETE重复该步骤以删除文件。

在 AzureRM 任务之前添加 Trackyon Stop 并在之后添加 Trackyon Start 任务对我来说效果很好。 TakeAppOffline = true 不需要这样做，但它可以正常工作，并且可以避免手动或脚本编写。 只需将任务添加到发布定义中。 Trackyon 步骤易于设置

2016 年 12 月 21 日凌晨 12 点 10 分，Chad T < [email protected] [email protected] > 写道：

这是我们在 Powershell 中的解决方法，我们现在将其用作 CI/构建过程的一部分。 特别感谢@appveyor https://github.com/appveyor的帮助：

$username = $ env:deployusername
$password = $环境：部署密码
$base64AuthInfo = [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes(("{0}:{1}" -f $username,$password)))
$标头 = @{
'授权' = ('基本 {0}' -f $base64AuthInfo)
'如果匹配' = '*'
}
$apiUrl = " https://YourAzureWebsite.scm.azurewebsites.net/api/vfs/site/wwwroot/app_offline.htm "
$filePath = "app_offline_tmp.htm"
调用-RestMethod -Uri $apiUrl -Headers $Headers -Method PUT -InFile $filePath -ContentType "multipart/form-data"

这利用了 Kudu REST API https://github.com/projectkudu/kudu/wiki/REST-API到 HTTP PUT 正确大小写的 app_offline.htm 文件。 我们已将 WebDeploy 配置为删除不在部署中的任何文件，因此它会自动删除该文件作为部署的一部分。 如果您不使用此模式，您可能需要在部署完成后重复使用 HTTP DELETE 删除文件的步骤。

-
您收到此消息是因为您发表了评论。
直接回复此邮件，在 GitHub 上查看https://github.com/aspnet/Home/issues/694#issuecomment-268436959 ，或将帖子静音https://github.com/notifications/unsubscribe-auth/AID9WoUdbuBnFoXR2K5o8AiUtv8nE9dRks5rKLTcgaJpZM4FJp_R 。

此消息是非公开的，可能包含特权、专有或机密信息。 如误收，请立即通知寄件人，并删除原件的所有副本。 禁止您对电子邮件的任何其他使用。 任何未经授权的复制、存储、使用或披露此消息的内容都是不允许的，并且可能是非法的。 在当地法律允许的情况下，我们的系统可能会监控和扫描与 Lithero 的电子通信，以确保信息安全和评估内部对 Lithero 政策和适用法律的遵守情况。

/抄送@davidebbo

尝试在您的应用的 Azure 应用设置中设置MSDEPLOY_RENAME_LOCKED_FILES=1 。

@davidebbo这似乎无法解决问题。

我认为这与围栏 Azure 一侧的更改有关？ 很多人（尤其是在 aspnet slack 频道上）都同时遇到了这个问题。

Azure 中的变化无法解释为什么我们会在 TFS 上看到这种情况。 会不会是代理？

我们看到了同样的问题。 App_Offline.htm 未被拾取。 奇怪的是，如果我们从 VS 部署它运行良好。

奇怪的是，对我来说，它不适用于 VS，如下所述：#1883

我的团队也遇到了这个问题，几乎每次部署都因文件锁定而失败。 需要重新启动 azure 中的每个应用程序并重新运行部署。 我们正在使用 Octopus Deploy。

我的团队今天早上遇到了这个问题。 微软团队有什么意见吗？ 发布管道对我们的生产力至关重要，这会阻止发布到生产站点。 谢谢！

@bmoscao - app_offline.html 区分大小写。

我在 Azure 上也出现了这个问题。 我没有做任何事情来导致它。

我也有这个问题。 问题是EnableMSDeployAppOffline设置为true - 项目输出显示-enablerule:AppOffline作为 Visual Studio 运行的命令的一部分。 我不知道该怎么办...我最近才开始遇到这个问题..

我们的解决方法是停止应用程序池，部署，然后重新启动应用程序池。 我们正在使用 Release Manager 和内联 powershell插件来完成此操作。

停止：

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

开始：

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

不过，肯定会感谢 Microsoft 的一些输入，这在过去仅在 RM Azure 部署步骤中启用 appOffline 规则时效果很好。

@davidebbo我们正在使用带有插槽的 ASP.NET Core、VSTS Release Manager 和 AzureRmWebApp。

@davidebbo谢谢！ 这个对我有用 ;）

也发生在我们身上 - msdeploy 到 Azure。 很高兴看到它同时为许多人神秘地开始了——而且不仅仅是我们——但总体而言并不是超级令人放心！

我不认为 MS 的人需要对此进行确认，可能他们很清楚问题出在哪里。 无论如何，这里也一样。 从 VSTS 部署，12 月初停止工作。 目前我正在使用 trackyon 任务停止/启动。

通过这个线程，对于每个条目，并不总是很清楚：

1. 问题是指 Azure 应用服务还是其他一些托管
2. 人们是否尝试过如上所述更改 app_offline 大小写。 似乎有几个人报告了那里的成功。
3. 是否尝试过MSDEPLOY_RENAME_LOCKED_FILES 。 同样，有几个人似乎已经成功了。

如果您遇到此问题，请明确说明您的方案是什么以及您尝试过什么，以便我们理解这一点。 谢谢！

@davidebbo

当我尝试使用 Visual Studio/MSBuild 进行部署时，我收到消息 ERROR_FILE_IN_USE。 该任务是在服务器上创建一个 App_Offline.htm 文件，但它不会关闭应用程序。

使用 Web 部署创建 app_offline.htm 文件会使应用程序停机。

这是我的设置：

• 服务器：IIS 8、.NET Core Windows Server Hosting 1.1.0 和 Web Deploy 3.6
• 我的机器：Visual Studio 2015 Update 3 和 .NET Core 1.0.1 Tools Preview 2
• 发布个人资料：

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

我已经在一个类似的线程上评论了这个错误，并且每次我想重新部署时都不得不停止并重新启动我的 Azure Web 应用程序（仅在开发环境中）。 在这周之前从来没有这样做过。 我决定基本上从模板创建一个 Visual Studio 2015 .net 核心 Web 应用程序，而无需任何修改。

我在本地主机上运行 Web 应用程序一点问题都没有。
我将新应用程序发布到我的 Azure Web 应用程序服务计划没有问题，浏览器立即启动该站​​点没有问题。
我检查了 Azure 仪表板，完全没有问题。

然后我去重新发布了网络应用程序，没有修改任何东西 - 代码或设置，并且出现以下错误。

从那时起，我必须停止 Web 应用程序，发布到 Azure，然后启动 Web 应用程序。 这以前从未发生在我身上。 这是一个非常简单的 Microsoft 模板部署。

我记录了整个过程，并在 Microsoft 2015 VS 反馈系统中发送了该反馈。 希望你能找到那个录音。 或者我可能会再做一次。

问候彼得

@davidebbo

问题是指 Azure 应用服务还是其他一些托管

Azure 应用服务。

人们是否尝试过如上所述更改 app_offline 大小写。 似乎有几个人报告了那里的成功。

将 App_Offline 更改为 app_offline 可以解决问题 - 此文件是通过 webdeploy 自动创建的，并在部署过程中使用“App_Offline”外壳，这是问题的症结所在。

@davidebbo
与@ctolkien 完全相同。

@davidebbo

问题是指 Azure 应用服务还是其他一些托管

就我而言，我正在部署到 Azure 应用服务。 不知道其他主机。

人们是否尝试过如上所述更改 app_offline 大小写。 似乎有几个人报告了那里的成功。

我正在使用 VSTS (https://aka.ms/azurermwebdeployreadme) 中的“部署 AzureRM Web 应用程序”任务。 有一个选项“使用 Web 部署发布”<-选中和“使应用程序脱机”<-选中了曾经可以工作的选项，直到某处发生更改并且停止工作。
“信息”工具提示明确说明将“app_offline.htm”与小写“a”一起放置。
我不知道如何使用这个脚本来改变它，它应该已经是小写的了。

是否尝试了 MSDEPLOY_RENAME_LOCKED_FILES。 同样，有几个人似乎已经成功了。

没试过。 不知道该怎么做。 但无论如何，我宁愿让应用程序脱机，而不是更改锁定的文件内容。

谢谢大家。 所以很明显，主要问题在于app_offline.htm的外壳，而不是与 Azure App Service 相关的任何内容（这是我来自的一方）。 这由https://github.com/aspnet/AspNetCoreModule/issues/50 跟踪。

我建议关闭这个问题并保留另一个问题。 我会让 ASP.NET 专家从那里得到它，除非有理由认为 Azure Web App 是部分原因（不太可能基于@fabiano在 Azure 之外报告相同的情况）。

实际上，这看起来像是工具的回归，它似乎已经开始创建 App_Offline.html 而不是 app_offline.html。 @mlorbetske ， @vijayrkn - 知道它是什么吗？

我明白了，所以您是说核心运行时（AspNetCoreModule）总是区分大小写，但它过去不是问题，因为 VS 使用匹配的大小写，现在不是了？

尽管无论如何，我认为运行时在这里不应该区分大小写，因此有两种可能的路径来解决这个问题。

@davidebbo - 这是正确的。 我相信 AspNetCoreModule 总是区分大小写的。

@davidebbo

而不是与 Azure App Service 相关的任何内容（这是我来自的一方）

我想将 Azure AppService 引入讨论的原因是因为没有代表我们进行任何更改，事情刚刚开始失败，我们没有更改任何包版本。 ANCM 修订版是否针对应用服务进行了修订？

@ctolkien是的，我认为它确实已更新。 所以很可能上面的结论是不正确的。 相反，新理论是：

• 较旧的 ANCM (7.1.1965.0)不区分大小写。
• 较新的版本 (7.1.1970.0) 变得区分大小写。
• VS 发布方面没有任何变化，外壳一直是App_Offline.htm 。

@moozzyk你认为这是一种可能性，还是你肯定它总是区分大小写？

@moozzyk @davidebbo - app_offline 外壳的 VS 工具没有变化。 VS 工具使用 appoffline 规则 (-enablerule:AppOffline) 调用 msdeploy，然后 msdeploy 删除 App_Offline.htm。

这个问题看起来像是 ANCM 中的行为变化。 根据这里的第一条评论 app_offline 应该不区分大小写（https://github.com/aspnet/IISIntegration/issues/81）。

@ctolkien

将 App_Offline 更改为 app_offline 可解决此问题

我在哪里改变这个？ 我直接从 Visual Studio 到 Azure 执行 MSDEPLOY。

@oyvindvol

我在哪里改变这个？ 我直接从 Visual Studio 到 Azure 执行 MSDEPLOY。

据我所知，您无法从 MSDEPLOY 更改App_Offline的大小写，您现在需要自定义脚本解决方案。 您可以使用我在上面发布的 powershell 脚本作为起点。

为了更新大家，我们确认了上面的理论是正确的：区分大小写错误是 ANCM 较新版本中的回归，并且该版本在 12 月部署到 Azure App Service，导致用户突然遇到此问题。

该计划是从 ASP.NET Core 团队获取 ANCM 修复并将其部署到应用服务。 目前还没有预计到达时间，但应该在一月份的某个时候发生。

谢谢！

@davidebbo我们是否能够下载 ANCM 以使用 iis 安装在我们自己的服务器上并遇到这个特定的错误？

@Pictuel我会这么认为。 请注意，我在这里的角度严格来说是 Azure 应用服务，所以我会让核心团队评论非 Azure 场景。

感谢您的提醒:)

@Pictuel是的，我们将确保发布适用于 .NET Core 的 Windows 托管安装程序的更新版本，其中包含对 ANCM 的更新。

@shirhatti

@shirhatti我在这里监视更新的安装程序何时可用于更新文档链接。

在经历了那个线程之后，我不太确定应用服务的解决方法到底是什么。 是应用程序设置还是使用自定义部署脚本或停止和启动站点？

如果是应用程序设置，我读过另一条评论，说它会导致网站无法获取新的 DLL。

如果我理解正确，在 ANCM (https://github.com/aspnet/AspNetCoreModule/issues/50) 上提供更新之前，我们方面没有解决方法。 应用服务应由 azure 团队更新。

我认为您对应用服务的最佳选择是按照@dtmnash here的描述停止/启动应用程序。

@davidebbo “计划是从 ASP.NET Core 团队获得 ANCM 修复并将其部署到应用服务。目前还没有预计到达时间，但它应该在一月份的某个时间发生。” -- 让我们知道 ETA 何时准备就绪 :)

暂定部署预计到达时间在 24 日至 30 日之间。 部署在许多规模单位上逐渐发生，因此并非每个人都会同时得到修复。

谢谢，对我来说它刚刚开始工作:-)

对我来说仍然是一个问题:(

@hbunjes感谢您的确认！

@rsnj它在一段时间内逐渐发生。 这一切都应该在月底之前完成（除非我们遇到问题）。

@davidebbo部署似乎适用于我的一些应用程序，但不是全部。 奇怪的是，有些部署会失败，但其他部署不会针对在同一应用服务计划中运行的应用。 是否可以查看特定 Web 应用程序正在运行的 ANCM 版本？

@henningst有关检查的方法，请参见https://github.com/aspnet/AspNetCoreModule/issues/50#issuecomment -271381892。

昨天不是为我工作，但现在是。 谢谢@davidebbo！

它也开始为我工作。 谢谢！

是的，部署现已完成，因此它应该适用于所有人。

这里也对我有好处。

似乎现在正在工作。 从报告来看，花了一年多的时间来解决这个问题。 我会虽然部署问题得到更高的优先级：p

如何为非 Azure 解决此问题？

@pekkah我认为它经历了不同的问题。 最新的一个比一年近得多。

@jdshkolnik对于非 Azure，我想您只需要开始使用新的 ANCM。

@jdshkolnik
该更新可在https://www.microsoft.com/net/download/core#/runtime下载
这是下载的直接链接。

@shirhatti我安装了这个，但仍然收到这些错误。

我仍然在巴西南部的圣保罗遇到错误。

@jdshkolnik当您在 PowerShell 中运行它时，您会看到什么版本？

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

@shirhatti 7.1.1971.0

更新：对不起，这是我的错。 我正在审查和更新现有版本的部署步骤，而不是版本定义。 我已经记不清我做了多少次了……

每次尝试部署时，我仍然会遇到此错误，即使我的 aspnetcore.dll 版本是应该已修复的版本。

aspnetcore.dll 版本：7.1.1971.0
部署使用：VSTS 任务 Azure App Service Deploy v3.*（预览版）
使应用程序脱机：选中
删除目的地的附加文件：选中
重命名锁定的文件：选中
MSDEPLOY_RENAME_LOCKED_FILES 应用设置：未添加

在这个阶段，我不清楚什么设置是或不需要这个工作。

现在我的第一个文件在使用中再次出现在 azure app services 上：

2017-02-14T22:41:10.4400186ZC:\Program Files (x86)\IIS\Microsoft Web Deploy V3\msdeploy.exe -来源：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 -enablerule:AppOffline

2017-02-14T22:41:34.3837386Z 错误代码：ERROR_FILE_IN_USE

2017-02-14T22:41:34.3837386Z 更多信息：Web Deploy 无法修改目标上的文件“Ascend.Ammo.Portal.exe”，因为它被外部进程锁定。 为了使发布操作成功，您可能需要重新启动应用程序以释放锁定，或者在下次尝试发布时为 .Net 应用程序使用 AppOffline 规则处理程序。 了解更多信息：http: //go.microsoft.com/fwlink/?LinkId=221672#ERROR_FILE_IN_USE。

2017-02-14T22:41:34.3837386Z 错误计数：1。

仅供参考：文档似乎链接到旧版本 (*.1970) 的安装程序： https ://docs.microsoft.com/en-us/aspnet/core/publishing/iis#install -the-net-core- windows-server-hosting-bundle。

另外，在运行时下载页面上似乎只有 LTS 版本有修复？

@shirhatti ~当新的托管包安装程序链接准备好时告诉我，我会把它拍到文档中（它在几个地方）。~

~ 是不是这个： https ://go.microsoft.com/fwlink/?linkid=837808 ...这不是 aka.ms 链接。~

如果 fwlink 没问题，我会设置https://github.com/aspnet/Docs/pull/2773来解决这个问题。

也发生在 Visual Studio 中，并且如选项所示 - 存在应用程序离线规则。

@davidebbo你能确认这是固定的吗？ 从很多人那里听到他们仍然在打它。 该工具的发布版本是否对此进行了任何修复，还是仍然存在托管问题？

我也试图弄清楚为什么以及何时发生。 我几乎可以肯定我已经看到该进程正在 scm 站点的进程资源管理器中运行，并且发布得很好。

我也在将我的网站更新为最新的工具，希望这个问题与旧的 project.json 工具有关。

该修复程序不久前已部署到 Azure 应用服务，我不知道有人在之后仍然看到此问题。 当然，非 Azure 主机上的用户在没有更新的情况下仍然可以看到。

对于 Azure，如果您遇到问题，请按如下方式进行测试：

• 转到 Kudu 进程资源管理器并确保您的应用程序的进程正在运行（通常是 dotnet.exe）
• 从 Kudu 命令手动创建app_offline.htm文件（例如运行touch app_offline.htm ）
• 再次检查进程资源管理器，并确保该进程不再存在。

我会再测试一些，你有没有看到一些帖子的图像，它清楚地表明文件正在使用并且它使用离线应用程序。

但我会按照你的要求进行测试。

此外，我们正在使用部署到虚拟应用程序的横向扩展 + 应用程序 - 不知道这是否会改变任何东西。

@pksorensen '手动' 将有助于隔离 WebDeploy 可能正在做的任何事情。 即，如果简单地删除app_offline.htm不会停止该过程，那么我们确实知道存在不是由 WebDeploy 引起的问题。

请注意，通常，您最终会得到一个 dotnet.exe 进程，而在您的情况下，您有一个不同的 exe 名称。 我想知道这是否与这个问题有关。

1. 转到 Kudu 进程资源管理器并确保您的应用程序的进程正在运行（通常是 dotnet.exe）
   我这样做了，但它不是 dotnet.exe 而是我们的名字编译 bin Ascend.Ammo.RegistrationTablet.exe

然后我确实触摸了 app_offline.htm，但这并没有终止进程。

因为我没有看到 dotnet.exe，所以我做错了什么吗？

我会让 dotnet / ANCM 专家对此部分发表评论。 我知道默认情况下，在部署核心 ASP.NET 应用程序时，它使用 dotnet.exe。 我认为当您使用独立部署（或其他任何名称）时，情况并非如此。 但我不知道这会如何影响 ANCM 和 app_offline.htm。

@DamianEdwards谁能对此发表最佳评论？

我使用部署槽避免了这个问题。 100% 的时间工作。 在复制文件之前停止插槽。 这将删除内存中的所有内容，因此您的副本将不会工作锁定文件。 然后启动插槽并切换到生产环境。 额外的好处是您的客户永远不会看到应用程序离线页面。 他们获得了 0 停机时间部署。

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

@DarqueWarrior插槽当然可以工作（并且由于其他原因很好用），但是这个线程中的关键是要了解为什么 app_offline 对于像@pksorensen 这样的人来说在关闭核心进程时显得无效。 我希望核心团队对此发表评论。

@davidebbo要回答您之前的问题，便携式与独立与 app_offline 行为无关。 应用程序脱机文件由 w3wp.exe（由 ASP.NET Core 模块）监控。

@DarqueWarrior感谢您的建议，但有一条评论-如果您像我们一样将多个站点部署到同一应用程序服务中的虚拟应用程序，则插槽（如果我没记错的话）适用于所有这些站点，因此您必须先部署所有站点交换。 这很麻烦。 现在，我们可以轻松地将部件（微服务）部署到各个虚拟应用程序。 因为我们可以将它们分散到单独的应用程序服务中，但是我们需要前端的负载均衡器/网关来使它们再次共享同一个域，这也比我们现在愿意做的花费更多的时间。

所以我同意你的建议是更可取的方式，它现在不适合我们。 所以仍然希望解决 File In Use 问题。

@pksorensen您是否有机会在虚拟站点中设置复制并共享其名称？ 基本上，我希望在您的站点正在运行的状态下查看它，并且在 Kudu 控制台中手动创建 app_offline.htm不会导致它关闭。

@shirhatti知道什么会导致 ANCM 不关闭进程吗？ 它尝试这样做的力度有多大？

@davidebbo这将花费我一些时间，但我会尝试解决一些问题来重新制作。

@davidebbo我创建了一个新的 ASP.NET Core 应用程序和一个新的 Azure 应用程序服务。 我正在使用 Azure 的“持续交付（预览版）”功能，但遇到了这个问题。

2017-03-30T02:54:36.5648892Z ##[错误]未能部署应用服务。
2017-03-30T02:54:36.5658893Z ##[错误]错误代​​码：ERROR_FILE_IN_USE
2017-03-30T02:54:37.1850861Z 更多信息：Web Deploy 无法修改目标上的文件“myApp.dll”，因为它被外部进程锁定。 为了使发布操作成功，您可能需要重新启动应用程序以释放锁定，或者在下次尝试发布时为 .Net 应用程序使用 AppOffline 规则处理程序。 了解更多信息：http: //go.microsoft.com/fwlink/?LinkId=221672#ERROR_FILE_IN_USE。
2017-03-30T02:54:37.1860517Z 错误计数：1。
2017-03-30T02:54:37.4179909Z ##[error]Error: C:\Program Files\IIS\Microsoft Web Deploy V3\msdeploy.exe 失败，返回码：4294967295

在 D:\home\site\wwwroot 中手动创建 app_offline.htm 确实会停止 dotnet.exe 进程。

那么这是否意味着“持续交付（预览版）”本身存在问题？

除上述内容外，我通过手动转到 VSTS 版本定义、附加部署选项、勾选“使应用程序脱机”来解决此问题。

但这提出了几个问题：
为什么“让应用离线”默认不勾选？ 这种情况是否仍然有效（例如，它是否减少了停机时间）？

如果是，那么为什么会失败？ 如果不是，那么为什么“持续交付（预览版）”不勾选？

无论哪种方式 - 似乎某处都有错误。

@Jon12345 ：此线程仅讨论 app_offline.htm 是否与核心应用程序一起正常工作。 因此，默认情况下 VSTS 可能会或可能不会这样做实际上是一个单独的讨论，应该在 VSTS 论坛上进行（可能是 https://social.msdn.microsoft.com/Forums/vstudio/en-US/家？论坛=TFService）。

在这一点上，大多数人似乎在修复后都被解除了封锁。 @pksorensen有一份关于它不起作用的报告，我们正在等待一个 repro 应用程序来查看。

我仍然在 TFS 2017 Update 1 上得到这个。

@jdshkolnik您确定它已设置为创建 appoffline.htm 文件吗？ 如果不是，则不在此问题的范围内。 请按照上述说明进行手动 appoffline.htm 测试。

@davidebbo是的，是的。 通常情况下，计划的夜间部署第一次尝试失败，需要手动重新部署尝试，这通常会成功。

仅供参考，我的公司与您的公司联合，因此我可以通过 Skype for Business 桌面共享轻松地向您展示。

@jdshkolnik请确保您进行了上面讨论的手动测试，因为这有助于排除其他所有问题。

重要提示：此问题与调查 VSTS 或其他发布工作流的任何问题无关。 它只涉及一件事：确保 appoffline.htm 正常工作。

@davidebbo只要我手动将 app_offline.htm 放入文件夹，它就会脱机。

我不知道如何更好地区分我是否完全符合这里的主题。 我所知道的是，去年它突然出现在那些正常运行的网站上，并且从那以后就经常抬头。

##[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我最好的猜测是，无论此部署脚本在做什么，都不会在发布文件之前创建 appoffline.htm。 这可能是 VSTS 配置问题或错误。 但从 ANCM 的角度来看，您所做的测试表明，在创建 appoffline 时，一切正常。

@davidebbo我不知道我所做的是一个明确的测试。 毕竟，我们得到错误后的第二次手动尝试通常是成功的。 可能阻止 app_offline.htm 的部署过程未运行。

我在 7.1.1971.0 上仍然遇到这个区分大小写的问题。 当我尝试使用 VS 进行部署时，我得到一个文件锁定错误，所以我查看了应用程序是否仍在运行，并且确实如此。 我打开 Kudu 命令行查看 wwwroot 目录和 App_Offline.htm 文件夹中有哪些文件，但进程仍在运行。 然后我输入 touch app_offline.htm 并且进程按预期停止运行。 我仔细检查了模块，我的 aspnetcore.dll 版本是 7.1.1971.0。

@alexgritton这很奇怪。 似乎暗示 ANCM 最初并未检测到该文件。 这是持续发生还是随机发生？

我今天刚刚在 Azure App Services 上创建了该应用程序，并且它已经发生了一整天，所以我会一直这么说。 您对可能导致这种情况的原因有任何其他想法吗？

并不真地。 我会让 ANCM 专家评论他们如何进行文件更改监控，以及他们是否能想到未检测到初始创建的原因。

@davidebbo我遇到了完全相同的问题。 我的团队有一个假构建，它将文件 AppBuild.htm 从构建服务器复制到目标站点作为 app_offline.htm。 然后，我们尝试使用 msdeploy 同步文件夹并通过另一个进程错误打开该文件夹。 如果我触摸该文件，请将文件从 app_offline.htm 重命名为 app_offline.htm.rename 并重新命名，或者使用文件资源管理器覆盖 app_offline.htm，然后该过程会正常停止。 为什么它不能通过我们的脚本运行，但如果我们手动执行它，这并不完全有意义。

更新：我们发现更新最后一次写入时间似乎一直触发关闭：

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

监控 app_offline.htm 文件的代码肯定有问题。

@derekgreer所以您看到的是，当您复制文件时，不会触发关机？ 我无法从 Kudu 控制台复制此内容。 例如

• 转到 Kudu 控制台
• 运行touch app_offline.htm in D:\home\site在不同的文件夹中创建一个空文件
• 运行copy app_offline.htm wwwroot 。 请注意，这会保留上次写入时间并更新创建时间（标准文件复制行为）。

结果：dotnet.exe 进程立即关闭（您可以使用 Kudu 进程资源管理器进行检查）。

这些相同的步骤对您有用吗？ 如果是这样，在您的复制场景中可能有什么不同？

实际上，我还应该补充一点，这个问题是间歇性的，我们在 Windows Server 2012 上使用 IIS 8。

今天早上我的目的是看看我是否可以在设置 Kudu 控制台之前使用 powershell 或批处理脚本重现该问题，但首先使用我的团队在周五使用的测试 Fake 构建脚本进行了测试，以创建 app_offline.htm 文件各种方式（复制现有文件，创建新文件等），它目前正在工作。 这反映了我们构建失败的模式，有时它会关闭进程而其他时候不会。 当它确实开始失败时，它似乎始终如一地这样做。 我们在周五进行了几个小时的测试，它始终不会因为一个简单的 Fake 构建而停止，除了创建一个新的 app_offline.htm 文件之外什么也没做。 我还应该补充一点，我们会定期手动创建文件并查看进程停止，因此似乎不会出现任何情况下进程在使用一段时间后不会关闭。

当我可以再次重现该问题时，我将查看使用 powershell 和/或批处理文件创建文件是否仍然反映该问题。

@davidebbo好吧，废话......我只是注意到我忘记注释掉更新上次更新时间的行，所以它确实仍然显示相同的行为。 我现在将尝试使用 powershell 和批处理文件并更新您。

@davidebbo

对困惑感到抱歉。 好的，这是我发现的：

使用具有以下内容的批处理文件似乎可靠地导致进程关闭：

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

使用等效的 bash 脚本也会可靠地导致进程关闭：

#!/bin/bash

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

使用具有以下内容的 powershell 脚本似乎永远不会导致进程关闭：

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

鉴于 Fake 和 Powershell 都在 CLR 下运行，而 DOS 复制命令、bash 和 Kudu 控制台不运行，这似乎表明与通过 CLR 创建的文件有关。

奇怪的是，我发现不同版本之间生成的文件的创建/更新时间戳没有差异。

@derekgreer哦，所以您根本没有在 Azure 应用服务上运行。 这是我在整个传奇中的角度，所以我会让 ASP.NET 人员对此进行进一步评论。

尽管物有所值，但我无法在应用服务中进行复制：

• 使用 Kudu 的 PowerShell 控制台
• 转到站点\wwwroot 文件夹
• 运行New-Item app_offline.htm -type file

@moozzyk你能帮忙调查@derekgreer的repro 外部应用程序服务吗？

更多信息：

由于通过文件资源管理器创建、复制、重命名等一直有效，我决定看看基于 .Net 的文件资源管理器应用程序是否反映了与我在 Fake 和 PowerShell 中看到的结果相同的结果。 有一个名为“Nomad”的基于 .Net 的文件浏览器，我最终下载并使用它进行了测试，结果与 Fake 和 PowerShell 一致。 创建 app_offline.htm 文件后，该过程并未停止。 然后我重命名该文件并再次将其重命名为 app_offline.htm，然后核心进程关闭。

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

我认为这种方法需要包含标志“FILE_NOTIFY_CHANGE_CREATION”。

我想知道 Fake、PowerShell 和 Nomad 通用的 .Net API 是否不会以与正常文件创建相同的方式触发这些其他标志。

@shirhatti你能确保有人调查这个潜在的 ANCM 问题吗？

@davidebbo确认。 我们正在调查它

我有一个非常相似的问题。 如果我在 Windows 资源管理器中复制 app_offline.htm 文件，则它会正确停止该过程，但如果我使用构建服务器中的 COPY app_offline.htm \server\share\siteapp_offline.htm 创建它，则它不会停止并且文件保持锁定状态.

@gulbanana我和你有同样的问题。 你已经解决了吗？ @shirhatti你的调查有什么更新吗？ 这让团队疯狂，因为 CI 管道由于文件复制失败而一直失败，而文件复制失败又是由于 dotnet.exe 没有被 app_offline.htm 关闭。

我通过使用类似echo "<html>page content</html>" > \\server\share\app_offline.htm的方法解决了这个问题。 我认为@derekgreer是正确的，该错误是关于 ANCM 仅监视某些文件创建方法，并且它抓住了这个。

@derekgreer
我现在正在研究问题。 在我的测试机器中使用您的一个重现命令，我能够重现此问题。 我使用了以下命令。 （注意：以下命令将创建空（文件大小为零）文件。

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

一件有趣的事情是，如果我在创建 app_offline.htm 文件时添加一些文件内容，则没有问题。 这可以通过简单地添加 -value "test" 参数来完成，如下所示：

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

您能否确认您是否在重现环境中看到相同的症状？
如果是这样，我认为只有在使用某种特殊方式（例如使用 new-item powershell 命令）创建空 app_offline.htm 时才会出现此问题。

@gulbanana
我无法使用 Copy 命令重现此问题。 你能解释一下你的复制品的更多细节吗？ 如果你能找到一些重现步骤，我可以在我的测试机器上重现同样的问题，那就太好了。

我可以确认它与 app_offline.htm 文件是否为空而不运行这些命令无关，因为我们的经验是将具有所需内容的文件复制到部署文件夹。 根据我的经验，如果第二个命令确实有效，我猜它可能会导致文件更改事件。 也许它会创建文件并随后用内容更新它。 无论如何，我用来创建包含或不包含内容的文件的每个与 .net 相关的进程都无法触发进程关闭。

@shirhatti 有更新吗？ 您是否能够确认您的代码应该使用“FILE_NOTIFY_CHANGE_CREATION”标志？

@derekgreer我们正在监听每个有效标志，除了更改上次访问和更改属性。
FILE_NOTIFY_VALID_MASK & ~FILE_NOTIFY_CHANGE_LAST_ACCESS & ~FILE_NOTIFY_CHANGE_ATTRIBUTES

所以是的，我们已经在听FILE_NOTIFY_CHANGE_CREATION 。

抄送：@pan-wang

@shirhatti啊，我现在明白了。 我不知道该标志涵盖了更改创建。 我很好奇，你能重现这个问题吗？

对空的 app_offline.htm 没有反应应该是固定的： https ://github.com/aspnet/IISIntegration/issues/174

@moozzyk @derekgreer感谢您的确认。 好的，我也发现这个问题与空文件内容没有直接关系。 找出根本原因后，我会更新您。

@jhkimnew我不再有确切的损坏设置，但我可以描述细节：

• IIS 在 windows server 2008 r2 上运行，使用 ANCM 托管 asp.net 核心应用程序
• 构建服务器也是2008r2，在同一个域上
• IIS 服务器使用 Windows 共享共享其网站物理目录
• 域用户（构建服务器的帐户）在构建服务器上运行 powershell 脚本
  如果此脚本使用 windows 复制命令从另一个目录中的现有文件复制到 app_offline，则托管进程不会关闭。 如果脚本改为使用“echo”（可能是 mingw 安装中的 /bin/echo，我不确定），那么托管进程会关闭。

我怀疑问题与那种远程副本更新或不更新的文件属性有关

@gulbanana为了清楚起见，您尝试使用 dos copy 命令而不是 power shell copy-item commandlet？ 我认为我没有尝试过常规的 dos 副本，但我发现我使用的任何基于 .net 的应用程序都不起作用。

除非 powershell 有别名，否则它是 dos copy

就我而言，PowerShell 副本不会关闭 dotnet.exe 进程，但作为 Out-Content 别名的 echo 确实有效。 我觉得这不太可能是 .NET 问题，但更多的是关于为什么网络副本不起作用

我调查了 aspnetcore.dll (ANCM) 更改通知中是否存在任何问题，但是当我尝试使用 powershell cmdlet 或 DOS 命令手动删除 app_offline.htm 时，我无法重现该问题。 我发现了一个未在此处讨论的缺失点。
那是关于优雅的关机。 与 HttpPlatformHandler" 不同，ANCM 支持优雅关闭，这意味着当 app_offline.htm 被放到根目录时，ANCM 会向后端进程发送 Crtrl-C/Break 信号并等待 10 秒以允许优雅关闭发生。
10 秒是默认值，用户可以通过 ANCM 配置设置的 shutdownTimeLimit 调整该值。 如果后端进程在配置的shutdownTimeLimit 内没有关闭，ANCM 应该杀死后端进程。

在检查 MSDeploy 发布与 ANCM 正常关闭的关系时，我终于找到了一个一致的重现步骤，即增加关闭时间（5 秒），并注意到 MSDeploy 默认仅重试 2 次，仅等待 2 秒，最终无法发布因为它不等待正常关机时间。

@vijayrkn
在我将 aspnetcore web 应用程序的启动和结束位置都设置了 5 秒延迟后，在将 aspnetcore web 应用程序发布到本地 IIS 服务器的第二次尝试中，我能够重现此问题中报告的相同错误。 我还附上了我在下面使用的发布配置文件。
您能解释一下为什么会发生这种情况，并就如何解决这个发布问题给出正确的指导吗？ 并请就此单独提出一个新问题，以便您的团队跟踪此问题以增强用户体验。

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

MSDeploy 尝试在删除 app_offline 后立即进行部署。 如果停止进程有延迟，则部署可能会失败。

可以使用此 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)

例如，将此属性设置为 10 将确保 msdeploy 重试 10 次，中间有 1 秒的延迟。
<RetryAttemptsForDeployment>10</RetryAttemptsForDeployment>

@vijayrkn

感谢您的信息。 添加下面的两行后，我没有看到相同的重现环境有任何问题。
<EnableMSDeployAppOffline>True</EnableMSDeployAppOffline> <RetryAttemptsForDeployment>10</RetryAttemptsForDeployment>

因此，遇到类似问题的任何人都需要使用适当的值增加 RetryAttemptsForDeployment 计数，然后重试是否可以解决问题。

注意：我添加 EnableMSDeployAppOffline 的原因是，当使用本地 IIS 服务器作为发布 aspnetcore Web 应用程序的目标时，默认情况下禁用它。 因此，如果您不确定您的环境中是否启用了该功能，您只需要添加该行，这就是为什么我在此处添加它以供您参考。

只是为了确保最初的问题不会因为最近的讨论而丢失，我的团队遇到的问题绝对不是时间问题。 我们已经测试了通过 Powershell、Fake 和名为“Nomad”的基于 .Net 的文件浏览器手动创建 app_offline.htm 文件，无论您等待多长时间，该过程都不会关闭。 通过文件资源管理器、DOS 批处理文件或 bash 脚本（即非基于 .Net 库的进程）创建文件会导致进程在 1-2 秒内关闭。

这似乎表明：

1. 问题与网络无关（所有测试均针对远程文件共享执行）
2. 这不是一个正常的关机/计时问题

事实上，创建 app_offline.htm 文件的 3 种非 .Net 方法可靠且快速地关闭了进程，并且创建文件的 3 种基于 .Net 库的方法永远不会导致我们的测试中进程关闭，这似乎是一个真正的，对我来说真的很大。

@derekgreer
即使使用“Nomad”，我也无法重现该问题。
这是我在 Windows 10 (amd64) 机器上所做的。

1. 安装 IIS
2. 安装 Visual Studio 2017
3. 创建一个 AspnetCore Web 应用程序并使用 MSDeploy 部署到本地 IIS 服务器
4. 安装 Nomad v3.2.0.2890 (http://www.nomad-net.info/downloads)
5. 向 Web 应用程序发送请求
6. 打开任务管理器并确认 dotnet.exe 进程正在运行
7. 打开 Nomad 并在 Web 应用程序的根目录中创建一个名为 app_offline.htm 的新文件
8. 查看任务管理器并验证创建 app_offline.htm 文件时 dotnet.exe 进程是否消失

你能给出确切的重现步骤，以便我可以按照重现问题吗？

除了我们的 .Net Core 应用程序实际上是在 VS 2015 中创建的标准 .Net 4.5.2 控制台应用程序这一事实之外，它引用了 ASP.Net Core 程序集，我看不出有什么区别。 该项目现在大约有一年的历史，并且由于从 .Net 框架模板项目类型引用核心模板项目类型以及对 .Net 核心的各种测试库支持的限制，当时以这种方式设置。

我们发现了几个问题： 1) 删除 app_offline.htm 文件（使用某些工具）有时只会触发被 ANCM 过滤掉的文件属性更改通知。 2) ANCM 可能无法读取 app_offline.htm，因为后者由文件复制工具保存。 3) 优雅关闭导致后端进程终止延迟。
我们将在下一个版本中解决前两个问题。 对于正常关机情况，用户需要重试。

听起来不错。 我的情况绝对不是关于正常关闭超时 - 当它停止时它会立即停止。

关于这个问题的任何更新？
尝试使用 VSTS 将 ASP.NET Core 1.1 应用程序部署到 Azure Web App 插槽时遇到问题

• 我在应用程序设置中设置了MSDEPLOY_RENAME_LOCKED_FILES=1
• 管理应用服务任务配置为使应用脱机
• 部署应用服务任务 _was_ 配置为使应用脱机，但这也不起作用

核心问题是DLL正在使用中：

@ChuckkNorris请参阅https://github.com/Microsoft/vsts-tasks/issues/1607了解最新信息。

@davidebbo感谢您的回复，大卫。 我确实看到了那个线程，这就是我发现我尝试过的许多解决方法的地方。

由于这个问题仍然存在并且错误仍然很普遍，我希望很快会有修复，而不是另一种解决方法。 毕竟这个问题已经公开了两年多了。

@ChuckkNorris虽然症状相同，但这不是同一个问题：

• 与app_offline.htm的大小写有关的原始问题，导致它被完全忽略。 这已经修复了一段时间。
• 这个新问题仅在一周左右前开始，并且发生是因为现在创建app_offline.htm时 Core 需要更长的时间才能关闭，并且默认情况下 msdeploy 不会等待足够长的时间。 解决方法是增加重试次数。

我刚刚将 VS 2017 更新到 15.3 并安装了 .NET core 2.0 SDK。 在 VS 中创建了一个简单的 MVC 应用程序——它的目标是 netcoreapp1.1。 我发布到 Azure，一切都很好。 我升级到 newcoreapp2.0，然后将所有 nuget 包升级到 2.0（Microsoft.AspNetCore、Microsoft.AspNetCore.Mvc 等）

尝试发布到 Azure（即覆盖 1.1）时，我得到了这个

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

我必须禁用 MvcViewComplication 才能让我的 2.0 应用程序通过 git 部署并防止文件使用中的问题。

https://github.com/Microsoft/vsts-tasks/issues/5259
https://github.com/Microsoft/vsts-tasks/issues/1607#issuecomment -349115532
@davidebbo ，我们可以就此问题结束吗？
尽管为 web 部署添加了重试帮助程序，但此问题仍然存在。

只是想指出一点，这也会影响 FTP 发布。

@jeremycook FTP 有点不同，因为它没有自动使用 App_Offline。 您需要手动创建该文件以关闭进程，然后您可以复制文件。

@davidebbo 很公平，但似乎如果我使用 Visual Studio 的发布功能通过 FTP 发布它应该可以正常工作。 也许我发错地方了？

@jeremycook坦率地说，我不确定 VS 在进行 FTP 部署时会做什么。 也许其他人可以发光，但它似乎更像是一个 VS 问题而不是 ASP.NET。

虽然隔离，但如果您手动创建 App_Offline.html，然后从 VS 进行 FTP 发布，测试部署是否成功会很有趣。

@vijayrkn您能否评论 FTP 部署期间的 VS 行为？

从 VS 到 App 服务的 FTP 发布不支持 App_Offline。

@vijayrkn好的，因此出于所有实际目的，我们可以说不支持通过 FTP 进行 .NET Core 部署，除非用户在部署之前明确停止该站点。 正确的？

@davidebbo - 是的，这是正确的。

使用 IIS Web 部署模板将 asp.net core 2.0 Web 应用程序从 VSTS 版本部署到 IIS 时遇到此问题。 由于文件正在使用，删除失败。 应用离线选项已启用。

@davidebbo @vijayrkn @shirhatti这有点令人沮丧。 是否有计划让 FTP/XCOPY 工作？ 是否应该打开一个新问题，专注于通过 FTP/XCOPY/ROBOCOPY/等部署老式方式？

我参加这个聚会迟到了，但这里有几点我想报告：
VS 2017 企业版
asp.net 4.6.xx
服务器是服务器 2012 R2 上的 IIS 8.5
sql server 类型的 dll 被锁定，当不同的开发人员使用 msdeploy 进行发布时，会出现错误，并且该网站现在已损坏，因为只有部分部署运行。

sql 类型的 dll 被锁定在 app bin 文件夹中，并且只有它们。
重命名 dll 文件，然后我可以发布。
sql 类型打包具有用于加载非托管 dll 的 caned 代码。
似乎应该将其更改为不锁定它们。 如果可以的话。

我看到人们谈论重新启动站点或使其脱机的方法，但我没有在 msdeploy 中找到它的设置。 我看到的 xml 不在我的文件中。

微软发布的 sql types 包中应该添加更好的指导。

在这个问题上发帖，因为它似乎与我的更直接相关。 我也关注了同一主题的以下问题，尽管它是针对 VSTS 的。 我直接从视觉工作室发布。

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

这对我来说一直是一个时断时续的问题，但最近又恢复了，在我的一个应用服务网站上，几乎所有的发布尝试都出现了这个错误。 该站点托管在“基本”级别的服务上，因此我没有在其他应用程序上使用的插槽来解决此问题。

这适用于 .net core 2 mvc 应用程序。

一个想法：作为 Web 应用程序一部分的某些文件不会在每次发布时都进行更改（例如 sql 类型）
但是 ms deploy 试图在每次部署时替换它们。
似乎应该进行某种检查以防止重新复制未更改的文件，这将使更新更小更快，并且更少需要弄乱文件锁定。
如果可以做到的话，会有多重好处。

另一件事是更好地识别锁定文件的原因以及为什么以及如何撤消它。
并将其作为标准部署管道的一部分。

@figuerres 几个月来我一直想处理这个问题。 由于影子复制，通常可以避免锁定问题，但是通过从~/bin加载这些本机 DLL，会产生锁定问题。 我有一个潜在的解决方案，但我不确定它是否是一个完全安全的解决方案： https ://stackoverflow.com/questions/47796553/is-it-safe-to-manually-copy-native-dlls-to-

我同意 NuGet 包的文档应该提供一种更好的方法，这种方法不会导致锁定问题。

@figuerres仅供参考，我已经实现了上述内容，请参阅代码的 Stack Overflow 问题。

在任务管理器中杀死 dotnet.exe

这里是什么状态？ 3年过去了，还没修好。 我必须手动转到服务器并停止网站。

3年？ 该问题于 2017 年 8 月报告。 1 喜欢哇。
2018 年 4 月 23 日星期一晚上 8:56 Oliver Janik [email protected]
写道：

这里是什么状态？ 3年过去了，还没修好。 我必须手动去
到服务器并停止网站。

—
您收到此消息是因为您订阅了此线程。
直接回复此邮件，在 GitHub 上查看
https://github.com/aspnet/Home/issues/694#issuecomment-383768450或静音
线程
https://github.com/notifications/unsubscribe-auth/AAXhfrhOTvZn2qb4kU-Y1Kg9I-IQKD9yks5trnhXgaJpZM4FJp_R
.

第一篇文章说“pekkah 于 2015 年 6 月 23 日打开了这个问题”

你说得对。 我的错。 我只看到了电子邮件链中的最后一个时间戳。
2018 年 4 月 23 日星期一晚上 9:06 Oliver Janik [email protected]
写道：

第一篇文章说“pekkah 于 2015 年 6 月 23 日发表评论”

—
您收到此消息是因为您发表了评论。

直接回复此邮件，在 GitHub 上查看
https://github.com/aspnet/Home/issues/694#issuecomment-383769982或静音
线程
https://github.com/notifications/unsubscribe-auth/AAXhfgwYG-jLjnoJF7MCMtzbbfxSZkt2ks5trnqXgaJpZM4FJp_R
.

关闭，因为这和泥土一样古老😄

@Eilon对不起，但为什么关闭？ 还是没有解决？

关闭，因为这和泥土一样古老😄

但这仍然是一个问题.. ? （即使在非天蓝色部署中）

创建了一个新问题 (#3719) 以提高可见性。