A NGWS runtime assembly is the functional unit of sharing and reuse in the NGWS runtime. It is a collection of types and resources that are built to work together and form a logical unit of functionality, a “logical” dll. An assembly forms the fundamental unit of deployment, version control, reuse, activation scooping, and security permissions. Contained in an assembly is the assembly manifest, which contains all the metadata needed to specify the version requirements, security identity, and all information needed to define the scope of the assembly and resolve references to resources and classes.
It is important to understand what an assembly is not. An assembly is not a unit of application deployment. It is a unit of class deployment, much like a dll. An application is built from assemblies, and these assemblies can be packaged for deployment in several ways.
Currently there are two versioning problems that occur with Win32 applications. First, current applications cannot express versioning rules between pieces of an application and have these rules honored and enforced by the operating system. The current approach relies on “common-sense” coding practices that state that interface definitions are static once published and that a single piece of code must maintain backward compatibility with previous versions. Furthermore, code is typically designed so that only a single version of it can be present and executing on a machine at any given time.
The second versioning problem is the fact that there is no way to maintain consistency between the sets of components that were built together and the set that will be present at run time. These two versioning problems combine to create DLL conflicts, where installing one application can inadvertently break an existing application because a certain software component or DLL was installed that was not fully backward compatible with a previous version. Once this situation occurs, there is no support in the system for diagnosing and fixing the problem.
Windows 2000 introduced some progress toward fixing DLL conflicts. First, Windows 2000 enables you to create client applications where the dependent DLLs are located in the same directory as the application’s EXE. Windows 2000 first check for the component in the directory where the EXE is located before checking the fully qualified path or doing the normal path search. This allows components to be independent of components installed and used by other applications.
The second feature in Windows 2000 designed to partially fix DLL conflicts is System File Protection. The operating system locks the files in the System32 directory that are shipped with the OS so they cannot be inadvertently replaced when applications are installed.
The NGWS runtime continues this evolution toward a complete solution to DLL conflicts. To solve the remaining problems that lead to DLL conflicts, the NGWS runtime:
The NGWS runtime solves versioning problems by using assemblies. An assembly is the fundamental unit of sharing and reuse in the NGWS runtime. For more information on versioning, see Assemblies and Versioning.
An assembly is not a unit of packaging in and of itself. An assembly can be made up of PE files and resource files, and these files can be deployed in a number of ways. An assembly can contain one file or multiple files. How you choose to create assemblies will dictate much of your deployment story.
You can deploy assemblies using the Windows Installer, Internet Explorer, or by copying the assembly. Assemblies can be deployed in as .cab files or as .msi files. You can also simply download or xcopy an assembly to deploy. For more information on deployment, see Packaging Components for Distribution