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

Self-Contained/SingleFile 유형의 .NET Core/5+ 실행 파일을 임베딩한다면?

페이스북의 지인이 재미있는 의견을 올렸군요. ^^

@rkttu/posts/4194954673885182
; https://www.facebook.com/rkttu/posts/4194954673885182

/*
닷넷 프레임워크일 때는 생각없이 다른 프로젝트의 EXE output만 임베딩해서 쓰는 방법을 꽤 자주 이용했는데, 닷넷 코어로 넘어가고나니 이 방법을 쓰기 부담스러워지는 부분이 있다.
Self-Contained Publish를 하던 Trimming을 하던 어쨌든 사이즈가 20~50MB 정도 되는 EXE 파일을 만들어야 하는데, 이 전략으로 그냥 포함을 시키면 만들어지는 EXE 파일의 크기가 너무 커진다는 점.
여러모로 NativeAOT의 늦은 데뷔가 아쉬워지는 부분이다.
*/

/*
다른 이야기지만 가끔 저는 써먹는 방법이 크기가 크지 않은 파일은 BASE 64 string으로 인코딩해서 코드에 verbatim string으로 넣는 방법도 이용하곤 합니다. 좋은 접근법이 아닐 수는 있겠지만 요긴하게 이용할 때가 있습니다.
*/


예를 들어 볼까요?

우선, .NET Core/5+ 콘솔 프로젝트를 2개(ConsoleApp1, ConsoleApp2)를 만들고, 그중에서 ConsoleApp1을,

using System;

namespace ConsoleApp1
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine("Hello World!");
            Console.WriteLine(new DateTime(2008, 12, 28));
        }
    }
}

self-contained 유형으로 배포합니다.

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

    <PropertyGroup>
        <OutputType>Exe</OutputType>
        <TargetFramework>net5.0</TargetFramework>

        <RuntimeIdentifier>win-x64</RuntimeIdentifier>
        <DebugType>embedded</DebugType>

        <AppendRuntimeIdentifierToOutputPath>false</AppendRuntimeIdentifierToOutputPath>
        <AppendTargetFrameworkToOutputPath>false</AppendTargetFrameworkToOutputPath>

        <SelfContained>true</SelfContained>
        <IncludeAllContentForSelfExtract>true</IncludeAllContentForSelfExtract>

        <PublishTrimmed>true</PublishTrimmed>
        <PublishSingleFile>true</PublishSingleFile>
    </PropertyGroup>

    <ItemGroup>
        <RuntimeHostConfigurationOption Include="System.Globalization.Invariant" Value="true" />
    </ItemGroup>

</Project>

그럼, 약 18MB 정도의 ConsoleApp1.exe 단일 파일이 생성되는데요, 이제 그걸 ConsoleApp2에서 리소스로 포함(embedded) 시키고 다음과 같이 코드를 작성하면,

using System;
using System.Diagnostics;
using System.IO;

namespace ConsoleApp2
{
    class Program
    {
        static void Main(string[] args)
        {
            ExtractResource("ConsoleApp2", "ConsoleApp1.exe");

            Process.Start("ConsoleApp1.exe");
        }

        private static void ExtractResource(string resNamespace, string resFileName)
        {
            string curPath = Path.GetDirectoryName(typeof(Program).Assembly.Location);
            string resTargetPath = Path.Combine(curPath, resFileName);

            if (File.Exists(resTargetPath) == true)
            {
                return;
            }

            using (System.IO.Stream stream = System.Reflection.Assembly.GetExecutingAssembly().GetManifestResourceStream($"{resNamespace}.{resFileName}"))
            {
                using (System.IO.FileStream fileStream = new System.IO.FileStream(resTargetPath, System.IO.FileMode.Create))
                {
                    stream.CopyTo(fileStream);
                }
            }
        }
    }
}

