2009-04-23 14 views
7

मान लें कि आपके पास एक क्लास लाइब्रेरी प्रोजेक्ट है जिसमें कई पूरक फाइलें हैं जिन्हें संकलित असेंबली (जैसे साधारण टेक्स्ट फाइलें या यहां तक ​​कि एक विरासत अप्रबंधित डीएलएल भी शामिल है) एक इंटरऑप परत के रूप में असेंबली)। असेंबली में पूरक फाइलों को एम्बेड करते समय relatively straightforward है, हमारे पास ऐसी परिस्थितियां हैं जहां यह संभव नहीं है या केवल अवांछनीय है। हमें उन्हें "साइडकार" फाइलों (यानी असेंबली के साथ फाइलें, संभावित रूप से असेंबली के सापेक्ष उपनिर्देशिका में) की आवश्यकता होती है।बाहरी फ़ाइलों को असेंबली के साथ कैसे संबद्ध करें

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

+0

मैं "टीएफएस निर्भरता प्रतिकृतिकर्ता" का सुझाव देने जा रहा था लेकिन यह केवल साइडकार फाइलों के लिए असेंबली के लिए काम करता है .. – RobS

उत्तर

2

आप al.exe का उपयोग कर सकते हैं, लेकिन एक सी # कंपाइलर विकल्प भी प्रतीत होता है। आप/linkresource सी # कंपाइलर विकल्प का उपयोग कर एक बहुआयामी असेंबली बनाना चाहते हैं। निर्देश here हैं, लेकिन आदेश इस के समान है:

csc /linkresource:N.dll /t:library A.cs 

कहाँ N.dll एक देशी DLL जहाँ भी कामयाब रहे विधानसभा (GAC में भी शामिल है।) चला जाता है जाना होगा कि वहाँ कम से एक बहुत ही स्पष्ट विवरण दिया गया है है लिंक मैंने प्रदान किया।

+0

मैंने पढ़ा है कि लिंक किए गए दस्तावेज़ और कुछ अन्य जिन्हें मैंने बहु-फ़ाइल असेंबली से संबंधित पाया है, लेकिन मुझे अभी भी यकीन नहीं है कि यह मेरे प्रश्न का उत्तर देने के लिए कैसे लागू हो सकता है। क्या आप एक उत्तरदायी असेंबली द्वारा लिपटे एक अप्रबंधित डीएलएल की समस्या को हल करने के लिए इसका उपयोग कैसे किया जा सकता है, इसके बारे में अधिक जानकारी शामिल करने के लिए आप इसका उत्तर संपादित कर सकते हैं, जिसे उच्च स्तर के प्रबंधित के लिए उपयोग के लिए एक सामान्य लाइब्रेरी स्थान में उपलब्ध कराने की आवश्यकता है एक अलग समाधान में मौजूद अनुप्रयोग (यह आसानी से प्रबंधित रैपर का संदर्भ ले सकता है, लेकिन इसमें स्वचालित रूप से अप्रबंधित DLL को इसके आउटपुट डीआईआर में शामिल नहीं किया जाता है)? – iammichael

+0

संपादन के लिए धन्यवाद; ऐसा लगता है कि यह समस्या को हल करने के लिए उपयुक्त हो सकता है। हालांकि, चूंकि इसे सरल दृश्य स्टूडियो से एमएसबिल्ड या अन्य कमांड लाइन-आधारित बिल्ड (लिंक किए गए संदर्भ राज्य "में निर्मित हमारी बिल्ड प्रक्रिया को बदलने की आवश्यकता होगी क्योंकि यह कंपाइलर विकल्प विजुअल स्टूडियो में अनुपलब्ध है और इसे प्रोग्रामेटिक रूप से बदला नहीं जा सकता है।"), I मैं सत्यापित करने के लिए इस समय परीक्षण करने में असमर्थ हूं। हालांकि यह निश्चित रूप से आशाजनक दिखता है। – iammichael

+0

सत्यापित करने में सक्षम नहीं है, ऐसा करने का समय अनुमानित न करें, और फ़ाइलों के लिए कम से कम आदर्श मैन्युअल प्रति का उपयोग करके समाप्त हो गया है, लेकिन यह प्रश्न के वास्तविक उत्तर की तरह लगता है, इसलिए मैं ' मैं स्वीकार कर रहा हूँ – iammichael

1

क्या आपने अपने समाधान के लिए सेटअप बनाने का प्रयास किया है? एप्लिकेशन स्थापना निर्देशिका को लक्षित करने वाली साइडकार फ़ाइलों को शामिल करने का एक विकल्प है।

एक और विकल्प असेंबली संसाधनों में साइडकार फाइलों को शामिल करना होगा और पहली बार चलाने पर उन्हें डिस्क पर लपेटना होगा।

+0

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

+0

हमने वास्तव में इंटरऑप डीएलएस और अन्य संसाधनों के अनचाहे रनटाइम को सफलतापूर्वक किया। हमने इसका उपयोग करके 'पथ द्वारा असेंबली रिज़ॉल्यूशन' हल किया। इससे कोई फर्क नहीं पड़ता कि आप कौन से एप्लिकेशन डोमेन या होस्ट प्रक्रिया से असेंबली निष्पादित करते हैं, यह गतिशील रूप से रनटाइम के दौरान डिस्क पर उन्हें अनचाहे कर देगा और हम हाल ही में असेंबली असेंबली के संदर्भ को हल करेंगे। यह एप्लिकेशन अपडेट वितरित करने में भी उपयोगी पाया गया था। –

