Microsoft MVP성태의 닷넷 이야기
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
(연관된 글이 2개 있습니다.)

C# - Unhandled exception. System.Runtime.InteropServices.COMException (0x800080A5)

해당 오류를 재현하기 위해, 지난 글에서 실습한 (.NET 8로 만든) C# COM DLL을,

.NET Core 3/5+ 기반의 COM Server를 기존의 regasm처럼 등록하는 방법
; https://www.sysnet.pe.kr/2/0/13459

using System.Runtime.InteropServices;
using System;
using System.Windows.Forms;

namespace ClassLibrary1
{
    [ComVisible(true)]
    [Guid("23172f2f-a3d3-4180-97ae-7805f74a5a46")]
    [InterfaceType(ComInterfaceType.InterfaceIsDual)]
    public interface IMyNetCode
    {
        void ShowDialog();
    }

    [ComVisible(true)]
    [Guid("41AC8568-9230-4E63-B7C5-CAAD997EE207")]
    public class MyNetCode : IMyNetCode
    {
        public void ShowDialog()
        {
            string platform = (IntPtr.Size == 4) ? "x86" : "x64";
            MessageBox.Show($" {RuntimeEnvironment.GetSystemVersion()}: {platform}");
        }
    }
}

동일한 .NET 8 C# Console Application에서 활성화시켜 실행하면,

using ClassLibrary1;
using System.Runtime.InteropServices;

namespace ConsoleApp1
{
    internal class Program
    {
        static void Main(string[] args)
        {
            Guid guid = new Guid("{41AC8568-9230-4E63-B7C5-CAAD997EE207}");
            Type type = Type.GetTypeFromCLSID(guid);

            object comObject = Activator.CreateInstance(type); // 예외 발생
        }
    }
}

이런 오류가 발생합니다.

C:\temp\net45_from_net80\x64\Debug> ConsoleApp1.exe
Unhandled exception. System.Runtime.InteropServices.COMException (0x800080A5): Retrieving the COM class factory for component with CLSID {41AC8568-9230-4E63-B7C5-CAAD997EE207} failed due to the following error: 800080a5 0x800080A5.
   at System.RuntimeTypeHandle.AllocateComObject(Void* pClassFactory)
   at System.RuntimeType.CreateInstanceDefaultCtor(Boolean publicOnly, Boolean wrapExceptions)
   at ConsoleApp1.Program.Main(String[] args) in C:\temp\net45_from_net80\ConsoleApp1\Program.cs:line 16

오류 코드가 0x800080A5 (-2147450715)인데, 검색해도 잘 안 나오는 꽤나 낯선 오류입니다. ^^;




원인은 프로젝트 설정에서 기인합니다. C# COM DLL 측에서 Windows Forms의 MessageBox.Show를 사용했기 때문에 해당 프로젝트는 다음과 같이 구축한 상태인데요,

<Project Sdk="Microsoft.NET.Sdk">
    <PropertyGroup>
        <TargetFramework>net8.0-windows</TargetFramework>
        <OutputType>Library</OutputType>
        <UseWindowsForms>true</UseWindowsForms>

        <EnableComHosting>true</EnableComHosting>
        <EnableRegFreeCom>true</EnableRegFreeCom>

        <BaseOutputPath>..\x64</BaseOutputPath>
        <AppendTargetFrameworkToOutputPath>false</AppendTargetFrameworkToOutputPath>
        <Platform>x64</Platform>

    </PropertyGroup>
    <PropertyGroup>
        <SignAssembly>true</SignAssembly>
    </PropertyGroup>
    <PropertyGroup>
        <AssemblyOriginatorKeyFile>test.snk</AssemblyOriginatorKeyFile>
    </PropertyGroup>

    <Target Name="PostBuild" AfterTargets="PostBuildEvent">
        <Exec Command="dscom tlbexport &quot;$(TargetPath)&quot;" />
    </Target>

    <ItemGroup Condition="Exists('$(AssemblyName).tlb')">
        <ComHostTypeLibrary Include="$(AssemblyName).tlb" Id="1"/>
    </ItemGroup>
</Project>

