c++/cli method signature limitation

[dotnetchic]

Anybody know what the "internal limitation" of a method signature is
for c++/cli?

I've got a mixed assembly that throws an exception for one particular
function (very large if-else control). It throws a
System.Runtime.InteropServices.MarshalDirectiveExc eption with the
additional information "Internal limitation: method signature is too
complex or too large." When I compile the function as native, no
problem.

TIA,
Sharon

[Marcus Heege]

Hi Sharon
"dotnetchic" <do********@gmail.com> wrote in message
news:11**********************@q12g2000cwa.googlegr oups.com...

Anybody know what the "internal limitation" of a method signature is
for c++/cli?

I've got a mixed assembly that throws an exception for one particular
function (very large if-else control). It throws a
System.Runtime.InteropServices.MarshalDirectiveExc eption with the
additional information "Internal limitation: method signature is too
complex or too large." When I compile the function as native, no
problem.

TIA,
Sharon

This looks like a very interesting bug.
Can you please tell me what the CallStack of the MarshalDirectiveException
gives you?
Can you please tell me the signature of the critical function?

Marcus

[dotnetchic]

Well, let's see...

method signature (open file method) looks like this:
int foo(FILE *file1, FILE *file2, CUSTOMSTRUCT1 custom1, CUSTOMSTRUCT2
custom2, unsigned short parm5, unsigned short parm6, unsigned short
parm7, int parm8, unsigned short &parm9)
{
// function body = 1800+ lines, roughly 1550 lines of executable code
}

and the call stack at the point the exception is thrown is:
KERNEL32.DLL!7c81eb33()
[Frames below may be incorrect and/or missing, no symbols loaded for
KERNEL32.DLL]
KERNEL32.DLL!7c81eb33()
MyApp.exe!foo(...)
[External Code]
MyApp.exe!OnFileOpen() Line 949 + 0x35 bytes
[External Code]
(... then several calls into mfc80d.dll for messaging ...)

[Sean M. DonCarlos]

"dotnetchic" wrote:

method signature (open file method) looks like this:
int foo(FILE *file1, FILE *file2, CUSTOMSTRUCT1 custom1, CUSTOMSTRUCT2
custom2, unsigned short parm5, unsigned short parm6, unsigned short
parm7, int parm8, unsigned short &parm9)
{
// function body = 1800+ lines, roughly 1550 lines of executable code
}

I would try passing pointers to the two custom structures instead of the
entire structures themselves to the function. While the marshaller should be
able to handle a 9-parameter function, it may be choking on the structures.

Sean

[dotnetchic]

Well, this is a bit of legacy code that I'm not sure I want to modify.
I'll probably leave it compiled as unmanaged for now, and eventually
get around to re-writing it.

But I will test your hypothesis, once I figure out how...can we pass a
pointer in c++/cli? Don't we have to use IntPtr or something? ??

Thanks,
Sharon

[dotnetchic]

That was easier than I thought. Pass pointers to the structs instead,
compile as managed, and it appears to run smoothly. Well, the program
crashes :( but it's beyond the scope of this thread.

cheers!

[Marcus Heege]

"dotnetchic" <do********@gmail.com> wrote in message
news:11*********************@i39g2000cwa.googlegro ups.com...

Well, this is a bit of legacy code that I'm not sure I want to modify.
I'll probably leave it compiled as unmanaged for now, and eventually
get around to re-writing it.
Just add a new file to the project that is compiled without /clr. Place the
function into this file. If necessay, you can also write a wrapper function
in this file, that passes all the arguments via one struct pointer or so.

In the file where you want to call the wapper function, just declare it is
usual.
But I will test your hypothesis, once I figure out how...can we pass a
pointer in c++/cli? Don't we have to use IntPtr or something? ??

No, you can work with pointers in C++/CLI, no need to use IntPtr.

Marcus

[dotnetchic]

> Just add a new file to the project that is compiled without /clr. Place the

function into this file. If necessay, you can also write a wrapper function
in this file, that passes all the arguments via one struct pointer or so.

I've been using the #pragma unmanaged/managed keywords to delimit
native functions, but it looks like a lot of my native code will end up
residing in the same file, so I can in some cases compile the entire
file without /clr.

Is this a bad practice? Should I avoid using the #pragma unmanaged
keyword? I'd really hate to write wrappers for all these native
functions. I'm porting a very large codebase.

Sharon

[Marcus Heege]

Hi Sharon,

"dotnetchic" <do********@gmail.com> wrote in message
news:11**********************@j73g2000cwa.googlegr oups.com...

Just add a new file to the project that is compiled without /clr. Place
the
function into this file. If necessay, you can also write a wrapper
function
in this file, that passes all the arguments via one struct pointer or so.
I've been using the #pragma unmanaged/managed keywords to delimit
native functions, but it looks like a lot of my native code will end up
residing in the same file, so I can in some cases compile the entire
file without /clr.

Is this a bad practice? Should I avoid using the #pragma unmanaged
keyword?

It is a bad practice to use #pragma unmanaged. Native functions should end
up in cpp files compiled to native code and managed functions should end up
in cpp files compiled with /clr.
I'd really hate to write wrappers for all these native functions. I'm
porting a very large codebase.

There is no need to write wrappers.The only reason why you had to write one
wrapper frunction was because you reached the limits of P/Invoke

[dotnetchic]

Duly noted. I suppose it does make more sense to have all the native
code residing in separate units. Many thanks, Marcus.

There is no need to write wrappers.The only reason why you had to write one
wrapper frunction was because you reached the limits of P/Invoke

Speaking of, is this limitation of P/Invoke documented anywhere? I've
been reading up on the usage of P/Invoke for a couple of weeks now, and
only in debugging did I discover this problem.

Sharon

[Marcus Heege]

"dotnetchic" <do********@gmail.com> wrote in message
news:11**********************@u72g2000cwu.googlegr oups.com...

Duly noted. I suppose it does make more sense to have all the native
code residing in separate units. Many thanks, Marcus.

There is no need to write wrappers.The only reason why you had to write
one
wrapper frunction was because you reached the limits of P/Invoke

Speaking of, is this limitation of P/Invoke documented anywhere? I've
been reading up on the usage of P/Invoke for a couple of weeks now, and
only in debugging did I discover this problem.

After you have made me aware of this problem, it will likely be in the book
I am currently witing. Thanks for the info :-)