.Cs ফাইলগুলি প্রকল্পের সাথে সংযোগের মাধ্যমে .dll ফাইলগুলি ব্যবহার করার সুবিধা (আমার নিজস্ব জেনেরিক সহায়ক শ্রেণি / এক্সটেনশন পদ্ধতিগুলির জন্য)


38

আমার একটি সহায়ক প্রকল্প রয়েছে যা আমি তৈরি করা সমস্ত অ্যাপ্লিকেশনগুলিতে ব্যবহার করি। এটিতে কিছু এক্সটেনশন পদ্ধতি এবং জেনেরিক হেল্পার ক্লাস, নিয়ন্ত্রণ ইত্যাদি রয়েছে I আমি সময়ে সময়ে সহায়তা প্রকল্প আপডেট / প্রসারিত করি। এগুলি সাধারণত ছোট এবং সম্পর্কিত সম্পর্কিত প্রকল্প হয় এবং আমি কেবলমাত্র তাদের সকলের সাথেই কাজ করি।

এটি ব্যবহারের জন্য আমি দুটি পদ্ধতির চেষ্টা করেছি

  • আমি যেখানে সেগুলি ব্যবহার করি প্রতিটি প্রকল্পে সরাসরি .cs ফাইল যুক্ত করুন (লিঙ্ক হিসাবে যুক্ত করুন)
  • এটি .dll হিসাবে সংকলন করুন এবং এটি রেফারেন্স হিসাবে যুক্ত করুন

আমি এই পদ্ধতির কিছু সুবিধা এবং ত্রুটিগুলি দেখতে পাচ্ছি।
প্রথমটি:

  • সহজ, কারণ সহায়ক শ্রেণিগুলি এক্স ফাইলের মধ্যে সংকলিত হয়ে যায়, তাই আমি খুব সহজেই কেবল খুব সহজেই কেবল একটি একক .এক্সে ফাইল সরবরাহ করতে পারি যা ঠিক কাজ করবে। যেহেতু আমি লিঙ্ক হিসাবে যুক্ত করেছি, আমি নিশ্চিতভাবে নিশ্চিত হতে পারি যে যখনই আমি কোনও প্রকল্প তৈরি করি যা সহায়ক ব্যবহার করে, সহায়ক ফাইলগুলি সর্বশেষতম সংস্করণ হবে।
  • আরও সহজ, কারণ আমি ফাইলগুলি পৃথক করতে পারি, যাতে .NET 4.0 এ আমার এক্সটেনশন পদ্ধতিগুলি। নেট 4.5.৪ এর প্রয়োজন থেকে আলাদা আলাদাভাবে উল্লেখ করা যায়, যার অর্থ পুরো অ্যাপ্লিকেশন নেট নেট on.০ এ চলতে পারে that
  • ব্রেকপয়েন্টস ইত্যাদির সমস্ত সুবিধা সহ কোডের মাধ্যমে ডিবাগ করার অনুমতি দেয় ...
  • 'সেরা অনুশীলন' বলে মনে হয় না

