Aspnetcore: Deployment gagal karena file sedang digunakan

Saya melihat masalah serupa dengan penguncian file IIS pada Azure VM yang mencegah penyebaran WebDeploy. Solusi saya adalah mengeluarkan tiga perintah WebDeploy: hentikan AppPool, terapkan, mulai ulang AppPool. Lihat skrip saya; dan jika Anda memiliki kemampuan untuk menjalankan tiga perintah WebDeploy, Anda mungkin dapat melakukan sesuatu yang serupa dengan Azure Apps.

Mendapatkan masalah ini dalam versi beta6.

Sama disini! Itu menyebabkan Visual Studio 2015 saya benar-benar membeku - ketika menerbitkan aplikasi vNext saya (saya pikir beta6 dan beta7).

Apakah Anda menggunakan skrip yang disediakan oleh Microsoft untuk melakukan penyebaran? Jika demikian, Anda cukup menambahkan baris di PublishAspNet5Website.ps1 untuk memulai ulang aplikasi web:

Restart-AzureWebsite -Name $websiteName

Saya memiliki modifikasi skrip build saya yang diuraikan dalam posting ini: Menyelesaikan Masalah Penerapan ASP.NET 5 ke Slot Aplikasi Web Azure

@brandonmartinez , Memulai ulang situs web tidak akan membantu, karena situs web produksi akan terus menerima permintaan, yang karenanya akan mengunci kembali file. Satu-satunya cara yang dapat diandalkan, saat ini, untuk memperbarui situs web IIS dan Azure adalah dengan mematikan kumpulan aplikasi situs web, lalu memperbarui file, dan kemudian memulai ulang situs web. Cukup ikuti tautan @GuardRex untuk detail lebih lanjut.

Namun, kita tidak perlu repot dengan skrip penerapan khusus saat bekerja dalam kondisi default dengan VS2015.

Mudah-mudahan infrastruktur HttpPlatformHandler yang baru (yang tidak lagi membutuhkan AspNet.Loader.dll) akan sedikit lebih memaafkan, tetapi saya tidak menahan napas di sini. Kami mungkin akan mendapatkan .dll lain yang terkunci.

@rubenprins Itulah solusi yang saya gunakan juga, melalui alat Azure SDK di VS.

Ada perintah PS untuk melakukannya jika Anda bisa mendapatkan akses PS ke VM. https://github.com/GuardRex/net5-iis-ps-publish/blob/7623122dbfdc55a7c53c8edd2e97443e0eea22c9/net5-iis-ps-publish.ps1#L389 -L396

aspnet/vsweb-publish juga sangat menarik; namun, sepertinya itu menggunakan offline-template.html , dan saya pikir ditemukan bahwa metode itu tidak akan mencegah masalah penguncian dll ... hanya menghentikan AppPool, menyebarkan, dan memulai ulang AppPool telah menjadi stabil, pendekatan kerja.

kita tidak perlu repot dengan skrip penerapan khusus saat bekerja dalam kondisi default dengan VS2015

Satu hal yang terpikir oleh saya: Mampu menggunakan 'Publikasikan ke sistem file' dan mengaitkan skrip tepat setelah publikasi yang memiliki bit MSDeploy di dalamnya telah mengaktifkan kisah penerapan yang sangat sederhana dan berguna untuk beberapa VM. Karena skrip dieksekusi secara berurutan, skrip hanya berjalan VM-ke-VM langsung. Membuat rehat kopi yang menyenangkan. :senyum:

Saya memiliki pertanyaan di Memulai mengonfigurasi penyeimbang beban yang menghadap internet menggunakan Azure Resource Manager dengan tim Manajer Sumber Daya Azure menanyakan tentang cara memberi tahu penyeimbang beban untuk menghentikan sementara pengiriman lalu lintas ke VM saat Anda menerapkan.

Anyway... kembali ke topik yang dibahas @pekkah . Karena kami tahu perintah PS berfungsi, periksa opsi untuk menjalankannya dalam versi VSO:

Microsoft/vso-agen-tugas
Jalankan skrip dalam proses pembuatan Anda
Menjalankan skrip pra-pembuatan di Team Foundation Service (Visual Studio Online) untuk proses pembangunan Azure Continuous Deployment
Fitur Otomatisasi Build Baru di Visual Studio Online

... ya ... sesuatu seperti itu harus bekerja untuk Anda.

Masalah yang sama disini...

Masih menunggu solusi resmi

Bruno

Ini akan diselesaikan dengan https://github.com/aspnet/IISintegration/issues/81.

@moozzyk , Masalah itu hanya akan memperbaiki penyebaran melalui alat khusus seperti msdeploy. Penerapan sinkronisasi Xcopy/File masih tidak dapat dilakukan, yang juga akan memblokir/menghalangi banyak skenario CI yang hanya berfungsi dengan ASP.NET v1-4.

Masalah masih ada di ASP.NET Core 1.0 RC2 dengan Visual Studio 2015.2 MSDeploy ke IIS 8 pada Windows 2012 R2 dengan alat terbaru untuk server. Membunuh proses dotnet.exe atau mendaur ulang kumpulan aplikasi menyelesaikan masalah. Tapi itu membutuhkan akses desktop jarak jauh ke server dan bukan proses yang mulus.

@dg9ngf - ini adalah bug di web.deploy sekarang. Mereka menambahkan fungsionalitas app_offline.htm untuk Azure tetapi dinonaktifkan secara default saat Anda menerapkan secara lokal. Coba buka profil publikasi Anda (PublishProfiles->*.pubxml) dan ubah:

<EnableMSDeployAppOffline>False</EnableMSDeployAppOffline>

ke

<EnableMSDeployAppOffline>True</EnableMSDeployAppOffline>

Jika ini tidak berhasil, tanyakan @vijayrkn

Jika Anda menggunakan alat VS untuk mempublikasikan menggunakan profil msdeploy, maka properti ini secara otomatis ditambahkan ke pubxml Anda.

<EnableMSDeployAppOffline>True</EnableMSDeployAppOffline>

Di jendela keluaran Anda, Anda akan melihat perintah msdeploy yang mirip dengan ini.

"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 dalam perintah harus berhati-hati dalam menambahkan appOffline selama penerapan.

Jika konten appOffline khusus diperlukan, Anda dapat menyetel properti ini di pubxml.

<AppOfflineTemplate>Path to app offline</AppOfflineTemplate>

Properti itu _not_ ada di file .pubxml yang dibuat Visual Studio. Jadi saya menambahkannya tetapi tidak mengubah apa pun. Argumen -e nablerule:AppOffline tidak _not_ muncul di jendela keluaran.

Bisakah Anda membagikan baris perintah msdeploy yang ditampilkan di jendela keluaran?

Juga, dapatkah Anda mengonfirmasi bahwa pubxml memiliki WebPublishMethod sebagai 'MSDeploy'.
<WebPublishMethod>MSDeploy</WebPublishMethod>

Tidak, file tersebut memiliki ini sebagai gantinya: <WebPublishMethod>FileSystem</WebPublishMethod>

Berikut baris perintah dari jendela output: 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]

Saya menggunakan tugas "Azure Web App Deployment" di VSTS, seperti yang dijelaskan dalam posting blog ini: http://donovanbrown.com/post/2016/05/30/DevOps-for-ASPNET-Core-RC2

Apakah ada cara untuk menentukan <EnableMSDeployAppOffline>True</EnableMSDeployAppOffline> menggunakan metode itu?

Hai, saya memiliki masalah yang sama di Azure, saya menyelesaikannya dengan cara ini https://github.com/davidebbo/WAWSDeploy/issues/14

@dg9ngf Dalam versi skrip PowerShell saat ini, kami mendukung appOffline hanya untuk WebPublishMethod - 'MSDeploy'.

Dukungan AppOffline untuk publikasi sistem file akan tersedia pada rilis berikutnya.

@bojingo saya dalam situasi yang sama. Apakah Anda mengetahui hal ini?

@davenewza : Jika Anda mengunjungi posting blog itu lagi, solusinya ada di komentar.
http://donovanbrown.com/post/2016/05/30/DevOps-for-ASPNET-Core-RC2

Pada dasarnya Anda perlu menambahkan langkah-langkah VSTS untuk menghentikan/memulai situs. Sangat jauh dari solusi ideal (sebenarnya, cukup timpang), terutama karena saya tidak menggunakan slot penerapan, tetapi ini berfungsi dengan baik untuk lingkungan pengembangan/pengujian kami.

Ada versi ARM pratinjau baru dari tugas VSTS penyebaran aplikasi web yang berbasis msdeploy dan berjanji untuk memperbaikinya, tetapi saya tidak beruntung dengan itu karena saya membutuhkan klien untuk membuat prinsip layanan untuk berlangganan, dan itu itu merepotkan. Mungkin Anda bisa membuatnya berfungsi:
https://github.com/Microsoft/vsts-tasks/tree/master/Tasks/AzureRmWebAppDeployment

@vijayrkn Dialog Publikasikan Web di VS2015 tidak berisi opsi apa pun untuk mengatur msdeploy - hanya memberikan opsi untuk WebPublishMethod=FileSystem.

Bisakah Anda memberikan contoh .pubxml untuk WebPublishMethod=msdeploy?

@tomfanning Untuk aplikasi konsol inti ASP.NET, satu-satunya opsi publikasi yang tersedia saat ini adalah sistem file. Apakah Anda mencoba memublikasikan aplikasi konsol? Untuk aplikasi web, semua 4 opsi ini harus tersedia (penyebaran web, paket penerapan web, sistem file, dan ftp).
Contoh webdeploy pubxml - https://github.com/dotnetpublish/AspNetCoreBlogList/tree/master/src/AspNetCoreBlogList/Properties/PublishProfiles

