2010-03-03 10 views
25

मेरे पास एक एमएसबिल्ड कार्य है जो xcopy को कॉल (अन्य चीजों के साथ) निष्पादित करता है। मुझे जो मिला है वह यह है कि जब मैं अपने एमएसबिल्ड कार्य को बैच फ़ाइल से चलाता हूं तो एक्सकॉपी को यह कॉल सही तरीके से निष्पादित करता है, और किसी आउटपुट को निष्पादित या उत्पन्न करने में विफल रहता है जो मुझे किसी भी विचार को अनुमति देता है कि उसी बैच फ़ाइल को दूसरे से क्या कहा जा रहा है एक सिस्टम के साथ सी # अनुप्रयोग। डायग्नोस्टिक्स.प्रोसेस।सिस्टम.डिग्नोस्टिक्स.प्रोसेस का उपयोग वास्तव में क्या करता है?

दोनों प्रक्रियाओं और अधिक या कम एक ही संरचना के साथ शुरू कर रहे हैं:

waitProc.StartInfo.Arguments = "/C [executable]"; 
waitProc.StartInfo.FileName = "cmd.exe"; 
waitProc.StartInfo.UseShellExecute = false; 

इसके अलावा Xcopy आदेश पर को असत्य से सत्य "UseShellExecute" को बदल कर मैं इस दोनों उपयोग के मामलों में सफल होने के लिए कर सकते हैं, फिर भी आदेश तीसरे उपयोग के मामले में चलाने में विफल रहता है। तीसरा उपयोग मामला हमारी स्वचालित बिल्ड सिस्टम है जो एक विंडोज़ सेवा है जिसे सीधे एमएसबिल्ड कहते हैं। हमारी बिल्ड मशीन पर विफलता के मामले में कॉपी कमांड अनिश्चित काल तक लटका हुआ है, मुझे विश्वास है, क्योंकि System.Diagnostics.Process एक विंडो प्रदर्शित करने का प्रयास करता है, और सेवाओं के पास उनके साथ जुड़े विंडोज डेस्कटॉप सत्र नहीं होते हैं, इसलिए वे नहीं कर सकते खिड़कियां प्रदर्शित करें।

मैंने "CreateNoWindow" प्रॉपर्टी का उपयोग करने का प्रयास किया है, और मैंने "विंडो स्टाइल" को "ProcessWindowStyle.Hidden" पर सेट करने का प्रयास किया है, लेकिन यह बिल्ड मशीन पर व्यवहार को नहीं बदलता है।

यह सब कहा, मैं वास्तव में जानना चाहता हूं कि वास्तव में UseShellExecute प्रॉपर्टी क्या करती है, क्योंकि ऐसा लगता है कि एमएसडीएन दस्तावेज के मुकाबले यह बहुत कुछ है।

धन्यवाद।

+0

हाय क्रिस, क्या आपने कभी इसके साथ आगे बढ़े? मुझे एक समान स्थिति का सामना करना पड़ रहा है: http://stackoverflow.com/questions/7085185/msbuild-buildinparallel-custom-task-spawning-process-that-fails-to-run –

उत्तर

28

ProcessStartInfo.UseShellExecute प्रक्रिया विंडोज शेल का उपयोग करने के लिए निर्दिष्ट आवेदन निष्पादित करने के लिए कहता है।

इस सेट के बिना, आप केवल एक EXE फ़ाइल निष्पादित कर सकते हैं। इसे सेट करके, आप Windows शैल का उपयोग करने की अनुमति देते हैं, जो एक .doc फ़ाइल निर्दिष्ट करने और संबंधित प्रोग्राम को फ़ाइल खोलने जैसी चीजों की अनुमति देता है।

हालांकि, विंडोज शैल का उपयोग करने के लिए एक वैध डेस्कटॉप संदर्भ की आवश्यकता होती है, यही कारण है कि आपका तीसरा उपयोग केस विफल हो जाता है।

