The SLAR (vol2) on System.Runtime.InteropServices.CharSet


Continuing in the series sharing some of the information in the .NET Framework Standard Library Annotated Reference Vol 1 and .NET Framework Standard Library Annotated Reference Vol 2 with some information on CharSet.


 


public enum CharSet


{


CF Ansi = 2,


Auto = 4,


MS CF None = 1,


Unicode = 3,


}


 


 


AN


It’s somewhat unfortunate that CharSet.Ansi is the default behavior for PInvoke, since


managed strings and characters are internally Unicode. Win32 APIs often expose both an ANSI


and Unicode export, but by default you end up calling the ANSI one, requiring the Interop


marshaler to copy each Unicode string to a new ANSI string! In contrast, by calling the Unicode


export, the CLR can just pin the managed strings and expose them directly. You can override


the default behavior and explicitly mark each PInvoke signature with CharSet.Auto,


although in the future the CLR will provide a module-level DefaultCharSetAttribute that


allows you to select your own default for all signatures in your module.


 



 


BTW – if you like Adam’s take on the world, check out his exhaustive book on Interop…


.NET and COM: The Complete Interoperability Guide

Comments (1)

  1. Kevin Westhead says:

    Another comment about this enum is that it doesn’t have a member for zero, which breaks the enum design guidelines (see http://blogs.msdn.com/kcwalina/archive/2004/05/18/134208.aspx). Instead, the None member has a value of 1 and this means you can have a situtation where the default value assigned by the CLR is not a member of the enum. E.g. the following ctor will output "False":

    internal class CharSetTest

    {

    private CharSet m_charSet;

    public CharSetTest() : base()

    {

    Debug.WriteLine(Enum.IsDefined(typeof(CharSet), m_charSet).ToString());

    }

    }

    Having said that, I doubt this enum is used much outside of the existing interop attributes, so it’s unlikely to be a problem.