Shared Assemblies GAC

Original title:

Original address: https://www.cnblogs.com/1996V/p/9037603.html

Shared Assemblies GAC

I've said so much about the details and rules of the CLR loading assemblies, in fact, similar to mscorlib.dll, System.dll such an FCL class library has been cited so frequently, it is already a necessary part of our. NET programming, every project will be referenced, in order to no longer every use of a copy, so there is a location on the computer dedicated to store these we will use the assembly, called the global assembly cache (Global Assembly CACHE,GAC), which is typically located in C:\Windows\Microsoft.NET\assembly and prior to 3.5 versions of C:\Windows\assembly.
Since it is the location of shared storage, it is unavoidable to encounter file name duplication, so in order to eliminate this kind of situation, the rule in the GAC can only have a strong name assembly, each time the CLR to load the strong-named assembly, the first through the identity to the GAC lookup, The GAC has its own set of directory structures, taking into account the complex case of assembly file name consistency but version culture. If we want to put our own assembly in the GAC, we must first sign it and then use the Gacutil.exe tool (which exists in the command-line tool https://docs.microsoft.com/zh-cn/dotnet/framework/ TOOLS/DEVELOPER-COMMAND-PROMPT-FOR-VS) to register in the GAC, it is worth mentioning that a strong-named assembly is installed in the GAC and is signed.

GAC Tools: Https://docs.microsoft.com/en-us/dotnet/framework/tools/gacutil-exe-gac-tool

Extended

The CLR loads the assembly on demand, without executing the code, without invoking the instruction, without a corresponding instruction, and the CLR does not manipulate it accordingly. When we execute environment.currentdirectory this code, the CLR first obtains the environment type information, knows its existence mscorlib.dll assembly through its own meta-data, so the CLR wants to load the assembly, and mscorlib.dll Because of its special status, it has been automatically loaded into memory by the type loader as early as the CLR initialization, so this line of code can read the method information of the type directly in memory.
In this chapter, although I describe the CLR's rules for searching assemblies, in fact, loading assembly read type information is far less simple, which involves finding the "application domain" concept and memory information that are unique to the. NET Framework.

Simple extension two questions, where is the mscorlib.dll loaded? What kind of a situation is in the memory heap?

Shared Assemblies GAC