Microsoft enterprise database 4.1 Study Notes (9) deployment of enterprise database assembly

The Enterprise Library contains many assemblies. Except for the Unity module, the names of each assemblies in the Enterprise Library start with Microsoft. Practices. enterpriselibrary. In addition, other modules may depend on the Common Assembly of the Enterprise Library. Applications that use one module may also need the assembly of other modules. For example, if the caching module is used, the assembly of the data access module may be required.

To use the Enterprise Library in an application, you can deploy the Enterprise Library assembly in the following two ways.

• In the application directory, it is used as the private assembly of the application.
• In the shared directory of the file system or GAC.

I. Preparation and version

If the source code of the Enterprise Library is compiled, the default generated assembly has no signature. You cannot put them into GAC, and you cannot enjoy the benefits of signature assembly.

1.1 Use xcopy

You do not need to use the signature or deploy the assembly of the Enterprise Library to GAC. You can only put them in the application directory. For this simple deployment method, you can use xcopy to install the application assembly and the Enterprise Library assembly on the target computer. However, if multiple applications on the target computer are using the Enterprise Library, you will store a copy of the Enterprise Library assembly in the directory of each application.

1.2 use GAC (Global Assembly Cache)

In addition, you can sign the Enterprise Library Assembly to ensure that their names are globally unique and the version is available. If you do this, you can deploy multiple applications in the shared location when using the Enterprise Library. For example, you can deploy the Enterprise Library in GAC so that any computer application can use the Enterprise Library assembly.

You can deploy the Assembly to GAC using the following method:

• Drag to open the c: \ windows \ Assembly directory and drag the signed Assembly directly to the C: \ WINDOWS \ Assembly directory.
• Use gacutili. EXE to copy the file to the C: \ WINDOWS \ Assembly directory.
• Use the. NET Framework Configuration tool mscorcfg. MSC

Version 1.3

After the Assembly signature is completed, the version and name protection can be deployed in GAC for all applications.

It is not recommended that you directly use the namespace of the Enterprise Library in the application, because this will make it difficult to distinguish from the source code of the Enterprise Library. We recommend that you select a namespace related to your project.

Ii. Upgrade the Enterprise Library assembly

If the Enterprise Library provides a new version, you can install the new version of the Assembly. However, if the new version has compatibility issues with specific applications, you can install the new version in GAC and configure some applications to use the new version installed in GAC, other compatible applications continue to use the old Enterprise Library.

2.1 upgrade private assembly

If the Enterprise Library assembly is deployed as a private application assembly, you only need to replace the old version DLL with the new DLL.

Note: Your application copies an old version of the Enterprise Library Assembly before the upgrade. In case of compatibility problems, you can replace it with the old version.

2.2 upgrade shared assembly

The simplest way to upgrade a shared assembly is to replace the old DLL in GAC with the new DLL. By default, CLR automatically loads the same major version and minor version, but the internal version and revision are the latest Assembly and used as applications. Therefore, if the major version and minor version do not change, adding the latest Assembly to GAC will be automatically used by all applications.

If the primary and secondary versions are added, or the new version has compatibility issues with existing applications, you can modify the default version policy. A configuration file is used under each application to specify the version of the used assembly. In this example, you can specify an assembly without compatibility issues to use the new Enterprise Library assembly.

 

　　Knowledge Point: Major version, minor version, internal version, and revision version

. NET Framework-style version name format:Major version number. Minor version number. Build version number. Corrected version number
 Comparison: major_version_number.minor_version_number.build_number.revision_number

. NET Framework-style version name format

   The version number consists of two to four parts: the main version number, the minor version number, the internal version number, and the revision number. The main version number and minor version number are required. The internal version number and revision number are optional. However, if the revision number is defined, the internal version number is required. All defined parts must be integers greater than or equal to 0.
  These parts should be used in accordance with the following conventions:
 Major: an assembly with the same name but different major version numbers cannot be exchanged. For example, this applies to a large number of product rewriting, which makes backward compatibility impossible.
  Minor: if the names of the two sets are the same as those of the primary version, but the minor version number is different, this indicates a significant enhancement, but takes care of backward compatibility. For example, this applies to the product's revised version or a new version that is fully backward compatible.
  Build: different internal version numbers indicate re-Compilation of the same source. This is suitable for changing the processor, platform, or compiler.
  Revision: The names, major version numbers, and minor version numbers are the same, but the different revision numbers of the Assembly should be completely interchangeable. This applies to fixing security vulnerabilities in previously released assemblies.
 Only later versions with different internal version numbers or revision numbers are considered as patch updates of previous versions.

　　

Iii. partially trusted environment

Applications that use versions earlier than Enterprise Library 3.0 require sufficient permissions so that the Assembly can access some resources with full trust. The latest Enterprise Library, including 4.1. You can use the Enterprise Library with partial trust.

 

Not complete ........................

Http://www.cnblogs.com/virusswb/archive/2010/04/18/1714747.html