দ্বিতীয়টি:

  • সঠিক পদ্ধতির বলে মনে হচ্ছে তবে:
  • আমার একটি পৃথক .dll ফাইল সরবরাহ করার প্রয়োজন, যা কোনও কারণে ব্যবহারকারীদের পক্ষে অনেক বেশি কঠিন (তারা আমার প্রোগ্রামগুলি .dll ছাড়াই ভাগ করে নেওয়ার প্রবণতা বোধ করেন যা পরে শুরুতে ক্র্যাশ হয়))
  • যেহেতু এটি একটি একক। dll তে সংকলিত হয়ে যায় তাই এর জন্য নেট নেট এর সর্বোচ্চ সংস্করণ প্রয়োজন হবে - আমার অনেক ব্যবহারকারীর কাছে নেট নেট নেই 4.5.৪ এবং আমার সহায়ক শ্রেণীর কিছু উপাদানকেই এটির প্রয়োজন হয়, যার অর্থ আমি কিছু লোককে বাধ্য করতে পারি বিনা কারণে তাদের সিস্টেম আপডেট করতে
  • আমার এটিও নিশ্চিত হওয়া দরকার যে যখনই আমি আমার কোনও প্রোগ্রাম আপডেট করি, আমি .dll ফাইলটি সরবরাহ করি - যদিও আমি জানি না যে এটি শেষ সংস্করণ থেকে পরিবর্তিত হয়েছে কিনা, না (এটি হতে পারে তবে এটি ছিল) একই সংস্করণ হতে পারে)। আমি এটি নির্ধারণের সহজ উপায়টি দেখতে পাচ্ছি না, অ্যাসেম্বলি সংস্করণটি ট্র্যাক না করে যা অতিরিক্ত কাজ। আপাতত, আমি যখন আমার প্রোগ্রামগুলি আপডেট করি তখন আমি কেবল আপডেট এক্সই সরবরাহ করি এবং আমি এটিকে ছোট এবং নিম্ন প্রোফাইল রাখতে চাই।

তো, এখানে .dll ফাইলটি ব্যবহারের আসল উপকারটি কী? দয়া করে মনে রাখবেন, আমি সমস্ত অ্যাপ্লিকেশন এবং সহায়ক ফাইলগুলির একমাত্র ব্যক্তি সম্পাদনা কোড।


এছাড়াও, স্পষ্ট করার জন্য - অ্যাপ্লিকেশনগুলি সাধারণত খুব সামান্য হয়, তবে সহায়ক শ্রেণিতে অন্তর্ভুক্ত কোডগুলি তাদের সকলের জন্য সম্পূর্ণ জেনেরিক (কিছু সাধারণ স্ট্রিং-তুলনা, পাথ বা এক্সএমএল ক্রিয়াকলাপ ইত্যাদি) is


আসলে, কেউ আমাকে এখনই উপলব্ধি করিয়েছে যে তৃতীয় বিকল্প রয়েছে। যেহেতু আমার একটি সেপার্ট প্রকল্পে সহায়ক কোড রয়েছে, আমি এই প্রকল্পটি আমার প্রতিটি পৃথক অ্যাপ্লিকেশনগুলির সমাধানগুলিতে যুক্ত করতে পারি - যা কেবলমাত্র একটিমাত্র প্রকল্প যুক্ত না করেই একক ফাইলগুলির জন্য 'অ্যাড লিঙ্ক অ্যাড' জাতীয় ধরণের কাজ করে ... তবে ডক ব্রাউন যেমন লক্ষ্য করেছেন, এর মূল অর্থ হ'ল .dll যেভাবেই হোক এই প্রকল্পে যুক্ত করা দরকার ...

তবুও আরেকটি জিনিস যা dll ফাইলগুলি ব্যবহার না করার পক্ষে, তা হেল্পার ক্লাসের মাধ্যমে সক্রিয়ভাবে ডিবাগ করার ক্ষমতা ...


3
আপনি ঠিক বলেছেন, এবং আমি এটিও করছি, এটি উচ্চতর নেট নেট প্রয়োজনীয়তার ক্ষেত্রে সহায়তা করে ... তবে আমি এটি করা পছন্দ করি না ... 40 কেবি অ্যাপ্লিকেশনটির জন্য ইনস্টলারটি ওভারকিলের কিছুটা হলেও :)
বার্তোসজ

3
ভাল আপনি সর্বদা কোস্টুরার মতো কিছু ব্যবহার করতে পারেন এটি ডিএলএলগুলি মার্জ করার জন্য একটি সরঞ্জাম। আপনি একটিমাত্র ফাইল রেখে এবং প্রয়োজনীয় যে কোনও লাইব্রেরি ব্যবহার করার অনুমতি দিয়ে আপনি সমস্ত নির্ভরতা EXE এর সাথে একীভূত করতে পারেন। সরলতার জন্য এটি বিল্ড প্রক্রিয়াতে স্বয়ংক্রিয় করা যেতে পারে।
Kroltan

