Microsoft MVP성태의 닷넷 이야기
VC++: 54. C++로 만든 WinRT 프로그램 [링크 복사], [링크+제목 복사],
조회: 33454
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 
(연관된 글이 1개 있습니다.)

C++로 만든 WinRT 프로그램


"wafe" 님의 댓글로 인해 좀 더 살펴보았습니다.

Windows 8에서 새롭게 지원되는 WinRT 응용 프로그램
; https://www.sysnet.pe.kr/2/0/1122

[wafe] 닷넷 의존성은 언어를 c#으로 해서 그런 것 아닐까요? 언어를 c++로 하면 닷넷 의존성은 없을 것 같긴 합니다.

[wafe] 메트로 앱 환경에 대해서 설명한 글이 있어서 요약해봤어요.
http://wafe.kr/entry/Windows-8-revenge-of-com


지난번 글을 쓸 때에 제가 분명히 C++로도 WinRT 응용 프로그램 예제를 생성해 보아서 C++/CLI 구문으로 되어 있는 것을 확인했었는데요. 혹시나 싶어서 그때 생성한 C++ WinRT 예제를 다시 열어 보았습니다. MainPage.xaml.h 파일이 다음과 같이 나오더군요.

#pragma once

#include "pch.h"
#include "MainPage.g.h"

namespace Application3
{
    public ref class MainPage
    {
        public:
            MainPage();
            ~MainPage();
    };
}

전형적인 C++/CLI 구문이기 때문에 C#, VB.NET으로 만든 것에만 닷넷 런타임을 올리진 않았을 거라는 생각이 들었던 것입니다. 그래도 이번에는 확인을 위해 "Process Explorer"를 띄웠는데... 오호 ^^; clr.dll이 보이질 않습니다.

vcpp_winrt_1.png

마이크로소프트가 재미있는 구조를 선택했군요. C#과 VB.NET 언어로 만든 WinRT 프로그램은 닷넷과 병행할 수 있도록 만들고, C++/CLI 언어로 만든 WinRT 프로그램은 그렇지 않게 했습니다.

C++/CLI임에도 불구하고 닷넷에 의존하지 않는다는 것은 다음과 같은 구문이 빌드되지 않는다는 것과도 같습니다.

System::Diagnostics::Debug::WriteLine("TEST");

물론, 위의 구문이 컴파일되지 않는 이유에는 "System.dll" 참조가 없기 때문이기도 합니다. 그렇다면, 참조를 한번 해볼까요?

원래 Visual Studio 2010에서도 C++ 프로젝트에서는 System.dll 참조는 기본적으로 할 수 없습니다. 부가적으로, "Common Language Runtime Support (/clr)" 옵션을 준 후에야 이것이 가능한데요. 그래서 C++ WinRT 프로젝트에서도 /clr 옵션을 명시적으로 주었습니다. (/clr 옵션이 "General" 범주에서 찾을 수 있었는데, WinRT 프로젝트 유형에서는 "C/C++" 범주로 밀려났습니다.)

그러고 나서 빌드를 하니 다음과 같은 오류가 발생하면서 빌드가 안됩니다.

error D8016: '/clr' and '/ZW' command-line options are incompatible d:\...[생략]..\cl    Application3

새로 생긴 /ZW 옵션은 짐작하시겠지만 "Enable Widnows Run Time Extensions (/ZW)"입니다. 즉, C++/CLI에서는 WinRT 런타임과 닷넷 런타임은 서로 배타적인 사이가 된 것입니다.

한 가지 더 아쉬운 사실은, C#/VB.NET WinRT 프로젝트는 기존의 C#/VB.NET 라이브러리를 참조할 수 있지만, C++ WinRT 프로젝트는 .NET 라이브러리는 물론 기존의 C++/CLI 라이브러리 역시 참조를 할 수 없다는 것입니다. (혹시, 정식 버전에서는 바뀔 수 있을까요?)

엄밀히 분석해 보면, C++/CLI보다는 C#/VB.NET으로 만들어진 기존 닷넷 라이브러리가 압도적으로 많기 때문에 편의를 위해 C#/VB.NET 프로젝트에서는 닷넷 병행을 지원하게 된 것이 아닌가 싶은데요. 아무튼 닷넷 시대에 와서도 꿋꿋하게 C++을 사랑해서 C++/CLI로 프로그램을 코딩해 온 개발자들이 있다면 약간 기운 빠지는 사실이 아닌가 싶습니다.

