In .Net framework v1.0/v1.1, when an assembly is installed to GAC, we will generate a file __AssemblyInfo__.ini in the assembly's directory. The file contains some information about the assembly.

An example of the file is below:

C:\WINDOWS\assembly\GAC\System\1.0.5000.0__b77a5c561934e089>more __AssemblyInfo__.ini
DisplayName=System, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089

Signature is the strong name hash of the assembly.
MVID is the MVID of the assembly (if you run ildasm on the assembly, you will see MVID at the bottom of the manifest of the assembly).
URL is the original location where the assembly is installed from.
DisplayName is, the assembly identity.

DisplayName is informational only. It is never used.

Signature and MVID are used for native image evaluation. During native image loading, we need to make sure that the IL assembly is still the same assembly when the native image is compiled. Part of the evaluation is doing strong name signature validation. Of course if we open the assembly, the perf will go to hell. So we make a optimization to write the strong name signature to the __AssemblyInfo__.ini file. Instead of opening the assembly, we will open a much smaller text file. Both signature and MVID are used in native image evaluation.

The URL field is not always there. It is only possible when the source file path is known. For assemblies installed with MSI, since there is no meaning source file path, the URL will not be there.

If you use the shell extension GAC viewer, the viewer will show the URL as the property of the assembly.

In managed code, the URL will also shows up as Assembly.GetName().Codebase.

There are a few problems with the __AssemblyInfo__.ini file.

1. It is ANSI only, so it does not work with Unicode assembly name.
2. It is written/read with WritePrivateProfileString/GetPrivateProfileString. Those APIs are deprecated. They are still in Windows API strictly for AppCompat reason. This by itself is fine. But we found a bug that using those APIs will cause application hang (see http://blogs.msdn.com/junfeng/archive/2004/02/06/68152.aspx, and http://blogs.msdn.com/junfeng/archive/2004/02/08/69537.aspx).
3. The source file URL shows up in Assembly.GetName().Codebase, which is a source of confusion, since some assemblies will have this codebase, while others won't have it (when they don't have the codebase, the codebase will be the file path to the GAC).

In .Net framework 2.0, the native image evaluation path is totally re-written. So there is no reason to have Signature and MVID in the __AssemblyInfo__.ini file. We also want to remove the inconsistency of Assembly.GetName().Codebase problem. And the DisplayName is informational only. That leaves no reason for the __AssemblyInfo__.ini file to exist.

Thus in .Net framework 2.0, __AssemblyInfo__.ini is gone for assemblies in GAC, if the assemblies are compiled with CLR 2.0. For assemblies compiled with CLR v1.0/v1.1, we still generate the __AssemblyInfo__.ini file so that native image for .Net framework v1.0/v1.1 still works, but URL and DisplayName are removed from the file.

Comments (3)

  1. Jason Haley says:

    Interesting finds so far this week

  2. Riyaz says:

    Nice article to peek inside framework.

    Can we have more details on the native image evaluation path for .Net v2.0

Skip to main content