.NET 4.0 একটি নতুন জিএসি আছে, কেন?

Question

%windir%\Microsoft.NET\assembly\নতুন জিএসি । এর অর্থ কি এখন আমাদের দুটি জিএসি পরিচালনা করতে হবে, একটি নেট নেট ২.০-৩.৫ অ্যাপ্লিকেশনগুলির জন্য এবং অন্যটি নেট 4.0.০ অ্যাপ্লিকেশনগুলির জন্য?

প্রশ্ন হচ্ছে, কেন?

Comments

প্রশ্ন জিজ্ঞাসা করার জন্য ধন্যবাদ .. আমি যখন খুব সহজেই তার মূল অবস্থানটি খুঁজে পাইনি তখন আমি খুব বিভ্রান্ত হয়ে পড়েছি :)

— জাসল

ভাল প্রশ্ন ... অনেক ধন্যবাদ।

— স্মিভিকিপিডিয়া

আপনার প্রশ্নের জন্য +1। আমি নেট ৩.০ এর অধীনে উন্নয়ন শুরু করেছি এবং "ডুয়াল" জিএসি ইস্যুতে বিভ্রান্ত হয়েছি,।

— হার্নান

এটি কয়েকটি পুনরাবৃত্তি গ্রহণ করেছে, তবে মাইক্রোসফ্ট অবশেষে .NET এ ডিএলএল হেল্ক এনেছে। হ্যাঁ!

— অযৌক্তিকভাবে

Answer 1

হ্যাঁ যেহেতু 2 টি পৃথক গ্লোবাল অ্যাসেম্বলি ক্যাশে (জিএসি) রয়েছে, তাই আপনাকে তাদের প্রত্যেককে স্বতন্ত্রভাবে পরিচালনা করতে হবে।

। নেট ফ্রেমওয়ার্ক ৪.০-তে, জিএসি কয়েকটি পরিবর্তন করেছে। জিএসি দুটি সিলেট-এ বিভক্ত ছিল, প্রতিটি সিএলআরের জন্য একটি করে।

নেট ফ্রেমওয়ার্ক 2.0 এবং। নেট ফ্রেমওয়ার্ক 3.5 উভয়ের জন্য সিএলআর সংস্করণ ব্যবহৃত হয় সিএলআর 2.0। জিএসি বিভক্ত করার জন্য পূর্ববর্তী দুটি কাঠামোর প্রকাশের কোনও প্রয়োজন ছিল না। নেট ফ্রেমওয়ার্ক ৪.০ এ পুরানো অ্যাপ্লিকেশনগুলি ভাঙ্গার সমস্যা।

সিএলআর ২.০ এবং সিএলআর ৪.০ এর মধ্যে সমস্যাগুলি এড়াতে, জিএসি এখন প্রতিটি রানটাইমের জন্য ব্যক্তিগত জিএসি'র মধ্যে বিভক্ত হয়ে গেছে main মূল পরিবর্তনটি হ'ল সিএলআর ভি 2.0 অ্যাপ্লিকেশনগুলি এখন জিএসি-তে সিএলআর ভি 4.0 অ্যাসেমব্লিশিগুলি দেখতে পাবে না।

সূত্র

কেন?

দেখে মনে হচ্ছে কারণ .NET 4.0 এ সিএলআর পরিবর্তন হয়েছিল তবে 2.0 থেকে 3.5 তে নয়। একই জিনিসটি ঘটেছিল 1.1 থেকে 2.0 সিএলআর এর সাথে। দেখে মনে হয় যে, জিএসি-তে যতক্ষণ না তারা একই সিএলআর থেকে থাকে ততক্ষণ বিভিন্ন সংঘের বিভিন্ন সংস্করণ সংরক্ষণ করার ক্ষমতা রয়েছে। তারা পুরানো অ্যাপ্লিকেশনগুলি ভাঙতে চায় না।

জিএসসি পরিবর্তনগুলি সম্পর্কে এমএসডিএন-তে নিম্নলিখিত তথ্যটি 4.0 এ দেখুন ।

