AppDomainSetup.PrivateBinPath vs Environment.SetEnvironmentVariable

Question

我只需要我的应用知道在哪里寻找一些非托管的dll。我正在使用SetEnvironmentVariable并且效果很好。我知道还有一个属性AppDomainSetup.PrivateBinPath。它们之间有什么实际区别？

目前我正在执行以下操作：

var dllDirectory = @"C:\some\path";
Environment.SetEnvironmentVariable("PATH", Environment.GetEnvironmentVariable("PATH") + ";" + dllDirectory)

编辑： 我注意到Environment.SetEnvironmentVariable实际上并没有改变PATH变量，它接缝只会影响调用它的应用程序。

Answer 1

PrivateBinPath是CLR查找程序集的地方。

不哪个Windows会查找DLL，它对CLR配置一无所知。它使用常规的Windows搜索规则，通常表现如下：

1. 与存储EXE的目录相同的目录
2. 在Set / AddDllDirectory（）调用中指定的目录（如果有）
3. Windows系统目录（通常为c：\ windows \ system32）
4. Windows安装目录（通常为c：\ windows）
5. 当前默认目录（Environment.CurrentDirectory）
6. PATH环境变量中列出的目录。

对此有几个怪癖，它已被修补了很多。特别是子弹5是安全问题，并且可能被滥用以使程序加载恶意DLL。但足够接近你在野外所期望的东西。

在代码中设置PATH环境变量是可以的，但它并不完全可靠。它位于列表的 bottom 当然是一个问题，您可能会加载错误的DLL。并且PATH环境变量本身很麻烦，它很容易在计算机上损坏，并且可能已经太长而不允许您向其附加另一个目录。很难诊断问题。

您应始终始终，始终青睐bullet 1.只需将本机DLL复制到与EXE相同的目录中。始终工作，始终可靠，绝不惊讶，无需特殊配置。没有人关心这个目录有点满，不是你的客户，不是文件系统，不是操作系统。

如果你必须总是喜欢子弹2，请按SetDllDirectory()。它不完全可靠，如果您加载的DLL之一也在使用它，那么您将遇到问题。但你很快发现了。使用AddDllDiretory（）会更好，但在足够的Windows版本上仍然不支持它。

Answer 2

AppDomainSetup.PrivateBinPath是应用程序基目录下的一组文件夹，在appdomain设置期间探测私有程序集。 Env var PATH不一定指向应用程序基目录下的文件夹。 PATH将包含任意文件夹路径。