Take the 2-minute tour ×

I have a C# app using a C++ DLL. This has been working fine but I now have to change "Treat wchar_t as built-in type" from "Yes (/Zc:wchar_t)" to "No (/Zc:wchar_t-)" and my C# app has become very unstable. The interop layer between C++ and C# include some strings as function parameters and in structs like this:


typedef struct
    // Used to be: WCHAR wstrName[256];
    wchar_t wstrName[256];
} sdevicemodel_t;


namespace Thingy
    [StructLayout(LayoutKind.Sequential, CharSet = CharSet.Unicode)]
    public struct DeviceModel
        // info
        [MarshalAs(UnmanagedType.ByValTStr, SizeConst = 256)]
        public string Name;

Do I need to change this declaration to match the C++ change, or is this fine and my problem lies elsewhere?

Thanks for any help.

share|improve this question
By turning off /Zc:wchar_t you are now saying that you will define wchar_t in your code if you use it. What is it defined as? –  Guvante Mar 13 '12 at 23:14
It's still defined by Visual Studio. –  parsley72 Mar 14 '12 at 0:28
add comment

1 Answer

up vote 3 down vote accepted

Short answer is: No, it does not affect the Interop in any way.

This option says the compiler to treat the wchar_t C++ type as a built-in type, instead of a typedef of unsigned short. This is required by the (not-so) latest versions of the C++ language, but older versions of the MS C++ compilers didn't do it right.

So now you have two options: the C++ standards way: (The Right Way™) and the back-compatible way (The MS Way™).

But that difference (built-in type vs. typedef type) is only significant when you do function overloads, template specializations or the like. C# Interop is concerned only with binary compatibility, and that is unchanged by this option (wchar_t is in both cases an unsigned 16-bit integer).

share|improve this answer
add comment

Your Answer


