Visual Studio बिल्ड फ़ाइल आउटपुट पर लॉक करता है

Question

मेरे पास वीएस 2010 में एक सरल WinForms समाधान है। जब भी मैं इसका निर्माण करता हूं, आउटपुट फाइल (बिन \ डिबग \ app.exe) बंद हो जाती है, और बाद में एक संदेश के साथ विफल हो जाता है जैसे "The process cannot access the file 'bin\Debug\app.exe' because it is being used by another process." कि प्रोजेक्ट बनाने का एकमात्र तरीका वीएस के बाद पुनरारंभ करना है। हर निर्माण, जो बहुत ही अजीब है।

मुझे यह पुराना ब्लॉग पोस्ट http://blogs.geekdojo.net/brian/archive/2006/02/17/VS2005FileLocking.aspx मिला है - ऐसा लगता है कि समस्या वास्तव में पुरानी है। क्या किसी को पता है कि यहाँ क्या हो रहा है, या कम से कम कुछ बदलाव?

अपडेट करें

मैं वास्तव में फ़ाइल नहीं चलाता । लॉकिंग बिल्ड के बाद होता है, डिबग के बाद नहीं (यानी VS शुरू - बिल्ड - बिल्ड - फेल!) और मैंने एंटीवायरस को बंद करने की कोशिश की। यह मदद नहीं करता है।

अपडेट २

प्रोसेस एक्सप्लोरर फ़ाइल को लोड करने में devenv.exe दिखाता है (DLL में, हैंडल में नहीं)। ऐसा लगता है कि निर्माण के दौरान कुछ गड़बड़ ने उतराई को रोका, लेकिन (पहला) निर्माण बिना किसी संदेश के पूरा हो गया, फिर "1 सफल, ओ विफल" /

Comments

कभी-कभी मुझे भी इसी तरह की समस्या होती है; क्या आप विंडोज 7 का उपयोग करते हैं? मेरे मामले में, यह वीएस फाइल को लॉक नहीं कर रहा है: मैं इसे केवल एक्सप्लोरर में हटा सकता हूं, और बिल्ड ठीक चलता है। मैंने देखा कि समस्या अधिक बार होती है अगर मेरे पास आउटपुट निर्देशिका पर एक एक्सप्लोरर विंडो खुली हो। वायरस स्कैनर btw का उपयोग नहीं।

— 21

Win7 पर कभी-कभी समान समस्या आती है, जब NUnit का उपयोग किया जाता है, जो कि जब आप कुछ TDD कर रहे होते हैं तो बहुत कष्टप्रद होता है।

— मथियास

@stijn: ऑन-एक्सेस वायरस स्कैनर का उपयोग नहीं?

— डोहोह

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

— स्टिंगजैक

शायद यह मदद करेगा: सातforums.com/tutorials/…

— शनि टेक्नोलॉजीज

Answer 1

एक ही मुद्दा था, लेकिन एक समाधान मिला ( केवन नैय्यर का धन्यवाद ):

लेकिन इसे कैसे हल किया जाए? आपके प्रोजेक्ट प्रकार के आधार पर विभिन्न तरीके हैं, लेकिन एक सरल समाधान जो मैं विजुअल स्टूडियो ऐड-इन डेवलपर्स को सुझाता हूं, वह है उनके प्रोजेक्ट के बिल्ड ईवेंट में एक साधारण कोड जोड़ना।

आप अपने प्रोजेक्ट के प्री-बिल्ड इवेंट कमांड लाइन में कोड की निम्न पंक्तियाँ जोड़ सकते हैं।

if exist "$(TargetPath).locked" del "$(TargetPath).locked"
if exist "$(TargetPath)" if not exist "$(TargetPath).locked" move "$(TargetPath)" "$(TargetPath).locked"

Comments

मेरे लिए भी काम किया। अब कुछ समय के लिए वह मुद्दा रहा है।

— अनुष्ठान