그렇다고 C++ WinRT 프로젝트에서 C# 라이브러리를 아예 사용하지 못하는 것은 아니고 방법이 있긴 합니다. C# 프로젝트를 "Windows Metro style" 범주에 있는 "Class Library"로 생성하면 "Output type"으로 C/C++ 프로젝트에서도 참조가 가능한 "WinMD File"을 지정할 수 있습니다.

vcpp_winrt_2.png

불행히도 여기가 끝이 아닙니다. 이렇게 생성된 기본 Class1.cs 파일만 포함된 라이브러리를 빌드하면 다음과 같은 오류들이 발생합니다.

1. Type 'ClassLibrary3.Class1' is unsealed but is not enabled for composition. Either seal 'ClassLibrary3.Class1', or mark it with the System.Runtime.InteropServices.WindowsRuntime.EnableCompositionAttribute so that you can derive from it. To use the class from JavaScript, you must seal it. c:\...[생략]...\obj\Debug\ClassLibrary3.winmdobj ClassLibrary3


2. Unable to determine a default interface for runtime class 'ClassLibrary3.Class1'. The class does not implement any interfaces, and no interface was generated for it because it does not contain any public methods, properties, or events. c:\...[생략]...\obj\Debug\ClassLibrary3.winmdobj ClassLibrary3


첫 번째 빌드 오류를 해결하려면 다음과 같이 public으로 노출되는 클래스들에 대해 모두 'sealed' 예약어를 지정해야 합니다.

sealed public class Class1
{
}

sealed public class Class2
{
}

두 번째 오류를 해결하려면 역시 public으로 노출되는 모든 클래스들에 대해 'interface' 상속을 받도록 지정해야 합니다.

public interface IClass1
{
}

sealed public class Class1 : IClass1
{
}

sealed public class Class2 : IClass1
{
}

이 정도 제약이라면, 기존 C#/VB.NET을 C++용 WinRT 프로젝트에서 사용하기 위해 변형하는 것은 쉽진 않을 것 같습니다. 어쨌든 이렇게 제작된 C# 라이브러리를 C++ WinRT 프로젝트에서 참조하면 되는데, 그나마 다행이라면 프로세스에 clr.dll까지 올라온 것을 확인할 수 있습니다.

닷넷이 올라왔다면... 혹시 C++ WinRT 프로젝트에서 기존 C# 프로젝트를 사용하려는 경우, 해당 C# 프로젝트에서 필요한 부분만 노출시켜주는 별도의 WinMD C# 프로젝트를 만들어서 경유해 사용할 수 있지 않을까요? 넵. 가능합니다. ^^ 대신 지금의 Visual Studio 11 Developer Preview 버전에서는 WinMD C# 프로젝트에서 일반 닷넷 C# 프로젝트를 참조하려면 목록 상자에서 "회색"으로 표시됩니다. 그래도 직접 참조를 시도하면 성공은 하는데 솔루션 탐색기에서는 다음과 같이 잘못된 프로젝트 참조라고 경고합니다.

vcpp_winrt_3.png

상관없습니다. 빌드하고 실행하면 C++ WinRT 프로젝트에서 C# WinMD 프로젝트를 거쳐 기존의 C# 라이브러리에 있는 코드들이 정상적으로 실행됩니다.

Windows 8로 오면서 재미있는 상황이 하나 벌어졌군요. ^^ 예전에는 C# 프로젝트에서 C++/CLI를 경유해 기존 C/C++ 코드를 재사용하려고 했지만, 이제는 반대로 C++ WinRT 프로젝트에서 C# 코드를 재사용하기 위해 C# WinMD 프로젝트를 경유해야 하는군요. ^^

(끝을 맺기 전에, ^^ "wafe" 님의 좋은 의견 감사드립니다. 덕분에 이 정도까지 또 알게 되었습니다. ^^)




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

[연관 글]






[최초 등록일: ]
[최종 수정일: 7/10/2021]

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

비밀번호

댓글 작성자
 



2011-09-27 09시15분
"Enable Widnows Run Time Extensions" 옵션이 켜진 상태에서는 C++/CLI라는 이름 대신 C++/CX라고 불리는 것 같습니다. ^^

WinRT Reflection (C++/CX)
; http://stackoverflow.com/questions/7553273/winrt-reflection-c-cx
정성태
2011-10-06 01시08분
정성태