উদাহরণস্বরূপ, নেট। 1.1 এবং .NET 2.0 উভয় একই জিএসি ভাগ করে নিয়েছে, তবে এই শেয়ারকৃত জিএসি থেকে অ্যাসেম্বলি লোড করা একটি নেট নেট 1.1 অ্যাপ্লিকেশন, নেট নেট অ্যাসেমসিলি পেতে পারে, যার ফলে .NET 1.1 অ্যাপ্লিকেশনটি ভেঙে যায়

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

ভবিষ্যতের সংস্করণগুলিতে সিএলআর আপডেট হওয়ার সাথে সাথে আপনি একই জিনিসটি আশা করতে পারেন। যদি কেবল ভাষা পরিবর্তিত হয় তবে আপনি একই জিএসি ব্যবহার করতে পারেন।

Comments

এই ব্লগ পোস্টটি কেবল ওপি-র আবিষ্কারকে পুনরুদ্ধার করে, কেন জিএসি বিভক্ত হওয়া দরকার তা ব্যাখ্যা করে না । এটি সুস্পষ্ট নয়, আসল জিএসি 4.0.০ টি সমাবেশকে আলাদা রাখতে যথেষ্ট সক্ষম ছিল। তাদের একটি নতুন [এসেম্বলি

— ভার্সন

@ হাস: সম্ভবত সঠিক কারণ না হলেও এটি বলে: "সিএলআর ২.০ এবং সিএলআর ৪.০ এর মধ্যে সমস্যাগুলি এড়াতে", এর ভিতরেও প্রশ্নটির দুটি প্রশ্ন ছিল। দ্বিতীয় প্রশ্ন হচ্ছে: "এর অর্থ কি এখন আমাদের দুটি জিএসি পরিচালনা করতে হবে, একটি নেট নেট ২.০-৩.৫ অ্যাপ্লিকেশন এবং অন্যটি নেট নেট অ্যাপ্লিকেশনগুলির জন্য?"

— ব্রায়ান আর বন্ডি

আপনার একটি লিঙ্ক থেকে আপনার এটি উদ্ধৃত করা উচিত: "উদাহরণস্বরূপ, নেট। 1.1 এবং .NET 2.0 উভয়ই একই জিএসি ভাগ করে নিয়েছে, তাহলে এই শেয়ার্ড জিএসি থেকে একটি সংসদীয় লোড করে একটি নেট নেট 1.1 অ্যাপ্লিকেশন পেতে পারে। নেট 2.0 অ্যাসেমব্লিশগুলি , যার ফলে .NET 1.1 অ্যাপ্লিকেশনটি ভঙ্গ করা হচ্ছে। "

— সর্বাধিক তোরো

Answer 2

আমিও কেন জানতে 2 GAC চেয়েছিলেন এবং নিম্নলিখিত পাওয়া মার্ক মিলার দ্বারা ব্যাখ্যা মধ্যে মন্তব্য বিভাগে এর .NET 4.0 2 গ্লোবাল পরিষদের ক্যাশে (GAC) :

মার্ক মিলার বলেছেন ... 28 জুন, 2010 12:13 পিএম

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

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

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

এটি লক্ষণীয় যে আমরা যখন ভিএল প্রকাশ করি তখন আমরা জ্যাকের অবস্থানগুলি পরিবর্তন করেছিলাম যখন আমরা সমাবেশের পরিচয়ের অংশ হিসাবে আর্কিটেকচার চালু করি। যারা GAC_MSIL, GAC_32, এবং GAC_64 যুক্ত করেছে, যদিও এখনও সব% উইন্ডির% \ সমাবেশের অধীনে রয়েছে। দুর্ভাগ্যক্রমে, এই প্রকাশের জন্য এটি বিকল্প ছিল না।

আশা করি এটি ভবিষ্যতের পাঠকদের সহায়তা করবে।

Comments

লিঙ্কযুক্ত নিবন্ধে মিলারের মন্তব্যগুলি বিষয়টির অভ্যন্তরীণ দৃষ্টিভঙ্গি সরবরাহ করে।

— নিমেশ মাধবন

Answer 3

এটি খুব একটা বোঝায় না, আসল জিএসি ইতিমধ্যে অ্যাসেমব্লির বিভিন্ন সংস্করণ সংরক্ষণ করতে যথেষ্ট সক্ষম ছিল। এবং কোনও প্রোগ্রাম অনুমান করার ভুল কারণটি কখনই ভুল সংঘটিত ঘটেছে তা হ্রাস করার খুব কম কারণ রয়েছে, সমস্ত নেট নেট 4 টি অ্যাসেমব্লিই [এসেম্বলি ভার্শন] ৪.০.০.০ পর্যন্ত ছুঁড়েছে। প্রসেস-ইন-প্রসেস নতুন বৈশিষ্ট্যটিতে এটি পরিবর্তন করা উচিত নয়।

আমার অনুমান: সেখানে ইতিমধ্যে অনেকগুলি নেট প্রকল্প রয়েছে যা "সরাসরি জিএসি-তে কোনও কিছুই রেফারেন্স দেয় না" রীতি ভঙ্গ করে। আমি এই সাইটে এটি বেশ কয়েকবার দেখেছি।

এই প্রকল্পগুলি ভাঙ্গার এড়াতে কেবল একটি উপায়: জিএসি সরিয়ে নিন। মাইক্রোসফ্টে ব্যাক-কম্প্যাটটি পবিত্র।

Comments

এটি হ'ল একমাত্র উত্তর যা এটি কেন তা ব্যাখ্যা করার চেষ্টা করে । +1

— এড এস

@ હંস প্যাস্যান্ট: "জিএসি-তে সরাসরি কখনই কিছু উল্লেখ করা হয় না" রুল বলতে আপনার অর্থ কী?

— সর্বাধিক তোরো

@ ম্যাক্স: আপনার মেশিনে .NET সমাবেশগুলির দুটি অনুলিপি রয়েছে। এগুলি সি: \ উইন্ডোজ \ মাইক্রোসফট.এন এবং সি: \ প্রোগ্রাম ফাইলগুলি \ রেফারেন্স অ্যাসেমব্লিগুলিতে রেফারেন্স অ্যাসেমব্লিগুলি হতে বোঝায়। এবং রানটাইমের সময় ব্যবহৃতগুলি, জিএসি @ সি: \ উইন্ডোজ \ সমাবেশ। তারা একই নয়, 64৪-বিট উদাহরণ হবে। মাইক্রোসফ্ট শেল এক্সটেনশান হ্যান্ডলারের সাহায্যে জিএসি'র কথা উল্লেখ না করার জন্য যথাসাধ্য চেষ্টা করেছিল। এবং অ্যাড রেফারেন্স ডায়ালগ। 100% কার্যকর নয়

— হ্যানস প্যাস্যান্ট

@ હંস প্যাস্যান্ট: প্রত্যক্ষ রেফারেন্সটি 'সি: I উইন্ডোজস \ এসেম্বলি \ জিএসি_এমএসআইএল \ সিস্টেম \ ২.০.০.০__b77a5c561934e089 \ System.dll' এর মতো কিছু, আমি দেখতে পাচ্ছি না যে নতুন সংস্করণ যুক্ত করলে সেই রেফারেন্সটি কীভাবে ভেঙে যায়।

— ম্যাক্স তোরো

@ હંস প্যাস্যান্ট: "এবং কোনও প্রোগ্রামটি ভুলক্রমে ভুল ঘটনাটিকে ভুলভাবে উল্লেখ করার খুব কম কারণ আছে" আমি মনে করি যে এখানে মূল কীটি আছে Assembly.LoadWithPartialName, যদি আমাদের জিএসি তে অ্যাসেম্বলির ২ টি সংস্করণ থাকে তবে কী হবে?

— সর্বাধিক তোরো