सामान्यतः, cmd.exe का उपयोग तब तक समस्याग्रस्त है जब तक कि आप Windows शैल का उपयोग नहीं कर रहे हों। आप सीधे अपने "बैच" ऑपरेशन को संभालने के लिए कोड लिखना चाहते हैं - यानी: अपनी प्रतिलिपि बनाने के लिए System.IO namespace में विधियों का उपयोग करें। यह पूरी तरह से इस मुद्दे से बच जाएगा।

+1

क्या आपको कोई विचार है कि इसकी आवश्यकता क्यों है वैध डेस्कटॉप संदर्भ? मुझे लगता है कि यह मामला था जब यह बिल्ड मशीन पर लटक रहा था, लेकिन मुझे वास्तव में समझ में नहीं आया कि विंडोज शैल को स्क्रीन पर आकर्षित करने की क्षमता क्यों होगी। – Beanz

+4

@ क्रिस: "विंडोज शैल" मूल रूप से एक्सप्लोरर है, और जब आप वास्तव में लॉगिन करते हैं तो लॉन्च किया जाता है। दुर्भाग्यवश, बिल्ड मशीनों पर बैच फाइलों के साथ यह एक आम मुद्दा है - मैंने देखा है कि बहुत से लोग इसके साथ संघर्ष करते हैं, और मैंने इस समस्या से बचने के लिए सीधे सी # में अपनी "स्क्रिप्ट" लिखने के लिए स्विच किया है;) –

+0

इसके अलावा, यदि आप प्रक्रिया के पर्यावरण चर को संशोधित करना चाहते हैं तो आपको 'UseShellExecute' निर्दिष्ट करना होगा। –

1

Documentation से:

गलत पर इस गुण को सेट आप इनपुट, आउटपुट, और त्रुटि धाराओं रीडायरेक्ट करने के लिए सक्षम बनाता है।

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

नोट: 0Sयदि आप ErrorDialog प्रॉपर्टी को पर सेट करते हैं तो UseShellExecute सत्य होना चाहिए। का उपयोग करते समय वर्किंग डायरेक्टरी प्रॉपर्टी अलग-अलग व्यवहार करती है जब UseShellExecute गलत है तो UseShellExecute सत्य है। जब UseShellExecute सत्य है, कार्यशील निर्देशिका संपत्ति निष्पादन योग्य स्थान निर्दिष्ट करती है। यदि वर्किंग डायरेक्टरी एक खाली स्ट्रिंग है, वर्तमान निर्देशिका को निष्पादन योग्य समझा जाता है।

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

0

'UseShellExecute' IIRC के उपयोग, अन्वेषक (मुख्य शेल) प्रक्रिया और नहीं .NET रनटाइम निष्पादित करने के लिए .... जब तक कि किसी ने मुझसे सही करता है कि मैं गलत हूँ अनुमति देने के लिए

+0

यह संपत्ति कंसोल या खोल द्वारा इस ऐप को निष्पादित करने के लिए ऑपरेटिंग सिस्टम को बताती है। – Andrey

+0

@ माइकल - आपने हस्ताक्षर क्यों हटाया? निश्चित रूप से मैंने सोचा था कि मैं कठोर समझा जाने वाले किसी भी व्यक्ति को रखने के बजाय 'सबसे अच्छा संबंध' कहकर विनम्र था .... आपका तर्क क्या है? एफवाईआई - मैंने 800 से अधिक प्रश्नों का उत्तर दिया है और एक शिकायत नहीं है ... जब मैं किसी के प्रश्न का सही उत्तर देता हूं या राजनीतिक सुधार पागल हो जाता है तो मुझे अच्छा धन्यवाद 'धन्यवाद टॉम' मिलता है! आह – t0mm13b

0
है ...

क्या आपने वर्किंग डायरेक्टरी सही तरीके से निर्दिष्ट की है? आप >c:\log.txt 2>c:\err.txt जोड़कर अपने कमांड का वास्तविक आउटपुट देख सकते हैं और इसे जोड़कर

संबंधित मुद्दे