2
আপনি যখন কোনও সমস্যার সমাধানে একটি প্রকল্প যুক্ত করেন, আপনি উপরে উল্লিখিত সমস্ত ত্রুটিগুলি সহ আপনাকে এখনও এই প্রকল্পের ডিএলএল স্থাপন করতে হবে।
ডক ব্রাউন

2
@ ডকব্রাউন - পবিত্র জঞ্জাল, আপনি ঠিক বলেছেন :)
বার্তোসপ

1
.Cs ফাইল বা প্রকল্পগুলিতে লিঙ্ক করাতে অন্য একটি ত্রুটি থাকতে পারে। আপনি যদি অনেকগুলি প্রকল্পে এই ভাগ করা ফাইলগুলি ব্যবহার করে থাকেন এবং একটি প্রকল্পের জন্য আপনার ভাগ করা লাইব্রেরিগুলিতে একটি ব্রেকিং পরিবর্তন প্রয়োজন হয়, আপনার এখন আপনার অন্যান্য প্রকল্পগুলি রিফেক্টর করতে হবে। রেফারেন্সিং ডেলস আপনাকে তা থেকে উত্তাপ দেয় যদি আপনার কোডের আপডেট যুক্তিযুক্তকরণের প্রয়োজন না থাকে। আমি যখন ভাগ করা প্রকল্পগুলিতে কাস্টম প্রমাণীকরণের মতো জিনিসগুলিতে জড়িত তখন আমি এই সমস্যাগুলির মধ্যে থাকা উন্নয়ন দলগুলির অংশ হয়েছি। গ্রাহক নতুন অ্যাপ্লিকেশনটির জন্য একটি পরিবর্তন চেষ্টা করতে চান এবং এখন আপনার সাধারণ লাইব্রেরিটি কোনওভাবে সংস্করণ করা দরকার। Dlls ব্যবহার করে তা করেন।
এল্লেসিল

উত্তর:


13

আপনি ইতিমধ্যে বেশিরভাগ উপকারিতা এবং কনসকে সন্ধান করেছেন। সিএস ফাইলগুলিকে রেফারেন্স হিসাবে ব্যবহার করা প্রকৃতপক্ষে আরও স্বল্প ওজন এবং পরিচালনা করা প্রায়শই সহজ। যাইহোক, যখন আপনার csফাইলগুলি সম্পূর্ণ স্ব-অন্তর্ভুক্ত থাকে এবং কোনও বিশেষ বিল্ড প্রয়োজনীয়তা না থাকে তখন আমি এই পদ্ধতিটি একচেটিয়াভাবে ব্যবহার করার পরামর্শ দিই ।

পৃথক ডিএলএল ব্যবহার করা

  • অন্যান্য ইউটিলিটি বা লাইব্রেরিগুলির উপর নির্ভরশীলতাগুলি সুস্পষ্ট করে তুলবে (যতক্ষণ না আপনার পক্ষে এই ধরনের নির্ভরতা না থাকে, এটি কার্যকর থাকবে)

  • আপনাকে নির্দিষ্ট বিল্ড কনফিগারেশনগুলি সংজ্ঞায়িত করার অনুমতি দেবে (উদাহরণস্বরূপ, যদি কোনও শ্রেণি কেবল x86 কনফিগারেশনে কাজ করে বা কমপক্ষে .NET 4.0 প্রয়োজন হয় তবে সমাবেশের বিল্ড কনফিগারেশনটি এই প্রয়োজনীয়তাটি সুস্পষ্ট করে তোলে)।

