2011-01-11 18 views
6

हम अपने कुछ वीसी ++ विरासत उत्पादों को .NET प्लेटफॉर्म के साथ सी # में स्थानांतरित करने की योजना बना रहे हैं .. मैं आशावादी और प्रभावी देने के प्रस्ताव को देने से पहले अवशिष्ट जानकारी एकत्र करने की प्रक्रिया में हूं ग्राहकों के लिए दृष्टिकोण। मैं निम्नलिखित विवरणों की तलाश में हूं। सी # नेट के लिए कुलपति की ++ प्रवास मेंवीसी ++ से सी # माइग्रेशन दिशानिर्देश/दृष्टिकोण/मुद्दे

  1. किसी भी सामान्य दिशा निर्देशों
  2. क्या मुद्दे हैं कि एक टीम जब हम इस गतिविधि
  3. तक का समय लग वहाँ किसी भी मौजूदा दृष्टिकोण उपलब्ध हैं का सामना कर सकते हैं? मेरा मानना ​​है कि कई ने कोशिश की हो सकती है लेकिन विस्तृत जानकारी नहीं हो सकती है, लेकिन इसके तहत इसे समेकित करने से न केवल मुझे बल्कि किसी भी व्यक्ति को इन सूचनाओं की तलाश करने में मदद मिलेगी।
  4. इंटरनेट पर उपलब्ध कोई भी अच्छा/वैध संसाधन?
  5. यदि इस समूह में कोई माइक्रोसॉफ्ट लोग माइक्रोसॉफ्ट टीम से कोई सुझाव?
  6. आर्किटेक्चर, घटकों डिजाइन दृष्टिकोण, आदि

कृपया मुझे इन जानकारी प्राप्त करने में मदद करते हैं, प्रत्येक पैसा मुझे मदद मिलेगी अच्छी समझ हासिल करने के लिए .. जो लोग अपने ज्ञान को साझा करेंगे करने के लिए पहले से

धन्यवाद इस सवाल को पूरी तरह से करें।

+0

@all: मेरे वीसी ++ उत्पादों के बारे में अधिक जानकारी, इस उत्पाद में उद्देश्य सी आधारित ओओपी अवधारणाओं के साथ अधिकतर COM शामिल हैं, यह विकास उत्पाद के लगभग 17 वर्ष है। जो अनिवार्य रूप से बहुत से घटकों के साथ कोड का मतलब है। हाल ही में मेरे क्लाइंट ने मुझे इस पूरे उत्पाद को मर्ज करने का प्रस्ताव देने के लिए कहा है और यह मौजूदा किसी अन्य .NET उत्पाद के साथ कार्यक्षमता है और उन सुविधाओं को बढ़ाता है .. – KSH

+0

@all: इससे हमें समस्या का समाधान करने के लिए एक दृष्टिकोण के बारे में सोचने के लिए मजबूर किया गया। व्यक्तिगत COM या DLLs की पहचान करने की योजना जो वीसी ++ में हैं जो सीधे .NET कार्यों के अंदर उपयोग किए गए रैपर के माध्यम से हो सकती हैं। आवश्यकता होने पर केवल इन मॉड्यूल को छूने की योजना है। नए ढांचे के सामान के साथ यूआई के पूर्ण पुनर्लेखन की योजना बनाने के अलावा। यूआई/कोड/अवधारणाओं पर अधिक सुझाव अधिक ज्ञान प्राप्त करने में मदद करेंगे .. – KSH

उत्तर

4

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

संपादित करें: ध्यान में रखना एक और बात यह है कि .NET ढांचा बहुत बड़ा है। आपको अपने सी ++ कोड में उपयोगिता कक्षाएं मिल सकती हैं जिन्हें सी # में मानक लाइब्रेरी कक्षाओं द्वारा पूरी तरह से बदला जा सकता है।

14

अक्सर, मेरी सबसे अच्छी सलाह है: ऐसा न करें

