Osadzanie zespołów wewnątrz innego zespołu

ILMerge łączy zespoły, co jest miłe, ale czasami nie do końca to, czego chcesz. Na przykład, jeśli dany zespół jest ściśle nazwany, a nie masz do niego klucza, nie możesz wykonać ILMerge bez złamania tego podpisu. Co oznacza, że musisz wdrożyć wiele zespołów.

Jako alternatywa dla ilmerge, możesz osadzić jeden lub więcej zestawów jako zasoby w exe lub DLL. Następnie, w czasie wykonywania, gdy składy są ładowane, można programowo rozpakuj osadzony zespół, załaduj go i uruchom. To brzmi skomplikowanie, ale jest tylko trochę kodu boilerplate.

Aby to zrobić, osadzić zespół, tak jak osadzić każdy inny zasób (obraz, plik tłumaczenia, dane itp.). Następnie skonfiguruj AssemblyResolver, który zostanie wywołany w czasie wykonywania. Powinien być ustawiony w statycznym konstruktorze klasy startowej. Kod jest bardzo prosty.

    static NameOfStartupClassHere()
    {
        AppDomain.CurrentDomain.AssemblyResolve += new ResolveEventHandler(Resolver);
    }

    static System.Reflection.Assembly Resolver(object sender, ResolveEventArgs args)
    {
        Assembly a1 = Assembly.GetExecutingAssembly();
        Stream s = a1.GetManifestResourceStream(args.Name);
        byte[] block = new byte[s.Length];
        s.Read(block, 0, block.Length);
        Assembly a2 = Assembly.Load(block);
        return a2;
    }

Właściwość Name w parametrze ResolveEventArgs jest nazwa zgromadzenia, które ma zostać rozwiązane. Ta nazwa odnosi się do zasobu, a nie do nazwy pliku. Jeśli osadzono plik o nazwie " MyAssembly.dll "i wywołać osadzony zasób "Foo" , a następnie nazwa, którą chcesz tutaj jest "Foo". Ale to byłoby mylące, więc sugeruję użycie nazwy pliku Złożenia dla nazwy zasobu. Jeśli osadzono i nazwałeś swój zespół poprawnie, możesz po prostu wywołać metodę GetManifestResourceStream () z nazwą złożenia i załadować w ten sposób. Bardzo proste.

Działa to z wieloma złożeniami, tak samo dobrze jak z pojedynczym osadzonym złożeniem.

W prawdziwej aplikacji będziesz potrzebował lepszej obsługi błędów w tej rutynie - na przykład co, jeśli nie ma strumienia o danej nazwie? Co się stanie, jeśli odczyt się nie powiedzie? itd. Ale to pozostało do zrobienia.

W pozostałej części kodu aplikacji, types from the assembly są używane normalnie.

Kiedy budujesz aplikację, musisz dodać odniesienie do danego zestawu, ponieważ normalnie. Jeśli używasz narzędzi wiersza poleceń, użyj opcji /r W csc.exe; jeśli używasz Visual Studio, musisz " dodać odniesienie..."w menu podręcznym projektu.

Podczas wykonywania, sprawdzanie i weryfikacja wersji assembly działa jak zwykle.

Jedyna różnica polega na rozkładzie. Gdy wdrażasz lub rozpowszechniasz aplikację, nie musisz rozpowszechniać biblioteki DLL dla osadzonego (i odwoływanego) zestawu. Wystarczy wdrożyć główny zespół; nie ma potrzeby rozprowadzania drugiego złożeń, ponieważ są one osadzone w głównej DLL lub EXE.

Możesz osadzić assembly (lub dowolny plik) jako zasób (a następnie użyć klasy ResourceManager, aby uzyskać do nich dostęp), ale jeśli chcesz po prostu połączyć Assembly, lepiej użyć narzędzia takiego jak ILMerge .

Uwaga ILMerge nie działa z wbudowanymi zasobami, takimi jak XAML, więc aplikacje WPF itp. będą musiały użyć metody Cheeso.

Istnieje również narzędzie mkbundle oferowane przez projekt Mono

Dlaczego używają tego samego formatu pliku i / lub rozszerzenia pliku?

Dlaczego miałoby być inaczej - służy temu samemu celowi!

Moje 2¢ trochę wyjaśnienia tutaj: DLL jest dynamiczna biblioteka Link. Oba w starym stylu .dll (kod C) i styl .NET.dll są z definicji bibliotekami "dynamic link". Więc .dll jest właściwym Opisem dla obu.

W odniesieniu do odpowiedzi Cheeso na osadzanie złożeń jako zasobów i ładowanie ich dynamicznie przy użyciu przeładowania Load(byte []) przy użyciu obsługi zdarzenia AssemblyResolve, musisz zmodyfikować rozwiązanie, aby sprawdzić AppDomain, czy istniejąca instancja złożeń ładuje się i zwraca istniejącą instancję złożeń, jeśli jest już załadowana.

Assemblies loaded using that overload does not have a context, which can cause the framework to try and reload the assembly multiple razy. Bez zwracania już załadowanej instancji, można skończyć z wieloma instancjami tego samego kodu złożeń i typów, które powinny być równe, ale nie będą, ponieważ framework uważa, że pochodzą z dwóch różnych złożeń.

Co najmniej jednym ze sposobów, w jaki zostanie wykonane wiele zdarzeń AssemblyResolve dla tego samego zestawu załadowanego do kontekstu "No", jest to, że masz odwołania do typów, które wystawia z wielu zestawów załadowanych do Twojej AppDomain, ponieważ kod wykonuje to, czego potrzebujesz te typy rozwiązały się.

Https://msdn.microsoft.com/en-us/library/dd153782%28v=vs.110%29.aspx

Kilka istotnych punktów z linku:

" Inne złożenia nie mogą wiązać się z złożeniami, które są ładowane bez kontekstu, chyba że obsługujesz AppDomain.AssemblyResolve event "

" wczytywanie wielu zestawów o tej samej tożsamości bez kontekstu może powodować problemy z tożsamością typu podobne do tych powodowanych przez wczytywanie zestawów o tej samej tożsamości do wiele kontekstów. Zobacz unikanie ładowania złożenia w wielu kontekstach."

Proponuję spróbować Costura.Fody . Tylko nie zapomnij zainstalować-pakiet Fody przed Costura.Fody (w celu uzyskania najnowszej Fody!)