Встраивание DLL в скомпилированный исполняемый файл

Я настоятельно рекомендую использовать Costura.Fody - безусловно, лучший и самый простой способ встраивать ресурсы в вашу сборку. Он доступен как пакет NuGet.

Install-Package Costura.Fody

После добавления в проект он автоматически вставит все ссылки, которые копируются в выходной каталог, в вашу основную сборку. Возможно, вы захотите очистить встроенные файлы, добавив цель в свой проект:

Install-CleanReferencesTarget

Вы также сможете указать, следует ли включать pdb, исключать определенные сборки или извлекать сборки на лету. Насколько мне известно, поддерживаются и неуправляемые сборки.

Обновить

В настоящее время некоторые люди пытаются добавить поддержку DNX.

Обновление 2

Для последней версии Fody вам потребуется MSBuild 16 (то есть Visual Studio 2019). Fody версии 4.2.1 будет выполнять MSBuild 15. (ссылка: Fody поддерживается только в MSBuild 16 и более поздних версиях. Текущая версия: 15)

Просто щелкните свой проект правой кнопкой мыши в Visual Studio, выберите «Свойства проекта» -> «Ресурсы» -> «Добавить ресурс» -> «Добавить существующий файл…» и включите приведенный ниже код в свой App.xaml.cs или аналогичный.

public App()
{
    AppDomain.CurrentDomain.AssemblyResolve +=new ResolveEventHandler(CurrentDomain_AssemblyResolve);
}

System.Reflection.Assembly CurrentDomain_AssemblyResolve(object sender, ResolveEventArgs args)
{
    string dllName = args.Name.Contains(',') ? args.Name.Substring(0, args.Name.IndexOf(',')) : args.Name.Replace(".dll","");

    dllName = dllName.Replace(".", "_");

    if (dllName.EndsWith("_resources")) return null;

    System.Resources.ResourceManager rm = new System.Resources.ResourceManager(GetType().Namespace + ".Properties.Resources", System.Reflection.Assembly.GetExecutingAssembly());

    byte[] bytes = (byte[])rm.GetObject(dllName);

    return System.Reflection.Assembly.Load(bytes);
}

Вот моя исходная запись в блоге: http://codeblog.larsholm.net/2011/06/embed-dlls-easily-in-a-net-assembly/

Если это действительно управляемые сборки, вы можете использовать ILMerge. Для нативных DLL вам придется немного поработать.

См. также: Как можно объединить dll Windows C ++ с исполняемым файлом приложения C #?

Да, можно объединять исполняемые файлы .NET с библиотеками. Для выполнения этой работы доступно несколько инструментов:

• ILMerge - это служебная программа, которую можно использовать для объединения нескольких сборок .NET в одну сборку.
• Mono mkbundle, упаковывает exe и все сборки с libmono в один бинарный пакет.
• IL-Repack является альтернативой ILMerge FLOSS с некоторыми дополнительными функциями.

Кроме того, это можно комбинировать с Mono Linker, который удаляет неиспользуемый код и, следовательно, делает в результате сборка поменьше.

Другая возможность - использовать .NETZ, который не только позволяет сжимать сборку, но также может упаковать DLL прямо в exe. Отличие от вышеупомянутых решений заключается в том, что .NETZ не объединяет их, они остаются отдельными сборками, а упаковываются в один пакет.

.NETZ - это инструмент с открытым исходным кодом, который сжимает и упаковывает исполняемые файлы Microsoft .NET Framework (EXE, DLL), чтобы уменьшить их размер.

ILMerge может объединять сборки в одну единственную сборку при условии сборка имеет только управляемый код. Вы можете использовать приложение командной строки или добавить ссылку на exe и программно слить. Для версии с графическим интерфейсом есть Eazfuscator, а также .Netz, оба из которых бесплатны. Платные приложения включают BoxedApp и SmartAssembly.

Если вам нужно объединить сборки с неуправляемым кодом, я бы предложил SmartAssembly. У меня никогда не было проблем с SmartAssembly, но со всеми остальными. Здесь он может встроить необходимые зависимости в качестве ресурсов в ваш основной исполняемый файл.

Вы можете сделать все это вручную, не беспокоясь о том, управляется ли сборка или в смешанном режиме, путем встраивания dll в свои ресурсы и последующего использования сборки ResolveHandler AppDomain. Это универсальное решение, основанное на худшем случае, то есть сборках с неуправляемым кодом.

