Support pythonnet for AppDomain #78
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Very nice, thank you! I'll fix the CI on master s.t. you can rebase on that. |
When using domain.Load for an assembly, the assembly resolution rules are awkward Even if the full path is given to the AssemblyName, when the domain tries to load the assembly, it does not use that context and tries to resolve the assembly using normal domain resolution rules, which would require an assembly resolver to be installed. However, the assembly resolver that is actually used at runtime is the one installed to the main appdomain. This prevents a library like Python.Runtime.dll (used by pythonnet) which is not installed to the application base directory to be loaded by clr_loader. To fix this issue, the assembly resolver of the main appdomain is lazily extending to include paths needed for libraries passed into GetFunction, and GetFunction internally uses AppDomain.DoCallBack() to marshal the function pointer inside the target app domain, using global domain data to access the function pointer and return it to the user of clr_loader.
e3b043b to
f58e574
Compare
filmor
reviewed
Jul 28, 2025
Comment on lines
+27
to
+33
| get | ||
| { | ||
| string codeBase = Assembly.GetExecutingAssembly().CodeBase; | ||
| UriBuilder uri = new UriBuilder(codeBase); | ||
| string path = Uri.UnescapeDataString(uri.Path); | ||
| return Path.GetDirectoryName(path); | ||
| } |
There was a problem hiding this comment.
Please add a comment here that this contraption is needed in case the DLL was shadow-copied (otherwise one could simply use .Location). I don't think this can happen with how we load it, but it doesn't hurt to pre-empt this issue.
filmor
reviewed
Jul 28, 2025
|
|
||
| _delegates[key] = result; | ||
| Domain.DoCallBack(new CrossAppDomainDelegate(DomainSetup.StoreFunctorFromDomainData)); | ||
| result = (IntPtr)Domain.GetData("_thisFunctor"); |
There was a problem hiding this comment.
- It might make sense to unset this after it is read and check the value here
- This is not at all thread-safe. The simplest approach is probably to lock here in C#.
filmor
reviewed
Jul 28, 2025
| var assemblyName = AssemblyName.GetAssemblyName(assemblyPath).Name; | ||
| var assembly = domain.Load(AssemblyName.GetAssemblyName(assemblyPath)); | ||
| var type = assembly.GetType(typeName, throwOnError: true); | ||
| var deleg = Delegate.CreateDelegate(typeof(EntryPoint), type, function); |
There was a problem hiding this comment.
You must ensure that this delegate stays alive, e.g. by attaching it to the AppDomain object via SetData.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Related to pythonnet/pythonnet#2053
Fixes #53
When using domain.Load for an assembly, the assembly resolution rules are awkward Even if the full path is given to the AssemblyName, when the domain tries to load the assembly, it does not use that context and tries to resolve the assembly using normal domain resolution rules, which would require an assembly resolver to be installed. However, the assembly resolver that is actually used at runtime is the one installed to the main appdomain.
This prevents a library like Python.Runtime.dll (used by pythonnet) which is not installed to the application base directory to be loaded by clr_loader.
It is possible for an assembly to run code in another appdomain (using DoCallBack), but only if that assembly is reachable from the BaseDirectory. ClrLoader was not reachable because the base directory was hardcoded to that which contained python.exe, and ClrLoader.dll is not found there. I fixed this by making the folder which contains ClrLoader.dll the BaseDirectory for app domains created by ClrLoader.
To fix this issue, the assembly resolver of the main appdomain is lazily extending to include paths needed for libraries passed into GetFunction, and GetFunction internally uses AppDomain.DoCallBack() to marshal the function pointer inside the target app domain, using global domain data to access the function pointer and return it to the user of clr_loader.
With these changes, the following block:
will print "Python"