GH48 - Support additional assembly loading #49
Conversation
|
References #48 |
|
Further explanation why this is necessary: This is what is breaking my Load(), not the fact that ResolveHandler mangles the assembly name... but I think what I've added is sane anyway ... I have a dependency on a mixed assembly that won't load; only LoadFrom() works as a fallback ... |
|
Hmm, I think the Travis CI failure error is a false positive. Btw, using fuslogvw.exe, the error is traceable to: What makes this especially insidious is it appears to |
|
Yes, the failure on Python 2.6 looks weird. @ton 8000 yroberts? I've pushed your branch onto this main repo to trigger an appveyor Windows build (there was a setting missing, I think in the future PRs should trigger this automatically, like it does with Travis). |
|
This also breaks the Windows build, again the Python 2.6 version: https://ci.appveyor.com/project/davidanthoff/pythonnet/build/2.0.0.25/job/2gc6r888yb5hvd9o I don't know the code well enough to figure out what is going on, though. |
|
It looks like the same problem that the change I made to load the assemblies differently was to try and fix. What was happening then was that the python runtime ended up getting loaded twice, once by clr.pyd and then again by any other assembly that referenced it. I'll take a look at this later today - I hadn't anticipated that loading the assembly that way would break some assemblies. Probably the thing to do will be to revert those changes I made and fix the original problem another way. |
|
This issue should now be fixed in #50. |
|
Fixed in #50 |
* add extensions support * Update CHANGELOG.md * handle python err
This solves my problem. Are there any obvious issues?