Жалпы тілдік инфрақұрылымдағы (CLI) жиналымдар – Windows жүйесінде қолданылатын, кодты тарату, нұсқалау және қауіпсіздік үшін пайдаланылатын құрал. CIL кодын қамтиды.
Ағылшыншамен салыстырыңыз: абзацты басыңыз — түпнұсқа терезеде ашылады. Абзац астындағы EN түймесі оны мәтін ішінде көрсетеді.
Мазмұны
Кіріспе
Common Language Infrastructure (CLI) тіліндегі ассамблерге балама.
the counterpart to assembly language in the Common Language Infrastructure
Microsoft компаниясы Windows-тың соңғы нұсқаларында пайдалану үшін анықтаған Common Language Infrastructure (CLI) ассамблері – тарату, нұсқаларды басқару және қауіпсіздік үшін қолданылатын компиляцияланған код кітапханасы. Оның екі түрі бар: процесс ассамблерлері (EXE) және кітапхана ассамблерлері (DLL). Процесс ассамблері кітапхана ассамблерлерінде анықталған сыныптарды пайдаланатын процесс болып табылады. CLI ассамблерлері CIL-де кодты қамтиды, ол әдетте CLI тілінен жасалады, содан кейін орындалу кезінде just-in-time компиляторымен машина тіліне компиляцияланады. .NET Framework іске асырылымында бұл компилятор Common Language Runtime (CLR) құрамына кіреді. Ассамблер бір немесе бірнеше файлдан тұруы мүмкін. Код файлдары модульдер деп аталады. Ассамблер бірнеше код модулін қамтуы мүмкін. Код модульдерін жасау үшін әртүрлі тілдерді пайдалануға болады, сондықтан ассамблерді жасау үшін бірнеше түрлі тілді қолдану техникалық тұрғыдан мүмкін. Дегенмен, Visual Studio бір ассамблерде әртүрлі тілдерді қолдануды қолдамайды.
Defined by Microsoft for use in recent versions of Windows, an assembly in the Common Language Infrastructure (CLI) is a compiled code library used for deployment, versioning, and security. There are two types: process assemblies (EXE) and library assemblies (DLL). A process assembly represents a process that will use classes defined in library assemblies. CLI assemblies contain code in CIL, which is usually generated from a CLI language, and then compiled into machine language at run time by the just in time compiler. In the NET Framework implementation, this compiler is part of the Common Language Runtime (CLR). An assembly can consist of one or more files. Code files are called modules. An assembly can contain more than one code module. And since it is possible to use different languages to create code modules, it is technically possible to use several different languages to create an assembly. Visual Studio however does not support using different languages in one assembly.
Құрастыру нұсқалары
CLI құрамалары нұсқа туралы ақпаратты қамти алады, бұл оларға ортақ құрамалардың салдарынан туындаған қосымшалар арасындағы көптеген қақтығыстарды болдырмауға көмектеседі. Дегенмен, бұл құрамалар арасындағы барлық нұсқаулық қақтығыстарды толығымен жоймайды.
CLI assemblies can have version information, allowing them to eliminate most conflicts between applications caused by shared assemblies. However, this does not eliminate all possible versioning conflicts between assemblies.
Жинақтар мен CLI қауіпсіздігі
CLI кодтық кіру қауіпсіздігі жинақтар мен дәлелдерге негізделеді. Дәлел жинақтан алынған кез келген мәлімет болуы мүмкін, бірақ көбінесе ол жинақтың бастапқы көзінен жасалады – жинақ Интернеттен, интранеттен жүктелген немесе жергілікті машинаға орнатылған (жинақ басқа машинадан жүктелген болса, ол GAC ішіндегі оқшауланған орынға сақталады және демек, жергілікті орнатылған деп есептелмейді). Рұқсаттар бүкіл жинақтарға қолданылады, ал жинақ қажетті ең төменгі рұқсаттарды арнайы атрибуттар арқылы көрсете алады (CLI метадеректеріне қараңыз). Жинақ жүктелген кезде CLR жинаққа қатысты дәлелді пайдаланып, бір немесе бірнеше кодтық кіру рұқсатынан тұратын рұқсаттар жиынтығын құрайды. CLR содан кейін осы рұқсаттар жиынтығында жинақтың талап ететін рұқсаттардың бар екенін тексереді. CLI коды кодтық кіру қауіпсіздігіне қатысты сұрау жасауға болады. Бұл кодтың артық құқықтарды талап ететін әрекеттерді тек шақыру стегіндегі барлық әдістердің барлық жинақтарында көрсетілген рұқсаттар болған жағдайда ғана орындай алатынын білдіреді. Егер бір жинақта рұқсат болмаса, қауіпсіздік қатесі туындайды. CLI коды сондай-ақ шақыру стегінен рұқсат алу үшін байланысты сұрауды орындай алады. Бұл жағдайда CLR шақыру стегіндегі ТОП позициядағы бір әдісті ғана қарастырады. Мұнда стек бойынша іздеу шақыру стегіндегі бір әдіспен шектеледі, соның арқасында CLR CALL STACK-тағы барлық басқа әдістерде де көрсетілген рұқсаттар бар деп есептейді. Жинақ – METADATA және MSIL файлының үйлесімі.
CLI Code Access Security is based on assemblies and evidence. Evidence can be anything deduced from the assembly, but typically it is created from the source of the assembly – whether the assembly was downloaded from the Internet, an intranet, or installed on the local machine (if the assembly is downloaded from another machine it will be stored in a sandboxed location within the GAC and hence is not treated as being installed locally). Permissions are applied to entire assemblies, and an assembly can specify the minimum permissions it requires through custom attributes (see CLI metadata). When the assembly is loaded the CLR will use the evidence for the assembly to create a permission set of one or more code access permissions. The CLR will then check to make sure that this permission set contains the required permissions specified by the assembly. CLI code can perform a code access security demand. This means that the code will perform some privileged action only if all of the assemblies of all of the methods in the call stack have the specified permission. If one assembly does not have the permission a security exception is thrown. The CLI code can also perform Linked Demand for getting the permission from the call stack. In this case the CLR will look at only one method in the call stack in the TOP position for the specified permission. Here the stack walk through is bound to one method in the call stack by which the CLR assumes that all the other methods in the CALL STACK have the specified permission. The Assembly is a combination of METADATA and MSIL file.
Спутниктер жиынтығы
Жалпы, жиналыстар мәдениетке бейтарап ресурстарды қамтуы керек. Егер сіз жиналымыңызды жергіліктілендіргіңіз келсе (мысалы, әртүрлі тілдер үшін әртүрлі тізбектерді пайдалану), спутниктік жиналыстарды – арнайы, тек ресурстардан тұратын жиналыстарды қолдануыңыз керек. Аты айтқандай, спутник негізгі жиналым деп аталатын жиналыммен байланысты. Бұл жиналым (мысалы, lib.dll) бейтарап ресурстарды қамтиды (Microsoft мұны халықаралық ағылшын тілі дейді, бірақ АҚШ ағылшын тілі деп түсіндіріледі). Әрбір спутниктің аты тиесілі кітапхананың атына ресурстар қосылып жазылады (мысалы, lib.resources.dll). Спутникке бейтарап емес мәдениет атауы беріледі, бірақ бұл қолданыстағы Windows файлдық жүйелерінде (FAT32 және NTFS) ескерілмейтіндіктен, бір папкада бірдей PE атымен бірнеше файл болуы мүмкін. Бұл мүмкін болмағандықтан, спутниктер қосымша папкасының ішіндегі қосалқы папкаларда сақталуы керек. Мысалы, Ұлыбритания ағылшын тіліндегі ресурстарға ие спутниктің CLI аты "lib.resources Version=0.0.0.0 Culture=en-GB PublicKeyToken=null", PE файл аты lib.resources.dll болады және en-GB деп аталатын қосалқы папкада сақталады. Спутниктер System.Resources.ResourceManager деп аталатын CLI класы арқылы жүктеледі. Дамылшы ресурстың атын және негізгі жиналым туралы ақпаратты (бейтарап ресурстармен) беруі керек. ResourceManager класы машинаның тілін анықтайды және осы ақпаратты, сондай-ақ негізгі жиналымның атын спутниктің және оны қамтитын қосалқы папканың атын алу үшін пайдаланады. Содан кейін ResourceManager спутникті жүктей алады және жергіліктілендірілген ресурсты алады.
In general, assemblies should contain culture neutral resources. If you want to localize your assembly (for example use different strings for different locales) you should use satellite assemblies – special, resource only assemblies. As the name suggests, a satellite is associated with an assembly called the main assembly. That assembly (say, lib. dll) will contain the neutral resources (that Microsoft says is International English, but implies to be US English). Each satellite has the name of the associated library appended with resources (for example lib. resources. dll). The satellite is given a non neutral culture name, but since this is ignored by existing Windows file systems (FAT32 and NTFS) this would mean that there could be several files with the same PE name in one folder. Since this is not possible, satellites must be stored in subfolders under the application folder. For example, a satellite with the UK English resources will have a CLI name of "lib. resources Version=0.0.0.0 Culture=en GB PublicKeyToken=null", a PE file name of lib. resources. dll, and will be stored in a subfolder called en GB. Satellites are loaded by a CLI class called System. Resources. ResourceManager. The developer has to provide the name of the resource and information about the main assembly (with the neutral resources). The ResourceManager class will read the locale of the machine and use this information and the name of the main assembly to get the name of the satellite and the name of the subfolder that contains it. ResourceManager can then load the satellite and obtain the localized resource.
Анықтамалық құрамалар
C# компиляторының /reference жалаушасын қолдану арқылы орындалатын код кітапханасын сілтемелеуге болады.
One can reference an executable code library by using the /reference flag of the C# compiler.
Жиналысқа қол қоюды кешіктіру
Ортақ жинақтар қолданбалар арасында ортақ пайдаланылатын жинақты бірегей анықтау үшін күшті атауды беруі керек. Күшті атау ашық кілттік таңбасы, мәдениет, нұсқасы және PE файлының атауынан тұрады. Егер жинақ дамыту мақсатында пайдаланылатын, ортақ жинақ болса, күшті атау процедурасы тек ашық кілтті жасаудан тұрады. Жеке кілт сол уақытта жасалмайды. Ол тек жинақ орнатылғанда ғана жасалады.
The shared assemblies need to give a strong name for uniquely identifying the assembly that might be shared among the applications. The strong naming consists of the public key token, culture, version and PE file name. If an assembly is likely to be used for the development purpose which is a shared assembly, the strong naming procedure contains only public key generation. The private key is not generated at that time. It is generated only when the assembly is deployed.