Microsoft MVP성태의 닷넷 이야기
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 

닷넷 EXE 실행 오류 - Mixed mode assembly is build against version 'v2.0.50727' of the runtime

이상하군요, 동일한 실행 파일이 동일한 운영체제에서 고객사의 특정 컴퓨터에서만 다음과 같은 오류가 발생합니다.

Unhandled Exception: System.IO.FileLoadException: Mixed mode assembly is built against version 'v2.0.50727' of the runtime and cannot be loaded in the 4.0 runtime without additional configuration information.


순수하게 오류 메시지의 의미만으로 보면 .NET 2.0 ~ 3.5 대상으로 빌드한 "mixed mode 어셈블리"는 .NET 4.0 환경에서 별도의 옵션 설정 없이는 로드할 수 없다는 것입니다.

사실, 제가 만든 어셈블리는 .NET 2.0을 대상으로 빌드한 것이 맞습니다. 그리고 .NET 4.0 환경에서도 실행이 될 수 있도록 supportedRuntime 설정을 해둔 것인데요,

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <startup>
        <supportedRuntime version="v4.0.30319"/>
        <supportedRuntime version="v2.0.50727"/>
    </startup>
</configuration>

메시지에 따라 이 오류를 해결하려면 "additional configuration information"이 필요하고, 여기서의 요구 사항을 만족하는 설정은 useLegacyV2RuntimeActivationPolicy입니다.

useLegacyV2RuntimeActivationPolicy
; https://docs.microsoft.com/en-us/dotnet/framework/configure-apps/file-schema/startup/startup-element

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <startup useLegacyV2RuntimeActivationPolicy="true">
        <supportedRuntime version="v4.0.30319"/>
        <supportedRuntime version="v2.0.50727"/>
    </startup>
</configuration>

일단, 이것으로 급한 불은 껐는데요. ^^




문제는, "mixed mode assembly"의 기준입니다. 아래의 문서에 보면 이에 대해 설명하고 있는데요,

Mixed (native and managed) assemblies
; https://docs.microsoft.com/en-us/cpp/dotnet/mixed-native-and-managed-assemblies

Mixed assemblies are capable of containing both unmanaged machine instructions and MSIL instructions.
...[생략]...
Visual C++ only supports the generation of mixed managed assemblies by using the /clr compiler option.

(14) What is a mixed-mode assembly?
; http://stackoverflow.com/questions/7266936

A mixed-mode assembly is a dynamic link library that contains both managed code and native code for a particular processor architecture. Since it contains native code it can only be loaded into a process that matches the processor architecture it was compiled for.


보는 바와 같이, 현재 mixed managed assembly를 생성할 수 있는 유일한 방법은 Visual C++/CLI만 가능한 것입니다. 반면, 제가 겪은 문제의 어셈블리는 C#으로 AnyCPU를 대상으로 만든 것이기 때문에 저 기준에 부합하지 않습니다.

그렇기 때문에, 대부분의 환경에서는 정상적으로 실행이 되었지만 "원인을 알 수 없는" 그 고객사의 특정 컴퓨터에서만 저 오류가 발생하고 있는 것입니다. 그나마 원인을 유추해 볼 수 있는 것은 해당 어셈블리가 unsafe 예약어를 사용해 포인터를 다루는 코드가 있긴 하다는 점입니다. 따라서 일단 해당 어셈블리의 unsafe 코드 사용을 없애고 다시 빌드했지만, 고객사 측의 실 서버에서 진행된 문제라 다시 테스트를 할 수는 없는 상황입니다. (나중에 혹시나, 해당 고객사로부터 피드백을 받으면 기록에 추가하겠습니다. ^^)




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







[최초 등록일: ]
[최종 수정일: 4/22/2021]

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

비밀번호

댓글 작성자
 




