Can you show exactly what CSArray is and how you create it? If I initialise CSArray = System.Array.CreateInstance(System.Byte, 1000) this works fine for me.

And yes, C# enums are integers.

I have the following:

print(type(CSArray))
>>><class 'System.Byte[]'>

Using your definition gives the same error on my computer.

On my side, for test purpose, I create CSArray using a static C# method:

public static byte[] Test_Image()
{
    Image image = Image.FromFile("C:\\users\\alex\\logo.png");
    ImageConverter converter = new ImageConverter();
    byte[] byteArray = (byte[]) converter.ConvertTo(image, typeof(byte[]));
    return byteArray;
}

What versions of Python, Python.NET and .NET are you using?

Sorry I forgot:
Python 3.5
Python.Net 2.1 cloned yesterday from here
Windows 8.1 .NET4.5

@aPere3 @filmor this problem is exactly the same as described here by @mahibra:

#170

the type int reported for GCHandleType.Pinned is 32-bit in c# because it is enum, but int in python 3 is pointing to int64.

so try explicitly passing GCHandleType(GCHandleType.Pinned) - not sure if it works though.

from System import Int32
handler = GCHandle.Alloc(CSArray, Int32(GCHandleType.Pinned))

Gives me the same error as before.... What a pity!

@aPere3 try this branch, although Travis CI and appveyor tests not done yet: #175

@aPere3 all tests have been passed, so please try this updated version!

@denfromufa , I cloned an build from the master branch since you merged it a few hours ago...
Anyway, no changes, still that same error....

@aPere3 this used to work before, because overloading did not really check for types, which was giving wrong results like Math.Abs(5.3)=5 due to wrong selection of overloaded method.

In your case what happens is that .NET enum GCHandleType.Pinned is converted to Python int before it is passed to GCHandle.Alloc() method, which is not what C# and IronPython do.

So the temporary fix would be one of the following:

• special case enums in overloading method selection to allow inter-operability with integer types.
• implement context manager with clr.ignore_overloading_types, where method overloading logic is ignored only within this context
• special case conversion logic to prevent conversion of c# enums to python integers in .ToPython() method
• if only one overloaded signature matches by number of arguments, then ignore types and try to return results with warning

But the bigger problem is that why .ToPython() has to be called on .NET types and deviate from IronPython?!

Let me know what you think @tonyroberts @filmor ?

@denfromufa was your last post dedicated to me or developers of pythonNet? Because I'm quite new to python and I didn't get the details of your temporary fix recipe.

Anyway, is a downgrading to another version of python likely to help me with this bug ?

@aPere3 I fixed in this branch and tested it on my machine:

#176

@aPere3 did my patch work for you? if yes, then can you close this issue?

@denfromufa Sorry for the late reply...
I cloned the last develop branch and still no changes, I have the same error...
But I found that when I compile your code with:

$ python setup.py bdist_wheel

an error occurs. I didn't notice it because the files are built anyway but I have:

C:\Users\alex\Downloads\pythonnet\packages\UnmanagedExports.1.2.6\tools\RGiesecke.DllExport.targets(42,5): err
or : Microsoft.Build.Utilities.ToolLocationHelper could not find ildasm.exe.

Is it important? Why are the files built anyway?
Still the import of clr and my first import work without particular issues...

@aPere3

As you can see from pull request #176 it has not been merged yet, so you need to
try my branch pointing at this pull request:

https://github.com/denfromufa/pythonnet/tree/patch-8

Not sure about ildasm.exe, which .net versions do you have installed?
Anyway you can also try to build from visual studio, just select proper
configuration and set python version symbol in Python.Runtime and clrmodule
projects.

On Friday, March 11, 2016, Alex, Péré <notifications@github.com
javascript:_e(%7B%7D,'cvml','notifications@github.com');> wrote:

@denfromufa https://github.com/denfromufa Sorry for the late reply...
I cloned the last develop branch and still no changes, I have the same
error...
But I found that when I compile your code with:

$ python setup.py bdist_wheel

an error occurs. I didn't notice it because the files are built anyway but
I have:

C:\Users\alex\Downloads\pythonnet\packages\UnmanagedExports.1.2.6\tools\RGiesecke.DllExport.targets(42,5): err
or : Microsoft.Build.Utilities.ToolLocationHelper could not find ildasm.exe.

Is it important? Why are the files built anyway?
Still the import of clr and my first import work without particular
issues...

—
Reply to this email directly or view it on GitHub
#174 (comment)
.

@denfromufa re your question about IronPython, PythonNet has nothing to do with IronPython - they are no way related. Any similarity is purely because they are both related to Python, not with each other. IronPython is a Python language implementation for the CLR, whereas PythonNet is a set of libraries built using the CPython API. Questions about why one has diverged from the other are irrelevant as neither is derived from the other.

@denfromufa Sorry for (very) late reply. I tried with your patch branch, and no error occurred on the line. This seems to have worked! Thank you very much!

Anyway my code still do not work, but it is not related to this bug anymore, haha!

@tonyroberts I thought ironpython compatibility is one of goals in pythonnet, because some people switch from ironpython due to obvious reasons, unless pythonnet breaks their existing ironpython code without migration path.

@aPere3 glad to know that this works, open another issue if your new issue is related to pythonnet.

Thank you I close!