VB代码动态编译：CodeDom与Roslyn系统引用路径差异问询

这个问题问到点子上了！我来给你捋清楚CodeDom是怎么悄悄搞定系统程序集路径的，还有为啥Roslyn就得你手动给全路径。

CodeDom的自动查找逻辑 #

CodeDom（比如你用的VB版本VBCodeProvider）是.NET Framework时代的产物，它深度依赖CLR的内置程序集解析机制，根本不用你操心路径的事：

• 首先会去当前CLR运行时的安装目录找，比如C:\Windows\Microsoft.NET\Framework\v4.0.30319这种固定路径
• 要是目录里没找到，就去**全局程序集缓存（GAC）**里匹配程序集名称——GAC本身就是专门存系统和共享程序集的地方，CLR有一套成熟的逻辑能根据程序集名称找到对应的物理文件
• 最后还会扫一遍当前应用的运行目录

简单说，当你写param.ReferencedAssemblies.Add("System.dll")的时候，CodeDom背后会调用类似Assembly.Load("System")的逻辑，CLR自动帮你把程序集名称转换成完整的文件路径，你完全感知不到这个过程。

为啥Roslyn必须要完整路径？ #

Roslyn是微软新一代的编译器工具链，设计理念和CodeDom完全不同：它是跨运行时的（支持.NET Framework、.NET Core、.NET 5+），而不同运行时的程序集布局天差地别——.NET Core之后就没有统一的GAC了，每个应用的依赖都是独立的，也没有固定的CLR安装目录。

为了兼容所有场景，Roslyn选择了显式控制的设计：它默认不会帮你自动搜索程序集路径，必须由你明确指定。这样一来，不管你是在哪个运行时环境下编译，都能精准控制要引用的程序集。

当然，如果你想让Roslyn也能自动找路径，也有办法：

• 对于.NET Framework，可以先通过Assembly.Load("System.dll").Location获取到完整路径，再传给MetadataReference.CreateFromFile()
• 对于.NET Core/.NET 5+，可以用Microsoft.Extensions.DependencyModel这个库来扫描当前应用的依赖程序集，自动获取路径

总结一下 #

CodeDom是沾了.NET Framework老机制的光，靠CLR的自动解析就能省掉路径；而Roslyn是为了适配现代跨运行时场景，设计得更严谨，必须你手动指定路径（或者通过工具类自动获取）。

内容的提问来源于stack exchange，提问作者Anoop