Jika ini adalah aplikasi web dan Anda hanya melihat opsi publikasi sistem file, dapatkah Anda memeriksa xproj untuk melihat apakah itu mengimpor ini?
<Import Project="$(VSToolsPath)\DotNet.Web\Microsoft.DotNet.Web.targets" Condition="'$(VSToolsPath)' != ''" />

@bojingo Saya sudah dapat mengatur prinsip layanan, ada beberapa tutorial di internet. Saya tidak memiliki tautan di sini tetapi saya dapat mencarinya jika Anda membutuhkannya. Sekarang masalah saya adalah bahwa tugas tersebut memerlukan file parameter.xml yang tidak dihasilkan pada publikasi ASP Net Core... :(

Saya memiliki TFS 2015 di tempat dan ini tetap menjadi masalah yang sangat mengganggu.

Saya juga mengalami masalah ini ...

Solusi saya adalah menjaga slot pementasan yang saya gunakan untuk berhenti, lalu mempublikasikannya (swap otomatis berfungsi). Mulai ulang, lalu penggelaran tidak berhasil (penyebaran dengan VSTS)

Saya menggunakan gurita dengan Azure Web Apps, yang tidak menyajikan opsi untuk slot pementasan. Namun, memeriksa opsi berikut tampaknya berhasil:

• Turunkan domain aplikasi dengan aman dengan app_offline.html kosong di root.
• Hapus file di tujuan yang bukan bagian dari penerapan

Saya menggunakan Visual Studio 2015 Update 3 untuk menerbitkan situs asp.net core 1.1 / .net framework 4.5.2 ke IIS. Itu menjatuhkan App_Offline.htm yang tidak menghapus situs. Jika saya mengganti namanya di server menjadi app_offline.htm situs akan turun.

Per app_offline.htm ini harus peka huruf besar-kecil.

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

Deployer mengunggah app_offline.htm (tidak peka huruf besar/kecil)

Saya baru saja menerbitkan lagi dan melihat App_Offline.htm turun dan situs saya tidak turun dan saya mendapatkan file yang sedang digunakan kesalahan. Ketika saya mengubahnya menjadi app_offline.htm situs saya turun dan saya dapat menerbitkan tanpa kesalahan.

Saya menjadi tuan rumah di jalur UNC bersama - saya tidak tahu apakah itu membuat perbedaan.

@Tratcher - apakah Anda tahu mengapa casing App_Offline.htm akan membuat perbedaan di sini?

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

Saya dapat mengatasi masalah ini dengan menambahkan pengaturan aplikasi Azure dari

MSDEPLOY_RENAME_LOCKED_FILES = 1

... seperti yang dijelaskan di sini:
https://github.com/Microsoft/vsts-tasks/issues/1607#issuecomment -260946957

YMMV

@BenBarreth Apakah ada sesuatu yang serupa yang berlaku untuk non-Azure?

bukannya saya tahu maaf @jdshkolnik

Tampaknya mungkin ada masalah dengan MSDEPLOY_RENAME_LOCKED_FILES = 1. Ini membantu penyebaran berhasil, tetapi mungkin berarti bahwa DLL baru tidak diambil saat runtime:
https://github.com/Azure/Azure-webjobs-sdk-script/issues/569#issuecomment -264490818

Itu sepertinya bukan "perbaikan" yang tepat bagi saya. Itu hanya menyembunyikan kegagalan penerapan.

Perbaikan yang sebenarnya mungkin dapat dijelaskan dalam masalah ini:
https://github.com/Azure/Azure-webjobs-sdk-script/issues/1023

Benar-benar mencari resolusi untuk ini. Sepertinya tugas VSTS penyebaran web RM menangani ini dengan opsi "Ambil Aplikasi Offline" dipilih, tetapi pada akhir pekan ini kami terus-menerus mendapatkan kesalahan. Kami telah kembali menghentikan slot penerapan, menerapkan, dan memulai lagi.

Demikian juga dengan kami, masalah ini muncul pada hari Jumat minggu lalu dan telah menghalangi kami untuk menyebarkan sejak saat itu...

Sama disini. Sepertinya itu hanya memengaruhi situs dengan Always On = true, tapi itu tidak pasti.

Saya masih memiliki masalah ini bahkan ketika mengatur MSDEPLOY_RENAME_LOCKED_FILES = 1 dalam konfigurasi saya. Hampir tidak mungkin untuk memperbarui build di server saya sekarang. Ini baru mulai terjadi beberapa hari yang lalu.

Masalah yang sama mulai terjadi pada saya minggu ini. Hingga minggu ini menyebarkan layanan aplikasi AzureRM di VSTS dengan pengaturan Ambil Aplikasi Offline = benar secara konsisten bekerja. Sekarang pengaturan ini tampaknya diabaikan atau layanan tidak dihentikan tepat waktu. Saya harus memulai ulang secara manual atau menghentikan/memulai layanan aplikasi saat menjalankan rilis untuk itu juga melebihi.

Masalah yang sama di sini. AzureRm bekerja selama berbulan-bulan dan tiba-tiba berhenti. Penyebaran terakhir saya adalah dua minggu lalu pada 12/5 dan sekarang pada 12/20 itu menghasilkan Error_File_In_Use. Sangat kesal harus kembali ke start/stop manual.

Inilah solusi kami di Powershell yang kami gunakan untuk saat ini sebagai bagian dari proses CI/build kami. Terima kasih khusus kepada @appveyor guys untuk bantuan dengan ini:

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

Ini menggunakan Kudu REST API untuk HTTP PUT file app_offline.htm #$ dengan huruf besar yang benar. Kami telah mengonfigurasi WebDeploy untuk menghapus file apa pun yang tidak ada dalam penerapan, sehingga secara otomatis menghapus file sebagai bagian dari penerapan. Anda mungkin perlu mengulangi langkah tersebut menggunakan HTTP DELETE untuk menghapus file setelah penerapan selesai jika Anda tidak menggunakan mode ini.

Menambahkan Trackyon Stop sebelum tugas AzureRM dan tugas Trackyon Start setelahnya berfungsi dengan baik untuk saya. Ini seharusnya tidak diperlukan dengan TakeAppOffline = true tetapi berfungsi dan menghindari manual atau skrip. Cukup tambahkan tugas ke definisi rilis. Langkah-langkah Trackyon mudah diatur

Pada 21 Desember 2016, pukul 12:10, Chad T < [email protected] [email protected] > menulis:

Inilah solusi kami di Powershell yang kami gunakan untuk saat ini sebagai bagian dari proses CI/build kami. Terima kasih khusus kepada @appveyor https://github.com/appveyor guys untuk bantuan dengan ini:

$username = $ env:deployusername
$password = $ env:deploypassword
$base64AuthInfo = [Konversi]::ToBase64String([Text.Encoding]::ASCII.GetBytes(("{0}:{1}" -f $username,$password)))
$Header = @{
'Otorisasi' = ('Dasar {0}' -f $base64AuthInfo)
'Jika-Cocok' = '*'
}
$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"

Ini menggunakan Kudu REST API https://github.com/projectkudu/kudu/wiki/REST-API untuk HTTP PUT file app_offline.htm dengan casing yang benar di tempatnya. Kami telah mengonfigurasi WebDeploy untuk menghapus file apa pun yang tidak ada dalam penerapan, sehingga secara otomatis menghapus file sebagai bagian dari penerapan. Anda mungkin perlu mengulangi langkah tersebut menggunakan HTTP DELETE untuk menghapus file setelah penerapan selesai jika Anda tidak menggunakan mode ini.

-
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub https://github.com/aspnet/Home/issues/694#issuecomment-268436959 , atau nonaktifkan utasnya https://github.com/notifications/unsubscribe-auth/AID9WoUdbuBnFoXR2K5o8AiUtv8nE9dRks .

Pesan ini bersifat non-publik dan mungkin berisi informasi istimewa, hak milik, atau rahasia. Jika Anda menerimanya karena kesalahan, harap segera beri tahu pengirim dan hapus semua salinan aslinya. Penggunaan email lainnya oleh Anda dilarang. Penyalinan, penyimpanan, penggunaan, atau pengungkapan isi pesan ini tidak diizinkan dan mungkin melanggar hukum. Jika diizinkan oleh hukum setempat, komunikasi elektronik dengan Lithero, dapat dipantau dan dipindai oleh sistem kami untuk tujuan keamanan informasi dan penilaian kepatuhan internal terhadap kebijakan Lithero dan hukum yang berlaku.

/ cc @davidebbo

Coba atur MSDEPLOY_RENAME_LOCKED_FILES=1 di Pengaturan Aplikasi Azure untuk aplikasi Anda.

@davidebbo ini sepertinya tidak menyelesaikan masalah.

Saya berasumsi ini terkait dengan perubahan di sisi pagar Azure? Banyak orang (terutama di saluran slack aspnet) memiliki masalah ini semua muncul pada waktu yang sama.

Perubahan di Azure tidak akan menjelaskan mengapa kami melihat ini di tempat dengan TFS. Mungkinkah itu agen?

Kami melihat masalah yang sama. App_Offline.htm tidak diambil. Cukup aneh jika kami menyebarkan dari VS itu berfungsi dengan baik.

Cukup aneh, bagi saya itu tidak berfungsi dari VS, seperti yang dijelaskan di sini: #1883

Tim saya juga mengalami masalah ini, hampir setiap kali penerapan gagal karena file terkunci. Perlu memulai ulang setiap aplikasi di Azure dan menjalankan kembali penerapan. Kami menggunakan Octopus Deploy.

Tim saya mengalami masalah ini pagi ini. Ada komentar dari tim Microsoft? Pipa rilis sangat penting untuk produktivitas kami, ini mencegah rilis ke lokasi produksi. Terima kasih!

@bmoscao - app_offline.html peka huruf besar/kecil.

Masalah ini juga muncul untuk saya di Azure. Tidak ada yang saya lakukan di akhir saya untuk menyebabkan itu.

Saya mengalami masalah ini juga. Masalahnya adalah EnableMSDeployAppOffline diatur ke true - dan keluaran proyek menunjukkan -enablerule:AppOffline sebagai bagian dari perintah yang dijalankan oleh visual studio. Saya tidak yakin apa yang harus dilakukan ... Saya baru saja mulai mendapatkan masalah ini baru-baru ini ..

Solusi kami untuk ini adalah menghentikan kumpulan aplikasi, menerapkan, lalu memulai ulang kumpulan aplikasi. Kami menggunakan Release Manager dan plugin powershell inline untuk mencapai ini.

Berhenti:

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

Awal:

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

Pasti akan menghargai beberapa masukan dari Microsoft, ini dulu bekerja dengan baik hanya dengan mengaktifkan aturan appOffline pada langkah penyebaran RM Azure.

@davidebbo Kami menggunakan ASP.NET Core, VSTS Release Manager, dan AzureRmWebApp dengan slot.

@davidebo terima kasih! Ini bekerja untuk saya;)

