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>
그럼, (
Native 로더 및 런타임을 포함해야 하니) 약 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은 이 글의 예제 프로젝트를 포함합니다.)
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]