Comments 75
Думаю, стоит уточнить, что данный способ не позволит запихать среду исполнения .NET в EXE файл, чтобы его можно было запускать на компах без установленного .NET Framework.
Более года пользуюсь для этих целей консольной утилитой ILMerge (Microsoft) как для корпоративных, так и для персональных утилит (.NET 2.0-3.5SP1). Механизм работы несколько отличается от описанного — разработка проекта ведётся обычным способом, а потом (например, в релизной конфигурации) все сборки и испольняемый файл «склеиваются» с сохранением пространтсв имен в единый исполняемый файл. Сжатие, соответственно, в этом случае не применяется.
У этого метода есть недостаток. Если кто то добавит в References вашу сборку и одну из сборок с которой ваша смерджена, то отхватит исключение. А приведенный автором способ позволяет это обойти.
Аналогично, используем ILMerge если нужно просто встроить библиотеки в exe'шник.
Я бы добавил, что подход, описанный в статье, реализован в утилитах, таких как NETZ (консольная), а также NBox (консольная, но собирает не из строки, а из нормального XML конфига). Последняя утилита — собственного написания, постоянно ей пользуюсь, недавно даже собрался и оформил краткий русский мануал.
OMG. неужели так сложно слизать еще одну «фишку» макоси — .app?
религия не позволяет? я так и думал… странно, а иконку в топик от макоси позволяет вставить…
p.s.
вот зачем было вынуждать меня писать этот провокационный комментарий?
p.s.
вот зачем было вынуждать меня писать этот провокационный комментарий?
фишка о которой вы говорите несколько иное
знаю, но в итоге мы получаем: один аккуратненький фаил(не будем рушить фантазии яблочников, и будем все же считать этот каталог файлом), он спокойно переносится и работает на любом другом маке.
p.s.
меня минусуют из-за того, что я упомянул мак в блоге .Net? эхх, а я уже начал считать .net'еров адекватными людьми…
p.s.
меня минусуют из-за того, что я упомянул мак в блоге .Net? эхх, а я уже начал считать .net'еров адекватными людьми…
Не-не, вот если бы вы написали: «Вот неплохо было бы позаимствовать идею у Mac OS, где есть <описание фишки>, и сделать аналогичную под <ось, программный продукт или еще чего>, было б классно!» — К вам никаких претензий точно б небыло :)
А так как вы толсто троллить пришли в дотнет со своим ябблом — получайте полноразмерные, свежие, сочно-красные минусы. :) Заслужили.
А так как вы толсто троллить пришли в дотнет со своим ябблом — получайте полноразмерные, свежие, сочно-красные минусы. :) Заслужили.
Ну я просто в не совсем вежливой форме описал, что я хотел бы видеть. И троллить я не собирался, я просто описал как все прекрасно у меня в макоси и не плохо было бы уж и эту фичу скопировать из макоси.
Ну у нас на хабре, за три года, как бы сложилась взаимовежливая и толерантная к чужим предпочтениям среда. Не стоит все ж… :)
судя потому, что меня все еще минусуют — адекватность под сомнением. и тут не никакой «взаимовежливая и толерантная к чужим предпочтениям среды» — посмотрите топики про iPad, H.264… и все же — почему так трудно позаимствовать идею у Mac OS, где есть удобный эпликейшен контейнер .app, и сделать аналогичную под Win7, было б классно!
Вы когда-нибудь видели, как выглядит .app в винде?
Ну только фанат мака может прийти в тему про сборку exe с библиотеками и начать рассказывать про свою ОС.
Чему вы удивляетесь?
Чему вы удивляетесь?
тому, что только фанат может отрицать явную прелесть такого подхода. Я описать прелесть такого подхода, и даже ни разу не написал ".net говно если так не умеет!!111" конкретно описал, что было бы не плохим добавлением в разработку под Win7. Да, собрать ехе с библиотеками для маленькой софтины наверное удобно, а теперь попробуйте это сделать для фотошопа или любой попсовой игры?
Или вам религия не позволяет смореть на чужую точку зрения? Быстрее надо заминусовать и скрыть, чтобы молодые и не опытные еще не просекли плюшки маков!!1111
p.s.
по поводу организации приложений в *nix like os ничего против не имею, вполне вменяемо, несколько приложей используют одну и туже библиотеку, вполне удобно, лучше чем плодить бесконечные копии этих библиотек, но тогда требуется система контроля зависимостей, которая не вписывается в мои понимания домашней системы. Ну вот глупо когда я хочу поставить гимп (зайти на сайт гимпа, скачать dmg, drag'n'drop, use it luke) запускать мэнеджер пакетов, искать там гимп, тыкать инсталл, ждать пока проверяться зависимости и тянуть все то, что ему надо — не дружелюбно все это.
Или вам религия не позволяет смореть на чужую точку зрения? Быстрее надо заминусовать и скрыть, чтобы молодые и не опытные еще не просекли плюшки маков!!1111
p.s.
по поводу организации приложений в *nix like os ничего против не имею, вполне вменяемо, несколько приложей используют одну и туже библиотеку, вполне удобно, лучше чем плодить бесконечные копии этих библиотек, но тогда требуется система контроля зависимостей, которая не вписывается в мои понимания домашней системы. Ну вот глупо когда я хочу поставить гимп (зайти на сайт гимпа, скачать dmg, drag'n'drop, use it luke) запускать мэнеджер пакетов, искать там гимп, тыкать инсталл, ждать пока проверяться зависимости и тянуть все то, что ему надо — не дружелюбно все это.
Ммм… Я так и не понял кому вы ответили :)
Если честно, я не понял, зачем собирать фотошоп со строенными библиотеками?
Религия мне много чего позволяет. Я пользуюсь Windows 7 и Arch с Gentoo, меня, как видите, не разрывает на куски.
к p.s.
По вашему, написать aptitude (допустим, у вас убунту), emerge (допустим генту), pacman (допустим арч) и название «gimp» — это сложнее, чем зайти на офф сайт, скачать, поставить?
Впрочем, больше не спорю, потому что я не все понимаю, что вы пишете.
Если честно, я не понял, зачем собирать фотошоп со строенными библиотеками?
Религия мне много чего позволяет. Я пользуюсь Windows 7 и Arch с Gentoo, меня, как видите, не разрывает на куски.
к p.s.
По вашему, написать aptitude (допустим, у вас убунту), emerge (допустим генту), pacman (допустим арч) и название «gimp» — это сложнее, чем зайти на офф сайт, скачать, поставить?
Впрочем, больше не спорю, потому что я не все понимаю, что вы пишете.
эээ ну да мне проще зайти на сайт гимпа и слить пакет, чем тянуть все зависимости.
>Ммм… Я так и не понял кому вы ответили :)
Если честно, я не понял, зачем собирать фотошоп со строенными библиотеками?
Религия мне много чего позволяет. Я пользуюсь Windows 7 и Arch с Gentoo, меня, как видите, не разрывает на куски.
Я говорю о том, что в маке приложения это один фаил (да на самом деле это директория, но юзер видит только один фаил). Когда я хочу запустить это приложения на другом маке, я просто перетаскиваю этот .app, один «фаил» и все. инет никаких архаизмов как .reg.
>Ммм… Я так и не понял кому вы ответили :)
Если честно, я не понял, зачем собирать фотошоп со строенными библиотеками?
Религия мне много чего позволяет. Я пользуюсь Windows 7 и Arch с Gentoo, меня, как видите, не разрывает на куски.
Я говорю о том, что в маке приложения это один фаил (да на самом деле это директория, но юзер видит только один фаил). Когда я хочу запустить это приложения на другом маке, я просто перетаскиваю этот .app, один «фаил» и все. инет никаких архаизмов как .reg.
Апп — папочка, а не исполняемый бинарный юниксовый файл из этой папочки, и переносятся аппликации, как правило сжатые или в файл зип или в яйца или в образы дмж.
>один аккуратненький фаил(не будем рушить фантазии яблочников, и будем все же считать этот каталог файлом
в этом каталоге хранится вся информация которая требуется для запуска приложения. и переносить ее можно как угодно. Но для дистрибьюции используется чаще всего dmg со сжатием или банальный .tgz/.zip.
p.s.
человек вроде бы грамотный, а каталоги(директории) называет «папочкой». ну нет таких вещей как «папочка» и «мамочка», есть только каталоги директории.
в этом каталоге хранится вся информация которая требуется для запуска приложения. и переносить ее можно как угодно. Но для дистрибьюции используется чаще всего dmg со сжатием или банальный .tgz/.zip.
p.s.
человек вроде бы грамотный, а каталоги(директории) называет «папочкой». ну нет таких вещей как «папочка» и «мамочка», есть только каталоги директории.
Низзя, низзя тут никого неграмотными абзывать! Автор за это карму сбивает! Цензура знаешь ли!
человек вроде бы грамотный, а каталоги(директории) называет «папочкой». ну нет таких вещей как «папочка» и «мамочка», есть только каталоги директории.
То есть, «Folder» никак нельзя перевести на русский язык?
Чем вас не устраивает инсталлятор вида setup.exe? Один файл и вы можете спать спокойно.
Описанный автором способ выполняет немного другую задачу.
Описанный автором способ выполняет немного другую задачу.
То о чем говорится в статье — статическая линковка. Макоси не было, когда ее придумали.
почему забыли про jar файлы?
а вообще портабельный софт рулит до невозможности
а вообще портабельный софт рулит до невозможности
примерно таким подходом я пользовался. Мне требовалось распаковать ресурсы, мучатся и сохранять все по одному файлу (а ресурс-файлов больше одного десятка) ну это тяжеловато.
Упаковал, добавил zip в ресурсы исполняемого файла, а затем просто сохранение архива на диск и распаковка в нужный момент.
Упаковал, добавил zip в ресурсы исполняемого файла, а затем просто сохранение архива на диск и распаковка в нужный момент.
Я так понимаю, про ILMerge автор не слышал.
Он работает несколько иначе, в комментах выше уже обсуждали :)
Кроме того, могут быть проблемы с некоторыми аттрибутами, которые требуют тип, указанный текстом… там название сборки надо будет править
Не совсем понимаю сути проблемы. Если встречается тип, который хранится в сборке, которой нет в памяти, сборка погружается через AssemblyResolve.
Это я про ILMerge, который просто сливает все сборки в одну.
А можете привести пример? просто интересно
Если имеется ввиду пример проблемы с ILMerge, то пожалуйста:
после мержа работать не будет, т.к. MySecondAssembly уже физически не существует. Т.е. Из-за той части типа, которая содержит название сборки — весь сыр-бор.
Как правило, текстовые имена типов используются такими атрибутами как Editor, Designer, TypeConverter…
var myType = Type.GetType("MyNamespace.MyType, MySecondAssembly");после мержа работать не будет, т.к. MySecondAssembly уже физически не существует. Т.е. Из-за той части типа, которая содержит название сборки — весь сыр-бор.
Как правило, текстовые имена типов используются такими атрибутами как Editor, Designer, TypeConverter…
Небольшая магия с AssemblyResolve легко решит эту проблему.
Это понятно. Я к тому, что без лишних телодвижений в коде, ни ILMerge ни AutoMapper попросту не работают…
Хотелось бы чего-то типо xap, как в Silverlight :)
Хотелось бы чего-то типо xap, как в Silverlight :)
Да, вы полностью правы. Один из минусов использования ILMerge заключается в том, что указанный вами пример отработает некорректно. Однако и это, впринципе, несложно решается. Например, для того чтобы подгрузить из сборки, слепленной утилитой, embedded resource нужно тоже указать правильное имя ресурса, а оно зависит от имени сборки. В обоих случаях имя сборки легко получить, указав вместо статического «Assembly.GetEntryAssembly().GetName().Name», а сам namespace при «склеивании» у типа не меняется.
ILMerge не умеет сжимать, так что данная вещь типа более продвинутая. хотя я как пользовался ILMerge, так и буду :)
А Вы ничего не путаете насчет SysInternals?
Помоему, там все утилиты написаны на Visual C++ и используеться только API Windows.
Помоему, там все утилиты написаны на Visual C++ и используеться только API Windows.
UFO just landed and posted this here
Для этого зависимые dll кладут в одну папку с exe файлом.
О GAC слышали?
О GAC слышали?
Что мне всегда нравилось в .NET — что никогда не задумываешься «как». Написание кода по времени сокращается в разы
Есть еще пакер который укладывает все файлы в один EXE, как нативные так и .net — Molebox.
Не только исполнительные, но и файлы ресурсов. Распаковывает все в память.
Не только исполнительные, но и файлы ресурсов. Распаковывает все в память.
Одно замечание по DeflateStream — степень сжатия крайне невысокая, плюс «архив» может занимать больше места, чем исходник (как наблюдал — до 1,5 раз)
https://connect.microsoft.com/VisualStudio/feedback/details/93636/gzipstream-deflatestream-increase-file-size-on-compression
https://connect.microsoft.com/VisualStudio/feedback/details/93636/gzipstream-deflatestream-increase-file-size-on-compression
«Чтобы .NET код мог работать, в использующий его AppDomain нужно загрузить сборку, содержащую типы, которые используются в коде.»
-код работает?
-типы содержатся?
-сборка содержит типы?
-типы используются в коде?
Можно ведь как-то котролировать свое мысле-изложение? Извините, накипело. Такое ощущение, что читаю очередной перевод технической статьи девочкой филологом.
-код работает?
-типы содержатся?
-сборка содержит типы?
-типы используются в коде?
Можно ведь как-то котролировать свое мысле-изложение? Извините, накипело. Такое ощущение, что читаю очередной перевод технической статьи девочкой филологом.
Может быть я просто давно привык к косо звучащей русской терминологии, но я понял это предложение с первого раза. Прочёл, не спотыкаясь.
Я ж не против. Это был всего лишь призыв к тому, что если садишься писать статью, то нужно помнить, что это не коммент в аське или на форуме. Эту статью будут читать много людей с совершенно разным уровнем компетенции, а не очкастые, бородатые быдлокодеры, которые уже кроме как через notepad общаться не умеют! ИМХО, замечание актуальное и из-за обиды карму сбивать — плохой тон!
Еще такой вопрос — а вы на ResolveType тоже подписались, и вручную их ищете? Потому что Load(byte[]) — он же грузит в Load-neither контекст; как итог, некоторые типы могут не резолвиться.
Хорошая статья. Но для этих же целей можно использовать MoleBox, а если важен и объем тоже — то можно пройтись ASPACK'ом.
Для решения проблем, описанных в заключении (один файл, независимость, передача по сети/на флеху) проще всего использовать архивацию (имеется ввиду всей папки каким-нибудь rar или zip). Это снимает все описанные проблемы, но сопровождать и обновлять такое приложение удобнее (при необходимости можно заменить необходимую библиотеку).
Это также касается вопроса передачи по сети: 1 библиотечку передать явно проще, чем заново полный продукт.
Также в любом маломальски крупном приложении будут какие-то файлы настроек, которые паковать описанным автором способом нельзя (они для того и хранятся отдельно, чтобы их корректировать, не меняя бинарники). Так если их хранить отдельно, то проще уже все паковать архиватором и распаковівать на принимающей стороне.
Это также касается вопроса передачи по сети: 1 библиотечку передать явно проще, чем заново полный продукт.
Также в любом маломальски крупном приложении будут какие-то файлы настроек, которые паковать описанным автором способом нельзя (они для того и хранятся отдельно, чтобы их корректировать, не меняя бинарники). Так если их хранить отдельно, то проще уже все паковать архиватором и распаковівать на принимающей стороне.
Да, верно. Но Вы забыли об одной маленькой мелочи. При распаковывании такого файла — Вам понадобится еще и доп. место, которое ровно весу файла при обычных операциях.
Когда это 5-10 мб — это ничего. А если у меня файл 1 гиг? 4? 8?
Я покажусь извращенцем, но это я делаю. Пример — игра. любая. Тот же кс или варкрафт.
Первая весит от 1- до 6, в зависимости от карт, моделей и прочего. В ней ооочень много файлов. Распаковка займет время и ресурсы. Вторая — от 1 до 2-х гиг. Сравнительно мало файлов, но сами mpq весят много.
И теперь Вам нужно место — около 1 гига свободного места на диске ц под рар (если учесть что Вы не сменили в свойствах системы переменные temp path).
Зачем мне знать сколько места и все прочее — я просто работаю в своей среде, т.е. на флешке и ни байта не забрал с ситемы. Да. можно поспорить, что некоторые такие проекты требуют доступа именно к переменным папкам системы, то ли Мои документы, то ли Documents and Settings, но и это можно сэмулировать. Благо с реестром это проще сделать.
Когда это 5-10 мб — это ничего. А если у меня файл 1 гиг? 4? 8?
Я покажусь извращенцем, но это я делаю. Пример — игра. любая. Тот же кс или варкрафт.
Первая весит от 1- до 6, в зависимости от карт, моделей и прочего. В ней ооочень много файлов. Распаковка займет время и ресурсы. Вторая — от 1 до 2-х гиг. Сравнительно мало файлов, но сами mpq весят много.
И теперь Вам нужно место — около 1 гига свободного места на диске ц под рар (если учесть что Вы не сменили в свойствах системы переменные temp path).
Зачем мне знать сколько места и все прочее — я просто работаю в своей среде, т.е. на флешке и ни байта не забрал с ситемы. Да. можно поспорить, что некоторые такие проекты требуют доступа именно к переменным папкам системы, то ли Мои документы, то ли Documents and Settings, но и это можно сэмулировать. Благо с реестром это проще сделать.
Экзешник размеров в 1 гиг? 4? 8
Мсье знает толк в извращениях.
Мсье знает толк в извращениях.
Я думаю автор статьи при своим постом преследовал несколько другие цели, чем запаковывание игр размером 1-2 гига в один exe-шник. :) Я, честно говоря, не видел, чтобы так делали и производители игр. А как раз в таких ситуация, как Ваша, они именно архивируют, а потом распаковывают/инсталлируют у пользователя.
«Один exe-шник» хорош лишь в некоторых вырожденых случаях. И то дает больше неудобств, чем преимуществ.
«Один exe-шник» хорош лишь в некоторых вырожденых случаях. И то дает больше неудобств, чем преимуществ.
Сам в свое время смотрел как это в LinqPad сделано — спасибо что расписали все по шагам. Действительно, это наверное удобно, хотя остается вопрос — можно ли это же делать если у .Net сборки зависимости на C++ сборки? Тут ведь
Assembly.Load работать не будет.
Смотря как реализована зависимость. Если это C++/CLI сборка, то Assembly.Load должен сработать.
Если это native dll, то тут нужно гуглить такую же статью на С++. В SysInternals инструментах это реализовано, так что должен быть соответствующий WinAPI вызов. Может у Рихтера в книге даже реализация найдется. В любом случае нужно будет перехватывать PInvoke вызовы к unmanaged DLL. Либо PInvoke обертки выделять в отдельные сборки и анализировать в AssemblyResolve, либо пробовать приспособить TypeResolve, либо принять соглашение об именовании таких оберток и использовать аспектное программирование.
Если это native dll, то тут нужно гуглить такую же статью на С++. В SysInternals инструментах это реализовано, так что должен быть соответствующий WinAPI вызов. Может у Рихтера в книге даже реализация найдется. В любом случае нужно будет перехватывать PInvoke вызовы к unmanaged DLL. Либо PInvoke обертки выделять в отдельные сборки и анализировать в AssemblyResolve, либо пробовать приспособить TypeResolve, либо принять соглашение об именовании таких оберток и использовать аспектное программирование.
Sign up to leave a comment.
Программа из одного exe