क्या WiX C# कस्टम एक्शन के लिए उत्पन्न क्लास और असेंबली (विजुअल स्टूडियो के लिए) का नाम बदलना ठीक है?</p> <p>"CustomAction.config", "CustomAction.cs:

Question

जब मैं दृश्य स्टूडियो 2010 के साथ WiX 3.x का प्रयोग कर एक Windows इंस्टालर एक्सएमएल" सी # कस्टम क्रिया परियोजना "" MyCustomActions "कहा जाता है बनाने के लिए है, यह निम्न फ़ाइलें उत्पन्न करता है "और प्रोजेक्ट फ़ाइल" MyCustomActions.csproj "।

हम एक विधानसभा नामकरण योजना हमारी कंपनी का नाम भी शामिल है कि उपयोग करते हैं, तो हम कुछ ऐसा करने के लिए विधानसभा का नाम बदलने: CompanyName.ProductName.MyCustomActions

एक ही समय में, हम के लिए डिफ़ॉल्ट नाम स्थान और वास्तविक नाम स्थान बदल असेंबलीनाम से मेल खाने के लिए कस्टमएक्शन क्लास CompanyName.ProductName.MyCustomActions।

यह किसी भी अन्य फ़ाइल या वर्ग के नाम को परिवर्तित किए बिना यह करने के लिए ठीक है?

बात मैं के बारे में सोच रहा हूँ "CustomAction.config" फ़ाइल का उपयोग कर रहा है - इस बात का नाम किसी तरह से उत्पादन विधानसभा नाम से संबंधित होना है? मुझे यकीन नहीं है कि "CustomAction.config" का उपयोग कैसे किया जाएगा।

इसके अलावा: "CustomAction.cs" फ़ाइल में "कस्टमएक्शन" नामक एक कक्षा होती है (बहुवचन नोट करें), और हमारे नामकरण सम्मेलन का कहना है कि कक्षा के लिए कोड फ़ाइल में कक्षा के समान नाम होना चाहिए, इसलिए हम कोड फ़ाइल को "CustomActions.cs" में बदलना चाहेंगे। मुझे यकीन है कि ठीक है ... है ना?

अंत में, यदि हम कुछ और करने के लिए CustomAction वर्ग का नाम बदलने के लिए किया था, तो वह ठीक हो सकता है? दोबारा, मैं सिर्फ "कस्टमएक्शन.कॉन्फिग" से अपने रिश्ते से चिंतित हूं।

मुझे लगता है कि इन सभी सवालों को एक में घुमाया जा सकता है: बाकी नामस्थान, असेंबली और कक्षा के नामों के साथ "CustomAction.config" फ़ाइल के नाम के बीच संबंध क्या है?

अगर मैं इसका जवाब है, यह मेरी सभी पिछले सवालों के जवाब देने हैं।

Answer 1

एक WIX कस्टम एक्शन प्रोजेक्ट के लिए, इससे कोई फर्क नहीं पड़ता कि आप अपनी कक्षाओं या असेंबली या नेमस्पेस या किसी और चीज का नाम क्या रखते हैं, कॉन्फ़िगरेशन फ़ाइल को हमेशा 'CustomAction.config' नाम दिया जाना चाहिए (इसे WIX में हार्ड-कोडड माना जाता है) और इसका निर्माण वीएस में फ़ाइल प्रॉपर्टी में एक्शन को 'कंटेंट' पर सेट किया जाना चाहिए। परियोजना में किसी और चीज के लिए ऐसी कोई आवश्यकता नहीं है।

यह कॉन्फ़िगरेशन फ़ाइल समर्थित सीएलआर संस्करण निर्दिष्ट कर सकती है (वास्तव में इसकी अनुशंसा की जाती है) और इसमें कोई अतिरिक्त कॉन्फ़िगरेशन हो सकता है जो आपके कस्टम एक्शन डीएल की आवश्यकता हो सकती है।

आपका डीएल मानक .Net ऐप कॉन्फ़िगरेशन API का उपयोग करके इन अतिरिक्त कॉन्फ़िगरेशन सेटिंग्स को पढ़ने में सक्षम होगा।

Answer 2

मैं संकलित ढांचे के साथ-साथ अन्य .नेट चौखटे में अनुप्रयोग चलाने के लिए कॉन्फ़िग फ़ाइल का इस्तेमाल किया है। उदाहरण के लिए अगर हम CLR 2.0 (.NET फ्रेमवर्क 2.0 या 3.5) है कि आवेदन .NET फ्रेमवर्क 4.0 अकेले स्थापित मशीन में नहीं चला का उपयोग करें। उस स्थिति में यदि हम नीचे दिए गए कोड को कॉन्फ़िगरेशन फ़ाइल में सेट करते हैं और कॉन्फ़िगरेशन फ़ाइल को एप्लिकेशन के साथ रखते हैं तो यह फ्रेमवर्क 4.0 अकेले स्थापित मशीन में चलाएगा।

<startup useLegacyV2RuntimeActivationPolicy="true"> 
<supportedRuntime version="v2.0.50727"/> 
<supportedRuntime version="v4.0"/> 

मुझे उम्मीद है कि यहां कॉन्फ़िगर फ़ाइल का उपयोग करने का एक ही कारण है।