빌드 후 실행했을 때, ConsoleApp1.exe를 실행할 수 있습니다. 물론, 이를 위해 해당 EXE를 리소스로 담아 두고 있으니 ConsoleApp2의 소스 코드가 거의 기본 코드만 있는데도 (당연히) 18MB가 넘는 크기로 생성됩니다. 게다가 ConsoleApp2까지도 Self-contained/SingleFile로 생성하면 40MB 정도의 바이너리가 될 것입니다.




그런데, 여기서 한 가지 의문이 생기지 않나요? 그러니까, 어차피 런타임은 ConsoleApp2에 의해 올라와 있는데, 굳이 embedded한 EXE 리소스가 또다시 런타임을 들고 있을 필요는 없어 보입니다. 즉, .NET Framework 시절처럼 단순히 IL 코드로만 구성된 DLL/EXE만을 담고 있어도 될 것 같은 가정입니다.

그래도 혹시 모르니 ^^ 테스트는 해봐야 할 것입니다. 이를 위해 우선 ConsoleApp1에 대해 (publish가 아닌 일반 빌드의) 출력으로 나오는 DLL을 Base64 인코딩해, ConsoleApp2에서 다음과 같이 들고 있겠습니다.

using System;
using System.Reflection;

namespace ConsoleApp2
{
    class Class1Res
    {
        public static Assembly GetAssembly()
        {
            byte [] buf = Convert.FromBase64String(contents);
            return Assembly.Load(buf);
        }

        // ConsoleApp1.dll의 base64 인코딩 텍스트
        static string contents = @"
TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAgAAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1v
...[생략]...
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA==
";
    }
}

DLL 출력을 base64 인코딩시켰으니 이제 실행 파일이 아닌데요, 상관없습니다, ConsoleApp2 실행 파일을 재사용하면 되므로 다음과 같이 코딩해 이를 해결할 수 있습니다.

using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.Linq;
using System.Reflection;

namespace ConsoleApp2
{
    class Program
    {
        static void Main(string[] args)
        {
            if (args.Length != 0)
            {
                List embeddedTarget = args.SkipWhile((txt) => txt != "/run").ToList();
                if (embeddedTarget.Count == 1)
                {
                    return;
                }

                string embeddedTargetDll = embeddedTarget[1];

                switch (embeddedTargetDll)
                {
                    case "1":
                        Assembly asm = Class1Res.GetAssembly();
                        MethodInfo mi = asm.EntryPoint;
                        mi.Invoke(null, new object[] { new string[0] { } });
                        return;
                }
            }

            ProcessStartInfo psi = new ProcessStartInfo();
            psi.FileName = Process.GetCurrentProcess().ProcessName;
            psi.Arguments = Environment.CommandLine + $" /run 1";
            psi.RedirectStandardOutput = true;
            Process target = Process.Start(psi);

            string text = target.StandardOutput.ReadToEnd();
            Console.WriteLine(text);
        }
    }
}

위의 프로그램을 실행하면 다음과 같은 절차를 거치게 됩니다.

ConsoleApp2 프로세스 시작
내장 ConsoleApp1.dll을 실행하기 위해 다시 ConsoleApp2 프로세스 시작
    내장 ConsoleApp1.dll을 base64 디코딩해 ConsoleApp2 프로세스 내에서 ConsoleApp1.dll의 Main 함수를 실행
    두 번째 실행된 ConsoleApp2 프로세스 종료
두 번째 프로세스의 출력을 자신의 화면에 출력

실제로 실행해 보면, ConsoleApp2의 런타임 로드 환경에 도움을 받아 ConsoleApp1.dll이 잘 실행이 되는 것을 확인할 수 있습니다.




자, 그렇다면 이제 관심사는 ConsoleApp2 프로젝트를 self-contained/singlefile로 빌드한 경우는 어떨까입니다.

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

    <PropertyGroup>
        <OutputType>Exe</OutputType>
        <TargetFramework>net5.0</TargetFramework>
        
        <RuntimeIdentifier>win-x64</RuntimeIdentifier>
        <DebugType>embedded</DebugType>

        <AppendRuntimeIdentifierToOutputPath>false</AppendRuntimeIdentifierToOutputPath>
        <AppendTargetFrameworkToOutputPath>false</AppendTargetFrameworkToOutputPath>

        <SelfContained>true</SelfContained>
        <IncludeAllContentForSelfExtract>true</IncludeAllContentForSelfExtract>

        <PublishTrimmed>true</PublishTrimmed>
        <PublishSingleFile>true</PublishSingleFile>

    </PropertyGroup>

    <ItemGroup>
        <RuntimeHostConfigurationOption Include="System.Globalization.Invariant" Value="true" />
    </ItemGroup>
    