Terjadi pada kami juga - msdeploy ke Azure. Senang melihat itu dimulai secara misterius untuk sejumlah orang pada saat yang sama - dan itu bukan hanya kami - tetapi tidak terlalu meyakinkan secara keseluruhan!

Saya tidak berpikir orang-orang di MS memerlukan konfirmasi untuk ini, mungkin mereka tahu betul apa masalahnya. Bagaimanapun, sama di sini. Menyebarkan dari VSTS, berhenti bekerja pada awal Desember. Saat ini saya menggunakan tugas trackyon untuk menghentikan/memulai.

Melalui utas ini, untuk setiap entri, tidak selalu jelas:

1. apakah masalah mengacu pada Layanan Aplikasi Azure atau hosting lainnya
2. apakah orang telah mencoba mengubah casing app_offline seperti yang dibahas di atas. Tampaknya beberapa orang melaporkan keberhasilan di sana.
3. apakah MSDEPLOY_RENAME_LOCKED_FILES telah dicoba. Sekali lagi, beberapa orang tampaknya telah berhasil dengan itu.

Jika Anda mengalami masalah ini, harap jelaskan secara eksplisit apa skenario Anda dan apa yang telah Anda coba, sehingga kami dapat memahaminya. Terima kasih!

@davidebo

Saya menerima pesan ERROR_FILE_IN_USE ketika saya mencoba untuk menggunakan menggunakan Visual Studio/MSBuild. Tugasnya adalah membuat file App_Offline.htm di server tetapi tidak menghapus aplikasi.

Membuat file app_offline.htm menggunakan Web Deploy akan menghapus aplikasi.

Ini adalah pengaturan saya:

• Server: IIS 8, .NET Core Windows Server Hosting 1.1.0, dan Web Deploy 3.6
• Mesin saya: Visual Studio 2015 Update 3 dan .NET Core 1.0.1 Tools Preview 2
• Publikasikan profil:

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

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

@davidebo

Saya telah mengomentari kesalahan ini di utas serupa dan harus menghentikan dan memulai ulang aplikasi web Azure saya setiap kali saya ingin memindahkan (hanya di lingkungan pengembangan). Tidak pernah melakukan ini sebelum minggu ini. Saya memutuskan untuk membuat aplikasi web inti Visual Studio 2015 .net dari template tanpa modifikasi apa pun.

Saya menjalankan aplikasi web di Host lokal tidak ada masalah sama sekali.
Saya menerbitkan aplikasi baru ke Paket Layanan Aplikasi Web Azure saya tanpa masalah dan browser segera membuka situs tanpa masalah.
Saya memeriksa Azure Dashboard dan tidak ada masalah sama sekali.

Saya kemudian pergi dan menerbitkan ulang aplikasi web tanpa mengubah apa pun - kode atau pengaturan dan kesalahan berikut muncul dengan sendirinya.

Sejak saat itu saya harus menghentikan aplikasi web, mempublikasikan ke Azure dan kemudian memulai aplikasi web. Ini tidak pernah terjadi pada saya sebelumnya. Ini adalah penerapan template Microsoft yang sangat sederhana.

Saya merekam seluruh proses ini dan mengirimkan umpan balik itu dalam sistem umpan balik Microsoft 2015 VS. Semoga Anda dapat menemukan rekaman itu. Atau aku mungkin bisa melakukannya lagi.

Salam Peter

@davidebo

apakah masalah mengacu pada Layanan Aplikasi Azure atau hosting lainnya

Layanan Aplikasi Azure.

apakah orang telah mencoba mengubah casing app_offline seperti yang dibahas di atas. Tampaknya beberapa orang melaporkan keberhasilan di sana.

Mengubah App_Offline ke app_offline memperbaiki masalah - file ini dibuat melalui webdeploy secara otomatis dengan casing 'App_Offline' sebagai bagian dari penerapan, yang merupakan inti masalahnya.

@davidebo
Persis sama dengan @ctolkien.

@davidebo

apakah masalah mengacu pada Layanan Aplikasi Azure atau hosting lainnya

Dalam kasus saya, saya menggunakan Layanan Aplikasi Azure. Tidak tahu tentang hosting lain.

apakah orang telah mencoba mengubah casing app_offline seperti yang dibahas di atas. Tampaknya beberapa orang melaporkan keberhasilan di sana.

Saya menggunakan tugas "Menyebarkan Aplikasi Web AzureRM" dari VSTS (https://aka.ms/azurermwebdeployreadme). Ada opsi "Terbitkan menggunakan Web Deploy" <- dicentang dan "Ambil Aplikasi Offline" <- centang mana yang dulu berfungsi, hingga sesuatu berubah di suatu tempat dan berhenti berfungsi.
Tooltip "info" secara eksplisit memberi tahu tentang menempatkan "app_offline.htm" dengan huruf kecil "a".
Saya tidak yakin bagaimana mengubahnya menggunakan skrip ini, seharusnya huruf kecil.

apakah MSDEPLOY_RENAME_LOCKED_FILES telah dicoba. Sekali lagi, beberapa orang tampaknya telah berhasil dengan itu.

Tidak dicoba. Tidak tahu bagaimana melakukannya. Tetapi bagaimanapun juga, saya lebih suka membuat aplikasi offline daripada mengubah konten file yang terkunci.

Terima kasih semuanya. Jadi kedengarannya jelas bahwa masalah utamanya adalah dengan casing app_offline.htm , dan bukan apa pun yang terkait dengan Layanan Aplikasi Azure (dari sisi mana saya berasal). Dan ini dilacak oleh https://github.com/aspnet/AspNetCoreModule/issues/50.

Saya sarankan untuk menutup masalah ini dan menyimpan yang lain. Saya akan membiarkan para ahli ASP.NET mengambilnya dari sana, kecuali ada alasan untuk berpikir bahwa Aplikasi Web Azure sebagian yang harus disalahkan (tidak mungkin berdasarkan @fabiano melaporkan hal yang sama di luar Azure).

Sebenarnya ini terlihat seperti regresi dalam perkakas di mana tampaknya sudah mulai membuat App_Offline.html alih-alih app_offline.html. @mlorbetske , @vijayrkn - tahu apa itu?

Saya mengerti, jadi Anda mengatakan bahwa runtime inti (AspNetCoreModule) selalu peka huruf besar/kecil, tetapi itu tidak menjadi masalah karena VS menggunakan huruf besar/kecil yang cocok dan sekarang tidak?

Meskipun terlepas dari itu, saya berpendapat bahwa runtime tidak boleh peka huruf besar-kecil di sini, jadi ada dua kemungkinan jalur ke depan untuk mengatasi masalah ini.

@davidebbo - ini benar. Saya percaya AspNetCoreModule selalu peka huruf besar-kecil.

@davidebo

dan bukan apa pun yang terkait dengan Layanan Aplikasi Azure (dari mana saya berasal)

Saya kira alasan membawa Azure AppService ke diskusi adalah karena tanpa perubahan apa pun atas nama kami, semuanya mulai gagal, kami tidak mengubah versi paket kami. Apakah revisi ANCM direvisi pada Layanan Aplikasi?

@ctolkien ya, saya pikir itu memang diperbarui. Jadi bisa jadi kesimpulan di atas tidak tepat. Sebaliknya teori baru adalah:

• ANCM yang lebih lama (7.1.1965.0) tidak peka huruf besar-kecil.
• Yang lebih baru (7.1.1970.0) menjadi peka huruf besar/kecil.
• Tidak ada yang berubah di sisi penerbitan VS, dan casingnya selalu App_Offline.htm .

@moozzyk menurut Anda itu kemungkinan, atau apakah Anda yakin itu selalu peka huruf besar-kecil?

@moozzyk @davidebbo - Tidak ada perubahan pada alat VS untuk casing app_offline. Alat VS memanggil msdeploy dengan aturan appoffline (-enablerule:AppOffline) dan msdeploy menjatuhkan App_Offline.htm.

Masalah ini terlihat seperti perubahan perilaku di ANCM. Berdasarkan komentar pertama di sini app_offline harus peka terhadap huruf besar-kecil (https://github.com/aspnet/IISintegration/issues/81).

@ctolkien

Mengubah App_Offline ke app_offline memperbaiki masalah

Di mana saya mengubah ini? Saya melakukan MSDEPLOY langsung dari Visual Studio ke Azure.

@oyvindvol

Di mana saya mengubah ini? Saya melakukan MSDEPLOY langsung dari Visual Studio ke Azure.

Anda tidak dapat mengubah casing App_Offline dari MSDEPLOY sejauh yang saya tahu, Anda harus membuat skrip khusus sebagai solusi untuk saat ini. Anda dapat menggunakan skrip PowerShell yang saya posting di atas sebagai titik awal.

Untuk memperbarui semua orang, kami mengonfirmasi bahwa teori di atas benar: bug sensitivitas huruf besar-kecil adalah regresi dalam versi ANCM yang lebih baru, dan versi itu disebarkan ke Azure App Service pada bulan Desember, menyebabkan pengguna tiba-tiba terkena ini.

Rencananya adalah untuk mendapatkan perbaikan ANCM dari tim ASP.NET Core dan menyebarkannya ke App Service. Belum ada ETA, tetapi itu akan terjadi sekitar bulan Januari.

Terima kasih!

@davidebbo akankah kami dapat mengunduh ANCM untuk dipasang di server kami sendiri menggunakan iis dan mengenai bug khusus ini juga?

@Pictuel saya akan berpikir begitu. Perhatikan bahwa sudut pandang saya di sini adalah Layanan Aplikasi Azure, jadi saya akan membiarkan tim Inti mengomentari skenario non-Azure.

terimakasih atas peringatannya :)

@Pictuel ya kami akan memastikan bahwa versi terbaru dari penginstal hosting Windows untuk .NET Core akan dirilis yang berisi pembaruan ke ANCM.

@shirhatti

@shirhatti Saya memantau di sini ketika penginstal yang diperbarui tersedia untuk memperbarui tautan dokumen.

Setelah melalui utas itu, saya tidak begitu yakin apa solusi sebenarnya untuk Layanan Aplikasi. Apakah Pengaturan Aplikasi atau menggunakan skrip penerapan khusus atau menghentikan dan memulai situs?

Jika itu adalah pengaturan aplikasi, saya telah membaca komentar lain yang mengatakan itu menyebabkan situs web tidak mengambil DLL baru.

Jika saya mengerti dengan benar, tidak ada solusi di pihak kami sampai pembaruan tersedia di ANCM (https://github.com/aspnet/AspNetCoreModule/issues/50). Layanan aplikasi harus diperbarui oleh tim Azure.

Saya pikir Anda sebaiknya bertaruh pada Layanan Aplikasi adalah menghentikan/memulai aplikasi seperti yang dijelaskan oleh @dtmnash di sini .

@davidebbo "Rencananya adalah untuk mendapatkan perbaikan ANCM dari tim Inti ASP.NET dan menyebarkannya ke Layanan Aplikasi. Belum ada ETA, tetapi itu akan terjadi sekitar bulan Januari." -- Beri tahu kami jika ETA sudah siap untuk hal ini :)

ETA penerapan tentatif adalah antara tanggal 24 dan 30. Deployment terjadi secara bertahap pada banyak unit skala, jadi tidak semua orang akan mendapatkan perbaikan pada waktu yang sama.

Terima kasih, bagi saya itu baru mulai bekerja :-)

