как windows cll dll может быть объединена в c # приложение exe?

<p>у меня есть windows c # программа, которая использует c++ dll для ввода/вывода данных. моя цель - развернуть приложение как один exe-файл. </p><p>какие шаги для создания такого исполняемого файла?</p>

<p>развертывание управляемого и неуправляемого кода в одной сборке. воскресенье, 4 февраля 2007 г.</p><p>разработчики .net любят развертывание xcopy. и они любят отдельные компоненты сборки. по крайней мере, я всегда чувствую себя немного неловко, если мне нужно использовать какой-то компонент и мне нужно запомнить список файлов, которые также нужно включить в основную сборку этого компонента. поэтому, когда мне недавно пришлось разработать компонент управляемого кода и дополнить его некоторым неуправляемым кодом из c dll (спасибо маркусу хигу за помощь в этом!), я подумал о том, как сделать его проще. разверните две библиотеки dll. если бы это были всего две сборки, я бы использовал ilmerge, чтобы собрать их в один файл. но это не работает для компонентов смешанного кода с управляемыми и неуправляемыми библиотеками dll.</p><p>итак, вот что я придумал для решения:</p><p>я включаю все библиотеки dll, которые я хочу развернуть, с основной сборкой моего компонента в качестве встроенных ресурсов .... затем я настраиваю конструктор класса для извлечения этих библиотек, как показано ниже. класс ctor вызывается только один раз в каждом appdomain, поэтому я думаю, что это незначительные накладные расходы.</p><pre><code>namespace mylib { public class myclass { static myclass() { resourceextractor.extractresourcetofile("mylib.managedservice.dll", "managedservice.dll"); resourceextractor.extractresourcetofile("mylib.unmanagedservice.dll", "unmanagedservice.dll"); } ... </code></pre><p>в этом примере я включил две библиотеки dll в качестве ресурсов, одну - библиотеку неуправляемого кода, а другую - управляемый код dll (только для демонстрационных целей), чтобы показать, как этот метод работает для обоих типов кода.</p><p>код для извлечения библиотек dll в свои файлы прост:</p><pre><code>public static class resourceextractor { public static void extractresourcetofile(string resourcename, string filename) { if (!system.io.file.exists(filename)) using (system.io.stream s = system.reflection.assembly.getexecutingassembly().getmanifestresourcestream(resourcename)) using (system.io.filestream fs = new system.io.filestream(filename, system.io.filemode.create)) { byte[] b = new byte[s.length]; s.read(b, 0, b.length); fs.write(b, 0, b.length); } } } </code></pre><p>работа с управляемым кодом сборка такая же, как обычно - почти. вы ссылаетесь на него (здесь: managedservice.dll) в основном проекте вашего компонента (здесь: mylib), но для свойства copy local установлено значение false. кроме того, вы связываете сборку как существующий элемент и устанавливаете для действия сборки значение «встроенный ресурс».</p><p>для неуправляемого кода (здесь: unmanagedservice.dll) вы просто ссылаетесь на dll как существующий элемент и задаете для параметра «действия» для «встроенный ресурс». чтобы получить доступ к его функциям, используйте атрибут dllimport как обычно, например,.</p><pre><code>[dllimport("unmanagedservice.dll")] public extern static int add(int a, int b); </code></pre><p>это оно! как только вы создаете первый экземпляр класса со статическим ctor, встроенные библиотеки dll извлекаются в свои собственные файлы и готовы к использованию, как если бы вы развернули их как отдельные файлы. если у вас есть права на запись для каталога выполнения, это должно работать нормально. по крайней мере, для прототипного кода, я думаю, этот способ развертывания одной сборки довольно удобен.</p><p>наслаждайтесь!</p><p> <a href="http://weblogs.asp.net/ralfw/archive/2007/02/04/single-assembly-deployment-of-managed-and-unmanaged-code.aspx">http://weblogs.asp.net/ralfw/archive/2007/02/04/single-assembly-deployment-of-managed-and-unmanaged-code.aspx</a> </p>

<p>попробуйте <a href="http://boxedapp.com/">boxedapp</a> ; это позволяет загружать все библиотеки dll из памяти. кроме того, кажется, что вы можете даже встроить .net время выполнения. хорошо для создания действительно автономных приложений ...</p>

<p>просто щелкните правой кнопкой мыши свой проект в visual studio, выберите «свойства проекта» -> «ресурсы» -> «добавить ресурс» -> «добавить существующий файл… .\_\_» и включите приведенный ниже код в файл app.xaml.cs или аналогичный.</p><pre><code>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); } </code></pre><p>вот мой оригинальный пост в блоге: <a href="http://codeblog.larsholm.net/2011/06/embed-dlls-easily-in-a-net-assembly/">http://codeblog.larsholm.net/2011/06/embed-dlls-easily-in-a-net-assembly/</a> </p>

