MSILVosSpec文档格式.docx
《MSILVosSpec文档格式.docx》由会员分享,可在线阅读,更多相关《MSILVosSpec文档格式.docx(78页珍藏版)》请在冰豆网上搜索。
1.2RelationshiptoTypeSafety9
1.3RelationshiptoManagedMetadata-drivenExecution10
1.3.1ManagedCode10
1.3.2ManagedData11
1.4RelationshiptoUnmanagedCOM12
1.5IntroductiontotheCommonLanguageSpecification(CLS)12
1.6Summary14
2TypeSystem16
2.1RelationshiptoObject-OrientedProgramming17
2.2ValuesandTypes18
2.2.1ValueTypesandReferenceTypes18
2.2.2Built-InTypes18
2.2.3Classes,InterfacesandObjects19
2.2.4BoxingandUnboxingofValues20
2.2.5IdentityandEqualityofValues20
2.2.5.1Identity21
2.2.5.2Equality21
2.3Locations22
2.3.1AssignmentCompatibleLocations22
2.3.2Coercion22
2.3.3Casting22
2.4TypeMembers24
2.4.1Fields,ArrayElements,andValues24
2.4.2Methods24
2.4.3StaticFieldsandStaticMethods25
2.4.4VirtualMethods25
2.5Naming26
2.5.1ValidNames26
2.5.2AssembliesandScoping26
2.5.3Visibility,Accessibility,andSecurity28
2.5.3.1VisibilityofTypes29
2.5.3.2AccessibilityofMembers29
2.5.3.3SecurityPermissions30
2.5.3.4NestedTypes30
2.6Contracts32
2.6.1Signatures33
2.6.1.1TypeSignatures33
2.6.1.2LocationSignatures33
2.6.1.3LocalSignatures34
2.6.1.4ParameterSignatures35
2.6.1.5MethodSignatures35
2.7AssignmentCompatibility37
2.8TypeSafetyandVerification38
2.9TypeDefiners39
2.9.1ArrayTypes39
2.9.2PointerTypes40
2.9.3InterfaceTypeDefinition41
2.9.4ClassTypeDefinition42
2.9.5ObjectTypeDefinitions43
2.9.5.1ScopeandVisibility43
2.9.5.2Concreteness43
2.9.5.3TypeMembers44
2.9.5.4SupportingInterfaceContracts44
2.9.5.5SupportingClassContracts45
2.9.5.6Constructors45
2.9.5.7Finalizers46
2.9.6ValueTypeDefinition46
2.9.7TypeInheritance47
2.9.8ObjectTypeInheritance47
2.9.9ValueTypeInheritance47
2.9.10InterfaceTypeInheritance47
2.10MemberInheritance49
2.10.1FieldInheritance49
2.10.2MethodInheritance49
2.10.3PropertyandEventInheritance49
2.10.4Hiding,Overriding,andLayout49
2.11MemberDefinitions52
2.11.1MethodDefinitions52
2.11.2FieldDefinitions52
2.11.3PropertyDefinitions53
2.11.4EventDefinitions54
2.11.5NestedTypeDefinitions54
3CLRMetadata56
3.1ComponentsandAssemblies57
3.2AccessingMetadata58
3.2.1MetadataTokens58
3.2.2MemberSignaturesinMetadata59
3.3UnmanagedCOMandUnmanagedCode60
3.4MethodImplementationMetadata61
3.5ClassLayout62
3.6Assemblies:
NameScopesforTypes63
3.7MetadataExtensibility65
3.8Globals,Imports,andExports67
3.9ScopedStatics68
4CommonLanguageSpecification70
4.1MarkingItemsasCLS-Compliant70
4.2Identifiers71
4.3Overloading71
4.4OperatorOverloading73
4.4.1UnaryOperators73
4.4.2BinaryOperators73
4.4.3ConversionOperators75
4.5NamingPatterns75
4.6CollectedCLSRules76
5TheVirtualExecutionSystem(VES)80
5.1MicrosoftIntermediateLanguage(MSIL)81
5.2LoadingManagedCode83
5.3ConversionofMSILintoNativeCode84
5.4VerificationofImplementationCode85
5.5ServicesBasedonStackFormat85
5.6SecurityServices87
5.7ProfilingandDebuggingServices88
5.8Delegates90
5.9Proxies,Contexts,andRemoting90
6Index93
OverviewoftheCommonLanguageRuntime
Thisdocumentservesasahigh-leveltechnicalintroductiontothearchitectureoftheCommonLanguageRuntime(CLR),partofthe.NETFramework.Whereappropriate,thisdocumentprovidespointerstomoredetailedinformationcontainedinotherdocuments.Atthecenteroftheruntimeisasingletypesystem,theCommonTypeSystem(CTS),whichissharedbycompilers,tools,andtheruntimeitself.Itisthemodelthatdefinestherulestheruntimefollowswhendeclaring,using,andmanagingtypes.TheCTSestablishesaframeworkthatenablescross-languageintegration,typesafety,andhighperformancecodeexecution.ThisdocumentdescribesthearchitectureofCLRbydescribingtheCTSanditsimplementationbytheruntime.
Thefollowingfourareasarecoveredinthisdocument:
TheCommonTypeSystem.TheCommonTypeSystem(CTS)providesarichtypesystemthatsupportsthetypesandoperationsfoundinmanyprogramminglanguages.TheCommonTypeSystemisintendedtosupportthecompleteimplementationofawiderangeofprogramminglanguages.
Metadata.TheCLRusesmetadatatodescribeandreferencethetypesdefinedbytheCommonTypeSystem.Metadatacanbestored(“persisted”)inawaythatisindependentofanyparticularprogramminglanguage.Thus,metadataprovidesacommoninterchangemechanismforusebetweentoolsthatmanipulateprograms(compilers,debuggers,etc.)aswellasbetweenthesetoolsandtheVirtualExecutionSystem.
TheCommonLanguageSpecification.WhilenotstrictlypartoftheCTS,theCommonLanguageSpecificationisanagreementbetweenlanguagedesignersandframework(classlibrary)designers.ItspecifiesasubsetoftheCTSTypeSystemandasetofusageconventions.LanguagesprovidetheirusersthegreatestabilitytoaccessframeworksbyimplementingatleastthosepartsoftheCTSthatarepartoftheCLS.Similarly,frameworkscanbemostwidelyusediftheirpubliclyexposedaspects(classes,interfaces,methods,fields,etc.)useonlytypesthatarepartoftheCLSandadheretotheCLSconventions.
TheVirtualExecutionSystem.TheVirtualExecutionSystem(VES)implementsandenforcestheCTSmodel.TheVESisresponsibleforloadingandrunningprogramswrittenfortheCLR.Itprovidestheservicesneededtoexecutemanagedcodeanddata,usingthemetadatatoconnectseparatelygeneratedmodulestogetheratruntime(latebinding).
Together,theseaspectsoftheCLRformaunifyingframeworkfordesigning,developing,deploying,andexecutingdistributedcomponentsandapplications.TheappropriatesubsetoftheCommonTypeSystemisavailablefromeachprogramminglanguagethattargetstheCLR.Language-basedtoolscommunicatewitheachotherandwiththeVirtualExecutionSystemusingmetadatatodefineandreferencethetypesusedtoconstructtheapplication.TheVirtualExecutionSystemusesthemetadatatocreateinstancesofthetypesasneededandtoprovidedatatypeinformationtootherpartsoftheinfrastructure(suchasremotingservices,assemblydownloading,security,etc.).
ProblemsAddressed
TheCommonTypeSystemaddressesanumberofissuesthathavecomplicatedthecreationanddeploymentofdistributedapplications:
Similarandbutsubtlyincompatibletypes-Dates,Times,Integers,SQLnullabletype,etc.
Limitedcodereuse-Cannotimportatypefromadifferentlanguageandtreatitthesameastypesdefineddirectlyinthelanguage.
Non-uniformobjectmodels–Differingwaysofdealingwithevents,dynamicbehaviors,persistence,properties,exceptions,etc.
TheCTSabstractsandsimplifiesthedetailsofthelanguage/toolthatmustbeknownbeforeaservicecanbebuilt.Byprovidingacommonframework,itallowstheruntimeandassociatedservicestoautomatemuchoftheworkthatisperformedmanuallytoday.Thecommonframeworkrepairsthefollowingweaknessesintoday’sinfrastructure:
Nocommonexecutionmodel-Nouniformwaytoinspectthestateofanexecutingprogram.Crucialforcodeaccesssecurity,enablesdeclarativeruntimeservices,andsimplifiestoolslikeprofilers.
Brittlebindingmechanisms–Allthethingsthatleadto“DLLhell”andthegeneralversioningproblemsthatarisefromsoftwareevolution.
Inshort,toolittleisknownaboutaprogramafteritiscompiled.TheCLRaddressesthisproblembyproviding:
aCommonType,
ameansofpersistinginformationabouttypesalongwiththecomponentsthatusethem(metadata),
aspecificationofthesubsetoftypesthathavebroadreachacrossprogramminglanguages,and
ameansofbuildinginstancesgiventypedescriptions(theVirtualExecutionSystem).
RelationshiptoTypeSafety
Typesafetyisusuallydiscussedintermsofwhatitdoes,e.g.guaranteeingencapsulationbetweendifferentobjects,orintermsofwhatitprevents,e.g.memorycorruptionbywritingwhereoneshouldn’t.However,fromthepointofviewoftheCommonTypeSystem,typesafetyisaboutguaranteeing:
Referencesarewhattheysaytheyare-Everyreferenceistypedandthethingreferenced,thedefinition,alsohasatype,andtheyarecompatibleinastrictsense.
Identitiesarewhotheysaytheyare-Thereisnowaytocorruptorspoofanobject,andbyimplicationauserorsecuritydomain.Theaccesstoanobjectisthroughaccessiblefunctionsandfields.Anobjectcanstillbepoorlydesigned.Thekeyisthatalocalanalysisoftheobjectandthethingsituses,asopposedtoaglobalanalysisofallusesofanobject,issufficienttounderstandthevulnerabilities
Onlyappropriateoperationscanbeinvoked–Thereferencetypedefinestheaccessiblefunctionsandfields.Thisincludeslimitingvisibilitybasedonwherethereferenceis,e.g.protectedfieldsonlyvisibleinsubclasses
TheCommonTypeSystempromotestypesafetye.g.everythingistyped.Typesafetycanbeoptionallyenforced.Thehardproblemisdeterminingifanimplementationconformstoatypesafedeclaration.Sincethedeclarationsarecarriedalongasmetadatawiththecompiledformoftheprogram,acompilerfromMicrosoftIntermediateLanguage(MSIL)tonativecode(seeTypeSafetyandVerification)cantype-checktheimplementations.Whencoupledwithcodesigning,theissueisthenwhentot