C # application Set

an assembly is a logical unit that contains compiled, code that targets the. NET Framework. This sentence can be understood as follows:

first, the assembly is the logical unit of code and is a logical concept. It is not exactly equivalent to a compiled DLL physical file,

In general, however, we think that a static private assembly is consistent with a compiled DLL file or EXE file.

Second, it is compiled. It is not a project name or namespace, and it is not the source code.

Finally, it is for the. NET Framework. This means that although it is compiled, it still needs to be run on the. NET framework.

An assembly can be a DLL or EXE that includes metadata, or it can consist of multiple files, such as resource files, metadata, DLLs, and EXE.

Note: Win32 DLLs (dynamic-link libraries) and DLLs (assembly files) in dotnet are all DLLs, but the data organization within them is not the same,

So don't confuse the two.

Classification of assemblies:

Static assemblies: Static assemblies include intermediate language metadata (MSIL, something similar to Java bytecode), and the Assembly's resources (bitmaps, JPEG files, resource files, and so on).

Static assemblies are stored in the hard disk file.

Dynamic assemblies: Dynamic assemblies run directly from memory and are not stored on disk until they are executed, such as when a site program in ASP. NET 2.0 is running with a dynamic assembly.

Private assemblies: Private assemblies are typically shipped with some software and only provide a dedicated class library for the software that contains code that can be used only for that application.

A generic private assembly is placed in the same directory as the application and is copied to the target machine at deployment time.

Shared assemblies: Shared assemblies are common libraries that other applications can use, typically installed in the system GAC. Because other software can access the shared assembly,

Therefore, all shared assemblies must have a strong name (signed by the publisher). The local application directory can be used to store specialized assemblies.

Therefore, there is generally no version conflict issue with a private assembly. None of the other applications will overwrite the private assembly. Of course, you can still use the version number of the private assembly,

This helps to modify and manage the code, but it is not. NET is required. This dedicated assembly is a favorite of most programmers, and it's a good way to avoid DLL hell problems.

However, this specialized assembly can only be deployed in the directory where the application resides, and cannot be placed in the System32 directory as a previous WIN32 DLL for multiple applications to share.

But sometimes designers still have the need to share assemblies (deploy the assembly to the GAC catalog), which in turn brings us to the point where we see Dell Hell again

and slowly approaching us, In fact, Dell HELL is not possible at all in DLL shared assemblies. Because sharing an assembly is not simply copying a private assembly to the GAC

Directory, developers can only use the relevant tools to place strong-named assemblies (Strong-name Assembly) in the same directory as the GAC.

An assembly with the same name but different version numbers can be allowed in the GAC, and when different versions of strong-named assemblies are installed in the GAC,

Different applications invoke different assemblies based on the version number information, so that there is no problem with DLL assembly conflicts.



C # application Set