Because each NGWS runtime image carries the metadata for declarations, implementations, and references specific to that image, the image-specific metadata is referred to as component metadata, and the resulting component is said to be self-describing. To draw an analogy, this information integrates and extends what a combination of typelibs, IDL files, DLLRegisterServer, and a myriad of custom .xxx files express in Unmanaged COM, in disparate formats and as side notes to the actual executable file. In fact, the presence of metadata in the image is part of what it means to be an NGWS component.
Collections of NGWS components and other files are packaged together for deployment into assemblies, discussed in more detail in a later section. More than just a deployment-time concept, an assembly is a logical unit of functionality that serves as the primary unit of reuse in NGWS. Effectively, assemblies establish a name scope for types.
This means that types declared and implemented in individual components are exported for use by other implementations via the assembly in which the component participates. All references to a type are scoped by the identity of the assembly in whose context the type is being used. NGWS provides services to locate a referenced assembly and “ask” that assembly to resolve the type reference. It is this mechanism that provides an isolation scope for applications: the assembly alone controls what implementation bits participate in the assembly, and the runtime has infrastructure to honor these rules.
Every assembly has a manifest that declares what components make up (or are allowed to make up) the assembly, what types are exported, how type references are resolved, how assembly references are resolved, configuration rules, etc. An assembly may carry an explicit manifest or the manifest may be implicit. When explicit, the manifest includes information about exactly what implementations (specific dependent component and assembly versions) were used to successfully build the manifest, and, optionally, version binding rules to be enforced at runtime. When implicit, the manifest is derived from the components that are declared to make up the assembly, where the binding rules are, effectively, “these bits only.”
Just as NGWS components are self-describing via component metadata persisted into the NGWS runtime image, so are assemblies self-describing via their manifests: All of the resource declarations and resolution rules are expressed declaratively and persisted into a binary image that can be consumed by the NGWS runtime metadata engine. When a single file makes up a NGWS runtime assembly, there is no need to carry two separate NGWS runtime files, one to contain the component metadata and one to contain the assembly metadata. Rather, the component and assembly metadata may be combined into the metadata binary of the NGWS runtime loadable image.