따라서 호출 측에서도, 비록 Windows Forms 관련 코드를 직접적으로 사용하지 않았지만 마찬가지로 UseWindowsForms 옵션을 추가해야 합니다.

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
      <TargetFramework>net8.0-windows</TargetFramework>
      <OutputType>Exe</OutputType>
      <UseWindowsForms>true</UseWindowsForms>

      <BaseOutputPath>..\x64</BaseOutputPath>
      <AppendTargetFrameworkToOutputPath>false</AppendTargetFrameworkToOutputPath>
      <Platform>x64</Platform>
      
      <ApplicationManifest>app.manifest</ApplicationManifest>

  </PropertyGroup>

</Project>

이후 다시 실행하면, 정상적으로 실행이 됩니다. 그런데, 여기서 재미있는 건, COM Client 역할을 하는 측의 프로젝트를 그냥 일반적인 .NET Framework Console Application으로 만들거나, 단순히 C/C++ 클라이언트로 만든 경우에는 저런 설정과 무관하게 잘 실행이 된다는 점입니다.




한 가지 더 재미있는 점이 있는데요, COM Server와 클라이언트의 TargetFramework을 아래와 같이 바꾸면,

[C# COM 서버 역할을 하는 ClassLibrary1]
    <TargetFramework>net7.0-windows</TargetFramework>
    <UseWindowsForms>true</UseWindowsForms>

[C# COM Client 역할을 하는 ConsoleApp1]
    <TargetFramework>net7.0-windows</TargetFramework>
    <UseWindowsForms>true</UseWindowsForms>

당연히 잘 동작하겠지만, RuntimeEnvironment.GetSystemVersion()의 결괏값이 "v4.0.30319"라고 나온다는 점입니다. .NET 8 환경에서는 정상적으로 "v8.0.0"이 나왔던 반면, .NET 7인 경우에는 마치 Desktop용의 .NET Framework을 가리키는 버전이 나오는 것입니다.

아울러, 다음과 같이 버전이 서로 일치하지 않는 경우에도,

[C# COM 서버 역할을 하는 ClassLibrary1]
    <TargetFramework>net7.0-windows</TargetFramework>
    <UseWindowsForms>true</UseWindowsForms>

[C# COM Client 역할을 하는 ConsoleApp1]
    <TargetFramework>net8.0-windows</TargetFramework>
    <UseWindowsForms>true</UseWindowsForms>

혹은 반대로 하는 경우에도,

[C# COM 서버 역할을 하는 ClassLibrary1]
    <TargetFramework>net8.0-windows</TargetFramework>
    <UseWindowsForms>true</UseWindowsForms>

[C# COM Client 역할을 하는 ConsoleApp1]
    <TargetFramework>net7.0-windows</TargetFramework>
    <UseWindowsForms>true</UseWindowsForms>

이유는 알 수 없지만, 동일하게 "0x800080A5" 오류가 발생합니다. (제가 테스트한 것은 .NET 5부터 한 것인데, 모두 COM 서버와 클라이언트의 프로젝트 버전이 동일해야 합니다. 아마도 이전의 .NET Core 런타임에서도 마찬가지 현상이 있을 듯합니다.) 이런 조합의 수까지 고려해 테스트를 하려면, 마이크로소프트도 참 골치 아플 것 같습니다. ^^;

(2023-12-02 업데이트) 정식 문서에 보면,
Hosting layer error and exit codes
; https://github.com/dotnet/runtime/blob/main/docs/design/features/host-error-codes.md

0x800080a5에 대해,

Error returned by hostfxr_initialize_for_runtime_config if the component being initialized requires framework which is not available or incompatible with the frameworks loaded by the runtime already in the process. For example trying to load a component which requires 3.0 into a process which is already running a 2.0 runtime.

라는 설명이 나오는군요. ^^ 결국 지난번의 결론에 해당합니다.

(첨부 파일은 이 글의 예제 코드를 포함합니다.)




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

[연관 글]






[최초 등록일: ]
[최종 수정일: 12/2/2023]

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

비밀번호

댓글 작성자
 




... [16]  17  18  19  20  21  22  23  24  25  26  27  28  29  30  ...
NoWriterDateCnt.TitleFile(s)
13242정성태2/4/20234599디버깅 기술: 189. ASP.NET Web Application (.NET Framework) 프로젝트의 숨겨진 예외 - System.UnauthorizedAccessException
13241정성태2/3/20234036디버깅 기술: 188. ASP.NET Web Application (.NET Framework) 프로젝트의 숨겨진 예외 - System.IO.FileNotFoundException
13240정성태2/1/20234183디버깅 기술: 187. ASP.NET Web Application (.NET Framework) 프로젝트의 숨겨진 예외 - System.Web.HttpException
13239정성태2/1/20233868디버깅 기술: 186. C# - CacheDependency의 숨겨진 예외 - System.Web.HttpException
13238정성태1/31/20236000.NET Framework: 2092. IIS 웹 사이트를 TLS 1.2 또는 TLS 1.3 프로토콜로만 운영하는 방법
13237정성태1/30/20235697.NET Framework: 2091. C# - 웹 사이트가 어떤 버전의 TLS/SSL을 지원하는지 확인하는 방법
13236정성태1/29/20235189개발 환경 구성: 663. openssl을 이용해 인트라넷 IIS 사이트의 SSL 인증서 생성
13235정성태1/29/20234826개발 환경 구성: 662. openssl - 윈도우 환경의 명령행에서 SAN 적용하는 방법
13234정성태1/28/20235909개발 환경 구성: 661. dnSpy를 이용해 소스 코드가 없는 .NET 어셈블리의 코드를 변경하는 방법 [1]
13233정성태1/28/20237284오류 유형: 840. C# - WebClient로 https 호출 시 "The request was aborted: Could not create SSL/TLS secure channel" 예외 발생
13232정성태1/27/20234950스크립트: 43. uwsgi의 --processes와 --threads 옵션
13231정성태1/27/20233961오류 유형: 839. python - TypeError: '...' object is not callable
13230정성태1/26/20234340개발 환경 구성: 660. WSL 2 내부로부터 호스트 측의 네트워크로 UDP 데이터가 1개의 패킷으로만 제한되는 문제
13229정성태1/25/20235374.NET Framework: 2090. C# - UDP Datagram의 최대 크기
13228정성태1/24/20235482.NET Framework: 2089. C# - WMI 논리 디스크가 속한 물리 디스크의 정보를 얻는 방법 [2]파일 다운로드1
13227정성태1/23/20235144개발 환경 구성: 659. Windows - IP MTU 값을 바꿀 수 있을까요? [1]
13226정성태1/23/20234824.NET Framework: 2088. .NET 5부터 지원하는 GetRawSocketOption 사용 시 주의할 점
13225정성태1/21/20234019개발 환경 구성: 658. Windows에서 실행 중인 소켓 서버를 다른 PC 또는 WSL에서 접속할 수 없는 경우
13224정성태1/21/20234453Windows: 221. Windows - Private/Public/Domain이 아닌 네트워크 어댑터 단위로 방화벽을 on/off하는 방법
13223정성태1/20/20234612오류 유형: 838. RDP 연결 오류 - The two computers couldn't connect in the amount of time allotted
13222정성태1/20/20234312개발 환경 구성: 657. WSL - DockerDesktop.vhdx 파일 위치를 옮기는 방법
13221정성태1/19/20234474Linux: 57. C# - 리눅스 프로세스 메모리 정보파일 다운로드1
13220정성태1/19/20234592오류 유형: 837. NETSDK1045 The current .NET SDK does not support targeting .NET ...
13219정성태1/18/20234199Windows: 220. 네트워크의 인터넷 접속 가능 여부에 대한 판단 기준
13218정성태1/17/20234096VS.NET IDE: 178. Visual Studio 17.5 (Preview 2) - 포트 터널링을 이용한 웹 응용 프로그램의 외부 접근 허용
13217정성태1/13/20234714디버깅 기술: 185. windbg - 64비트 운영체제에서 작업 관리자로 뜬 32비트 프로세스의 덤프를 sos로 디버깅하는 방법
... [16]  17  18  19  20  21  22  23  24  25  26  27  28  29  30  ...