यदि आप काम कर रहे हैं, तो सी ++ कोड साफ़ करें, इसे फिर से लिखने का कोई कारण नहीं है। विरासत कोड के चारों ओर रैपर बनाने के लिए सी ++/सीएलआई का उपयोग करना बहुत आसान है ताकि इसे सी #/नेट से उपयोग किया जा सके।

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

कहा जा रहा है कि, सी ++ से सी # तक कोड माइग्रेट करना आम तौर पर स्क्रैच रीराइट से बहुत अधिक पूर्ण होता है (जब तक आप उपरोक्त वर्णित नहीं करते हैं)। यह मुख्य रूप से पुस्तकालयों में भारी अंतर के कारण है, भाषाओं में अंतर नहीं।

.NET Framework उन उपकरणों की एक विशाल लाइब्रेरी प्रदान करता है जो लिखे जाने पर आपके कोड के आर्किटेक्चर को बदल सकते हैं और कर सकते हैं। यदि आप सीधे सी ++ से सी # पर पोर्ट करते हैं, तो आप पाएंगे कि आप गैर-मानक तरीकों से बहुत सी चीजें कर रहे हैं, और आप बहुत मुश्किल-से-बनाए रखने वाले सी # कोड के साथ समाप्त हो जाएंगे।

मेरा सुझाव, मेरे अनुभव के आधार पर, मेरा कोड पहले लपेटना है। फिर, यदि आप तय करते हैं कि आपको कुछ कार्यक्षमता बढ़ाने की आवश्यकता है, और रैपर की वजह से यह बेकार है, तो आप पूरी तरह से नई तकनीकों और पुस्तकालयों का उपयोग करके सी # में अपने कोड के एक विशिष्ट भाग को फिर से लिख सकते हैं - और सी ++ टुकड़े को टुकड़े से प्रतिस्थापित कर सकते हैं।

+2

इस दृष्टिकोण के साथ समस्या यह है कि आप विंडोज फोन जैसे सुरक्षा प्रतिबंधित संदर्भों में सी ++/सीएलआई नहीं चला सकते हैं। (जब तक आप '/ clr: pure' का उपयोग नहीं करते हैं, जो आपको वैसे भी सबकुछ फिर से लिखने के लिए मजबूर करता है) –

+0

@ बिली: लेकिन आप विंडोज फोन पर उसी पुस्तकालयों का भी उपयोग नहीं कर सकते हैं - तो आप वास्तव में नए कोड लिखने जा रहे हैं वैसे भी इसके लिए खरोंच ... –

+1

@Reed: उस पर बहस नहीं कर रहा है। बस यह कहकर कि "बस सी ++/सीएलआई के रूप में संकलित करें और सब ठीक हो जाएगा" वास्तव में सभी संदर्भों में सच नहीं है। सुनिश्चित नहीं है कि पुस्तकालयों द्वारा आपका क्या मतलब है - जैसा कि मुझे याद है कि सी ++/सीएलआई में सी ++ मानक पुस्तकालय का एक प्रबंधित संस्करण शामिल है। –

2

कुछ चीजें हैं जो तुरन्त आ:

  • सुनिश्चित करें कि आप सी ++ "चार" और सी # "चार" भ्रमित नहीं करते हैं। आप शायद जानते हैं कि सी # में "char" वास्तव में एक-बाइट आदिम नहीं है। तो, पोर्टिंग की प्रक्रिया में आप भ्रमित हो सकते हैं, ध्यान दें कि सी # में आप सी ++ "char" को "बाइट" पर पोर्ट करते हैं।

  • जैसे ब्रेनन विन्सेंट ने कहा, सी ++ बहु-विरासत का समर्थन करता है जबकि सी # नहीं करता है। यदि आपकी कक्षाएं "जटिल" हैं, तो आपको शायद पदानुक्रम को फिर से सोचना होगा।

  • पॉइंटर्स सी ++ में सी # में मूल नहीं हैं। दोबारा, यह निर्भर करता है कि आपने अपना सी ++ ऐप कैसे लिखा है, लेकिन मैं शर्त लगा सकता हूं कि आप वहां पॉइंटर्स का उपयोग कर रहे हैं, इसलिए सुनिश्चित करें कि यूसाफ सी # के साथ मेल खाता है क्योंकि यह प्रोग्रामर (पारदर्शी रूप से) से पारदर्शी रूप से उन्हें अलग-अलग संभालता है।