यह मेरे लिए काम करता है। मैंने नीचे व्लादिमीर दत्सयुक के अनुसार इसके% यादृच्छिक% संस्करण की कोशिश की, लेकिन पाया कि मेरे मामले में केवल लॉक की जा रही फ़ाइल VS शुरू करने के बाद पहले बिल्ड से है, इसलिए इसे केवल एक बार काम करने की आवश्यकता है। मैं वीएस 2013 पर हूं, और जीआईआई डिजाइनर का उपयोग नहीं कर रहा हूं, बस बहुत सारे संदर्भ और टी 4 टेम्पलेट परियोजनाओं के साथ एक बड़ा समाधान है।

— दावोस

: के रूप में यह भी ताला लगा हुआ था मैं भी PDB नाम बदलने की जरूरत है if exist "$(TargetDir)$(TargetName).pdb.locked" del "$(TargetDir)$(TargetName).pdb.locked" ,if exist "$(TargetDir)$(TargetName).pdb" if not exist "$(TargetDir)$(TargetName).pdb.locked" move "$(TargetDir)$(TargetName).pdb" "$(TargetDir)$(TargetName).pdb.locked"

— टोबियास जम्मू

मेरे लिए भी काम करता है (विजुअल स्टूडियो 2013)। Thx

— बेनामी

VS2017 पर काम करता रहता है। क्या आश्चर्य की बात है कि समस्या VS2017 में बनी हुई है!

— कार्वो लोको

Answer 2

यह वायरस का मुद्दा नहीं है। यह दृश्य स्टूडियो 2010 बग है। ऐसा लगता है कि यह मुद्दा दृश्य स्टूडियो गुई डिजाइनर का उपयोग करने से संबंधित है।

पूर्व-निर्मित ईवेंट में लॉक आउटपुट फ़ाइल को किसी अन्य अस्थायी में स्थानांतरित करने के लिए यहां समाधान है। यह बेतरतीब ढंग से अस्थायी फ़ाइल नाम उत्पन्न करने के लिए समझ में आता है।

del "$(TargetPath).locked.*" /q 
if exist "$(TargetPath)"  move "$(TargetPath)" "$(TargetPath).locked.%random%"
exit /B 0

निरंतर अस्थायी फ़ाइल नामों का उपयोग करने के मामले में आप सिर्फ ताले को स्थगित करेंगे:

यह वर्कअराउंड ठीक एक बार काम करता है

 if exist "$(TargetPath).locked" del "$(TargetPath).locked"
    if exist "$(TargetPath)" if not exist "$(TargetPath).locked" move "$(TargetPath)" "$(TargetPath).locked"

मुझे 2 अस्थायी फ़ाइलों के साथ एक समाधान भी मिला है जो ठीक 2 बार काम करता है।

Comments

यह मेरे साथ भी होता है, लेकिन केवल तभी जब मैं अपना ऐप चलाता हूं। मुझे संदेह है कि यह कैशिंग या जो भी कारणों के लिए निष्पादन योग्य है उस पर नजर रखते हुए ओएस है। इसके अलावा, यह केवल उन ऐप्स के लिए होता है जो System.Reflection.Assembly.GetExecutingAssembly () को कॉल करते हैं, कम से कम मेरे मामले में।

— TheBlastOne

ठीक है, ऐसा लगता है कि यह केवल तभी होता है, जब अंतिम नाम System.Reflection.Assembly.GetExecutingAssembly, या -और वह समाचार है- यदि कोई डिज़ाइन-टाइम घटक का स्रोत कोड (किसी भी डिज़ाइन-टाइम घटक का स्रोत कोड जो घटक टूलबार में सक्रिय है) जो कि System.Reflection.Assembly.GetExecutingAssembly के लिए कॉल करता है, डिज़ाइन-टाइम के दौरान संपादक अंतिम संस्करण शुरू होने पर खुला था। समझ गया?

— TheBlastOne

मुझे लगता है कि यह समस्या अचानक दिखाई दी ... अब मैंने अपने जीवन के 30 मिनट बर्बाद कर दिए हैं एक प्रोजेक्ट सेटअप बनाने की कोशिश कर रहा हूं .. क्योंकि मुझे लॉकिंग समस्याएं आती हैं! मैं भी आवेदन नहीं चला ..