static void Main()
{
    AppDomain.CurrentDomain.AssemblyResolve += (sender, args) =>
    {
        string assemblyName = new AssemblyName(args.Name).Name;
        if (assemblyName.EndsWith(".resources"))
            return null;

        string dllName = assemblyName + ".dll";
        string dllFullPath = Path.Combine(GetMyApplicationSpecificPath(), dllName);

        using (Stream s = Assembly.GetEntryAssembly().GetManifestResourceStream(typeof(Program).Namespace + ".Resources." + dllName))
        {
            byte[] data = new byte[stream.Length];
            s.Read(data, 0, data.Length);

            //or just byte[] data = new BinaryReader(s).ReadBytes((int)s.Length);

            File.WriteAllBytes(dllFullPath, data);
        }

        return Assembly.LoadFrom(dllFullPath);
    };
}

Ключевым моментом здесь является запись байтов в файл и загрузка из его местоположения. Чтобы избежать проблем с курицей и яйцом, вы должны убедиться, что вы объявили обработчик перед доступом к сборке и что вы не имеете доступа к элементам сборки (или не создаете экземпляры чего-либо, что имеет дело со сборкой) внутри части загрузки (разрешения сборки). Также убедитесь, что GetMyApplicationSpecificPath() не является временным каталогом, поскольку временные файлы могут быть удалены другими программами или вами (не то, чтобы они были удалены, пока ваша программа обращается к dll, но, по крайней мере, это неприятно. AppData хорошее расположение). Также обратите внимание, что вам нужно записывать байты каждый раз, вы не можете загружать из местоположения только потому, что dll уже находится там.

Для управляемых dll вам нужно не записывать байты, а загружать напрямую из местоположения dll или просто читать байты и загружать сборку из памяти. Примерно так:

    using (Stream s = Assembly.GetEntryAssembly().GetManifestResourceStream(typeof(Program).Namespace + ".Resources." + dllName))
    {
        byte[] data = new byte[stream.Length];
        s.Read(data, 0, data.Length);
        return Assembly.Load(data);
    }

    //or just

    return Assembly.LoadFrom(dllFullPath); //if location is known.

Если сборка полностью неуправляемая, вы можете увидеть эту ссылку или это как как загружать такие dll.

Отрывок Джеффри Рихтера очень хорош. Короче говоря, добавьте библиотеку как встроенные ресурсы и добавьте обратный вызов прежде всего. Вот версия кода (найденная в комментариях к его странице), которую я поместил в начале метода Main для консольного приложения (просто убедитесь, что все вызовы, которые используют библиотеку, находятся в другом методе, чем Main).

AppDomain.CurrentDomain.AssemblyResolve += (sender, bargs) =>
        {
            String dllName = new AssemblyName(bargs.Name).Name + ".dll";
            var assem = Assembly.GetExecutingAssembly();
            String resourceName = assem.GetManifestResourceNames().FirstOrDefault(rn => rn.EndsWith(dllName));
            if (resourceName == null) return null; // Not found, maybe another handler will find it
            using (var stream = assem.GetManifestResourceStream(resourceName))
            {
                Byte[] assemblyData = new Byte[stream.Length];
                stream.Read(assemblyData, 0, assemblyData.Length);
                return Assembly.Load(assemblyData);
            }
        };

Чтобы расширить @ Bobby asnwer выше. Вы можете отредактировать свой .csproj, чтобы использовать IL-Repack для автоматической упаковки всех файлов в один сборка при сборке.

1. Установите пакет nuget ILRepack.MSBuild.Task с Install-Package ILRepack.MSBuild.Task
2. Отредактируйте раздел AfterBuild вашего .csproj

Вот простой пример, который объединяет ExampleAssemblyToMerge.dll с выходными данными вашего проекта.

<!-- ILRepack -->
<Target Name="AfterBuild" Condition="'$(Configuration)' == 'Release'">

   <ItemGroup>
    <InputAssemblies Include="$(OutputPath)\$(AssemblyName).exe" />
    <InputAssemblies Include="$(OutputPath)\ExampleAssemblyToMerge.dll" />
   </ItemGroup>

   <ILRepack 
    Parallel="true"
    Internalize="true"
    InputAssemblies="@(InputAssemblies)"
    TargetKind="Exe"
    OutputFile="$(OutputPath)\$(AssemblyName).exe"
   />
</Target>

.NET Core 3.0 изначально поддерживает компиляцию в один EXE-файл.

Эта функция включается при использовании следующего свойства в файле проекта (.csproj):

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

Это делается без каких-либо внешних инструментов.

Дополнительную информацию см. В моем ответе на этот вопрос.

Вы можете добавить библиотеки DLL в качестве встроенных ресурсов, а затем попросить вашу программу распаковать их в каталог приложения при запуске (после проверки, есть ли они уже там).

Однако файлы установки создать настолько легко, что я не думаю, что это того стоит.