Masih menjadi masalah bagi saya :(

@hbunjes terima kasih telah mengonfirmasi!

@rsnj itu terjadi secara progresif selama beberapa periode waktu. Itu semua harus dilakukan pada akhir bulan (kecuali kami menemukan masalah).

@davidebbo Deployment tampaknya berfungsi untuk beberapa aplikasi saya tetapi tidak semua. Yang aneh adalah beberapa penerapan gagal tetapi yang lain tidak untuk aplikasi yang berjalan dalam Paket Layanan Aplikasi yang sama. Apakah mungkin untuk melihat versi ANCM apa yang berjalan untuk aplikasi web tertentu?

@henningst Lihat https://github.com/aspnet/AspNetCoreModule/issues/50#issuecomment -271381892 untuk cara memeriksa.

Tidak bekerja untuk saya kemarin tapi sekarang. Terima kasih @davidebo!

Itu mulai bekerja untuk saya juga. Terima kasih!

Ya, penerapan sekarang sudah selesai, jadi itu akan berfungsi untuk semua orang.

Semua baik untuk saya di sini juga.

Kelihatannya sekarang dapat berfungsi. Dari laporan, butuh lebih dari satu tahun untuk memperbaikinya. Saya akan menganggap masalah penyebaran mendapatkan prioritas yang lebih tinggi :p

Bagaimana cara memperbaikinya untuk non-Azure?

@pekkah saya pikir itu mengalami masalah yang berbeda. Yang terbaru jauh lebih baru dari satu tahun.

@jdshkolnik untuk non-Azure, saya kira Anda hanya perlu mulai menggunakan ANCM baru.

@jdshkolnik
Pembaruan telah tersedia untuk diunduh di https://www.microsoft.com/net/download/core#/runtime
Ini adalah tautan langsung ke unduhan.

@shirhatti Saya menginstal ini namun saya masih mendapatkan kesalahan ini.

Saya masih mendapatkan kesalahan di Sao Paulo, Brasil Selatan.

@jdshkolnik Versi apa yang Anda lihat saat menjalankan ini di PowerShell?

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

@shirhatti 7.1.1971.0

Pembaruan : maaf, ini salah saya. Saya meninjau dan memperbarui langkah-langkah penyebaran Rilis yang ada daripada definisi rilis. Aku sudah lupa berapa kali aku melakukan ini...

Saya masih menemukan kesalahan ini setiap kali saya mencoba untuk menyebarkan meskipun versi aspnetcore.dll saya adalah yang seharusnya diperbaiki.

versi aspnetcore.dll : 7.1.1971.0
Dikerahkan menggunakan : tugas VSTS Azure App Service Deploy v3.* (pratinjau)
Ambil Aplikasi Offline : Dicentang
Hapus file tambahan di tujuan : Dicentang
Ganti nama file yang dikunci : Dicentang
Pengaturan aplikasi MSDEPLOY_RENAME_LOCKED_FILES : Tidak ditambahkan

Pada tahap ini tidak jelas bagi saya pengaturan apa yang diperlukan atau tidak agar ini berfungsi.

Baru saja file pertama saya digunakan lagi sekarang di layanan aplikasi 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' - tujuan: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 Kode Kesalahan: ERROR_FILE_IN_USE

2017-02-14T22:41:34.3837386Z Informasi Selengkapnya: Web Deploy tidak dapat mengubah file 'Ascend.Ammo.Portal.exe' di tujuan karena dikunci oleh proses eksternal. Agar operasi publikasi berhasil, Anda mungkin perlu memulai ulang aplikasi untuk melepaskan kunci, atau menggunakan pengendali aturan AppOffline untuk aplikasi .Net pada upaya publikasi berikutnya. Pelajari lebih lanjut di: http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_FILE_IN_USE.

2017-02-14T22:41:34.3837386Z Hitungan kesalahan: 1.

FYI: dokumen tampaknya menautkan ke penginstal dengan versi lama (*.1970): https://docs.microsoft.com/en-us/aspnet/core/publishing/iis#install -the-net-core- paket-windows-server-hosting.

Juga, sepertinya di halaman unduhan runtime hanya versi LTS yang diperbaiki?

@shirhatti ~Beri tahu saya ketika tautan penginstal bundel hosting baru sudah siap, dan saya akan memasukkannya ke dalam dokumen (ada di beberapa tempat).~

~Yang ini: https://go.microsoft.com/fwlink/?linkid=837808 ... itu bukan link aka.ms lho~

Saya menyiapkan https://github.com/aspnet/Docs/pull/2773 untuk membahas ini jika fwlink ok.

Juga terjadi di studio visual, dan seperti yang ditunjukkan opsi - aturan offline aplikasi hadir.

@davidebbo, bisakah Anda mengonfirmasi apakah ini sudah diperbaiki? Mendengar dari cukup banyak orang bahwa mereka masih memukulnya. Apakah versi rilis alat memiliki perbaikan untuk ini atau masih masalah hosting?

Saya juga mencoba mencari tahu mengapa dan kapan itu terjadi. Saya hampir yakin saya telah melihat bahwa proses sedang berjalan dalam proses explorer di situs scm dan itu diterbitkan dengan baik.

Saya juga sedang dalam proses memperbarui situs saya ke perkakas terbaru, berharap masalah ini terkait dengan perkakas project.json lama.

Perbaikan telah diterapkan ke Layanan Aplikasi Azure beberapa waktu lalu, dan saya tidak mengetahui ada orang yang masih melihat masalah setelahnya. Tentu saja, pengguna di host non-Azure masih dapat melihatnya jika belum diperbarui.

Untuk Azure, jika Anda mengalami masalah, silakan uji sebagai berikut:

• Buka penjelajah proses Kudu dan pastikan proses aplikasi Anda berjalan (biasanya dotnet.exe)
• Buat file app_offline.htm secara manual (mis. jalankan touch app_offline.htm ) dari perintah Kudu
• Periksa lagi process explorer, dan pastikan proses itu sudah tidak ada lagi.

Saya akan menguji lagi, apakah Anda melihat gambar beberapa posting, itu jelas menunjukkan bahwa file sedang digunakan dan menggunakan aplikasi offline.

Tapi saya akan menguji seperti yang Anda minta.

Selain itu, kami menggunakan aplikasi scaleout + yang dikerahkan ke aplikasi virtual - tidak tahu apakah itu mengubah apa pun.

@pksorensen melakukannya 'secara manual' akan membantu mengisolasi dari apa pun yang mungkin dilakukan WebDeploy. yaitu jika hanya menjatuhkan app_offline.htm tidak menghentikan proses, maka kami benar-benar tahu ada masalah yang tidak disebabkan oleh WebDeploy.

Perhatikan bahwa biasanya, Anda berakhir dengan proses dotnet.exe, sementara dalam kasus Anda, Anda memiliki nama exe yang berbeda. Aku ingin tahu apakah itu entah bagaimana berhubungan dengan masalah ini.

1. Buka penjelajah proses Kudu dan pastikan proses aplikasi Anda berjalan (biasanya dotnet.exe)
   Saya melakukan ini, tetapi ini bukan dotnet.exe tetapi nama kami dikompilasi bin Ascend.Ammo.RegistrationTablet.exe

Kemudian saya menyentuh app_offline.htm, tetapi ini tidak mematikan prosesnya.

Apakah saya melakukan sesuatu yang salah karena saya tidak melihat dotnet.exe?

Saya akan membiarkan pakar dotnet / ANCM mengomentari bagian itu. Saya tahu secara default, ketika menggunakan aplikasi inti ASP.NET, ia menggunakan dotnet.exe. Saya pikir kasusnya ketika tidak adalah ketika Anda menggunakan penerapan mandiri (atau apa pun namanya). Tapi saya tidak tahu bagaimana hal itu memengaruhi ANCM dan app_offline.htm.

@DamianEdwards siapa yang bisa mengomentari ini?

Saya menghindari masalah itu menggunakan slot penyebaran. Bekerja 100% dari waktu. Hentikan slot sebelum Anda menyalin file. Ini akan menghapus semuanya dari memori sehingga salinan Anda tidak akan berfungsi dengan file yang terkunci. Kemudian mulai slot dan tukar ke produksi. Manfaat tambahan, pelanggan Anda tidak pernah melihat halaman offline aplikasi. Mereka mendapatkan penerapan 0 downtime.

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

Slot @DarqueWarrior berfungsi tentu saja (dan bagus untuk digunakan karena alasan lain), tetapi hal utama dalam utas ini adalah memahami mengapa app_offline tampak tidak efektif dalam mematikan proses Inti untuk beberapa orang seperti @pksorensen. Dan saya ingin tim Inti mengomentari itu.

@davidebbo Untuk menjawab pertanyaan Anda sebelumnya, portabel vs mandiri tidak ada hubungannya dengan perilaku app_offline. File offline aplikasi dipantau oleh w3wp.exe (oleh modul ASP.NET Core).

@DarqueWarrior Terima kasih atas sarannya, satu komentar - jika Anda seperti kami menyebarkan situs berlipat ganda ke aplikasi virtual di layanan aplikasi yang sama, slot (jika saya ingat benar) berfungsi di semua itu, jadi Anda harus menggunakan semua situs sebelumnya bertukar. Ini merepotkan. Saat ini kami dapat menyebarkan bagian (layanan mikro) ke aplikasi virtual individu dengan mudah. Tentu saja kita dapat menyebarkannya ke layanan aplikasi terpisah, tetapi kemudian kita akan membutuhkan loadbalancer/gateway di depan untuk membuat mereka berbagi domain yang sama lagi, juga menghabiskan lebih banyak waktu daripada yang ingin kita lakukan sekarang.

Jadi saya setuju bahwa apa yang Anda sarankan adalah cara yang lebih disukai, itu tidak cocok dengan kami saat ini. Jadi masih berharap untuk resolusi pada masalah File In Use.

@pksorensen apakah ada kemungkinan Anda dapat mengatur repro di situs dummy dan membagikan namanya? Pada dasarnya, saya ingin melihatnya dalam keadaan situs Anda berjalan, dan membuat app_offline.htm secara manual di konsol Kudu tidak menyebabkannya dimatikan.

@shirhatti tahu apa yang bisa menyebabkan ANCM tidak mematikan prosesnya? Seberapa agresif ia mencoba melakukan itu?

@davidebbo Ini akan memakan sedikit waktu, tetapi saya akan mencoba melakukan sesuatu untuk membuat repro.

@davidebbo Saya membuat aplikasi ASP.NET Core baru, dan Layanan Aplikasi Azure baru. Saya menggunakan fitur "Pengiriman Berkelanjutan (Pratinjau)" Azure, dan saya mendapatkan masalah ini.

2017-03-30T02:54:36.5648892Z ##[error]Gagal menerapkan Layanan Aplikasi.
30-03-2017T02:54:36.5658893Z ##[error]Kode Kesalahan: ERROR_FILE_IN_USE
2017-03-30T02:54:37.1850861Z Informasi Lebih Lanjut: Web Deploy tidak dapat mengubah file 'myApp.dll' di tujuan karena dikunci oleh proses eksternal. Agar operasi publikasi berhasil, Anda mungkin perlu memulai ulang aplikasi untuk melepaskan kunci, atau menggunakan pengendali aturan AppOffline untuk aplikasi .Net pada upaya publikasi berikutnya. Pelajari lebih lanjut di: http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_FILE_IN_USE.
2017-03-30T02:54:37.1860517Z Hitungan kesalahan: 1.
2017-03-30T02:54:37.4179909Z ##[error]Error: C:\Program Files\IIS\Microsoft Web Deploy V3\msdeploy.exe gagal dengan kode pengembalian: 4294967295

Membuat app_offline.htm secara manual di D:\home\site\wwwroot memang menghentikan proses dotnet.exe.

Jadi apakah ini berarti ada masalah dengan "Pengiriman Berkelanjutan (Pratinjau)" itu sendiri?

Lebih lanjut di atas, saya memperbaikinya dengan secara manual membuka Definisi Rilis VSTS, Opsi Penerapan Tambahan, mencentang "Ambil Aplikasi Offline".

Tapi ini menimbulkan beberapa pertanyaan:
Mengapa "Ambil Aplikasi Offline" tidak dicentang secara default? Apakah skenario ini masih berfungsi (misalnya apakah ini mengurangi waktu henti)?

Jika ya, lalu mengapa gagal? Jika tidak, lalu mengapa "Pengiriman Berkelanjutan (Pratinjau)" membiarkannya tidak dicentang?

Either way - sepertinya ada bug di suatu tempat.

@ Jon12345 : utas ini hanya membahas apakah app_offline.htm berfungsi dengan benar dengan aplikasi Inti. Jadi fakta bahwa VSTS mungkin atau mungkin tidak melakukan ini secara default benar-benar merupakan diskusi terpisah, yang harus dilakukan di forum VSTS (mungkin https://social.msdn.microsoft.com/Forums/vstudio/en-US/ rumah?forum=TFService).

Pada titik ini, kebanyakan orang tampaknya telah diblokir setelah perbaikan. Ada satu laporan yang tidak berfungsi oleh @pksorensen , dan kami sedang menunggu aplikasi repro untuk dilihat.

Saya masih mendapatkan ini di TFS 2017 Pembaruan 1.

@jdshkolnik Apakah Anda yakin sudah menyiapkan file appoffline.htm? Jika tidak, itu di luar cakupan masalah ini. Silakan lakukan tes appoffline.htm manual seperti yang diuraikan di atas.

@davidebbo Ya, benar. Sering kali penerapan malam yang dijadwalkan gagal pada upaya pertamanya dan memerlukan upaya penerapan ulang manual yang biasanya berhasil.

FYI, perusahaan saya tergabung dengan perusahaan Anda sehingga saya dapat dengan mudah menunjukkan kepada Anda melalui berbagi desktop Skype for Business.

@jdshkolnik pastikan Anda melakukan tes manual yang dibahas di atas, karena ini membantu mengeluarkan yang lainnya dari persamaan.

Penting : Masalah ini bukan tentang menyelidiki masalah apa pun dengan VSTS atau alur kerja penerbitan lainnya. Ini hanya tentang satu hal: memastikan appoffline.htm berfungsi.

@davidebbo Ini offline segera setelah saya secara manual menempatkan app_offline.htm ke dalam folder.

Saya tidak tahu bagaimana membedakan dengan lebih baik apakah saya sesuai dengan topik di sini. Yang saya tahu adalah bahwa itu tiba-tiba muncul tahun lalu untuk situs yang bekerja tanpa masalah dan secara teratur mengangkat kepalanya sejak itu.

##[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 Tebakan terbaik saya adalah bahwa apa pun yang dilakukan skrip penerapan ini tidak membuat appoffline.htm sebelum menerbitkan file. Ini bisa menjadi masalah atau bug konfigurasi VSTS. Tetapi dari sudut pandang ANCM, pengujian yang Anda lakukan menunjukkan bahwa segala sesuatunya berfungsi seperti yang diharapkan ketika appoffline dibuat.

@davidebbo Saya tidak tahu bahwa apa yang saya lakukan adalah tes definitif. Lagi pula, upaya manual kedua setelah kami mendapatkan kesalahan biasanya berhasil. Proses penerapan yang mungkin memblokir app_offline.htm tidak berjalan.

Saya masih mengalami masalah peka huruf besar/kecil ini pada 7.1.1971.0. Ketika saya mencoba untuk menyebarkan menggunakan VS saya mendapatkan kesalahan file terkunci, jadi saya melihat untuk melihat apakah aplikasi masih berjalan dan cukup yakin itu. Saya membuka baris perintah Kudu untuk melihat file apa yang ada di direktori wwwroot dan App_Offline.htm berada di folder tetapi prosesnya masih berjalan. Kemudian saya mengetik touch app_offline.htm dan proses berhenti berjalan seperti yang diharapkan. Saya memeriksa ulang modul dan versi aspnetcore.dll saya adalah 7.1.1971.0.

@alexgritton itu aneh. Tampaknya menyiratkan bahwa ANCM awalnya tidak mendeteksi file. Apakah itu terjadi secara konsisten atau acak?

Saya baru saja membuat aplikasi hari ini di Azure App Services dan itu sudah terjadi sepanjang hari, jadi saya akan mengatakannya secara konsisten. Apakah Anda punya ide lain tentang apa yang bisa menyebabkan ini?

Tidak juga. Saya akan membiarkan pakar ANCM berkomentar tentang bagaimana mereka melakukan monitor perubahan file, dan jika mereka dapat memikirkan alasan mengapa pembuatan awal tidak terdeteksi.

@davidebbo Saya mengalami masalah yang sama persis. Tim saya memiliki Fake build yang menyalin file AppBuild.htm dari server build ke situs target sebagai app_offline.htm. Kami kemudian mencoba menggunakan msdeploy untuk menyinkronkan folder dan membuka kesalahan proses lain. Jika saya menyentuh file, ganti nama file dari app_offline.htm menjadi app_offline.htm.rename dan kembali lagi, atau timpa app_offline.htm menggunakan File Explorer maka proses berhenti dengan benar. Tidak masuk akal mengapa itu tidak bekerja melalui skrip kami tetapi melakukannya jika kami melakukannya secara manual.

Pembaruan: Kami menemukan bahwa memperbarui waktu penulisan terakhir tampaknya secara konsisten memicu penghentian:

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

Tampaknya ada sesuatu dengan kode yang memonitor file app_offline.htm.

@derekgreer Jadi yang Anda lihat adalah ketika Anda menyalin file, shutdown tidak dipicu? Saya tidak dapat mengulangi ini dari konsol Kudu. misalnya

• Buka Konsol Kudu
• Jalankan touch app_offline.htm di D:\home\site untuk membuat file kosong di folder lain
• Jalankan copy app_offline.htm wwwroot . Perhatikan bahwa ini mempertahankan waktu penulisan terakhir dan memperbarui waktu pembuatan (perilaku penyalinan file standar).

Hasil: proses dotnet.exe mati seketika (Anda dapat memeriksa menggunakan penjelajah proses Kudu).

Apakah langkah yang sama ini berhasil untuk Anda? Jika demikian, apa yang mungkin berbeda dalam skenario repro Anda?

Sebenarnya, saya juga harus menambahkan bahwa masalah ini telah terputus-putus dan kami menggunakan IIS 8 pada Windows Server 2012 .

Maksud saya pagi ini adalah untuk melihat apakah saya dapat mereproduksi masalah dengan skrip PowerShell atau batch sebelum menyiapkan Konsol Kudu, tetapi setelah terlebih dahulu menguji dengan skrip uji Fake build yang digunakan tim saya pada hari Jumat untuk membuat file app_offline.htm di berbagai cara (salin file yang ada, buat file baru, dll.), saat ini berfungsi. Ini mencerminkan pola kegagalan build kami yang terkadang mematikan proses dan terkadang tidak. Ketika mulai gagal, tampaknya melakukannya secara konsisten. Kami menguji selama berjam-jam pada hari Jumat dan secara konsisten tidak akan berhenti dengan pembuatan Palsu sederhana yang sama sekali tidak melakukan apa pun kecuali membuat file app_offline.htm baru. Saya juga harus menambahkan bahwa kami akan secara berkala membuat file secara manual dan melihat proses berhenti, jadi sepertinya tidak ada situasi apa pun di mana proses tidak akan dimatikan setelah beberapa lama penggunaan.

Ketika saya dapat mereproduksi masalah lagi, saya akan melihat apakah membuat file menggunakan PowerShell dan/atau file batch masih mencerminkan masalah tersebut.

@davidebbo Yah, sial ... Saya baru menyadari bahwa saya lupa mengomentari baris yang memperbarui waktu pembaruan terakhir, jadi memang masih menunjukkan perilaku yang sama. Saya akan mencoba dengan PowerShell dan file batch sekarang dan memperbarui Anda.

@davidebo

Maaf bila membingungkan. Oke, inilah yang saya temukan:

Menggunakan file batch dengan konten berikut tampaknya andal menyebabkan proses dimatikan:

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

Menggunakan skrip bash yang setara juga secara andal menyebabkan proses dimatikan:

#!/bin/bash

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

Menggunakan skrip PowerShell dengan konten berikut sepertinya tidak pernah menyebabkan proses mati:

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

Mengingat bahwa Fake dan Powershell berjalan di bawah CLR sementara perintah salin DOS, bash, dan Konsol Kudu tidak, ini tampaknya menunjuk ke sesuatu yang terkait dengan file yang dibuat melalui CLR.

Yang aneh adalah, saya tidak melihat perbedaan dalam stempel waktu buat/perbarui file yang dihasilkan antara berbagai versi.

@derekgreer Oh, jadi Anda tidak menjalankan Layanan Aplikasi Azure sama sekali. Itu sudut pandang saya di seluruh kisah ini, jadi saya akan membiarkan orang-orang ASP.NET berkomentar lebih lanjut tentang ini.

Meskipun untuk apa nilainya, saya tidak dapat melakukan repro di Layanan Aplikasi:

• Gunakan konsol PowerShell Kudu
• Buka situs\wwwfolder root
• Jalankan New-Item app_offline.htm -type file

@moozzyk dapatkah Anda membantu menyelidiki repro @derekgreer di luar layanan aplikasi?

Info lebih lanjut:

Sejak membuat, menyalin, mengganti nama, dll. melalui File Explorer telah bekerja secara konsisten, saya memutuskan untuk melihat apakah aplikasi file explorer berbasis .Net mencerminkan hasil yang sama seperti yang saya lihat dengan Fake dan PowerShell. Ada file explorer berbasis .Net bernama "Nomad" yang akhirnya saya unduh dan uji dan hasilnya konsisten dengan Fake dan PowerShell. Saat membuat file app_offline.htm, prosesnya tidak berhenti. Saya kemudian mengganti nama file dan menamainya kembali ke app_offline.htm lagi dan proses Core kemudian dimatikan.

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

Saya pikir metode ini ingin menyertakan flag "FILE_NOTIFY_CHANGE_CREATION".

Saya ingin tahu apakah .Net API yang umum untuk Fake, PowerShell, dan Nomad tidak memicu flag lain ini dengan cara yang sama seperti pembuatan file biasa.

@shirhatti bisakah Anda memastikan seseorang menyelidiki potensi masalah ANCM ini?

@davidebbo Ack. Kami sedang menyelidikinya

Saya mengalami masalah yang sangat mirip. Jika saya menyalin file app_offline.htm di Windows Explorer maka prosesnya akan berhenti dengan benar, tetapi jika saya membuatnya menggunakan COPY app_offline.htm \server\share\siteapp_offline.htm dari server build saya maka itu tidak berhenti dan file tetap terkunci .

@gulbanana Saya memiliki masalah yang sama persis seperti yang Anda lakukan. Apakah Anda sudah menyelesaikannya? @shirhatti Ada pembaruan tentang penyelidikan Anda? Yang ini membuat tim gila karena pipa CI gagal sepanjang waktu karena kegagalan penyalinan file yang pada gilirannya disebabkan oleh dotnet.exe tidak dimatikan oleh app_offline.htm.

Saya mengatasi masalah ini dengan menggunakan sesuatu di sepanjang baris echo "<html>page content</html>" > \\server\share\app_offline.htm . Saya pikir @derekgreer benar bahwa bug adalah tentang ANCM yang hanya menonton beberapa metode pembuatan file, dan menangkap yang ini.

@derekgreer
Saya sedang mencari masalah sekarang. Dengan salah satu perintah repro Anda di mesin uji saya, saya dapat mereproduksi masalah ini. Saya menggunakan perintah di bawah ini. (CATATAN: perintah di bawah ini akan membuat file kosong (ukuran file nol).

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

Satu hal yang menarik adalah jika saya menambahkan beberapa konten file saat membuat file app_offline.htm, tidak ada masalah. Itu dapat dilakukan hanya dengan menambahkan parameter -value "test" sebagai berikut:

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

Bisakah Anda mengonfirmasi jika Anda melihat gejala yang sama di lingkungan repro Anda?
Jika demikian, saya pikir masalah ini hanya terjadi ketika app_offline.htm kosong dibuat dengan beberapa cara khusus seperti menggunakan perintah powershell item baru.

@gulbanana
Saya tidak dapat mereproduksi masalah ini dengan perintah Salin. Bisakah Anda menjelaskan lebih detail tentang repro Anda? Akan sangat bagus jika Anda dapat menemukan beberapa langkah repro yang dengannya saya dapat mereproduksi masalah yang sama pada mesin uji saya.

Saya dapat mengonfirmasi bahwa itu tidak terkait dengan apakah file app_offline.htm kosong tanpa menjalankan perintah tersebut karena pengalaman kami dengan menyalin file dengan konten yang diinginkan ke folder penyebaran. Berdasarkan pengalaman saya, saya kira perintah kedua mungkin menyebabkan acara perubahan file jika memang berfungsi. Mungkin itu membuat file dan kemudian memperbaruinya dengan konten. Terlepas dari itu, setiap proses terkait .net yang saya gunakan untuk membuat file dengan atau tanpa konten gagal memicu proses shutdown.

@shirhatti Ada pembaruan? Apakah Anda dapat mengonfirmasi bahwa kode Anda harus menggunakan tanda "FILE_NOTIFY_CHANGE_CREATION"?

@derekgreer Kami mendengarkan setiap flag yang valid kecuali mengubah akses terakhir dan mengubah atribut.
FILE_NOTIFY_VALID_MASK & ~FILE_NOTIFY_CHANGE_LAST_ACCESS & ~FILE_NOTIFY_CHANGE_ATTRIBUTES

Jadi ya, kami sudah mendengarkan FILE_NOTIFY_CHANGE_CREATION .

cc: @pan-wang

@shirhatti Ah, saya mengerti sekarang. Saya tidak menyadari bahwa bendera mencakup pembuatan perubahan. Saya ingin tahu, apakah Anda dapat mereproduksi masalah ini?

Tidak bereaksi terhadap app_offline.htm yang kosong seharusnya diperbaiki: https://github.com/aspnet/IISintegration/issues/174

@moozzyk @derekgreer Terima kasih atas konfirmasinya. Oke, saya juga menemukan bahwa masalahnya tidak terkait langsung dengan konten file kosong. Saya akan memperbarui Anda setelah mencari tahu akar masalahnya.

@jhkimnew saya tidak memiliki pengaturan rusak yang tepat lagi, tetapi saya dapat menjelaskan secara spesifik:

• IIS berjalan di windows server 2008 r2, menghosting aplikasi inti asp.net menggunakan ANCM
• membangun server juga 2008r2, pada domain yang sama
• Server IIS memiliki direktori fisik situs web yang dibagikan menggunakan berbagi windows
• pengguna domain (akun server build) menjalankan skrip PowerShell di server build
  jika skrip ini menggunakan perintah windows copy untuk menyalin di app_offline dari file yang ada di direktori lain, maka proses hosting tidak dimatikan. jika skrip malah menggunakan "echo" (yang mungkin /bin/echo dari instalasi mingw, saya tidak yakin) maka proses hosting dimatikan.

saya menduga masalahnya ada hubungannya dengan atribut file mana yang diperbarui atau tidak diperbarui oleh salinan jarak jauh semacam itu

@gulbanana Hanya untuk memperjelas, Anda mencoba dengan perintah dos copy dan bukan commandlet power shell copy-item? Saya rasa saya tidak mencoba salinan dos biasa, tetapi saya menemukan bahwa aplikasi berbasis .net apa pun yang saya gunakan tidak berfungsi.

kecuali PowerShell memiliki alias untuk itu, itu dos copy

Dalam kasus saya, salinan PowerShell tidak akan mematikan proses dotnet.exe, tetapi gema, yang merupakan alias Out-Content berfungsi. Saya merasa ini bukan masalah .NET, tetapi lebih tentang mengapa salinan jaringan tidak berfungsi

Saya menyelidiki apakah ada masalah dalam pemberitahuan perubahan aspnetcore.dll (ANCM), tetapi saya tidak dapat mereproduksi masalah ketika saya mencoba untuk menghapus app_offline.htm secara manual baik menggunakan cmdlet powershell atau perintah DOS. Dan saya menemukan satu poin yang hilang yang tidak dibahas di sini.
Itu tentang shutdown yang anggun. Tidak seperti HttpPlatformHandler", ANCM mendukung graceful shutdown, yang berarti ketika app_offline.htm dijatuhkan pada direktori root, ANCM mengirimkan sinyal Crtrl-C/Break ke proses backend dan menunggu hingga 10 detik yang memungkinkan terjadinya graceful shutdown.
10 detik adalah nilai default dan pengguna dapat menyesuaikan nilai dengan shutdownTimeLimit pengaturan konfigurasi ANCM. Jika proses backend tidak dimatikan di shutdownTimeLimit yang dikonfigurasi, ANCM seharusnya mematikan proses backend.

Saat memeriksa bagaimana penerbitan MSDeploy terkait dengan shutdown anggun ANCM, saya akhirnya menemukan satu langkah repro yang konsisten, yaitu meningkatkan waktu shutdown (5 detik) dan melihat MSDeploy mencoba ulang hanya 2 kali secara default dan menunggu hanya 2 detik dan akhirnya gagal untuk mempublikasikan karena tidak menunggu waktu shutdown yang anggun.

@vijayrkn
Setelah saya menunda 5 detik untuk memulai dan mengakhiri aplikasi web aspnetcore, saya dapat mereproduksi kesalahan yang sama, yang dilaporkan dalam masalah ini, dalam percobaan kedua penerbitan aplikasi web aspnetcore ke server IIS lokal. Saya melampirkan profil publikasi yang saya gunakan di bawah ini juga.
Maukah Anda menjelaskan mengapa ini terjadi dan memberikan panduan yang benar tentang cara memperbaiki masalah penerbitan ini? Dan tolong buat masalah baru tentang ini secara terpisah sehingga tim Anda melacak masalah ini untuk meningkatkan pengalaman pengguna.

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

MSDeploy mencoba untuk menyebarkan tepat setelah app_offline dijatuhkan. Jika ada penundaan dalam menghentikan proses, maka penyebaran bisa gagal.

Jumlah percobaan ulang untuk penerapan dapat diatur menggunakan properti msbuild ini (https://github.com/aspnet/websdk/blob/dev/src/Publish/Microsoft.NET.Sdk.Publish.Targets/netstandard1.0/PublishTargets/Microsoft .NET.Sdk.Publish.MSDeploy.targets#L67)

misalnya, menyetel properti ini ke 10 akan memastikan bahwa msdeploy mencoba lagi 10 kali dengan jeda satu detik di antaranya.
<RetryAttemptsForDeployment>10</RetryAttemptsForDeployment>

@vijayrkn

Terima kasih untuk informasi. Setelah menambahkan dua baris di bawah ini, saya tidak melihat masalah dengan lingkungan repro yang sama.
<EnableMSDeployAppOffline>True</EnableMSDeployAppOffline> <RetryAttemptsForDeployment>10</RetryAttemptsForDeployment>

Jadi, siapa pun yang mengalami masalah serupa perlu meningkatkan jumlah RetryAttemptsForDeployment dengan nilai yang sesuai dan coba lagi jika itu dapat menyelesaikan masalah.

CATATAN: Alasan saya menambahkan EnableMSDeployAppOffline adalah karena dinonaktifkan secara default saat menggunakan server IIS lokal sebagai tujuan penerbitan aplikasi web aspnetcore. Jadi, jika Anda tidak yakin apakah itu diaktifkan atau tidak di lingkungan Anda, Anda hanya perlu menambahkan baris juga dan itulah mengapa saya menambahkannya di sini untuk informasi Anda.

Hanya untuk memastikan masalah asli tidak hilang karena diskusi terbaru, masalah yang dialami tim saya jelas bukan masalah waktu. Kami telah menguji pembuatan file app_offline.htm secara manual melalui Powershell, Fake, dan file explorer berbasis .Net bernama "Nomad" dan prosesnya tidak dimatikan tidak peduli berapa lama Anda menunggu. Membuat file melalui File Explorer, file batch DOS, atau skrip bash (yaitu proses berbasis perpustakaan non .Net) menyebabkan proses dimatikan dalam waktu 1-2 detik.

Ini tampaknya menunjukkan:

1. Masalahnya bukan terkait jaringan (semua pengujian dilakukan terhadap berbagi file jarak jauh)
2. Ini bukan masalah shutdown/waktu yang anggun

Fakta bahwa 3 metode non-.Net untuk membuat file app_offline.htm mematikan proses dengan andal dan cepat dan bahwa 3 metode berbasis .Net-library untuk membuat file tidak pernah mengakibatkan proses dimatikan dalam pengujian kami tampaknya benar-benar , indikator yang sangat besar bagi saya.

@derekgreer
Saya tidak dapat mereproduksi masalah bahkan dengan "Nomad".
Inilah yang saya lakukan pada mesin Windows 10 (amd64) saya.

1. Instal IIS
2. Instal Visual Studio 2017
3. Buat aplikasi web AspnetCore dan sebarkan ke server IIS lokal dengan MSDeploy
4. Instal Nomad v3.2.0.2890 (http://www.nomad-net.info/downloads)
5. Kirim permintaan ke aplikasi web
6. Buka Task Manager dan konfirmasikan proses dotnet.exe sedang berjalan
7. Buka Nomad dan buat file baru bernama app_offline.htm di direktori root aplikasi web
8. Lihat Task Manager dan verifikasi proses dotnet.exe hilang ketika file app_offline.htm dibuat

Maukah Anda memberikan langkah-langkah repro yang tepat sehingga saya dapat mengikuti untuk mereproduksi masalah?

Selain fakta bahwa aplikasi .Net Core kami sebenarnya adalah Aplikasi Konsol .Net 4.5.2 standar yang dibuat di VS 2015 yang merujuk rakitan ASP.Net Core, saya tidak melihat perbedaan. Proyek ini berusia sekitar satu tahun sekarang dan didirikan seperti itu pada saat itu karena keterbatasan dengan referensi jenis proyek template inti dari jenis proyek template kerangka .Net dan berbagai macam dukungan perpustakaan pengujian untuk inti .Net.

Kami mengidentifikasi beberapa masalah: 1) menjatuhkan file app_offline.htm (menggunakan beberapa alat) terkadang hanya memicu pemberitahuan perubahan properti file yang difilter oleh ANCM. 2) ANCM mungkin gagal membaca app_offline.htm karena yang terakhir dipegang oleh alat penyalinan file. 3) shutdown yang anggun menyebabkan penundaan dalam menghentikan proses backend.
Kami akan membahas dua masalah pertama dalam rilis berikutnya. Untuk kasus shutdown yang anggun, pengguna perlu mencoba lagi.

kedengarannya bagus. kasus saya jelas bukan tentang batas waktu shutdown yang anggun - ketika itu berhenti, ia segera berhenti.

Setiap pembaruan tentang masalah ini?
Mendapatkan saat mencoba menyebarkan aplikasi ASP.NET Core 1.1 ke slot Azure Web App menggunakan VSTS

• Saya memiliki set MSDEPLOY_RENAME_LOCKED_FILES=1 di Pengaturan Aplikasi
• Kelola Tugas Layanan Aplikasi dikonfigurasi untuk menjadikan aplikasi offline
• Menyebarkan tugas Layanan Aplikasi _was_ dikonfigurasi untuk membuat aplikasi offline, tetapi itu juga tidak berhasil

Masalah intinya adalah bahwa DLL sedang digunakan:

@ChuckkNorris silakan lihat https://github.com/Microsoft/vsts-tasks/issues/1607 untuk yang terbaru tentang ini.

@davidebbo Terima kasih atas balasan Anda, David. Saya memang melihat utas itu dan di situlah saya menemukan banyak solusi yang saya coba.

Karena masalah ini masih terbuka dan kesalahannya masih umum, saya berharap mungkin ada perbaikan segera, bukan solusi lain. Masalah ini telah terbuka selama lebih dari dua tahun sekarang.

@ChuckkNorris sementara gejalanya sama, ini bukan masalah yang sama:

• Masalah asli terkait dengan casing app_offline.htm , menyebabkannya diabaikan sepenuhnya. Itu telah diperbaiki untuk sementara waktu.
• Masalah baru ini dimulai sekitar seminggu yang lalu, dan terjadi karena sekarang Core membutuhkan waktu lebih lama untuk dimatikan ketika app_offline.htm dibuat, dan msdeploy secara default tidak menunggu cukup lama. Solusinya adalah meningkatkan jumlah percobaan ulang.

Saya baru saja memperbarui VS 2017 ke 15.3 dan menginstal .NET core 2.0 SDK. Membuat aplikasi MVC sederhana di VS - itu menargetkan netcoreapp1.1. Saya menerbitkan ke Azure, dan semuanya baik-baik saja. Saya memutakhirkan ke newcoreapp2.0 dan kemudian memutakhirkan semua paket nuget ke 2.0 (Microsoft.AspNetCore, Microsoft.AspNetCore.Mvc, dll)

Saat mencoba menerbitkan ke Azure (yaitu menimpa 1.1), saya mendapatkan ini

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

Saya harus menonaktifkan MvcViewComplication agar aplikasi 2.0 saya dapat digunakan melalui git dan mencegah masalah penggunaan file.

https://github.com/Microsoft/vsts-tasks/issues/5259
https://github.com/Microsoft/vsts-tasks/issues/1607#issuecomment -349115532
@davidebbo , Bisakah kita menutup masalah ini?
Meskipun menambahkan bantuan coba lagi untuk penerapan web, masalah ini tetap ada.

Hanya ingin menunjukkan yang jelas, bahwa ini mempengaruhi penerbitan FTP juga.

@jeremycook FTP sedikit berbeda, karena tidak memiliki otomatisasi untuk menggunakan App_Offline. Anda harus membuat file itu secara manual untuk menghentikan proses, setelah itu Anda dapat menyalin file.

@davidebbo cukup adil tetapi sepertinya jika saya mempublikasikan melalui FTP menggunakan fitur publikasi Visual Studio yang seharusnya berfungsi. Mungkin saya memposting ke tempat yang salah?

@jeremycook terus terang, saya tidak yakin apa yang dilakukan VS saat melakukan penerapan FTP. Mungkin orang lain bisa bersinar, tetapi sepertinya lebih seperti pertanyaan VS daripada ASP.NET.

Meskipun untuk mengisolasi, akan menarik untuk menguji apakah penyebaran berhasil jika Anda secara manual membuat App_Offline.html, dan kemudian FTP mempublikasikan dari VS.

@vijayrkn Bisakah Anda mengomentari perilaku VS selama penerapan FTP?

Penerbitan FTP dari VS ke layanan Aplikasi tidak mendukung App_Offline.

@vijayrkn ok, jadi untuk semua tujuan praktis, kita dapat mengatakan bahwa penyebaran .NET Core melalui FTP tidak didukung, kecuali jika pengguna secara eksplisit menghentikan situs sebelum penerapan. Benar?

@davidebbo - Ya, itu benar.

Mendapat masalah ini saat menggunakan aplikasi web asp.net core 2.0 ke IIS dari rilis VSTS menggunakan templat penyebaran web IIS. Hapus gagal karena file sedang digunakan. Opsi offline aplikasi diaktifkan.

@davidebbo @vijayrkn @shirhatti ini semua agak menyedihkan. Apakah ada rencana untuk membuat FTP/XCOPY berfungsi? Haruskah masalah baru dibuka yang berfokus pada penerapan cara lama melalui FTP/XCOPY/ROBOCOPY/dll.?

saya terlambat ke pesta ini tetapi di sini ada beberapa hal yang ingin saya laporkan:
VS 2017 Perusahaan
asp.net 4.6.xx
server adalah IIS 8.5 di server 2012 R2
jenis server sql dll terkunci dan kuncinya seperti itu ketika pengembang yang berbeda melakukan publikasi dengan msdeploy mereka mendapatkan kesalahan dan situs web sekarang rusak karena hanya sebagian dari penyebaran yang dijalankan.

jenis sql dll terkunci di folder bin aplikasi dan hanya mereka.
ganti nama file dll dan kemudian saya dapat mempublikasikan.
kemasan jenis sql memiliki kode cambuk untuk memuat dll yang tidak dikelola.
sepertinya itu harus diubah untuk tidak mengunci mereka. jika itu bisa dilakukan.

saya telah melihat orang-orang berbicara tentang cara memulai kembali situs atau menjadikannya offline tetapi saya belum menemukan pengaturan di msdeploy untuk itu. xml yang saya lihat tidak ada di file saya.

panduan yang lebih baik harus ditambahkan ke paket tipe sql yang diterbitkan microsoft.

Posting tentang masalah ini karena tampaknya lebih terkait langsung dengan saya. Saya juga mengikuti masalah di bawah ini pada topik yang sama meskipun untuk VSTS. Saya menerbitkan langsung dari visual studio.

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

Ini telah menjadi masalah hidup dan mati bagi saya tetapi baru-baru ini kembali berlaku dan di salah satu situs layanan aplikasi saya, saya mendapatkan kesalahan ini di hampir semua upaya publikasi. Situs ini di-host pada layanan tingkat 'dasar' jadi saya tidak memiliki slot yang saya gunakan di aplikasi lain untuk mengatasi masalah ini.

Ini untuk aplikasi .net core 2 mvc.

Satu pemikiran: beberapa file yang merupakan bagian dari aplikasi web tidak berubah pada setiap publikasi (seperti jenis sql)
tetapi ms deploy mencoba menggantinya di setiap penerapan.
sepertinya semacam pemeriksaan harus terjadi untuk tidak menyalin ulang file yang tidak berubah dan itu akan membuat pembaruan lebih kecil dan lebih cepat dan tidak perlu mengacaukan penguncian file.
banyak manfaat jika itu bisa dilakukan.

hal lainnya adalah mengidentifikasi dengan lebih baik apa yang mengunci file dan mengapa serta bagaimana membatalkannya.
dan dapatkan itu sebagai bagian dari jalur penerapan standar.

@figuerres Saya sudah lama ingin menangani masalah itu selama beberapa bulan sekarang. Masalah penguncian biasanya dihindari karena Shadow Copying, tetapi dengan memuat DLL asli tersebut dari ~/bin , masalah penguncian dibuat. Saya memiliki solusi potensial, tetapi saya tidak yakin apakah itu solusi yang sepenuhnya aman: https://stackoverflow.com/questions/47796553/is-it-safe-to-manually-copy-native-dlls-to- a-bayangan-salin-direktori

Saya setuju bahwa dokumentasi untuk paket NuGet harus menyediakan metode yang lebih baik, yang tidak menyebabkan masalah penguncian.

@figuerres FYI, saya telah menerapkan hal di atas, lihat pertanyaan Stack Overflow untuk kodenya.

Bunuh dotnet.exe di Pengelola Tugas

Apa statusnya di sini? 3 tahun berlalu, masih belum diperbaiki. Saya harus secara manual pergi ke server dan menghentikan situs web.

3 tahun? Masalah ini dilaporkan Agustus 2017. Dimatikan oleh 1 like whoa.
Pada Senin, 23 April 2018 pukul 20:56 Oliver Janik [email protected]
menulis:

Apa statusnya di sini? 3 tahun berlalu, masih belum diperbaiki. Saya harus pergi secara manual
ke server dan menghentikan situs web.

—
Anda menerima ini karena Anda berlangganan utas ini.
Balas email ini secara langsung, lihat di GitHub
https://github.com/aspnet/Home/issues/694#issuecomment-383768450 , atau bisukan
benang
https://github.com/notifications/unsubscribe-auth/AAXhfrhOTvZn2qb4kU-Y1Kg9I-IQKD9yks5trnhXgaJpZM4FJp_R
.

Postingan pertama mengatakan " pekkah membuka edisi ini pada 23 Jun 2015"

Kamu benar. Salahku. Saya hanya melihat stempel waktu terakhir di rantai email.
Pada Senin, 23 April 2018 pukul 21:06 Oliver Janik [email protected]
menulis:

Postingan pertama mengatakan "pekkah berkomentar pada 23 Jun 2015"

—
Anda menerima ini karena Anda berkomentar.

Balas email ini secara langsung, lihat di GitHub
https://github.com/aspnet/Home/issues/694#issuecomment-383769982 , atau bisukan
benang
https://github.com/notifications/unsubscribe-auth/AAXhfgwYG-jLjnoJF7MCMtzbbfxSZkt2ks5trnqXgaJpZM4FJp_R
.

Menutup karena ini setua kotoran

@Eilon Maaf, tapi mengapa ini ditutup? Itu masih belum terselesaikan?

Menutup karena ini setua kotoran

Tapi itu masih masalah..? (bahkan pada penerapan none-Azure)

Membuat masalah baru (#3719) untuk meningkatkan visibilitas.