— गोरिल्ला एप

stackoverflow.com/questions/3312646/… जिसने मेरे लिए काम किया

— गोरिल्लाएप

Pbd फ़ाइल के लिए अतिरिक्त: del "$(TargetPath).locked.*" /q if exist "$(TargetPath)" move "$(TargetPath)" "$(TargetPath).locked.%random%" del "$(TargetDir)$(TargetName).pdb.locked.*" /q if exist "$(TargetDir)$(TargetName).pdb" move "$(TargetDir)$(TargetName).pdb" "$(TargetDir)$(TargetName).pdb.locked.%random%" exit /B 0

— Marv

Answer 3

समस्या मुझे भी हुई।

मेरा परिदृश्य यह था: रनिंग विंडो 7 (लेकिन विंडोज एक्सपी में भी हो सकता है) और WPF उपयोगकर्ता नियंत्रण के साथ एक परियोजना पर काम करते समय मैं सभी समय का निर्माण कर सकता था, जब तक कि उपयोगकर्ता नियंत्रण के XAML फ़ाइल को खोलने से - वहाँ से, मैं ' एक निर्माण हो गया, और फिर फ़ाइलें बंद हैं।

इसके अलावा, मैंने देखा है कि मैं विजुअल स्टूडियो (Devenv.exe) को प्रशासक के रूप में चला रहा था, मैंने प्रशासक के विशेषाधिकारों के बिना विजुअल स्टूडियो चलाना शुरू कर दिया है और समस्या दूर हो गई है! ।

मुझे पता है अगर यह आपकी भी मदद की। सौभाग्य।

Comments

मैं सभी वीएस 11 रिलीज में यह ठीक वही मुद्दा रहा है, लेकिन अभी तक एक ठीक करने में कामयाब नहीं हुआ है (दुर्भाग्य से व्यवस्थापक विशेषाधिकार के बिना जाने से मदद नहीं मिली)। किसी भी विचारों की सराहना की!

— दान नोलन

Answer 4

मैं या तो एक लालची वायरस स्कैनिंग सॉफ्टवेयर पर देखा है, या अगर app.exe ठीक से बंद नहीं कर रहा है। सुनिश्चित करें कि प्रक्रिया अभी भी नहीं चल रही है।

Answer 5

आपकी मशीन पर वायरस स्कैनर के बारे में क्या? क्या आप ऐसी कोई प्रक्रिया देख सकते हैं जो आपकी फ़ाइल को संभाल रही हो ( पता लगाने के लिए प्रोसेस एक्सप्लोरर का उपयोग करें )?

हो सकता है कि आपकी प्रक्रिया सूची में "app.exe" दिखाई दे, यानी आपके द्वारा डीबग किया गया अंतिम संस्करण अभी भी चल रहा है? जब आप ऐसे एप्लिकेशन विकसित करते हैं जिनमें कई थ्रेड होते हैं, तो ऐसा हो सकता है यदि आप joinउन सभी को नहीं करते हैं।

Answer 6

मुझे भी यही समस्या थी और मुझे पता चला, कि वीएस केवल तभी एक्सई को लॉक करता है, जब मैंने बिल्डिंग से पहले वीएस में फॉर्म या यूजरकंट्रोल खोला था। समाधान काफी आसान था, मुझे समाधान बनाने से पहले किसी भी फॉर्म / यूजरकंट्रोल को बंद करना पड़ा और यह काम कर गया।

Answer 7

स्टॉर्मनेट के महान उत्तर के आधार पर , मैंने एक छोटी स्क्रिप्ट रखी जो सभी मामलों में काम करे।

यहां प्री बिल्ड इवेंट टेक्स्ट बॉक्स में डालने के लिए कोड है

$(SolutionDir)\BuildProcess\PreBuildEvents.bat  "$(TargetPath)"  "$(TargetFileName)"  "$(TargetDir)"  "$(TargetName)"