সুতরাং বিশেষত আপনার যদি প্রচুর একক শ্রেণীর, স্ব-র অন্তর্ভুক্ত উপাদান থাকে, তবে ফাইলগুলির জন্য রেফারেন্স ব্যবহার করা ভাল, তবে আপনার যদি অন্য উপাদানগুলি নির্দিষ্ট করে দেওয়ার উপাদান বা নির্দিষ্ট বিল্ড প্রয়োজনীয়তা থাকে তবে আমি ডিএলএল ব্যবহার করার পরামর্শ দেব।

অনেকগুলি পৃথক ডিএলএল পরিচালনার ক্ষেত্রে সমস্যাগুলি হ্রাস করার জন্য, আপনি হয় একটি ইনস্টলার প্যাকেজ তৈরি করতে পারেন, বা আইএলমার্জ ব্যবহার করতে পারেন, যা একক এক্সিকিউটেবলের মধ্যে অ্যাসেমব্লির সেট এম্বেড করতে পারে। আমাদের পরিবেশে আমরা প্রতিটি অ্যাপ্লিকেশনের জন্য একটি ডিপোলি স্ক্রিপ্ট ব্যবহার করে সমস্যাটিকে আলাদাভাবে মোকাবিলা করি। এই স্ক্রিপ্টটি নিশ্চিত করে যে কোনও নতুন অ্যাপ্লিকেশন রিলিজ প্রকাশিত হলে সমস্ত প্রয়োজনীয় ডিএলএল সর্বদা উত্পাদনে সরবরাহ করা হয়।


ঠিক আছে, আপনাকে অনেক ধন্যবাদ - সুতরাং, আমি কি সঠিকভাবে বুঝতে পারি যে, যতক্ষণ না আমার সহায়ক শ্রেণিগুলি অন্য কোনও বাহ্যিক ঘরের রেফারেন্স দেয় না (কেবলমাত্র স্ট্যান্ডার্ড। নেট কোড থাকে) সেগুলি কেবল লিঙ্ক করা কোনও ঘৃণা নয়?
বার্তোসজ

@ বার্টোস: কোনও বহিরাগত ডিএলএল নেই, এবং প্রতিটি সহায়ক শ্রেণীর আদর্শভাবে অন্য কোনও সহায়ক শ্রেণি বা একই ফাইলে সঞ্চিত কেবলমাত্র অন্যান্য সহায়ক সহায়ক ক্লাস ব্যবহার করা উচিত নয়। সত্যি কথা বলতে, কিছুটা ডিগ্রি পর্যন্ত আপনি পরিস্থিতি পরিচালনা করতে পারেন যেখানে সহায়ক শ্রেণি A এর জন্য একটি পৃথক ফাইলে সঞ্চিত হেল্পার ক্লাস বি প্রয়োজন, তবে এই পদ্ধতিরটি ভালভাবে স্কেল হয় না।
ডক ব্রাউন

1
@PeterK। - হ্যাঁ, এবং আমি করেছি :)
বার্তোসজ

1
@ ওয়াটসিসনাম: এটি কাজ করে না এমন নয়। যাইহোক, আমার কাছে এটি সমাধানের মতো শোনাচ্ছে না যা জিনিসগুলিকে সরল করে তুলবে, আরও অনেকের মতো যা অপ্রত্যাশিত সমস্যার কারণ হতে পারে ;-)
ডক ব্রাউন

1
@ ওজকান: আমাদের পরিবেশে এটি কিছু নেটওয়ার্ক শেয়ারের জন্য কেবল এক্সকপি স্থাপনা (প্রাক্তন সংস্করণটিকে ব্যাক আপ করার জন্য এবং বর্তমানে কোনও প্রোগ্রামই ব্যবহার করছে না তা নিশ্চিত করার জন্য কিছু অতিরিক্ত পদক্ষেপের সাথে - যা প্রথম স্থাপনার ফোল্ডারের নাম বদলে দেওয়ার চেষ্টা করে অর্জন করা হয়েছে)। এটি কোন ডিএলগুলি মোতায়েন করবে তা জানে কারণ আমরা স্ক্রিপ্টে প্রয়োজনীয় ডিএলএল তালিকা হার্ডকড করেছি - এর পিছনে কোনও যাদু নেই। এই সমাধানটি নিখুঁত নয়, তবে বেশ কয়েকটি ক্ষেত্রে আমাদের পক্ষে কাজ করে এমন কয়েকটি প্রোগ্রাম বাদে যা কয়েক ডজন ব্যবহারকারী ব্যবহার করে।
ডক ব্রাউন

