This is preliminary documentation and subject to change.
To comment on this topic, please send us email at ngwssdk@microsoft.com. Thanks!
The Minimum You Need to Know About Assemblies
As a developer, you can think of an assembly as a “logical” dll. Here is a list of things you should remember about an assembly:
- It contains code that the runtime will execute. IL code in a PE file will not be executed if it does not have an assembly manifest associated with it. Note too that each assembly can have only one entry point (i.e. DllMain, WinMain, or Main).
- It forms a security boundary – An assembly is the unit at which permissions are requested and granted. For more information on security boundaries as they apply to assemblies, see Assemblies and Security Considerations.
- It forms a type boundary – Every type has as part of its identity the assembly in which it resides. Therefore, a type MyType loaded in the scope of one assembly is not the same as type MyType loaded in the scope of another assembly. For more information on assemblies and type boundaries, see Assemblies and Type Identity.
- It forms a reference scope boundary – The assembly’s manifest contains the rules for resolving types and resources. It specifies what types and resources are exposed outside the assembly. The manifest also enumerates other assemblies on which it is dependent. For more information on scoping, see Scoping Application Behavior in an Application Domain.
- It forms a convenient unit for “private” assemblies, such as utilities, debug code, and exceptions. For more information on how to best group code modules into assemblies, see Considerations when Creating Assemblies and Packaging NGWS Applications.
- It forms a version boundary – The assembly is the smallest versionable unit in the NGWS runtime; all types and resources in the same assembly are versioned as a unit. The assembly’s manifest describes the version dependencies you specify for any dependent assemblies. For more information on versioning, see Assemblies and Versioning.
- It determines the unit of sharing if you create a shared assembly. For more information on sharing assemblies, see Shared Assemblies.
- It forms a deployment unit – An application when launched only requires those assemblies it initially calls. All assemblies of an application do not have to be present at run time; other assemblies, such as localization resources, can be retrieved on demand. This allows downloaded applications to be kept simple and thin. For more information on deploying assemblies, see Packaging Components for Distribution.
- It is the unit at which side-by-side execution is supported. For more information on running multiple versions of the same assembly, see Side by Side Execution.
Some of the information in an assembly manifest can be overridden by an application or machine-wide configuration file. For more information on configuration files, see Creating Configuration Files.