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

(StrongName의 버전 구분이 필요 없는) .NET Core 어셈블리 바인딩 규칙

제목이 곧 결론인데요, .NET Core부터는 강력한 이름의 어셈블리조차도 바인딩 시에 버전 정보를 전혀 고려하지 않습니다. 예를 들어 볼까요? ^^

가령 EXE 프로젝트인 ConsoleApp1의 Program.cs에서 12.0.3 버전의 Netonsoft.Json을 사용해 보겠습니다.

// Install-Package Newtonsoft.Json -Version 12.0.3

using Newtonsoft.Json;
using System;

namespace ConsoleApp1
{
    class Program
    {
        static void Main(string[] args)
        {
            Product product = new Product();
            product.Name = "Apple";

            string json = JsonConvert.SerializeObject(product);
            Console.WriteLine(json);
        }
    }

    public class Product
    {
        public string Name { get; internal set; }
    }
}

그럼 당연히 ConsoleApp1.exe 빌드 시 출력 폴더에는 12.0.3 버전의 Netonsoft.Json.dll도 함께 놓일 것이고, 이후 실행하면 그 버전의 어셈블리가 로드해 동작하게 됩니다. 문제는, 이 프로젝트가 다른 버전의 Netonsoft.Json.dll을 사용하는 라이브러리를 참조했을 때입니다. 이를 위해 ClassLibrary1 프로젝트를 하나 만들어 11.0.2 버전의 Newtonsoft.Json를 사용하는 코드를 넣은 후,

// Install-Package Newtonsoft.Json -Version 11.0.2

using Newtonsoft.Json;
using System;

namespace ClassLibrary1
{
    public class Class1
    {
        public void Test()
        {
            Person person = new Person();
            person.Name = "Apple";

            string json = JsonConvert.SerializeObject(person);
            Console.WriteLine(typeof(Class1).Assembly.FullName + ", " + json + ", " + typeof(JsonConvert).Assembly.FullName);
        }
    }

    public class Person
    {
        public string Name { get; internal set; }
    }
}

EXE 프로젝트 측에서 ClassLibrary1을 참조해 그 코드를 사용해 봅니다.

static void Main(string[] args)
{
    Product product = new Product();
    product.Name = "Apple";

    string json = JsonConvert.SerializeObject(product);
    Console.WriteLine(json);

    new ClassLibrary1.Class1().Test();
}

정리하면, 다음과 같은 형식의 프로젝트 구조를 갖게 됩니다.

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

netcoer_binding_redirect_1.png




만약 .NET Framework에서 위와 같이 프로젝트를 구성하게 되면 (특별한 조치를 취하지 않는 한) 실행 시 다음과 같은 식의 예외가 발생합니다.

C:\ConsoleApp1\bin\Debug\net461> ConsoleApp1.exe
{"Name":"Apple"}

Unhandled Exception: System.IO.FileLoadException: Could not load file or assembly 'Newtonsoft.Json, Version=11.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040) at ClassLibrary1.Class1.Test()
at ConsoleApp1.Program.Main(String[] args)


(참고로, Newtonsoft.Json의 경우 제품 버전이 12.x.x의 경우 StrongName의 버전이 12.0.0.0이고, 11.x.x의 경우에는 11.0.0.0입니다.)

왜냐하면, EXE 프로젝트가 빌드하면서 생성한 출력 폴더에는 EXE를 기준으로 한 12.0.0.0 버전의 Newtonsoft.Json.dll이 있기 때문에 11.0.0.0 버전의 Newtonsoft.Json을 사용하는 ClassLibrary1에서는 버전이 상이해서 예외가 발생하는 것입니다.

반면, .NET Core에서 실행하면 다음과 같이 실행이 잘 됩니다.

{"Name":"Apple"}
ClassLibrary1, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null, {"Name":"Apple"}, Newtonsoft.Json, Version=12.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed


즉, .NET Core에서는 ClassLibrary1가 요청한 11.0.0.0 버전의 Newtonsoft.Json 어셈블리를 12.0.0.0 버전의 어셈블리로 자동으로 매핑시켜 준 것입니다.




.NET Core의 이런 정책이 가능한 이유는 GAC를 갖지 않기 때문입니다. .NET Core 응용 프로그램이 사용하는 모든 어셈블리들은 EXE와 같은 폴더에 있어야 하기 때문에, 그리고 별도로 GAC와 같은 공통 장소에서 로드할 필요가 없기 때문에 버전 관리가 사실상 의미가 없어진 것입니다.

한마디로, 버전 관리가 매우 편해진 것인데 달리 말하면 공통 어셈블리들의 경우 반드시 하위 호환성을 지켜야만 합니다. 만약 하위 호환성이 없다면 별도로 다른 어셈블리 이름으로 새롭게 프로젝트를 시작해야 합니다. 재미있는 것은, 실제로 위의 예제에서 다룬 Newtonsoft.Json의 참조를 역으로 바꾸면 빌드 자체가 안 됩니다. 즉, ConsoleApp1 프로젝트에서 11.0.2 버전을 참조하고, ClassLibrary1 프로젝트에서 12.0.3 버전을 참조하면 다음과 같은 에러가 발생합니다.

