Microsoft MVP성태의 닷넷 이야기
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 
(연관된 글이 5개 있습니다.)
(시리즈 글이 5개 있습니다.)
.NET Framework: 318. gacutil.exe로 어셈블리 등록 시 시스템 변경 사항
; https://www.sysnet.pe.kr/2/0/1285

.NET Framework: 319. regasm.exe로 어셈블리 등록 시 시스템 변경 사항 (1) - .NET 2.0 + x86/x64/AnyCPU
; https://www.sysnet.pe.kr/2/0/1286

.NET Framework: 320. regasm.exe로 어셈블리 등록 시 시스템 변경 사항 (2) - .NET 4.0 + .NET 2.0
; https://www.sysnet.pe.kr/2/0/1287

.NET Framework: 321. regasm.exe로 어셈블리 등록 시 시스템 변경 사항 (3) - Type Library
; https://www.sysnet.pe.kr/2/0/1288

.NET Framework: 322. regsvcs.exe로 어셈블리 등록 시 시스템 변경 사항
; https://www.sysnet.pe.kr/2/0/1289




regasm.exe로 어셈블리 등록 시 시스템 변경 사항 (1) - .NET 2.0 + x86/x64/AnyCPU

regasm.exe는 .NET 어셈블리를 COM 개체로 등록해 주는 역할을 합니다. 그래서, C# 클래스를 C/C++에서 COM 개체로써 활성화 시켜 접근할 수 있기 때문에 Interop 차원에서 유용하게 쓸 수 있는데요.

regasm.exe를 사용할 때 알고 계셔야 하는 것이 바로 COM 개체의 위치가 레지스트리에 있다는 점입니다. 왜냐하면 64비트 운영체제에서는 COM 개체 등록 위치가 플랫폼에 따라 다음과 같이 바뀌기 때문입니다.

x64: HKEY_CLASSES_ROOT\CLSID
x86: HKEY_CLASSES_ROOT\Wow6432Node\CLSID

이번에도 환경 테스트를 위해 프로젝트를 구성해 볼 텐데요. 편의상 지난번 gacutil.exe를 설명할 때 첨부한 코드를 변경해 보겠습니다. 그리 많은 수정은 아니고, 단지 Guid 특성 추가 및 assembly 레벨로 ComVisible 특성을 true로 바꾼 후 각각 x86/x64로 빌드해 주는 것이 끝입니다.

[assembly: ComVisible(true)]

namespace ClassLibraryAsAdmin
{
    [System.Runtime.InteropServices.Guid("41AC8568-9230-4E63-B7C5-CAAD997EE207")]
    public class AdminCode
    {
        public void SetRegistryValue()
        {
            if (IntPtr.Size == 4)
            {
                Console.Write("x86 ");
            }
            else
            {
                Console.Write("x64 ");
            }

            Console.WriteLine(".NET Framework: " + Environment.Version.ToString());
        }
    }
}

gacutil.exe의 경우에는 등록 기준을 판가름하는 것이 해당 C# DLL의 ".NET Framework" 버전이었는데요. 하지만 regasm.exe의 경우에는 COM 개체가 x86/x64에 따라 등록 위치가 달라지는 반면 C# DLL 자체는 "AnyCPU"로도 빌드될 수 있으므로 왠지 구분 단계가 모호해집니다. 그래서 DLL 단계에서 구분이 안 되기 때문에, 해당 DLL을 등록해 주는 regasm.exe 자체의 플랫폼에 따라 등록 위치가 달라진다는 특징을 갖게 됩니다.

결국 다음과 같이 4가지 상황으로 나뉩니다.

x86 + .NET 2.0: %windir%\Microsoft.NET\Framework\v2.0.50727\regasm.exe
x64 + .NET 2.0: %windir%\Microsoft.NET\Framework64\v2.0.50727\regasm.exe

x86 + .NET 4.0: %windir%\Microsoft.NET\Framework\v4.0.30319\regasm.exe
x64 + .NET 4.0: %windir%\Microsoft.NET\Framework64\v4.0.30319\regasm.exe