</Project>

아쉽게도, ConsoleApp1의 DateTime을 사용하는 코드에서 다음과 같은 예외가 발생합니다.

c:\temp> ConsoleApp2.exe
Unhandled Exception: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation.
 ---> System.TypeLoadException: Could not load type 'System.DateTime' from assembly 'System.Runtime, Version=5.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.
   at ConsoleApp1.Program.Main(String[] args)
   --- End of inner exception stack trace ---
   at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor, Boolean wrapExceptions)
   at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
   at System.Reflection.MethodBase.Invoke(Object obj, Object[] parameters)
   at ConsoleApp2.Program.Main(String[] args)

이 예외가 발생하는 것은, ConsoleApp2 프로젝트 측의 PublishTrimmed 때문입니다. 즉, ConsoleApp1 프로젝트에서는 System.DateTime을 사용했는데, ConsoleApp2에서는 해당 타입을 사용한 적이 없어 SingleFile 바이너리에 누락되었고 그것을 찾고 있으니 TypeLoadException 예외가 발생합니다.

따라서, ConsoleApp2로 호스팅을 정상적으로 하려고 하면 PublishTrimmed 옵션을 제거하고 빌드해야 합니다. 그런데, ^^; 그로 인해 19MB 정도의 trimmed 바이너리가 59MB짜리 ConsoleApp2.exe 파일로 생성되기 때문에 이렇게 되면 Console1 프로젝트를 self-contained+singlefile로 한 것보다 더 크기가 커진 격이 됩니다.




물론, 문제는 저것뿐만이 아닙니다. 가령, ConsoleApp1 프로젝트에서 다른 DLL을 참조한 경우라면 ConsoleApp2에서 실행 시 오류가 발생하게 됩니다. 예를 들어, 다음과 같이 Json.NET을 참조해 코드를 추가하면,

using Newtonsoft.Json;
using System;

namespace ConsoleApp1
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine("Hello World!");

            Product product = new Product();
            product.Name = "Apple";
            product.Expiry = new DateTime(2008, 12, 28);
            product.Sizes = new string[] { "Small" };

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

빌드된 Console1.dll에는 Newtonsoft.Json.dll이 없으므로 당연히 그것만 리소스에 포함한 ConsoleApp2 프로젝트 환경으로는 오류가 발생할 수밖에 없습니다. 이런 문제를 해결하려면 1) ConsoleApp1.dll을 리소스 처리한 것처럼 Newtonsoft.Json.dll도 리소스로 담아 AppDomain.AssemblyResolve 이벤트에서 반환하거나, 2) 그게 귀찮으면 그냥 ConsoleApp2 프로젝트에서 사용하지는 않지만 참조를 추가해 호스팅 환경을 준비하는 방법이 있습니다.




결국, 그다지 현실성 없는 방법이지만 ^^; 그래도 테스트를 해본 것에 의미를 두겠습니다. 그나저나, 이런 상황은 NativeAOT가 나온다고 해서 크게 좋아질 것 같지는 않습니다. 어차피 AOT로 컴파일해도 결과물만 기계어일 뿐 사실상 CoreCLR 위에서 구동되는 모든 환경은 같기 때문에 그런 의미에서 현재의 Trimmed/SingleFile이 20MB를 유지하는 것만큼 정도는 될 듯합니다. 즉, clrjit.dll, coreclr.dll, mscordaccore.dll을 기본(7MB+)으로 프로젝트 내에서 사용하는 BCL의 모든 AOT 컴파일 결과물을 포함하는 크기가 어느 정도까지 작아질지는 의문입니다.

