मिश्रित एसएसआईएस/डीएलएल समाधान

Question

की स्वचालित तैनाती वर्तमान में हमारे पास एसएसआईएस/सी # का उपयोग करके विकसित समाधान है। एसएसआईएस पैकेज (अन्य चीजों के साथ) में एक स्क्रिप्ट कार्य है जो कक्षा पुस्तकालयों में विकसित तर्क का उपयोग करता है। इस कार्यक्षमता को एसएसआईएस पैकेज से अलग रहने की जरूरत है।

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

हमारा स्वचालित परिनियोजन उपकरण (दाएं) स्वचालित रूप से डीएलएल के संस्करण संख्याओं को बढ़ाता है, जिसे बाद में जीएसी में प्रकाशित किया जाता है। हालांकि यह एसएसआईएस पैकेज को तोड़ता है, क्योंकि यह डीएलएल की उस संस्करण संख्या के आधार पर कोशिश करेगा और उसे एक्सेस करेगा जिसे वे विकास मशीन जीएसी के रूप में प्रकाशित किए गए थे।

हमारे पास एकमात्र समाधान है जो संकलित डीएलएल प्राप्त करने के लिए है, मैन्युअल रूप से एसएसआईएस पैकेज स्क्रिप्ट कार्य को संशोधित करें और फिर पैकेज प्रकाशित करें।

ऐसा लगता है कि ऐसा करने का एक बेहतर तरीका होना चाहिए - क्या किसी को भी इस समस्या का सामना करना पड़ा है और बेहतर समाधान के साथ आया है? या क्या हमारे दृष्टिकोण में कुछ मौलिक है जिसे हमें बदलने की जरूरत है (डीएलएल की आवश्यकता को खत्म करने से परे)?

धन्यवाद!

Answer 1

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

Dim rsAssembly As Assembly = Assembly.LoadFile("path from config file") 
    Dim rsType As Type = rsAssembly.GetType("class name from config file") 
    Dim obj As Object = Activator.CreateInstance(rsType) 

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

भविष्य चाहने वालों के लिए यहाँ प्रकाशित किया गया था, लेकिन अगर किसी को भी कुछ के साथ आता है बेहतर मैं अभी भी पता है कि कैसे आप इसे हल कर बहुत ही उत्सुक हो सकता है - पोस्ट यहाँ और मैं जवाब :)

Answer 2

क्या आप पूरी तरह से सुनिश्चित हैं कि साझा किए गए DLLs को को जीएसी में तैनात किया जाना चाहिए? यदि वे एसएसआईएस पैकेज के समान फ़ोल्डर में हैं, तो उन्हें फ्रेमवर्क द्वारा उन्हें जीएसी में जोड़ने की आवश्यकता के बिना खोजने योग्य होना चाहिए।

क्या संस्करण संख्या परिवर्तन से बचने के लिए आपके निर्माण सिस्टम को अपडेट करने का कोई तरीका नहीं है? यदि उन असेंबली का कोड बदल नहीं रहा है, तो संस्करण संख्या को अपडेट करने की कोई आवश्यकता नहीं है।

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

Answer 3

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