Assembly in .NET: Assembly व उसके Structure के विभिन्न हिस्सों के बारे में हमने इस पुस्तक की शुरूआत में ही काफी Detailed Discussion किया था। फिर भी यहां हम Assembly Related कुछ जरूरी बातों को फिर से Discuss कर रहे हैं, क्योंकि इन बातों को पुस्तक की शुरूआत में पूरी तरह से समझना मुि”कल था, इसलिए इन्हे वहां Discuss नहीं किया गया था।

Structure of Assembly

जब हम हमारे किसी भी .NET Program को .DLL या .EXE File के रूप में Compile करते हैं, तो वह File वास्तव में Native Machine Code में Convert नहीं होती, बल्कि एक Common Intermediate Language (CIL) में Convert होती है, जिसे Assembly File के रूप में जाना जाता है।

इसी Assembly File में Just-In-Time (JIT) Compiler के लिए भी जरूरी Instructions होती हैं, जिन्हें Use करके JIT Compiler, CIL Code को Runtime में Native Codes में Convert करता है, जिसमें अन्‍य Assembly Files का Reference भी होता है, जिन्हें Current Program में किसी जरूरत को पूरा करने के लिए Reference किया गया होता है।

सामान्‍यत: ज्यादातर Assembly Files एक Single Assembly File के रूप में Composed होते हैं, जिसके चार हिस्से होते हैं:

• MENIFEST : Assembly File के इस Manifest Part में Current Assembly की Identity होती है, उन Files की List होती है, जिन्हें Current Assembly को Create करने में Participate किया है, Assembly के विभिन्न Components का Map होता है और Current Assembly में जिन अन्‍य Assemblies को Use किया गया है, उनका Reference होता है।
• METADATA : Assembly के इस Part में Current Assembly में Use किए गए सभी Types की Information होती है।
• CIL Code : Assembly के इस Part में Current Assembly के सभी Intermediate Codes होते हैं।
• Resources : Assembly के इस Part में Current Assembly में Use किए सभी Resources जैसे कि Image Files, Media Files आदि की जानकारी होती है। ये एक Optional Part होता है।

Assembly को आसानी से समझने के लिए हम निम्न चित्रानुसार भी दर्शा सकते हैं:

Assembly Code Files को Modules के नाम से जाना जाता है। हालांकि ज्यादातर Assemblies एक Single File या Module के रूप में होती हैं, लेकिन कुछ में एक से ज्यादा Files या Module भी हो सकते हैं। जिस Assembly में Multiple Modules होते हैं, उनमें केवल एक ही File Primary Module होता है, जबकि अन्‍य सभी Files को Secondary Module के नाम से जाना जाता है।

Primary Module File में Assembly का Manifest व Secondary Module का Reference होता है। जबकि Secondary Module File का Extension .netmodule होता है। Multiple File Assemblies को एक Single Unit की तरह ही Treat किया जाता है। उन्हें एक साथ ही Deploy किया जाता है और उनका Version Number भी समान ही होता है। जैसे:

Identity of Assembly

.NET Framework में Assemblies का नाम उतना महत्वपूर्ण नहीं होताए जितना अन्‍य Operating System व Environments जैसे कि Java में होता है। बल्कि .NET Framework में Assembly की Identity ज्यादा महत्वपूर्ण होती है। किसी Assembly की Identity के भी चार मुख्‍य हिस्से होते हैं, जो आपस में मिलकर किसी Assembly को Uniquely Identify करने का काम करते हैं। ये Components निम्नानुसार हैं:

• Single Name: ये Part Current Assembly का Extension सहित नाम होता है। हर Assembly का एक Simple नाम होता है, जिसे Assembly Name या Friendly Name कहा जाता है।
• Version Number: Version Number के रूप में हर Assembly एक Integer Number होता है, जिसके बीच चार Periods का प्रयोग किया जाता है जो कि MinorVersion.Build.Revision को Represent करते हैं। जैसे 2.3.20.9 का मतलब ये है कि Current Assembly का Major Version Number 2 है, Minor Version Number 3 है, Build Number 20 है और Revision Number 9 है।
• Culture Information: Culture Information के रूप में हर Assembly एक String होता है, जो कि 2 से 5 Characters के माध्‍यम से Language या Language के साथ Country या Region को Represent करता है।
• Public Key: ये एक 128-Byte String होता है, जो कि Current Assembly को Globally Uniquely Identify करने के लिए एक Developer स्वयं Produce करता है।