मैं कुछ और बाद में, अच्छा सवाल जोड़ सकता हूं!

1

सबसे पहले, अपने काम करने वाले मूल C++ कोड को न लें और इसे C++/CLI के रूप में संकलित करें। आपको भयानक परिणाम मिलेगा। दूसरा, अपने काम करने वाले देशी सी ++ कोड को न लें और इसे सी # में अनुवाद करने का प्रयास करें, साथ ही बेस क्लास लाइब्रेरीज़ का उपयोग करने के लिए स्थानों को ध्यान में रखते हुए, अपनी डेटा एक्सेस तकनीक बदलना और एमएफसी से डब्ल्यूपीएफ में अपना यूआई प्रतिमान समायोजित करना। आप सबसे पहले, जो पहले था, उत्पादन करने के लिए बहुत सारी ऊर्जा खर्च करेंगे।

इसके बजाय, अपने कामकाजी देशी सी ++ कोड लें और इसे दोबारा दोहराएं ताकि आपके पास एक या अधिक "व्यावसायिक तर्क" पुस्तकालय हों। यदि ये पहले से मौजूद हैं तो उनके पास COM इंटरफेस हो सकते हैं, वे कुछ "बाहरी सी" प्रकार के फ़ंक्शंस का पर्दाफाश कर सकते हैं, या वे कुछ C++ इंस्टेंस विधियों का पर्दाफाश कर सकते हैं। कोई चिंता नहीं। यदि वे पहले से मौजूद नहीं हैं, तो आपके पास दो विकल्प हैं। यदि प्रस्तुति परत द्वारा आवश्यक कुछ तरीकों की आवश्यकता है, और वे तारों की तरह सरल चीजें लेते हैं, तो कुछ तर्कों को व्यापार तर्क के प्रवेश द्वार के रूप में रखें। अब आप उन्हें पी/Invoke का उपयोग कर प्रबंधित यूआई (वीबी या सी #, विंडोज फॉर्म या डब्ल्यूपीएफ, जो कुछ भी) से कॉल कर सकते हैं। यदि बहुत कुछ है और आप उन्हें व्यवस्थित करना चाहते हैं, या यदि उन्हें जटिल structs या ऑब्जेक्ट्स लेने की आवश्यकता है तो एक सी ++/सीएलआई कक्षा या कक्षाएं लिखें जो देशी सी ++ कक्षाओं से बात कर सकती हैं, जबकि "सार्वजनिक रेफ क्लास" कक्षाओं को उजागर करते समय प्रबंधित यूआई के लिए। सी ++/सीएलआई मार्शलिंग और आजीवन मुद्दों को आसान बना देगा।

अपने नए यूआई के लिए, इसे स्क्रैच से लिखें, जहां आवश्यक हो वहां व्यवसाय तर्क में कॉल करें। पुरानी यूआई का उपयोग केवल अपनी क्षमताओं और सत्यापन के लिए एक मार्गदर्शिका के रूप में करें। यूआई बनाने के लिए अपनी नई यूआई तकनीक (डब्ल्यूपीएफ या जो भी) के "देखो और महसूस करें" का प्रयोग करें और यांत्रिक रूपांतरण का प्रयास न करें। आप बस पिक्सल का पीछा करते हैं और यदि आप पुरानी यूई के बहुत करीब से चिपके रहते हैं तो आपको कड़ी मेहनत करनी होगी। पुराने ऐप में 3 बटन और एक चेकबॉक्स था? ग्रेट, 3 डब्ल्यूपीएफ-लुकिंग बटन और एक डब्ल्यूपीएफ-दिखने वाला चेकबॉक्स आ रहा है। इसके बदले में आप रिबन पर स्विच कर रहे हैं? ठीक। जब आप पूरा कर लें तो अलग दिखना ठीक है।

फिर आप अपने मूल व्यापार तर्क पुस्तकालयों को तैनात करते हैं, फिर भी मूल कोड के रूप में संकलित, आपके सी ++/सीएलआई रैपर यदि आपके पास है, और आपका प्रबंधित यूआई है। यह फोन को छोड़कर कुछ भी काम करेगा।

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

4

मुझे सी ++ (एमएफसी) से सी # (WinForms) से एक बड़ा आवेदन माइग्रेट करने के अतीत में व्यापक अनुभव हुआ है।

कुछ महत्वपूर्ण कारक अपनी रणनीति को प्रभावित कर सकते हैं:

  1. सबसे पहले, तुम क्यों की ओर पलायन करना पड़ता है? उचित रणनीति चुनने के लिए अपने लक्ष्यों को जानें। ज्यादातर मामलों में, आपको "बस" माइग्रेट नहीं करना चाहिए ताकि आप एक अच्छी नई तकनीक का उपयोग कर रहे हों।

  2. मौजूदा कोड बेस कितना बड़ा है? यदि यह एक बहुत ही छोटा कोड बेस है, तो कहने के लिए सप्ताहों को फिर से लिखना है, अधिक विश्लेषण के साथ परेशान न करें और बस इसे करें ...

  3. क्या आपको सभी मौजूदा कार्यक्षमताओं को परिवर्तित करना है सी#? या आप सी ++ को रखने और सी # में केवल नई सुविधाओं को जोड़ने के साथ रह सकते हैं? आपके मौजूदा सी ++ कोड को किस तरह से संयोजित किया गया है, इस पर निर्भर करते हुए, आप सी # में विकसित होने पर इसका पुन: उपयोग जारी रखने के लिए COM इंटरॉप जैसी तकनीकों का उपयोग करने में सक्षम हो सकते हैं।

  4. क्या आप किसी भी नए संस्करण को रिलीज़ करने में देरी कर सकते हैं जब तक आप सबकुछ फिर से लिख नहीं लेते? आमतौर पर जवाब नहीं होगा। (नेटस्केप प्रकार दिमाग में आता है - आप this पढ़ना चाहेंगे ...) आप ऐसी रणनीति के साथ आना चाह सकते हैं जहां आप धीरे-धीरे अपने एप्लिकेशन में घटकों और ढांचे को प्रतिस्थापित कर सकें, इस तरह से आप संस्करण उन्नयन जारी करने के लिए स्वतंत्र हो जाते हैं , ताकि प्रत्येक संस्करण में थोड़ा और सी # और थोड़ा कम C++ हो।

  5. असल में, मेरे लिए काम करने वाला एक दृष्टिकोण सी # में मेरे आवेदन के बुनियादी ढांचे को फिर से लिखना था, और COM इंटरऑप का उपयोग करके, मेरे सी ++ एप्लिकेशन से उन ढांचे का उपभोग करना था। प्रत्येक रिलीज में सी # में कुछ और ढांचे और नियंत्रण थे। एक बार जब हम कोड के एक महत्वपूर्ण द्रव्यमान को परिवर्तित कर देते हैं, साथ ही साथ हमारी मुख्य विंडो के सभी नियंत्रणों को परिवर्तित कर देते हैं, तो हमने एप्लिकेशन के एंट्री-पॉइंट को C++ के बजाय .NET होने के लिए बदल दिया।

  6. संसाधनों के लिए, मेरे लिए, पुस्तक ".NET and COM: The complete interoperability guide" एक खजाना था।

यही मुख्य चीज है जो मैं अभी सोच सकता हूं। मैं आपके पास बहुत से विशिष्ट प्रश्नों का उत्तर देने में सक्षम हो सकता हूं।

+0

+20 अगर मैं कर सकता था। बहुत बढ़िया जवाब। –

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