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)
12891정성태12/23/2021633스크립트: 38. 파이썬 - uwsgi의 --master 옵션
12890정성태12/23/2021672VC++: 152. Golang - (문자가 아닌) 바이트 위치를 반환하는 strings.IndexRune 함수
12889정성태12/22/20211060.NET Framework: 1123. C# - (SharpDX + DXGI) 화면 캡처한 이미지를 빠르게 JPG로 변환하는 방법파일 다운로드1
12888정성태12/21/2021858.NET Framework: 1122. C# - ImageCodecInfo 사용 시 System.Drawing.Image와 System.Drawing.Bitmap에 따른 Save 성능 차이파일 다운로드1
12887정성태12/21/2021892오류 유형: 777. OpenCVSharp4를 사용한 프로그램 실행 시 "The type initializer for 'OpenCvSharp.Internal.NativeMethods' threw an exception." 예외 발생
12886정성태12/20/2021727스크립트: 37. 파이썬 - uwsgi의 --enable-threads 옵션
12885정성태12/20/2021482오류 유형: 776. uwsgi-plugin-python3 환경에서 MySQLdb 사용 환경
12884정성태12/20/2021476개발 환경 구성: 620. Windows 10+에서 WMI root/Microsoft/Windows/WindowsUpdate 네임스페이스 제거
12883정성태12/19/2021644오류 유형: 775. uwsgi-plugin-python3 환경에서 "ModuleNotFoundError: No module named 'django'" 오류 발생
12882정성태12/18/2021531개발 환경 구성: 619. Windows Server에서 WSL을 위한 리눅스 배포본을 설치하는 방법
12881정성태12/17/2021607개발 환경 구성: 618. WSL Ubuntu 20.04에서 파이썬을 위한 uwsgi 설치 방법 (2)
12880정성태12/16/2021602VS.NET IDE: 170. Visual Studio에서 .NET Core/5+ 역어셈블 소스코드 확인하는 방법
12879정성태12/16/20212377오류 유형: 774. Windows Server 2022 + docker desktop 설치 시 WSL 2로 선택한 경우 "Failed to deploy distro docker-desktop to ..." 오류 발생
12878정성태12/15/2021678개발 환경 구성: 617. 윈도우 WSL 환경에서 같은 종류의 리눅스를 다중으로 설치하는 방법
12877정성태12/15/2021548스크립트: 36. 파이썬 - pymysql 기본 예제 코드
12876정성태12/14/2021583개발 환경 구성: 616. Custom Sources를 이용한 Azure Monitor Metric 만들기
12875정성태12/13/2021562스크립트: 35. python - time.sleep(...) 호출 시 hang이 걸리는 듯한 문제
12874정성태12/13/2021478오류 유형: 773. shell script 실행 시 "$'\r': command not found" 오류
12873정성태12/12/2021701오류 유형: 772. 리눅스 - PATH에 등록했는데도 "command not found"가 나온다면?
12872정성태12/12/2021606개발 환경 구성: 615. GoLang과 Python 빌드가 모두 가능한 docker 이미지 만들기
12871정성태12/12/20211343오류 유형: 771. docker: Error response from daemon: OCI runtime create failed
12870정성태12/9/2021548개발 환경 구성: 614. 파이썬 - PyPI 패키지 만들기 (4) package_data 옵션
12869정성태12/8/2021644개발 환경 구성: 613. git clone 실행 시 fingerprint 묻는 단계를 생략하는 방법
12868정성태12/7/2021514오류 유형: 770. twine 업로드 시 "HTTPError: 400 Bad Request ..." 오류
12867정성태12/7/2021568개발 환경 구성: 612. 파이썬 - PyPI 패키지 만들기 (3) entry_points 옵션
12866정성태12/7/20212289오류 유형: 769. "docker build ..." 시 "failed to solve with frontend dockerfile.v0: failed to read dockerfile ..." 오류
1  2  3  4  5  6  7  [8]  9  10  11  12  13  14  15  ...