AppDomainSetup.PrivateBinPath vs Environment.SetEnvironmentV

本文关键字：SetEnvironmentV Environment vs PrivateBinPath AppDomainSetup | 更新日期: 2023-09-27 17:51:15

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

目前我的做法如下:

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

编辑:我注意到了环境。SetEnvironmentVariable实际上并没有改变PATH变量，它似乎只影响调用它的应用。

AppDomainSetup.PrivateBinPath vs Environment.SetEnvironmentV

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环境变量是可以的，但它并不完全可靠。它在列表的底部当然是一个问题，你可能会得到错误的DLL加载。而且PATH环境变量本身很麻烦，它在机器上很容易被破坏，而且可能已经太长，无法向其附加另一个目录。很难诊断问题

你应该总是，总是， 总是喜欢子弹头1。只需将本机dll复制到与EXE相同的目录中。总是工作，总是可靠的，从来没有一个惊喜，不需要特别的配置。没有人会在意这个目录是否已经满了，你的客户、文件系统和操作系统都不会在意。

如果必须始终支持项目2，请调用SetDllDirectory()。它不是完全可靠的，如果您加载的某个dll也在使用它，您就会遇到麻烦。但你很快就会发现。使用adddlldirectory()更好，但它不支持足够多的Windows版本。

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

相关文章：