Benefits of Assembly in .Net Framework

Assemblies are designed to simplify application deployment and to solve versioning problems that can occur with component-based applications. End users and developers are familiar with versioning and deployment issues that arise from today's component-based systems. Some end users have experienced the frustration of installing a new application on their computer, only to find that an existing application has suddenly stopped working. Many developers have spent countless hours trying to keep all necessary registry entries consistent in order to activate a COM class. Many deployment problems have been solved by the use of assemblies in the .NET Framework. Because they are self-describing components that have no dependencies on registry entries, assemblies enable zero-impact application installation. They also simplify uninstalling and replicating applications. Versioning Problems Currently two versioning problems occur with Win32 applications: Versioning rules cannot be expressed between pieces of an application and enforced by the operating system. The current approach relies on backward compatibility, which is often difficult to guarantee. Interface definitions must be static, once published, and 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 computer at any given time. There is no way to maintain consistency between sets of components that are built together and the set that is 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. An End to DLL Conflicts Windows 2000 began to fully address these problems. It provides two features that partially fix DLL conflicts: Windows 2000 enables you to create client applications where the dependent .dll files are located in the same directory as the application's .exe file. Windows 2000 can be configured to check for a component in the directory where the .exe file is located before checking the fully qualified path or searching the normal path. This enables components to be independent of components installed and used by other applications. Windows 2000 locks files that are shipped with the operating system in the System32 directory so they cannot be inadvertently replaced when applications are installed. The common language runtime uses assemblies to continue this evolution toward a complete solution to DLL conflicts. The Assembly Solution To solve versioning problems, as well as the remaining problems that lead to DLL conflicts, the runtime uses assemblies to do the following: Enable developers to specify version rules between different software components. Provide the infrastructure to enforce versioning rules. Provide the infrastructure to allow multiple versions of a component to be run simultaneously (called side-by-side execution).