I am calling ODBC API functions from a C# program. At first I was specifying
CharSet=CharSet.Unicode because I wanted to assume that the Unicode versions
were available. However, now I think I need to check whether the ANSI functions
are being called.
In Adam Nathan's book ".NET and COM: The Complete Interoperability Guide", on
page 797, he says (under the section on CharSet.Unicode):
"Unicode...causes the CLR to look for an entry point called FunctionNameW, even
if there is an entry point called FunctionName. (If there is no FunctionNameW
function, FunctionName will be invoked if it exists.)"
My question is, how can I tell at runtime which function (FunctionNameW or
FunctionName) was called? I need to do this in a platform-independent way
because I am running on Mono also (in fact, that's where I'm seeing the ANSI
functions chosen instead of Unicode).
Thinking about it now, I guess I could do something brute-force and use the
ExactSpelling setting to declare a P/Invoke signature for the W function, and
trap for System.EntryPointNotFoundException, but I was wondering if there was a
smarter way.
Thanks,
Chuck
Robert Jordan - 28 Sep 2004 15:39 GMT
> I am calling ODBC API functions from a C# program. At first I was specifying
> CharSet=CharSet.Unicode because I wanted to assume that the Unicode versions
> were available. However, now I think I need to check whether the ANSI functions
> are being called.
CharSet=CharSet.Auto
bye
Rob
"Peter Huang" - 29 Sep 2004 04:16 GMT
Hi Chunk,
I agree with Rob's suggestion. We can use CharSet.Auto.
CharSet.Auto
Platform invoke chooses between ANSI and Unicode formats at run time, based
on the target platform.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/htm
l/cpconcharsetobjectfield.asp
Auto
Supported by the .NET Compact Framework.
Automatically marshal strings appropriately for the target operating
system. The default is Unicode on Windows NT, Windows 2000, Windows XP, and
the Windows Server 2003 family; the default is Ansi on Windows 98 and
Windows Me.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/
frlrfsystemruntimeinteropservicescharsetclasstopic.asp
The document is based on the CLR of Microsoft version, it may have
different behavior on Mono which depends on Mono implementation.
Best regards,
Peter Huang
Microsoft Online Partner Support

Signature
Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
Chuck Heatherly - 29 Sep 2004 09:52 GMT
>Hi Chuck,
>
[quoted text clipped - 13 lines]
>http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/
>frlrfsystemruntimeinteropservicescharsetclasstopic.asp
I don't understand how this answers my question though. I want to know how to
tell elsewhere in my code whether the ANSI or Unicode version of the function
was chosen.
Chuck
Robert Jordan - 29 Sep 2004 11:08 GMT
>>Hi Chuck,
>>
[quoted text clipped - 17 lines]
> tell elsewhere in my code whether the ANSI or Unicode version of the function
> was chosen.
You can query Marshal.SystemDefaultCharSize. When it's 2,
then the Unicode functions will be called, unless you
overrode the P/Invoke DllImport declaration with CharSet.Ansi.
bye
Rob
Chuck Heatherly - 29 Sep 2004 11:58 GMT
>>>Hi Chuck,
>>>
[quoted text clipped - 21 lines]
>then the Unicode functions will be called, unless you
>overrode the P/Invoke DllImport declaration with CharSet.Ansi.
Rob, thanks for responding. I did see this field in MSDN, but it seems that
it's based on whether the operating system supports Unicode or not.
In my case with ODBC drivers, I think you can have a Unicode system with an ODBC
driver that only supports ANSI. For example, the MySQL ODBC Driver version 3.51
does not support Unicode, so the ANSI versions of the ODBC functions are called.
But Marshal.SystemDefaultCharSize returns 2 on that system.
Again, if there's no other way to determine what I'm looking for, I guess I can
just use the ExactSpelling attribute and trap for the EntryPointNotFound
exception.
Chuck
"Peter Huang" - 30 Sep 2004 10:29 GMT
Hi Chunk,
I am sorry for misunderstanding your meaning, now I am reseaching the issue
to see if there is an approach to detect in the runtime which version of
DLL entrypoint we are calling.
Thanks.
Best regards,
Peter Huang
Microsoft Online Partner Support

Signature
Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
"Peter Huang" - 01 Oct 2004 04:00 GMT
Hi
I have consulted the issue with the engineer in our dev team, that he has
confirmed that we can not do that in CLR.
So far I think your approach that use the try...catch is the only way to do
the job.
Thanks for you understanding, if you still have any concern please feel
free to post here.
Best regards,
Peter Huang
Microsoft Online Partner Support

Signature
Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.