Eryk Sun <eryk...@gmail.com> added the comment:
> I didn't realize assemblyBinding was supported by the generic runtime > framework, the documentation https://docs.microsoft.com/en-us/dotnet/ > framework/deployment/how-the-runtime-locates-assemblies seems to > suggest it is a dotnet feature. Native private assemblies are supported in XP, but the probing element [1] of an assemblyBnding isn't available until Windows 7, which restricts this to Python 3.6+. Alternatively, we could implement our own $ORIGIN-like support for Windows. Embed relative paths as a resource in the PYD file. If found, Python would internally call AddDllDirectory for each directory, load the extension with the flag LOAD_LIBRARY_SEARCH_DEFAULT_DIRS, and then remove the directories via RemoveDllDirectory. This wouldn't solve the problem of DLL name and version conflicts, however. For that, the import tables would have to be modified in every DLL. I think there's an existing project that implements something like that for Unix. Even if we're able to load two versions of a DLL in a process, they may still conflict with each other over resources (e.g. a named pipe). DLLs have to be designed to support multiple instances per process. See Authoring a DLL for a Side-by-Side Assembly [2]. [1]: https://docs.microsoft.com/en-us/windows/desktop/SbsCs/application-configuration-files [2]: https://docs.microsoft.com/en-us/windows/desktop/SbsCs/authoring-a-dll-for-a-side-by-side-assembly ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue35688> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