+1

क्या आपने एक्जिकिंग उपयोगकर्ता को डिस्क पर इंटरऑप डीएलएल लिखने में असमर्थ होने के साथ किसी अनुमति अनुमति में भाग लिया था? – iammichael

0

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

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

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

+0

हम टीएफएस का उपयोग कर रहे हैं, उपversण नहीं, और फिर भी मुझे यकीन नहीं है कि समस्या हल हो जाती है क्योंकि लाइब्रेरी को संदर्भित करने वाले एप्लिकेशन को व्यक्तिगत साइडकार फ़ाइलों के बारे में जानने की आवश्यकता नहीं है (जो मुझे लगता है कि यदि आप हैं उन्हें आपके विवरण के अनुसार परियोजना संदर्भ के रूप में जोड़ना)। हालांकि, मैं गलत कह रहा हूं कि आप यहां क्या कह रहे हैं। प्री/पोस्ट बिल्ड इवेंट्स के लिए, स्वचालित होने की कमी एक सौदा ब्रेकर की तरह है। लुकास को भी मेरी टिप्पणी देखें, जिन्होंने प्री/पोस्ट-बिल्ड इवेंट्स का भी सुझाव दिया था। – iammichael

+0

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

0

मैं कुछ समय पहले इस से निपटता हूं। यह एक आम समस्या है।

आप कुछ postbuild कार्यों बना सकते हैं:

http://www.codingday.com/execute-batch-commands-before-or-after-compilation-using-pre-build-or-post-build-events/

आशा इस मदद करता है ... :)

+0

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

0

यह है कि आप संदर्भ गलत प्रकार का उपयोग कर रहे हैं मुझे ऐसा लगता है। दो प्रकार के संदर्भ हैं- संदर्भ और परियोजना संदर्भ। संदर्भ एक विशिष्ट असेंबली के लिए एक स्पष्ट संदर्भ है। ProjectReference किसी अन्य प्रोजेक्ट का संदर्भ है (.csproj कहें)।

जो आप खोज रहे हैं वह ProjectReference है। वीएस और डिफ़ॉल्ट MSBuild लक्ष्य CopyLocal करने के लिए सेटअप हैं। यदि आप अपनी "साइडकार" फ़ाइलों के लिए CopyToOutputPath को सही सेट करते हैं, तो इस प्रोजेक्ट के किसी भी प्रोजेक्ट संदर्भ अब भी उसी फाइल में खींचेंगे।

मुझे यकीन नहीं है कि क्या आप आईडीई में समाधानों में प्रोजेक्ट संदर्भों को कर सकते हैं। मैं एमएसबिल्ड के साथ बहुत कुछ सौदा करता हूं जहां एसएलएन फाइलें प्रासंगिक नहीं हैं और इस तरह मैं इससे निपटता हूं।

+0

हाँ, अगर चीजें एक समाधान के भीतर हैं, तो परियोजना का संदर्भ ठीक काम करता है। मैं इस तरह से निहित है कि सवाल में। यह अलग-अलग समाधानों के साथ काम नहीं करता है, न ही लाइब्रेरी प्रोजेक्ट फ़ाइल उपलब्ध नहीं होने पर यह काम करने की संभावना है (यानी यदि एप्लिकेशन डेवलपर्स के पास असेंबली प्लस साइडकार फाइलें हैं और वास्तविक प्रोजेक्ट फ़ाइल नहीं है) – iammichael

0

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

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

NAnt भी आपका विकल्प है, लेकिन अभी मैं अपने निर्माण/डीबग स्वचालन के रूप में रेक का उपयोग करके खुश हूं।

चूंकि इसे विजुअल स्टूडियो के भीतर एकीकृत नहीं किया जा सकता है, इसलिए मैं एक कार्य (या तो एमएसबिल्ड, एनएएनटी या रेक में) बनाता हूं, जो अंत में vsjitdebugger.exe निष्पादित करता है जब इसे डिबगिंग के दौरान मेरे विजुअल स्टूडियो में संलग्न किया जाता है ।

ये सिर्फ मेरी शैलियों हैं, आप शायद अपनी शैली बना सकते हैं।

1

क्या होगा यदि आप लाइब्रेरी और इसकी निर्भरताओं वाले merge module बनाते हैं? इसके बाद आपके इंस्टॉलर को इस मॉड्यूल को संदर्भित करने की आवश्यकता होगी, लेकिन आप सुनिश्चित करेंगे कि सभी आवश्यक फाइलें मौजूद होंगी।

+0

ऐसा लगता है जैसे यह होगा कुछ परिस्थितियों में काम करते हैं, लेकिन वर्तमान में हम अपने लाइब्रेरी घटकों या हमारी वेबसाइट अनुप्रयोगों के लिए इंस्टॉलर्स का उपयोग नहीं कर रहे हैं, इसलिए इससे हमारी तैनाती प्रक्रिया और विकास प्रक्रिया के लिए अधिक महत्वपूर्ण रूप से दोनों ओवरहेड जोड़े जाएंगे। – iammichael

1

मुझे बहुत अच्छा solution मिला है जो लिंकसॉर्स और प्रतिलिपि संदर्भों का उपयोग करना बहुत आसान बनाता है।

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