Aspnetcore: فشل النشر بسبب الملف قيد الاستخدام

لقد لاحظت وجود مشكلة مماثلة في تأمين ملف IIS على Azure VM الذي منع نشر WebDeploy. الحل البديل الخاص بي هو إصدار ثلاثة أوامر WebDeploy: إيقاف AppPool ، نشر ، إعادة تشغيل AppPool. انظر السيناريو الخاص بي. وإذا كان لديك القدرة على تشغيل ثلاثة أوامر WebDeploy ، فقد تتمكن من القيام بشيء مماثل باستخدام Azure Apps.

الحصول على هذه المشكلة في beta6.

نفس الشيء هنا! يتسبب ذلك في تجميد Visual Studio 2015 الخاص بي فعليًا - عند نشر تطبيق vNext (كلاهما beta6 و beta7 على ما أعتقد).

هل تستخدم البرامج النصية التي توفرها Microsoft للقيام بالنشر؟ إذا كان الأمر كذلك ، يمكنك فقط إضافة سطر في PublishAspNet5Website.ps1 لإعادة تشغيل تطبيق الويب:

Restart-AzureWebsite -Name $websiteName

تم توضيح تعديلات البرنامج النصي للبناء في هذا المنشور: حل مشكلة نشر ASP.NET 5 إلى Azure Web App Slot

brandonmartinez ، لن تساعد إعادة تشغيل موقع ويب ، حيث سيستمر موقع الإنتاج في تلقي الطلبات ، مما يؤدي بالتالي إلى إعادة تخزين الملفات. الطريقة الوحيدة الموثوقة حاليًا لتحديث موقعي IIS و Azure هي إيقاف تشغيل تجمع تطبيقات موقع الويب ، ثم تحديث الملفات ، ثم إعادة تشغيل موقع الويب. ما عليك سوى اتباع رابط GuardRex لمزيد من التفاصيل.

ومع ذلك ، لا يجب أن نتعامل مع البرامج النصية المخصصة للنشر عند العمل في ظل الظروف الافتراضية مع VS2015.

نأمل أن تكون البنية الأساسية الجديدة لـ HttpPlatformHandler (التي لم تعد بحاجة إلى AspNet.Loader.dll) أكثر تسامحًا ، لكنني لا أحبس أنفاسي هنا. من المحتمل أن نحصل على ملف .dll مغلق آخر.

rubenprins هذا هو الحل الذي أستخدمه أيضًا ، من خلال أدوات Azure SDK في VS.

هناك أوامر 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 ونشره وإعادة تشغيله كان ثابتًا ، نهج العمل.

لا يجب أن نتعامل مع البرامج النصية المخصصة للنشر عند العمل في ظل الظروف الافتراضية مع VS2015

حدث شيء واحد بالنسبة لي على الرغم من ذلك: أن تكون قادرًا على استخدام "النشر إلى نظام الملفات" وربط نص برمجي بعد النشر الذي يحتوي على بتات MSDeploy قد أتاح قصة نشر بسيطة ومفيدة للغاية لأجهزة VM المتعددة. نظرًا لأن البرنامج النصي يتم تنفيذه بالتتابع ، فإنه ينتقل فقط من VM إلى VM أسفل السطر. يجعل استراحة قهوة لطيفة. :ابتسامة:

لدي سؤال في البدء في تكوين موازن تحميل يواجه الإنترنت باستخدام Azure Resource Manager مع فريق Azure Resource Manager يسأل عن كيفية إخبار موازن التحميل بالتوقف مؤقتًا عن إرسال حركة المرور إلى الجهاز الظاهري أثناء النشر.

على أي حال ... العودة إلى الموضوع الذي أثاره pekkah . نظرًا لأننا نعلم أن أوامر PS تعمل ، تحقق من الخيارات لتنفيذها في بناء VSO:

مهام وكيل Microsoft / vso
قم بتشغيل برنامج نصي في عملية البناء الخاصة بك
تشغيل البرامج النصية سابقة الإنشاء في Team Foundation Service (Visual Studio Online) لعملية إنشاء النشر المستمر لـ Azure
ميزات أتمتة البناء الجديدة في Visual Studio Online

... نعم ... شيء من هذا القبيل يجب أن يعمل من أجلك.

نفس المشكلة هنا...

ما زلت في انتظار حل رسمي

برونو

سيتم حل ذلك عن طريق https://github.com/aspnet/IISIntegration/issues/81.

moozzyk ، ستعمل هذه المشكلة على إصلاح النشر فقط عبر أدوات مخصصة مثل msdeploy. لن يكون نشر مزامنة Xcopy / File ممكنًا ، مما سيؤدي أيضًا إلى حظر / إعاقة العديد من سيناريوهات CI التي تعمل فقط مع ASP.NET v1-4.

لا تزال المشكلة موجودة في ASP.NET Core 1.0 RC2 مع Visual Studio 2015.2 MSDeploy في IIS 8 على Windows 2012 R2 بأحدث الأدوات للخادم. يؤدي إنهاء عملية dotnet.exe أو إعادة تدوير تجمع التطبيقات إلى حل المشكلة. لكن هذا يحتاج إلى وصول سطح المكتب البعيد إلى الخادم وليست عملية سلسة تمامًا.

@ dg9ngf - هذا خطأ في web.deploy الآن. لقد أضافوا وظيفة app_offline.htm لـ Azure ولكن يتم تعطيلها افتراضيًا عند النشر محليًا. حاول فتح ملف تعريف النشر الخاص بك (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>

كانت هذه الخاصية _not_ موجودة في ملف .pubxml الذي أنشأه Visual Studio. لذلك أضفته لكنه لم يغير شيئًا. -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]

أقوم بالنشر باستخدام مهمة "نشر تطبيق الويب Azure" في VSTS ، كما هو موضح في منشور المدونة هذا: http://donovanbrown.com/post/2016/05/30/DevOps-for-ASPNET-Core-RC2

هل هناك طريقة لتحديد <EnableMSDeployAppOffline>True</EnableMSDeployAppOffline> باستخدام هذه الطريقة؟

مرحبًا ، لقد واجهت نفس المشكلة في Azure ، لقد قمت بحلها بهذه الطريقة https://github.com/davidebbo/WAWSDeploy/issues/14

@ dg9ngf في الإصدار الحالي من سكربت بوويرشيل ، ندعم appOffline فقط لـ WebPublishMethod - "MSDeploy".

سيتوفر دعم AppOffline لنشر نظام الملفات في الإصدار التالي.

bojingo أنا في نفس الموقف. هل هذا الرقم؟

davenewza : إذا قمت بزيارة منشور المدونة هذا مرة أخرى ، فإن الحل يكمن في التعليقات.
http://donovanbrown.com/post/2016/05/30/DevOps-for-ASPNET-Core-RC2

تحتاج في الأساس إلى إضافة خطوات VSTS لإيقاف / بدء الموقع. بعيد جدًا عن الحل المثالي (في الواقع ، ضعيف تمامًا) ، خاصةً لأنني لا أستخدم فتحات النشر ، لكنه يعمل بشكل جيد لبيئة التطوير / الاختبار الخاصة بنا.

هناك إصدار ARM جديد للمعاينة من مهمة VSTS لنشر تطبيق الويب والتي تعتمد على msdeploy وتعود بإصلاحها ، لكن لم يحالفني الحظ معها لأنني كنت بحاجة إلى العميل لإنشاء مبدأ خدمة للاشتراك ، وذلك كان من المتاعب. ربما يمكنك الحصول على ذلك للعمل:
https://github.com/Microsoft/vsts-tasks/tree/master/Tasks/AzureRmWebAppDeployment

vijayrkn لا يحتوي مربع حوار نشر الويب في VS2015 على أي خيار لتعيين msdeploy - يوفر فقط خيارات WebPublishMethod = FileSystem.

هل يمكنك تقديم نموذج .pubxml لـ WebPublishMethod = msdeploy من فضلك؟

tomfanning بالنسبة لتطبيق وحدة التحكم الأساسية ASP.NET ، فإن خيار النشر الوحيد المتاح حاليًا هو نظام الملفات. هل تحاول نشر تطبيق وحدة التحكم؟ بالنسبة لتطبيق الويب ، يجب أن تكون جميع هذه الخيارات الأربعة متاحة (النشر عبر الويب ، حزمة نشر الويب ، نظام الملفات وبروتوكول نقل الملفات).
نموذج webdeploy pubxml - https://github.com/dotnetpublish/AspNetCoreBlogList/tree/master/src/AspNetCoreBlogList/Properties/PublishProfiles