यहाँ फाइल में कॉपी करने की स्क्रिप्ट है $(SolutionDir)\BuildProcess\PreBuildEvents.bat (निश्चित रूप से आप इस पथ को संशोधित कर सकते हैं):

REM This script is invoked before compiling an assembly, and if the target file exist, it moves it to a temporary location
REM The file-move works even if the existing assembly file is currently locked-by/in-use-in any process.
REM This way we can be sure that the compilation won't end up claiming the assembly cannot be erased!

echo PreBuildEvents 
echo  $(TargetPath) is %1
echo  $(TargetFileName) is %2 
echo  $(TargetDir) is %3   
echo  $(TargetName) is %4

set dir=C:\temp\LockedAssemblies

if not exist %dir% (mkdir %dir%)

REM delete all assemblies moved not really locked by a process
del "%dir%\*" /q

REM assembly file (.exe / .dll) - .pdb file - eventually .xml file (documentation) are concerned
REM use %random% to let coexists several process that hold several versions of locked assemblies
if exist "%1"  move "%1" "%dir%\%2.locked.%random%"
if exist "%3%4.pdb" move "%3%4.pdb" "%dir%\%4.pdb.locked%random%"
if exist "%3%4.xml.locked" del "%dir%\%4.xml.locked%random%"

REM Code with Macros
REM   if exist "$(TargetPath)"  move "$(TargetPath)" "C:\temp\LockedAssemblies\$(TargetFileName).locked.%random%"
REM   if exist "$(TargetDir)$(TargetName).pdb" move "C:\temp\LockedAssemblies\$(TargetName).pdb" "$(TargetDir)$(TargetName).pdb.locked%random%"
REM   if exist "$(TargetDir)$(TargetName).xml.locked" del "C:\temp\LockedAssemblies\$(TargetName).xml.locked%random%"

Answer 8

एक ज्ञात समस्या 533411 भी है जहां बिल्ड नंबरों को स्वचालित रूप से अपडेट करने का उपयोग लॉकिंग समस्या का कारण बन सकता है। बग रिपोर्ट से समाधान

पुनर्निर्माण के बाद अस्थायी वर्कअराउंड असेंबली संस्करण अद्यतन अक्षम हो जाएगा। AssemblyInfo.cs फ़ाइल में, वाइल्ड कार्ड AssemblyVersion विशेषता से, हटाने उदाहरण के लिए:
: की जगह इस
[: AssemblyVersion विधानसभा ( "1.4 *।")]
[विधानसभा AssemblyFileVersion ( "1.4")]
इस के साथ:
[विधानसभा: AssemblyVersion ("1.4.0.0")]
[असेंबली: असेम्बली फ़ाइलवेशन ("1.4.0.0")]

Answer 9

मुझे यह समस्या थी और इसे कुछ कस्टम कोड के साथ हल किया। यहाँ देखें: Visual Studio 2010 बिल्ड फ़ाइल लॉक समस्याएँ

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

कस्टम कोड का कारण यह था कि अक्सर सुझाए गए समाधान केवल एक बार काम करते थे और फिर नाम बदलने वाली फाइलों को भी लॉक कर दिया जाता था, जिससे नाम बदल दिया जाता था। यहाँ हम फ़ाइल में डेटा-टाइम जानकारी संलग्न करते हैं ताकि नामांकित संस्करण संघर्ष न कर सकें।

Answer 10

केवल एक चीज जो मेरे लिए काम करती थी वह थी विजुअल स्टूडियो 2012 को छोड़ना, प्रॉब्लम होने वाले प्रॉजेक्ट के लिए BIN और OBJ फोल्डर को डिलीट करना और विजुअल स्टूडियो को फिर से खोलना।

समस्या हल हो गई ... अगली बार तक

Answer 11

