MSDN Magazine - January 2008 - (Page 20)

If [PreserveSigAttribute] is set to true (the default for P/Invoke), this transformation won’t happen. Note that with COM functions, [PreserveSigAttribute] is usually set to false by default, though there are a number of ways to change that. For details, please consult the MSDN® documentation for TlbExp.exe and TlbImp.exe. 3. Always specify the capacity of StringBuilder in advance and make sure the capacity is big enough to hold the buffer. The best practice on the unmanaged code side is to accept the size of the string buffer as an argument to avoid buffer overruns. In COM, you can also use size_is in IDL to specify the size. When the CLR performs data marshaling, it has two options: copying and pinning (see msdn2.microsoft.com/23acw07k). By default, the CLR will make a copy that will be used during marshaling. For example, if managed code is passing a string as an ANSI CString to unmanaged code, the CLR will make a copy of the string, convert it to ANSI, and then pass the temporary’s pointer to unmanaged code. That copying can be quite slow and can create performance problems. In certain cases, the CLR is able to optimize the marshaling pro cess by directly pinning the managed object in the Garbage Col lector (GC) heap so that it cannot be relocated during the call. The pointer to the managed object (or to somewhere inside the man aged object) will be passed directly to unmanaged code. Pinning is performed when all of the following conditions are met: First, managed code must be calling native code, not the other way around. Second, the type must be blittable or must be capable of becoming blittable under certain conditions. Third, you’re not passing by reference (out or ref), and fourth, the caller and callee are in the same thread context or apartment. The second rule deserves further explanation. A blittable type is one that has a common representation in both managed and unmanaged memory. As such, blittable types do not require con version when marshaling. A typical example of a type that is non blittable, but can become blittable, is the char type. By default, it is nonblittable since it can be mapped to either Unicode or ANSI. However, because char is always Unicode in the CLR, it does be come blittable when you specify [DllImportAttribute(CharSet= Unicode)] or [MarshalAsAttribute(UnmanagedType.LPWSTR)]. In the following example, arg can be pinned in PassUnicodeString, but it cannot be pinned in PassAnsiString: [DllImport(@”MarshalLib.dll”, CharSet = CharSet.Unicode)] public static extern string PassUnicodeString(string arg); [DllImport(@”MarshalLib.dll”, CharSet = CharSet.Ansi)] public static extern string PassAnsiString(string arg); StringBuilder and Marshaling The CLR marshaler has builtin knowledge of the StringBuilder type and treats it differently from other types. By default, StringBuilder is passed as [InAttribute, OutAttribute]. StringBuilder is special because it has a Capacity property that can determine the size of the required buffer at run time, and it can be changed dynamically. Therefore, during the marshaling process, the CLR can pin StringBuilder, directly pass the address of internal buffer used in StringBuilder, and allow the contents of this buffer to be changed by native code in place. To take full advantage of StringBuilder, you’ll need to follow all of these rules: 1. Don’t pass StringBuilder by reference (using out or ref). Other wise, the CLR will expect the signature of this argument to be wchar_t ** instead of wchar_t *, and it won’t be able to pin StringBuilder’s internal buffer. Performance will be significantly degraded. 2. Use StringBuilder when the unmanaged code is using Unicode. Otherwise, the CLR will have to make a copy of the string and convert it between Unicode and ANSI, thus degrading perfor mance. Usually you should marshal StringBuilder as LPARRAY of Unicode characters or as LPWSTR. Figure 7 CLR Type Knowledge IDL Signature [In] Type [In] Type * [Out] Type * [In, Out] Type * [In] Type ** [Out] Type ** [In, Out] Type ** Change Type No change allowed No change allowed In-place change In-place change No change allowed Reference change Reference change or in-place change Copying and Pinning Figure 8 Type Change Rules C# Signature int arg out int arg ref int arg string arg out string arg ref string arg [InAttribute, OutAttribute] StringBuilder arg [OutAttribute] StringBuilder arg Change Type No change allowed In-place change In-place change No change allowed Reference change Reference change or in-place change In-place change In-place change Memory Ownership During a function call, a function can make two kinds of changes to its arguments: a reference change or an inplace change. A refer ence change involves changing where a pointer points; if the pointer already points to a piece of allocated memory, that memory may first need to be freed before the pointer to it is lost. An inplace change involves changing the memory at the location pointed to by the reference. Which of these changes is made depends on the type of the ar gument and, most importantly, the contract between the callee and caller. However, since the CLR cannot figure out the contract automatically, it has to rely on common knowledge about types, as illustrated in Figure 7. 20 msdnmagazine CLR Inside Out http://msdn2.microsoft.com/23acw07k

Table of Contents Feed for the Digital Edition of MSDN Magazine - January 2008

MSDN Magazine - January 2008 Contents Toolbox CLR Inside Out Data Points Advanced Basics Cutting Edge IIS 7.0 - Enhance Your Apps with the Integrated ASP.NET Pipeline World Ready - Around the World with ASP.NET AJAX Applications WCF Syndication - HTTP Programming with WCF and the .NET Framework 3.5 Wicked Code Foundations Extreme ASP.NET {End Bracket}

MSDN Magazine - January 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.