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

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

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

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

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

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

Возможно, но не так просто, создать гибридную собственную / управляемую сборку на C#. Если бы вы использовали C++ вместо этого, было бы намного проще, поскольку компилятор Visual C++ может создавать гибридные сборки так же легко, как и все остальное.

Если у вас нет строгих требований к созданию гибридной сборки, я согласен с MusiGenesis, что на самом деле это не стоит того, чтобы делать с C#. Если вам нужно это сделать, возможно, лучше подумайте о переходе на C++ / CLI.

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

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

Как правило, для выполнения слияния сборок, как вы описываете, вам понадобится какой-то инструмент для пост-сборки. Существует бесплатный инструмент под названием Eazfuscator (eazfuscator.blogspot.com/), предназначенный для изменения байт-кода, который также обрабатывает слияние сборок. Вы можете добавить это в командную строку после сборки с помощью Visual Studio, чтобы объединить ваши сборки, но ваш опыт будет варьироваться из-за проблем, которые возникнут в любых сценариях слияния нетривиальных сборок.

Вы также можете проверить, имеет ли NANT возможность объединять сборки после сборки, но я недостаточно хорошо знаком с NANT, чтобы сказать, встроена ли эта функция или нет.

Также существует множество подключаемых модулей Visual Studio, которые будут выполнять слияние сборок как часть сборки приложения.

В качестве альтернативы, если вам не нужно, чтобы это выполнялось автоматически, существует ряд инструментов, таких как ILMerge, которые объединят сборки .net в один файл.

Самая большая проблема, с которой я столкнулся при слиянии сборок, - это то, используют ли они какие-либо похожие пространства имен. Или, что еще хуже, ссылаться на разные версии одной и той же dll (мои проблемы обычно были с файлами dll NUnit).

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

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

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

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

.NETZ is a open source tool that compresses and packs the Microsoft .NET Framework executable (EXE, DLL) files in order to make them smaller.

Просто щелкните свой проект в 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 может объединять сборки в одну сборку при условии, что сборка имеет только управляемый код. Вы можете использовать приложение командной строки или добавить ссылку на 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, но, по крайней мере, это неприятно. хорошее расположение). Также обратите внимание, что вам нужно записывать байты каждый раз, вы не можете загружать из местоположения только потому, что 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.

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

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.

отрывок Джеффри Рихтера очень хорошо. Короче говоря, добавьте библиотеку как встроенные ресурсы и добавьте обратный вызов прежде всего. Вот версия кода (найдена в комментариях к его странице), которую я поместил в начале метода 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);
            }
        };

Я настоятельно рекомендую использовать 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)

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

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

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>

Я использую компилятор csc.exe, вызываемый из сценария .vbs.

В вашем скрипте xyz.cs добавьте следующие строки после директив (мой пример для Renci SSH):

using System;
using Renci;//FOR THE SSH
using System.Net;//FOR THE ADDRESS TRANSLATION
using System.Reflection;//FOR THE Assembly

//+ref>"C:\Program Files (x86)\Microsoft\ILMerge\Renci.SshNet.dll"
//+res>"C:\Program Files (x86)\Microsoft\ILMerge\Renci.SshNet.dll"
//+ico>"C:\Program Files (x86)\Microsoft CAPICOM 2.1.0.2 SDK\Samples\c_sharp\xmldsig\resources\Traffic.ico"

Теги ref, res и ico будут взяты приведенным ниже сценарием .vbs для формирования команды csc.

Затем добавьте вызывающий преобразователь сборки в Main:

public static void Main(string[] args)
{
    AppDomain.CurrentDomain.AssemblyResolve += new ResolveEventHandler(CurrentDomain_AssemblyResolve);
    .

... и добавьте сам резолвер где-нибудь в классе:

    static Assembly CurrentDomain_AssemblyResolve(object sender, ResolveEventArgs args)
    {
        String resourceName = new AssemblyName(args.Name).Name + ".dll";

        using (var stream = Assembly.GetExecutingAssembly().GetManifestResourceStream(resourceName))
        {
            Byte[] assemblyData = new Byte[stream.Length];
            stream.Read(assemblyData, 0, assemblyData.Length);
            return Assembly.Load(assemblyData);
        }

    }

Я называю сценарий vbs, чтобы он соответствовал имени файла .cs (например, ssh.vbs ищет ssh.cs); это многократно упрощает выполнение сценария, но если вы не такой идиот, как я, то общий сценарий может выбрать целевой файл .cs путем перетаскивания:

    Dim name_,oShell,fso
    Set oShell = CreateObject("Shell.Application")
    Set fso = CreateObject("Scripting.fileSystemObject")

    'TAKE THE VBS SCRIPT NAME AS THE TARGET FILE NAME
    '################################################
    name_ = Split(wscript.ScriptName, ".")(0)

    'GET THE EXTERNAL DLL's AND ICON NAMES FROM THE .CS FILE
    '#######################################################
    Const OPEN_FILE_FOR_READING = 1
    Set objInputFile = fso.OpenTextFile(name_ & ".cs", 1)

    'READ EVERYTHING INTO AN ARRAY
    '#############################
    inputData = Split(objInputFile.ReadAll, vbNewline)

    For each strData In inputData

        if left(strData,7) = "//+ref>" then 
            csc_references = csc_references & " /reference:" &         trim(replace(strData,"//+ref>","")) & " "
        end if

        if left(strData,7) = "//+res>" then 
            csc_resources = csc_resources & " /resource:" & trim(replace(strData,"//+res>","")) & " "
        end if

        if left(strData,7) = "//+ico>" then 
            csc_icon = " /win32icon:" & trim(replace(strData,"//+ico>","")) & " "
        end if
    Next

    objInputFile.Close


    'COMPILE THE FILE
    '################
    oShell.ShellExecute "c:\windows\microsoft.net\framework\v3.5\csc.exe", "/warn:1 /target:exe " & csc_references & csc_resources & csc_icon & " " & name_ & ".cs", "", "runas", 2


    WScript.Quit(0)

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

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

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

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

См. Мой ответ на этот вопрос для получения дополнительной информации.

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

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

Когда у вас много DLL, может быть сложно вручную включить ту, которая вам нужна в исполняемый файл. Лучший метод, который я нашел, был объяснен Wegged здесь, в StackOverflow.

Скопируйте сюда его ответ для ясности (все кредиты Wegged)

1) Добавьте это в свой файл .csproj:

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

2) Сделайте так, чтобы ваш основной Program.cs выглядел так:

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

3) Добавьте метод OnResolveAssembly:

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);
    }
}