일단, x86 .NET 2.0 DLL을 .NET 2.0의 gacutil + x86 regasm으로 처리하는 경우를 볼까요?

gacutil.exe /i ClassLibraryAsAdmin.dll
Microsoft (R) .NET Global Assembly Cache Utility.  Version 3.5.30729.1
Copyright (c) Microsoft Corporation.  All rights reserved.

Assembly successfully added to the cache

C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\regasm.exe ClassLibraryAsAdmin.dll
Microsoft (R) .NET Framework Assembly Registration Utility 2.0.50727.3053
Copyright (C) Microsoft Corporation 1998-2004.  All rights reserved.

Types registered successfully

이로 인해 변경된 레지스트리를 보면 다음과 같고,

HKEY_CLASSES_ROOT\ClassLibraryAsAdmin.AdminCode

HKEY_CLASSES_ROOT\Wow6432Node\ClassLibraryAsAdmin.AdminCode
HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{41AC8568-9230-4E63-B7C5-CAAD997EE207}

생성된 GAC 경로는 아래와 같습니다.

C:\WINDOWS\assembly\GAC_32\ClassLibraryAsAdmin\1.0.0.0__465ff3ec4fc809d7\ClassLibraryAsAdmin.dll

보시는 것처럼, "ProgId"의 경우에는 (쓸데없이) x86/x64에 모두 등록된 반면, CLSID는 x86에만 등록되어 있습니다. 이것이 등록에 사용한 regasm.exe가 x86인 경우의 결과입니다.

실제로 등록된 C# COM 개체를 다음과 같이 활성화하는 테스트를 거치면,

Guid guid = new Guid("{41AC8568-9230-4E63-B7C5-CAAD997EE207}");
Type type = Type.GetTypeFromCLSID(guid);

object comObject = Activator.CreateInstance(type);
AdminCode adminCode = comObject as AdminCode;
adminCode.TestMethod();

x86 EXE 프로세스에서는 정상적으로 실행이 되지만, x64 EXE에서는 아래와 같은 오류를 발생합니다.

Unhandled Exception: System.Runtime.InteropServices.COMException (0x80040154): Retrieving the COM class factory for component with CLSID {41AC8568-9230-4E63-B7C5-CAAD997EE207} failed due to the following error: 80040154.
   at System.RuntimeTypeHandle.CreateInstance(RuntimeType type, Boolean publicOnly, Boolean noCheck, Boolean& canBeCached, RuntimeMethodHandle& ctor, Boolean& bNeedSecurityCheck)
   at System.RuntimeType.CreateInstanceSlow(Boolean publicOnly, Boolean fillCache)
   at System.RuntimeType.CreateInstanceImpl(Boolean publicOnly, Boolean skipVisibilityChecks, Boolean fillCache)
   at System.Activator.CreateInstance(Type type, Boolean nonPublic)
   at ConsoleApplication1.Program.Main(String[] args) in d:\...[생략]...\ConsoleApplication1\Program.cs:line 19

물론, 위의 코드를 CLSID가 아닌 ProgId로 테스트하는 것도 가능합니다.

Type type = Type.GetTypeFromProgID("ClassLibraryAsAdmin.AdminCode");

object comObject = Activator.CreateInstance(type);
AdminCode adminCode = comObject as AdminCode;
adminCode.TestMethod();

결과는 CLSID로 활성화한 경우와 다르지 않습니다.

자, 이제 그럼 반대로 해보면, x64 C# DLL을 gacutil + x64 regasm.exe로 등록하면 레지스트리와 파일은 각각 다음과 같이 설정됩니다.

HKEY_CLASSES_ROOT\ClassLibraryAsAdmin.AdminCode
HKEY_CLASSES_ROOT\CLSID\{41AC8568-9230-4E63-B7C5-CAAD997EE207}

HKEY_CLASSES_ROOT\Wow6432Node\ClassLibraryAsAdmin.AdminCode

C:\WINDOWS\assembly\GAC_64\ClassLibraryAsAdmin\1.0.0.0__465ff3ec4fc809d7\ClassLibraryAsAdmin.dll

