Aspnetcore: फ़ाइल उपयोग में होने के कारण परिनियोजन विफल हो जाता है

मैंने Azure VM पर IIS फ़ाइल लॉकिंग के साथ एक समान समस्या देखी, जिसने WebDeploy परिनियोजन को रोका। मेरा समाधान तीन वेब डिप्लॉय कमांड जारी करना है: ऐपपूल को रोकें, तैनात करें, ऐपपूल को पुनरारंभ करें। मेरी स्क्रिप्ट देखें; और यदि आपके पास तीन WebDeploy कमांड चलाने की क्षमता है, तो आप Azure Apps के साथ भी कुछ ऐसा ही करने में सक्षम हो सकते हैं।

बीटा 6 में यह समस्या आ रही है।

मेरा भी यही विचार है! यह मेरे विजुअल स्टूडियो 2015 को वास्तव में फ्रीज करने का कारण बनता है - मेरे vNext ऐप को प्रकाशित करते समय (बीटा 6 और बीटा 7 दोनों मुझे लगता है)।

क्या आप परिनियोजन करने के लिए Microsoft द्वारा प्रदान की गई स्क्रिप्ट का उपयोग कर रहे हैं? यदि ऐसा है, तो आप वेब ऐप को पुनः आरंभ करने के लिए PublishAspNet5Website.ps1 में बस एक पंक्ति जोड़ सकते हैं:

Restart-AzureWebsite -Name $websiteName

मेरे पास इस पोस्ट में उल्लिखित मेरी बिल्ड स्क्रिप्ट संशोधन हैं: Azure वेब ऐप स्लॉट में ASP.NET 5 परिनियोजन समस्या का समाधान करें

@brandonmartinez , एक वेबसाइट को पुनरारंभ करने से मदद नहीं मिलेगी, क्योंकि एक उत्पादन वेबसाइट को अनुरोध प्राप्त होते रहेंगे, जो इसलिए फाइलों को फिर से खोल देगा। वर्तमान में, IIS और Azure दोनों वेबसाइटों को अपडेट करने का एकमात्र विश्वसनीय तरीका वेब साइट के एप्लिकेशन पूल को बंद करना है, फिर फ़ाइलों को अपडेट करना है, और फिर वेबसाइट को पुनरारंभ करना है। अधिक जानकारी के लिए बस @GuardRex के लिंक का अनुसरण करें।

हालाँकि, हमें VS2015 के साथ डिफ़ॉल्ट परिस्थितियों में काम करते समय कस्टम परिनियोजन स्क्रिप्ट के बारे में बताने की आवश्यकता नहीं है।

उम्मीद है कि नया HttpPlatformHandler इंफ्रास्ट्रक्चर (जिसे अब AspNet.Loader.dll की आवश्यकता नहीं है) थोड़ा और क्षमाशील होगा, लेकिन मैं यहां अपनी सांस नहीं रोक रहा हूं। हम शायद एक और लॉक .dll प्राप्त करेंगे।

@rubenprins वीएस में एज़ूर एसडीके टूल्स के माध्यम से मैं जिस कामकाज का उपयोग करता हूं वह भी है।

ऐसा करने के लिए PS कमांड हैं यदि आप PS को VM तक पहुंच प्राप्त कर सकते हैं। https://github.com/GuardRex/net5-iis-ps-publish/blob/7623122dbfdc55a7c53c8edd2e97443e0eea22c9/net5-iis-ps-publish.ps1#L389 -L396

aspnet/vsweb-publish भी बहुत दिलचस्प है; हालांकि, ऐसा लगता है कि यह offline-template.html का उपयोग करता है, और मुझे लगा कि यह पता चला है कि यह विधि डीएल लॉकिंग समस्या को नहीं रोकेगी ... केवल ऐपपूल को रोकना, तैनात करना और ऐपपूल को पुनरारंभ करना एक स्थिर रहा है, काम करने का तरीका।

VS2015 के साथ डिफ़ॉल्ट परिस्थितियों में काम करते समय हमें कस्टम परिनियोजन स्क्रिप्ट के बारे में बात करने की आवश्यकता नहीं है

हालांकि मेरे साथ एक बात हुई है: 'फाइल सिस्टम में प्रकाशित करें' का उपयोग करने में सक्षम होने और प्रकाशन के ठीक बाद एक स्क्रिप्ट को हुक करने में सक्षम होने के कारण इसमें MSDeploy बिट्स हैं जो कई वीएम के लिए बहुत ही सरल और उपयोगी परिनियोजन कहानी को सक्षम करता है। चूंकि स्क्रिप्ट को क्रमिक रूप से निष्पादित किया जाता है, इसलिए यह लाइन के ठीक नीचे VM-to-VM जाता है। एक अच्छा कॉफी ब्रेक बनाता है। :मुस्कुराओ:

मेरे पास एक सवाल है कि एज़्योर रिसोर्स मैनेजर टीम के साथ एज़्योर रिसोर्स मैनेजर का उपयोग करके एक इंटरनेट फेसिंग लोड बैलेंसर को कॉन्फ़िगर करना शुरू करें, जिसमें लोड बैलेंसर को अस्थायी रूप से वीएम को ट्रैफ़िक भेजना बंद करने के बारे में बताया जाए।

वैसे भी ... उस विषय पर वापस आना जो @pekkah ने उठाया था। चूंकि हम जानते हैं कि पीएस कमांड काम करते हैं, इसलिए वीएसओ बिल्ड में उन्हें निष्पादित करने के विकल्पों की जांच करें:

Microsoft/vso-एजेंट-कार्य
अपनी निर्माण प्रक्रिया में एक स्क्रिप्ट चलाएँ
Azure कंटीन्यूअस डिप्लॉयमेंट बिल्ड प्रक्रिया के लिए टीम फाउंडेशन सर्विस (विजुअल स्टूडियो ऑनलाइन) में प्री-बिल्ड स्क्रिप्ट चलाना
विजुअल स्टूडियो ऑनलाइन में नई बिल्ड ऑटोमेशन सुविधाएं

... हाँ ... ऐसा कुछ आपके लिए काम करना चाहिए ।

वही समस्या है...

अभी भी एक आधिकारिक समाधान की प्रतीक्षा कर रहा है

ब्रूनो

इसका समाधान https://github.com/aspnet/IISIntegration/issues/81 द्वारा किया जाएगा।

@moozzyk , वह समस्या केवल msdeploy जैसे समर्पित टूलिंग के माध्यम से परिनियोजन को ठीक करेगी। Xcopy/फ़ाइल सिंक परिनियोजन अभी भी संभव नहीं होगा, जो कई 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 में अभी एक बग है। उन्होंने Azure के लिए app_offline.htm कार्यक्षमता जोड़ी है लेकिन जब आप स्थानीय रूप से परिनियोजित करते हैं तो यह डिफ़ॉल्ट रूप से अक्षम हो जाती है। अपनी प्रकाशित प्रोफ़ाइल खोलने का प्रयास करें (PublishProfiles->*.pubxml) और बदलें:

<EnableMSDeployAppOffline>False</EnableMSDeployAppOffline>

प्रति

<EnableMSDeployAppOffline>True</EnableMSDeployAppOffline>

अगर यह काम नहीं करता है तो पूछें @vijayrkn

यदि आप किसी msdeploy प्रोफ़ाइल का उपयोग करके प्रकाशित करने के लिए VS टूलिंग का उपयोग कर रहे हैं, तो यह गुण स्वचालित रूप से आपके 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

-ई नेबलरूल: कमांड में ऐपऑफ़लाइन को तैनाती के दौरान ऐपऑफ़लाइन को जोड़ने का ध्यान रखना चाहिए।

यदि कस्टम ऐपऑफ़लाइन सामग्री की आवश्यकता है, तो आप इस संपत्ति को pubxml में सेट कर सकते हैं।

<AppOfflineTemplate>Path to app offline</AppOfflineTemplate>

वह गुण _not_ .pubxml फ़ाइल में मौजूद था जिसे Visual Studio ने बनाया था। तो मैंने इसे जोड़ा लेकिन यह कुछ भी नहीं बदला। -e nablerule:AppOffline तर्क आउटपुट विंडो में _not_ प्रकट होता है।

क्या आप आउटपुट विंडो में प्रदर्शित msdeploy कमांडलाइन साझा कर सकते हैं?

साथ ही, क्या आप पुष्टि कर सकते हैं कि pubxml में 'MSDeploy' के रूप में WebPublishMethod है।
<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]

मैं वीएसटीएस में "एज़ूर वेब ऐप परिनियोजन" कार्य का उपयोग कर रहा हूं, जैसा कि इस ब्लॉग पोस्ट में वर्णित है: http://donovanbrown.com/post/2016/05/30/DevOps-for-ASPNET-Core-RC2

क्या उस विधि का उपयोग करके <EnableMSDeployAppOffline>True</EnableMSDeployAppOffline> निर्दिष्ट करने का कोई तरीका है?

नमस्ते, मेरे पास Azure में एक ही समस्या थी, मैंने इस तरह से हल किया https://github.com/davidebo/WAWSDeploy/issues/14

@ dg9ngf पॉवरशेल स्क्रिप्ट के वर्तमान संस्करण में, हम केवल WebPublishMethod - 'MSDeploy' के लिए ऐपऑफ़लाइन का समर्थन करते हैं।

फ़ाइल सिस्टम प्रकाशन के लिए AppOffline समर्थन अगली रिलीज़ में उपलब्ध होगा।

@bojingo मैं उसी स्थिति में हूं। क्या आपने यह पता लगाया?

@davenewza : यदि आप उस ब्लॉग पोस्ट पर दोबारा जाते हैं, तो समाधान टिप्पणियों में है।
http://donovanbrown.com/post/2016/05/30/DevOps-for-ASPNET-Core-RC2

मूल रूप से आपको साइट को रोकने/शुरू करने के लिए VSTS चरणों को जोड़ने की आवश्यकता है। एक आदर्श समाधान से बहुत दूर (वास्तव में, काफी लंगड़ा), खासकर जब से मैं तैनाती स्लॉट का उपयोग नहीं कर रहा हूं, लेकिन यह हमारे देव/परीक्षण पर्यावरण के लिए ठीक काम करता है।

वेब ऐप परिनियोजन VSTS कार्य का एक नया पूर्वावलोकन ARM संस्करण है जो msdeploy- आधारित है और इसे ठीक करने का वादा करता है, लेकिन मुझे इसके साथ भाग्य नहीं मिला क्योंकि मुझे ग्राहक को सदस्यता के लिए एक सेवा प्रिंसिपल बनाने की आवश्यकता थी, और वह एक परेशानी थी। शायद आप इसे काम पर ला सकते हैं:
https://github.com/Microsoft/vsts-tasks/tree/master/Tasks/AzureRmWebAppDeployment

@vijayrkn VS2015 में वेब प्रकाशित करें संवाद में msdeploy सेट करने का कोई विकल्प नहीं है - केवल WebPublishMethod=FileSystem.

क्या आप कृपया WebPublishMethod=msdeploy के लिए एक नमूना .pubxml प्रदान कर सकते हैं?

