Microsoft MVP성태의 닷넷 이야기
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
(연관된 글이 1개 있습니다.)
(시리즈 글이 2개 있습니다.)
.NET Framework: 400. 눈으로 확인하는 LayoutKind 옵션 효과
; https://www.sysnet.pe.kr/2/0/1558

닷넷: 2250. PInvoke 호출 시 참조 타입(class)을 마샬링하는 [IN], [OUT] 특성
; https://www.sysnet.pe.kr/2/0/13609




PInvoke 호출 시 참조 타입(class)을 마샬링하는 [IN], [OUT] 특성

예를 하나 들어볼까요? ^^

우선, 비교를 위해 값 형식인 struct 타입을 P/Invoke로 호출해 보겠습니다. 이를 위해 다음과 같이 API 하나를 노출하는 DLL을 만들고,

// C++ 헤더

struct Store
{
public:
    __int64 value1;
};

extern "C"
{
    __declspec(dllexport) void GetStore(Store* pValue);
};

// C++ cpp

__declspec(dllexport) void GetStore(Store* pValue)
{
    printf("Called: %I64d\n", pValue->value1);
    pValue->value1 = 50;
}

C# 측에서 다음과 같이 호출하면,

using System.Runtime.InteropServices;

[StructLayout(LayoutKind.Sequential)]
public struct StoreStruct
{
    public long v1;
    public StoreStruct(long value) => v1 = value;
}

internal class Program
{
    [DllImport("Dll1.dll")]
    static extern void GetStore(out StoreStruct value);

    static void Main(string[] args)
    {
        StoreStruct value = new StoreStruct(10);

        GetStore(out value);
        Debug.Assert(value.v1 == 50);
    }
}

/* 실행 시 출력 결과:
Called: 10
*/

C/C++ 측의 GetStoreStruct 함수도 잘 호출이 되었고, 거기서 반환한 v1의 값도 C# 측에서 50으로 잘 받았습니다. 여기서 재미있는 것은, C#의 out 예약어를 사용했지만 그와 무관하게 C/C++ 측의 API에서는 마치 ref와 동일하게 작용했다는 점입니다. 사실 ref와 out은 C# 언어의 구분일 뿐 내부적으로는 2개 모두 ref와 동일하게 처리되기 때문입니다.




그런데, 저 예제를 class로 바꿔서, 즉 struct StoreStruct를 class StoreClass로 테스트하면 어떻게 될까요? 이를 위해 C# 측에서는 다음과 같은 코드를 추가한 다음,

[StructLayout(LayoutKind.Sequential)]
public class StoreClass
{
    public long v1;
    public StoreClass(long value) => v1 = value;
}

internal class Program
{
    [DllImport("Dll1.dll", EntryPoint = "GetStore")]
    static extern void GetStoreClass(ref StoreClass value);

    static void Main(string[] args)
    {
        StoreClass value = new StoreClass(20);

        GetStoreClass(ref value); // 예외 발생
    }
}

/* 실행 결과: C/C++ 측의 printf 출력과 함께,
Called: 1809131705472

C# 측으로 넘어오는 시점에 예외 발생
System.NullReferenceException
  HResult=0x80004003
  Message=Object reference not set to an instance of an object.
  Source=<Cannot evaluate the exception source>
  StackTrace:
<Cannot evaluate the exception stack trace>
*/

실행해 보면, 일단 C/C++ 함수까지는 코드가 실행된 것임을 printf 출력으로 알 수 있지만, 예외는 C# 측으로 제어를 반환하면서 발생합니다. 추적을 해보면, C/C++ 측에서 "Store *pValue"로 받은 값의 첫 번째 필드인 1809131705472 값을 포인터라고 가정하고 hex 주소로 따지만 0x1a538a71480가 됩니다. 위의 경우 디버거에서 메모리 창을 이용해 그 주소의 값을 보면 20이 들어있는 것을 확인할 수 있습니다.

따라서, 오히려 C/C++ 측에서 다음과 같이 값을 받은 거나 마찬가지입니다.

__declspec(dllexport) void GetStore(Store value)
{
    printf("Called: %I64d(%I64x)\n", value.value1);
}

이유가 뭘까요? ^^




사실, C#의 out/ref 인자는 마샬링에 어떠한 영향도 주지 않습니다. 단지 그것은 C#의 문법대로 변수의 값, 또는 참조 주소를 넘기는 역할만 하며 거기에 struct나 class의 차별은 없습니다.

하지만, P/Invoke에 의한 Managed <- -> Native 간의 데이터 이동은 struct 값 형식은 상관없지만 class 참조 형식의 경우에는 반드시 닷넷 런타임이 관여를 하게 됩니다. 따라서, 애당초 참조 형식이라면 C# 측에서 out이나 ref가 아닌, 대상 API에 맞춰 마샬링 방법을 지정해야 합니다.

아래의 문서가 바로 그런 내용을 설명합니다. ^^

Marshalling Classes, Structures, and Unions
; https://learn.microsoft.com/en-us/dotnet/framework/interop/marshalling-classes-structures-and-unions#systime-sample