إذا كان تطبيق ويب وكنت ترى خيار نشر نظام الملفات فقط ، فهل يمكنك التحقق من xproj لمعرفة ما إذا كان يستورد هذا؟
<Import Project="$(VSToolsPath)\DotNet.Web\Microsoft.DotNet.Web.targets" Condition="'$(VSToolsPath)' != ''" />

bojingo لقد تمكنت من إعداد مدير الخدمة ، وهناك العديد من البرامج التعليمية على الشبكة. ليس لدي الروابط هنا ولكن يمكنني البحث عنها إذا كنت بحاجة إليها. مشكلتي الآن هي أن المهمة تتطلب ملف parameters.xml لم يتم إنشاؤه على نشر ASP Net Core ... :(

لدي TFS 2015 في مكان العمل ولا تزال هذه مشكلة مزعجة بشكل لا يصدق.

أنا أيضًا أواجه هذه المشكلة ...

كان الحل هو الاحتفاظ بفتحة التدريج التي أنشرها لإيقافها ، ثم النشر عليها (يعمل التبادل التلقائي). إعادة التشغيل ، ثم النشر لم ينجح (النشر باستخدام VSTS)

أنا أستخدم الأخطبوط مع Azure Web Apps ، والذي لا يقدم خيارًا لفتحات التدريج. ومع ذلك ، يبدو أن التحقق من الخيارات التالية قد نجح:

• قم بإسقاط نطاق التطبيق بأمان باستخدام 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

يحمّل الناشر 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

حقا تبحث عن حل لهذا. بدا الأمر وكأن مهمة VSTS لنشر الويب RM اعتنت بهذا مع تحديد خيار "Take App Offline" ، ولكن اعتبارًا من نهاية هذا الأسبوع نتلقى الأخطاء باستمرار. لقد عدنا إلى إيقاف فتحة النشر والنشر والبدء مرة أخرى.

وبالمثل ، ظهرت هذه المشكلة يوم الجمعة من الأسبوع الماضي ومنعتنا من الانتشار منذ ذلك الحين ...

نفس الشيء هنا. يبدو أنه يؤثر فقط على المواقع التي تعمل باستخدام Always On = true ، لكن هذا ليس مؤكدًا.

ما زلت أواجه هذه المشكلة حتى عند تعيين MSDEPLOY_RENAME_LOCKED_FILES = 1 في التكوين الخاص بي. يكاد يكون من المستحيل تحديث البناء على الخادم الخاص بي الآن. بدأ هذا للتو قبل أيام قليلة.

لقد بدأت نفس المشكلة بالنسبة لي هذا الأسبوع. حتى هذا الأسبوع ، يتم نشر خدمة تطبيق AzureRM في VSTS مع الإعداد 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 إلى HTTP PUT الملف المغلف بشكل صحيح app_offline.htm في مكانه. لقد تم تكوين WebDeploy لإزالة أي ملفات ليست في النشر ، لذلك يقوم تلقائيًا بإزالة الملف كجزء من النشر. قد تحتاج إلى تكرار الخطوة باستخدام HTTP DELETE لإزالة الملف بعد النشر باعتباره انتهى إذا كنت لا تستخدم هذا الوضع.

تعمل إضافة Trackyon Stop قبل مهمة AzureRM ومهمة Trackyon Start بعد ذلك بشكل جيد بالنسبة لي. لا ينبغي أن يكون هذا ضروريًا مع TakeAppOffline = true ولكنه يعمل ويتجنب الدليل أو البرمجة النصية. فقط أضف المهمة إلى تعريف الإصدار. خطوات Trackyon سهلة الإعداد

في 21 كانون الأول (ديسمبر) 2016 ، الساعة 12:10 صباحًا ، كتب "تشاد" على العنوان التالي:

إليك الحل البديل في Powershell الذي نستخدمه حاليًا كجزء من عملية CI / البناء. شكر خاص لappveyor https://github.com/appveyor رفاق للمساعدة في هذا:

username = $ env: publishusername
كلمة المرور $ = $ env: publishpassword
$ base64AuthInfo = [تحويل] :: ToBase64String ([Text.Encoding] :: ASCII.GetBytes (("{0}: {1}" -f $ username، $ password)))
رؤوس $ = @ {
'التخويل' = ('أساسي {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 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/AID9WoUdbuBnFoXR2K5o8AiUtv8nE9DRks .

هذه الرسالة ليست عامة وقد تحتوي على معلومات خاصة أو خاصة أو سرية. إذا كنت قد تلقيتها عن طريق الخطأ ، فيرجى إخطار المرسل على الفور وحذف جميع نسخ الأصل. يحظر أي استخدام آخر للبريد الإلكتروني من قبلك. لا يُسمح بأي نسخ أو تخزين أو استخدام أو إفشاء غير مصرح به لمحتويات هذه الرسالة وقد يكون غير قانوني. حيثما يسمح القانون المحلي ، يجوز مراقبة الاتصالات الإلكترونية مع Lithero وفحصها ضوئيًا بواسطة أنظمتنا لأغراض أمن المعلومات وتقييم الامتثال الداخلي لسياسات Lithero والقوانين المعمول بها.

/ سم مكعب davidebbo

حاول تعيين MSDEPLOY_RENAME_LOCKED_FILES=1 في إعدادات تطبيق Azure لتطبيقك.

davidebbo لا يبدو أن هذا يحل الأمور.

أفترض أن هذا مرتبط بتغيير على الجانب الأزرق من السياج؟ لقد واجه الكثير من الأشخاص (خاصة على قناة سلاك aspnet) هذه المشكلة جميعًا في نفس الوقت.

لن يفسر التغيير في Azure سبب رؤيتنا لهذا في مكان العمل مع TFS. هل يمكن أن يكون الوكيل؟

نحن نشهد نفس المشكلة. لم يتم اختيار App_Offline.htm. من الغريب أنه إذا نشرنا من VS فإنه يعمل بشكل جيد.

بشكل غريب ، بالنسبة لي لا يعمل من VS ، كما هو موضح هنا: # 1883

يواجه فريقي أيضًا هذه المشكلة ، تقريبًا في كل مرة يفشل النشر بسبب الملف المقفل. يحتاج إلى إعادة تشغيل كل تطبيق في اللازوردية وإعادة تشغيل النشر. نحن نستخدم Octopus Deploy.

واجه فريقي هذه المشكلة هذا الصباح. هل من تعليقات من فريق Microsoft؟ يعتبر خط أنابيب التحرير أمرًا بالغ الأهمية لإنتاجيتنا ، فهو يمنع عمليات التحرير في مواقع الإنتاج. شكرا!

bmoscao - app_offline.html حساس لحالة الأحرف.

ظهرت هذه المشكلة أيضًا بالنسبة لي على Azure. لم أفعل شيئًا في نهايتي للتسبب في ذلك.

أواجه هذه المشكلة أيضا. الشيء هو أن EnableMSDeployAppOffline تم ضبطه على true - ويظهر ناتج المشروع -enablerule:AppOffline كجزء من الأمر الذي يتم تشغيله بواسطة الاستوديو المرئي. لست متأكدًا مما يجب فعله ... لقد بدأت للتو في تلقي هذه المشكلة مؤخرًا ..

كان الحل البديل لهذا هو إيقاف تجمع التطبيقات ، ونشره ، ثم إعادة تشغيله. نحن نستخدم Release Manager والمكوّن الإضافي بوويرشيل المضمن لإنجاز ذلك.

قف:

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 على الرغم من أن هذا كان يعمل بشكل رائع فقط مع تمكين قاعدة appOffline في خطوة نشر RM Azure.

davidebbo نحن نستخدم ASP.NET Core و VSTS Release Manager و AzureRmWebApp مع فتحات.

تضمين التغريدة إنه يعمل بالنسبة لي ؛)

يحدث لنا أيضًا - msdeploy في Azure. يسعدني أن أرى أنه بدأ بشكل غامض لعدد من الأشخاص في نفس الوقت - وهو ليس فقط نحن - ولكنه ليس مطمئنًا بشكل عام!

لا أعتقد أن الأشخاص في مرض التصلب العصبي المتعدد يحتاجون إلى تأكيد لذلك ، ربما يعرفون جيدًا ما هي المشكلة. على أي حال ، نفس الشيء هنا. النشر من VSTS ، توقف عن العمل في أوائل ديسمبر. في الوقت الحالي ، أستخدم مهمة trackyon للتوقف / البدء.

استعراض هذا الموضوع ، لكل إدخال ، ليس واضحًا دائمًا:

1. ما إذا كانت المشكلة تشير إلى Azure App Service أو بعض الاستضافة الأخرى
2. ما إذا كان الأشخاص قد حاولوا تغيير غلاف app_offline كما تمت مناقشته أعلاه. يبدو أن العديد من الأشخاص أبلغوا عن النجاح هناك.
3. ما إذا كان MSDEPLOY_RENAME_LOCKED_FILES قد تمت تجربته. مرة أخرى ، يبدو أن العديد من الأشخاص قد نجحوا في ذلك.

إذا كنت تواجه هذه المشكلة ، فالرجاء توضيح ما هو السيناريو الخاص بك وما الذي جربته ، حتى نتمكن من فهم هذا الأمر. شكرا!

تضمين التغريدة

أتلقى الرسالة ERROR_FILE_IN_USE عندما أحاول النشر باستخدام Visual Studio / MSBuild. المهمة هي إنشاء ملف App_Offline.htm على الخادم لكنها لا تؤدي إلى إيقاف التطبيق.

يؤدي إنشاء ملف app_offline.htm باستخدام Web Deploy إلى إيقاف التطبيق.

هذا هو الإعداد الخاص بي:

• الخادم: 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>

تضمين التغريدة

لقد علقت على هذا الخطأ في سلسلة رسائل مماثلة وكنت مضطرًا إلى إيقاف تطبيق الويب Azure وإعادة تشغيله في كل مرة أرغب في إعادة النشر (في بيئة التطوير فقط). لم يضطر إلى القيام بذلك قبل هذا الأسبوع. قررت إنشاء تطبيق ويب أساسي Visual Studio 2015 .net بشكل أساسي من القالب دون أي تعديلات.

قمت بتشغيل تطبيق الويب على المضيف المحلي لا توجد مشكلة على الإطلاق.
أقوم بنشر التطبيق الجديد على خطة خدمة تطبيق Azure Web App الخاصة بي بدون أي مشكلة ، وعرض المتصفح على الفور عدم وجود مشكلة في الموقع.
راجعت Azure Dashboard ولا توجد مشاكل على الإطلاق.

ثم ذهبت وأعدت نشر تطبيق الويب دون تعديل أي شيء - رمز أو إعدادات والخطأ التالي يظهر نفسه.

من ذلك الحين فصاعدًا ، لا بد لي من إيقاف تطبيق الويب ، والنشر إلى Azure ثم بدء تطبيق الويب. هذا لم يحدث لي من قبل هذا نشر بسيط للغاية لقالب Microsoft.

لقد سجلت هذه العملية برمتها وأرسلت تلك التعليقات ضمن نظام ملاحظات Microsoft 2015 VS. أتمنى أن تجد هذا التسجيل. أو ربما يمكنني فعل ذلك مرة أخرى.

تحياتي بطرس

تضمين التغريدة

ما إذا كانت المشكلة تشير إلى Azure App Service أو بعض الاستضافة الأخرى

خدمة تطبيق Azure.

ما إذا كان الأشخاص قد حاولوا تغيير غلاف app_offline كما تمت مناقشته أعلاه. يبدو أن العديد من الأشخاص أبلغوا عن النجاح هناك.

يؤدي تغيير App_Offline إلى app_offline إلى إصلاح المشكلة - يتم إنشاء هذا الملف عبر webdeploy تلقائيًا باستخدام غلاف "App_Offline" كجزء من النشر ، وهو جوهر المشكلة.

تضمين التغريدة
بالضبط نفسctolkien.

تضمين التغريدة

ما إذا كانت المشكلة تشير إلى Azure App Service أو بعض الاستضافة الأخرى

في حالتي ، أقوم بالنشر في خدمة تطبيقات Azure. لا أعرف عن الاستضافة الأخرى.

ما إذا كان الأشخاص قد حاولوا تغيير غلاف app_offline كما تمت مناقشته أعلاه. يبدو أن العديد من الأشخاص أبلغوا عن النجاح هناك.

أنا أستخدم مهمة "نشر تطبيق الويب AzureRM" من VSTS (https://aka.ms/azurermwebdeployreadme). هناك خيار "النشر باستخدام Web Deploy" <- تم تحديده و "Take App Offline" <- حدد الخيار الذي كان يعمل ، حتى تغير شيء ما في مكان ما وتوقف عن العمل.
يخبر تلميح "المعلومات" صراحةً عن وضع "app_offline.htm" بأحرف صغيرة "a".
لست متأكدًا من كيفية تغييره باستخدام هذا البرنامج النصي ، يجب أن يكون بالفعل بأحرف صغيرة.

سواء تمت تجربة MSDEPLOY_RENAME_LOCKED_FILES. مرة أخرى ، يبدو أن العديد من الأشخاص قد نجحوا في ذلك.

لم يحاكم. لا أعرف كيف تفعل ذلك. ولكن على أي حال ، أفضل استخدام التطبيق في وضع عدم الاتصال بدلاً من تغيير محتويات الملفات المقفلة.

شكرا لكم جميعا. لذلك يبدو واضحًا أن المشكلة الأساسية تتعلق بغلاف app_offline.htm ، وليس أي شيء متعلق بخدمة تطبيق Azure (وهو الجانب الذي أتيت منه). ويتم تتبع ذلك من خلال 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 كان دائمًا حساسًا لحالة الأحرف.

تضمين التغريدة

وليس أي شيء متعلق بخدمة تطبيقات Azure (وهو الجانب الذي أتيت منه)

أعتقد أن سبب تقديم Azure AppService إلى المناقشة هو أنه بدون أي تغييرات نيابة عنا ، بدأت الأشياء للتو في الفشل ، ولم نغير أيًا من إصدارات الحزمة الخاصة بنا. هل تمت مراجعة مراجعة ANCM على خدمات التطبيقات؟

ctolkien نعم ، أعتقد أنه تم تحديثه بالفعل. لذلك يمكن أن يكون الاستنتاج أعلاه غير صحيح. بدلاً من ذلك ، فإن النظرية الجديدة هي:

• لم يكن ANCM الأقدم (7.1.1965.0) حساسًا لحالة الأحرف.
• الإصدار الأحدث (7.1.1970.0) أصبح حساسًا لحالة الأحرف.
• لم يتغير شيء من جانب النشر VS ، وكان الغلاف دائمًا App_Offline.htm .

moozzyk هل تعتقد أن هذا احتمال ، أم أنك متأكد من أنه كان دائمًا حساسًا لحالة الأحرف؟

moozzykdavidebbo - لم يكن هناك تغيير في أدوات VS لغلاف app_offline. تستدعي أدوات VS msdeploy مع قاعدة appoffline (-enablerule: AppOffline) وتقوم msdeploy بإسقاط App_Offline.htm.

هذه المشكلة تبدو وكأنها تغيير سلوك في ANCM. بناءً على التعليق الأول هنا ، يجب أن يكون app_offline حساسًا لحالة الأحرف (https://github.com/aspnet/IISIntegration/issues/81).

تضمين التغريدة

يؤدي تغيير App_Offline إلى app_offline إلى إصلاح المشكلة

أين يمكنني تغيير هذا؟ أفعل MSDEPLOY مباشرة من Visual Studio إلى Azure.

تضمين التغريدة

أين يمكنني تغيير هذا؟ أفعل MSDEPLOY مباشرة من Visual Studio إلى Azure.

لا يمكنك تغيير غلاف App_Offline من MSDEPLOY بقدر ما أعرف ، ستحتاج إلى حل برنامج نصي مخصص في الوقت الحالي. يمكنك استخدام البرنامج النصي بوويرشيل الذي نشرته أعلاه كنقطة بداية.

لتحديث الجميع ، أكدنا أن النظرية أعلاه صحيحة: خطأ حساسية الحالة هو تراجع في إصدار ANCM الأحدث ، وتم نشر هذا الإصدار في Azure App Service في ديسمبر ، مما تسبب في إصابة المستخدمين بهذا فجأة.

تتمثل الخطة في الحصول على إصلاح ANCM من فريق ASP.NET Core ونشره في خدمة التطبيقات. لا توجد ETA حتى الآن ، ولكن يجب أن يحدث ذلك في وقت ما في شهر يناير.

شكرا!

davidebbo هل سنتمكن من تنزيل ANCM لتثبيته على خادمنا الخاص باستخدام iis وضرب هذا الخطأ أيضًا؟

@ Pictuel أعتقد ذلك. لاحظ أن الزاوية الخاصة بي هنا هي خدمة تطبيقات Azure بدقة ، لذا سأدع الفريق الأساسي يعلق على سيناريوهات غير Azure.

وذلك بفضل لرؤساء متابعة :)

Pictuel نعم سنضمن إصدار إصدار محدث من برنامج تثبيت استضافة Windows لـ .NET Core يحتوي على التحديث لـ ANCM.

تضمين التغريدة

shirhatti أنا أراقب هنا عندما يكون المثبت المحدث متاحًا لتحديث روابط المستندات.

بعد المرور عبر هذا الموضوع ، لست متأكدًا حقًا من الحل البديل لخدمات التطبيقات بالضبط. هل هو إعداد التطبيق أم أنه يستخدم برنامج نشر مخصص أو إيقاف وبدء تشغيل الموقع؟

إذا كان هذا هو إعداد التطبيق ، فقد قرأت تعليقًا آخر يقول إنه يتسبب في عدم قيام موقع الويب بالتقاط مكتبات DLL الجديدة.

إذا فهمت بشكل صحيح ، فلا يوجد حل بديل من جانبنا حتى يتوفر تحديث على ANCM (https://github.com/aspnet/AspNetCoreModule/issues/50). يجب تحديث خدمات التطبيقات من قبل فريق azure.

أعتقد أن أفضل رهان على خدمة التطبيقات هو إيقاف / تشغيل التطبيق كما هو موضح بواسطة dtmnash هنا .

davidebbo "تتمثل الخطة في الحصول على إصلاح ANCM من فريق ASP.NET Core ونشره في خدمة التطبيقات. لا توجد ETA حتى الآن ، ولكن يجب أن يحدث ذلك في وقت ما في يناير." - أخبرنا عندما يكون وقت الوصول المتوقع جاهزًا في هذا الأمر :)

وقت النشر المؤقت هو ما بين 24 و 30. يحدث النشر تدريجيًا على العديد من وحدات الميزان ، لذلك لن يحصل الجميع على الإصلاح في نفس الوقت بالضبط.

شكرًا لك ، لقد بدأت العمل للتو :-)

لا تزال مشكلة بالنسبة لي :(

hbunjes شكرا للتأكيد!

rsnj يحدث هذا تدريجيًا على مدار فترة زمنية معينة. يجب أن يتم كل ذلك بحلول نهاية الشهر (ما لم نواجه مشكلة).

يبدو أن davidebbo Deployment يعمل مع بعض تطبيقاتي ولكن ليس كلها. الشيء الغريب هو أن بعض عمليات النشر تفشل ولكن البعض الآخر لا يحدث للتطبيقات التي تعمل في نفس خطة خدمة التطبيق. هل من الممكن معرفة إصدار ANCM الذي يتم تشغيله لتطبيق ويب معين؟

henningst راجع https://github.com/aspnet/AspNetCoreModule/issues/50#issuecomment -271381892 لمعرفة طريقة التحقق.

لم يكن يعمل لي بالأمس ولكنه الآن. شكرا لك davidebbo!

لقد بدأت العمل من أجلي أيضا. شكرا!

نعم ، اكتمل النشر الآن ، لذا يجب أن يعمل مع الجميع.

كل خير بالنسبة لي هنا أيضا.

يبدو أنه يعمل الآن. من التقرير استغرق الأمر أكثر من عام لإصلاح هذا. كنت سأفعل على الرغم من أن مشكلات النشر تحظى بأولوية أعلى: p

كيفية إصلاح هذا لغير Azure؟

pekkah أعتقد أنه مر بمشكلات مختلفة. كان آخرها أكثر حداثة من عام واحد.

jdshkolnik لغير Azure ، أعتقد أنك تحتاج فقط إلى البدء في استخدام ANCM الجديد.

تضمين التغريدة
التحديث متاح للتنزيل من https://www.microsoft.com/net/download/core#/runtime
هذا رابط مباشر للتنزيل.

shirhatti لقد قمت بتثبيت هذا ولكن ما زلت أتلقى هذه الأخطاء.

ما زلت أتلقى الخطأ في ساو باولو ، جنوب البرازيل.

jdshkolnik ما هو الإصدار الذي تراه عند تشغيل هذا في PowerShell؟

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

عبدالله @ 3bdul1ah 7

تحديث : آسف ، كان هذا خطأي. كنت أقوم بمراجعة وتحديث خطوات نشر الإصدار الحالي بدلاً من تعريف الإصدار. لقد فقدت عدد المرات التي قمت فيها بهذا ...

ما زلت أواجه هذا الخطأ في كل مرة أحاول فيها النشر على الرغم من أن إصدار aspnetcore.dll الخاص بي هو الإصدار الذي من المفترض أنه تم إصلاحه.

إصدار aspnetcore.dll: 7.1.1971.0
تم النشر باستخدام : مهمة VSTS Azure App Service Deploy v3. * (معاينة)
Take App Offline : تم الفحص
إزالة الملفات الإضافية في الوجهة : تم التحديد
إعادة تسمية الملفات المقفلة : تم التحديد
MSDEPLOY_RENAME_LOCKED_FILES إعداد التطبيق : لم تتم إضافته

في هذه المرحلة ، ليس من الواضح بالنسبة لي ما هي الإعدادات المطلوبة أو غير المطلوبة حتى يعمل هذا.

لقد حصلت للتو على ملفي الأول قيد الاستخدام مرة أخرى الآن على خدمات تطبيق azure:

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 '- الفعل: sync -retryAttempts = 20 -verbose -e nablerule: AppOffline

2017-02-14T22: 41: 34.3837386Z رمز الخطأ: ERROR_FILE_IN_USE

2017-02-14T22: 41: 34.3837386Z مزيد من المعلومات: لا يمكن لـ Web Deploy تعديل ملف 'Ascend.Ammo.Portal.exe' على الوجهة لأنه مؤمن بواسطة عملية خارجية. للسماح لعملية النشر بالنجاح ، قد تحتاج إما إلى إعادة تشغيل التطبيق الخاص بك لتحرير القفل ، أو استخدام معالج قاعدة AppOffline لتطبيقات .Net في محاولة النشر التالية. اعرف المزيد على: 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.

أيضًا ، يبدو أنه في صفحة تنزيلات وقت التشغيل ، فقط إصدار LTS لديه الإصلاح؟

shirhatti ~ أخبرني عندما يكون رابط مثبت حزمة الاستضافة الجديد جاهزًا ، وسأقوم بتصويره في المستندات (في أماكن قليلة). ~

هل هذا هو: https://go.microsoft.com/fwlink/؟linkid=837808 ... هذا ليس رابط aka.ms tho. ~

أقوم بإعداد https://github.com/aspnet/Docs/pull/2773 لتغطية هذا إذا كان fwlink على ما يرام.

يحدث أيضًا في الاستوديو المرئي ، وكما تظهر الخيارات - قاعدة التطبيق دون اتصال بالإنترنت موجودة.

davidebbo هل يمكن أن تؤكد هل تم إصلاح هذا؟ نسمع من الكثير من الناس أنهم ما زالوا يضربون بها. هل يحتوي إصدار الإصدار من الأداة على أي إصلاح لهذا الأمر أم أنه لا يزال يمثل مشكلة في الاستضافة؟

أحاول أيضًا معرفة سبب حدوث ذلك ومتى يحدث. أنا متأكد تقريبًا من أنني رأيت أن العملية قيد التشغيل في مستكشف العمليات على موقع scm وتم نشرها على ما يرام.

أنا بصدد تحديث مواقعي إلى أحدث الأدوات أيضًا ، على أمل أن تكون المشكلة متعلقة بأدوات project.json القديمة.

تم نشر الإصلاح في Azure App Service منذ فترة ، ولست على علم بأي شخص لا يزال يرى المشكلة بعد ذلك. بالطبع ، قد يستمر المستخدمون في مضيفات غير Azure في رؤيتها إذا لم يتم تحديثها.

بالنسبة إلى Azure ، إذا كنت تواجه مشكلة ، فيرجى اختبارها على النحو التالي:

• انتقل إلى Kudu process Explorer وتأكد من تشغيل عملية التطبيق (عادةً dotnet.exe)
• إنشاء ملف app_offline.htm يدويًا (على سبيل المثال ، تشغيل touch app_offline.htm ) من أمر Kudu
• تحقق من مستكشف العمليات مرة أخرى ، وتأكد من أن هذه العملية لم تعد موجودة.

سأختبر المزيد ، هل رأيت الصورة بضع منشورات ، فهي تُظهر بوضوح أن الملف قيد الاستخدام ويستخدم التطبيق في وضع عدم الاتصال.

لكنني سأختبر كما طلبت.

أيضًا ، نحن نستخدم تطبيقات scaleout + التي تم نشرها في التطبيقات الافتراضية - لا أعرف ما إذا كان هذا يغير شيئًا.

pksorensen القيام بذلك "يدويًا" سيساعد في عزل أي شيء قد يفعله WebDeploy. على سبيل المثال ، إذا لم يؤدِ إسقاط app_offline.htm إلى إيقاف العملية ، فنحن نعلم حقًا أن هناك مشكلة لا تسببها WebDeploy.

لاحظ أنه عادةً ما ينتهي بك الأمر باستخدام عملية dotnet.exe ، بينما في حالتك لديك اسم exe مختلف. أتساءل عما إذا كان ذلك يتعلق بطريقة أو بأخرى بهذه القضية.

1. انتقل إلى Kudu process Explorer وتأكد من تشغيل عملية التطبيق (عادةً 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 نشكرك على النصيحة ، مع تعليق واحد - إذا كنت تنشر مواقع مضاعفة إلى تطبيقات افتراضية في نفس خدمة التطبيق ، فإن الفتحات (إذا كنت أتذكر بشكل صحيح) تعمل عبر كل هؤلاء ، لذلك سيتعين عليك نشر جميع المواقع من قبل مبادلة. هذا هو المتاعب. الآن يمكننا نشر أجزاء (خدمات صغيرة) للتطبيقات الافتراضية الفردية بسهولة. نظرًا لأنه يمكننا نشر هؤلاء في خدمات تطبيقات منفصلة ، ولكن بعد ذلك سنحتاج إلى تحميل موازين / بوابات أمامهم لجعلهم يشاركون نفس المجال مرة أخرى ، كما أنه يكلف المزيد من الوقت الذي نحن على استعداد للقيام به الآن.

لذلك أوافق على أن ما تقترحه هو الطريقة المفضلة ، فهو لا يناسبنا الآن. لذلك ما زلت آمل في التوصل إلى حل بشأن قضية الملف قيد الاستخدام.

pksorensen هل هناك فرصة لإنشاء نسخة في موقع وهمي ومشاركة اسمه؟ في الأساس ، أود رؤيته في الحالة التي يعمل بها موقعك ، ولا يؤدي إنشاء app_offline.htm يدويًا في وحدة تحكم Kudu إلى إيقاف تشغيله.

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' على الوجهة لأنه مؤمن بواسطة عملية خارجية. للسماح لعملية النشر بالنجاح ، قد تحتاج إما إلى إعادة تشغيل التطبيق الخاص بك لتحرير القفل ، أو استخدام معالج قاعدة AppOffline لتطبيقات .Net في محاولة النشر التالية. اعرف المزيد على: http://go.microsoft.com/fwlink/؟LinkId=221672#ERROR_FILE_IN_USE.
2017-03-30 T02: 54: 37.1860517Z عدد الأخطاء: 1.
2017-03-30T02: 54: 37.4179909Z ## [خطأ] خطأ: C: \ Program Files \ IIS \ Microsoft Web Deploy V3 \ msdeploy.exe فشل مع رمز الإرجاع: 4294967295

يؤدي إنشاء app_offline.htm يدويًا في D: \ home \ site \ wwwroot بالفعل إلى إيقاف عملية dotnet.exe.

فهل هذا يعني أن هناك مشكلة في "العرض المستمر (المعاينة)" نفسها؟

بالإضافة إلى ما سبق ، قمت بإصلاح هذا بالانتقال يدويًا إلى تعريف إصدار VSTS وخيارات النشر الإضافية ووضع علامة "Take App Offline".

لكن هذا يثير بعض الأسئلة:
لماذا لا يتم تحديد "Take App Offline" بشكل افتراضي؟ هل يجب أن يستمر هذا السيناريو في العمل (على سبيل المثال ، هل يقلل من وقت التوقف عن العمل)؟

إذا كانت الإجابة بنعم ، فلماذا فشلت؟ إذا كانت الإجابة "لا" ، فلماذا يترك "التسليم المستمر (المعاينة)" الأمر دون تحديد؟

في كلتا الحالتين - يبدو أن هناك خطأ في مكان ما.

@ Jon12345 : هذا الموضوع يدور فقط حول مناقشة ما إذا كان app_offline.htm يعمل بشكل صحيح مع التطبيقات الأساسية. لذا فإن حقيقة أن VSTS قد تفعل ذلك أو لا تفعله افتراضيًا هي بالفعل مناقشة منفصلة ، والتي يجب إجراؤها في منتدى VSTS (ربما https://social.msdn.microsoft.com/Forums/vstudio/en-US/ المنزل؟ المنتدى = TFService).

في هذه المرحلة ، يبدو أن معظم الأشخاص قد تم إلغاء حظرهم بعد الإصلاح. كان هناك تقرير واحد عن أنه لا يعمل بواسطة pksorensen ، ونحن ننتظر تطبيق repro للنظر فيه.

ما زلت أحصل على هذا في تحديث TFS 2017 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 وكان يحدث طوال اليوم ، لذلك أود أن أقول باستمرار. هل لديك أي أفكار أخرى عما يمكن أن يسبب هذا؟

ليس صحيحا. سأترك خبراء ANCM يعلقون على كيفية قيامهم بمراقبة تغيير الملفات ، وإذا كان بإمكانهم التفكير في سبب عدم اكتشاف الإنشاء الأولي.

davidebbo أواجه نفس المشكلة بالضبط. يمتلك فريقي بنية وهمية تنسخ ملفًا AppBuild.htm من خادم الإنشاء إلى الموقع المستهدف مثل app_offline.htm. نحاول بعد ذلك استخدام msdeploy لمزامنة المجلد وفتحه بخطأ عملية آخر. إذا لمست الملف ، أعد تسمية الملف من app_offline.htm إلى app_offline.htm.rename والعودة مرة أخرى ، أو الكتابة فوق app_offline.htm باستخدام File Explorer ثم تتوقف العملية بشكل صحيح. ليس من المنطقي تمامًا سبب عدم نجاحه من خلال البرنامج النصي الخاص بنا ولكنه يعمل إذا قمنا بذلك يدويًا.

تحديث: وجدنا أن تحديث وقت الكتابة الأخير يبدو أنه يؤدي إلى إيقاف التشغيل باستمرار:

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 Console
• قم بتشغيل touch app_offline.htm في D:\home\site لإنشاء ملف فارغ في مجلد مختلف
• قم بتشغيل copy app_offline.htm wwwroot . لاحظ أن هذا يحافظ على وقت الكتابة الأخير ويحدّث وقت الإنشاء (سلوك نسخ الملف القياسي).

النتيجة: يتم إيقاف تشغيل عملية dotnet.exe على الفور (يمكنك التحقق باستخدام Kudu process Explorer).

هل تعمل هذه الخطوات نفسها معك؟ إذا كان الأمر كذلك ، ما الذي قد يكون مختلفًا في سيناريو repro الخاص بك؟

في الواقع ، كان يجب أن أضيف أيضًا أن هذه المشكلة كانت متقطعة وأننا نستخدم IIS 8 على Windows Server 2012.

كان هدفي هذا الصباح هو معرفة ما إذا كان بإمكاني إعادة إنتاج المشكلة باستخدام برنامج powerhell أو نص برمجي دفعة قبل إعداد Kudu Console ، ولكن بعد الاختبار لأول مرة باستخدام برنامج اختبار Fake build script الذي كان فريقي يستخدمه يوم الجمعة لإنشاء ملف app_offline.htm في بطرق مختلفة (نسخ ملف موجود ، إنشاء ملف جديد ، إلخ) ، إنه يعمل حاليًا. هذا يعكس نمط إخفاقات البناء لدينا وكذلك حيث تم إغلاق العملية في بعض الأحيان وأوقات أخرى لا. عندما تبدأ بالفشل ، يبدو أنها تفعل ذلك باستمرار. اختبرناها لساعات يوم الجمعة ولن يتوقف الأمر باستمرار مع إنشاء Fake بسيط لم يفعل شيئًا على الإطلاق باستثناء إنشاء ملف app_offline.htm جديد. يجب أن أضيف أيضًا أننا سننشئ الملف يدويًا بشكل دوري ونرى توقف العملية ، لذلك لا يبدو أن هناك أي نوع من المواقف حيث لن يتم إيقاف العملية بعد فترة طويلة من الاستخدام.

عندما يمكنني إعادة إنتاج المشكلة مرة أخرى ، سأرى ما إذا كان إنشاء الملف باستخدام بوويرشيل و / أو ملف دفعي لا يزال يعكس المشكلة.

davidebbo حسنًا ، حماقة ... لقد لاحظت للتو أنني نسيت التعليق على سطر كان يقوم بتحديث وقت التحديث الأخير ، لذلك لا يزال يظهر نفس السلوك بالفعل. سأحاول مع بوويرشيل وملف دفعي الآن وأقوم بتحديثك.

تضمين التغريدة

اسف لخلط الامور. حسنًا ، هذا ما وجدته:

يبدو أن استخدام ملف دفعي بالمحتويات التالية يتسبب بشكل موثوق في إيقاف العملية:

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

يؤدي استخدام نص برمجي مكافئ إلى إيقاف العملية بشكل موثوق:

#!/bin/bash

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

يبدو أن استخدام برنامج نصي بوويرشيل بالمحتويات التالية لا يؤدي إلى إيقاف العملية مطلقًا:

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

بالنظر إلى أن كلاً من Fake و Powershell يعملان تحت CLR بينما الأمر DOS copy و bash و Kudu Console لا يعملان ، يبدو أن هذا يشير إلى شيء يتعلق بالملف الذي يتم إنشاؤه من خلال CLR.

الشيء الغريب هو أنني لا أرى أي اختلافات في الطوابع الزمنية لإنشاء / تحديث الملف الناتج بين الإصدارات المختلفة.

derekgreer أوه ، إذن أنت لا تعمل على خدمة تطبيقات Azure على الإطلاق. هذه هي الزاوية الخاصة بي في هذه الملحمة بأكملها ، لذلك سأترك مستخدمي ASP.NET يعلقون أكثر على هذا.

على الرغم من ما يستحقه ، لم أتمكن من إعادة عرضه في خدمة التطبيق:

• استخدم وحدة تحكم PowerShell الخاصة بـ Kudu
• انتقل إلى مجلد site \ wwwroot
• تشغيل New-Item app_offline.htm -type file

moozzyk ، هل يمكنك المساعدة في التحقيق في خدمة التطبيق الخارجية derekgreer ؟

مزيد من المعلومات:

منذ الإنشاء والنسخ وإعادة التسمية وما إلى ذلك من خلال File Explorer يعمل باستمرار ، قررت معرفة ما إذا كان تطبيق مستكشف الملفات المستند إلى .Net يعكس نفس النتائج التي أراها مع Fake و PowerShell. هناك مستكشف ملفات قائم على الشبكة يسمى "Nomad" والذي انتهى بي الأمر بالتنزيل والاختبار معه وكانت النتائج متوافقة مع 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".

أتساءل عما إذا كانت واجهة برمجة تطبيقات .Net المشتركة بين Fake و PowerShell و Nomad لا تؤدي إلى تشغيل هذه العلامات الأخرى بنفس طريقة إنشاء الملف العادي.

shirhatti ، هل يمكنك التأكد من أن شخصًا ما يحقق في مشكلة ANCM المحتملة هذه؟

تضمين التغريدة ونحن نتطلع الى ذلك

لدي مشكلة مشابهة جدا. إذا قمت بنسخ ملف app_offline.htm في مستكشف Windows ، فسيوقف العملية بشكل صحيح ، ولكن إذا قمت بإنشائه باستخدام 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 فقط لبعض طرق إنشاء الملف ، وهو يمسك هذا الخطأ.

تضمين التغريدة
أنا أبحث في القضية الآن. باستخدام أحد أوامر repro الخاصة بك في جهاز الاختبار الخاص بي ، تمكنت من إعادة إنتاج هذه المشكلة. لقد استخدمت الأمر أدناه. (ملاحظة: سيقوم الأمر أدناه بإنشاء ملف فارغ (حجم الملف صفر).

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"

هل يمكنك تأكيد ما إذا كنت ترى نفس الأعراض في بيئة repro الخاصة بك؟
إذا كان الأمر كذلك ، أعتقد أن هذه المشكلة تحدث فقط عندما يتم إنشاء app_offline.htm الفارغ بطريقة خاصة مثل استخدام الأمر بوويرشيل new-item.

تضمين التغريدة
لا يمكنني إعادة إنتاج هذه المشكلة باستخدام أمر النسخ. هل يمكنك شرح شيء أكثر تفصيلاً من كتابك؟ سيكون من الرائع أن تجد بعض خطوات إعادة المحاولة التي يمكنني من خلالها إعادة إنتاج نفس المشكلة على جهاز الاختبار الخاص بي.

يمكنني أن أؤكد أنه لا يتعلق بما إذا كان ملف 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 .

سم مكعب: @ عموم وانغ

shirhatti آه ، فهمت الآن. لم أكن أعلم أن العلم يغطي إنشاء التغيير. لدي فضول ، هل تمكنت من إعادة إظهار المشكلة؟

تم إصلاح عدم الرد على app_offline.htm الفارغ: https://github.com/aspnet/IISIntegration/issues/174

moozzykderekgreer شكرا على التأكيد. حسنًا ، وجدت أيضًا أن المشكلة لا تتعلق مباشرة بمحتوى الملف الفارغ. سأقوم بتحديثك بعد معرفة السبب الجذري.

jhkimnew ليس لدي الإعداد المعطل بالضبط بعد الآن ، لكن يمكنني وصف التفاصيل:

• يعمل IIS على windows server 2008 r2 ، ويستضيف تطبيق asp.net الأساسي باستخدام ANCM
• بناء الخادم هو أيضا 2008r2 ، على نفس المجال
• يحتوي خادم IIS على دليل موقع الويب الفعلي الخاص به المشترك باستخدام مشاركة Windows
• يقوم مستخدم المجال (حساب خادم الإنشاء) بتشغيل برنامج نصي بوويرشيل على خادم الإنشاء
  إذا كان هذا البرنامج النصي يستخدم الأمر windows copy لنسخ في app_offline من ملف موجود في دليل آخر ، فلن يتم إيقاف تشغيل عملية الاستضافة. إذا كان البرنامج النصي يستخدم بدلاً من ذلك "echo" (والذي قد يكون / bin / echo من تثبيت mingw ، لست متأكدًا) عندئذٍ يتم إيقاف عملية الاستضافة.

أظن أن المشكلة تتعلق تحديدًا بسمات الملف التي يتم تحديثها أو لا يتم تحديثها بواسطة هذا النوع من النسخ البعيدة

gulbanana فقط لكي أكون واضحًا ، حاولت باستخدام الأمر dos copy وليس الأمر commandlet الخاص بنسخ العنصر power shell؟ لا أعتقد أنني جربت نسخة دوس العادية ، لكنني وجدت أن أي تطبيق يستند إلى .net استخدمته لا يعمل.

ما لم يكن بوويرشيل له اسم مستعار لذلك ، كان نسخة دوس

في حالتي ، لن تقوم نسخة PowerShell بإيقاف تشغيل عملية dotnet.exe ، ولكن يعمل echo ، وهو اسم مستعار لـ Out-Content. أشعر أنه من غير المحتمل أن تكون مشكلة في .NET ، ولكن هناك المزيد بخصوص سبب عدم عمل نسخة الشبكة

لقد قمت بالتحقيق في ما إذا كانت هناك أي مشكلة في إخطار تغيير aspnetcore.dll (ANCM) ، لكنني لم أتمكن من إعادة إنتاج المشكلة عندما حاولت إسقاط app_offline.htm يدويًا إما باستخدام بوويرشيل cmdlet أو أمر DOS. ووجدت نقطة واحدة مفقودة لم تتم مناقشتها هنا.
هذا هو حول الإغلاق الرشيق. على عكس HttpPlatformHandler "، يدعم ANCM الإغلاق الرشيق ، مما يعني أنه عندما يتم إسقاط app_offline.htm في الدليل الجذر ، يرسل ANCM إشارة Crtrl-C / Break إلى عملية الواجهة الخلفية وينتظر حتى 10 ثوانٍ للسماح بحدوث الإغلاق الرشيق.
10 ثوانٍ هي القيمة الافتراضية ويمكن للمستخدمين ضبط القيمة باستخدام shutdownTimeLimit لإعدادات تكوين ANCM. إذا لم يتم إيقاف تشغيل عملية الواجهة الخلفية في shutdownTimeLimit الذي تم تكوينه ، فمن المفترض أن يقتل ANCM عملية الواجهة الخلفية.

أثناء التحقق من كيفية ارتباط نشر MSDeploy بإغلاق ANCM الرشيق ، وجدت أخيرًا خطوة واحدة متسقة ، وهي زيادة وقت إيقاف التشغيل (5 ثوانٍ) ولاحظت أن MSDeploy يعيد المحاولة مرتين فقط افتراضيًا وينتظر ثانيتين فقط ويفشل في النهاية في النشر لأنه لا ينتظر وقت الإغلاق الرشيق.

تضمين التغريدة
بعد أن قمت بتأخير 5 ثوانٍ لكل من مكان بدء تطبيق الويب aspnetcore وإنهائه ، تمكنت من إعادة إنتاج نفس الخطأ ، الذي تم الإبلاغ عنه في هذه المشكلة ، في التجربة الثانية لنشر تطبيق الويب aspnetcore على خادم 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 مرات مع تأخير لمدة ثانية واحدة بينهما.
<RetryAttemptsForDeployment>10</RetryAttemptsForDeployment>

تضمين التغريدة

اشكرك على المعلومات. بعد إضافة السطرين أدناه ، لا أرى أي مشكلة في نفس بيئة repro.
<EnableMSDeployAppOffline>True</EnableMSDeployAppOffline> <RetryAttemptsForDeployment>10</RetryAttemptsForDeployment>

لذلك ، سيحتاج أي شخص يواجه مشكلة مماثلة إلى زيادة عدد RetryAttemptsForDeployment بقيمة مناسبة والمحاولة مرة أخرى إذا كان ذلك يمكن أن يحل المشكلة.

ملاحظة: سبب إضافة EnableMSDeployAppOffline هو تعطيل ذلك افتراضيًا عند استخدام خادم IIS المحلي كوجهة لنشر تطبيق ويب aspnetcore. لذلك ، إذا لم تكن متأكدًا مما إذا كان ذلك ممكّنًا أم لا في بيئتك ، فستحتاج فقط إلى إضافة السطر أيضًا ولهذا السبب أضفته هنا لمعلوماتك.

فقط للتأكد من عدم ضياع المشكلة الأصلية بسبب المناقشات الأخيرة ، فإن المشكلة التي واجهها فريقي ليست بالتأكيد مشكلة توقيت. لقد اختبرنا إنشاء ملف app_offline.htm يدويًا من خلال كل من مستكشف الملفات Powershell و Fake و .Net المسمى "Nomad" ولا يتم إيقاف العملية بغض النظر عن المدة التي تنتظرها. يؤدي إنشاء الملف من خلال File Explorer ، أو ملف دفعي DOS ، أو برنامج نصي bash (أي العمليات غير المستندة إلى مكتبة .Net) إلى إيقاف العملية في غضون 1-2 ثانية.

يبدو أن هذا يشير إلى:

1. المشكلة ليست متعلقة بالشبكة (تم إجراء جميع الاختبارات على مشاركة ملف بعيد)
2. إنها ليست مشكلة إغلاق / توقيت رشيق

حقيقة أن 3 طرق غير شبكة لإنشاء ملف app_offline.htm تؤدي إلى إيقاف العملية بشكل موثوق وسريع وأن الأساليب القائمة على مكتبة الشبكة لإنشاء الملف لا تؤدي أبدًا إلى إيقاف العملية في اختباراتنا يبدو أنها حقًا ، مؤشر كبير بالنسبة لي.

تضمين التغريدة
لا يمكنني إعادة إظهار المشكلة حتى مع "البدوي".
هذا ما فعلته على جهاز Windows 10 (amd64).

1. قم بتثبيت IIS
2. قم بتثبيت Visual Studio 2017
3. قم بإنشاء تطبيق ويب AspnetCore ونشره على خادم IIS المحلي باستخدام MSDeploy
4. قم بتثبيت Nomad v3.2.0.2890 (http://www.nomad-net.info/downloads)
5. أرسل طلبًا إلى تطبيق الويب
6. افتح إدارة المهام وتأكد من تشغيل عملية dotnet.exe
7. افتح Nomad وأنشئ ملفًا جديدًا باسم app_offline.htm في الدليل الجذر لتطبيق الويب
8. راجع إدارة المهام وتحقق من اختفاء عملية dotnet.exe عند إنشاء ملف app_offline.htm

هل ستعطي خطوات إعادة المحاولة الدقيقة حتى أتمكن من اتباعها لإعادة إظهار المشكلة؟

بصرف النظر عن حقيقة أن تطبيق .Net Core الخاص بنا هو في الواقع تطبيق قياسي .Net 4.5.2 Console تم إنشاؤه في VS 2015 والذي يشير إلى تجميعات ASP.Net Core ، لا أرى أي فرق. يبلغ عمر المشروع الآن حوالي عام وقد تم إعداده بهذه الطريقة في ذلك الوقت بسبب القيود المفروضة على الإشارة إلى أنواع مشاريع القوالب الأساسية من أنواع مشاريع قوالب إطار الشبكة وأنواع مختلفة من دعم مكتبة الاختبار لـ .Net core.

حددنا مشكلتين: 1) إسقاط ملف app_offline.htm (باستخدام بعض الأدوات) يؤدي أحيانًا فقط إلى تشغيل إشعار تغيير خاصية الملف الذي تمت تصفيته بواسطة ANCM. 2) قد يفشل ANCM في قراءة app_offline.htm حيث تم احتجاز الأخير بواسطة أداة نسخ الملف. 3) تسبب الإغلاق الرشيق في تأخير إنهاء عملية الواجهة الخلفية.
سوف نتناول أول مسألتين في الإصدار القادم. لحالة إيقاف التشغيل الرائعة ، يحتاج المستخدم إلى إعادة المحاولة.

يبدو ذلك جيدا. لم تكن حالتي بالتأكيد تتعلق بمهلة إغلاق رشيقة - عندما تتوقف ، تتوقف على الفور.

أي تعديل حدث في هذه القضية؟
محاولة نشر تطبيق ASP.NET Core 1.1 في فتحة تطبيق Azure Web باستخدام VSTS

• لدي MSDEPLOY_RENAME_LOCKED_FILES=1 تم تعيينه في إعدادات التطبيق
• تم تكوين "إدارة مهمة خدمة التطبيق" لجعل التطبيق في وضع عدم الاتصال
• تم تكوين مهمة "نشر خدمة التطبيق" لجعل التطبيق في وضع عدم الاتصال ، ولكن هذا لم ينجح أيضًا

المشكلة الأساسية هي أن DLL قيد الاستخدام:

ChuckkNorris الرجاء مراجعة https://github.com/Microsoft/vsts-tasks/issues/1607 للحصول على أحدث المعلومات حول هذا.

@ davidebbo شكرًا على ردك يا ​​ديفيد. لقد رأيت هذا الخيط وهذا هو المكان الذي اكتشفت فيه العديد من الحلول التي جربتها.

نظرًا لأن هذه المشكلة لا تزال مفتوحة ولا يزال الخطأ سائدًا ، كنت آمل أن يكون هناك إصلاح قريبًا ، وليس حلًا آخر. ظلت هذه القضية مفتوحة لأكثر من عامين حتى الآن بعد كل شيء.

ChuckkNorris بينما الأعراض هي نفسها ، هذه ليست نفس المشكلة:

• الإصدار الأصلي المتعلق بغلاف app_offline.htm ، مما تسبب في تجاهله تمامًا. تم إصلاح ذلك لفترة من الوقت.
• بدأت هذه المشكلة الجديدة منذ أسبوع أو نحو ذلك ، وتحدث لأن Core الآن يستغرق وقتًا أطول لإغلاقه عند إنشاء app_offline.htm ، ولن تنتظر msdeploy بشكل افتراضي طويلاً بما يكفي. الحل هو زيادة عدد مرات إعادة المحاولة.

لقد قمت للتو بتحديث VS 2017 إلى 15.3 وقمت بتثبيت .NET core 2.0 SDK. إنشاء تطبيق MVC بسيط في VS - كان يستهدف 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 ، هل يمكننا الحصول على إغلاق لهذه المشكلة؟
على الرغم من إضافة مساعد إعادة المحاولة لنشر الويب ، إلا أن هذه المشكلة لا تزال قائمة.

أردت فقط الإشارة إلى ما هو واضح ، أن هذا يؤثر على نشر FTP أيضًا.

jeremycook FTP مختلف قليلاً ، لأنه لا يحتوي على أتمتة لاستخدام App_Offline. ستحتاج إلى إنشاء هذا الملف يدويًا لإيقاف العملية ، وبعد ذلك يمكنك نسخ الملفات.

davidebbo عادل بما فيه الكفاية ولكن يبدو أنني إذا قمت بالنشر عبر FTP باستخدام ميزة نشر Visual Studio ، يجب أن تعمل فقط. ربما أقوم بالنشر في المكان الخطأ؟

jeremycook بصراحة ، لست متأكدًا مما يفعله VS عند نشر FTP. ربما يمكن للآخرين التألق ، لكن يبدو أنه سؤال VS أكثر من ASP.NET.

على الرغم من العزل ، سيكون من المثير للاهتمام اختبار ما إذا كان النشر ناجحًا إذا قمت بإنشاء App_Offline.html يدويًا ، ثم نشر FTP من VS.

vijayrkn هل يمكنك التعليق على سلوك VS أثناء نشر FTP؟

نشر FTP من VS إلى خدمة التطبيق لا يدعم App_Offline.

vijayrkn حسنًا ، لذلك لجميع الأغراض العملية ، يمكننا القول أن نشر .NET Core عبر FTP غير مدعوم ، ما لم يوقف المستخدم الموقع صراحة قبل النشر. حق؟

davidebbo - نعم ، هذا صحيح.

ضرب هذه المشكلة عند نشر تطبيق الويب asp.net core 2.0 على IIS من إصدار VSTS باستخدام قالب نشر ويب IIS. فشل الحذف بسبب الملف قيد الاستخدام. تم تمكين خيار التطبيق دون اتصال.

Davidebbovijayrknshirhatti هذا كل شيء محبط بعض الشيء. هل هناك خطط لتشغيل FTP / XCOPY؟ هل يجب فتح إصدار جديد يركز على نشر الطرق القديمة عبر FTP / XCOPY / ROBOCOPY / إلخ؟

لقد تأخرت عن هذه الحفلة ولكن إليك بعض الأجزاء التي أريد الإبلاغ عنها:
VS 2017 إنتربرايز
asp.net 4.6.xx
الخادم هو IIS 8.5 على الخادم 2012 R2
يتم تأمين أنواع خادم dlls لأنواع خوادم SQL ويكون القفل على هذا النحو عندما يقوم مطور آخر بالنشر باستخدام msdeploy يحصل على خطأ ويكون موقع الويب الآن معطلاً كجزء من عملية النشر فقط.

يتم تأمين أنواع dlls من نوع sql في مجلد حاوية التطبيق وفقطهم.
إعادة تسمية ملفات dll وبعد ذلك يمكنني النشر.
تحتوي عبوة أنواع SQL على رمز مختزل لتحميل ملفات dlls غير المُدارة.
يبدو أنه يجب تغيير ذلك لعدم قفلها. إذا كان ذلك ممكنًا.

لقد رأيت أشخاصًا يتحدثون عن طرق لإعادة تشغيل الموقع أو إيقاف تشغيله ولكني لم أجد إعدادًا في msdeploy لذلك. xml الذي رأيته ليس في ملفاتي.

يجب إضافة إرشادات أفضل إلى حزمة أنواع SQL التي تنشرها Microsoft.

النشر حول هذه المسألة حيث يبدو أنها مرتبطة بشكل مباشر أكثر بقضيتي. لقد تابعت أيضًا المشكلة أدناه حول نفس الموضوع على الرغم من أنها خاصة بـ VSTS. أنا أنشر مباشرة من الاستوديو المرئي.

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

لقد كانت هذه مشكلة في وضع التشغيل وإيقاف التشغيل بالنسبة لي ولكنها عادت مؤخرًا سارية المفعول وعلى أحد مواقع خدمة التطبيقات الخاصة بي ، تلقيت هذا الخطأ في جميع محاولات النشر تقريبًا. هذا الموقع مستضاف على مستوى خدمة "أساسي" لذا ليس لدي فتحات أستخدمها في تطبيقات أخرى للتغلب على هذه المشكلة.

هذا لتطبيق .net core 2 mvc.

فكرة واحدة: بعض الملفات التي تعد جزءًا من تطبيق ويب لا يتم تغييرها في كل عملية نشر (مثل أنواع SQL)
لكن نشر ms يحاول استبدالها في كل عملية نشر.
يبدو أن نوعًا من الفحص يجب أن يحدث لعدم إعادة نسخ ملف لم يتغير ، وهذا من شأنه أن يجعل التحديث أصغر وأسرع وأقل حاجة للتلاعب بقفل الملف.
فوائد متعددة إذا كان ذلك ممكنًا.

الشيء الآخر هو تحديد ما هو قفل الملف بشكل أفضل ولماذا وكيفية التراجع عن ذلك.
والحصول على ذلك كجزء من خط أنابيب النشر القياسي.

figuerres كنت أرغب في التعامل مع هذه المشكلة منذ شهرين الآن. عادةً ما يتم تجنب مشكلات التأمين بسبب النسخ الاحتياطي ، ولكن عن طريق تحميل مكتبات DLL الأصلية من ~/bin ، يتم إنشاء مشكلة تأمين. لدي حل محتمل ، لكنني لست متأكدًا مما إذا كان حلاً آمنًا تمامًا: https://stackoverflow.com/questions/47796553/is-it-safe-to-manually-copy-native-dlls-to- a-shadow-copy-directory

أوافق على أن الوثائق الخاصة بحزمة NuGet يجب أن توفر طريقة أفضل ، طريقة لا تسبب مشكلات في القفل.

figuerres FYI ، لقد قمت بتنفيذ ما ورد أعلاه ، راجع سؤال Stack Overflow للتعرف على الكود.

اقتل dotnet.exe في إدارة المهام

ما هي الحالة هنا؟ بعد 3 سنوات ، ما زالت غير ثابتة. يجب أن أذهب يدويًا إلى الخادم وأوقف موقع الويب.

3 سنوات؟ تم الإبلاغ عن هذه المشكلة في أغسطس من عام 2017. تم إيقاف بنسبة 1 مثل قف.
يوم الاثنين 23 أبريل 2018 الساعة 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
.

الرسالة الأولى تقول "فتحت بيكه هذا العدد في 23 حزيران (يونيو) 2015"

أنت على حق. خطأي. رأيت فقط الطابع الزمني الأخير في سلسلة البريد الإلكتروني.
يوم الاثنين 23 أبريل 2018 الساعة 9:06 مساءً Oliver Janik [email protected]
كتب:

الرسالة الأولى تقول "pekkah تم التعليق في 23 Jun 2015"

-
أنت تتلقى هذا لأنك علقت.

قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/aspnet/Home/issues/694#issuecomment-383769982 ، أو كتم الصوت
الخيط
https://github.com/notifications/unsubscribe-auth/AAXhfgwYG-jLjnoJF7MCMtzbbfxSZkt2ks5trnqXgaJpZM4FJp_R
.

يتم الإغلاق لأن هذا قديم قدم التراب 😄

Eilon آسف ، ولكن لماذا تم إغلاق هذا؟ لا يزال دون حل؟

يتم الإغلاق لأن هذا قديم قدم التراب 😄

لكنها ما زالت مشكلة ..؟ (حتى في حالة عدم وجود أزور)

إنشاء عدد جديد (# 3719) لزيادة الرؤية.