Microsoft MVP성태의 닷넷 이야기
VC++: 54. C++로 만든 WinRT 프로그램 [링크 복사], [링크+제목 복사],
조회: 33478
글쓴 사람
정성태 (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)
12285정성태8/4/202018417오류 유형: 635. 윈도우 10 업데이트 - 0xc1900209 [2]
12284정성태8/4/202017807디버깅 기술: 169. Hyper-V의 VM에 대한 메모리 덤프를 뜨는 방법
12283정성태8/3/202018657디버깅 기술: 168. windbg - 필터 드라이버 확인하는 확장 명령어(!fltkd) [2]
12282정성태8/2/202016523디버깅 기술: 167. windbg 디버깅 사례: AppDomain 간의 static 변수 사용으로 인한 crash (2)
12281정성태8/2/202020151개발 환경 구성: 500. (PDB 연결이 없는) DLL의 소스 코드 디버깅을 dotPeek 도구로 해결하는 방법
12280정성태8/2/202018288오류 유형: 634. 오라클 (평생) 무료 클라우드 VM 생성 후 SSH 접속 시 키 오류 발생 [2]
12279정성태7/29/202020008개발 환경 구성: 499. 닷넷에서 접근해보는 InterSystems의 Cache 데이터베이스파일 다운로드1
12278정성태7/23/202016616VS.NET IDE: 149. ("Binary was not built with debug information" 상태로) 소스 코드 디버깅이 안되는 경우
12277정성태7/23/202018587개발 환경 구성: 498. DEVPATH 환경 변수의 사용 예 - .NET Reflector의 (PDB 연결이 없는) DLL의 소스 코드 디버깅
12276정성태7/23/202017949.NET Framework: 930. 개발자를 위한 닷넷 어셈블리 바인딩 - DEVPATH 환경 변수
12275정성태7/22/202020163개발 환경 구성: 497. 닷넷에서 접근해보는 InterSystems의 IRIS Data Platform 데이터베이스파일 다운로드1
12274정성태7/21/202019504개발 환경 구성: 496. Azure - Blob Storage Account의 Location 이전 방법 [1]파일 다운로드1
12273정성태7/18/202022241개발 환경 구성: 495. Azure - Location이 다른 웹/DB 서버의 경우 발생하는 성능 하락
12272정성태7/16/202015448.NET Framework: 929. (StrongName의 버전 구분이 필요 없는) .NET Core 어셈블리 바인딩 규칙 [2]파일 다운로드1
12271정성태7/16/202018348.NET Framework: 928. .NET Framework의 Strong-named 어셈블리 바인딩 (2) - 런타임에 바인딩 리디렉션파일 다운로드1
12270정성태7/16/202019030오류 유형: 633. SSL_CTX_use_certificate_file - error:140AB18F:SSL routines:SSL_CTX_use_certificate:ee key too small
12269정성태7/16/202016266오류 유형: 632. .NET Core 웹 응용 프로그램 - The process was terminated due to an unhandled exception.
12268정성태7/15/202018869오류 유형: 631. .NET Core 웹 응용 프로그램 오류 - HTTP Error 500.35 - ANCM Multiple In-Process Applications in same Process
12267정성태7/15/202020953.NET Framework: 927. C# - 윈도우 프로그램에서 Credential Manager를 이용한 보안 정보 저장파일 다운로드1
12266정성태7/14/202017917오류 유형: 630. 사용자 계정을 지정해 CreateService API로 서비스를 등록한 경우 "Error 1069: The service did not start due to a logon failure." 오류발생
12265정성태7/10/202016742오류 유형: 629. Visual Studio - 웹 애플리케이션 실행 시 "Unable to connect to web server 'IIS Express'." 오류 발생
12264정성태7/9/202028038오류 유형: 628. docker: Error response from daemon: Conflict. The container name "..." is already in use by container "...".
12261정성태7/9/202019302VS.NET IDE: 148. 윈도우 10에서 .NET Core 응용 프로그램을 리눅스 환경에서 실행하는 2가지 방법 - docker, WSL 2 [5]
12260정성태7/8/202017111.NET Framework: 926. C# - ETW를 이용한 ThreadPool 스레드 감시파일 다운로드1
12259정성태7/8/202016345오류 유형: 627. nvlddmkm.sys의 BAD_POOL_HEADER BSOD 문제 [1]
12258정성태7/8/202020163기타: 77. DataDog APM 간략 소개
... 61  62  63  64  65  [66]  67  68  69  70  71  72  73  74  75  ...