The parameter must be declared with the InAttribute and OutAttribute attributes because classes, which are reference types, are passed as In parameters by default.


기본 동작이 class 참조 형식에 대해 "InAttribute" 역할로 전달된다고 하는데요, 이전 예제 코드에서 왜 "__declspec(dllexport) void GetStore(Store value)"처럼 값이 전달된 것인지 설명이 됩니다.

그러니까, class 참조 형식은 InAttribute, OutAttribute 특성을 지정해 닷넷 런타임 측에 마샬링을 제어할 수 있는 힌트를 줘야 하는 것입니다. 따라서, 위에서 오류가 발생했던 코드를 올바르게 동작하게 하려면 다음과 같이 호출해 주면 됩니다.

[DllImport("Dll1.dll", EntryPoint = "GetStore")]
static extern void GetStoreClass([In, Out] StoreClass value);

StoreClass value = new StoreClass(20);

GetStoreClass(value);
Debug.Assert(value.v1 == 50);




그런데, 사실 위의 구조체 같은 경우에는 굳이 [In, Out]을 지정하지 않아도 잘 동작합니다.

[DllImport("Dll1.dll", EntryPoint = "GetStore")]
static extern void GetStoreClass(StoreClass value);

StoreClass value = new StoreClass(20);

GetStoreClass(value);
Debug.Assert(value.v1 == 50);

왜 그런 걸까요? ^^ 이유는 간단합니다. 닷넷 런타임이 해당 타입은 별도의 전/후처리를 할 필요가 없다고 판단하므로 그냥 value 인스턴스 자체의 주소를 C/C++ 측에 넘기기 때문입니다. 실제로 포인터 값을 출력해 확인할 수 있습니다.

// C# 측 코드

{
    StoreClass value = new StoreClass(20);

    fixed (long* ptr = &value.v1)
    {
        Console.WriteLine($"ptr: 0x{new IntPtr(ptr):X}");
        GetStoreClass(value);
        Debug.Assert(value.v1 == 50);
    }
}

// C/C++ 측 코드

__declspec(dllexport) void GetStore(Store* pValue)
{
    printf("Called: %I64d - ptr == 0x%p\n", pValue->value1, pValue);
    pValue->value1 = 50;
}

실행해 보면 이런 출력이 나옵니다.

ptr: 0x1E402415640
Called: 20(14) - ptr == 0x000001E402415640

동일하죠? ^^ 위와 같은 이유 덕분에 [In, Out]을 지정하지 않아도 상관없지만, 언제나 그런 것은 아닙니다. 즉, 닷넷 런타임이 마샬링에 관여하게 되는 경우에 문제가 발생합니다. 이를 재현하기 위해선, 마샬링이 관여하도록 일부러 MarshalAs를 사용하는 타입을 하나 넣으면 됩니다.

[StructLayout(LayoutKind.Sequential)]
public class OrderTestClass
{
    public int i;
    [MarshalAs(UnmanagedType.LPWStr, SizeConst = 10)]
    public string s;
}

위의 타입을 C/C++에서는 이렇게 사용하도록 코드를 추가하고,

// C/C++ 헤더

struct OrderTest
{
public:
    int i;
    wchar_t* string;
};

extern "C"
{
    __declspec(dllexport) void GetOrderTest(OrderTest* pValue);
};

// C/C++ 측 코드

__declspec(dllexport) void GetOrderTest(OrderTest* pValue)
{
    printf("Called: %d, %ls - ptr == 0x%p\n", pValue->i, pValue->string, pValue);

    wcscpy_s(pValue->string, 10, L"GOOD");
    pValue->i = 70;
}

C#에서 호출하면,

[DllImport("Dll1.dll")]
static extern void GetOrderTest([In, Out] OrderTestClass value);

OrderTestClass value = new OrderTestClass();
value.i = 5;
value.s = "TEST";

fixed (int* ptr = &value.i)
{
    Console.WriteLine($"[GetOrderTest] ptr: 0x{new IntPtr(ptr):X}");
    GetOrderTest(value);
    Debug.Assert(value.i == 70);
    Debug.Assert(value.s == "GOOD");
}

이번에는 출력 결과에서 포인터 값이 다르게 나옵니다.

ptr: 0x15193015700
Called: 5, TEST - ptr == 0x0000003FF837E150

이유는 간단합니다. C#은 value 인스턴스를 넘겼지만, 닷넷 런타임은 int 4바이트 + sizeof(wchar_t) * 10개의 연속된 메모리 공간을 별도로 할당하고 거기에 ([In] 특성을 지정했으므로) 값을 채운 다음에 그 포인터를 C/C++ 측에 넘깁니다.

그리고 C/C++ 측에서는 해당 포인터에 값을 채운 다음 제어를 닷넷 런타임으로 반환하면, ([Out] 특성을 지정했으므로) 별도로 할당된 공간에 채워졌던 그 값을 다시 C#의 value 인스턴스에 설정해 주면서 P/Invoke API 호출을 마칩니다.

