为什么没有记录 GAC 文件夹结构？
Why does the GAC folders structure is not documented?
为什么没有记录 GAC 文件夹结构？
我正在阅读 CLR via C# 一书，书中指出：
The reason that CSC.exe doesn’t look in the GAC for referenced assemblies is that you’d have to
know the path to the assembly file and the structure of the GAC is undocumented.
我不明白为 GAC 文件夹结构创建规则和记录它们的障碍是什么。
更新
在评论中有人建议可能存在技术问题，不允许实施文件夹结构的规则。但我可以通过提供一个可能的规则示例来证明情况并非如此：
1 GAC 只能包含强命名程序集。
2 根据定义，强命名程序集是一个具有名称、版本号、文化和 public 密钥令牌（实际上是 public 密钥，但为了简单起见，我们可以使用令牌的程序集，因为public 密钥太长）。
1 2 -> 3 每个程序集都可以通过名称、版本、区域性和 public 密钥标记来唯一标识。
3 -> 4 如果我们使用以下文件夹结构规则，那么我们将满足提供所需文件夹结构规则的初始 objective：[名称]/[版本]/[文化]/[public密钥令牌]/[程序集本身]
我是不是漏掉了什么？
.NET初始标准文档只定义了GAC的功能，并没有限制其实现。因此，
- .NET Framework 2.x/3.x 有初始实现。
- .NET Framework 4.x 使用不同的实现。
- Mono 等其他实现使用它们自己的结构。
最重要的是，.NET Core 甚至没有 GAC。
因此，C# 编译器不能依赖 GAC 的参考搜索算法实现。
为什么没有记录 GAC 文件夹结构？
我正在阅读 CLR via C# 一书，书中指出：
The reason that CSC.exe doesn’t look in the GAC for referenced assemblies is that you’d have to know the path to the assembly file and the structure of the GAC is undocumented.
我不明白为 GAC 文件夹结构创建规则和记录它们的障碍是什么。
更新 在评论中有人建议可能存在技术问题，不允许实施文件夹结构的规则。但我可以通过提供一个可能的规则示例来证明情况并非如此：
1 GAC 只能包含强命名程序集。 2 根据定义，强命名程序集是一个具有名称、版本号、文化和 public 密钥令牌（实际上是 public 密钥，但为了简单起见，我们可以使用令牌的程序集，因为public 密钥太长）。 1 2 -> 3 每个程序集都可以通过名称、版本、区域性和 public 密钥标记来唯一标识。 3 -> 4 如果我们使用以下文件夹结构规则，那么我们将满足提供所需文件夹结构规则的初始 objective：[名称]/[版本]/[文化]/[public密钥令牌]/[程序集本身]
我是不是漏掉了什么？
.NET初始标准文档只定义了GAC的功能，并没有限制其实现。因此，
- .NET Framework 2.x/3.x 有初始实现。
- .NET Framework 4.x 使用不同的实现。
- Mono 等其他实现使用它们自己的结构。
最重要的是，.NET Core 甚至没有 GAC。
因此，C# 编译器不能依赖 GAC 的参考搜索算法实现。