Public Key वास्तव में Public/Private Key Pair का Part होता है, जो कि दो बहुत ही बडी संख्‍याओं का हिस्सा होता है, जिसका प्रयोग Digital Signature के रूप में किया जा सकता है। Public Key को Publicly Available किया जा सकता है, लेकिन Private Key को केवल उस Assembly का Owner ही Access कर सकता है। Public Key Assembly की Identity का हिस्सा होता है।

Assembly के Name व Identity से सम्बंधित जानकारियां Assembly के Manifest में Embed होती हैं, जिसे निम्न चित्रानुसार Represent किया जा सकता है:

Strongly Named Assembly

जब हम किसी Assembly में Unique Digital Signature Attach करते हैं, तो इस तरह की Assembly को Strongly Named Assembly के नाम से जाना जाता है। ये Assemblies उन Assemblies से ज्यादा Secure होती हैं। Strongly Named Assemblies का फायदा ये होता है कि हम इस बात के लिए Sure हो सकते हैं कि Assembly किसी Secured Source से आई है।

साथ ही एक बार Define किया गया Unique Digital Signature दुबारा Create नहीं होताए इसलिए इस प्रकार की Assembly ज्यादा Secure तो होती ही है, साथ ही यदि इस Assembly के Content में कोई Change करना हो, तो CLR Catching के Security Components को Modify किए बिना Change करना सम्भव नहीं होता।

जबकि एक Weakly Named Assembly में Unique Digital Signature नहीं होता। इसलिए ऐसी Assembly ज्यादा Insecure होती है। Strongly Named Assembly केवल किसी अन्‍य Strongly Named Assembly को ही Access कर सकता है।

Strongly Named Assembly बनाने के लिए Developer को स्वयं कुछ नहीं करना होताए बल्कि Developer द्वारा Assembly से सम्बंधित जरूरी Information प्राप्त करके Compiler स्वयं ही उन Information की Hashing करते हुए एक Unique Digital Signature Create करता है और उसे Assembly के साथ Attach कर देता है। Hashing करने के लिए Compiler, Assembly Developer से निम्न Information प्राप्त करता है:

• The sequence of bytes composing the assembly
• The simple name
• The version number
• The culture information
• The public/private key pair

यदि हम Visual Studio का प्रयोग करके Strongly Named Assembly Create करना चाहते हैं, तो हमें public/private Key Pair की एक File की जरूरत होती है। यदि हमारे पास ये File न हो, तो Visual Studio स्वयं इस Fire को हमारी Assembly को Strongly Named Assembly बनाने के लिए Generate कर देता है। जब एक बार public/private Key Pair File Generate हो जाती है, उसके बाद हमें निम्न Steps को Follow करना होता है:

• Open the properties of the project.
• Select the Signing tab.
• Select the Sign the Assembly check box, and enter the location of the key file or create a new one.

इन तीनों Steps को Follow करने के बाद अब यदि हम अपने Current Program को Compile करें, तो Generate होने वाली Assembly एक Strongly Named Assembly File होती है। इस पूरी प्रक्रिया को हम निम्नानुसार एक चित्र द्वारा आसानी से Represent कर सकते हैं:

जब हम Visual Studio Install करते हैं, तो Visual Studio के साथ ही String Name Tool (sn.exe) नाम का एक Tool भी हमारे Computer में Automatically Installed हो जाता है। ये एक Command Line Tool होता है, जो हमें हमारी किसी Assembly को Digitally Signed बनाने की Command Line सुविधा Provide करता है।

जब हम Professional Development करते हैं, तो हम Visual Studio जैसे किसी IDE को ही Use करते हैं। इसलिए अपने Application को Develop करने के बाद Deployment की प्रक्रिया को हम Visual Studio द्वारा ही समझने की कोशिश करेंगे।

जब हम Visual Studio का प्रयोग करके Strong Name Generate करना चाहते हैं, तो हमें सबसे पहले हमें हमारे Project के Solution Explorer में दिखाई देने वाले अपने Project पर Right Click करके Properties नाम के Option को Click करना होता है। Click करते ही हमारे सामने निम्नानुसार एक Page Display होता है:

इस Page पर हमें “Signing*” नाम के Option को Select करना होता है और उपरोक्त चित्र में दर्शा, अनुसार “<New…>” Option को Click करना होता है, जबकि यदि हम पहले से Exist किसी Signature File को Use करना चाहते हैं, तो हम <Browse…> Option को Click कर सकते हैं। Click करते ही हमारे सामने निम्नानुसार “Create Strong Name Key” नाम का एक Dialog Box Display होता है:

जैसाकि इस Dialog Box में हम देख सकते हैं कि हमने हमारी Key File का नाम MyAssemblyKeyPair.snk दिया है, क्योंकि किसी भी Signature File का Extension *.snk ही होता है।

जैसे ही जरूरी Information Fill करके हम इस Dialog Box के OK Button पर Click करते हैं, हमारी Digital Sign File Create हो जाती है, जिसे हम हमारे Project के Solution Explorer में देख सकते हैं।

Private Deployment of Assembly

जब हम किसी Target Machine पर किसी Assembly File को Normal File की तरह Copy कर देते हैं और यदि ऐसी Assembly File को किसी भी अन्‍य Library File (.DLL File) यानी अन्‍य Assembly File की जरूरत नहीं होती, तो हमारी Current Assembly File उस Target Computer पर भी बिना किसी परेशानी के ज्यों की त्यों Run हो जाती है।

इस प्रकार की Assembly, जो कि केवल Target Machine पर Copy करने मात्र से Run हो जाती है, Private Assembly कहलाती है और इस प्रकार के Deployment को XCopy Deployment कहा जाता है।

Private Assemblies को किसी भी Directory में Place करने पर वे Normal तरीके से Run होते हैं, जब तक कि उन्हें जिस किसी भी अन्‍य Supporting File की जरूरत हो, वह Current Directory में ही Available हो।

यहां तक कि हम एक ही Computer पर यदि एक ही Private Assembly को एक से ज्यादा Locations पर Store करते हैं, तो हम हर अलग Location से उसी Assembly को अलग-अलग Run कर सकते हैं।

जिस Directory में Private Assembly को Store किया जाता है, उसे Application Directory के नाम से जाना जाता है। साथ ही कोई Private Assembly, Strongly Named भी हो सकती है और Weakly Named भी।

जब हम Private Assembly Create करते हैं, तो हमें उन Private Assemblies को Windows की Registry में Register करने की जरूरत नहीं होती। इसलिए किसी Private Assembly को Uninstall करने के लिए हमें केवल उस Private Assembly को Computer System से Delete ही करना होता है।

Shared Assemblies and GAC

Private Assemblies काफी उपयोगी होती हैं, लेकिन कई बार हमें किसी DLL File को अपने Application के Central Part के रूप में Use करना होता है, जो कि हमारे Application के विभिन्न हिस्सों द्वारा Internally Shared होती है।

.NET हमें ऐसी ही एक Repository Provide करता है, जिसे Global Assembly Cache (GAC) के नाम से जाना जाता है और इस GAC में हम जिन Assemblies को Store कर देते हैं, उन्हें Shared Assembly कहते हैं। GAC की कुछ मुख्‍य बातें हैं, जिन्हें हमें याद रखना जरूरी होता है:

• GAC में केवल Strongly Named Assemblies को ही Store किया जा सकता है।
• GAC में हम .DLL या .EXE दोनों प्रकार की Assemblies को Store कर सकते हैं। लेकिन .NET के पिछले Versions में हम GAC में केवल .DLL Library Files को ही Store कर सकते थे।
• GAC, Windows System Directory की Subdirectory में Exist होता है। .NET 4.0 से पहले ये “\Windows\Assembly” में Exist होता था। जबकि .NET 4.0 व बाद के Versions में ये “\Windows\Microsoft.NET\assembly\GAC_MSIL” नाम की Subdirectory में Exist होता है।

Installing Assemblies into GAC

जब हम हमारी किसी Assembly को GAC में Install करना चाहते हैं, तो सबसे पहले CLR के Security Components हमारी Assembly के Digital Signature को Validity के लिए Check करते हैं। यदि हमारी Assembly में Digital Signature न हो, तो CLR हमारी Assembly को GAC में Install नहीं करने देता।

CLR किसी Assembly के Digital Signature को केवल एक ही बार Check करता है। जब एक बार कोई Assembly GAC में Install हो जाती है, तो फिर CLR उसे एक Valid Assembly ही मानता है और दुबारा कभी Validity के लिए Digital Signature को Check नहीं करता।