РЕДАКТИРОВАТЬ: этот метод будет легко использовать со сборками .NET. С библиотеками DLL, отличными от .NET, было бы намного больше работы (вам нужно было бы выяснить, где распаковать файлы, зарегистрировать их и т. Д.).

Еще один продукт, который может с этим элегантно справиться, - это SmartAssembly, доступный по адресу SmartAssembly.com. Этот продукт, помимо объединения всех зависимостей в единую DLL, (необязательно) обфусцирует ваш код, удаляет лишние метаданные, чтобы уменьшить итоговый размер файла, а также может фактически оптимизировать IL для повышения производительности во время выполнения.

Существует также какая-то функция глобальной обработки исключений / отчетов, которую он добавляет в ваше программное обеспечение (при желании), что может быть полезно. Я считаю, что у него также есть API командной строки, поэтому вы можете сделать его частью процесса сборки.

Ни подход ILMerge, ни обработка события AssemblyResolve Ларсом Холмом Дженсеном не будут работать для хоста плагина. Скажем, исполняемый файл H загружает сборку P динамически и обращается к ней через интерфейс IP, определенный в отдельной сборке. Чтобы встроить IP в H, потребуется небольшая модификация кода Ларса:

Dictionary<string, Assembly> loaded = new Dictionary<string,Assembly>();
AppDomain.CurrentDomain.AssemblyResolve += (sender, args) =>
{   Assembly resAssembly;
    string dllName = args.Name.Contains(",") ? args.Name.Substring(0, args.Name.IndexOf(',')) : args.Name.Replace(".dll","");
    dllName = dllName.Replace(".", "_");
    if ( !loaded.ContainsKey( dllName ) )
    {   if (dllName.EndsWith("_resources")) return null;
        System.Resources.ResourceManager rm = new System.Resources.ResourceManager(GetType().Namespace + ".Properties.Resources", System.Reflection.Assembly.GetExecutingAssembly());
        byte[] bytes = (byte[])rm.GetObject(dllName);
        resAssembly = System.Reflection.Assembly.Load(bytes);
        loaded.Add(dllName, resAssembly);
    }
    else
    {   resAssembly = loaded[dllName];  }
    return resAssembly;
};  

Уловка для обработки повторяющихся попыток разрешить одну и ту же сборку и вернуть существующую вместо создания нового экземпляра.

РЕДАКТИРОВАТЬ: Чтобы это не испортило сериализацию .NET, убедитесь, что возвращено значение null для всех сборок, не встроенных в вашу, что приведет к стандартному поведению по умолчанию. Вы можете получить список этих библиотек:

static HashSet<string> IncludedAssemblies = new HashSet<string>();
string[] resources = System.Reflection.Assembly.GetExecutingAssembly().GetManifestResourceNames();
for(int i = 0; i < resources.Length; i++)
{   IncludedAssemblies.Add(resources[i]);  }

и просто верните null, если переданная сборка не принадлежит IncludedAssemblies.

Следующий метод НЕ ИСПОЛЬЗУЙТЕ внешние инструменты и АВТОМАТИЧЕСКИ включайте все необходимые DLL (никаких действий вручную не требуется, все делается при компиляции)

Я читал здесь много ответов, в которых говорилось об использовании методов ILMerge, ILRepack или Джеффри Ритчера, но ни один из них не работал с приложениями WPF < / em> И пользоваться им было непросто.

<Target Name="AfterResolveReferences">
  <ItemGroup>
    <EmbeddedResource Include="@(ReferenceCopyLocalPaths)" Condition="'%(ReferenceCopyLocalPaths.Extension)' == '.dll'">
      <LogicalName>%(ReferenceCopyLocalPaths.DestinationSubDirectory)%(ReferenceCopyLocalPaths.Filename)%(ReferenceCopyLocalPaths.Extension)</LogicalName>
    </EmbeddedResource>
  </ItemGroup>
</Target>

[STAThreadAttribute]
public static void Main()
{
    AppDomain.CurrentDomain.AssemblyResolve += OnResolveAssembly;
    App.Main();
}

private static Assembly OnResolveAssembly(object sender, ResolveEventArgs args)
{
    Assembly executingAssembly = Assembly.GetExecutingAssembly();
    AssemblyName assemblyName = new AssemblyName(args.Name);

    var path = assemblyName.Name + ".dll";
    if (assemblyName.CultureInfo.Equals(CultureInfo.InvariantCulture) == false) path = String.Format(@"{0}\{1}", assemblyName.CultureInfo, path);

    using (Stream stream = executingAssembly.GetManifestResourceStream(path))
    {
        if (stream == null) return null;

        var assemblyRawBytes = new byte[stream.Length];
        stream.Read(assemblyRawBytes, 0, assemblyRawBytes.Length);
        return Assembly.Load(assemblyRawBytes);
    }
}