@tomfanning ASP.NET कोर कंसोल एप्लिकेशन के लिए, वर्तमान में उपलब्ध एकमात्र प्रकाशन विकल्प फाइल सिस्टम है। क्या आप कंसोल एप्लिकेशन प्रकाशित करने का प्रयास कर रहे हैं? एक वेब ऐप के लिए, ये सभी 4 विकल्प उपलब्ध होने चाहिए (वेब ​​परिनियोजन, वेब परिनियोजन पैकेज, फ़ाइल सिस्टम और एफ़टीपी)।
नमूना वेब परिनियोजन 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 मैं सेवा प्रिंसिपल स्थापित करने में सक्षम हूं, नेट पर कई ट्यूटोरियल हैं। मेरे पास यहां लिंक नहीं हैं, लेकिन जरूरत पड़ने पर मैं उन्हें ढूंढ सकता हूं। अब मेरी समस्या यह है कि कार्य को एक पैरामीटर.एक्सएमएल फ़ाइल की आवश्यकता होती है जो एएसपी नेट कोर प्रकाशन पर उत्पन्न नहीं होती है ... :(

मेरे पास टीएफएस 2015 ऑन-प्रिमाइसेस है और यह एक अविश्वसनीय रूप से कष्टप्रद समस्या बनी हुई है।

मैं भी इस मुद्दे में भाग रहा हूँ ...

मेरा समाधान मेरे स्टेजिंग-स्लॉट को रखना था जिसे मैं रोकने के लिए तैनात करता हूं, फिर इसे प्रकाशित करता हूं (ऑटो स्वैप काम करता है)। फिर से शुरू करना, फिर तैनाती से काम नहीं चला (वीएसटीएस के साथ तैनाती)

मैं Azure वेब ऐप्स के साथ ऑक्टोपस का उपयोग कर रहा हूं, जो कि स्टेजिंग स्लॉट के लिए कोई विकल्प प्रस्तुत नहीं करता है। हालाँकि, निम्न विकल्पों की जाँच करने से लगता है कि काम किया है:

• रूट में खाली app_offline.html के साथ ऐप डोमेन को सुरक्षित रूप से नीचे लाएं।
• गंतव्य पर फ़ाइलें निकालें जो परिनियोजन का हिस्सा नहीं हैं

मैं आईआईएस को एएसपीनेट कोर 1.1/.नेट फ्रेमवर्क 4.5.2 साइट प्रकाशित करने के लिए विजुअल स्टूडियो 2015 अपडेट 3 का उपयोग कर रहा हूं। यह 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 में बदलता हूं तो मेरी साइट बंद हो जाती है और मैं बिना किसी त्रुटि के प्रकाशित कर सकता हूं।

मैं एक साझा यूएनसी पथ पर मेजबानी कर रहा हूं - मुझे नहीं पता कि इससे कोई फर्क पड़ता है या नहीं।

@Tratcher - क्या आप जानते हैं कि App_Offline.htm के आवरण से यहाँ क्या फर्क पड़ेगा?

जयविजयर्कन देखें https://github.com/aspnet/AspNetCoreModule/issues/50

मैं एक Azure ऐपसेटिंग जोड़कर इस समस्या को हल करने में सक्षम था

MSDEPLOY_RENAME_LOCKED_FILES = 1

... जैसा कि यहां बताया गया है:
https://github.com/Microsoft/vsts-tasks/issues/1607#issuecomment -260946957

वाईएमएमवी

@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

वास्तव में इसका समाधान ढूंढ रहे हैं। ऐसा लग रहा था कि आरएम वेब परिनियोजन वीएसटीएस कार्य ने "टेक ऐप ऑफलाइन" विकल्प के साथ इसका ध्यान रखा, लेकिन इस सप्ताह के अंत तक हमें लगातार त्रुटियां मिल रही हैं। हम परिनियोजन स्लॉट को रोकने, परिनियोजित करने और फिर से शुरू करने के लिए वापस आ गए हैं।

इसी तरह, हमारे साथ, यह मुद्दा पिछले सप्ताह शुक्रवार को सामने आया और तब से हमें तैनात करने से रोक दिया गया है ...

मेरा भी यही विचार है। ऐसा लगता है कि यह केवल हमेशा चालू = सत्य वाली साइटों को प्रभावित करता है, लेकिन यह सुनिश्चित नहीं है।

मेरे कॉन्फ़िगरेशन में MSDEPLOY_RENAME_LOCKED_FILES = 1 सेट करते समय भी मुझे यह समस्या है। अब मेरे सर्वर पर बिल्ड को अपडेट करना लगभग असंभव है। अभी कुछ दिन पहले ही ऐसा होना शुरू हुआ है।

इस सप्ताह मेरे लिए भी यही समस्या होने लगी है। इस सप्ताह तक वीएसटीएस में एज़्योरआरएम ऐप सेवा की तैनाती के साथ टेक ऐप ऑफलाइन = ट्रू ने लगातार काम किया। अब ऐसा लगता है कि इस सेटिंग को या तो अनदेखा कर दिया गया है या समय पर सेवा को बंद नहीं किया गया है। इसके लिए रिलीज को चलाने के दौरान मुझे ऐप सेवा को मैन्युअल रूप से पुनरारंभ करना या रोकना/शुरू करना होगा।

यहाँ वही मुद्दा। AzureRm महीनों से काम कर रहा था और अचानक बंद हो गया। मेरी आखिरी तैनाती दो हफ्ते पहले 12/5 को थी और अब 12/20 को यह Error_File_In_Use उत्पन्न कर रही है। मैनुअल स्टार्ट/स्टॉप पर वापस जाने के लिए बहुत नाराज हैं।

यहाँ पॉवर्सशेल में हमारा वर्कअराउंड है जिसका उपयोग हम अभी अपनी CI/बिल्ड प्रक्रिया के हिस्से के रूप में कर रहे हैं। इसमें मदद के लिए @appveyor दोस्तों का विशेष धन्यवाद:

$username = $env:deployusername
$password = $env:deploypassword
$base64AuthInfo = [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes(("{0}:{1}" -f $username,$password)))
$Headers = @{
  'Authorization' = ('Basic {0}' -f $base64AuthInfo)
  'If-Match'      = '*'
}
$apiUrl = "https://YourAzureWebsite.scm.azurewebsites.net/api/vfs/site/wwwroot/app_offline.htm"
$filePath = "app_offline_tmp.htm"
Invoke-RestMethod -Uri $apiUrl -Headers $Headers -Method PUT -InFile $filePath -ContentType "multipart/form-data"

यह Kudu REST API का उपयोग HTTP PUT में सही ढंग से आवरण वाली app_offline.htm फ़ाइल में करता है। हमारे पास किसी भी फाइल को हटाने के लिए WebDeploy कॉन्फ़िगर किया गया है जो परिनियोजन में नहीं है, इसलिए यह स्वचालित रूप से परिनियोजन के हिस्से के रूप में फ़ाइल को हटा देता है। यदि आप इस मोड का उपयोग नहीं कर रहे हैं, तो आपकी तैनाती समाप्त होने के बाद फ़ाइल को निकालने के लिए आपको HTTP DELETE का उपयोग करके चरण को दोहराने की आवश्यकता हो सकती है।

AzureRM कार्य से पहले एक ट्रैकियन स्टॉप जोड़ना और बाद में एक ट्रैकियन प्रारंभ कार्य मेरे लिए अच्छा काम कर रहा है। TakeAppOffline = true के साथ यह आवश्यक नहीं होना चाहिए लेकिन यह काम कर रहा है और यह मैन्युअल या स्क्रिप्टिंग से बचाता है। बस कार्य को रिलीज़ परिभाषा में जोड़ें। ट्रैकियन चरणों को स्थापित करना आसान है

21 दिसंबर 2016 को पूर्वाह्न 12:10 बजे चाड टी < नोटिफिकेशन @github.com [email protected] > ने लिखा:

यहाँ पॉवर्सशेल में हमारा वर्कअराउंड है जिसका उपयोग हम अभी अपनी CI/बिल्ड प्रक्रिया के हिस्से के रूप में कर रहे हैं। इसके लिए मदद के लिए @appveyor https://github.com/appveyor दोस्तों का विशेष धन्यवाद:

$उपयोगकर्ता नाम = $ env:तैनाती उपयोगकर्ता नाम
$पासवर्ड = $ env:तैनातीपासवर्ड
$base64AuthInfo = [कन्वर्ट]::ToBase64String([Text.Encoding]::ASCII.GetBytes(("{0}:{1}" -f $username,$password)))
$हेडर = @{
'प्राधिकरण' = ('मूल {0}' -f $base64AuthInfo)
'इफ-मैच' = '*'
}
$apiUrl = " https://YourAzureWebsite.scm.azurewebsites.net/api/vfs/site/wwwroot/app_offline.htm "
$filePath = "app_offline_tmp.htm"
Invoke-RestMethod-Uri $apiUrl-Headers $Headers-Method PUT-InFile $filePath-ContentType "मल्टीपार्ट/फॉर्म-डेटा"

यह Kudu REST API का उपयोग करता है https://github.com/projectkudu/kudu/wiki/REST-API HTTP के लिए सही ढंग से केस की गई app_offline.htm फ़ाइल को जगह में रखता है। हमारे पास किसी भी फाइल को हटाने के लिए WebDeploy कॉन्फ़िगर किया गया है जो परिनियोजन में नहीं है, इसलिए यह स्वचालित रूप से परिनियोजन के हिस्से के रूप में फ़ाइल को हटा देता है। यदि आप इस मोड का उपयोग नहीं कर रहे हैं, तो आपकी तैनाती समाप्त होने के बाद फ़ाइल को निकालने के लिए आपको HTTP DELETE का उपयोग करके चरण को दोहराने की आवश्यकता हो सकती है।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की थी।
इस ईमेल का सीधे उत्तर दें, इसे GitHub https://github.com/aspnet/Home/issues/694#issuecomment-268436959 पर देखें, या थ्रेड को म्यूट करें https://github.com/notifications/unsubscribe-auth/AID9WoUdbuBnFoXR2K5o8AiUTv8nE9dRks5rKLTcgaJp_Rks5rKLTcga ।

यह संदेश गैर-सार्वजनिक है और इसमें विशेषाधिकार प्राप्त, स्वामित्व वाली या गोपनीय जानकारी हो सकती है। यदि आपने इसे गलती से प्राप्त किया है, तो कृपया प्रेषक को तुरंत सूचित करें और मूल की सभी प्रतियां हटा दें। आपके द्वारा ई-मेल का कोई अन्य उपयोग निषिद्ध है। इस संदेश की सामग्री की किसी भी अनधिकृत नकल, भंडारण, उपयोग या प्रकटीकरण की अनुमति नहीं है और यह गैरकानूनी हो सकता है। जहां स्थानीय कानून द्वारा अनुमति दी गई है, लिथेरो के साथ इलेक्ट्रॉनिक संचार की निगरानी और स्कैन हमारे सिस्टम द्वारा सूचना सुरक्षा और लिथेरो नीतियों और लागू कानूनों के आंतरिक अनुपालन के मूल्यांकन के उद्देश्यों के लिए किया जा सकता है।

/ cc @davidebbo

अपने ऐप के लिए Azure ऐप सेटिंग में MSDEPLOY_RENAME_LOCKED_FILES=1 सेट करने का प्रयास करें।

@davidebo यह चीजों को हल करने के लिए प्रतीत नहीं होता है।

मुझे लगता है कि यह बाड़ के Azure पक्ष में बदलाव से संबंधित है? बहुत से लोगों (विशेषकर एस्पनेट स्लैक चैनल पर) ने इस मुद्दे को एक ही समय में उठाया है।

Azure में परिवर्तन से यह स्पष्ट नहीं होगा कि हम इसे TFS के साथ ऑन-प्रिमाइसेस क्यों देख रहे हैं। क्या यह एजेंट हो सकता है?

हम वही समस्या देख रहे हैं। App_Offline.htm नहीं उठाया गया। अजीब तरह से पर्याप्त अगर हम वीएस से तैनात करते हैं तो यह अच्छी तरह से काम करता है।

अजीब तरह से, मेरे लिए यह वीएस से काम नहीं करता है, जैसा कि यहां बताया गया है: #1883

मेरी टीम को भी इस समस्या का सामना करना पड़ता है, लॉक फ़ाइल के कारण लगभग हर बार परिनियोजन विफल हो जाता है। नीला और फिर से परिनियोजन में प्रत्येक ऐप को पुनरारंभ करने की आवश्यकता है। हम ऑक्टोपस परिनियोजन का उपयोग कर रहे हैं।

मेरी टीम को आज सुबह इस समस्या का सामना करना पड़ा। Microsoft टीम की ओर से कोई टिप्पणी? रिलीज पाइपलाइन हमारी उत्पादकता के लिए महत्वपूर्ण है, यह उत्पादन स्थलों को रिलीज को रोक रही है। धन्यवाद!

@bmoscao - app_offline.html केस संवेदी है।

यह समस्या मेरे लिए Azure पर भी प्रकट हुई है। मैंने इसके लिए अपनी ओर से कुछ भी नहीं किया है।

मुझे भी यह समस्या हो रही है। बात यह है कि EnableMSDeployAppOffline को true पर सेट किया गया है - और प्रोजेक्ट आउटपुट विजुअल स्टूडियो द्वारा चलाए जा रहे कमांड के हिस्से के रूप में -enablerule:AppOffline दिखाता है। मुझे यकीन नहीं है कि क्या करना है ... मुझे हाल ही में यह मुद्दा मिलना शुरू हुआ है ..

इसके लिए हमारा समाधान ऐप पूल को रोकना, परिनियोजित करना, फिर ऐप पूल को पुनरारंभ करना था। हम इसे पूरा करने के लिए रिलीज़ मैनेजर और इनलाइन पॉवरशेल प्लगइन का उपयोग कर रहे हैं।

विराम:

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

निश्चित रूप से माइक्रोसॉफ्ट से कुछ इनपुट की सराहना करेंगे, हालांकि यह आरएम एज़ूर तैनाती चरण पर एपऑफलाइन नियम को सक्षम करने के साथ बहुत अच्छा काम करता था।

@davidebbo हम स्लॉट के साथ ASP.NET Core, VSTS रिलीज़ मैनेजर और AzureRmWebApp का उपयोग कर रहे हैं।

@davidebbo धन्यवाद! इससे मेरा काम बनता है ;)

