Mixed DLL Loading Problem??

[Mali Guven]

Hello,

I have a native DLL (written in C) which is supposed to call a managed DLL
(was written in C#, and an entry point was injected modifying the ildasm'd
code).

The exectuable calls the native DLL but the native DLL fails to load the
managed DLL. The paper that addresses the 'mixed DLL problem' below does not
offer any understandable workaround.
http://msdn.microsoft.com/library/de...ingProblem.asp

Does anybody who has came across this have a better understanding of the
possible resolutions of the mixed dll problem? I am very close to totally
abondaning working with mixed DLLs (wasting hundreds of manhours).

Regards,
Mali

[Willy Denoyette [MVP]]

"Mali Guven" <gu*****@hotmai l.com> wrote in message
news:du******** **@eeyore.INS.c wru.edu...
| Hello,
|
| I have a native DLL (written in C) which is supposed to call a managed DLL
| (was written in C#, and an entry point was injected modifying the ildasm'd
| code).
|
| The exectuable calls the native DLL but the native DLL fails to load the
| managed DLL. The paper that addresses the 'mixed DLL problem' below does
not
| offer any understandable workaround.
|
http://msdn.microsoft.com/library/de...ingProblem.asp
|
| Does anybody who has came across this have a better understanding of the
| possible resolutions of the mixed dll problem? I am very close to totally
| abondaning working with mixed DLLs (wasting hundreds of manhours).
|
| Regards,
| Mali
|
|

If I understand you correctly, you are calling a managed function from pure
unmanaged C code, right?
If that's the case, this has nothing to do with the mixed mode issue, "mixed
mode" means a single DLL that contains both managed(IL) and native code. You
are calling an "entry point" in a C# managed assembly, that you have created
by tweaking the IL and re-assembling, I guess you know that this is not a
supported scenario and extremely error prone. All you can do is use a
supported interop mechanism, that is, a real "mixed mode DLL", that calls
into C#, without resorting to a dirty hack, or use COM interop.

Willy.

[Mali Guven]

Thanks for the clarification. I will see what it would take to switch to the
real *mixed mode* (a DLL with both native and managed code). In my case, COM
interop is not an option due to speed concerns.

Mali
"Willy Denoyette [MVP]" <wi************ *@telenet.be> wrote in message
news:OX******** ******@TK2MSFTN GP14.phx.gbl...

"Mali Guven" <gu*****@hotmai l.com> wrote in message
news:du******** **@eeyore.INS.c wru.edu...
| Hello,
|
| I have a native DLL (written in C) which is supposed to call a managed DLL | (was written in C#, and an entry point was injected modifying the ildasm'd | code).
|
| The exectuable calls the native DLL but the native DLL fails to load the
| managed DLL. The paper that addresses the 'mixed DLL problem' below does
not
| offer any understandable workaround.
|
http://msdn.microsoft.com/library/de...ingProblem.asp |
| Does anybody who has came across this have a better understanding of the
| possible resolutions of the mixed dll problem? I am very close to totally | abondaning working with mixed DLLs (wasting hundreds of manhours).
|
| Regards,
| Mali
|
|

If I understand you correctly, you are calling a managed function from pure unmanaged C code, right?
If that's the case, this has nothing to do with the mixed mode issue, "mixed mode" means a single DLL that contains both managed(IL) and native code. You are calling an "entry point" in a C# managed assembly, that you have created by tweaking the IL and re-assembling, I guess you know that this is not a
supported scenario and extremely error prone. All you can do is use a
supported interop mechanism, that is, a real "mixed mode DLL", that calls
into C#, without resorting to a dirty hack, or use COM interop.

Willy.

[Willy Denoyette [MVP]]

Speed should not be a concern, COM interop can just be as fast as any other
interop mechanism (when done correctly). Whenever you transition from
unmanaged to unmanaged and back you'll incur some overhead, if this is not
wanted, you should not use managed code (or unmanaged for that matter).

Willy.
"Mali Guven" <gu*****@hotmai l.com> wrote in message
news:du******** **@eeyore.INS.c wru.edu...
|
| Thanks for the clarification. I will see what it would take to switch to
the
| real *mixed mode* (a DLL with both native and managed code). In my case,
COM
| interop is not an option due to speed concerns.
|
| Mali
|
|
| "Willy Denoyette [MVP]" <wi************ *@telenet.be> wrote in message
| news:OX******** ******@TK2MSFTN GP14.phx.gbl...
| >
| > "Mali Guven" <gu*****@hotmai l.com> wrote in message
| > news:du******** **@eeyore.INS.c wru.edu...
| > | Hello,
| > |
| > | I have a native DLL (written in C) which is supposed to call a managed
| DLL
| > | (was written in C#, and an entry point was injected modifying the
| ildasm'd
| > | code).
| > |
| > | The exectuable calls the native DLL but the native DLL fails to load
the
| > | managed DLL. The paper that addresses the 'mixed DLL problem' below
does
| > not
| > | offer any understandable workaround.
| > |
| >
|
http://msdn.microsoft.com/library/de...ingProblem.asp
| > |
| > | Does anybody who has came across this have a better understanding of
the
| > | possible resolutions of the mixed dll problem? I am very close to
| totally
| > | abondaning working with mixed DLLs (wasting hundreds of manhours).
| > |
| > | Regards,
| > | Mali
| > |
| > |
| >
| > If I understand you correctly, you are calling a managed function from
| pure
| > unmanaged C code, right?
| > If that's the case, this has nothing to do with the mixed mode issue,
| "mixed
| > mode" means a single DLL that contains both managed(IL) and native code.
| You
| > are calling an "entry point" in a C# managed assembly, that you have
| created
| > by tweaking the IL and re-assembling, I guess you know that this is not
a
| > supported scenario and extremely error prone. All you can do is use a
| > supported interop mechanism, that is, a real "mixed mode DLL", that
calls
| > into C#, without resorting to a dirty hack, or use COM interop.
| >
| > Willy.
| >
| >
|
|