References #48

Further explanation why this is necessary:

Loading assemblies with Assembly.Load(byte[]) that contain unmanaged code in not supported

http://stackoverflow.com/questions/2945080/how-do-i-dynamically-load-raw-assemblies-that-contains-unmanaged-codebypassing

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:

ERR: Unrecoverable error occurred during pre-download check (hr = 0x80070002).

What makes this especially insidious is it appears to AddReference correctly, not reporting any errors, only to have no namespaces be visible in python... do we really need that catch {} ?

Yes, the failure on Python 2.6 looks weird. @tonyroberts?

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.
@adamklein could you take a look and confirm when you get a chance?

Fixed in #50