VBA से C # में जाने पर सवाल उठाने वाली टीम के सदस्य

Question

पृष्ठभूमि

पिछले साल, मुझे लगभग 10 उपयोगकर्ताओं के लिए व्यावसायिक नियोजन के लिए इस्तेमाल किया जाने वाला एक उपकरण बनाने के लिए कहा गया था। यह एक अन्य आईटी टीम की ओर से किया गया था, जिन्होंने मुझे काम को "उप-अनुबंधित" किया था, और परियोजना की समय सीमा उनके पक्ष में थोड़ी अनियोजित होने के कारण, मुझे इसे थोड़ा भीड़ में लागू करना पड़ा।

उस समय, हमने तय किया कि सबसे तेज़ तरीका VBA के साथ एक एक्सेल वर्कबुक बनाना होगा और फिर उपयोगकर्ताओं को अपने पीसी पर उपयोग करने के लिए इंट्रानेट से इस VBA-वर्धित वर्कबुक को डाउनलोड करना होगा। इस मामले में एक्सेल एक अड़चन था क्योंकि हम जिस प्लानिंग सिस्टम (डेटाबेस) का उपयोग करते हैं वह केवल एक एक्सेल ऐड-इन के माध्यम से इंटरैक्ट कर सकता है जिसमें उसी समय लोड किया जाना चाहिए जब प्लानिंग वर्कबुक खुली हो। हालाँकि, उस समय VBA एक अड़चन नहीं था।

कार्यपुस्तिका मैंने VBA कोड की लगभग 4,000 पंक्तियों को बनाया और जब मैंने डेटा और प्रस्तुति परतों को अलग करने की कोशिश की, तो मैं परियोजना की समय सीमा के कारण सभी मामलों में नहीं कर सका। ईमानदार होने के लिए, जबकि मुझे इस कार्यपुस्तिका को बनाने पर गर्व है, मैं एक ही समय में थोड़ा निराश हूं कि यह बेहतर तरीके से किया जा सकता है, दोनों कोडिंग के संदर्भ में और उपयोगकर्ताओं की तैनाती भी।

आज

आज तक और आईटी टीम फिर से एक समान कार्यपुस्तिका का अनुरोध करने के लिए मेरे पास आई है (इसलिए मैं ऊपर की अन्य कार्यपुस्तिका के कुछ हिस्सों का पुन: उपयोग कर सकता हूं), लेकिन इस बार यह बहुत अधिक जटिल है और अधिक से अधिक उपयोगकर्ताओं द्वारा उपयोग किया जाएगा ( लगभग 200)।

हालांकि, इस बार, यह थोड़ा बेहतर नियोजित है और मैं देख सकता हूं कि हमारे पास चीजों की योजना बनाने के लिए थोड़ा और समय है। इसके आधार पर, मैंने समाधान और बुनियादी ढांचे के बारे में सोचा क्योंकि 100 उपयोगकर्ताओं के लिए प्रोग्रामिंग 10 उपयोगकर्ताओं के लिए प्रभाव से अधिक है। इसलिए, मैंने टीम को सुझाव दिया कि शायद हमें मौजूदा कोड को C # समाधान में माइग्रेट करने पर विचार करना चाहिए ताकि हम कोड को अधिक परिष्कृत तरीके से प्रबंधित कर सकें। मैं अभी भी इसे VSTO / Excel-DNA का उपयोग करते हुए एक ऐड-इन लिखित के रूप में मान रहा हूं जिसे तब उपयोगकर्ताओं के लिए तैनात किया जा सकता है।