यदि आपका $ (TargetPath) एक DLL को इंगित करता है जो COM का उपयोग करता है तो सुनिश्चित करें कि आपके पास एक डिफ़ॉल्ट निर्माता है। यह निश्चित नहीं है कि डिफ़ॉल्ट कंस्ट्रक्टर का अनुमान क्यों नहीं है। डिफ़ॉल्ट निर्माता को इस परिदृश्य में मेरे लिए जोड़ने का काम किया।

Answer 12

दृश्य स्टूडियो को बंद करना, फिर से खोलना और सबसे हालिया समाधान को फिर से लोड करना मेरे लिए समस्या के आसपास काम करता है। (विजुअल स्टूडियो 2013 अल्टीमेट)

Comments

हाँ, मुझे ऐसा हर बार करना होगा। इसका कोई हल नहीं है

— जॉन डेमेट्रियो

Answer 13

मैं VS2017 में xamarin एप्लिकेशन विकसित करने के लिए एक ही चीज़ में भाग गया।

ऐसा हुआ कि विंडोज डिफेंडर ने devenv.exe के साथ exe / dll को लॉक किया।

आप विन डिफेंडर में जा सकते हैं और जोड़ सकते हैं

devenv.exe
msbuild.exe

प्रक्रिया बहिष्करण सूची में।

Comments

आपको यह कैसे पता चला कि यह विंडोज़ डिफेंडर था?

— माइक

मेरे समाधान ने थोड़ा काम किया लेकिन मुझे पता चला कि यह वास्तव में मेरे लिए एक नए VS2017 अपडेट रिलीज़ में एक प्रमुख बग था। developercommunity.visualstudio.com/content/problem/54945/...

— माइकल जी

Answer 14

यह समाधान है जो मुझे पता है

1. नीचे दिखाए गए अनुसार प्रोजेक्ट सेटिंग्स में विज़ुअल स्टूडियो होस्टिंग प्रक्रिया को अनचेक करें

2. निर्वासन को मार डालो। यह taskmanager से आपका applicationname.vshost.exe होगा

3. अब आप आवेदन को फिर से बना सकते हैं और चला सकते हैं।

नोट: आप बिना किसी समस्या के इस विकल्प को फिर से सक्षम कर सकते हैं।

Answer 15

मैं McAfee LiveSafe वास्तविक समय स्कैनिंग अक्षम करके इस समस्या को ठीक करने में कामयाब रहा। मेरी .exe फ़ाइल लॉक हो जाएगी जैसे कि OP वर्णन करता है और मेरे पास फ़ाइल को निकालने का कोई तरीका नहीं होगा, जिसका अर्थ है कि मैं समाधान नहीं बना सकता। McAfee सुविधा को अक्षम करने के बाद समस्या चली गई थी।

फिर मैं निश्चित रूप से McAfee को पूरी तरह से अनइंस्टॉल करने के लिए चला गया, जो केवल इसलिए स्थापित किया गया था क्योंकि मेरा पीसी नया है और यह पहले से इंस्टॉल किए गए प्रोग्राम के साथ आया था।

Answer 16

मैंने एक नया रिक्त समाधान बनाया है और इसमें सभी पुरानी फाइलें जोड़ी हैं। इससे किसी तरह समस्या का समाधान हुआ।

Comments

यह संभवतः उत्तर नहीं हो सकता। अन्य लोगों ने इस समस्या और उपयुक्त कार्यदक्षता के लिए बहुत स्पष्ट कारण प्रदान किए हैं जिन्हें एक नई समाधान फ़ाइल बनाने की आवश्यकता नहीं है जो कि संस्करण नियंत्रण के साथ काम करते समय अस्वीकार्य है क्योंकि इतिहास खो जाएगा।

— बर्नहार्ड हॉफमैन

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

— बात नहीं

एक नया समाधान बनाने से केवल अस्थायी रूप से मेरे लिए समस्या हल हो गई। सबसे अच्छा जवाब व्लादिमीर Datsyuk से एक लगता है।

— user492238

यदि आप एक समाधान में 15 परियोजनाओं को पसंद करते हैं, तो क्या यह समाधान आपके लिए इष्टतम होगा?

— Shittu जोसेफ Olugbenga