<p>используйте <strong>fody.costura</strong> nuget</p><ol> <li>откройте свое решение -> проект -> управление пакетами nuget</li> <li>поиск <strong>fody.costura</strong></li> <li><strong>скомпилируйте</strong> ваш <em>проект</em>. </li> </ol><p>это оно !</p><blockquote> <p>источник: <a href="http://www.manuelmeyer.net/2016/01/net-power-tip-10-merging-assemblies/">http://www.manuelmeyer.net/2016/01/net-power-tip-10-merging-assemblies/</a> </p> </blockquote>

<p>вы пробовали ilmerge? <a href="http://research.microsoft.com/~mbarnett/ilmerge.aspx">http://research.microsoft.com/~mbarnett/ilmerge.aspx</a> </p><blockquote> <p>ilmerge - это утилита, которая может использоваться для объединения нескольких сборок .net в одну сборку. он доступен для свободного использования на странице «инструменты и утилиты» в центре разработчиков microsoft .net framework. </p> </blockquote><p>если вы создаете c++ dll с флагом <code>/clr</code> (полностью или частично c++/cli), то он должен работать:</p><pre><code>ilmerge /out:composite.exe mymainapp.exe utility.dll </code></pre><p>однако он не будет работать с обычной (родной) windows dll. </p>

<p> <a href="http://www.red-gate.com/products/dotnet-development/smartassembly/">smart assembly</a> может сделать это и многое другое. если ваша dll имеет неуправляемый код, она не позволит вам объединить dll в одну сборку, вместо этого она может встроить необходимые зависимости в качестве ресурсов в ваш основной exe-файл. его оборотная сторона, это не бесплатно.</p><p>вы можете сделать это вручную, внедрив dll в свои ресурсы, а затем полагаясь на сборку appdomain <code>resolvehandler</code>. когда дело доходит до dll в смешанном режиме, я обнаружил, что многие варианты и разновидности подхода <code>resolvehandler</code> не работают для меня (все, которые читают dll-байты в память и читают из нее). все они работали на управляемые библиотеки. вот что сработало для меня:</p><pre><code>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); }; } </code></pre><p>ключевым моментом здесь является запись байтов в файл и загрузка из него. чтобы избежать проблемы с курицей и яйцом, необходимо убедиться, что вы объявили обработчик перед доступом к сборке, и чтобы у вас не было доступа к элементам сборки (или к созданию экземпляров всего, что имеет отношение к сборке) внутри загрузочной (разрешающей сборку) части. также убедитесь, что <code>getmyapplicationspecificpath()</code> не является каким-либо временным каталогом, поскольку временные файлы могут пытаться стереть другие программы или вы сами (не то, что они будут удалены, когда ваша программа обращается к dll, но, по крайней мере, это создает неудобства. appdata хорошее место). также обратите внимание, что вы должны записывать байты каждый раз, вы не можете загрузить из местоположения только потому, что dll уже находится там.</p><p>если сборка полностью неуправляемая, вы можете увидеть эту <a href="https://stackoverflow.com/questions/666799/embedding-unmanaged-dll-into-a-managed-c-sharp-dll">ссылку</a> или <a href="http://bsmadhu.wordpress.com/2012/03/19/embedding-c-libraryexe-inside-net-assembly/">эту</a> о том, как загрузить такие библиотеки.</p>

<p> <a href="https://thinstall.com/help/index.php?\_netsupport.htm">thinstall</a> это одно решение. для нативного приложения windows я бы предложил встроить dll в виде объекта двоичного ресурса, а затем извлечь его во время выполнения до того, как он вам понадобится.</p>