Microsoft MVP성태의 닷넷 이야기
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일

C# - GUID 타입 전용의 UnmanagedType.LPStruct - 두 번째 이야기

이전 글에서,

C# - GUID 타입 전용의 UnmanagedType.LPStruct
; https://www.sysnet.pe.kr/2/0/12444

포인터 형의 GUID* 인자를 받는 API로,

__declspec(dllexport) void __stdcall GuidFunc(GUID* pGuid)
{
    wchar_t buf[1024] = { 0 };
    StringFromGUID2(*pGuid, buf, 1024);
    wcout << buf << endl;
}

UnmanagedType.LPStruct 특성을 지정한 Guid 인자를 넘겨줄 수 있다고 했습니다.

[DllImport("Dll1.dll", EntryPoint = "GuidFunc")]
static extern void GuidFunc([MarshalAs(UnmanagedType.LPStruct)] Guid ptr);

지난 글에 설명했지만, 원래 struct 값 형식은 닷넷 런타임이 마샬링 작업을 수행하지 않습니다. 하지만, 위와 같이 LPStruct를 지정한 경우에는 Guid 타입에 대해 마샬링을 수행하는데요, 이것을 포인터를 출력함으로써 확인할 수 있습니다.

__declspec(dllexport) void __stdcall GuidFunc(GUID* pGuid)
{
    wchar_t buf[1024] = { 0 };
    std::ignore = StringFromGUID2(*pGuid, buf, 1024);
    wcout << L"[GuidFunc] " << buf << L", ptr == " << pGuid << endl;
}

Guid iUnk = new Guid("{00000000-0000-0000-C000-000000000046}");

unsafe 
{
    Guid* ptr = &iUnk;
    Console.WriteLine($"[C#] ptr: {new IntPtr(ptr).ToInt64():X}");
    GuidFunc(iUnk);
}

/* 출력 결과:
    Console.WriteLine(iUnk);
[C#] ptr: bfe9a8
[GuidFunc] {00000000-0000-0000-C000-000000000046}, ptr == 0000000000BFE960
*/

포인터 값이 다르다는 것으로, 즉 닷넷 런타임은 Guid 값을 받아 별도의 메모리에 복사한 후 C/C++ API에 그 포인터 위치를 넘겨준 것으로 해석할 수 있습니다.




문서에도 나오지만, 엄밀히 UnmanagedType.LPStruct은 REFIID 타입으로 정의한 인자를 위해 만든 것입니다.

Native interoperability best practices
; https://learn.microsoft.com/en-us/dotnet/standard/native-interop/best-practices>

GUIDs are usable directly in signatures. Many Windows APIs take GUID& type aliases like REFIID. When passed by ref, they can either be passed by ref or with the [MarshalAs(UnmanagedType.LPStruct)] attribute.


단지, 저것이 GUID* 포인터 타입에도 문제없이 적용되는 이유는 GUID& 타입이 내부적으로는 포인터와 다를 바가 없기 때문입니다. (실제로 REFIID의 경우 C++에서 GUID&로, C 언어에서는 GUID* 타입으로 정의합니다.)

하지만, 포인터로 받는 경우에 LPStruct를 쓰는 것은 포인터가 [In, Out]의 의미를 갖는다는 점에서 어울리지 않습니다. 일례로, GuidFunc 내부에서 Guid* 인자의 값을 변경하는 경우,

__declspec(dllexport) void __stdcall GuidFunc(GUID* pGuid)
{
    ((byte *)pGuid)[0] = 0xFF;
}

C# 호출 측에서는,

[DllImport("Dll1.dll")]
static extern void GuidFunc([MarshalAs(UnmanagedType.LPStruct)] Guid ptr);

Guid iUnk = new Guid("{00000000-0000-0000-C000-000000000046}");
GuidFunc(iUnk); // iUnk의 값이 바뀌지 않음

값이 바뀌지는 않습니다. 이런 경우, 만약 Guid가 (struct가 아닌) class 참조 형식이었다면 [In, Out]을 함께 곁들여,

[DllImport("Dll1.dll")]
static extern void GuidFunc([In, Out, MarshalAs(UnmanagedType.LPStruct)] Guid ptr);