11

যখন কোনও অ্যাপ্লিকেশন বড় হয় তখন ডিএলএলগুলি কার্যকর হয় এবং এমন কিছু টুকরোগুলি থাকে যেগুলিকে আপডেটের প্রয়োজন হয় তবে পুরো অ্যাপ্লিকেশনটি নয়। সুতরাং, আপনি যদি এমএস ওয়ার্ড লিখছেন, তবে কোনও ডিএলএলে স্পেল-চেক কোড পাওয়া সুবিধাজনক যা এমএস ওয়ার্ডের সম্পূর্ণতা আপডেট না করে আপডেট করা যায়। আপনি যা লিখছেন তা যদি কোনও ছোট্ট ইউটিলিটি অ্যাপ হয় (বা স্ব-সংযুক্ত অ্যাপগুলির একটি সিরিজ যা একই কোড ব্যবহারের ক্ষেত্রে ঘটে থাকে) কোডটি অ্যাপ্লিকেশনগুলিতে এম্বেড করা আছে কি না তাতে কোনও তাত্পর্য নেই।


2

আপনার প্রশ্নের মধ্যে আপনি এটির সংক্ষিপ্ত বিবরণ দিয়েছেন, আমার কাছে কেবল কয়েকটি পয়েন্ট যোগ করতে হবে।

মনো বিকল্পগুলি একটি নুগেট প্যাকেজের একটি দুর্দান্ত উদাহরণ যা প্রথম পদ্ধতির খুব ভাল ব্যবহার করে।

বিকল্পভাবে, আপনি যদি dlls ব্যবহার করার সিদ্ধান্ত নেন তবে আপনি এম্বেডড রিসোর্স হিসাবে আপনার এক্সিকিউটেবলের মধ্যে সেই রেফারেন্স এম্বেড করতে কস্টুরার মতো সরঞ্জাম ব্যবহার করতে পারেন । এটি ব্যবহার করতে কেবল Costura.Fodyপ্যাকেজ যুক্ত করুন :

Install-Package Costura.Fody

প্রকৃতপক্ষে, আরও একটি জিনিস রয়েছে - এম্বেড থাকা প্রকল্প বা ফাইল হিসাবে লিঙ্ক হিসাবে যুক্ত করা, আপনি সহায়ক ফাইলের মাধ্যমেও কোডটি সক্রিয়ভাবে ডিবাগ করতে পারেন ...
বার্তোসপ

1
@ বার্তোজ আমার মনে হয় আপনি যতক্ষণ না সঠিক পিডিবি ফাইল রেখেছেন ততক্ষণ আপনি "সহায়তাকারী ফাইল" ছাড়াই "সমস্ত উপায়ে" ডিবাগ করতে পারবেন।
জ্যাক

আমি কস্টুরা জিনিসটি চেষ্টা করেছিলাম এবং আমি সত্যিই এটি পছন্দ করি!
বার্তোসপ

2

একটি dll আরও উপকারী কিনা বা না তা বিভিন্ন কারণের উপর নির্ভর করে:

  1. কোডের আকার (সংকলিত হলে)।
  2. কত প্রাক্তন এটি ব্যবহার করে।
  3. আপনি কোডটি আপডেট করার জন্য কতবার মনস্থ করেন।
  4. প্রাক্তনদের একত্রে রাখা বা সম্পূর্ণ পৃথকভাবে উপস্থিত থাকার উদ্দেশ্য রয়েছে কিনা।