... 31  32  33  34  35  36  37  38  39  40  41  42  43  [44]  45  ...
NoWriterDateCnt.TitleFile(s)
12539정성태2/16/20219747Windows: 189. WM_TIMER의 동작 방식 개요파일 다운로드1
12538정성태2/15/202110129.NET Framework: 1023. C# - GC 힙이 아닌 Native 힙에 인스턴스 생성 - 0SuperComicLib.LowLevel 라이브러리 소개 [2]
12537정성태2/11/202111191.NET Framework: 1022. UI 요소의 접근은 반드시 그 UI를 만든 스레드에서! - 두 번째 이야기 [2]
12536정성태2/9/202110159개발 환경 구성: 542. BDP(Bandwidth-delay product)와 TCP Receive Window
12535정성태2/9/20219274개발 환경 구성: 541. Wireshark로 확인하는 LSO(Large Send Offload), RSC(Receive Segment Coalescing) 옵션
12534정성태2/8/20219838개발 환경 구성: 540. Wireshark + C/C++로 확인하는 TCP 연결에서의 closesocket 동작 [1]파일 다운로드1
12533정성태2/8/20219502개발 환경 구성: 539. Wireshark + C/C++로 확인하는 TCP 연결에서의 shutdown 동작파일 다운로드1
12532정성태2/6/20219990개발 환경 구성: 538. Wireshark + C#으로 확인하는 ReceiveBufferSize(SO_RCVBUF), SendBufferSize(SO_SNDBUF) [3]
12531정성태2/5/20218987개발 환경 구성: 537. Wireshark + C#으로 확인하는 PSH flag와 Nagle 알고리듬파일 다운로드1
12530정성태2/4/202113196개발 환경 구성: 536. Wireshark + C#으로 확인하는 TCP 통신의 Receive Window
12529정성태2/4/202110242개발 환경 구성: 535. Wireshark + C#으로 확인하는 TCP 통신의 MIN RTO [1]
12528정성태2/1/20219662개발 환경 구성: 534. Wireshark + C#으로 확인하는 TCP 통신의 MSS(Maximum Segment Size) - 윈도우 환경
12527정성태2/1/20219855개발 환경 구성: 533. Wireshark + C#으로 확인하는 TCP 통신의 MSS(Maximum Segment Size) - 리눅스 환경파일 다운로드1
12526정성태2/1/20217702개발 환경 구성: 532. Azure Devops의 파이프라인 빌드 시 snk 파일 다루는 방법 - Secure file
12525정성태2/1/20217400개발 환경 구성: 531. Azure Devops - 파이프라인 실행 시 빌드 이벤트를 생략하는 방법
12524정성태1/31/20218526개발 환경 구성: 530. 기존 github 프로젝트를 Azure Devops의 빌드 Pipeline에 연결하는 방법 [1]
12523정성태1/31/20218577개발 환경 구성: 529. 기존 github 프로젝트를 Azure Devops의 Board에 연결하는 방법
12522정성태1/31/202110098개발 환경 구성: 528. 오라클 클라우드의 리눅스 VM - 9000 MTU Jumbo Frame 테스트
12521정성태1/31/202110032개발 환경 구성: 527. 이더넷(Ethernet) 환경의 TCP 통신에서 MSS(Maximum Segment Size) 확인 [1]
12520정성태1/30/20218592개발 환경 구성: 526. 오라클 클라우드의 VM에 ping ICMP 여는 방법
12519정성태1/30/20217636개발 환경 구성: 525. 오라클 클라우드의 VM을 외부에서 접근하기 위해 포트 여는 방법
12518정성태1/30/202125073Linux: 37. Ubuntu에 Wireshark 설치 [2]
12517정성태1/30/202112711Linux: 36. 윈도우 클라이언트에서 X2Go를 이용한 원격 리눅스의 GUI 접속 - 우분투 20.04
12516정성태1/29/20219350Windows: 188. Windows - TCP default template 설정 방법
12515정성태1/28/202110610웹: 41. Microsoft Edge - localhost에 대해 http 접근 시 무조건 https로 바뀌는 문제 [3]
12514정성태1/28/202110896.NET Framework: 1021. C# - 일렉트론 닷넷(Electron.NET) 소개 [1]파일 다운로드1
... 31  32  33  34  35  36  37  38  39  40  41  42  43  [44]  45  ...