.NET এ অ্যাসেমব্লির সংস্করণ করা একটি বিভ্রান্তিকর সম্ভাবনা হতে পারে যে বর্তমানে আপনার সমাবেশের জন্য কোনও সংস্করণ নির্দিষ্ট করার জন্য কমপক্ষে তিনটি উপায় রয়েছে।
এখানে মূল সংস্করণ-সম্পর্কিত তিনটি প্রধান বৈশিষ্ট্য রয়েছে:
// Assembly mscorlib, Version 2.0.0.0
[assembly: AssemblyFileVersion("2.0.50727.3521")]
[assembly: AssemblyInformationalVersion("2.0.50727.3521")]
[assembly: AssemblyVersion("2.0.0.0")]
সম্মেলনের মাধ্যমে সংস্করণটির চারটি অংশকে মেজর সংস্করণ , মাইনর সংস্করণ , বিল্ড এবং রিভিশন হিসাবে উল্লেখ করা হয় ।
AssemblyFileVersionস্বতন্ত্র একটি বিল্ড সনাক্ত করতে দেয়ার উদ্দেশ্যে করা হচ্ছে পৃথক সমাবেশ
সাধারণত আপনি সমাবেশের সংস্করণ প্রতিবিম্বিত করতে ম্যানুয়ালি মেজর এবং মাইনর এসেম্বলি ফাইল ফাইলটি সেট করে রাখবেন, তারপরে আপনার বিল্ড সিস্টেমটি অ্যাসেমব্লিকে সংকলন করে প্রতিবার বিল্ড এবং / বা সংশোধন বৃদ্ধি করুন। এসেম্বলিফিলিভিশনটি আপনাকে অনন্যভাবে সমাবেশের কোনও বিল্ড সনাক্ত করতে দেয়, যাতে আপনি এটিকে কোনও সমস্যার ডিবাগ করার জন্য একটি প্রাথমিক পয়েন্ট হিসাবে ব্যবহার করতে পারেন।
আমার বর্তমান প্রকল্পে আমাদের বিল্ড সার্ভারটি আমাদের উত্স নিয়ন্ত্রণ সংগ্রহস্থল থেকে পরিবর্তন তালিকাটি এনকোড করে এসেম্বলফায়ারভিশনের বিল্ড এবং রিভিশন অংশগুলিতে প্রবেশ করবে। এটি আমাদের বিল্ড সার্ভার দ্বারা উত্পাদিত যে কোনও সমাবেশের জন্য (উত্স নিয়ন্ত্রণে লেবেল বা শাখাগুলি ব্যবহার না করে বা ম্যানুয়ালি প্রকাশিত সংস্করণগুলির রেকর্ড না রেখে) কোনও সমাবেশ থেকে সরাসরি তার উত্স কোডে ম্যাপ করার অনুমতি দেয়।
এই সংস্করণ নম্বরটি উইন 32 সংস্করণ সংস্থানে সংরক্ষণ করা হয় এবং সমাবেশের জন্য উইন্ডোজ এক্সপ্লোরার সম্পত্তি পৃষ্ঠা দেখার সময় দেখা যায়।
সিএলআর বিধানসভা ফাইলভারশন সম্পর্কে কোন যত্ন করে না বা পরীক্ষা করে না।
AssemblyInformationalVersionআপনার সমগ্র পণ্য সংস্করণ প্রতিনিধিত্ব করতে দেয়ার উদ্দেশ্যে করা হচ্ছে
এসেম্বলি ইনফরমেশনাল ভার্শনটি পুরো পণ্যটির সুসংহত সংস্করণকে অনুমোদনের উদ্দেশ্যে তৈরি করা হয়েছে, এতে অনেকগুলি অ্যাসেম্বলি থাকতে পারে যা স্বতন্ত্রভাবে সংস্করণিত হতে পারে, সম্ভবত ভিন্ন ভিন্ন সংস্করণ নীতিমালা এবং পৃথক পৃথক দলগুলির দ্বারা বিকাশ লাভ করে।
“উদাহরণস্বরূপ, কোনও পণ্যের সংস্করণ ২.০ এ বেশ কয়েকটি সমিতি থাকতে পারে; এই জাতীয় সংসদগুলির মধ্যে একটি সংস্করণ 1.0 হিসাবে চিহ্নিত হয়েছে কারণ এটি একটি নতুন সংসদ যা একই পণ্যের 1.0 সংস্করণে পাঠায়নি। সাধারণত, আপনি আপনার পণ্যটির সর্বজনীন সংস্করণ উপস্থাপনের জন্য এই সংস্করণ নম্বরটির বড় এবং ছোটখাটো অংশগুলি সেট করেছেন। তারপরে আপনি বিল্ড এবং পুনর্বিবেচনার অংশগুলিকে প্রতিবারই বাড়ান যখন আপনি তার সমস্ত সমাবেশগুলির সাথে একটি সম্পূর্ণ পণ্য প্যাকেজ করেন ”" - জেফ্রি রিখর, [সি # এর মাধ্যমে সি # (দ্বিতীয় সংস্করণ)] পি। 57
সিএলআর বিধানসভা সম্পর্কিত তথ্য সংস্করণ যত্ন করে না বা পরীক্ষা করে না।
AssemblyVersionশুধুমাত্র সংস্করণ সম্পর্কে CLR খেয়াল (কিন্তু এটা সমগ্র বজায় রাখে AssemblyVersion)
এসএলবি ভার্শনটি সিএলআর দ্বারা দৃ named়ভাবে নামযুক্ত অ্যাসেমব্লিকে বাঁধতে ব্যবহার করা হয়। এটি বিল্ট অ্যাসেমব্লিংয়ের মেমরিফেস্ট মেটাডেটা টেবিল এবং এটি উল্লেখ করে যে কোনও সমাবেশের এসেম্বলিফের টেবিলে সংরক্ষণ করা হয়।
এটি অত্যন্ত গুরুত্বপূর্ণ, কারণ এর অর্থ এই যে আপনি যখন দৃ strongly়ভাবে নামযুক্ত সমাবেশটি উল্লেখ করেন, আপনি সেই অ্যাসেমব্লির একটি নির্দিষ্ট সমাবেশ ভার্সনের সাথে দৃers়ভাবে আবদ্ধ হন। সাফল্যের সাথে আবদ্ধ হওয়ার জন্য পুরো অ্যাসেম্বলি ভার্সন অবশ্যই একটি সঠিক মিল হতে পারে। উদাহরণস্বরূপ, আপনি যদি বিল্ড-টাইমে দৃ strongly়ভাবে নামযুক্ত অ্যাসেমব্লির 1.0.0.0 সংস্করণ উল্লেখ করেন তবে কেবলমাত্র সেই সমাবেশের 1.0.0.1 সংস্করণ রানটাইমে পাওয়া যায়, বাঁধাই ব্যর্থ হবে! (এরপরে আপনাকে এসেম্বলি বাইন্ডিং পুনঃনির্দেশ ব্যবহার করে এটিকে ঘিরে কাজ করতে হবে ))
পুরোটা AssemblyVersionমিলতে হবে কিনা তা নিয়ে বিভ্রান্তি । (হ্যাঁ এটা করে.)
কোনও অ্যাসেম্বলি লোড হওয়ার জন্য পুরো এসেম্বলি ভার্সনকে হুবহু মিল রাখতে হবে কিনা তা নিয়ে কিছুটা বিভ্রান্তি রয়েছে। কিছু লোক এই ভ্রান্ত বিশ্বাসের অধীনে রয়েছে যে সফলতার সাথে আবদ্ধ হওয়ার জন্য কেবল অ্যাসেম্বলি ভার্সনের মেজর এবং মাইনর অংশগুলি মিলতে হয়। এটি একটি বোধগম্য ধারণা, যদিও এটি চূড়ান্তভাবে ভুল (.NET 3.5 হিসাবে) এবং এটি আপনার সিএলআর সংস্করণের জন্য যাচাই করা তুচ্ছ। কেবলমাত্র এই নমুনা কোডটি কার্যকর করুন ।
আমার মেশিনে দ্বিতীয় সমাবেশের লোড ব্যর্থ হয় এবং ফিউশন লগের শেষ দুটি লাইন এটি পুরোপুরি পরিষ্কার করে দেয় কেন:
.NET Framework Version: 2.0.50727.3521
---
Attempting to load assembly: Rhino.Mocks, Version=3.5.0.1337, Culture=neutral, PublicKeyToken=0b3305902db7183f
Successfully loaded assembly: Rhino.Mocks, Version=3.5.0.1337, Culture=neutral, PublicKeyToken=0b3305902db7183f
---
Attempting to load assembly: Rhino.Mocks, Version=3.5.0.1336, Culture=neutral, PublicKeyToken=0b3305902db7183f
Assembly binding for failed:
System.IO.FileLoadException: Could not load file or assembly 'Rhino.Mocks, Version=3.5.0.1336, Culture=neutral,
PublicKeyToken=0b3305902db7183f' or one of its dependencies. The located assembly's manifest definition
does not match the assembly reference. (Exception from HRESULT: 0x80131040)
File name: 'Rhino.Mocks, Version=3.5.0.1336, Culture=neutral, PublicKeyToken=0b3305902db7183f'
=== Pre-bind state information ===
LOG: User = Phoenix\Dani
LOG: DisplayName = Rhino.Mocks, Version=3.5.0.1336, Culture=neutral, PublicKeyToken=0b3305902db7183f
(Fully-specified)
LOG: Appbase = [...]
LOG: Initial PrivatePath = NULL
Calling assembly : AssemblyBinding, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null.
===
LOG: This bind starts in default load context.
LOG: No application configuration file found.
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework64\v2.0.50727\config\machine.config.
LOG: Post-policy reference: Rhino.Mocks, Version=3.5.0.1336, Culture=neutral, PublicKeyToken=0b3305902db7183f
LOG: Attempting download of new URL [...].
WRN: Comparing the assembly name resulted in the mismatch: Revision Number
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.
আমি মনে করি এই বিভ্রান্তির কারণ সম্ভবত মাইক্রোসফ্ট কেবলমাত্র মেজর এবং মাইনর সংস্করণের অংশগুলিতে মিল রেখে পুরো অ্যাসেমব্লিউ ভার্শনটির এই কড়া ম্যাচিংয়ের জন্য আরও কিছুটা হালকা হতে চেয়েছিল:
"অ্যাসেম্বলি লোড করার সময়, সিএলআর স্বয়ংক্রিয়ভাবে সর্বশেষতম ইনস্টলড সার্ভিসিং সংস্করণটি সন্ধান করবে যা অনুরোধ করা হচ্ছে সমাবেশের প্রধান / গৌণ সংস্করণের সাথে মিলে।" - জেফ্রি রিখর, [সি # এর মাধ্যমে সি # (দ্বিতীয় সংস্করণ)] পি। 56
1.0 সিএলআর এর বিটা 1 তে এটি ছিল, যদিও এই বৈশিষ্ট্যটি 1.0 প্রকাশের আগে মুছে ফেলা হয়েছিল, এবং .NET 2.0 তে পুনরায় পৃষ্ঠপোষকতা করতে সক্ষম হয়নি:
“দ্রষ্টব্য: সংস্করণ সংখ্যা সম্পর্কে আপনার কীভাবে চিন্তা করা উচিত তা আমি কেবল বর্ণনা করেছি। দুর্ভাগ্যক্রমে, সিএলআর সংস্করণ সংখ্যাগুলি এভাবে আচরণ করে না। । )। যাইহোক,
মাইক্রোসফ্ট সিএলআর-এর লোডারকে ভবিষ্যতের সংস্করণে পরিবর্তন করার পরিকল্পনা করেছে যাতে এটি কোনও সমাবেশের প্রদত্ত প্রধান / গৌণ সংস্করণের জন্য সর্বশেষ বিল্ড / রিভিশনটি লোড করে। উদাহরণস্বরূপ, সিএলআর-এর ভবিষ্যতের সংস্করণে, যদি লোডার একটি অ্যাসেমব্লির 1.2.3.4 সংস্করণ এবং 1.2.5.0 সংস্করণ উপস্থিত থাকার চেষ্টা করে তবে লোডার স্বয়ংক্রিয়ভাবে সর্বশেষ সার্ভিসিং সংস্করণটি বেছে নেয়। এটি সিএলআরের লোডারে একটি খুব স্বাগত পরিবর্তন হবে - আমি যার জন্য অপেক্ষা করতে পারি না। " - জেফ্রি রিখর, [সি # এর মাধ্যমে সি # (দ্বিতীয় সংস্করণ)] পি। 164 (জোর আমার)
যেহেতু এই পরিবর্তনটি এখনও কার্যকর করা হয়নি, তাই আমি মনে করি এটি নিরাপদ যে মাইক্রোসফ্ট এই অভিপ্রায়টি ফিরে পেয়েছিল এবং এখনই এটি পরিবর্তন করতে খুব দেরী হয়েছে। এই পরিকল্পনাগুলির সাথে কী ঘটেছিল তা অনুসন্ধান করার জন্য আমি ওয়েবের চারপাশে অনুসন্ধান করার চেষ্টা করেছি, তবে আমি কোনও উত্তর পাই না find আমি এখনও এটি নীচে যেতে চেয়েছিলেন।
তাই আমি জেফ রিখটারকে ইমেল করেছিলাম এবং সরাসরি তাকে জিজ্ঞাসা করি - আমি বুঝতে পেরেছিলাম যে কেউ কী ঘটেছে তা যদি জানা থাকে তবে তা সে হবে।
তিনি শনিবার সকালে কম ঘন্টার মধ্যে 12 ঘন্টার মধ্যে জবাব দিয়েছিলেন এবং স্পষ্ট করে দিয়েছিলেন যে .NET 1.0 বিটা 1 লোডার একটি সমাবেশের সর্বশেষ উপলব্ধ বিল্ড এবং রিভিশনটি বাছাইয়ের এই 'স্বয়ংক্রিয় রোল-ফরোয়ার্ড' প্রক্রিয়াটি বাস্তবায়িত করেছিল, তবে এই আচরণটি ছিল .NET 1.0 শিপডের আগে ফেরানো হয়েছিল। পরে এটি পুনরুদ্ধার করার উদ্দেশ্যে করা হয়েছিল তবে এটি সিএলআর 2.0 প্রেরণের আগে এটি তৈরি করতে পারেনি। তারপরে সিলভারলাইট এসেছিল, যা সিএলআর দলের পক্ষে অগ্রাধিকার নিয়েছিল, সুতরাং এই কার্যকারিতাটি আরও বিলম্বিত হয়েছিল। ইতিমধ্যে, সিএলআর ১.০ বিটা ১-এর দিনগুলির বেশিরভাগ লোকেরা এরপরে চলে গেছে, সুতরাং এর মধ্যে ইতিমধ্যে যে সমস্ত কঠোর পরিশ্রম করা হয়েছিল তা সত্ত্বেও এটি দিনের আলো দেখতে পাবে না।
বর্তমান আচরণ, মনে হয় এটি এখানেই রয়েছে।
জেফের সাথে আমার আলোচনার বিষয়টিও লক্ষ্য করার মতো যে, 'স্বয়ংক্রিয় রোল-ফরোয়ার্ড' প্রক্রিয়াটি অপসারণের পরে কেবল এসেম্বলি ফাইল ভার্সন যুক্ত করা হয়েছিল - কারণ ১.০ বিটা ১-এর পরে, অ্যাসেম্বলি ভার্সনের কোনও পরিবর্তন আপনার গ্রাহকদের জন্য একটি ব্রেকিং পরিবর্তন ছিল, তখন ছিল কোথাও আপনার বিল্ড নম্বর নিরাপদে সংরক্ষণ করতে। এসএলএফিলি ভার্শনটি সেই নিরাপদ আশ্রয়স্থান, যেহেতু এটি কখনই সিএলআর দ্বারা স্বয়ংক্রিয়ভাবে পরীক্ষিত হয় না। মেজর / মাইনর (ব্রেকিং) এবং বিল্ড / রিভিশন (অ-ব্রেকিং) অ্যাসেম্বলি ভার্সনের অংশগুলির মধ্যে পৃথক করার চেষ্টা করার পরিবর্তে পৃথক অর্থ সহ দুটি পৃথক সংস্করণ সংখ্যা থাকা, সম্ভবত এটি সেভাবে আরও স্পষ্ট।
মূল লাইন: আপনি কখন নিজের পরিবর্তন করবেন সে সম্পর্কে সাবধানতার সাথে চিন্তা করুন AssemblyVersion
নৈতিকতাটি হ'ল আপনি যদি অ্যাসেমব্লিগুলি শিপিং করে থাকেন যেগুলি অন্যান্য বিকাশকারীরা রেফারেন্সিং করতে চলেছে, আপনি যখন এই পরিষদগুলির অ্যাসেম্বলি ভার্সন পরিবর্তন করবেন (এবং করবেন না) তখন আপনাকে অত্যন্ত সতর্কতা অবলম্বন করা উচিত। অ্যাসেম্বলি ভার্সনের যে কোনও পরিবর্তনের অর্থ হ'ল অ্যাপ্লিকেশন বিকাশকারীগণকে হয় নতুন সংস্করণটির বিরুদ্ধে পুনরায় সংকলন করতে হবে (সেই সমস্ত এসেম্বলাইফ এন্ট্রি আপডেট করতে হবে) অথবা বাইন্ডিংটিকে ম্যানুয়ালি ওভাররাইড করার জন্য অ্যাসেম্বলি বাইন্ডিং পুনঃনির্দেশগুলি ব্যবহার করতে হবে।
- পিছনে সামঞ্জস্যপূর্ণ হওয়ার উদ্দেশ্যে যা সার্ভিসিং রিলিজের জন্য এসেম্বলি ভার্সনটি পরিবর্তন করবেন না ।
- না মুক্তি আপনাকে জানাতে চাই যে অবিচ্ছিন্ন পরিবর্তনসমূহ আছে জন্য AssemblyVersion পরিবর্তন করুন।
কেবলমাত্র mscorlib এর সংস্করণ বৈশিষ্ট্যগুলিতে অন্য একবার দেখুন:
// Assembly mscorlib, Version 2.0.0.0
[assembly: AssemblyFileVersion("2.0.50727.3521")]
[assembly: AssemblyInformationalVersion("2.0.50727.3521")]
[assembly: AssemblyVersion("2.0.0.0")]
দ্রষ্টব্য যে এটি অ্যাসেমবিলি ফাইল ভার্সন যাতে আকর্ষণীয় সার্ভিসিংয়ের তথ্য রয়েছে (এটি এই সংস্করণটির সংশোধনী অংশ যা আপনাকে জানায় যে আপনি কী সার্ভিস প্যাক করছেন তা), এর মধ্যে অ্যাসেম্বলি ভার্সনটি বিরক্তিকর পুরানো 2.0.0.0 এ স্থির করা হয়েছে। অ্যাসেম্বলি ভার্সনের যে কোনও পরিবর্তনই প্রতিটি .NET অ্যাপ্লিকেশনকে mscorlib.dll রেফারেন্স করে নতুন সংস্করণের বিরুদ্ধে পুনরায় সংকলন করতে বাধ্য করবে!