x86과 유사하게 등록이 이뤄진 것을 확인할 수 있는데요. 마찬가지로, ProgId는 x86/x64에 모두 등록되었지만 CLSID는 x64에만 등록되었고, x64 EXE에서는 정상적으로 C# COM DLL을 사용할 수 있는 반면 x86 EXE에서는 System.Runtime.InteropServices.COMException이 발생합니다.

여기까지는, 그런대로 우리가 예상했던 결과와 크게 다르지 않습니다.




그렇다면, C# DLL을 "AnyCPU"로 두고 x86/x64 EXE 모두에서 정상적으로 활성화하고 싶다면 어떻게 해야 할까요? 일단, 해당 DLL을 x86 regasm.exe로 등록하면 x86 DLL을 등록했을 때와 동일한 레지스트리 값들만 설정이 됩니다.

HKEY_CLASSES_ROOT\ClassLibraryAsAdmin.AdminCode

HKEY_CLASSES_ROOT\Wow6432Node\ClassLibraryAsAdmin.AdminCode
HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{41AC8568-9230-4E63-B7C5-CAAD997EE207}

물론, gacutil은 정상적으로 플랫폼에 무관한게 GAC_MSIL로 등록이 됩니다.

C:\WINDOWS\assembly\GAC_MSIL\ClassLibraryAsAdmin\1.0.0.0__465ff3ec4fc809d7\ClassLibraryAsAdmin.dll

이런 레지스트리 값으로는 당연히 x86 EXE 프로세스에서만 정상적으로 C# COM 개체를 활성화할 수 있고, x64 EXE 프로세스에서는 System.Runtime.InteropServices.COMException 예외가 발생합니다. 문제는, x64용 CLSID가 등록되지 않았기 때문인데 이를 해결하기 위해 "HKEY_CLASSES_ROOT\CLSID\{41AC8568-9230-4E63-B7C5-CAAD997EE207}" 경로에 해당하는 레지스트리 값들을 수작업으로 맞춰주면 해결이 됩니다.

예를 들면, 다음과 같은 식의 레지스트리 값을 등록해 주는 것이지요.

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\CLSID\{41AC8568-9230-4E63-B7C5-CAAD997EE207}]
@="ClassLibraryAsAdmin.AdminCode"

[HKEY_CLASSES_ROOT\CLSID\{41AC8568-9230-4E63-B7C5-CAAD997EE207}\Implemented Categories]

[HKEY_CLASSES_ROOT\CLSID\{41AC8568-9230-4E63-B7C5-CAAD997EE207}\Implemented Categories\{62C8FE65-4EBB-45e7-B440-6E39B2CDBF29}]

[HKEY_CLASSES_ROOT\CLSID\{41AC8568-9230-4E63-B7C5-CAAD997EE207}\InprocServer32]
@="mscoree.dll"
"ThreadingModel"="Both"
"Class"="ClassLibraryAsAdmin.AdminCode"
"Assembly"="ClassLibraryAsAdmin, Version=1.0.0.0, Culture=neutral, PublicKeyToken=465ff3ec4fc809d7"
"RuntimeVersion"="v2.0.50727"

[HKEY_CLASSES_ROOT\CLSID\{41AC8568-9230-4E63-B7C5-CAAD997EE207}\InprocServer32\1.0.0.0]
"Class"="ClassLibraryAsAdmin.AdminCode"
"Assembly"="ClassLibraryAsAdmin, Version=1.0.0.0, Culture=neutral, PublicKeyToken=465ff3ec4fc809d7"
"RuntimeVersion"="v2.0.50727"

[HKEY_CLASSES_ROOT\CLSID\{41AC8568-9230-4E63-B7C5-CAAD997EE207}\ProgId]
@="ClassLibraryAsAdmin.AdminCode"

당연히, 이건 제가 이론적인 부분을 설명하려고 억지로 구성해 본 것이고 현실적으로 보면 x64용 regasm.exe를 실행해 주는 것이 맞습니다.