정상적으로 C# 호출 측의 값이 바뀌게 만들 수도 있었을 것입니다. 하지만, In, Out은 참조 형식의 인스턴스를 마샬링할 때만 관여하므로 위와 같이 Guid struct에 대해서는 아무런 역할도 하지 않으므로 의도한 동작을 수행할 수 없습니다.




그나저나, LPStruct를 REFIID 인자를 갖는 API에 대해 사용하라고 했는데... 좀 이상하지 않나요? GUID&는 결국 포인터인데 그렇다면 그것도 [In, Out] 의미를 갖는 유형이므로 단순히 LPStruct만 지정해서는 안 될 것 같습니다.

하지만, 그래도 되는 것이 REFIID의 엄밀한 정의에는 const를 포함하고 있기 때문입니다.

#define REFIID const IID &

그렇기 때문에 애당초 해당 API에서는 인자로 넘어온 GUID 값을 수정하지 못할 것임을 보장하므로,

__declspec(dllexport) void __stdcall GuidReadOnlyRefFunc(REFIID refGuid)
{
    refGuid.Data3 = 0x05; // 컴파일 오류
    // Error C3490 'Data3' cannot be modified because it is being accessed through a const object
}

별도의 [Out] 의미를 기대하지 않고 LPStruct 처리가 가능한 것입니다.




정리해 보면, Win32 API, 특히 COM 함수와 연동할 때 아래와 같이 정의돼 있다면,

virtual HRESULT STDMETHODCALLTYPE GetItem(/* [out] */ __RPC__out GUID *pguidKey) = 0;

이런 경우는 GUID* 포인터이지만 __RPC__out 힌트가 있으므로 [Out] 의미만 갖는다고 짐작할 수 있습니다. 따라서 C# 측에서는 마샬링 없는 유형의 out 인자로 호출할 수 있습니다.

uint GetItemByIndex(out Guid pGuidKey);

반면, 이렇게 정의한 경우라면,

virtual HRESULT STDMETHODCALLTYPE GetResource(/* [annotation][in] */ _In_  REFIID riid) = 0;

REFIID로 명시한 경우이므로 LPStruct를 활용해 인자 전달을 할 수 있습니다.

uint GuidRefFunc([MarshalAs(UnmanagedType.LPStruct)] Guid riid);

단지, 이런 경우 아쉬운 점이라면 내부적으로 마샬링을 수행하므로 Guid 값 복사 부하가 발생합니다. 이것을 없애기 위해서는 포인터로 전달해야 하지만 그러면 불필요하게 unsafe 문맥도 필요해지고 포인터를 구해야 하는 코드도 넣어야 합니다.

[DllImport("Dll1.dll", EntryPoint = "GuidFunc")]
static unsafe extern void GuidFunc2(Guid* ptr);

unsafe
{
    GuidFunc2(&iUnk);
}

저렇게 하면 속도는 빨라질 수 있지만 REFIID의 ([Out]이 없는) [In] 의미와는 또 맞지 않게 됩니다. 재미있는 건, 이런 양쪽의 장/단점을 모두 해결할 수 있는 문법이 C# 7.2부터 (값 형식의 성능 개선을 목적으로) 제공되는 in 변경자입니다.

[DllImport("Dll1.dll", EntryPoint = "GuidFunc")]
static extern void GuidInFunc(in Guid ptr);

GuidInFunc(in iUnk); // 값 복사도 없고, [In] 의미도 맞고!

혹은, C# 12부터 추가된 ref readonly 변경자를 써도 됩니다.

[DllImport("Dll1.dll", EntryPoint = "GuidFunc")]
static extern void GuidRefReadonlyFunc(ref readonly Guid ptr);

GuidRefReadonlyFunc(ref iUnk);

하지만, 여기서 주의할 점은, "in" 또는 "ref readonly"의 사용이 REFIID와 의미상으로 맞는다는 것이지, 실제로 [Out] 동작을 막을 수는 없다는 점입니다. 따라서 REFIID가 아닌 일반 Guid* 포인터 인자에 사용하게 되면 해당 C/C++ 함수의 내부에서 값을 변경하는 경우 C# 측의 인자에도 그대로 반영되므로 유의해야 합니다.

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




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







