NGWS SDK Documentation  

This is preliminary documentation and subject to change.
To comment on this topic, please send us email at ngwssdk@microsoft.com. Thanks!

Assemblies: Name Scopes for Types

An assembly is a collection of resources that are built to work together to deliver a cohesive set of functionality. An assembly carries all of the rules necessary to ensure that cohesion. It is the unit of access to resources in the NGWS runtime.

From the outside looking in, an assembly is a collection of exported resources, including types. Resources are exported by name. From the inside, an assembly is a collection of public (exported) and private (internal to the assembly) resources. It is the assembly that determines what resources are to be exposed outside of the assembly and what resources are accessible only within the current assembly scope. It is the assembly that controls how a reference to a resource, public or private, is mapped onto the bits that implement the resource. For types in particular, the assembly may also supply runtime configuration information. An NGWS runtime image or file can be thought of as a packaging of type declarations and implementations, where the packaging decisions could change under the covers without affecting clients of the assembly.

The identity of a type in the runtime is its assembly scope + its declared name. The same declared type deployed in two different assemblies is considered two different runtime types.

Assembly Dependencies: An assembly may depend on other assemblies. This happens when implementations in the scope of one assembly reference resources that are scoped in / owned by another assembly.

From a deployment perspective, an assembly may be deployed by itself, with the assumption that any other referenced assemblies will be available in the deployed environment. Or, it may be deployed with its dependent assemblies.

Manifests: Every assembly has a manifest that declares what modules 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 module and assembly versions) were used to successfully build the manifest, regardless of whether the assembly chooses to require binding to these specific versions at runtime. When implicit, the manifest is derived from the modules that are declared to make up the assembly, effectively binding to specific implementation versions.

Applications: Assemblies introduce isolation semantics for applications. An application is simply an assembly that has an external entry point that triggers (or causes a hosting environment such as IE to trigger) the creation of a new runtime Application Domain. This entry point is effectively the root of a tree of request invocations and resolutions. Some applications are a single, self-contained assembly. Others require the availability of other assemblies to provide needed resources. In either case, when a request is resolved to a module to load, the module is loaded into the same Application Domain from which the request originated. It is possible to monitor or stop an application via the Application Domain.

References: A reference to a type always qualifies a type name with the assembly scope within which the reference is to be resolved – that is, an assembly establishes the name scope of available resources. However, rather than establishing relationships between individual modules and referenced assemblies, every reference is resolved through the current assembly. This allows each assembly to have absolute control over how references are resolved. This is depicted by the following diagram: