Osadzanie bibliotek DLL w skompilowanym pliku wykonywalnym

Czy można osadzić wcześniej istniejącą bibliotekę DLL w skompilowanym pliku wykonywalnym w języku C # (tak, że masz tylko jeden plik do dystrybucji)? Jeśli to możliwe, jak można to zrobić?

Zwykle nie mam nic przeciwko pozostawieniu bibliotek DLL na zewnątrz i skonfigurowaniu programu do obsługi wszystkiego, ale było kilka osób w pracy, które mnie o to pytały i szczerze mówiąc nie wiem.

Zdecydowanie polecam użyć Costura.Fody - zdecydowanie najlepszy i najłatwiejszy sposób na osadzenie zasobów w swoim zestawie. Jest dostępny jako pakiet NuGet.

Install-Package Costura.Fody

Po dodaniu go do projektu, automatycznie osadza wszystkie odniesienia skopiowane do katalogu wyjściowego do głównego zestawu. Możesz wyczyścić osadzone pliki, dodając cel do swojego projektu:

Install-CleanReferencesTarget

Będziesz także mógł określić, czy dołączyć pdb, wykluczyć niektóre zespoły, czy wyodrębnić zespoły w locie. O ile mi wiadomo, obsługiwane są również niezarządzane zestawy.

Aktualizacja

Obecnie niektóre osoby próbują dodać obsługę DNX .

Aktualizacja 2

Aby uzyskać najnowszą wersję Fody, musisz mieć MSBuild 16 (więc Visual Studio 2019). Fody w wersji 4.2.1 wykona MSBuild 15. (odniesienie: Fody jest obsługiwany tylko w MSBuild 16 i nowszych. Aktualna wersja: 15 )

Po prostu kliknij prawym przyciskiem myszy projekt w Visual Studio, wybierz Właściwości projektu -> Zasoby -> Dodaj zasób -> Dodaj istniejący plik… I dołącz poniższy kod do pliku App.xaml.cs lub równoważnego.

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

Oto mój oryginalny post na blogu: http://codeblog.larsholm.net/2011/06/embed-dlls-easily-in-a-net-assembly/

Jeśli faktycznie są one zarządzanymi zespołami, możesz użyć ILMerge . W przypadku natywnych bibliotek DLL będziesz mieć trochę więcej pracy do zrobienia.

Zobacz także: W jaki sposób można połączyć bibliotekę DLL systemu Windows w exe aplikacji C #?

Tak, można łączyć pliki wykonywalne .NET z bibliotekami. Dostępnych jest wiele narzędzi do wykonania zadania:

• ILMerge to narzędzie, którego można użyć do scalenia wielu zestawów .NET w jeden zestaw.
• Mono mkbundle , pakuje exe i wszystkie zestawy z libmono w jeden pakiet binarny.
• IL-Repack jest alternatywą FLOSS do ILMerge, z kilkoma dodatkowymi funkcjami.

Ponadto można to połączyć z Mono Linkerem , który usuwa nieużywany kod i dlatego zmniejsza wynikowy zestaw.

Inną możliwością jest użycie .NETZ , który nie tylko pozwala na kompresowanie zestawu, ale także może spakować pliki dll bezpośrednio do exe. Różnica w stosunku do wyżej wymienionych rozwiązań polega na tym, że .NETZ nie łączy ich, pozostają one oddzielnymi zespołami, ale są pakowane w jedno opakowanie.

.NETZ to narzędzie typu open source, które kompresuje i pakuje pliki wykonywalne Microsoft .NET Framework (EXE, DLL) w celu ich zmniejszenia.

ILMerge może łączyć zespoły w jeden pojedynczy zespół, pod warunkiem, że zespół ma tylko zarządzany kod. Możesz użyć aplikacji wiersza polecenia lub dodać odwołanie do pliku exe i scalić programowo. W przypadku wersji GUI dostępny jest Eazfuscator , a także .Netz, które są bezpłatne. Płatne aplikacje to BoxedApp i SmartAssembly .

Jeśli musisz scalić zestawy z niezarządzanym kodem, sugerowałbym SmartAssembly . Nigdy nie miałem czkawki z SmartAssembly, ale ze wszystkimi innymi. Tutaj może osadzić wymagane zależności jako zasoby w głównym pliku exe.

Możesz zrobić to wszystko ręcznie, nie martwiąc się, czy asemblerem zarządzany jest tryb mieszany, osadzając dll w swoich zasobach, a następnie polegając na asemblerze AppDomain ResolveHandler. Jest to kompleksowe rozwiązanie, przyjmując najgorszy przypadek, tj. Zespoły z niezarządzanym kodem.

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

Kluczem tutaj jest zapis bajtów do pliku i ładowanie z jego lokalizacji. Aby uniknąć problemu z kurczakiem i jajkiem, musisz upewnić się, że deklarujesz moduł obsługi przed uzyskaniem dostępu do zespołu i że nie masz dostępu do elementów zestawu (lub tworzenia instancji wszystkiego, co ma do czynienia z zespołem) wewnątrz części ładowania (rozwiązywania zespołu). Upewnij się również, GetMyApplicationSpecificPath()czy nie ma katalogu tymczasowego, ponieważ pliki tymczasowe mogłyby zostać usunięte przez inne programy lub przez ciebie (nie dlatego, że zostaną usunięte, gdy twój program uzyskuje dostęp do biblioteki dll, ale przynajmniej jest to uciążliwe. AppData jest dobra Lokalizacja). Zauważ też, że musisz pisać bajty za każdym razem, nie możesz załadować z lokalizacji, ponieważ biblioteka DLL już tam znajduje się.

W przypadku bibliotek DLL zarządzanych nie trzeba pisać bajtów, ale ładować bezpośrednio z lokalizacji biblioteki DLL lub po prostu czytać bajty i ładować zestaw z pamięci. Tak lub mniej:

    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.

Jeśli zestaw jest całkowicie niezarządzany, możesz zobaczyć ten link lub ten sposób ładowania takich bibliotek dll.

Fragment Jeffrey Richter jest bardzo dobra. Krótko mówiąc, dodaj bibliotekę jako zasoby osadzone i dodaj wywołanie zwrotne, zanim cokolwiek innego. Oto wersja kodu (znaleziona w komentarzach na jego stronie), którą umieściłem na początku metody Main dla aplikacji konsolowej (po prostu upewnij się, że wszystkie wywołania, które korzystają z biblioteki, są inne niż 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);
            }
        };

Aby rozwinąć odpowiedź @ Bobby powyżej. Możesz edytować plik .csproj, aby użyć IL-Repack do automatycznego pakowania wszystkich plików w jeden zestaw podczas kompilacji.

1. Zainstaluj pakiet nuget ILRepack.MSBuild.Task za pomocą Install-Package ILRepack.MSBuild.Task
2. Edytuj sekcję AfterBuild w .csproj

Oto prosta próbka, która łączy PrzykładAssemblyToMerge.dll z danymi wyjściowymi projektu.

<!-- 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>

Możesz dodać biblioteki DLL jako zasoby osadzone, a następnie pozwolić programowi rozpakować je w katalogu aplikacji podczas uruchamiania (po sprawdzeniu, czy już tam są).

Pliki instalacyjne są jednak tak łatwe do zrobienia, że ​​nie sądzę, by było warto.

EDYCJA: Ta technika byłaby łatwa w przypadku zespołów .NET. W przypadku bibliotek DLL innych niż .NET byłoby o wiele więcej pracy (trzeba by dowiedzieć się, gdzie rozpakować pliki i zarejestrować je itd.).

Kolejnym produktem, który potrafi poradzić sobie z tym elegancko, jest SmartAssembly, na SmartAssembly.com . Ten produkt oprócz połączenia wszystkich zależności w jedną bibliotekę DLL (opcjonalnie) zaciemni kod, usunie dodatkowe metadane, aby zmniejszyć rozmiar pliku wynikowego, a także może faktycznie zoptymalizować IL w celu zwiększenia wydajności środowiska wykonawczego.

Istnieje także rodzaj globalnej obsługi wyjątków / raportowania, który dodaje do twojego oprogramowania (w razie potrzeby), który może być przydatny. Wierzę, że ma również interfejs API wiersza polecenia, dzięki czemu możesz włączyć go do procesu kompilacji.

Ani podejście ILMerge, ani Lars Holm Jensen obsługujący zdarzenie AssemblyResolve nie będą działać dla hosta wtyczek. Powiedz, że wykonywalny H ładuje dynamicznie zestaw P i uzyskuje do niego dostęp poprzez interfejs IP zdefiniowany w oddzielnym zestawie. Aby osadzić IP w H , potrzebna jest niewielka modyfikacja kodu Larsa:

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

Sztuczka związana z powtarzającymi się próbami rozwiązania tego samego zestawu i zwrócenia istniejącego zamiast tworzenia nowej instancji.

EDYCJA: Aby nie zepsuć serializacji .NET, pamiętaj, aby zwrócić wartość null dla wszystkich zestawów, które nie są osadzone w twoim, w ten sposób zachowując domyślne zachowanie. Możesz uzyskać listę tych bibliotek poprzez:

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

i po prostu zwróć null, jeśli przekazany zestaw nie należy do IncludedAssemblies.

.NET Core 3.0 natywnie obsługuje kompilację do pojedynczego pliku .exe

Ta funkcja jest włączona przez użycie następującej właściwości w pliku projektu (.csproj):

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

Odbywa się to bez zewnętrznego narzędzia.

Aby uzyskać więcej informacji, zobacz moją odpowiedź na to pytanie .

Może się to wydawać uproszczone, ale WinRar daje możliwość kompresji kilku plików do samorozpakowującego się pliku wykonywalnego.
Ma wiele konfigurowalnych opcji: ikona końcowa, wypakuj pliki do podanej ścieżki, plik do wykonania po rozpakowaniu, niestandardowe logo / teksty dla wyskakującego okienka wyświetlanego podczas wyodrębniania, w ogóle nie wyskakujące okno, tekst umowy licencyjnej itp.
Może być przydatny w niektórych przypadkach .

Używam kompilatora csc.exe wywoływanego ze skryptu .vbs.

W skrypcie xyz.cs dodaj następujące wiersze po dyrektywach (mój przykład dotyczy 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"

Znaczniki ref, res i ico zostaną pobrane przez poniższy skrypt .vbs w celu utworzenia polecenia csc.

Następnie dodaj wywoływacz resolvera zestawu w Main:

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

... i dodaj sam resolver gdzieś w klasie:

    static Assembly CurrentDomain_AssemblyResolve (nadawca obiektu, Argumenty ResolveEventArgs)
    {
        Łańcuch nazwa_zasobu = nowa nazwa_zespołu (args.Name). Nazwa + ".dll";

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

    }

Nazywam skrypt vbs, aby pasował do nazwy pliku .cs (np. Ssh.vbs szuka ssh.cs); dzięki temu uruchamianie skryptu wiele razy jest dużo łatwiejsze, ale jeśli nie jesteś idiotą takim jak ja, ogólny skrypt może pobrać docelowy plik .cs z przeciągania i upuszczania:

    Dim name_, oShell, fso
    Ustaw oShell = CreateObject („Shell.Application”)
    Ustaw fso = CreateObject („Scripting.fileSystemObject”)

    „WEŹ NAZWĘ SKRYPTU VBS JAKO NAZWĘ PLIKU CELOWEGO
    „#############################################################################
    name_ = Split (wscript.ScriptName, ".") (0)

    „POBIERZ NAZWY ZEWNĘTRZNYCH DLL I IKONY Z PLIKU .CS
    „####################################################################### ######
    Stała OPEN_FILE_FOR_READING = 1
    Ustaw objInputFile = fso.OpenTextFile (name_ & ".cs", 1)

    „PRZECZYTAJ WSZYSTKO W MIEJSCU
    „#############################
    inputData = Split (objInputFile.ReadAll, vbNewline)

    Dla każdego strData w inputData

        jeśli pozostało (strData, 7) = "// + ref>", to 
            csc_references = csc_references & "/ reference:" & trim (replace (strData, "// + ref>", "")) & ""
        koniec jeśli

        jeśli pozostało (strData, 7) = "// + res>", to 
            csc_resources = csc_resources & "/ resource:" & trim (replace (strData, "// + res>", "")) & ""
        koniec jeśli

        jeśli pozostało (strData, 7) = "// + ico>", to 
            csc_icon = "/ win32icon:" & trim (replace (strData, "// + ico>", "")) & ""
        koniec jeśli
    Kolejny

    objInputFile.Close


    „SKompiluj plik
    „################
    oShell.ShellExecute "c: \ windows \ microsoft.net \ framework \ v3.5 \ csc.exe", "/ warn: 1 / target: exe" i csc_references & csc_resources & csc_icon & "" & name_ & ".cs" , „”, „runas”, 2


    WScript.Quit (0)

Utworzenie hybrydowego zestawu natywnego / zarządzanego w języku C # jest możliwe, ale nie takie proste. Gdybyś zamiast tego używał C ++, byłoby to o wiele łatwiejsze, ponieważ kompilator Visual C ++ może tworzyć zespoły hybrydowe równie łatwo, jak wszystko inne.

O ile nie masz ścisłego wymogu wyprodukowania zestawu hybrydowego, zgodziłbym się z MusiGenesis, że nie jest to warte zachodu z C #. Jeśli musisz to zrobić, możesz zamiast tego przejść do C ++ / CLI.

Zasadniczo potrzebujesz jakiejś formy narzędzia po kompilacji, aby wykonać scalanie zespołu, tak jak to opisujesz. Istnieje bezpłatne narzędzie o nazwie Eazfuscator (eazfuscator.blogspot.com/), które jest przeznaczone do manipulacji kodem bajtowym, która obsługuje także scalanie zestawu. Możesz dodać to do wiersza poleceń po kompilacji w programie Visual Studio, aby scalić swoje zespoły, ale twój przebieg będzie się różnił z powodu problemów, które pojawią się w każdym nietypowym scenariuszu scalania zespołu.

Możesz również sprawdzić, czy kompilacja czyni nieistotność NANT ma możliwość scalania zestawów po zbudowaniu, ale sam nie znam wystarczająco NANT, aby stwierdzić, czy funkcjonalność jest wbudowana, czy nie.

Istnieje również wiele wtyczek Visual Studio, które wykonają scalanie zestawu w ramach budowania aplikacji.

Alternatywnie, jeśli nie trzeba tego robić automatycznie, istnieje wiele narzędzi, takich jak ILMerge, które scalą zespoły .net w jeden plik.

Największym problemem, jaki miałem przy scalaniu zestawów, jest to, że używają podobnych przestrzeni nazw. Lub gorzej, odwołaj się do różnych wersji tego samego dll (moje problemy były ogólnie z plikami dll NUnit).