ভাগ করা লাইব্রেরির উদ্দেশ্য হ'ল একাধিক এক্সিকিউটেবলের কাছে সাধারণ এমন কোড নেওয়া এবং এটি কেন্দ্রীভূত করা যাতে সমস্ত এক্সিকিউটেবলের একটি অনুলিপি ভাগ করা যায়। এটি স্থান বাঁচাতে এবং কোডটি আপডেট করা আরও সহজ করার উদ্দেশ্যে is

যদি আপনার সহায়ক শ্রেণিতে কোডের পরিমাণ খুব অল্প হয়, তবে এটি কোনও ডিএল-তে স্থানান্তরিত হওয়া উপযুক্ত হবে না কারণ কোডের ওভারহেডটি একটি ডেল-এ থাকায় এটি কেন্দ্রীভূত করে রাখার স্থান সাশ্রয়ী সুবিধার বিরুদ্ধে লড়াই করতে পারে।

অতিরিক্তভাবে, আপনি যদি কেবল কয়েকটি এক্সিকিউটেবল বানাচ্ছেন তবে প্রতিটি এক্সিকিউটেবলের কোডের আকার কোনও সমস্যা না হওয়ার জন্য যথেষ্ট ছোট হতে পারে। তবে, আপনি একই কোডটি যত বেশি এক্সিকিউটেবল ব্যবহার করছেন, কোডটি একটি ডেলিতে স্থানান্তরিত করা তত বেশি উপকারী।

সরলীকৃত উদাহরণ হিসাবে, বলুন যে আপনার সহায়ক শ্রেণিটি কোনও এক্সাই ফাইলে 128 বাইটে সংকলন করে, তবে যখন কোনও ডেলিতে স্থানান্তরিত হয়, তখন ডেলটি 512 বাইট হয়। যদি আপনার কাছে কেবল 3 এক্সিকিউটেবল থাকে তবে এক্সিকিউটেবলের কোডটি অন্তর্ভুক্ত করে আপনি স্থান সংরক্ষণ করবেন। তবে আপনার যদি 5 এক্সিকিউটেবল থাকে, তবে আপনি তখন সেই জায়গায় পৌঁছাতে পারেন যেখানে আপনি একটি ডেল রাখাই ভাল কারণ সংযুক্ত স্থানটি কোডের 5 কপি (5 * 128 = 640 বাইট) দ্বারা নেওয়া স্থানের চেয়ে বেশি ডিএল (512 বাইট) কোড রেখে by

এখন বলুন উদাহরণস্বরূপ আপনি আপনার সহায়ক কোডটিতে একটি বাগ খুঁজে পান। আপনি যদি বেকড কোড সহ আপনার সমস্ত এক্সিকিউটেবলকে সংকলন করেন তবে আপনাকে প্রতিটি এক্সিকিউটেবলের পুনরায় সংকলন করতে হবে এবং তারপরে পুনরায় সংযুক্ত সংস্করণগুলি পুনরায় বিতরণ করতে হবে। আপনি যদি একটি ডেল কোডটি সংকলন করেন তবে আপনাকে কেবলমাত্র একটি ডিএল পুনরায় সংকলন করতে হবে এবং পুনরায় বিতরণ করতে হবে এবং বাগটি এটি ব্যবহার করে সমস্ত এক্সিকিউটেবলের জন্য স্বয়ংক্রিয়ভাবে স্থির করা হবে।

শেষ অবধি, কোনও প্রোগ্রামের জন্য একটি ডেল খুঁজে পাওয়ার জন্য এটি জানতে হবে কোথায় ডিলের সন্ধান করতে হবে। আপনি যদি আপনার সমস্ত এক্সিকিউটেবলকে একসাথে রাখছেন তবে আপনি কেবল ডেলিকে একই ডিরেক্টরিতে রাখতে পারেন এবং তারা সকলেই সরাসরি খুঁজে পাবেন। আপনি যদি ইচ্ছাকৃতভাবে তাদের পৃথক করে রাখেন তবে একই dll ব্যবহারের জন্য তাদের সমন্বয় করা আরও শক্ত হয়ে যায়।