[최초 등록일: ]
[최종 수정일: 4/29/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)
12289정성태8/6/202017041개발 환경 구성: 502. Portainer에 윈도우 컨테이너를 등록하는 방법
12288정성태8/5/202016024오류 유형: 637. WCF - The protocol 'net.tcp' does not have an implementation of HostedTransportConfiguration type registered.
12287정성태8/5/202017622오류 유형: 636. C# - libdl.so를 DllImport로 연결 시 docker container 내에서 System.DllNotFoundException 예외 발생
12286정성태8/5/202018991개발 환경 구성: 501. .NET Core 용 container 이미지 만들 때 unzip이 필요한 경우
12285정성태8/4/202018572오류 유형: 635. 윈도우 10 업데이트 - 0xc1900209 [2]
12284정성태8/4/202017958디버깅 기술: 169. Hyper-V의 VM에 대한 메모리 덤프를 뜨는 방법
12283정성태8/3/202018914디버깅 기술: 168. windbg - 필터 드라이버 확인하는 확장 명령어(!fltkd) [2]
12282정성태8/2/202016664디버깅 기술: 167. windbg 디버깅 사례: AppDomain 간의 static 변수 사용으로 인한 crash (2)
12281정성태8/2/202020280개발 환경 구성: 500. (PDB 연결이 없는) DLL의 소스 코드 디버깅을 dotPeek 도구로 해결하는 방법
12280정성태8/2/202018404오류 유형: 634. 오라클 (평생) 무료 클라우드 VM 생성 후 SSH 접속 시 키 오류 발생 [2]
12279정성태7/29/202020213개발 환경 구성: 499. 닷넷에서 접근해보는 InterSystems의 Cache 데이터베이스파일 다운로드1
12278정성태7/23/202016787VS.NET IDE: 149. ("Binary was not built with debug information" 상태로) 소스 코드 디버깅이 안되는 경우
12277정성태7/23/202018732개발 환경 구성: 498. DEVPATH 환경 변수의 사용 예 - .NET Reflector의 (PDB 연결이 없는) DLL의 소스 코드 디버깅
12276정성태7/23/202018185.NET Framework: 930. 개발자를 위한 닷넷 어셈블리 바인딩 - DEVPATH 환경 변수
12275정성태7/22/202020286개발 환경 구성: 497. 닷넷에서 접근해보는 InterSystems의 IRIS Data Platform 데이터베이스파일 다운로드1
12274정성태7/21/202019660개발 환경 구성: 496. Azure - Blob Storage Account의 Location 이전 방법 [1]파일 다운로드1
12273정성태7/18/202022406개발 환경 구성: 495. Azure - Location이 다른 웹/DB 서버의 경우 발생하는 성능 하락
12272정성태7/16/202015572.NET Framework: 929. (StrongName의 버전 구분이 필요 없는) .NET Core 어셈블리 바인딩 규칙 [2]파일 다운로드1
12271정성태7/16/202018545.NET Framework: 928. .NET Framework의 Strong-named 어셈블리 바인딩 (2) - 런타임에 바인딩 리디렉션파일 다운로드1
12270정성태7/16/202019232오류 유형: 633. SSL_CTX_use_certificate_file - error:140AB18F:SSL routines:SSL_CTX_use_certificate:ee key too small
12269정성태7/16/202016505오류 유형: 632. .NET Core 웹 응용 프로그램 - The process was terminated due to an unhandled exception.
12268정성태7/15/202019065오류 유형: 631. .NET Core 웹 응용 프로그램 오류 - HTTP Error 500.35 - ANCM Multiple In-Process Applications in same Process
12267정성태7/15/202021234.NET Framework: 927. C# - 윈도우 프로그램에서 Credential Manager를 이용한 보안 정보 저장파일 다운로드1
12266정성태7/14/202018112오류 유형: 630. 사용자 계정을 지정해 CreateService API로 서비스를 등록한 경우 "Error 1069: The service did not start due to a logon failure." 오류발생
12265정성태7/10/202017017오류 유형: 629. Visual Studio - 웹 애플리케이션 실행 시 "Unable to connect to web server 'IIS Express'." 오류 발생
12264정성태7/9/202028334오류 유형: 628. docker: Error response from daemon: Conflict. The container name "..." is already in use by container "...".
... 61  62  63  64  65  [66]  67  68  69  70  71  72  73  74  75  ...