हमारे साथ भी हो रहा है - msdeploy to Azure. यह देखकर खुशी हुई कि यह एक ही समय में कई लोगों के लिए रहस्यमय तरीके से शुरू हुआ है - और यह सिर्फ हम ही नहीं है - बल्कि समग्र रूप से सुपर आश्वस्त करने वाला नहीं है!

मुझे नहीं लगता कि एमएस के लोगों को इसके लिए पुष्टि की जरूरत है, शायद वे अच्छी तरह जानते हैं कि समस्या क्या है। किसी भी मामले में, यहाँ वही। वीएसटीएस से तैनाती, दिसंबर की शुरुआत में काम करना बंद कर दिया। फिलहाल मैं रोकने/शुरू करने के लिए ट्रैकियन कार्य का उपयोग कर रहा हूं।

प्रत्येक प्रविष्टि के लिए इस सूत्र के माध्यम से जाना, यह हमेशा स्पष्ट नहीं होता है:

1. क्या समस्या Azure ऐप सेवा या किसी अन्य होस्टिंग को संदर्भित करती है
2. क्या लोगों ने ऊपर बताए अनुसार app_offline केसिंग को बदलने की कोशिश की है। लगता है कई लोगों ने वहां सफलता की सूचना दी।
3. क्या MSDEPLOY_RENAME_LOCKED_FILES की कोशिश की गई थी। फिर, ऐसा लगता है कि कई लोग इसमें सफल रहे हैं।

यदि आप इस समस्या का सामना कर रहे हैं, तो कृपया यह स्पष्ट करें कि आपका परिदृश्य क्या है और आपने क्या प्रयास किया है, ताकि हम इसका अर्थ समझ सकें। धन्यवाद!

@davidebbo

जब मैं विजुअल स्टूडियो/एमएसबिल्ड का उपयोग करके तैनात करने का प्रयास करता हूं तो मुझे ERROR_FILE_IN_USE संदेश प्राप्त हो रहा है। कार्य सर्वर पर एक App_Offline.htm फ़ाइल बना रहा है लेकिन यह ऐप को नीचे नहीं ले जा रहा है।

वेब परिनियोजन का उपयोग करके एक app_offline.htm फ़ाइल बनाना ऐप को नीचे ले जाता है।

यह मेरा सेटअप है:

• सर्वर: IIS 8, .NET कोर विंडोज सर्वर होस्टिंग 1.1.0, और वेब परिनियोजन 3.6
• माई मशीन: विजुअल स्टूडियो 2015 अपडेट 3 और .NET कोर 1.0.1 टूल्स प्रीव्यू 2
• प्रोफ़ाइल प्रकाशित करें:

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

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

@davidebbo

मैंने इस त्रुटि पर एक समान थ्रेड पर टिप्पणी की है और हर बार जब मैं पुन: नियोजित करना चाहता हूं (केवल विकास पर्यावरण में) मेरे एज़ूर वेब ऐप को रोकना और पुनरारंभ करना पड़ता है। इस सप्ताह से पहले ऐसा कभी नहीं करना पड़ा। मैंने मूल रूप से बिना किसी संशोधन के टेम्पलेट से विजुअल स्टूडियो 2015 .net कोर वेब ऐप बनाने का निर्णय लिया।

मैंने स्थानीय होस्ट पर वेब ऐप चलाया, कोई समस्या नहीं।
मैं अपने Azure वेब ऐप सेवा योजना में नया ऐप प्रकाशित करता हूं कोई समस्या नहीं है और ब्राउज़र ने तुरंत साइट को कोई समस्या नहीं दी।
मैंने Azure डैशबोर्ड की जाँच की और कोई समस्या नहीं है।

मैं तब गया और वेब ऐप को कुछ भी संशोधित किए बिना पुनः प्रकाशित किया - कोड या सेटिंग्स और निम्न त्रुटि स्वयं प्रस्तुत करती है।

तब से मुझे वेब ऐप बंद करना होगा, Azure पर प्रकाशित करना होगा और फिर वेब ऐप शुरू करना होगा। मेरे साथ ऐसा पहले कभी नहीं हुआ। यह Microsoft टेम्पलेट का एक बहुत ही सरल परिनियोजन है।

मैंने इस पूरी प्रक्रिया को रिकॉर्ड किया और उस फीडबैक को माइक्रोसॉफ्ट 2015 वीएस फीडबैक सिस्टम के भीतर भेज दिया। आशा है कि आपको वह रिकॉर्डिंग मिल जाएगी। या मैं शायद इसे फिर से कर सकता था।

सादर पीटर

@davidebbo

क्या समस्या Azure ऐप सेवा या किसी अन्य होस्टिंग को संदर्भित करती है

Azure ऐप सेवा।

क्या लोगों ने ऊपर बताए अनुसार app_offline केसिंग को बदलने की कोशिश की है। लगता है कई लोगों ने वहां सफलता की सूचना दी।

App_Offline को app_offline में बदलने से समस्या ठीक हो जाती है - यह फ़ाइल परिनियोजन के भाग के रूप में 'App_Offline' केसिंग के साथ स्वचालित रूप से webdeploy के माध्यम से बनाई जाती है, जो इस मुद्दे की जड़ है।

@davidebbo
बिल्कुल @ctolkien जैसा ही।

@davidebbo

क्या समस्या Azure ऐप सेवा या किसी अन्य होस्टिंग को संदर्भित करती है

मेरे मामले में, मैं Azure ऐप सेवा में तैनात कर रहा हूं। अन्य होस्टिंग के बारे में नहीं जानते।

क्या लोगों ने ऊपर बताए अनुसार app_offline केसिंग को बदलने की कोशिश की है। लगता है कई लोगों ने वहां सफलता की सूचना दी।

मैं VSTS (https://aka.ms/azurermwebdeployreadme) से "डिप्लॉय AzureRM वेब ऐप" कार्य का उपयोग कर रहा हूं। एक विकल्प है "वेब परिनियोजन का उपयोग करके प्रकाशित करें" <- चेक किया गया और "ऐप ऑफ़लाइन लें" <- चेक किया गया जो काम करता था, जब तक कि कहीं कुछ बदल नहीं गया और यह काम करना बंद कर दिया।
"जानकारी" टूलटिप स्पष्ट रूप से "app_offline.htm" को लोअर केस "ए" के साथ रखने के बारे में बताता है।
मुझे यकीन नहीं है कि इस स्क्रिप्ट का उपयोग करके इसे कैसे बदला जाए, यह पहले से ही कम मामला होना चाहिए।

क्या MSDEPLOY_RENAME_LOCKED_FILES का प्रयास किया गया था। फिर, ऐसा लगता है कि कई लोग इसमें सफल रहे हैं।

कोशिश नहीं की। पता नहीं कैसे करना है। लेकिन किसी भी मामले में, मैं लॉक की गई फ़ाइलों की सामग्री को बदलने के बजाय ऐप को ऑफ़लाइन लेना पसंद करूंगा।

सबको शुक्रीया। तो यह स्पष्ट लगता है कि प्राथमिक मुद्दा app_offline.htm के आवरण के साथ है, और Azure ऐप सेवा से संबंधित कुछ भी नहीं है (जिस तरफ से मैं आया हूं)। और इसे https://github.com/aspnet/AspNetCoreModule/issues/50 द्वारा ट्रैक किया जाता है।

मैं इस मुद्दे को बंद करने और दूसरे को रखने का सुझाव दूंगा। मैं ASP.NET विशेषज्ञों को इसे वहां से ले जाने दूंगा, जब तक कि यह सोचने का कोई कारण न हो कि Azure वेब ऐप आंशिक रूप से दोष देने के लिए है (संभावना नहीं है कि @fabiano Azure के बाहर समान रिपोर्टिंग पर आधारित है)।

वास्तव में यह टूलींग में एक प्रतिगमन जैसा दिखता है जहां ऐसा लगता है कि ऐप_ऑफ़लाइन.एचटीएमएल के बजाय ऐप_ऑफ़लाइन.एचटीएमएल बनाना शुरू कर दिया है। @mlorbetske , @vijayrkn - कोई विचार यह क्या हो सकता है?

मैं देखता हूं, तो आप कह रहे हैं कि कोर रनटाइम (AspNetCoreModule) हमेशा केस संवेदनशील था, लेकिन यह कोई समस्या नहीं थी क्योंकि वीएस मिलान करने वाले मामले का उपयोग कर रहा था और अब यह नहीं है?

हालांकि परवाह किए बिना, मैं तर्क दूंगा कि रनटाइम यहां संवेदनशील नहीं होना चाहिए, इसलिए इस मुद्दे को हल करने के लिए दो संभावित रास्ते हैं।

@ डेविडबो - यह सही है। मेरा मानना ​​है कि AspNetCoreModule हमेशा केस सेंसिटिव था।

@davidebbo

और Azure ऐप सेवा से संबंधित कुछ भी नहीं (जिस तरफ से मैं आया हूं)

मुझे लगता है कि Azure AppService को चर्चा में लाने का कारण यह है कि हमारी ओर से किसी भी बदलाव के बिना, चीजें अभी विफल होने लगीं, हमने अपने किसी भी पैकेज संस्करण को नहीं बदला। क्या ऐप सेवाओं पर एएनसीएम संशोधन संशोधित किया गया था?

@ctolkien हाँ, मुझे लगता है कि यह वास्तव में अपडेट किया गया था। तो यह बहुत अच्छी तरह से हो सकता है कि उपरोक्त निष्कर्ष सही नहीं है। इसके बजाय नया सिद्धांत है:

• पुराना ANCM (7.1.1965.0) केस संवेदी नहीं था।
• नया (7.1.1970.0) केस संवेदी बन गया।
• वीएस प्रकाशन पक्ष में कुछ भी नहीं बदला, और आवरण हमेशा App_Offline.htm रहा है।

@moozzyk क्या आपको लगता है कि यह एक संभावना है, या आप सकारात्मक हैं कि यह हमेशा केस संवेदनशील था?

@moozzyk @davidebbo - app_offline केसिंग के लिए VS टूलिंग में कोई बदलाव नहीं हुआ। वीएस टूलिंग ऐपऑफ़लाइन नियम (-enablerule:AppOffline) के साथ msdeploy को कॉल करता है और msdeploy ड्रॉप्स App_Offline.htm।

यह समस्या ANCM में व्यवहार परिवर्तन की तरह दिखती है। यहां पहली टिप्पणी के आधार पर app_offline केस इन-सेंसिटिव होना चाहिए (https://github.com/aspnet/IISIntegration/issues/81)।

@ctolkien

App_Offline को app_offline में बदलने से समस्या ठीक हो जाती है

मैं इसे कहां बदलूं? मैं विजुअल स्टूडियो से सीधे Azure तक MSDEPLOY करता हूं।

@oyvindvol

मैं इसे कहां बदलूं? मैं विजुअल स्टूडियो से सीधे Azure तक MSDEPLOY करता हूं।

जहाँ तक मुझे पता है, आप MSDEPLOY से App_Offline के आवरण को नहीं बदल सकते हैं, आपको अभी के लिए कस्टम स्क्रिप्ट समाधान की आवश्यकता होगी। आप ऊपर पोस्ट की गई पॉवरशेल स्क्रिप्ट का उपयोग शुरुआती बिंदु के रूप में कर सकते हैं।

सभी को अपडेट करने के लिए, हमने पुष्टि की कि उपरोक्त सिद्धांत सही है: केस सेंसिटिविटी बग एएनसीएम के नए संस्करण में एक प्रतिगमन है, और उस संस्करण को दिसंबर में Azure ऐप सेवा में तैनात किया गया, जिससे उपयोगकर्ता अचानक इसे हिट कर सकते हैं।

योजना ASP.NET कोर टीम से ANCM फिक्स प्राप्त करने और इसे ऐप सेवा में तैनात करने की है। अभी तक कोई ईटीए नहीं है, लेकिन यह जनवरी में किसी समय होना चाहिए।

धन्यवाद!

@davidebbo क्या हम आईआईएस का उपयोग करके अपने सर्वर पर स्थापित करने के लिए एएनसीएम डाउनलोड कर पाएंगे और इस विशेष बग को भी मार पाएंगे?

@Pictuel मैं ऐसा सोचूंगा। ध्यान दें कि यहां मेरा कोण सख्ती से Azure ऐप सेवा है, इसलिए मैं कोर टीम को गैर-Azure परिदृश्यों पर टिप्पणी करने दूंगा।

चेतावनी के लिये धन्यवाद :)

@Pictuel हाँ हम यह सुनिश्चित करेंगे कि .NET कोर के लिए Windows होस्टिंग इंस्टालर का एक अद्यतन संस्करण जारी किया जाएगा जिसमें ANCM का अद्यतन शामिल है।

@shirhatti

@shirhatti मैं यहां निगरानी कर रहा हूं जब अद्यतन इंस्टॉलर दस्तावेज़ लिंक अपडेट करने के लिए उपलब्ध है।

उस सूत्र के माध्यम से जाने के बाद मुझे वास्तव में यकीन नहीं है कि ऐप सेवाओं के लिए वास्तव में क्या समाधान है। क्या यह ऐप सेटिंग है या यह कस्टम परिनियोजन स्क्रिप्ट का उपयोग कर रहा है या साइट को रोकना और शुरू करना है?

यदि यह ऐप सेटिंग है तो मैंने एक और टिप्पणी पढ़ी है जिसमें कहा गया है कि यह वेबसाइट को नए डीएलएल नहीं लेने का कारण बनती है।

अगर मैं सही ढंग से समझता हूं कि एएनसीएम (https://github.com/aspnet/AspNetCoreModule/issues/50) पर अपडेट उपलब्ध होने तक हमारी तरफ से कोई समाधान नहीं है। एज़ूर टीम द्वारा ऐप सेवाओं को अपडेट किया जाना चाहिए।

मुझे लगता है कि आप ऐप सेवा पर सबसे अच्छा दांव लगाते हैं, जैसा कि यहां @dtmnash द्वारा वर्णित ऐप को रोकना / शुरू करना है।

@davidebbo "योजना ASP.NET कोर टीम से ANCM फिक्स प्राप्त करने और इसे ऐप सेवा में तैनात करने की है। अभी तक कोई ETA नहीं है, लेकिन यह जनवरी में कभी-कभी होना चाहिए।" -- हमें बताएं कि इस पर ईटीए कब तैयार होगा :)

संभावित परिनियोजन ईटीए 24 से 30 तारीख के बीच है। कई पैमाने की इकाइयों पर परिनियोजन धीरे-धीरे होता है, इसलिए सभी को ठीक एक ही समय में सुधार नहीं मिलेगा।

धन्यवाद, मेरे लिए यह अभी काम करना शुरू कर दिया :-)