GAC में किसी Assembly को Install करने के लिए हम gacutil.exe नाम के Command Line Utility Tool को Use कर सकते हैं, जो कि हमें GAC में किसी Assembly को Install या GAC से किसी Assembly को Delete करने की सुविधा Provide करता है तथा GAC में Exist सभी Assemblies की List Generate कर सकता है। इस Tool के साथ हम निम्नानुसार तीन में से किसी एक Flag को Use करके अपनी किसी Specific Type की Requirement को पूरा कर सकते हैं:

/i:   Inserts an assembly into the GAC
/u: Uninstalls an assembly from the GAC
/l:   Lists the assemblies in the GAC

उदाहरण के लिए यदि हम हमारी MyLibrary.dll File को GAC में Install करना चाहें, तो Command Prompt को हमें निम्नानुसार Use करना होगा:

C:\…\>gacutil -i MyLibrary.dll

जबकि इसी Library को GAC से Uninstall करने के लिए हमें निम्न Statement Use करना पडेगा:

C:\…\>gacutil -u MyLibrary.dll

लेकिन सामान्‍यत: हम ये काम Command Prompt द्वारा नहीं करते। क्योंकि Professional Development के लिए हम Visual Studio Use करते हैं और Visual Studio का प्रयोग करके बडी ही आसानी से Setup File Create किया जा सकता है, जिसका प्रयोग Application को किसी भी Computer पर Install करने के लिए किया जा सकता है।

जब एक बार हम हमारी किसी Assembly को GAC में Install कर देते हैं, उसके बाद हम उस Assembly को किसी भी .NET Application में Use कर सकते हैं।

जैसाकि हम जानते हैं कि एक Assembly File में Assembly की Unique Identity को Assembly के चारों भागों द्वारा तय किया जाता है, इसलिए यदि किसी Library File यानी Assembly का Version Number Change होता है या उसकी Public Key में अन्तर आता है, तो ये अन्तर Different Assemblies को Refer करते हैं।

परिणामस्वरूप एक ही GAC में एक ही नाम की कई Assemblies Exist हो सकती हैं, जो कि Internally एक दूसरे से चारों में से किसी एक या अधिक Parts के आधार पर अलग हो सकती हैं। Assemblies के Unique Identity के लिए इस 4 Part Unique Identity System की वजह से अलग-अलग Applications समान नाम की Assembly Exist होने के बावजूद उन्हीं Assemblies को Use करते हैं, जिनकी उन्हें जरूरत होती है। साथ ही समान नाम होने के बावजूद भी उनके बीच Name Conflict नहीं होता।

समान समय पर समान नाम की Assembly Exist होने पर भी हर Application अपनी ही Particular Assembly Copy को Use करता है। इस प्रक्रिया को .NET Framework में Side by Side Execution के नाम से जाना जाता है, जिसे निम्न चित्रानुसार आसानी से समझा जा सकता है:

Configuration File

Configuration File में Current Application से सम्बंधित Information होती है, जिसे CLR Runtime में Use करता है। ये Configuration File, CLR को Runtime में अलग-अलग तरह का काम करने के लिए Instruct करता है।

उदाहरण के लिए Different Version की DLL File की Searching के लिए अथवा किसी DLL Reference की Searching के लिए Additional Directories में Searching के लिए CLR को Runtime में Instruct कर सकता है।

Configuration File एक XML Code File होती है, जिसमें C# Code नहीं होते। इस Configuration File का प्रयोग करके हम किसी Assembly का Version Change होने पर उस Application Assembly को Update करने के लिए किया जाता है।

उदाहरण के लिए मानलो कि हमारा Application किसी GAC में Exist DLL को Reference करता है। GAC में Exist इस Referenced DLL Assembly की Identity हमारे Application के Manifest में Exist Identity से Exactly Match होती है।

लेकिन यदि हमारे Application की Assembly का Version Change होता है। परिणामस्वरूप यदि हम एक नए Version की Assembly को GAC में Install करेंगे, तो हालांकि दोनों Assemblies का नाम समान होगा, फिर भी दोनों Assemblies GAC में साथ में Coexist हो सकते हैं।

हालांकि हम नए Version की Assembly को GAC में Install कर देते हैं, लेकिन हमारा Application अभी भी पुराने Version की GAC Assembly को ही Reference करता। क्योंकि हमने हमारे Application द्वारा Shard Assembly को तो नए Version के लिए Modify करके GAC में Store कर दिया है, लेकिन अपने Application को नए Version की Shared Assembly का Reference Specify नहीं किया है।