Error NU1605 Detected package downgrade: Newtonsoft.Json from 12.0.3 to 11.0.2. Reference the package directly from the project to select a different version. 
 ConsoleApp1 -> ClassLibrary1 -> Newtonsoft.Json (>= 12.0.3) 
 ConsoleApp1 -> Newtonsoft.Json (>= 11.0.2)

아마도 하위 호환성까지는 개발자가 예측할 수 있다는 가정 하에 빌드를 허용했지만, 상위 호환성까지는 보증할 수 없으므로 막아버리겠다는 의미인 듯합니다. 따라서, 만약 닷넷 코어로 공통 라이브러리를 만드는 개발자라면 가능한 사용하는 라이브러리의 하위 버전을 참조해야 범용성이 좋아집니다.




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



donaricano-btn



[최초 등록일: ]
[최종 수정일: 7/10/2021]

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)
12281정성태8/2/20202679개발 환경 구성: 500. (PDB 연결이 없는) DLL의 소스 코드 디버깅을 dotPeek 도구로 해결하는 방법
12280정성태8/2/20202532오류 유형: 634. 오라클 (평생) 무료 클라우드 VM 생성 후 SSH 접속 시 키 오류 발생 [2]
12279정성태7/29/20203002개발 환경 구성: 499. 닷넷에서 접근해보는 InterSystems의 Cache 데이터베이스파일 다운로드1
12278정성태7/23/20201919VS.NET IDE: 149. ("Binary was not built with debug information" 상태로) 소스 코드 디버깅이 안되는 경우
12277정성태7/23/20202360개발 환경 구성: 498. DEVPATH 환경 변수의 사용 예 - .NET Reflector의 (PDB 연결이 없는) DLL의 소스 코드 디버깅
12276정성태7/23/20202167.NET Framework: 930. 개발자를 위한 닷넷 어셈블리 바인딩 - DEVPATH 환경 변수
12275정성태7/22/20203169개발 환경 구성: 497. 닷넷에서 접근해보는 InterSystems의 IRIS Data Platform 데이터베이스파일 다운로드1
12274정성태7/21/20203182개발 환경 구성: 496. Azure - Blob Storage Account의 Location 이전 방법 [1]파일 다운로드1
12273정성태7/18/20204135개발 환경 구성: 495. Azure - Location이 다른 웹/DB 서버의 경우 발생하는 성능 하락
12272정성태7/16/20201729.NET Framework: 929. (StrongName의 버전 구분이 필요 없는) .NET Core 어셈블리 바인딩 규칙파일 다운로드1
12271정성태7/16/20202103.NET Framework: 928. .NET Framework의 Strong-named 어셈블리 바인딩 (2) - 런타임에 바인딩 리디렉션파일 다운로드1
12270정성태7/16/20202711오류 유형: 633. SSL_CTX_use_certificate_file - error:140AB18F:SSL routines:SSL_CTX_use_certificate:ee key too small
12269정성태7/16/20201813오류 유형: 632. .NET Core 웹 응용 프로그램 - The process was terminated due to an unhandled exception.
12268정성태7/15/20201918오류 유형: 631. .NET Core 웹 응용 프로그램 오류 - HTTP Error 500.35 - ANCM Multiple In-Process Applications in same Process
12267정성태7/15/20202455.NET Framework: 927. C# - 윈도우 프로그램에서 Credential Manager를 이용한 보안 정보 저장파일 다운로드1
12266정성태7/14/20201828오류 유형: 630. 사용자 계정을 지정해 CreateService API로 서비스를 등록한 경우 "Error 1069: The service did not start due to a logon failure." 오류발생
12265정성태7/10/20201843오류 유형: 629. Visual Studio - 웹 애플리케이션 실행 시 "Unable to connect to web server 'IIS Express'." 오류 발생
12264정성태7/9/20203303오류 유형: 628. docker: Error response from daemon: Conflict. The container name "..." is already in use by container "...".
12261정성태7/9/20202412VS.NET IDE: 148. 윈도우 10에서 .NET Core 응용 프로그램을 리눅스 환경에서 실행하는 2가지 방법 - docker, WSL 2 [5]
12260정성태7/8/20201971.NET Framework: 926. C# - ETW를 이용한 ThreadPool 스레드 감시파일 다운로드1
12259정성태7/8/20201881오류 유형: 627. nvlddmkm.sys의 BAD_POOL_HEADER BSOD 문제
12258정성태7/8/20202809기타: 77. DataDog APM 간략 소개
12257정성태7/7/20202069.NET Framework: 925. C# - ETW를 이용한 Monitor Enter/Exit 감시파일 다운로드1
12256정성태7/7/20202070.NET Framework: 924. C# - Reflection으로 변경할 수 없는 readonly 정적 필드 [4]
12255정성태7/6/20201941.NET Framework: 923. C# - ETW(Event Tracing for Windows)를 이용한 Finalizer 실행 감시파일 다운로드1
12254정성태7/2/20202054오류 유형: 626. git - REMOTE HOST IDENTIFICATION HAS CHANGED!
... 16  17  18  19  20  21  22  23  [24]  25  26  27  28  29  30  ...