정리해 볼까요? AnyCPU 타입으로 빌드된 C# COM 개체를 x86/x64 EXE 프로세스에서 모두 사용하고 싶다면 gacutil + x86 regasm + x64 regasm 등록 과정을 거치면 된다는 것!




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

[연관 글]






[최초 등록일: ]
[최종 수정일: 11/30/2023]

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

비밀번호

댓글 작성자
 



2017-01-18 11시07분
[박형신] 기존에 있던 .net 어셈블리 파일을 가져와서 tlb를 이용하여 c++ x86 빌드로 동작 확인을 하였습니다. 그런데 c++ x64 빌드로 동작확인을 하려고 하는데
아래와 같은 에러가 나왔다면 EvalApi.dll 라는 .net 어셈블리파일이 x86으로 빌드되서 에러나는 것이겠지요? .net 어셈블리파일의 소스가 없는 상황이라서 x64로 빌드하지 않고
c++ x64 환경에서 빌드가 가능한 방법이 있을까요?

"RegAsm : error RA0000 : 'C:\Windows\Microsoft.NET\Framework64\v4.0.30319\EvalApi.dll'은(는) 올바른 .NET 어셈블리가
아니라서 로드하지 못했습니다."
[guest]
2017-01-19 11시17분
글쎄요. 구체적으로 어떻게 하신 건지 제가 재현할 수 있도록 관련 예제 코드와 과정을 적어주시면 답변에 도움이 될 것 같습니다. (RA0000 에러는 제가 접해본 적이 없습니다.)

우선, 기존 어셈블리가 x86으로만 빌드된 것인지 확인해 보세요. .NET Reflector등으로 해당 어셈블리를 열면 x86/x64/AnyCPU 빌드인지 확인이 가능합니다. 또는 gacutil.exe등을 통해 GAC에 등록해 보면 어셈블리 이름을 보고도 확인할 수 있습니다.
정성태
2018-08-13 07시18분
[SoulToMind] NSIS 스크립트를 활용해서 Activex 컨트롤 설치 모듈을 만들고 있는중입니다. AnyCpu로 설정된 Dll

v2.0.50727 버전 Regasm 86,64 버전으로 ActiveX에서 잘 동작하는지 32비트 64비트 테스트중입니다.

32비트에서는 오류 없이 정상적으로 잘되어 x86 regasm 으로만 등록하여 정상적으로 작동하는것을 확인하였고여
64비트에서는 오류가 발생하여 gacutil, x86 regasm, x64 regasm 순으로 등록 했습니다.

등록했으나 아래와 같은 에러 메시지가 나면서 작동이 되질 않아 해당 글과 같이 마지막 부분 HKEY_CLASSSES_ROOT\CLSID\ 에도 동일하게 레지스트리를 등록을 해주었는데도 동일한 에러가 발생합니다.

CoCreateInstance of OLE control {0350D90E-6559-49C5-89B1-2FDDA3D8356F} failed.    
Result code: 0x80070002
Is the control is properly registered?    

DebugView 로 보니 위와 같은 해당 메시지가 나옵니다. 의심해볼만한 부분이 어디있을까요?

글 읽어 주셔서 감사드립니다.
[guest]
2018-08-13 07시22분
[SoulToMind] 참 해당 에러 메시지는 MFC ActiveX 컨트롤에서 CreateControl 호출시 발생하는 에러입니다.
[guest]
2018-08-13 06시30분
0x80070002 오류라면 "The system cannot find the file specified"에 해당합니다. 글쎄요, 64비트 레지스트리에 정상적으로 등록했다면 그 에러가 나올 이유가 없어보입니다. 이 이상 제가 더 조언해 드릴 것이 없군요.
정성태

