Microsoft MVP성태의 닷넷 이야기
VC++: 54. C++로 만든 WinRT 프로그램 [링크 복사], [링크+제목 복사],
조회: 33461
글쓴 사람
정성태 (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)
12208정성태4/12/202015955Linux: 29. 리눅스 환경에서 C/C++ 프로그램이 Segmentation fault 에러가 발생한 경우
12207정성태4/2/202015751스크립트: 19. Windows PowerShell의 NonInteractive 모드
12206정성태4/2/202018405오류 유형: 613. 파일 잠금이 바로 안 풀린다면? - The process cannot access the file '...' because it is being used by another process.
12205정성태4/2/202015062스크립트: 18. Powershell에서는 cmd.exe의 명령어를 지원하진 않습니다.
12204정성태4/1/202015074스크립트: 17. Powershell 명령어에 ';' (semi-colon) 문자가 포함된 경우
12203정성태3/18/202017900오류 유형: 612. warning: 'C:\ProgramData/Git/config' has a dubious owner: '...'.
12202정성태3/18/202021171개발 환경 구성: 486. .NET Framework 프로젝트를 위한 GitLab CI/CD Runner 구성
12201정성태3/18/202018401오류 유형: 611. git-credential-manager.exe: Using credentials for username "Personal Access Token". [1]
12200정성태3/18/202018506VS.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/202016146오류 유형: 610. C# - CodeDomProvider 사용 시 Unhandled Exception: System.IO.DirectoryNotFoundException: Could not find a part of the path '...\f2_6uod0.tmp'.
12198정성태3/17/202019524오류 유형: 609. SQL 서버 접속 시 "Cannot open user default database. Login failed."
12197정성태3/17/202018774VS.NET IDE: 144. .NET Core 콘솔 응용 프로그램을 배포(publish) 시 docker image 자동 생성 - 두 번째 이야기 [1]
12196정성태3/17/202015933오류 유형: 608. The ServicedComponent being invoked is not correctly configured (Use regsvcs to re-register).
12195정성태3/16/202018257.NET Framework: 902. C# - 프로세스의 모든 핸들을 열람 - 세 번째 이야기
12194정성태3/16/202020983오류 유형: 607. PostgreSQL - Npgsql.NpgsqlException: sorry, too many clients already
12193정성태3/16/202017883개발 환경 구성: 485. docker - SAP Adaptive Server Enterprise 컨테이너 실행 [1]
12192정성태3/14/202019902개발 환경 구성: 484. docker - Sybase Anywhere 16 컨테이너 실행
12191정성태3/14/202021023개발 환경 구성: 483. docker - OracleXE 컨테이너 실행 [1]
12190정성태3/14/202015585오류 유형: 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/202021175개발 환경 구성: 482. Facebook OAuth 처리 시 상태 정보 전달 방법과 "유효한 OAuth 리디렉션 URI" 설정 규칙
12188정성태3/13/202026009Windows: 169. 부팅 시점에 실행되는 chkdsk 결과를 확인하는 방법
12187정성태3/12/202015538오류 유형: 605. NtpClient was unable to set a manual peer to use as a time source because of duplicate error on '...'.
12186정성태3/12/202017390오류 유형: 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/202017964오류 유형: 603. The browser service was unable to retrieve a list of servers from the browser master...
12184정성태3/11/202019892오류 유형: 602. Automatic certificate enrollment for local system failed (0x800706ba) The RPC server is unavailable. [3]
12183정성태3/11/202017694오류 유형: 601. Warning: DsGetDcName returned information for \\[...], when we were trying to reach [...].
... 61  62  63  64  65  66  67  68  [69]  70  71  72  73  74  75  ...