따라서, 위와 같은 경우에는 [In], [Out] 특성을 모두 지정해야만 C/C++ 측의 GetOrderTest 함수가 정상적으로 동작합니다. 여기서 만약,

  1. [In]을 뺀다면, 닷넷 런타임은 새로 할당한 공간에 C# 측의 value 인스턴스 값을 채우지 않고, 즉 0으로 초기화된 공간에 대한 포인터를 C/C++에 전달하므로 "OrderTest *pValue"의 i, string 값은 모두 0, null로 채워집니다.
  2. [Out]을 뺀다면, 닷넷 런타임은 [In]에 따라 값은 채워서 보내지만, C/C++ API 호출이 완료된 후 C# 측으로 값 복사를 해주지 않아 value 인스턴스의 값은 변하지 않게 됩니다.

이 정도면... 대충 이해가 되셨죠? ^^

(첨부 파일은 이 글의 예제 코드를 포함합니다.)




[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]

[연관 글]






[최초 등록일: ]
[최종 수정일: 4/27/2024]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 




... 61  62  63  64  65  66  67  68  [69]  70  71  72  73  74  75  ...
NoWriterDateCnt.TitleFile(s)
12209정성태4/13/202017399오류 유형: 614. 리눅스 환경에서 C/C++ 프로그램이 Segmentation fault 에러가 발생한 경우 (2)
12208정성태4/12/202015963Linux: 29. 리눅스 환경에서 C/C++ 프로그램이 Segmentation fault 에러가 발생한 경우
12207정성태4/2/202015790스크립트: 19. Windows PowerShell의 NonInteractive 모드
12206정성태4/2/202018421오류 유형: 613. 파일 잠금이 바로 안 풀린다면? - The process cannot access the file '...' because it is being used by another process.
12205정성태4/2/202015091스크립트: 18. Powershell에서는 cmd.exe의 명령어를 지원하진 않습니다.
12204정성태4/1/202015087스크립트: 17. Powershell 명령어에 ';' (semi-colon) 문자가 포함된 경우
12203정성태3/18/202017925오류 유형: 612. warning: 'C:\ProgramData/Git/config' has a dubious owner: '...'.
12202정성태3/18/202021187개발 환경 구성: 486. .NET Framework 프로젝트를 위한 GitLab CI/CD Runner 구성
12201정성태3/18/202018431오류 유형: 611. git-credential-manager.exe: Using credentials for username "Personal Access Token". [1]
12200정성태3/18/202018519VS.NET IDE: 145. NuGet + Github 라이브러리 디버깅 관련 옵션 3가지 - "Enable Just My Code" / "Enable Source Link support" / "Suppress JIT optimization on module load (Managed only)"
12199정성태3/17/202016166오류 유형: 610. C# - CodeDomProvider 사용 시 Unhandled Exception: System.IO.DirectoryNotFoundException: Could not find a part of the path '...\f2_6uod0.tmp'.
12198정성태3/17/202019527오류 유형: 609. SQL 서버 접속 시 "Cannot open user default database. Login failed."
12197정성태3/17/202018806VS.NET IDE: 144. .NET Core 콘솔 응용 프로그램을 배포(publish) 시 docker image 자동 생성 - 두 번째 이야기 [1]
12196정성태3/17/202015941오류 유형: 608. The ServicedComponent being invoked is not correctly configured (Use regsvcs to re-register).
12195정성태3/16/202018261.NET Framework: 902. C# - 프로세스의 모든 핸들을 열람 - 세 번째 이야기
12194정성태3/16/202020991오류 유형: 607. PostgreSQL - Npgsql.NpgsqlException: sorry, too many clients already
12193정성태3/16/202017902개발 환경 구성: 485. docker - SAP Adaptive Server Enterprise 컨테이너 실행 [1]
12192정성태3/14/202019914개발 환경 구성: 484. docker - Sybase Anywhere 16 컨테이너 실행
12191정성태3/14/202021037개발 환경 구성: 483. docker - OracleXE 컨테이너 실행 [1]
12190정성태3/14/202015614오류 유형: 606. Docker Desktop 업그레이드 시 "The process cannot access the file 'C:\Program Files\Docker\Docker\resources\dockerd.exe' because it is being used by another process."
12189정성태3/13/202021200개발 환경 구성: 482. Facebook OAuth 처리 시 상태 정보 전달 방법과 "유효한 OAuth 리디렉션 URI" 설정 규칙
12188정성태3/13/202026019Windows: 169. 부팅 시점에 실행되는 chkdsk 결과를 확인하는 방법
12187정성태3/12/202015565오류 유형: 605. NtpClient was unable to set a manual peer to use as a time source because of duplicate error on '...'.
12186정성태3/12/202017397오류 유형: 604. The SysVol Permissions for one or more GPOs on this domain controller and not in sync with the permissions for the GPOs on the Baseline domain controller.
12185정성태3/11/202017991오류 유형: 603. The browser service was unable to retrieve a list of servers from the browser master...
12184정성태3/11/202019910오류 유형: 602. Automatic certificate enrollment for local system failed (0x800706ba) The RPC server is unavailable. [3]
... 61  62  63  64  65  66  67  68  [69]  70  71  72  73  74  75  ...