H
Henk Verhoeven
Hi Everyone,
I just had a very odd behavior and was hoping someone could shed some light
on this.
I wrote a wrapper class around a 3rd party DLL (pinvoke)
I use this library in VB (or CS) and was able to re-produce 2 problems. By
the nature of the problem I figure it must be this 3rd party dll, but I am
not sure.
[DllImport("some3rd.dll", EntryPoint="meemoo",
CharSet=CharSet.Ansi,
CallingConvention=CallingConvention.StdCall,SetLastError=true) ]
private static extern void _MeeMoo(char[] in,StringBuilder out);
The some3rd.dll is located in the same folder as the application
1. If I call the application (vb/cs) from a path with spaces, then the dll
function call give a an object reference not set error, once I move this
into a folder with no spaces then I am good.
2. When using a file open dialog, and not restoring the directory causes the
same error. So I think that when the dll loads, either in the 3rd party dll
itself or VB/CS is loosing the path to the dll
I guess it cannot be cs/vb , because it loads dll (I think). Just the path
issues causes problems. How can I ( or can I) code within my wrapper around
this, ensure that the dll is located in the path before calling the dll
function.
[DllImport("c:\path\some3rd.dll", EntryPoint="meemoo", does
causes the same issues.
In my wrapper class, how can I "prevent" this from happening. Considering
that it looks like the requirements are that the current directory must be
the same location as the dll to facilitate this dll. I also don't want to
screw-up any calling dll's /exe's if they possibly need to change the
directory as a functional requirement.
Maybe something like a "temporary restore of the folder", before calling it,
then reverting back to the "current directory" or something along those
lines. Any ideas?
I just had a very odd behavior and was hoping someone could shed some light
on this.
I wrote a wrapper class around a 3rd party DLL (pinvoke)
I use this library in VB (or CS) and was able to re-produce 2 problems. By
the nature of the problem I figure it must be this 3rd party dll, but I am
not sure.
[DllImport("some3rd.dll", EntryPoint="meemoo",
CharSet=CharSet.Ansi,
CallingConvention=CallingConvention.StdCall,SetLastError=true) ]
private static extern void _MeeMoo(char[] in,StringBuilder out);
The some3rd.dll is located in the same folder as the application
1. If I call the application (vb/cs) from a path with spaces, then the dll
function call give a an object reference not set error, once I move this
into a folder with no spaces then I am good.
2. When using a file open dialog, and not restoring the directory causes the
same error. So I think that when the dll loads, either in the 3rd party dll
itself or VB/CS is loosing the path to the dll
I guess it cannot be cs/vb , because it loads dll (I think). Just the path
issues causes problems. How can I ( or can I) code within my wrapper around
this, ensure that the dll is located in the path before calling the dll
function.
[DllImport("c:\path\some3rd.dll", EntryPoint="meemoo", does
causes the same issues.
In my wrapper class, how can I "prevent" this from happening. Considering
that it looks like the requirements are that the current directory must be
the same location as the dll to facilitate this dll. I also don't want to
screw-up any calling dll's /exe's if they possibly need to change the
directory as a functional requirement.
Maybe something like a "temporary restore of the folder", before calling it,
then reverting back to the "current directory" or something along those
lines. Any ideas?