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)
12751정성태8/4/2021342개발 환경 구성: 591. Windows 10 WSL2 환경에서 docker-compose 빌드하는 방법
12750정성태8/3/2021225디버깅 기술: 181. windbg - 콜 스택의 "Call Site" 오프셋 값이 가리키는 위치
12749정성태8/2/2021252개발 환경 구성: 590. Visual Studio 2017부터 단위 테스트에 DataRow 특성 지원
12748정성태8/2/2021185개발 환경 구성: 589. Azure Active Directory - tenant의 관리자(admin) 계정 로그인 방법
12747정성태8/1/2021206오류 유형: 748. 오류 기록 - MICROSOFT GRAPH – HOW TO IMPLEMENT IAUTHENTICATIONPROVIDER파일 다운로드1
12746정성태7/31/2021377개발 환경 구성: 588. 네트워크 장비 환경을 시뮬레이션하는 Packet Tracer 프로그램 소개
12745정성태7/31/2021186개발 환경 구성: 587. Azure Active Directory - tenant의 관리자 계정 로그인 방법
12744정성태7/30/2021188개발 환경 구성: 586. Azure Active Directory에 연결된 App 목록을 확인하는 방법?
12743정성태7/30/2021240.NET Framework: 1083. Azure Active Directory - 외부 Token Cache 저장소를 사용하는 방법파일 다운로드1
12742정성태7/30/2021259개발 환경 구성: 585. Azure AD 인증을 위한 사용자 인증 유형
12741정성태7/29/2021242.NET Framework: 1082. Azure Active Directory - Microsoft Graph API 호출 방법파일 다운로드1
12740정성태7/29/2021266오류 유형: 747. SharePoint - InvalidOperationException 0x80131509
12739정성태7/28/2021279오류 유형: 746. Azure Active Directory - IDW10106: The 'ClientId' option must be provided.
12738정성태7/28/2021399오류 유형: 745. Azure Active Directory - Client credential flows must have a scope value with /.default suffixed to the resource identifier (application ID URI).
12737정성태7/28/2021268오류 유형: 744. Azure Active Directory - The resource principal named api://...[client_id]... was not found in the tenant
12736정성태7/28/2021241오류 유형: 743. Active Azure Directory에서 "API permissions"의 권한 설정이 "Not granted for ..."로 나오는 문제
12735정성태7/27/2021318.NET Framework: 1081. C# - Azure AD 인증을 지원하는 데스크톱 애플리케이션 예제(Windows Forms)파일 다운로드1
12734정성태7/26/2021588스크립트: 20. 특정 단어로 시작하거나/끝나는 문자열을 포함/제외하는 정규 표현식 - Look-around
12733정성태7/23/2021276.NET Framework: 1081. Self-Contained/SingleFile 유형의 .NET Core/5+ 실행 파일을 임베딩한다면?파일 다운로드2
12732정성태7/23/2021197오류 유형: 742. SharePoint - The super user account utilized by the cache is not configured.
12731정성태7/23/2021212개발 환경 구성: 584. Add Internal URLs 화면에서 "Save" 버튼이 비활성화 된 경우
12730정성태7/23/2021307개발 환경 구성: 583. Visual Studio Code - Go 코드에서 입력을 받는 경우
12729정성태7/22/2021258.NET Framework: 1080. xUnit 단위 테스트에 메서드/클래스 수준의 문맥 제공 - Fixture
12728정성태7/22/2021226.NET Framework: 1079. MSTestv2 단위 테스트에 메서드/클래스/어셈블리 수준의 문맥 제공
12727정성태7/21/2021344.NET Framework: 1078. C# 단위 테스트 - MSTestv2/NUnit의 Assert.Inconclusive 사용법(?)
12726정성태7/21/2021325VS.NET IDE: 169. 비주얼 스튜디오 - 단위 테스트 선택 시 MSTestv2 외의 xUnit, NUnit 사용법
1  2  3  4  [5]  6  7  8  9  10  11  12  13  14  15  ...