일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | ||||
4 | 5 | 6 | 7 | 8 | 9 | 10 |
11 | 12 | 13 | 14 | 15 | 16 | 17 |
18 | 19 | 20 | 21 | 22 | 23 | 24 |
25 | 26 | 27 | 28 | 29 | 30 | 31 |
- Invalid credentials
- Kotlin
- 인증문제해결
- 예제
- 디버깅
- 리액트 네이티브
- gradle
- EC2
- sourcetree
- react
- bitbucket
- Git
- Android
- flutter
- VisualStudio
- 빌드 오류
- 데이터바인딩
- aPK
- git인증
- 안드로이드 스튜디오
- 안드로이드
- 리액트
- WPF
- 뒤로가기 안됨
- 설정
- AWS
- react-native
- 안됨
- not working
- 개발환경설정
- Today
- Total
물에 살고싶은 개발자
🛠 C++/CLI 프로젝트에서 갑자기 나타난 IServiceProvider 에러 해결 본문
"헤더파일도 없는데 왜 이런 에러가 나죠?"
저도 그랬습니다. 직접 겪은 고통을 나누며 정리해봅니다.
💥 문제 상황
최근 어떤 외부 장치 SDK를 C++/CLI로 래핑하여 WPF 프로젝트와 연동하는 작업을 진행하던 중, 전혀 예상하지 못한 IServiceProvider 관련 컴파일 오류가 발생했습니다.
발생한 오류 목록은 다음과 같았습니다:
E0266: 'IServiceProvider'이(가) 모호합니다.
C3699: '^': 'IServiceProvider' 형식에 이 간접 참조를 사용할 수 없습니다.
C2371: 'IServiceProvider': 재정의, 기본 형식이 다릅니다.
C++/CLI ref 클래스 또는 인터페이스 클래스에 대한 일반 포인터는 사용할 수 없습니다.
🧪 문제의 이상한 점
✅ 중요한 점은 다음과 같습니다:
- *urlmon.h, servprov.h*는 제 프로젝트의 어느 위치에도 포함되어 있지 않았습니다.
- 제가 사용한 외부 SDK의 헤더파일을 전부 뒤져도 IServiceProvider 라는 이름은 존재하지 않았습니다.
- #using <mscorlib.dll>은 사용하지 않았고, 캐시 초기화도 시도했지만 문제는 여전히 발생했습니다.
즉, 존재하지도 않는 헤더의 내용이 컴파일 에러를 유발하고 있었던 겁니다.
🔍 원인 분석
결론부터 말하자면, C++/CLI 환경에서는 using namespace System; 선언으로 인해 .NET의 System.IServiceProvider 타입이 전역에서 노출됩니다.
이런 상태에서 Visual Studio 내부 또는 컴파일러의 메타데이터 처리 과정에서 COM 계열의 IServiceProvider가 자동으로 참조되거나 추론되는 경우가 있어, 해당 타입이 프로젝트 내에 명시적으로 존재하지 않더라도 오류가 발생할 수 있습니다.
✅ 해결 방법: #include 순서 조정!
기존 코드에서 using namespace 선언을 먼저 한 뒤에 SDK 관련 헤더들을 include하고 있었는데, 순서를 바꾸는 것만으로 문제가 해결되었습니다.
🔁 수정 전
using namespace System;
using namespace msclr::interop;
#include "SDK관련헤더.h"
#include "CrDeviceProperty.h"
...
✅ 수정 후 (해결됨)
#include "SDK관련헤더.h"
#include "CrDeviceProperty.h"
...
using namespace System;
using namespace msclr::interop;
💡 핵심 포인트
- #include는 타입 정의를 먼저 불러오기 때문에 네임스페이스 해석 시 우선순위에 영향을 줍니다.
- System::IServiceProvider가 먼저 선언되고 나면, 정체불명의 COM 기반 IServiceProvider와 충돌할 가능성이 줄어듭니다.
🎯 마무리하며
이번 문제는 비교적 간단한 해결 방법이 있었지만, 원인을 파악하는 데 적잖은 시간을 허비했습니다. C++/CLI는 .NET과 C++의 중간지대인 만큼, 양쪽의 컴파일 규칙을 모두 알아야 이런 함정을 피할 수 있다는 걸 다시 느꼈습니다.
헤더가 없다고 안심하지 마세요. Visual Studio는 내부적으로 여러 메타데이터와 COM 인터페이스를 함께 처리하기 때문에, 눈에 보이지 않는 헤더의 망령(?)이 오류를 유발할 수도 있습니다.