.NET impact on software installation
What is .NET? .... How do I change the entire software installation? .NET changes many ways we have software installation. The most obvious, we have a new language C #. Also, the operating system also has subtle changes, and how it handles shared code.
About metadata first, you have to know what is Managed Code? All Microsoft Intermediate Language (MSIL) code is running in Managed Code. For example, .NET launched new language C # is completely running in Managed Code. Languages included in other Visual Studio .Net, such as Visual C , allowing Managed Code and None-Managed Code to use. So what is the characteristic of Managed Code? It is the biggest difference between None-Managed Code to include metadata. Metadata describes each element in the code, allows the .NET running library to manage it, and make the code to be self-described. The .NET runtime provides services such as memory management, cross-language integration, code security, and object lifecycle automation by using metadata. Simply put, Managed Code is a code that can be run in a "contract cooperation" manner with the .NET running library. Metadata can include Assemblies, loadable files, types, methods, and more. The most closely related to the production and installation is asMbly manifest. Assembly is a primary component of a program, including all features, version information, and is published as a whole. Each Assembly must include an Assembly Manifest and make Assembly can be described herein. Manifest includes:
If you want to share with separate programs, you have to include digital signatures if you want to share with separate programs. The file included in the description specifies the type and resource of Assembly and indicates which of the assembly output. Level all dependent Assembly. Indicate license permit required
Manifest also included data completed by self-registration (Self-registration). For example, all types of information stored in manifest, these manifest data are placed in .dll or .exe file. This allows us to know the mutual dependencies of Managed Code through manifest, without mishand any information. However, if it is a mix of Managed Code and None-Managed Code, it is not so easy to do. If there is no new installation technology, developers will face a big problem. One of the misunderstandings for self-installation codes is that software written using Managed Code does not need to be installed. Because some mandates have been completed by metadata, such as registration of COM components. Just copy all the files to a directory, you can run it directly. Unfortunately, this is not all the process of software installation. Software installation is not simple to copy files from position a to position B. The software installer should provide users with a friendly, reliable, and unified way to install the software to the user's machine. First, the installer needs to pass a unified familiar user interface to allow the user to select the installed option, then create a folder, shortcut, upgrade, network installation, and license management, etc. In the above example, you can't do all these things for users, not to say that licenses are managed. In addition, Managed Code and None-Managed Code mixed applications cannot be installed. Moreover, to install such a program is more troublesome than installation pure none-management code. We can't throw all the previous code at once, all transferred to Managed Code. Therefore, we have to consider this issue seriously. Isolated Applications and Side-by-Side Components In Windows XP and .Net platforms, Microsoft provides a mechanism to reduce DLL HELL. We know that applications generally rely on some shared resources, so-called sharing, that is, if there is already a resource installed on the system, the application no longer needs to install the resource, it can be used directly. So DLL Hell has happened this way, if an application requires a higher resource than existing shared resources on the system, so it replaces the old version with a new high version of resources. And there is such possible possibilities, the new version of resources cannot be compatible with the old version of resources. Only one version of the resource can only exist in the system, so the application that relies on the old version of the resource will crash!
In order to solve this problem, Microsoft provides two ways: isolated Applications and Side-by-by-by-scroll. Isolated Application is an Isolated Version of all components of the program with an Isolated version of the program, which is not affected by other installer when publishing. But this requires full rewriting code, the cost is too high. Side-by-side components are running in an environment that can coexist together in new and old version of the shared resource. Many shared resources in Windows XP are written in Side-by-Side. Developers can achieve the benefits of Side-by-Side by writing application manifest. Application Manifest describes the version information of the components dependent on the program, so the operating system can load the correct shared resource based on this information. For example, the application is developed on the COMCTL32 V5 and Indescate in the Application Manifest, which depends on the COMCTL32 V5 version. Now, even if there is a COMCTL32 having another version on the system, the operating system will still load the V5 version of the V5 version. ... ..
The above text is taken from the documentation of InstallShield: << The Impact of .Net on Installations >>
For more information on software installation, please visit http://www.smiling.com.cn/search/groupinfo.ecgi?group_id=24326
