Microsoft MVP성태의 닷넷 이야기
VC++: 54. C++로 만든 WinRT 프로그램 [링크 복사], [링크+제목 복사],
조회: 33382
글쓴 사람
정성태 (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분
정성태

1  [2]  3  4  5  6  7  8  9  10  11  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
13893정성태2/27/20252225Linux: 115. eBPF (bpf2go) - ARRAY / HASH map 기본 사용법
13892정성태2/24/20252975닷넷: 2325. C# - PowerShell과 연동하는 방법파일 다운로드1
13891정성태2/23/20252498닷넷: 2324. C# - 프로세스의 성능 카운터용 인스턴스 이름을 구하는 방법파일 다운로드1
13890정성태2/21/20252317닷넷: 2323. C# - 프로세스 메모리 중 Private Working Set 크기를 구하는 방법(Win32 API)파일 다운로드1
13889정성태2/20/20253045닷넷: 2322. C# - 프로세스 메모리 중 Private Working Set 크기를 구하는 방법(성능 카운터, WMI) [1]파일 다운로드1
13888정성태2/17/20252483닷넷: 2321. Blazor에서 발생할 수 있는 async void 메서드의 부작용
13887정성태2/17/20253069닷넷: 2320. Blazor의 razor 페이지에서 code-behind 파일로 코드를 분리 및 DI 사용법
13886정성태2/15/20252572VS.NET IDE: 196. Visual Studio - Code-behind처럼 cs 파일을 그룹핑하는 방법
13885정성태2/14/20253232닷넷: 2319. ASP.NET Core Web API / Razor 페이지에서 발생할 수 있는 async void 메서드의 부작용
13884정성태2/13/20253504닷넷: 2318. C# - (async Task가 아닌) async void 사용 시의 부작용파일 다운로드1
13883정성태2/12/20253257닷넷: 2317. C# - Memory Mapped I/O를 이용한 PCI Configuration Space 정보 열람파일 다운로드1
13882정성태2/10/20252577스크립트: 70. 파이썬 - oracledb 패키지 연동 시 Thin / Thick 모드
13881정성태2/7/20252824닷넷: 2316. C# - Port I/O를 이용한 PCI Configuration Space 정보 열람파일 다운로드1
13880정성태2/5/20253167오류 유형: 947. sshd - Failed to start OpenSSH server daemon.
13879정성태2/5/20253392오류 유형: 946. Ubuntu - N: Updating from such a repository can't be done securely, and is therefore disabled by default.
13878정성태2/3/20253182오류 유형: 945. Windows - 최대 절전 모드 시 DRIVER_POWER_STATE_FAILURE 발생 (pacer.sys)
13877정성태1/25/20253236닷넷: 2315. C# - PCI 장치 열거 (레지스트리, SetupAPI)파일 다운로드1
13876정성태1/25/20253692닷넷: 2314. C# - ProcessStartInfo 타입의 Arguments와 ArgumentList파일 다운로드1
13875정성태1/24/20253131스크립트: 69. 파이썬 - multiprocessing 패키지의 spawn 모드로 동작하는 uvicorn의 workers
13874정성태1/24/20253542스크립트: 68. 파이썬 - multiprocessing Pool의 기본 프로세스 시작 모드(spawn, fork)
13873정성태1/23/20252969디버깅 기술: 217. WinDbg - PCI 장치 열거파일 다운로드1
13872정성태1/23/20252881오류 유형: 944. WinDbg - 원격 커널 디버깅이 연결은 되지만 Break (Ctrl + Break) 키를 눌러도 멈추지 않는 현상
13871정성태1/22/20253292Windows: 278. Windows - 윈도우를 다른 모니터 화면으로 이동시키는 단축키 (Window + Shift + 화살표)
13870정성태1/18/20253731개발 환경 구성: 741. WinDbg - 네트워크 커널 디버깅이 가능한 NIC 카드 지원 확대
13869정성태1/18/20253454개발 환경 구성: 740. WinDbg - _NT_SYMBOL_PATH 환경 변수에 설정한 경로로 심벌 파일을 다운로드하지 않는 경우
13868정성태1/17/20253109Windows: 277. Hyper-V - Windows 11 VM의 Enhanced Session 모드로 로그인을 할 수 없는 문제
1  [2]  3  4  5  6  7  8  9  10  11  12  13  14  15  ...