CLR full description: Marshaling between managed and unmanaged code

Let's face it. The world is not perfect. Almost a few companies are developing programs entirely with managed code, and there are still a lot of legacy unmanaged code that you need to work with. How do you integrate managed and unmanaged projects? In the form of calling unmanaged code from a managed application or calling managed code from an unmanaged code application?

Fortunately, Microsoft®.net Framework Interop opens up a channel between managed and unmanaged code, while marshaling plays a very important role in that connection because it allows for data exchange between the two (see Figure 1). There are a number of factors that affect how the CLR marshals data between unmanaged and managed domains, including properties such as [MarshalAs], [StructLayout], [InAttribute], and [OutAttribute], and languages such as out and ref in C # Key words.

Figure 1 Bridging the Gap between Managed and unmanaged Code

Because of these factors, it may be a difficult problem to marshal correctly because it requires a lot of information about unmanaged and managed code. In this column, we'll cover some of the basic but confusing topics you'll encounter when trying to marshal in your daily work. We don't cover custom marshaling, marshaling complex structures, or other high-level topics, but if you really understand these basic concepts, you're ready to deal with them.

[InAttribute] and [OutAttribute]

The first marshaling topic we want to discuss is about the use of InAttribute and OutAttribute, which are the two property types that are located in the System.Runtime.InteropServices namespace. (C # and Visual basic® allow abbreviated forms [in] and [out] when you apply these attributes to your code, but we insist on using the full name to avoid confusion.) ）

When applied to method parameters and return values, these properties control the direction of marshaling, so they are called directional properties. [InAttribute] tells the CLR to marshal data from the caller to the callee at the start of the call, [OutAttribute] tells the CLR to marshal the data from the callee back to the caller when it returns. Both the caller and the callee can be unmanaged or managed code. For example, in a p/invoke call, it is managed code that calls unmanaged code. However, in a reverse p/invoke call, it is possible that unmanaged code invokes managed code through a function pointer.

[InAttribute] and [OutAttribute] have four possible combinations: use only [InAttribute], only [OutAttribute], use [InAttribute, OutAttribute], and neither. If you do not specify any of the properties, you want the CLR to determine its own directional properties, which are usually by default using [InAttribute]. However, if it is a StringBuilder class, both [InAttribute] and [OutAttribute] are used at the same time without specifying any of the properties. (For more information, see the sections that follow on StringBuilder.) In addition, using the Out and ref keywords in C # may change the properties that have been applied, as shown in Figure 2. Note that if you do not specify a keyword for the parameter, it means that it is the default input parameter.

Figure 2 out and Ref and their associated Attributes

C # Keywords	Property
(not specified)	[InAttribute]
Out	[OutAttribute]
Ref	[Inattribute],[outattribute]