... [16]  17  18  19  20  21  22  23  24  25  26  27  28  29  30  ...
NoWriterDateCnt.TitleFile(s)
13228정성태1/24/20235192.NET Framework: 2089. C# - WMI 논리 디스크가 속한 물리 디스크의 정보를 얻는 방법 [2]파일 다운로드1
13227정성태1/23/20234909개발 환경 구성: 659. Windows - IP MTU 값을 바꿀 수 있을까요? [1]
13226정성태1/23/20234583.NET Framework: 2088. .NET 5부터 지원하는 GetRawSocketOption 사용 시 주의할 점
13225정성태1/21/20233834개발 환경 구성: 658. Windows에서 실행 중인 소켓 서버를 다른 PC 또는 WSL에서 접속할 수 없는 경우
13224정성태1/21/20234189Windows: 221. Windows - Private/Public/Domain이 아닌 네트워크 어댑터 단위로 방화벽을 on/off하는 방법
13223정성태1/20/20234385오류 유형: 838. RDP 연결 오류 - The two computers couldn't connect in the amount of time allotted
13222정성태1/20/20234060개발 환경 구성: 657. WSL - DockerDesktop.vhdx 파일 위치를 옮기는 방법
13221정성태1/19/20234281Linux: 57. C# - 리눅스 프로세스 메모리 정보파일 다운로드1
13220정성태1/19/20234401오류 유형: 837. NETSDK1045 The current .NET SDK does not support targeting .NET ...
13219정성태1/18/20233968Windows: 220. 네트워크의 인터넷 접속 가능 여부에 대한 판단 기준
13218정성태1/17/20233910VS.NET IDE: 178. Visual Studio 17.5 (Preview 2) - 포트 터널링을 이용한 웹 응용 프로그램의 외부 접근 허용
13217정성태1/13/20234499디버깅 기술: 185. windbg - 64비트 운영체제에서 작업 관리자로 뜬 32비트 프로세스의 덤프를 sos로 디버깅하는 방법
13216정성태1/12/20234743디버깅 기술: 184. windbg - 32비트 프로세스의 메모리 덤프인 경우 !peb 명령어로 나타나지 않는 환경 변수
13215정성태1/11/20236309Linux: 56. 리눅스 - /proc/pid/stat 정보를 이용해 프로세스의 CPU 사용량 구하는 방법 [1]
13214정성태1/10/20235847.NET Framework: 2087. .NET 6부터 SourceGenerator와 통합된 System.Text.Json [1]파일 다운로드1
13213정성태1/9/20235395오류 유형: 836. docker 이미지 빌드 시 "RUN apt install ..." 명령어가 실패하는 이유
13212정성태1/8/20235141기타: 85. 단정도/배정도 부동 소수점의 정밀도(Precision)에 따른 형변환 손실
13211정성태1/6/20235169웹: 42. (https가 아닌) http 다운로드를 막는 웹 브라우저
13210정성태1/5/20234255Windows: 219. 윈도우 x64의 경우 0x00000000`7ffe0000 아래의 주소는 왜 사용하지 않을까요?
13209정성태1/4/20234146Windows: 218. 왜 윈도우에서 가상 메모리 공간은 64KB 정렬이 된 걸까요?
13208정성태1/3/20234101.NET Framework: 2086. C# - Windows 운영체제의 2MB Large 페이지 크기 할당 방법파일 다운로드1
13207정성태12/26/20224401.NET Framework: 2085. C# - gpedit.msc의 "User Rights Assignment" 특권을 코드로 설정/해제하는 방법파일 다운로드1
13206정성태12/24/20224631.NET Framework: 2084. C# - GetTokenInformation으로 사용자 SID(Security identifiers) 구하는 방법 [3]파일 다운로드1
13205정성태12/24/20224965.NET Framework: 2083. C# - C++과의 연동을 위한 구조체의 fixed 배열 필드 사용 (2)파일 다운로드1
13204정성태12/22/20224247.NET Framework: 2082. C# - (LSA_UNICODE_STRING 예제로) CustomMarshaler 사용법파일 다운로드1
13203정성태12/22/20224408.NET Framework: 2081. C# Interop 예제 - (LSA_UNICODE_STRING 예제로) 구조체를 C++에 전달하는 방법파일 다운로드1
... [16]  17  18  19  20  21  22  23  24  25  26  27  28  29  30  ...