1

আপনার তৃতীয় বিকল্পটি সবচেয়ে উপযুক্ত (সমাধানে এটি একটি পৃথক "শ্রেণীর গ্রন্থাগার" প্রকল্প হিসাবে যুক্ত করুন)। এটি সমস্ত পদ্ধতির সুবিধার একত্রিত করে:

  • আপনার "সহায়ক প্রকল্প" সর্বদা বিভিন্ন প্রকল্পে আপ টু ডেট থাকে।
  • আপনি দ্রুত পরিবর্তনগুলি দেখতে চাইলে আপনি প্রকল্পের কোডটি উল্লেখ করতে পারেন।
  • আপনি প্রতিবার সঠিক .NET সংস্করণে এটি তৈরি করতে পারেন।
  • আপনি যে কোনও উপায়ে কোনও ডিএলএল এম্বেড করতে পারেন, তাই আপনার বিল্ডের অংশ হিসাবে আপনার কেবল এটি থাকতে পারে তা নিয়ে চিন্তা করবেন না।

আমরা এটি সর্বদা করি এবং আমি এই পদ্ধতির প্রস্তাব দেওয়ার পরিবর্তে কিছুই করতে পারি না।

আর একটি চতুর্থ বিকল্প যা আপনি উল্লেখ করেন নি তা হ'ল এটি একটি বেসরকারী নিউগেট সংগ্রহস্থলে রাখা যা আপনাকে সঠিকভাবে সংস্করণ করতে দেয় এবং প্রতিটি সমাধানে অতিরিক্ত প্রকল্প ছাড়াই রেফারেন্স দেয়।


2
এইচএম, এটি আমার কাছে উপস্থিত হয় যে যখন আমি এটিকে সমাধান হিসাবে একটি প্রকল্প হিসাবে যুক্ত করি এবং এই প্রকল্পটি অন্যান্য প্রকল্পগুলিতে উল্লেখ করি, তখন এটি এখনও এম্বেড হওয়ার পরিবর্তে পৃথক .dll হিসাবে তৈরি হয় ... আমার নির্দিষ্ট করার মতো কিছু আছে কি?
বার্তোসজ

1

বিকাশকারী হিসাবে, আমি সর্বদা আমার অ্যাপ্লিকেশনটির ইউটিলিটির সমাধানের রেফারেন্সটি অন্তর্ভুক্ত করতে চাই কারণ এটি আমাকে কোডটি ডিবাগ করার অনুমতি দেয় (এবং ইউটিলিটিতেও সম্ভাব্য বাগগুলি চিহ্নিত করে!) এবং ইউটিলিটিতে যে কোনও পরিবর্তন স্বয়ংক্রিয়ভাবে অ্যাপ্লিকেশনটিতে অন্তর্ভুক্ত করা হয়।

সুতরাং, আসলে সিদ্ধান্তটি নির্ভর করে যে ইউটিলিটি কতটা পরিপক্ক ! আপনি যদি ইউটিলিটি বাগগুলি সম্পর্কে অনিশ্চিত থাকেন তবে বাগগুলি সন্ধান করার জন্য আপনার সর্বদা সেই ইউটিলিটির .cs ফাইলটি অন্তর্ভুক্ত করা উচিত .. তবে আপনি যদি নিশ্চিত হন যে ইউটিলিটি যথেষ্ট পরিপক্ক এবং এটি কোনও বাগ সহ ফলাফল ফিরে পাবে না এবং সেখানে ইউটিলিটি বৃদ্ধির কোনও সুযোগ নেই, আপনি এগিয়ে গিয়ে ডিএলএল ফাইল অন্তর্ভুক্ত করতে পারেন।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.