AppDomainSetup.PrivateBinPath对Environment.SetEnvironmentVariable

Question

我只需要我的应用程序知道在哪里寻找一些未管理的dll。我正在使用SetEnvironmentVariable，它工作得很好。我知道还有一个属性AppDomainSetup.PrivateBinPath。他们之间的实际区别是什么？

目前，我正在做以下工作：

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

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

Answer 1

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

这不是Windows查找DLL的地方，它对CLR配置一无所知。它使用常规Windows搜索规则，通常如下所示：

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

这方面的一些怪癖，它已经被修补了很多。特别是，项目5是一个安全问题，可以被滥用，以获得一个程序来加载一个流氓DLL。但足够接近你在野外所能期待的。

在代码中设置PATH环境变量是可以的，它并不完全可靠。它在列表的底部当然是一个问题，您可能会得到错误的DLL加载。而且PATH环境变量本身很麻烦，它很容易在机器上损坏，并且可能已经太长了，无法将另一个目录附加到其中。很难诊断问题。

您应该始终，始终，总是喜欢项目1。只需将本机DLL复制到与EXE相同的目录。总是工作，始终可靠，从来没有惊喜，没有特殊的配置需要。没有人关心这个目录有点满，不关心你的客户，不关心文件系统，不关心操作系统。

如果您必须始终支持项目2，那么请调用SetDllDirectory()。它不是完全可靠的，如果您加载的DLL之一也在使用它，您将遇到麻烦。但你很快就会发现。使用AddDllDiretory()更好，但在尚未依赖的足够多的Windows版本上不支持它。

Answer 2

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