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은 이 글의 예제 프로젝트를 포함합니다.)




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

[연관 글]


donaricano-btn



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

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

비밀번호

댓글 쓴 사람
 




[1]  2  3  4  5  6  7  8  9  10  11  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
12839정성태9/15/2021275.NET Framework: 1118. C# 10 - (17) 제네릭 타입의 특성 적용파일 다운로드1
12838정성태9/13/2021277.NET Framework: 1117. C# - Task에 전달한 Action, Func 유형에 따라 달라지는 async/await 비동기 처리 [2]파일 다운로드1
12837정성태9/11/2021149VC++: 151. Golang - fmt.Errorf, errors.Is, errors.As 설명
12836정성태9/10/2021107Linux: 45. 리눅스 - 실행 중인 다른 프로그램의 출력을 확인하는 방법
12835정성태9/7/2021169.NET Framework: 1116. C# 10 - (16) CallerArgumentExpression 특성 추가파일 다운로드1
12834정성태9/7/202198오류 유형: 762. Visual Studio 2019 Build Tools - 'C:\Program' is not recognized as an internal or external command, operable program or batch file.
12833정성태9/6/2021180VC++: 150. Golang - TCP client/server echo 예제 코드파일 다운로드1
12832정성태9/6/202190VC++: 149. Golang - 인터페이스 포인터가 의미 있을까요?
12831정성태9/6/2021121VC++: 148. Golang - 채널에 따른 다중 작업 처리파일 다운로드1
12830정성태9/6/2021106오류 유형: 761. Internet Explorer에서 파일 다운로드 시 "Your current security settings do not allow this file to be downloaded." 오류
12829정성태9/5/2021215.NET Framework: 1115. C# 10 - (15) 구조체 타입에 기본 생성자 정의 가능파일 다운로드1
12828정성태9/4/2021224.NET Framework: 1114. C# 10 - (14) 단일 파일 내에 적용되는 namespace 선언파일 다운로드1
12827정성태9/4/2021119스크립트: 27. 파이썬 - 웹 페이지 데이터 수집을 위한 scrapy Crawler 사용법 요약
12826정성태9/3/2021177.NET Framework: 1113. C# 10 - (13) 문자열 보간 성능 개선파일 다운로드1
12825정성태9/3/202172개발 환경 구성: 603. GoLand - WSL 환경과 연동
12824정성태9/2/2021173오류 유형: 760. 파이썬 tensorflow - Dst tensor is not initialized. 오류 메시지
12823정성태9/2/2021168스크립트: 26. 파이썬 - PyCharm을 이용한 fork 디버그 방법
12822정성태9/1/2021101오류 유형: 759. 파이썬 tensorflow - ValueError: Shapes (...) and (...) are incompatible
12821정성태9/1/2021153.NET Framework: 1112. C# - .NET 6부터 공개된 ISpanFormattable 사용법
12820정성태9/1/202189VC++: 147. Golang - try/catch에 대응하는 panic/recover파일 다운로드1
12819정성태8/31/2021188.NET Framework: 1111. C# - FormattableString 타입
12818정성태8/31/2021127Windows: 198. 윈도우 - 작업 관리자에서 (tensorflow 등으로 인한) GPU 연산 부하 보는 방법
12817정성태8/31/202181스크립트: 25. 파이썬 - 윈도우 환경에서 directml을 이용한 tensorflow의 AMD GPU 사용 방법
12816정성태8/30/2021384스크립트: 24. 파이썬 - tensorflow 2.6 NVidia GPU 사용 방법 [2]
12815정성태8/30/2021206개발 환경 구성: 602. WSL 2 - docker-desktop-data, docker-desktop (%LOCALAPPDATA%\Docker\wsl\data\ext4.vhdx) 파일을 다른 디렉터리로 옮기는 방법
[1]  2  3  4  5  6  7  8  9  10  11  12  13  14  15  ...