Assembly is a collection of one or more files that make up a logical unit. The "file" here is usually a hosted module, but the assembly can also contain other files. Most of the assemblies contain only one file, but the assembly can and sometimes contain multiple files. All files that make up multiple file assemblies must be in the same directory. When using the C # compiler to generate a simple EXE file, this EXE file is not just a managed module, but it is also an assembly. Most compilers can generate non-assembled modules, which can also add additional files to the assembly created by themselves. The .NET Framework SDK also provides a tool called Al (Squiry Connector), which can join the file into an assembly.
Multi-file assemblies are commonly used to combine modules written in different languages, or combine managed modules to combine ordinary files containing JPEG or other resources. The multi-file assembly is also used to divide the application into a downloadable unit, which is useful for the code deployed on the Internet.
How does the CLR know those files belong to an assembly? In a file in the program set, a manifest is generated from a physical perspective, the list is just an increased metadata; when the compiler generates a hosted module, the hosting module happens to be an assembly, it will write the module Metadata is within the metadata. From a logical point of view, the list is a path diagram of the assembly content. Its most important element has the following number of the name of the program, a list of other files in the program, from the list of data types that exported in other files of the assembly, and map these data types to the information version of the files defined their files, The format is: the main version of the version number. Internal version number. Revision number
The list also includes additional information, such as the company name, description, secure license, and regional string. The latter defines the target country of the assembly (eg EN-US represents American English) and is usually used with the so-called "accessory assembly". Describe a multi-file assembly consisting of 3 hosting modules and a JPEG file. The main.exe file contains a list, and the list includes references to other files. From a perspective of a file system, these files are still a separate file. But for CLR, they are a logical entity.
If you miss out what action information is to complete, the compiler generates an assembly of weak names by default. "Weak Name" means that the program does not have encrypted signatures, and the CLR only uses the assembly using the name stored in the program collection list (excluding the extension assembly file name). But the assembly can have a strong name. Strong Name The assembly contains the publications of the public publisher's public, digital signature (have a list of the list of questions where the public is located)
Digital signature is generated by publisher private and confirmed by a public. Strong Name The assembly is indicated from the assembly name, a public key, version number, and regional string. Regardless of how small differences, it is enough to distinguish two different assemblies.
The SDK's Al utiler can be used to create a strong name assembly. Most language compilers, including C # and Visual Basic .NET compilers, you can also create a strong name assembly. Is it a deployment weak name assembly or a strong name assembly depends on you, you can determine it according to the target application of the assembly. If you want to deploy assemblies in global assembly cache GAC-placing a global repository for multiple applications, you must use a strong name assembly.
If you want to perform version check, you also need to use a strong name for the assembly. When the CLR loads a weak name, it does not print - when you replace the old version with a new version (maybe the new version is revised in the old version, and you want to use the application The application's application can automatically use the update assembly, which is very beneficial. However, when you carefully test the app for a version of the assembly, some people use a certain set of defects to replace it. The old version of the assembly is very bad. This is the "DLL Hell" that Windows developers often encounter. Strong name can solve this problem. When the CLR loads a strong name assembly, it will set the version number in the program. The application loaded version number is used to control (this information is recorded in the metadata of the module) If the version number does not match, the CLR will trigger an exception. The strict version check is also its own defect. If you decide to use the strong name, but later I found an error in the assembly. You corrected the error and deployed a corrected assembly. However, the application using this assembly does not load the new version of the assembly unless you reconstruct the application. And if you delete the old version, The application is not running at all. Solution is to modify the CLR binding policy. Administrators can point the CLR to the new version of the strong name assembly by editing the configuration file. Of course, if there is a problem with the new version, you have talked. Why don't you just grant others administrator privileges.
The operational assembly sounds complicated. Of course, this is the case, fortunately, if you do not need to create a shared program set or link to other assemblies (outside the FCL, it is a set of shared assemblies) Most of the problems about naming and binding do not need to be considered. What you do is to start the compiler, copy the assembly to the specified directory, and then run.