मैंने दो सप्ताह पहले आईटी टीम के साथ इस पर चर्चा की थी और सब कुछ ठीक लग रहा था, कल तक मुझे टीम में से एक से मेल प्राप्त हुआ था (जो VBA या C # नहीं जानता है) यह सवाल करते हुए कि हमें C # बनाम इस नए प्रोजेक्ट को क्यों शुरू करना चाहिए? पहले जैसा ही दृष्टिकोण। उनकी कुछ चिंताएँ थीं:

• यह एक काफी महत्वपूर्ण परियोजना है, इसलिए इसे काम करना है - एक C # समाधान स्थिर या काम नहीं करेगा और साथ ही मौजूदा VBA- आधारित समाधान भी होगा।
• हमें वीएबीए समाधान में जो कुछ भी हमने किया था उसे हमें फेंकना होगा और इसे सी # में खरोंच से फिर से बनाना होगा।
• किसी को दो अलग-अलग समाधानों का समर्थन करना होगा, एक VBA में और एक C # में। [वास्तव में, वर्तमान में उनके पास समर्थन के लिए कोई नहीं है, मैं आमतौर पर कदम रखता हूं]।

अब, मैं उनकी कुछ चिंताओं को कुछ हद तक समझ सकता हूं, लेकिन मुझे अगले चरणों पर निर्णय लेने की जरूरत है और उनके साथ क्या करना है। व्यक्तिगत रूप से, मैं सी # में लागू करना चाहूंगा क्योंकि मुझे लगता है कि इस तरह से "एंटरप्राइज" समाधान बनाने के लिए यह बेहतर होगा। इसके अलावा, मैं इस अवसर को अपने सी # कौशल पर लेना चाहूंगा क्योंकि मैं वर्तमान में सी # में सक्षम नहीं हूं क्योंकि मैं वीबीए हूं और मैं इस तरह की परियोजना को "अगले स्तर" पर ले जाऊंगा।

मैंने उन बिंदुओं की एक सूची तैयार की, जिनका उपयोग करने के लिए मैं कोशिश कर सकता हूं और उन्हें समझा सकता हूं कि इस परियोजना के लिए एक C # समाधान बेहतर होगा, यह वही है जो मैंने अभी तक किया है:

• इकाई का परीक्षण।
• स्रोत नियंत्रण।
• कोड प्रलेखन - अन्य सहायता व्यक्तियों को ज्ञान हस्तांतरण के लिए।
• बेहतर कोडिंग कन्वेंशन - बेहतर नामकरण और संरचना को लागू करने के लिए ReSharper जैसी चीजों का उपयोग कर सकते हैं।
• बेहतर आईडीई - त्रुटि हाइलाइटिंग के कारण कम गलतियां।
• विधानसभाओं के माध्यम से अधिक प्रतिरूपकता - भविष्य के साधनों में फिर से उपयोग को बढ़ावा दे सकती है।
• प्रबंधित परिनियोजन - यह नियंत्रित कर सकता है कि यह उपकरण किसके द्वारा उपयोग किया जाता है।

प्रश्न: मैं उन्हें समझाने के लिए किन अन्य बिंदुओं को जोड़ सकता हूं? या मैं इस परियोजना के साथ चबाने की तुलना में अधिक काटने की कोशिश कर रहा हूं? क्या मुझे बस चुप रहना चाहिए और वैसे भी VBA में करना चाहिए?

मुझे पता है कि सिर्फ एक नई भाषा की ओर बढ़ना क्योंकि इसका "नया" या "कूलर" होना किसी निर्णय का आधार नहीं होना चाहिए और जैसे कि मैंने इसे निर्णय बिंदु के रूप में शामिल करने का विरोध किया है - यह तथ्यों के बारे में है।

इसके अलावा, मैं भाषाओं के रूप में C # और VBA के बीच शाब्दिक तुलना के लिए नहीं कह रहा हूं, क्योंकि SO पर काफी तुलनाएं हैं।

Comments

अनुशंसित पढ़ने: मैं $ {कुछ} को $ {किसी} को कैसे समझाऊं?

— gnat

मुझे लगता है कि आपको यह देखने की जरूरत है। बस के मामले में यह दक्षिण में चला जाता है और आप अंत में वीबीए में फंस जाते हैं। अस्वीकरण: मैं इस परियोजना के डेवलपर्स में से एक हूं। रबरडक-vba.com

— रबरडक

Vb.net के बजाय C # क्यों?

— तैमिर

मैं एक ही स्थिति में हूँ, एक बहुत बड़ी (Vk कोड की 20k + लाइनें) एक EXCEL कार्यपुस्तिका में बनाया गया आवेदन। Office 2013 के साथ परीक्षण करने पर, यह बस काम करने में विफल रहता है, नए कार्यालय मॉडल में स्टार्ट-अप इवेंट के अनुक्रम में बदलाव के कारण माना जाता है, और संभवतः EMET के अधिक सख्त प्रवर्तन। मैं इस वर्ष Office 2013 के रोल-आउट से पहले C # और VB.NET के लिए क्रैश-रूपांतरण करने की स्थिति में हूं। अन्य, सरल (VBA वर्धित) कार्यपुस्तिकाएँ संगठन के आस-पास उपयोग की गई हैं, प्रतिरक्षा नहीं है, कुछ काम कर रहे हैं और अन्य नहीं।

— पीटर गेर्केन

C # अब और C # 7 साल पहले समान नहीं हैं। VB आधारित भाषाओं को अधिक से अधिक पदावनत किया जा रहा है। यदि आप शॉर्ट-टाइम फिक्स चाहते हैं, तो इसे VBA में करें। यदि यह भविष्य में अंतिम और संभवतः विस्तारित होना चाहिए, तो C # पर जाएं।

— मस्त

Answer 1

आपके द्वारा सूचीबद्ध तीन बिंदु उचित प्रतीत होते हैं:

यह एक काफी महत्वपूर्ण परियोजना है, इसलिए इसे काम करना है - एक C # समाधान स्थिर या काम नहीं करेगा और साथ ही मौजूदा VBA- आधारित समाधान भी होगा।

दरअसल, बाद में, आप बताते हैं: "मैं इस अवसर को अपने सी # कौशल पर ब्रश करना चाहता हूं क्योंकि मैं वर्तमान में सी # में सक्षम नहीं हूं क्योंकि मैं वीबीए हूं " (जोर मेरा)।

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

हमें वीएबीए समाधान में जो कुछ भी हमने किया था उसे हमें फेंकना होगा और इसे सी # में खरोंच से फिर से बनाना होगा।

चीजें जो आपको कभी भी दिमाग में नहीं आती हैं। आप कोड फेंक रहे हैं, साथ ही उपयोगकर्ता परीक्षण भी। अच्छी बात नहीँ हे।

किसी को दो अलग-अलग समाधानों का समर्थन करना होगा, एक VBA में और एक C # में। [वास्तव में, वर्तमान में उनके पास समर्थन के लिए कोई नहीं है, मैं आमतौर पर कदम रखता हूं]।

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

---

दूसरी ओर, आपके कुछ बिंदुओं की आलोचना की जा सकती है:

• इकाई का परीक्षण।

  आप अपनी वर्तमान परियोजना को भी परख सकते हैं। यदि उस के लिए कोई सुविधाजनक ढांचा नहीं है, तो एक बनाएं।

• स्रोत नियंत्रण।

  स्रोत नियंत्रण पाठ से संबंधित है। आपका वर्तमान कोड पाठ है, इसलिए आप इसके लिए स्रोत नियंत्रण का उपयोग कर सकते हैं।

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

• कोड प्रलेखन - अन्य सहायता व्यक्तियों को ज्ञान हस्तांतरण के लिए।

  माना।

• बेहतर कोडिंग कन्वेंशन - बेहतर नामकरण और संरचना को लागू करने के लिए ReSharper जैसी चीजों का उपयोग कर सकते हैं।

  "बेहतर" परिभाषित करें। एक्सेल के मैक्रोज़ के लिए कोडिंग कन्वेंशन हैं? यदि हाँ, तो उनका उपयोग करें: वे किसी भी अन्य की तुलना में बेहतर या बदतर नहीं हैं। यदि नहीं, तो बनाएं और उन्हें प्रकाशित करें ताकि अन्य लोग भी उनका उपयोग कर सकें। 2010 में पोस्ट किए गए एक प्रश्न के उत्तर निराशाजनक लगते हैं, लेकिन तब से नए उपकरण उपलब्ध हो सकते हैं।

  ध्यान दें कि कोडिंग सम्मेलनों का महत्वपूर्ण हिस्सा यह है कि उन्हें प्रतिबद्ध किया जाना चाहिए।

• बेहतर आईडीई - त्रुटि हाइलाइटिंग के कारण कम गलतियां।

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

• विधानसभाओं के माध्यम से अधिक प्रतिरूपकता - भविष्य के साधनों में फिर से उपयोग को बढ़ावा दे सकती है।

  मुझे पूरा यकीन है कि आपका वर्तमान उत्पाद कुछ हद तक प्रतिरूपकता का भी उपयोग कर सकता है।

• प्रबंधित परिनियोजन - यह नियंत्रित कर सकता है कि यह उपकरण किसके द्वारा उपयोग किया जाता है।

  माना।

---

एक पूर्ण पुनर्लेखन के बजाय, आप मैक्रो से क्रमिक रूप से VB.NET में लिखे गए साधारण असेंबली में कोड को स्थानांतरित करने का तरीका खोज सकते हैं । VB.NET में क्यों? तीन कारण:

• VBA और VB.NET में कम अंतर है क्योंकि VBA और C # के बीच है।

• आप VBA को बेहतर जानते हैं, और यह अकेले C # के बजाय VB.NET का उपयोग करने का एक अच्छा कारण है। यदि आप "अपने सी # कौशल पर ब्रश" करना चाहते हैं, तो इसे अपनी व्यक्तिगत परियोजनाओं के साथ करें, न कि व्यवसायिक महत्वपूर्ण सामान।

• किसी भाषा से दूसरे में फिर से लिखने से संभावित कीड़े हो जाते हैं। इस परियोजना के लिए आपको इसकी आवश्यकता नहीं है।

.NET असेंबली में जाने से आपको विज़ुअल स्टूडियो का सुविधाजनक वातावरण मिल सकता है, सुविधाजनक इकाई परीक्षण, टीएफएस और त्रुटि के साथ जो आप वर्तमान में अन्य परियोजनाओं में उपयोग करते हैं।

उसी समय, यदि आप अपने कोड चरण को चरण दर चरण आगे बढ़ाते हैं, तो आप एक पूर्ण पुनर्लेखन का जोखिम नहीं उठाते हैं (अर्थात चार महीने खर्च करने से कोई भी व्यक्ति उपयोग नहीं करना चाहता है क्योंकि नए कीड़े की संख्या अधिक है)। उदाहरण के लिए, आपको एक विशिष्ट विशेषता पर काम करने की आवश्यकता है? सोचें कि आप इस विशेष सुविधा को पहले .NET में कैसे स्थानांतरित कर सकते हैं।

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

Comments

VBA के साथ जाने पर, आप बहुत सारे अतिरिक्त मेटा-प्रोग्रामिंग के साथ समाप्त होते हैं। मैंने लिखा है, अन्य चीजों (परीक्षण, मैक्रो आयातक / निर्यातक आदि) के बीच, vba-excelsheets के लिए एक डिस्ट्रीब्यूटूल, जो दूरस्थ शीट खोलता है और मैक्रोज़ का आदान-प्रदान करता है, मैक्रोज़ अपडेट करता है और सुनिश्चित करता है कि शीट फिर से उचित आकार में हैं (C # में) , भगवान का शुक्र है)। फिर भी, मुझे लगता है कि अकेले VBA कोड से अधिक प्रयास था। मैं यह नहीं कह रहा हूं कि आपको किसी भी कीमत पर सी # के साथ जाना चाहिए, लेकिन अधिक आधुनिक प्लेटफॉर्म की ओर पलायन के बारे में सोचना हर किसी के हित में होना चाहिए।

— एसबीआई

क्या VB.NET वास्तव में VBA के समान है कि आपके दूसरे और तीसरे अंक अभी भी एक बार खड़े हैं ताकि आप उस प्रतिस्थापन को बना सकें?

— बेन आरोनसन

VB.NET का एक अतिरिक्त लाभ यह है कि आप विभिन्न .NET भाषाओं में लिखे घटकों को बहुत आसानी से जोड़ सकते हैं। तो, आप (उदाहरण के लिए) VBA से VB.NET पर माइग्रेट कर सकते हैं और फिर C #, VB.NET या किसी और चीज़ में नई कार्यक्षमता जोड़ सकते हैं जो आपके प्रोजेक्ट के लिए समझ में आता है।

— थियोडोरोस चात्जिगानियाकिंस

Answer 2

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

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

सोचने के लिए VBA की धारणा भी है। मुझे पता है कि यह सच नहीं है, लेकिन मैं काफी कम लोगों को जानता हूं, जो 'वीबीए' को फिर से शुरू करते हैं और सोचते हैं "क्या, यह आदमी आंतरिक काम कर रहा है? उसे वास्तविक भाषा का अनुभव क्यों नहीं है ?" वे 'VBA' देखते हैं और 'एक्सेल मैक्रो डेवलपर' सोचते हैं। जैसे एक सेल को दूसरे में कॉपी / पेस्ट करना, सरल गणना करना, आदि। आमतौर पर वीबीए में वास्तविक विकास की सराहना करने वाले लोग वे होते हैं जिन्होंने इसे किया है, और यह एक छोटे से पूल की तरह लगता है, कम से कम मेरे अनुभव में। आपके क्षेत्र में VBA की धारणा के बारे में बेहतर समझ हो सकती है, लेकिन मैंने इसके प्रति बहुत अधिक अनुचित नकारात्मकता देखी है।

दूसरी बात जिस पर मैं शून्य करना चाहता हूं: मेनमा ने VBA और C # के बीच समानता का उल्लेख किया। यह बिल्कुल सच है, और जेएमके का जवाब कुछ प्रौद्योगिकियों को पढ़ने के लिए प्रदान करता है। अपने VBA कोड को C # प्रोजेक्ट में कॉपी / पेस्ट करने की कोशिश करें और देखें कि सिंटैक्स त्रुटियां कितनी आसान लगती हैं।

आपने कहा था कि आपके पास कोड की 4,000 लाइनें हैं, जो कोड का एक अच्छा हिस्सा है और शायद बहुत अधिक कार्यक्षमता शामिल है ... लेकिन यह कोड की केवल 4,000 लाइनें हैं। कॉपी और पेस्ट की कोशिश करें। अगर आप उन वाक्यविन्यास त्रुटियों को साफ कर सकते हैं और काम करने की परियोजना है तो मुझे वास्तव में आश्चर्य नहीं होगा। आपके कोड का विवरण या आपके लिए उपलब्ध खाली समय की मात्रा को जाने बिना, मुझे लगता है कि आप इसे सप्ताहांत में दस्तक दे सकते हैं।

यह C # सर्वोत्तम प्रथाओं का पालन नहीं कर सकता है, यह अक्षम हो सकता है, लेकिन आप C # में एक कार्यात्मक समकक्ष परियोजना के साथ समाप्त होंगे। आप यह भी निश्चित रूप से निश्चित कर सकते हैं कि आपका नया C # कोड आपके पुराने VBA कोड से अधिक दोष-प्रवण नहीं है।

अपने समय पर अपने VBA कोड को C # में बदलना आपके लिए कुछ काम करेगा:

• जैसा कि आप सिंटैक्स त्रुटियों पर शोध करते हैं, आप C # प्रथाओं से अधिक परिचित होंगे - वास्तव में C # में काम करने के लिए प्राइमर का एक प्रकार
• यह प्लग-इन को एक्सेल में लोड करने के साथ किसी भी स्पष्ट मुद्दों पर एक प्रकाश को चमक देगा (क्योंकि एक्सेल संभवतः अभी भी एक आवश्यकता है)। शायद कोई समस्या है जिस पर आपने अभी तक विचार नहीं किया है जो कि एक अवरोधक हो सकता है।
• यह आपके ग्राहक (आईटी टीम) को एक सबूत की अवधारणा दिखाएगा। यदि वे देख सकते हैं कि आपके पास वर्तमान कार्यक्षमता के साथ एक कार्यशील C # प्लग-इन है, तो आप C # के साथ उनके कथित जोखिम के स्तर को कम करेंगे।

और आईटी के तीन बिंदुओं पर वापस जा रहे हैं:

• यह एक काफी महत्वपूर्ण परियोजना है, इसलिए इसे काम करना है - एक C # समाधान स्थिर या काम के साथ-साथ मौजूदा VBA- आधारित समाधान नहीं होगा।

जैसा कि उल्लेख किया गया है, आपका C # कोड समान कार्यक्षमता को कवर करेगा और आपके VBA के समान ही स्थिर होगा। कड़ाई से बोलते हुए, एक मौका है जो आप बग / दोष या अक्षमताओं का परिचय देते हैं, लेकिन ऐसा लगता है कि संभावना नहीं है। हम iOS / Object C से Android / Java के पोर्ट के बारे में बात नहीं कर रहे हैं, हम दो भाषाओं के बीच एक पोर्ट के बारे में बात कर रहे हैं जो वाक्य रचना में बहुत सारी समानताएं साझा करता है और सटीक एक ही तकनीक - एक्सेल वर्कबुक का उपयोग कर सकता है।

• वीएबीए समाधान में हमने जो किया था उसे हमें फेंकना होगा और सी # में खरोंच से इसे फिर से बनाना होगा।

इसके साथ, आप किसी भी प्रयास या कोड को नहीं फेंक रहे हैं।

• किसी को दो अलग-अलग समाधानों का समर्थन करना होगा, एक VBA में और एक C # में। [वास्तव में, वर्तमान में उनके पास समर्थन के लिए कोई नहीं है, मैं आमतौर पर कदम रखता हूं]।

आपके पास केवल 1 समाधान होगा, सभी C # में।

सभी सब में, आपके ग्राहक को बहुत अधिक जोखिम दिखाई देता है। यदि आप उस जोखिम को कम करने के लिए कदम उठा सकते हैं, तो वे सी # में परिवर्तन को गले लगा सकते हैं।

Comments

आप मेरे उत्तर के लिए कुछ बहुत ही मान्य काउंटर तर्क दें। ++ केवल इसे करने के लिए और यह देखने के लिए कि यह कैसे जाता है। आप सही हे। परियोजना को संभवतः दोपहर में पोर्ट किया जा सकता है।

— रबरडक

Answer 3

मुझे यह कहने से नफरत है, लेकिन आपके तर्क सिर्फ पानी नहीं रखते हैं।

इकाई का परीक्षण।

यह बहुत लंबे समय से एक सुलझी हुई समस्या है। वहाँ कई यूनिट परीक्षण रूपरेखाएँ हैं। एक चुनें। आपको पहले से ही ऐसा करना चाहिए था। मैं हमारी सलाह देता हूं , क्योंकि यह आईडीई में एकीकृत है और अन्य शानदार सुविधाएं प्रदान करता है।

स्रोत नियंत्रण

यह थोड़ा कठिन है, कुछ तैयार किए गए समाधान हैं, लेकिन यह वास्तव में आपके कोड को एक रिपॉजिटरी से बाहर और बाहर निकालने का मामला है। यहाँ यह करने के लिए एक कम भौंह तरीका है , लेकिन साथ ही अन्य बेहतर विकल्प भी हैं।

कोड प्रलेखन

एक सुलझी हुई समस्या भी। MZ-Toolshas एक XML प्रलेखन सुविधा है जो .Net के XML टिप्पणी डॉक्स के समान ही काम करती है।

बेहतर कोडिंग कन्वेंशन

जैसे Visual Studio में ReSharper plugin है, MZ-Tools और Rubberduck दोनों हैं में ऐसी विशेषताएं हैं।

बेहतर आई.डी.ई.

फिर, VBA IDE के लिए प्लग-इन उपलब्ध हैं।

विधानसभाओं के माध्यम से अधिक प्रतिरूपकता - भविष्य के साधनों में फिर से उपयोग को बढ़ावा दे सकती है।

एक सुलझी हुई समस्या भी। नहीं, आप असेंबलियां नहीं बना सकते, लेकिन आप अन्य VBA प्रोजेक्ट्स का संदर्भ ले सकते हैं।

प्रबंधित परिनियोजन - यह नियंत्रित कर सकता है कि यह उपकरण किसके द्वारा उपयोग किया जाता है।

एक बिट स्टिकर, आपको यह नियंत्रित करने के लिए कोड लिखना होगा कि कौन प्रोग्राम को एक्सेस करने में सक्षम है और कौन नहीं कर सकता है, लेकिन आपको (फिर से) शायद पहले से ही लिखित सुरक्षा कोड होना चाहिए।

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

---

इस सब के शीर्ष पर, यह तथ्य है कि आप खरोंच से शुरू करेंगे। मैं भी जोएल स्पोलस्की के लेख की सिफारिश करूंगा ।

उन्होंने इसे सबसे खराब रणनीतिक गलती बना दिया जो किसी भी सॉफ्टवेयर कंपनी कर सकती है:

उन्होंने खरोंच से कोड को फिर से लिखने का फैसला किया।

आपके आईटी लोग सही हैं। आपको इसे स्क्रैच से दोबारा नहीं लिखना चाहिए। आपको अपने वर्तमान समाधान के साथ समस्याओं को हल करना चाहिए।

अब, उस सभी के साथ, मैं पूरी तरह से समझ सकता हूं कि आप इसे C # या VB.Net में क्यों करना चाहते हैं। यदि आप एक नई परियोजना शुरू कर रहे हैं, तो वे वास्तव में एक बेहतर समाधान हैं , लेकिन लगता है कि यह एक नई परियोजना नहीं है। यह बेहतर है कि आपके पास जो कुछ भी है उसे सुधारने के लिए उसे शुरू करके तोड़ दें।

Answer 4

आप इस लेख में Microsoft राज्यों को भी इंगित कर सकते हैं :

सुविधाओं को बेहतर बनाने के लिए या बग्स को ठीक करने के लिए कोड को अपडेट करने के लिए यह आवश्यक होगा कि ऑफिस की कलाकृतियों को फिर से ईमेल किया जाए, फिर से संरचित किया जाए, और हर एक उपयोगकर्ता द्वारा और अनुकूलन का उपयोग करने वाली हर एक फ़ाइल में फिर से काम किया जाए।

लेख कार्यालय पर आधारित सामान के विकास के विभिन्न तरीकों के बारे में है, शायद आप अपनी चर्चा में कुछ अन्य पेशेवरों और विपक्षों से भी ले सकते हैं।

Comments

हाँ। डिलीवरी यहां प्रमुख कारक है। बाकी सब शब्दार्थ है।

— रबरडक

एक अविश्वसनीय संख्या है कि मैं व्यक्तिगत निष्कर्ष पर क्यों आया हूं कि आपको दौड़ना चाहिए ... जितनी तेजी से आप VBA से दूर हो सकते हैं उतना ही चलाएं। हालांकि, आपके उपयोगकर्ताओं को समझने वाले सबसे अच्छे तर्कों में से एक यह है कि चूंकि यह कोड एक स्प्रेडशीट में समाहित है, हर बार फ़ाइल की प्रतिलिपि बनाने के बाद, यह एक और फ़ाइल है जिसे फिक्स के साथ अद्यतन करने की आवश्यकता हो सकती है, जो एक मैन्युअल प्रक्रिया है। यदि कहें, तो आपको 9 महीनों में एक प्रमुख बग मिल जाएगा, सभी प्रभावित फाइलों को अपडेट करना होगा। यह एक असंभव कार्य बन सकता है यदि वे कई OCs पर वितरित किए जाते हैं। पवित्रता-खातिर, ऐप को एक प्लग-इन एक्सेल के लिए बंडल करें।

— RLH

मुझे नहीं लगता कि मैं उस @आरएलएच के सभी से सहमत हूं। VBA कई छोटे पैमाने की समस्याओं के लिए एक समझदार समाधान है। यह तब होता है जब वितरण एक ऐसा मुद्दा बन जाता है जो विफल हो जाता है।

— रबरडैक

Answer 5

यह वास्तव में इस बात पर निर्भर करता है कि आप C # को स्थानांतरित करने का इरादा रखते हैं (यानी आप किस तकनीक का उपयोग करने जा रहे हैं)।

यदि आप OpenXML का उपयोग करने जा रहे हैं, तो आप कुल री-राइट की बात कर रहे हैं, यदि आपके पास कोई समाधान है जो काम करता है, तो अनुशंसित नहीं है।

यदि आप इंटरोप का उपयोग करने के बारे में बात कर रहे हैं, तो आप पा सकते हैं कि प्रक्रिया आश्चर्यजनक रूप से चिकनी है। मैंने पूर्व में VBA से C # (Interop के साथ) कोड का एक बहुत स्थानांतरित कर दिया है और एक बार जब आप कार्यपुस्तिका में प्लग इन हो जाते हैं, तो:

var excelApplication = new Application();
var workbook = excelApplication.Workbooks.Open(@"C:\location.xlsx");

बहुत से मामलों में आप अपने VBA कोड को कॉपी / पास्ता कर सकते हैं, फ़ंक्शन को प्री-फास्टिंग कर सकते हैं workbook., डिम को var के साथ बदल सकते हैं आदि जहां उपयुक्त हो और अंत पर अर्धविराम जोड़ने।

यह मूल रूप से एक ही फ्रेमवर्क के नीचे (एक्सेल) है, आप सिंटेक्स को VBA से C # में बदल रहे हैं।

जब आप काम पूरा कर लें, तो आवेदन को सहेजना और बंद करना सुनिश्चित करें:

workbook.Save();
excelApplication.Quit();

फिर मार्शल के साथ आवेदन जारी करें:

Marshal.ReleaseComObject(excelApplication);

मैं शायद एक्सेल एप्लिकेशन ऑब्जेक्ट के चारों ओर आईडीसोपायरी को लागू करने वाला एक रैपर वर्ग लिखूंगा, फिर उपयोग करना सुनिश्चित करें using इस वस्तु का ।

अपने मामले को बनाने का एक अच्छा तरीका एक घंटे या ऐसा करना होगा, जो समय की एक छोटी सी जगह में प्रदर्शित करेगा कि आप कितनी जल्दी कोड को पोर्ट कर सकते हैं, और अपने सहयोगियों को मना सकते हैं कि यह एक अच्छा विचार है।

कोड काफी हद तक एक तरह से अपरिवर्तित रहेगा, लेकिन आपके पास विजुअल स्टूडियो के भीतर C # प्रोजेक्ट होने के सभी लाभ हैं।

Answer 6

मैं एक ही स्थिति में हूँ, एक बहुत बड़ी (Vk कोड की 20k + लाइनें) एक EXCEL कार्यपुस्तिका में बनाया गया आवेदन। Office 2013 के साथ परीक्षण करने पर यह बस काम करने में विफल रहता है, नए कार्यालय मॉडल में स्टार्ट-अप इवेंट के अनुक्रम में बदलाव के कारण माना जाता है, और संभवतः EMET के अधिक सख्त प्रवर्तन। मैं इस वर्ष Office 2013 के रोल-आउट से पहले C # और VB.NET के लिए क्रैश-रूपांतरण करने की स्थिति में हूं। अन्य, सरल (VBA वर्धित) कार्यपुस्तिकाएँ संगठन के आस-पास उपयोग की गई हैं, प्रतिरक्षा नहीं है, कुछ काम कर रहे हैं और अन्य नहीं।

त्रुटियाँ कार्यपुस्तिका_Open ईवेंट में होती हैं , जहाँ कार्यपुस्तिका की शीट अब उपलब्ध नहीं हैं, और आंतरिक EXCEL कोड में किसी VBA कोड से पहले संदर्भित किया जा रहा है।

VBA, C # और VB.NET के सभी में सहज होने के कारण मैं बाद के दोनों में रूपांतरण लिख रहा हूं। फ्रेमवर्क कोड C # में लिखा जा रहा है क्योंकि भाषा के मुहावरे मुझे VB.NET की तुलना में 3-4 बार उस भाषा में कुछ कार्यात्मक कार्यों को लिखने की अनुमति देते हैं। कोड का थोक VB.NET में है क्योंकि तब मेरा पुनर्लेखन कम व्यापक है, और वहाँ कुछ मुहावरे हैं जो C # में मौजूद नहीं हैं।

कोई भी निर्णय लेने से पहले, मैं दृढ़ता से अनुशंसा करता हूं कि आप OFFICE 2013 के साथ मौजूदा एप्लिकेशन और EMET प्रवर्तन की पूरी सीमा का परीक्षण करें, जो संगठन अगले 2-3 वर्षों में आगे बढ़ रहा है। आप, मेरी तरह, यह जान सकते हैं कि मौजूदा एप्लिकेशन किसी भी तरह से फिर से लिखे बिना उस वातावरण में नहीं चलेगा - जिस स्थिति में पुनर्लेखन के साथ-साथ डॉट नेट और वीएसटीओ भी हो सकते हैं।

परिशिष्ट:

थोड़ा स्वचालित एक्सट्रेक्ट यूटिलिटी लिखते हुए, जो वर्कबुक VBA की पूरी सामग्री के माध्यम से लूप करता है और सभी मॉड्यूल, क्लासेस और फॉर्म को फाइलों में एक्सपोर्ट करता है, 1-2 दिन का काम है, इस बात पर निर्भर करता है कि आप इसे कितना फैंस चाहते हैं। इसी तरह फाइलों को डाइरेक्टरी से एक रिक्त कार्यपुस्तिका में आयात करने के लिए रिवर्स के साथ। इन दोनों के साथ उचित स्रोत नियंत्रण में आपके सभी VBA कोड और बिल्ड होना काफी संभव है आपकी कार्यपुस्तिका के लिए स्रोत कोड से प्रक्रिया का होना संभव है।

या - एक्सेल वीबीए कोड क्लीनर जैसी मुफ्त उपयोगिता का उपयोग करें

Answer 7

मैं इस अवसर को अपने C # कौशल पर लेना चाहूंगा क्योंकि मैं वर्तमान में C # में सक्षम नहीं हूं क्योंकि मैं VBA हूं और मुझे इस तरह की परियोजना चाहिए जो मुझे "अगले स्तर" पर ले जाए।

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

मैं पुराने ऐप को C # ASAP में पोर्ट करने की सलाह देता हूं। हो सकता है कि कोई निर्णय लेने से पहले आप इस प्रक्रिया में पर्याप्त सीख सकें। कम से कम आप नई भाषा के साथ अपने कौशल को बढ़ाने के अपने लक्ष्य को प्राप्त करेंगे और अभी भी समय पर परियोजना प्राप्त करेंगे।

फिर से, यदि आपको लगता है कि इसके बारे में मजबूत है और परियोजना का निर्माण करना आपके कंधों पर आराम कर रहा है, तो इसे उसी तरह से करें जैसे आप चाहते हैं। अनुमति की अपेक्षा क्षमा प्राप्त करना हमेशा आसान होता है।