... 61  62  63  64  65  66  67  68  69  70  71  72  73  [74]  75  ...
NoWriterDateCnt.TitleFile(s)
12083정성태12/17/201922250Linux: 27. linux - lldb를 이용한 .NET Core 응용 프로그램의 메모리 덤프 분석 방법 [2]
12082정성태12/17/201920537오류 유형: 585. lsof: WARNING: can't stat() fuse.gvfsd-fuse file system
12081정성태12/16/201922388개발 환경 구성: 465. 로컬 PC에서 개발 중인 ASP.NET Core 웹 응용 프로그램을 다른 PC에서도 접근하는 방법 [5]
12080정성태12/16/201919532.NET Framework: 870. C# - 프로세스의 모든 핸들을 열람
12079정성태12/13/201921408오류 유형: 584. 원격 데스크톱(rdp) 환경에서 다중 또는 고용량 파일 복사 시 "Unspecified error" 오류 발생
12078정성태12/13/201921223Linux: 26. .NET Core 응용 프로그램을 위한 메모리 덤프 방법 [3]
12077정성태12/13/201920329Linux: 25. 자주 실행할 명령어 또는 초기 환경을 "~/.bashrc" 파일에 등록
12076정성태12/12/201918838디버깅 기술: 142. Linux - lldb 환경에서 sos 확장 명령어를 이용한 닷넷 프로세스 디버깅 - 배포 방법에 따른 차이
12075정성태12/11/201919626디버깅 기술: 141. Linux - lldb 환경에서 sos 확장 명령어를 이용한 닷넷 프로세스 디버깅
12074정성태12/10/201919278디버깅 기술: 140. windbg/Visual Studio - 값이 변경된 경우를 위한 정지점(BP) 설정(Data Breakpoint)
12073정성태12/10/201920850Linux: 24. Linux/C# - 실행 파일이 아닌 스크립트 형식의 명령어를 Process.Start로 실행하는 방법
12072정성태12/9/201917655오류 유형: 583. iisreset 수행 시 "No such interface supported" 오류
12071정성태12/9/201921159오류 유형: 582. 리눅스 디스크 공간 부족 및 safemode 부팅 방법
12070정성태12/9/201923082오류 유형: 581. resize2fs: Bad magic number in super-block while trying to open /dev/.../root
12069정성태12/2/201919473디버깅 기술: 139. windbg - x64 덤프 분석 시 메서드의 인자 또는 로컬 변수의 값을 확인하는 방법
12068정성태11/28/201928128디버깅 기술: 138. windbg와 Win32 API로 알아보는 Windows Heap 정보 분석 [3]파일 다운로드2
12067정성태11/27/201919538디버깅 기술: 137. 실제 사례를 통해 Debug Diagnostics 도구가 생성한 닷넷 웹 응용 프로그램의 성능 장애 보고서 설명 [1]파일 다운로드1
12066정성태11/27/201919189디버깅 기술: 136. windbg - C# PInvoke 호출 시 마샬링을 담당하는 함수 분석 - OracleCommand.ExecuteReader에서 OpsSql.Prepare2 PInvoke 호출 분석
12065정성태11/25/201917504디버깅 기술: 135. windbg - C# PInvoke 호출 시 마샬링을 담당하는 함수 분석파일 다운로드1
12064정성태11/25/201920404오류 유형: 580. HTTP Error 500.0/500.33 - ANCM In-Process Handler Load Failure
12063정성태11/21/201919356디버깅 기술: 134. windbg - RtlReportCriticalFailure로부터 parameters 정보 찾는 방법
12062정성태11/21/201918859디버깅 기술: 133. windbg - CoTaskMemFree/FreeCoTaskMem에서 발생한 덤프 분석 사례 - 두 번째 이야기
12061정성태11/20/201919294Windows: 167. CoTaskMemAlloc/CoTaskMemFree과 윈도우 Heap의 관계
12060정성태11/20/201920885디버깅 기술: 132. windbg/Visual Studio - HeapFree x64의 동작 분석
12059정성태11/20/201920044디버깅 기술: 131. windbg/Visual Studio - HeapFree x86의 동작 분석
12058정성태11/19/201920699디버깅 기술: 130. windbg - CoTaskMemFree/FreeCoTaskMem에서 발생한 덤프 분석 사례
... 61  62  63  64  65  66  67  68  69  70  71  72  73  [74]  75  ...