(첨부 파일, self_contained_exe_embed_sample.zip, dll_embed_sample.zip은 이 글의 예제 프로젝트를 포함합니다.)




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

[연관 글]






[최초 등록일: ]
[최종 수정일: 8/26/2021]

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

비밀번호

댓글 작성자
 



2021-11-11 09시38분
정성태

[1]  2  3  4  5  6  7  8  9  10  11  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
13090정성태6/29/202226오류 유형: 815. PyPI에 업로드한 패키지가 반영이 안 되는 경우
13089정성태6/28/202235개발 환경 구성: 646. HOSTS 파일 변경 시 Edge 브라우저에 반영하는 방법
13088정성태6/27/202245개발 환경 구성: 645. "Developer Command Prompt for VS 2022" 명령행 환경의 폰트를 바꾸는 방법
13087정성태6/23/2022118스크립트: 41. 파이썬 - FastAPI / uvicorn 호스팅 환경에서 asyncio 사용하는 방법
13086정성태6/22/2022188.NET Framework: 2026. C# 11 - 문자열 보간 개선 2가지파일 다운로드1
13085정성태6/22/2022163.NET Framework: 2025. C# 11 - 원시 문자열 리터럴(raw string literals)파일 다운로드1
13084정성태6/21/202258개발 환경 구성: 644. Windows - 파이썬 2.7을 msi 설치 없이 구성하는 방법
13083정성태6/20/2022143.NET Framework: 2024. .NET 7에 도입된 GC의 메모리 해제에 대한 segment와 region의 차이점
13082정성태6/19/202292.NET Framework: 2023. C# - Process의 I/O 사용량을 보여주는 GetProcessIoCounters Win32 API파일 다운로드1
13081정성태6/17/2022154.NET Framework: 2022. C# - .NET 7 Preview 5 신규 기능 - System.IO.Stream ReadExactly / ReadAtLeast파일 다운로드1
13080정성태6/17/202292개발 환경 구성: 643. Visual Studio 2022 17.2 버전에서 C# 11 또는 .NET 7.0 preview 적용
13079정성태6/17/202272오류 유형: 814. 파이썬 - Error: The file/path provided (...) does not appear to exist
13078정성태6/16/2022143.NET Framework: 2021. WPF - UI Thread와 Render Thread파일 다운로드1
13077정성태6/15/202298스크립트: 40. 파이썬 - postgresql 환경 구성
13075정성태6/15/2022138Linux: 50. Linux - apt와 apt-get의 차이 [2]
13074정성태6/13/2022162.NET Framework: 2020. C# - NTFS 파일에 사용자 정의 속성값 추가하는 방법파일 다운로드1
13073정성태6/12/2022202Windows: 207. Windows Server 2022에 도입된 WSL 2
13072정성태6/10/2022122Linux: 49. Linux - ls 명령어로 출력되는 디렉터리 색상 변경 방법
13071정성태6/9/2022156스크립트: 39. Python에서 cx_Oracle 환경 구성
13070정성태6/8/2022212오류 유형: 813. Windows 11에서 입력 포커스가 바뀌는 문제 [1]
13069정성태5/26/2022434.NET Framework: 2019. C# - .NET에서 제공하는 3가지 Timer 비교
13068정성태5/24/2022382.NET Framework: 2018. C# - 일정 크기를 할당하는 동안 GC를 (가능한) 멈추는 방법파일 다운로드1
13067정성태5/23/2022202Windows: 206. Outlook - 1년 이상 지난 메일이 기본적으로 안 보이는 문제
13066정성태5/23/2022216Windows: 205. Windows 11 - Windows + S(또는 Q)로 뜨는 작업 표시줄의 검색 바가 동작하지 않는 경우
13065정성태5/20/2022456.NET Framework: 2017. C# - Windows I/O Ring 소개파일 다운로드1
[1]  2  3  4  5  6  7  8  9  10  11  12  13  14  15  ...