अभी भी मेरे लिए एक मुद्दा है :(

@hbunjes पुष्टि करने के लिए धन्यवाद!

@rsnj यह कुछ समय से उत्तरोत्तर हो रहा है। यह सब महीने के अंत तक किया जाना चाहिए (जब तक कि हमें कोई समस्या न हो)।

@davidebbo परिनियोजन मेरे कुछ ऐप्स के लिए काम करता प्रतीत होता है लेकिन सभी नहीं। अजीब बात यह है कि कुछ परिनियोजन विफल हो जाते हैं लेकिन अन्य समान ऐप सेवा योजना में चल रहे ऐप्स के लिए नहीं होते हैं। क्या यह देखना संभव है कि किसी विशेष वेब ऐप के लिए एएनसीएम का कौन सा संस्करण चल रहा है?

@henningst जाँच करने के तरीके के लिए https://github.com/aspnet/AspNetCoreModule/issues/50#issuecomment -271381892 देखें।

कल मेरे लिए काम नहीं कर रहा था लेकिन अब यह है। धन्यवाद @davidebbo!

यह मेरे लिए भी काम करने लगा। धन्यवाद!

हां, तैनाती अब पूरी हो गई है, इसलिए इसे सभी के लिए काम करना चाहिए।

यहां भी मेरे लिए सब अच्छा है।

लगता है अब काम कर रहा है। रिपोर्ट से इसे ठीक करने में एक साल से अधिक का समय लगा। मैं हालांकि तैनाती के मुद्दों को उच्च प्राथमिकता देता: p

गैर-Azure के लिए इसे कैसे ठीक करें?

@pekkah मुझे लगता है कि यह अलग-अलग मुद्दों से गुजरा। नवीनतम एक वर्ष की तुलना में बहुत अधिक हाल का था।

@jdshkolnik गैर-Azure के लिए, मुझे लगता है कि आपको बस नए ANCM का उपयोग शुरू करने की आवश्यकता है।

@jdshkolnik
अपडेट https://www.microsoft.com/net/download/core#/runtime . पर डाउनलोड के लिए उपलब्ध है
यह डाउनलोड का सीधा लिंक है।

@shirhatti मैंने इसे स्थापित किया है फिर भी मुझे ये त्रुटियां मिल रही हैं।

मुझे अभी भी साओ पाउलो, दक्षिण ब्राजील में त्रुटि मिल रही है।

जब आप इसे PowerShell में चलाते हैं तो @jdshkolnik आपको कौन सा संस्करण दिखाई देता है?

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

@shirhatti 7.1.1971.0

अद्यतन : क्षमा करें, यह मेरी गलती थी। मैं रिलीज़ परिभाषा के बजाय मौजूदा रिलीज़ के परिनियोजन चरणों की समीक्षा और अद्यतन कर रहा था। मैंने यह गिनती खो दी है कि मैंने इसे कितनी बार किया है ...

मैं अभी भी इस त्रुटि में हर बार जब मैं तैनात करने का प्रयास करता हूं, भले ही aspnetcore.dll का मेरा संस्करण निश्चित रूप से तय किया गया हो।

aspnetcore.dll संस्करण : 7.1.1971.0
का उपयोग कर तैनात : VSTS कार्य Azure ऐप सेवा परिनियोजन v3.* (पूर्वावलोकन)
ऐप को ऑफलाइन लें : चेक किया गया
गंतव्य पर अतिरिक्त फ़ाइलें निकालें : जाँच की गई
लॉक की गई फाइलों का नाम बदलें : चेक किया गया
MSDEPLOY_RENAME_LOCKED_FILES ऐप सेटिंग : नहीं जोड़ा गया

इस स्तर पर यह मेरे लिए स्पष्ट नहीं है कि इसके काम करने के लिए कौन सी सेटिंग्स आवश्यक हैं या नहीं।

एज़ूर ऐप सेवाओं पर अभी मेरी पहली फ़ाइल उपयोग समस्या में थी:

2017-02-14T22:41:10.4400186ZC:\Program Files (x86)\IIS\Microsoft Web Deploy V3\msdeploy.exe - source:IisApp= 'D:/a/r1/a/Acend Ammo Portal/drop/apps /Artifacts/AmmoPortal' - dest:IisApp= 'core-asyoz77ajoed4/ammo-preview',ComputerName=' https://core-asyoz77ajoed4.scm.azurewebsites.net/msdeploy.axd?site=core-asyoz77ajoed4/ammo -preview ',UserName='$core-asyoz77ajoed4',Password=' * * ',IncludeAcls='False',AuthType='Basic' - verb:sync -retryAttempts=20 -verbose -e nablerule:AppOffline

2017-02-14T22:41:34.3837386Z त्रुटि कोड: ERROR_FILE_IN_USE

2017-02-14T22:41:34.3837386Z अधिक जानकारी: वेब परिनियोजन गंतव्य पर 'Acend.Ammo.Portal.exe' फ़ाइल को संशोधित नहीं कर सकता क्योंकि यह किसी बाहरी प्रक्रिया द्वारा अवरोधित है। प्रकाशन ऑपरेशन को सफल होने देने के लिए, आपको या तो लॉक को रिलीज़ करने के लिए अपने एप्लिकेशन को पुनरारंभ करने की आवश्यकता हो सकती है, या अपने अगले प्रकाशन प्रयास पर .Net एप्लिकेशन के लिए AppOffline नियम हैंडलर का उपयोग करना होगा। अधिक जानें: http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_FILE_IN_USE।

2017-02-14T22:41:34.3837386Z त्रुटि गणना: 1.

FYI करें: डॉक्स पुराने संस्करण (*.1970) के साथ एक इंस्टॉलर से लिंक होने लगते हैं: https://docs.microsoft.com/en-us/aspnet/core/publishing/iis#install -the-net-core- विंडोज़-सर्वर-होस्टिंग-बंडल.

साथ ही, ऐसा लगता है कि रनटाइम डाउनलोड पेज पर केवल एलटीएस संस्करण में ही फिक्स है?

@shirhatti ~ नया होस्टिंग बंडल इंस्टॉलर लिंक तैयार होने पर मुझे बताएं, और मैं इसे डॉक्स में शूट करूंगा (यह कुछ जगहों पर है)। ~

~क्या यह एक है: https://go.microsoft.com/fwlink/?linkid=837808 ... यह कोई aka.ms लिंक नहीं है।~

अगर fwlink ठीक है तो मैं इसे कवर करने के लिए https://github.com/aspnet/Docs/pull/2773 सेटअप करता हूं।

विजुअल स्टूडियो में भी होता है, और जैसा कि विकल्प दिखाते हैं - ऐप ऑफ़लाइन नियम मौजूद है।

@davidebbo क्या आप पुष्टि कर सकते हैं कि यह तय है? बहुत से लोगों से यह सुनकर कि वे अभी भी इसे मार रहे हैं। क्या टूलींग के रिलीज़ संस्करण में इसके लिए कोई समाधान है या यह अभी भी एक होस्टिंग समस्या है?

मैं यह भी पता लगाने की कोशिश कर रहा हूं कि ऐसा क्यों और कब होता है। मुझे पूरा यकीन है कि मैंने देखा है कि प्रक्रिया scm साइट पर प्रोसेस एक्सप्लोरर में चल रही है और यह ठीक प्रकाशित हुई है।

मैं अपनी साइटों को नवीनतम टूलिंग में भी अपडेट करने की प्रक्रिया में हूं, उम्मीद है कि यह समस्या पुराने प्रोजेक्ट.जेसन टूलिंग से संबंधित है।

फिक्स को कुछ समय पहले Azure ऐप सेवा में तैनात किया गया था, और मुझे इस बात की जानकारी नहीं है कि कोई भी व्यक्ति बाद में इस मुद्दे को देख रहा है। बेशक, गैर-Azure होस्ट पर उपयोगकर्ता अभी भी इसे देख सकते हैं यदि उन्हें अपडेट नहीं किया गया है।

Azure के लिए, यदि आपको समस्या हो रही है, तो कृपया इसे निम्नानुसार जांचें:

• कुडु प्रोसेस एक्सप्लोरर पर जाएं और सुनिश्चित करें कि आपके ऐप की प्रक्रिया चल रही है (आमतौर पर dotnet.exe)
• कुडू कमांड से मैन्युअल रूप से app_offline.htm फ़ाइल बनाएं (उदाहरण के लिए touch app_offline.htm चलाएं)
• प्रक्रिया एक्सप्लोरर को दोबारा जांचें, और सुनिश्चित करें कि प्रक्रिया अब वहां नहीं है।

मैं कुछ और परीक्षण करूंगा, क्या आपने छवि को कुछ पोस्ट देखा है, यह स्पष्ट रूप से दिखाता है कि फ़ाइल उपयोग में है और यह ऐप ऑफ़लाइन उपयोग करती है।

लेकिन जैसा आपने पूछा मैं परीक्षण करूंगा।

साथ ही, हम वर्चुअल एप्लिकेशन पर तैनात स्केलआउट + ऐप्स का उपयोग कर रहे हैं - यह नहीं पता कि इससे कुछ भी बदलता है या नहीं।

@pksorensen इसे 'मैन्युअल रूप से' करने से WebDeploy जो कुछ भी कर रहा है, उससे अलग करने में मदद मिलेगी। यानी अगर केवल app_offline.htm छोड़ने से प्रक्रिया रुकती नहीं है, तो हम वास्तव में जानते हैं कि कोई समस्या है जो WebDeploy के कारण नहीं है।

ध्यान दें कि आम तौर पर, आप एक dotnet.exe प्रक्रिया के साथ समाप्त होते हैं, जबकि आपके मामले में आपके पास एक अलग exe नाम होता है। मुझे आश्चर्य है कि क्या यह किसी तरह इस मुद्दे से संबंधित है।

1. कुडु प्रोसेस एक्सप्लोरर पर जाएं और सुनिश्चित करें कि आपके ऐप की प्रक्रिया चल रही है (आमतौर पर dotnet.exe)
   मैंने यह किया, लेकिन यह dotnet.exe नहीं है, लेकिन हमारा नाम संकलित बिन Ascend.Ammo.RegistrationTablet.exe है।

तब मैंने app_offline.htm को स्पर्श किया, लेकिन इससे प्रक्रिया समाप्त नहीं हुई।

क्या मैं कुछ गलत कर रहा हूँ क्योंकि मुझे dotnet.exe नहीं दिख रहा है?

मैं डॉटनेट/एएनसीएम विशेषज्ञों को उस हिस्से पर टिप्पणी करने दूंगा। मैं डिफ़ॉल्ट रूप से जानता हूं, कोर ASP.NET ऐप को तैनात करते समय, यह dotnet.exe का उपयोग करता है। मुझे लगता है कि जब ऐसा नहीं होता है तो आप स्टैंडअलोन परिनियोजन (या इसे जो भी कहा जाता है) का उपयोग करते हैं। लेकिन मुझे नहीं पता कि यह ANCM और app_offline.htm को कैसे प्रभावित करता है।

@DamianEdwards इस पर सबसे अच्छी टिप्पणी कौन कर सकता है?

मैं परिनियोजन स्लॉट का उपयोग करके उस समस्या से बचता हूं। 100% समय काम करता है। फ़ाइलें कॉपी करने से पहले स्लॉट बंद कर दें। यह सब कुछ मेमोरी से हटा देगा ताकि आपकी कॉपी बिना लॉक की गई फाइलों पर काम करे। फिर स्लॉट शुरू करें और उत्पादन में स्वैप करें। अतिरिक्त लाभ आपके ग्राहक कभी भी ऐप ऑफ़लाइन पृष्ठ नहीं देखते हैं। उन्हें 0 डाउनटाइम परिनियोजन मिलता है।

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

@DarqueWarrior स्लॉट निश्चित रूप से काम करता है (और अन्य कारणों से उपयोग करने के लिए अच्छा है), लेकिन इस धागे में महत्वपूर्ण बात यह समझना है कि @pksorensen जैसे कुछ लोगों के लिए कोर प्रक्रिया को बंद करने में app_offline अप्रभावी क्यों दिखाई देता है। और मैं चाहूंगा कि कोर टीम उस पर टिप्पणी करे।

@davidebbo आपके पहले के प्रश्न का उत्तर देने के लिए, पोर्टेबल बनाम स्टैंडअलोन का app_offline व्यवहार पर कोई असर नहीं पड़ता है। ऐप ऑफ़लाइन फ़ाइल की निगरानी w3wp.exe (ASP.NET कोर मॉड्यूल द्वारा) द्वारा की जाती है।

@DarqueWarrior सलाह के लिए धन्यवाद, एक टिप्पणी हालांकि - यदि आप एक ही ऐप सेवा में वर्चुअल एप्लिकेशन में कई साइटों को तैनात कर रहे हैं, तो स्लॉट (यदि मुझे सही याद है) उन सभी में काम करते हैं, इसलिए आपको पहले सभी साइटों को तैनात करना होगा अदला-बदली यह एक झंझट है। अभी हम अलग-अलग आभासी अनुप्रयोगों में भागों (सूक्ष्म सेवाओं) को आसानी से तैनात कर सकते हैं। क्योंकि हम उन्हें अलग-अलग ऐप सेवाओं में फैलाने के बारे में जा सकते हैं, लेकिन फिर हमें उसी डोमेन को फिर से साझा करने के लिए लोड बैलेंसर्स/गेटवे की आवश्यकता होगी, और अधिक समय भी खर्च होगा, फिर हम अभी ऐसा करने के इच्छुक हैं।

इसलिए मैं मानता हूं कि आपका सुझाव बेहतर तरीका है, यह अभी हमारे साथ फिट नहीं है। इसलिए अभी भी फाइल इन यूज मुद्दे पर एक समाधान की उम्मीद है।

@pksorensen किसी भी मौके पर आप एक डमी साइट में एक रेप्रो स्थापित कर सकते हैं और उसका नाम साझा कर सकते हैं? मूल रूप से, मैं इसे उस स्थिति में देखना चाहता हूं जहां आपकी साइट चल रही है, और मैन्युअल रूप से Kudu कंसोल में app_offline.htm बनाने से यह बंद नहीं होता है।

@shirhatti किसी भी विचार से एएनसीएम प्रक्रिया को बंद नहीं कर सकता है? यह कितनी आक्रामक तरीके से ऐसा करने की कोशिश करता है?

@davidebbo मुझे थोड़ा समय लगेगा लेकिन मैं एक रेप्रो बनाने के लिए कुछ काम करने की कोशिश करूंगा।

@davidebo मैंने एक नया ASP.NET कोर ऐप और एक नई Azure ऐप सेवा बनाई। मैं Azure की "निरंतर वितरण (पूर्वावलोकन)" सुविधा का उपयोग कर रहा हूं, और मुझे यह समस्या मिल रही है।

2017-03-30T02:54:36.5648892Z ##[त्रुटि] ऐप सेवा को परिनियोजित करने में विफल।
2017-03-30T02:54:36.5658893Z ##[त्रुटि] त्रुटि कोड: ERROR_FILE_IN_USE
2017-03-30T02:54:37.1850861Z अधिक जानकारी: वेब परिनियोजन गंतव्य पर 'myApp.dll' फ़ाइल को संशोधित नहीं कर सकता क्योंकि यह किसी बाहरी प्रक्रिया द्वारा अवरोधित है। प्रकाशन ऑपरेशन को सफल होने देने के लिए, आपको या तो लॉक को रिलीज़ करने के लिए अपने एप्लिकेशन को पुनरारंभ करने की आवश्यकता हो सकती है, या अपने अगले प्रकाशन प्रयास पर .Net एप्लिकेशन के लिए AppOffline नियम हैंडलर का उपयोग करना होगा। अधिक जानें: http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_FILE_IN_USE।
2017-03-30T02:54:37.1860517Z त्रुटि गणना: 1.
2017-03-30T02:54:37.4179909Z ##[त्रुटि] त्रुटि: C:\Program Files\IIS\Microsoft Web Deploy V3\msdeploy.exe रिटर्न कोड के साथ विफल: 4294967295

मैन्युअल रूप से D:\home\site\wwwroot में app_offline.htm बनाना वास्तव में dotnet.exe प्रक्रिया को रोकता है।

तो क्या इसका मतलब यह है कि "निरंतर वितरण (पूर्वावलोकन)" के साथ ही कोई समस्या है?

उपरोक्त के अलावा, मैंने मैन्युअल रूप से VSTS रिलीज़ डेफिनिशन, अतिरिक्त परिनियोजन विकल्प पर जाकर, "टेक ऐप ऑफलाइन" पर टिक करके इसे ठीक किया।

लेकिन इससे कुछ सवाल उठते हैं:
डिफ़ॉल्ट रूप से "टेक ऐप ऑफलाइन" को अनचेक क्यों किया जाता है? क्या यह परिदृश्य अभी भी काम करना चाहिए (उदाहरण के लिए क्या यह डाउनटाइम को कम करता है)?

यदि हां, तो असफल क्यों हो रहा है ? यदि नहीं, तो "निरंतर वितरण (पूर्वावलोकन)" इसे अचिह्नित क्यों करता है?

किसी भी तरह - ऐसा लगता है जैसे कहीं कोई बग है।

@Jon12345 : यह थ्रेड केवल इस बात पर चर्चा करने के बारे में है कि क्या app_offline.htm कोर ऐप्स के साथ सही ढंग से काम कर रहा है। इसलिए यह तथ्य कि वीएसटीएस डिफ़ॉल्ट रूप से ऐसा कर सकता है या नहीं कर सकता है, वास्तव में एक अलग चर्चा है, जिसे वीएसटीएस फोरम (शायद https://social.msdn.microsoft.com/Forums/vstudio/en-US/) पर होना चाहिए। होम? फोरम = TFService)।

इस बिंदु पर, अधिकांश लोगों को फिक्स के बाद अनब्लॉक कर दिया गया प्रतीत होता है। इसकी एक रिपोर्ट @pksorensen द्वारा काम नहीं कर रही है, और हम एक रेप्रो ऐप को देखने की प्रतीक्षा कर रहे हैं।

मुझे यह अभी भी टीएफएस 2017 अपडेट 1 पर मिलता है।

@jdshkolnik क्या आप सुनिश्चित हैं कि इसे appoffline.htm फ़ाइल बनाने के लिए सेट किया गया है? यदि नहीं, तो यह इस मुद्दे के दायरे से बाहर है। कृपया मैन्युअल appoffline.htm परीक्षण ऊपर बताए अनुसार करें।

@davidebbo हाँ, यह है। अक्सर ऐसा होता है कि निर्धारित रात्रि परिनियोजन अपने पहले प्रयास में विफल हो जाता है और इसके लिए मैन्युअल पुन: परिनियोजन प्रयास की आवश्यकता होती है जो आमतौर पर सफल होता है।

FYI करें, मेरी फर्म आपके साथ फ़ेडरेटेड है इसलिए मैं आपको 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 कॉन्फ़िगरेशन समस्या या बग हो सकता है। लेकिन एएनसीएम के दृष्टिकोण से, आपके द्वारा किए गए परीक्षण से पता चलता है कि ऐपऑफ़लाइन बनने पर चीजें उम्मीद के मुताबिक काम कर रही हैं।

@davidebbo मुझे नहीं पता कि मैंने जो किया वह एक निश्चित परीक्षा थी। आखिरकार, हमें त्रुटि मिलने के बाद दूसरा मैन्युअल प्रयास आमतौर पर सफल होता है। परिनियोजन प्रक्रिया जो app_offline.htm को अवरुद्ध कर सकती है, वह नहीं चल रही थी।

मैं अभी भी 7.1.1971.0 पर इस मामले के संवेदनशील मुद्दे पर चल रहा हूँ। जब मैं वीएस का उपयोग करके तैनात करने का प्रयास करता हूं तो मुझे फ़ाइल लॉक त्रुटि मिलती है, इसलिए मैंने यह देखने के लिए देखा कि ऐप अभी भी चल रहा था और निश्चित रूप से यह पर्याप्त था। मैंने कुडु कमांड लाइन खोली यह देखने के लिए कि कौन सी फाइलें wwwroot निर्देशिका और App_Offline.htm फ़ोल्डर में थीं लेकिन प्रक्रिया अभी भी चल रही थी। फिर मैंने स्पर्श app_offline.htm टाइप किया और प्रक्रिया अपेक्षित रूप से चलना बंद कर दी। मैंने मॉड्यूल की दोबारा जांच की और मेरा aspnetcore.dll संस्करण 7.1.1971.0 है।

@alexgritton यह अजीब है। ऐसा प्रतीत होता है कि एएनसीएम ने शुरू में फ़ाइल का पता नहीं लगाया था। क्या यह लगातार या अचानक होता है?

मैंने आज ही Azure ऐप सर्विसेज पर एप्लिकेशन बनाया है और यह पूरे दिन हो रहा है, इसलिए मैं लगातार कहूंगा। क्या आपके पास कोई अन्य विचार है कि इसका क्या कारण हो सकता है?

ज़रुरी नहीं। मैं एएनसीएम विशेषज्ञों को इस पर टिप्पणी करने दूंगा कि वे फ़ाइल परिवर्तन मॉनिटर कैसे करते हैं, और यदि वे किसी कारण के बारे में सोच सकते हैं कि प्रारंभिक निर्माण का पता क्यों नहीं चला।

@davidebo मुझे ठीक वैसी ही समस्या हो रही है। मेरी टीम के पास एक नकली निर्माण है जो एक फ़ाइल की प्रतिलिपि बनाता है AppBuild.htm बिल्ड सर्वर से लक्ष्य साइट पर app_offline.htm के रूप में। फिर हम फ़ोल्डर को सिंक करने के लिए msdeploy का उपयोग करने का प्रयास करते हैं और किसी अन्य प्रक्रिया त्रुटि द्वारा खोला जाता है। यदि मैं फ़ाइल को स्पर्श करता हूँ, तो फ़ाइल का नाम बदलकर app_offline.htm से app_offline.htm.rename कर देता हूँ और फिर वापस आ जाता हूँ, या फ़ाइल एक्सप्लोरर का उपयोग करके app_offline.htm को अधिलेखित कर देता हूँ तो प्रक्रिया ठीक से रुक जाती है। इसका कोई मतलब नहीं है कि यह हमारी स्क्रिप्ट के माध्यम से काम क्यों नहीं करता है, लेकिन अगर हम इसे मैन्युअल रूप से करते हैं।

अद्यतन: हमने पाया कि अंतिम लेखन समय को अद्यतन करना लगातार शट डाउन को ट्रिगर करता प्रतीत होता है:

Target "StopApi" (fun _ ->                                    
    trace "Deployment - Stopping Api"                 

    for folder in apiWebDeployShare do                        
        let offlineFile = folder @@ "app_offline.htm"         
        let offlineFileSource = folder @@ "AppOffline.htm"    
        CopyFile offlineFile offlineFileSource                
        File.SetLastWriteTime (offlineFile, DateTime.Now)     
)                

निश्चित रूप से कोड के साथ कुछ ऐसा प्रतीत होता है जो app_offline.htm फ़ाइल की निगरानी करता है।

@derekgrier तो आप जो देख रहे हैं वह यह है कि जब आप फ़ाइल को कॉपी करते हैं, तो शटडाउन ट्रिगर नहीं होता है? मैं Kudu कंसोल से इसे पुन: प्रस्तुत करने में सक्षम नहीं हूँ। जैसे

• कुडू कंसोल पर जाएं
• किसी भिन्न फ़ोल्डर में खाली फ़ाइल बनाने के लिए touch app_offline.htm को D:\home\site में चलाएँ
• copy app_offline.htm wwwroot चलाएँ। ध्यान दें कि यह अंतिम लेखन समय को सुरक्षित रखता है और निर्माण समय (मानक फ़ाइल प्रतिलिपि व्यवहार) को अद्यतन करता है।

परिणाम: dotnet.exe प्रक्रिया तुरंत बंद हो जाती है (आप Kudu प्रक्रिया एक्सप्लोरर का उपयोग करके जांच सकते हैं)।

क्या ये वही कदम आपके लिए काम करते हैं? यदि हां, तो आपके रेप्रो परिदृश्य में क्या भिन्न हो सकता है?

वास्तव में, मुझे यह भी जोड़ना चाहिए था कि यह समस्या रुक-रुक कर हो रही है और हम Windows Server 2012 पर IIS 8 का उपयोग कर रहे हैं।

आज सुबह मेरा इरादा यह देखने का था कि क्या मैं कुडू कंसोल को स्थापित करने से पहले एक पॉवरशेल या बैच स्क्रिप्ट के साथ इस मुद्दे को पुन: पेश कर सकता हूं, लेकिन परीक्षण के साथ पहली बार परीक्षण करने के बाद मेरी टीम शुक्रवार को app_offline.htm फ़ाइल बनाने के लिए उपयोग कर रही थी। विभिन्न तरीके (मौजूदा फ़ाइल की प्रतिलिपि बनाएँ, नई फ़ाइल बनाएँ, आदि), यह वर्तमान में काम कर रहा है। यह हमारी बिल्ड विफलताओं के पैटर्न को भी दर्शाता है जहां यह कभी-कभी प्रक्रिया को बंद कर रहा था और दूसरी बार नहीं। जब यह विफल होने लगता है, तो ऐसा लगता है कि यह लगातार ऐसा करता है। हमने शुक्रवार को घंटों तक परीक्षण किया और यह लगातार एक साधारण नकली निर्माण के साथ नहीं रुकेगा जिसने एक नई app_offline.htm फ़ाइल बनाने के अलावा कुछ भी नहीं किया। मुझे यह भी जोड़ना चाहिए कि हम समय-समय पर फ़ाइल को मैन्युअल रूप से बनाएंगे और प्रक्रिया को रोकेंगे, इसलिए यह किसी भी प्रकार की स्थिति नहीं होगी जहां कुछ विस्तारित अवधि के उपयोग के बाद प्रक्रिया बंद नहीं होगी।

जब मैं इस मुद्दे को फिर से पुन: पेश कर सकता हूं तो मैं देखूंगा कि पावरहेल और/या बैच फ़ाइल का उपयोग कर फ़ाइल बनाना अभी भी समस्या को दर्शाता है।

@davidebo ठीक है, बकवास ... मैंने अभी देखा है कि मैं एक पंक्ति पर टिप्पणी करना भूल गया था जो अंतिम अद्यतन समय अपडेट कर रहा था, इसलिए यह वास्तव में वही व्यवहार दिखा रहा है। मैं अब पॉवरशेल और एक बैच फ़ाइल के साथ प्रयास करूँगा और आपको अपडेट करूँगा।

@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 कॉपी कमांड, बैश, और Kudu कंसोल नहीं करते हैं, यह CLR के माध्यम से बनाई जा रही फ़ाइल से संबंधित किसी चीज़ की ओर इशारा करता है।

अजीब बात यह है कि, मुझे परिणामी फ़ाइल के विभिन्न संस्करणों के बीच टाइमस्टैम्प बनाने/अपडेट करने में कोई अंतर नहीं दिखता है।

@derekgrier ओह, तो आप Azure ऐप सेवा पर बिल्कुल नहीं चल रहे हैं। इस पूरी गाथा में यही मेरा दृष्टिकोण है, इसलिए मैं ASP.NET के लोगों को इस पर और टिप्पणी करने दूंगा।

हालांकि इसके लायक क्या है, मैं ऐप सेवा में पुन: पेश करने में सक्षम नहीं था:

• Kudu के PowerShell कंसोल का उपयोग करें
• साइट\wwwroot फ़ोल्डर पर जाएं
• भागो New-Item app_offline.htm -type file

@moozzyk क्या आप ऐप सेवा के बाहर @derekgrier के रेप्रो की जांच में मदद कर सकते हैं?

आगे की जानकारी:

चूंकि फ़ाइल एक्सप्लोरर के माध्यम से बनाने, कॉपी करने, नाम बदलने आदि ने लगातार काम किया है, इसलिए मैंने यह देखने का फैसला किया कि क्या नेट-आधारित फ़ाइल एक्सप्लोरर ऐप उसी परिणाम को प्रतिबिंबित करता है जैसा कि मैं नकली और पावरशेल के साथ देख रहा हूं। "नोमैड" नामक एक नेट-आधारित फ़ाइल एक्सप्लोरर है जिसे मैंने डाउनलोड करना और परीक्षण करना समाप्त कर दिया और परिणाम नकली और पावरशेल के अनुरूप थे। app_offline.htm फ़ाइल बनाने पर, प्रक्रिया बंद नहीं हुई। मैंने फिर फ़ाइल का नाम बदल दिया और उसका नाम बदलकर app_offline.htm कर दिया और फिर कोर प्रक्रिया बंद हो गई।

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

मुझे लगता है कि यह विधि "FILE_NOTIFY_CHANGE_CREATION" ध्वज को शामिल करना चाहेगी।

मुझे आश्चर्य है कि नकली, पावरशेल और घुमंतू के लिए सामान्य नेट एपीआई सामान्य फ़ाइल निर्माण के समान ही इन अन्य झंडे को ट्रिगर नहीं करता है।

@shirhatti क्या आप कृपया सुनिश्चित कर सकते हैं कि कोई इस संभावित ANCM मुद्दे की जाँच करे?

@davidebbo एके। हम इसमें देख रहे हैं

मेरे पास एक बहुत ही समान समस्या है। अगर मैं विंडोज एक्सप्लोरर में एक app_offline.htm फ़ाइल में कॉपी करता हूं तो यह प्रक्रिया को सही ढंग से रोकता है, लेकिन अगर मैं इसे अपने बिल्ड सर्वर से COPY app_offline.htm \server\share\siteapp_offline.htm का उपयोग करके बनाता हूं तो यह बंद नहीं होता है और फाइलें लॉक रहती हैं .

@ गुलबनाना मेरे पास ठीक वैसा ही मुद्दा है जैसा आप करते हैं। क्या आपने इसे पहले ही हल कर लिया है? @shirhatti आपकी जांच पर कोई अपडेट? यह टीम को पागल कर देता है क्योंकि सीआई पाइपलाइन हर समय फ़ाइल कॉपी विफलताओं के कारण विफल हो जाती है जो बदले में dotnet.exe द्वारा app_offline.htm द्वारा बंद नहीं होने के कारण होती है।

मैंने echo "<html>page content</html>" > \\server\share\app_offline.htm की तर्ज पर कुछ का उपयोग करके इस मुद्दे के आसपास काम किया। मुझे लगता है कि @derekgrier सही है कि बग एएनसीएम के बारे में है जो फ़ाइल निर्माण के केवल कुछ तरीकों को देख रहा है, और यह इसे पकड़ता है।

@ डेरेकग्रीर
मैं अब मामले को देख रहा हूं। मेरी परीक्षण मशीन में आपके एक रेप्रो कमांड के साथ, मैं इस समस्या को पुन: उत्पन्न करने में सक्षम था। मैंने नीचे कमांड का इस्तेमाल किया। (नोट: नीचे दिया गया कमांड खाली (फाइल साइज जीरो) फाइल बनाएगा।

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"

क्या आप पुष्टि कर सकते हैं कि क्या आप अपने रेप्रो पर्यावरण पर एक ही लक्षण देखते हैं?
यदि ऐसा है, तो मुझे लगता है कि यह समस्या केवल तब होती है जब खाली app_offline.htm कुछ विशेष तरीके से बनाया जाता है जैसे कि new-item powerhell कमांड का उपयोग करना।

@गुलबनाना
मैं इस मुद्दे को कॉपी कमांड के साथ पुन: पेश नहीं कर सकता। क्या आप अपने रेपो के बारे में अधिक विस्तार से बता सकते हैं? यह बहुत अच्छा होगा यदि आप कुछ रेप्रो चरण पा सकते हैं जिसके साथ मैं अपनी परीक्षण मशीन पर उसी समस्या को पुन: उत्पन्न कर सकता हूं।

मैं पुष्टि कर सकता हूं कि यह उन आदेशों को चलाए बिना app_offline.htm फ़ाइल खाली है या नहीं, क्योंकि हमारा अनुभव वांछित सामग्री वाली फ़ाइल को डिप्लॉय फ़ोल्डर में कॉपी करने के साथ रहा है। मेरे अनुभव के आधार पर, मुझे लगता है कि दूसरी कमांड फ़ाइल बदली हुई घटना का कारण बन सकती है यदि यह वास्तव में काम कर रही है। शायद यह फ़ाइल बनाता है और बाद में इसे सामग्री के साथ अद्यतन करता है। भले ही, प्रत्येक .net-संबंधित प्रक्रिया जिसका उपयोग मैंने केवल सामग्री के साथ या बिना फ़ाइल बनाने के लिए किया है, प्रक्रिया शटडाउन को ट्रिगर करने में विफल रहता है।

@shirhatti कोई अपडेट? क्या आप यह पुष्टि करने में सक्षम थे कि आपका कोड "FILE_NOTIFY_CHANGE_CREATION" ध्वज का उपयोग करना चाहिए?

@derekgrier हम अंतिम पहुंच और परिवर्तन विशेषताओं को छोड़कर हर वैध ध्वज को सुन रहे हैं।
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

@moozzyk @derekgrier पुष्टि के लिए धन्यवाद। ठीक है, मैंने यह भी पाया कि समस्या सीधे खाली फ़ाइल सामग्री से संबंधित नहीं है। मूल कारण का पता लगाने के बाद मैं आपको अपडेट करूंगा।

@jhkimnew मेरे पास अब सटीक टूटा हुआ सेटअप नहीं है, लेकिन मैं विशिष्टताओं का वर्णन कर सकता हूं:

• IIS विंडोज़ सर्वर 2008 r2 पर चल रहा है, ANCM का उपयोग करके asp.net कोर एप्लिकेशन की मेजबानी कर रहा है
• बिल्ड सर्वर भी 2008r2 है, उसी डोमेन पर
• IIS सर्वर की अपनी वेबसाइट की भौतिक निर्देशिका है जिसे विंडोज़ साझाकरण का उपयोग करके साझा किया गया है
• डोमेन उपयोगकर्ता (बिल्ड सर्वर का खाता) बिल्ड सर्वर पर एक पॉवरशेल स्क्रिप्ट चलाता है
  यदि यह स्क्रिप्ट किसी अन्य निर्देशिका में किसी मौजूदा फ़ाइल से ऐप_ऑफ़लाइन में कॉपी करने के लिए विंडोज़ कॉपी कमांड का उपयोग करती है, तो होस्टिंग प्रक्रिया बंद नहीं होती है। यदि स्क्रिप्ट इसके बजाय "इको" का उपयोग करती है (जो एक mingw इंस्टॉल से/बिन/इको हो सकती है, मुझे यकीन नहीं है) तो होस्टिंग प्रक्रिया बंद हो जाती है।

मुझे संदेह है कि समस्या यह है कि उस तरह की रिमोट कॉपी द्वारा कौन सी फ़ाइल विशेषताएँ अपडेट की जाती हैं या अपडेट नहीं की जाती हैं

@गुलबनाना बस स्पष्ट होने के लिए, आपने डॉस कॉपी कमांड के साथ प्रयास किया, न कि पावर शेल कॉपी-आइटम कमांडलेट? मुझे नहीं लगता कि मैंने नियमित डॉस कॉपी की कोशिश की, लेकिन मैंने पाया कि मेरे द्वारा इस्तेमाल किया गया कोई भी .net आधारित ऐप काम नहीं कर रहा था।

जब तक कि पॉवरशेल के पास इसके लिए एक उपनाम नहीं है, यह डॉस कॉपी था

मेरे मामले में, पावरशेल कॉपी dotnet.exe प्रक्रिया को बंद नहीं करेगी, लेकिन इको, जो आउट-कंटेंट का उपनाम है, काम करता है। मुझे लगता है कि यह एक .NET मुद्दा होने की संभावना नहीं है, लेकिन नेटवर्क कॉपी क्यों काम नहीं करती है, इस बारे में अधिक जानकारी

मैंने जांच की कि क्या aspnetcore.dll (ANCM) परिवर्तन अधिसूचना में कोई समस्या है, लेकिन जब मैंने app_offline.htm को मैन्युअल रूप से या तो powerhell cmdlet या DOS कमांड का उपयोग करके ड्रॉप करने का प्रयास किया, तो मैं समस्या को पुन: उत्पन्न करने में असमर्थ था। और मुझे एक लापता बिंदु मिला जिसकी चर्चा यहां नहीं की गई थी।
यह सुंदर बंद के बारे में है। HttpPlatformHandler" के विपरीत, ANCM ग्रेसफुल शटडाउन का समर्थन करता है, जिसका अर्थ है कि जब app_offline.htm को रूट डायरेक्टरी पर छोड़ दिया जाता है, तो ANCM बैकएंड प्रक्रिया के लिए एक Crtrl-C/Break सिग्नल भेजता है और 10 सेकंड तक प्रतीक्षा करता है जिससे ग्रेसफुल शट डाउन होता है।
10 सेकंड डिफ़ॉल्ट मान है और उपयोगकर्ता ANCM कॉन्फ़िगरेशन सेटिंग्स के शटडाउनटाइमलिमिट के साथ मान को समायोजित कर सकते हैं। यदि कॉन्फ़िगर किए गए शटडाउन टाइमलिमिट में बैकएंड प्रक्रिया शटडाउन नहीं है, तो एएनसीएम को बैकएंड प्रक्रिया को मारना चाहिए।

यह जाँचते हुए कि MSDeploy प्रकाशन ANCM ग्रेसफुल शटडाउन से कैसे संबंधित है, मुझे अंत में एक सुसंगत रेप्रो चरण मिला, जो शटडाउन समय (5 सेकंड) को बढ़ाना है और देखा कि MSDeploy डिफ़ॉल्ट रूप से केवल 2 बार पुनर्प्रयास करता है और केवल 2 सेकंड प्रतीक्षा करता है और अंततः प्रकाशित करने में विफल रहता है क्योंकि यह सुंदर शटडाउन समय की प्रतीक्षा नहीं करता है।

@vijayrkn
एस्पनेटकोर वेब एप्लिकेशन को शुरू करने और समाप्त करने के दोनों स्थानों पर 5 सेकंड की देरी के बाद, मैं उसी त्रुटि को पुन: उत्पन्न करने में सक्षम था, जो इस मुद्दे में रिपोर्ट किया गया था, स्थानीय आईआईएस सर्वर पर एस्पनेटकोर वेब एप्लिकेशन को प्रकाशित करने के दूसरे परीक्षण में। मैंने नीचे उपयोग की गई प्रकाशन प्रोफ़ाइल को भी संलग्न किया है।
क्या आप बताएंगे कि ऐसा क्यों होता है और इस प्रकाशन समस्या को कैसे ठीक किया जाए, इस बारे में एक सही दिशानिर्देश देंगे? और कृपया इस पर अलग से एक नया मुद्दा बनाएं ताकि आपकी टीम उपयोगकर्ता अनुभव को बढ़ाने के लिए इस मुद्दे को ट्रैक कर सके।

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

MSDeploy app_offline को छोड़ने के ठीक बाद परिनियोजित करने का प्रयास करता है। यदि प्रक्रिया को रोकने में देरी होती है, तो परिनियोजन विफल हो सकता है।

इस एमएसबिल्ड प्रॉपर्टी (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>

@vijayrkn

जानकारी के लिए धन्यवाद। नीचे दो पंक्तियों को जोड़ने के बाद, मुझे समान रेप्रो वातावरण के साथ कोई समस्या नहीं दिख रही है।
<EnableMSDeployAppOffline>True</EnableMSDeployAppOffline> <RetryAttemptsForDeployment>10</RetryAttemptsForDeployment>

इसलिए, जो कोई भी इसी तरह की समस्या में चलता है, उसे उचित मूल्य के साथ RetryAttemptsForDeployment गिनती बढ़ाने की आवश्यकता होगी और यदि वह समस्या को हल कर सकता है तो पुनः प्रयास करें।

नोट: मैंने EnableMSDeployAppOffline को जोड़ने का कारण यह है कि यह डिफ़ॉल्ट रूप से अक्षम है जब स्थानीय IIS सर्वर का उपयोग aspnetcore वेब एप्लिकेशन को प्रकाशित करने के गंतव्य के रूप में किया जाता है। इसलिए, यदि आप सुनिश्चित नहीं हैं कि यह आपके परिवेश में सक्षम है या नहीं, तो आपको बस लाइन भी जोड़नी होगी और इसलिए मैंने इसे आपकी जानकारी के लिए यहां जोड़ा है।

बस यह सुनिश्चित करने के लिए कि हाल की चर्चाओं के कारण मूल मुद्दा खो न जाए, मेरी टीम ने जिस मुद्दे का अनुभव किया वह निश्चित रूप से समय का मुद्दा नहीं है। हमने मैन्युअल रूप से app_offline.htm फ़ाइल को Powershell, Fake, और "Nomad" नामक .Net-आधारित फ़ाइल एक्सप्लोरर दोनों के माध्यम से बनाने का परीक्षण किया है और यह प्रक्रिया बंद नहीं होती है चाहे आप कितनी भी देर प्रतीक्षा करें। फ़ाइल एक्सप्लोरर, एक डॉस बैच फ़ाइल, या एक बैश स्क्रिप्ट (यानी गैर .नेट लाइब्रेरी-आधारित प्रक्रियाओं) के माध्यम से फ़ाइल बनाने से प्रक्रिया 1-2 सेकंड के भीतर बंद हो जाती है।

यह इंगित करने लगता है:

1. समस्या नेटवर्क से संबंधित नहीं है (सभी परीक्षण दूरस्थ फ़ाइल साझा के विरुद्ध किए गए थे)
2. यह एक सुंदर शटडाउन/समय का मुद्दा नहीं है

तथ्य यह है कि app_offline.htm फ़ाइल बनाने की 3 गैर-.नेट विधियों ने प्रक्रिया को मज़बूती से और तेज़ी से बंद कर दिया है और फ़ाइल बनाने के 3 .Net-लाइब्रेरी आधारित तरीकों का परिणाम कभी भी हमारे परीक्षणों में बंद होने की प्रक्रिया में नहीं होता है। , मेरे लिए वास्तव में बड़ा संकेतक।

@ डेरेकग्रीर
मैं "घुमंतू" के साथ भी इस मुद्दे को पुन: पेश नहीं कर सकता।
यहाँ मैंने अपने विंडोज 10 (amd64) मशीन पर क्या किया है।

1. आईआईएस स्थापित करें
2. विजुअल स्टूडियो 2017 स्थापित करें
3. एक AspnetCore वेब एप्लिकेशन बनाएं और MSDeploy के साथ स्थानीय IIS सर्वर पर तैनात करें
4. घुमंतू v3.2.0.2890 स्थापित करें (http://www.nomad-net.info/downloads)
5. वेब एप्लिकेशन को एक अनुरोध भेजें
6. कार्य प्रबंधक खोलें और पुष्टि करें कि dotnet.exe प्रक्रिया चल रही है
7. घुमंतू खोलें और वेब एप्लिकेशन की रूट निर्देशिका पर app_offline.htm नाम की एक नई फ़ाइल बनाएं
8. कार्य प्रबंधक देखें और सत्यापित करें कि app_offline.htm फ़ाइल बनने पर dotnet.exe प्रक्रिया समाप्त हो गई है

क्या आप सटीक रेप्रो कदम देंगे ताकि मैं इस मुद्दे को पुन: पेश करने के लिए अनुसरण कर सकूं?

इस तथ्य के अलावा कि हमारा नेट कोर एप्लिकेशन वास्तव में वीएस 2015 में बनाया गया एक मानक .Net 4.5.2 कंसोल एप्लिकेशन है जो एएसपी.नेट कोर असेंबली का संदर्भ देता है, मुझे कोई अंतर नहीं दिखता है। यह परियोजना अब लगभग एक वर्ष पुरानी है और उस समय इस तरह से स्थापित की गई थी क्योंकि .Net फ्रेमवर्क टेम्पलेट प्रोजेक्ट प्रकारों से कोर टेम्प्लेट प्रोजेक्ट प्रकारों और .Net कोर के लिए विभिन्न प्रकार के परीक्षण पुस्तकालय समर्थन के संदर्भ में सीमाएं थीं।

हमने कुछ मुद्दों की पहचान की: 1) app_offline.htm फ़ाइल को छोड़ना (कुछ टूल का उपयोग करके) कभी-कभी केवल ट्रिगर फ़ाइल संपत्ति परिवर्तन अधिसूचना जिसे एएनसीएम द्वारा फ़िल्टर किया गया था। 2) ANCM app_offline.htm को पढ़ने में विफल हो सकता है क्योंकि बाद वाला फ़ाइल कॉपी टूल द्वारा आयोजित किया गया था। 3) सुंदर शटडाउन के कारण बैकएंड प्रक्रिया को समाप्त करने में देरी हुई।
हम अगली रिलीज में पहले दो मुद्दों को संबोधित करेंगे। सुंदर शटडाउन मामले के लिए, उपयोगकर्ता को पुनः प्रयास करने की आवश्यकता है।

सुनने में तो अच्छा लगता है। मेरा मामला निश्चित रूप से एक सुंदर शटडाउन टाइमआउट के बारे में नहीं था - जब यह बंद हो जाता है तो यह तुरंत बंद हो जाता है।

इस मुद्दे पर कोई अपडेट?
ASP.NET Core 1.1 ऐप को VSTS का उपयोग करके Azure वेब ऐप स्लॉट में परिनियोजित करने का प्रयास करते समय प्राप्त करना

• मेरे पास एप्लिकेशन सेटिंग्स में MSDEPLOY_RENAME_LOCKED_FILES=1 सेट है
• ऐप को ऑफ़लाइन लेने के लिए ऐप सेवा कार्य प्रबंधित करें कॉन्फ़िगर किया गया है
• ऐप को ऑफ़लाइन लेने के लिए कॉन्फ़िगर किया गया ऐप सेवा कार्य _was_ परिनियोजित करें, लेकिन वह भी काम नहीं किया

मुख्य मुद्दा यह है कि डीएलएल उपयोग में है:

@ChuckkNorris कृपया इस पर नवीनतम जानकारी के लिए https://github.com/Microsoft/vsts-tasks/issues/1607 देखें।

@davidebo आपके उत्तर के लिए धन्यवाद, डेविड। मैंने उस धागे को देखा और यहीं से मैंने अपने द्वारा आजमाए गए कई वर्कअराउंड की खोज की।

चूंकि यह समस्या अभी भी खुली है और त्रुटि अभी भी प्रचलित है, मैं उम्मीद कर रहा था कि जल्द ही कोई समाधान हो सकता है, कोई अन्य समाधान नहीं। यह मुद्दा अब दो साल से अधिक समय से खुला है।

@ChuckkNorris जबकि लक्षण समान है, यह वही मुद्दा नहीं है:

• app_offline.htm के केसिंग से संबंधित मूल समस्या, जिसके कारण इसे पूरी तरह से नज़रअंदाज कर दिया गया। यह कुछ समय के लिए तय किया गया है।
• यह नया मुद्दा सिर्फ एक हफ्ते पहले शुरू हुआ था, और ऐसा इसलिए होता है क्योंकि अब कोर को बंद होने में अधिक समय लगता है जब app_offline.htm बनाया जाता है, और डिफ़ॉल्ट रूप से msdeploy लंबे समय तक प्रतीक्षा नहीं करता है। समाधान पुनर्प्रयासों की संख्या को बढ़ाना है।

मैंने अभी वीएस 2017 को 15.3 पर अपडेट किया है और .NET कोर 2.0 एसडीके स्थापित किया है। वीएस में एक साधारण एमवीसी ऐप बनाया - यह netcoreapp1.1 को लक्षित कर रहा था। मैंने Azure को प्रकाशित किया, और सब कुछ ठीक था। मैंने newcoreapp2.0 में अपग्रेड किया और फिर सभी नगेट पैकेजों को 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

मुझे अपने 2.0 ऐप्स को गिट के माध्यम से तैनात करने और उपयोग के मुद्दों में फ़ाइल को रोकने के लिए MvcViewComplication को अक्षम करना पड़ा है।

https://github.com/Microsoft/vsts-tasks/issues/5259
https://github.com/Microsoft/vsts-tasks/issues/1607#issuecomment -349115532
@davidebbo , क्या हम इस मुद्दे को बंद कर सकते हैं?
वेब परिनियोजन के लिए पुन: प्रयास सहायक जोड़ने के बावजूद, यह समस्या बनी हुई है।

बस स्पष्ट रूप से बताना चाहता था, कि यह एफ़टीपी प्रकाशन को भी प्रभावित करता है।

@jeremycook FTP थोड़ा अलग है, क्योंकि इसमें App_Offline का उपयोग करने के लिए कोई स्वचालन नहीं है। प्रक्रिया को बंद करने के लिए आपको उस फ़ाइल को मैन्युअल रूप से बनाना होगा, जिसके बाद आप फ़ाइलों की प्रतिलिपि बना सकते हैं।

@davidebbo काफी मेला है लेकिन ऐसा लगता है जैसे मैं विजुअल स्टूडियो की प्रकाशन सुविधा का उपयोग करके एफ़टीपी के माध्यम से प्रकाशित करता हूं कि इसे सिर्फ काम करना चाहिए। शायद मैं गलत जगह पोस्ट कर रहा हूँ?

@jeremycook स्पष्ट रूप से, मुझे यकीन नहीं है कि एफ़टीपी परिनियोजन करते समय वीएस क्या करता है। हो सकता है कि अन्य लोग चमक सकें, लेकिन यह ASP.NET की तुलना में VS प्रश्न जैसा लगता है।

हालांकि अलग करने के लिए, यह परीक्षण करना दिलचस्प होगा कि क्या परिनियोजन सफल है यदि आप मैन्युअल रूप से App_Offline.html बनाते हैं, और फिर FTP VS से प्रकाशित करते हैं।

@vijayrkn क्या आप FTP परिनियोजन के दौरान VS व्यवहार पर टिप्पणी कर सकते हैं?

वीएस से ऐप सेवा में प्रकाशित एफ़टीपी ऐप_ऑफलाइन का समर्थन नहीं करता है।

@vijayrkn ठीक है, इसलिए सभी व्यावहारिक उद्देश्यों के लिए, हम कह सकते हैं कि एफ़टीपी के माध्यम से .NET कोर परिनियोजन समर्थित नहीं है, जब तक कि उपयोगकर्ता तैनाती से पहले साइट को स्पष्ट रूप से बंद न कर दे। सही?

@ डेविडबो - हाँ, यह सही है।

आईआईएस वेब परिनियोजन टेम्पलेट का उपयोग करके वीएसटीएस रिलीज से आईआईएस में एएसपीनेट कोर 2.0 वेब ऐप को तैनात करते समय इस समस्या को मारना। फ़ाइल उपयोग में होने के कारण हटाना विफल रहता है। ऐप ऑफलाइन विकल्प सक्षम है।

@davidebbo @vijayrkn @shirhatti यह सब थोड़ा निराशाजनक है। क्या FTP/XCOPY के काम करने की कोई योजना है? क्या एक नया मुद्दा खोला जाना चाहिए जो पुराने जमाने के तरीकों को एफ़टीपी/एक्ससीओपीवाई/रोबोकॉपी/आदि के माध्यम से तैनात करने पर केंद्रित हो?

मुझे इस पार्टी के लिए देर हो चुकी है लेकिन यहां कुछ बिट्स हैं जिन्हें मैं रिपोर्ट करना चाहता हूं:
वीएस 2017 एंटरप्राइज
एएसपीनेट 4.6.xx
सर्वर 2012 R2 . पर IIS 8.5 है
sql सर्वर प्रकार dll लॉक हैं और लॉक ऐसा है जब एक अलग डेवलपर msdeploy के साथ प्रकाशित करता है तो उन्हें एक त्रुटि मिलती है और वेब साइट अब टूट जाती है क्योंकि तैनाती का केवल एक हिस्सा चलता है।

एसक्यूएल प्रकार डीएलएस ऐप बिन फ़ोल्डर में बंद हैं और केवल उन्हें।
डीएलएल फाइलों का नाम बदलें और फिर मैं प्रकाशित कर सकता हूं।
एसक्यूएल प्रकार पैकेजिंग में अप्रबंधित डीएलएस लोड करने के लिए कोड कैन्ड है।
ऐसा लगता है कि उन्हें लॉक न करने के लिए बदला जाना चाहिए। अगर ऐसा किया जा सकता है।

मैंने लोगों को साइट को फिर से शुरू करने या इसे ऑफ़लाइन लेने के तरीकों के बारे में बात करते देखा है, लेकिन मुझे इसके लिए msdeploy में कोई सेटिंग नहीं मिली है। मैंने जो एक्सएमएल देखा है वह मेरी फाइलों में नहीं है।

माइक्रोसॉफ्ट द्वारा प्रकाशित एसक्यूएल प्रकार पैकेज में बेहतर मार्गदर्शन जोड़ा जाना चाहिए।

इस मुद्दे पर पोस्ट करना क्योंकि यह मेरे से अधिक सीधे संबंधित लगता है। मैंने उसी विषय पर नीचे दिए गए मुद्दे का भी पालन किया है, हालांकि यह वीएसटीएस के लिए है। मैं सीधे विजुअल स्टूडियो से प्रकाशित कर रहा हूं।

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

यह मेरे लिए एक चालू और बंद मुद्दा रहा है लेकिन हाल ही में लागू हुआ और मेरी ऐप सेवा साइटों में से एक पर मुझे लगभग सभी प्रकाशन प्रयासों पर यह त्रुटि मिली। यह साइट एक 'बुनियादी' स्तर की सेवा पर होस्ट की गई है, इसलिए मेरे पास ऐसे स्लॉट नहीं हैं जिनका उपयोग मैं इस समस्या को हल करने के लिए अन्य ऐप्स पर करता हूं।

यह एक .NET कोर 2 एमवीसी अनुप्रयोग के लिए है।

एक विचार: कुछ फाइलें जो एक वेब ऐप का हिस्सा हैं, वे हर प्रकाशन (जैसे sql प्रकार) पर नहीं चल रही हैं
लेकिन एमएस परिनियोजन प्रत्येक तैनाती पर उन्हें बदलने की कोशिश कर रहा है।
ऐसा लगता है कि किसी फ़ाइल को दोबारा कॉपी न करने के लिए किसी प्रकार की जांच होनी चाहिए जो बदली नहीं है और इससे अपडेट छोटा और तेज़ हो जाएगा और फ़ाइल लॉकिंग के साथ गड़बड़ करने की आवश्यकता कम होगी।
कई लाभ अगर ऐसा किया जा सकता है।

दूसरी बात यह है कि फ़ाइल को लॉक करने की बेहतर पहचान करना और उसे क्यों और कैसे पूर्ववत करना है।
और इसे मानक परिनियोजन पाइपलाइन के एक भाग के रूप में प्राप्त करें।

@figuerres मैं अब कुछ महीनों से उस मुद्दे से निपटना चाहता हूं। शैडो कॉपीिंग के कारण आम तौर पर लॉकिंग मुद्दों से बचा जाता है, लेकिन उन मूल डीएलएल को ~/bin से लोड करके, एक लॉकिंग समस्या बनाई जाती है। मेरे पास एक संभावित समाधान है, लेकिन मुझे यकीन नहीं है कि यह पूरी तरह से सुरक्षित समाधान है: https://stackoverflow.com/questions/47796553/is-it-safe-to-manually-copy-native-dlls-to- ए-छाया-प्रति-निर्देशिका

मैं सहमत हूं कि NuGet पैकेज के लिए प्रलेखन को एक बेहतर तरीका प्रदान करना चाहिए, एक ऐसा जो लॉकिंग मुद्दों का कारण नहीं बनता है।

@figuerres FYI करें, मैंने उपरोक्त लागू किया है, कोड के लिए स्टैक ओवरफ़्लो प्रश्न देखें।

कार्य प्रबंधक में dotnet.exe को मारें

यहां क्या स्थिति है? 3 साल हो गए, अभी तक तय नहीं मुझे मैन्युअल रूप से सर्वर पर जाना है और वेबसाइट को रोकना है।

3 वर्ष? इस मुद्दे को 2017 के अगस्त की सूचना दी गई थी। 1 लाइक व्होआ द्वारा बंद।
सोम पर, अप्रैल 23, 2018 अपराह्न 8:56 ओलिवर जेनिक सूचनाएं @github.com
लिखा था:

यहां क्या स्थिति है? 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 बजे ओलिवर जेनिक सूचनाएं @github.com
लिखा था:

पहली पोस्ट में लिखा है "पेक्का ने 23 जून 2015 को टिप्पणी की"

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की थी।

इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/aspnet/Home/issues/694#issuecomment-383769982 , या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/AAXhfgwYG-jLjnoJF7MCMtzbbfxSZkt2ks5trnqXgaJpZM4FJp_R
.

बंद हो रहा है क्योंकि यह गंदगी जितनी पुरानी है

@Eilon क्षमा करें, लेकिन यह बंद क्यों था? यह अभी भी अनसुलझा है?

बंद हो रहा है क्योंकि यह गंदगी जितनी पुरानी है

लेकिन यह अभी भी एक मुद्दा है ..? (यहां तक ​​​​कि गैर-नीला तैनाती पर भी)

दृश्यता बढ़ाने के लिए एक नया मुद्दा (#3719) बनाया।