यदि हम हमारे Application को नए Version की Shared Assembly का Reference Specify करना चाहें, तो ऐसा करने के दो रास्ते हैं। पहला रास्ता ये है कि हम हमारे Application के लिए उस नई Shared Assembly को Specify करते हुए सभी Files को फिर से Compile करें। जबकि दूसरा तरीका ये है कि हम एक Configuration File द्वारा अपने Application को नई Shared Assembly के नए Version के लिए Modify कर दें।

परिणामस्वरूप जब CLR हमारे Application को Run करते समय उस Configuration File को Check करेगा, तो उसे पता चल जाएगा कि Current Application द्वारा जिस GAC Stored Shard Library File को Use किया जा रहा है, उसका Version क्या है। इस प्रक्रिया को हम निम्न चित्र द्वारा आसानी से समझ सकते हैं:

इस चित्र में हम ये मान रहे हैं कि MyProgram.exe वह Application है, जो MyLibrary.dll को Use करता है। चूंकि MyProgram.exe को MyLibrary.dll के v.1.0.0.0 Version के लिए Compile किया गया था, इसलिए ये Program तो GAC के इसी Version की Library File को Access करता है।

लेकिन इस MyProgram.exe Application के साथ एक Configuration File भी Exist है, जो CLR को इस बात का Instruction देता है कि MyProgram.exe Application के लिए MyLibrary.dll के v.2.0.0.0 Version को Load करना है।

परिणामस्वरूप Configuration File के माध्‍यम से भी हम Application द्वारा Use की जाने वाली Shared Library File को Change कर सकते हैं, जो कि इस Configuration Files का मुख्‍य उपयोग है।

जब हम हमारे किसी Application Program के लिए किसी Configuration File को Create करते हैं, तो हमारी Configuration File का Exactly वही नाम होता है, जो हमारे Program का नाम होता है तथा Application Program के पूरे नाम के बाद .config नाम Specified होता है, जिससे CLR को इस बात का पता चल जाता है कि कौन Configuration File है और कौन Actual Program File है।

यदि हम हमारे पिछले चित्र को देखें, तो हम आसानी से समझ सकते हैं कि हमारे Program का नाम MyProgram.exe है, तो उसी Program की Configuration File का नाम MyProgram.exe.config है।

Assemblies and Internal Access Modifier

इस Chapter की शुरूआत से अब तक के Assemblies के आधार पर हम समझ सकते हैं कि Assembly File किसी भी C# Application का एक Integral Part होता है, क्योंकि इसी Assembly File में उस Application के Deployment व Version Relation की विभिन्न जरूरी जानकारियां होती हैं।

सरल शब्दों में कहें तो Assemblies किसी भी .NET Application का Fundamental होते हैं, जो हमें Cross-Language Interoperability, Versioning व Safe-Component Interaction जैसी सुविधाऐं Provide करता है। साथ ही एक Assembly एक Scope भी Define करता है, जिसमें विभिन्न Codes Execute होते हैं।

इस पुस्तक में हमने मूल रूप से public, private, protected Access Modifiers का बहुत प्रयोग किया है। लेकिन इनके अलावा internal नाम का एक और Access Modifier होता है, जिसे हम जिस किसी भी Type के साथ Use करते हैं, CLR को इस बात का Instruction मिलता है कि वह Type, Current Assembly की विभिन्न Files के लिए Accessible है, फिर भले ही Current Assembly में केवल एक File हो या दस, इस बात से कोई फर्क नहीं पडता।

यानी यदि हम किसी Class को internal Keyword के साथ Define करते हैं, अथवा बिना किसी Keyword को Specify किए हुए Define करते हैं, तो वह Class जिस Namespace में Define की गई होती है, उस Namespace में जितनी भी अन्‍य Classes व Types Define किए गए होते हैं, यदि उन सभी को एक Single Library File के रूप में Compile कर लिया जाए, तो उस Library में Exist सभी Files व उन सभी Files में Exist सभी Types एक दूसरे के लिए Internally Accessible रहते हैं।

लेकिन जब जो भी Types internal होते हैं, वे केवल Current Assembly के विभिन्न सदस्यों के बीच ही Directly Accessible होते हैं। जबकि अन्‍य Assemblies के लिए ये पूरी तरह से Inaccessible यानी Hidden होते हैं।