Runtime: Одно автономное консольное приложение exe

Этот сценарий сейчас не поддерживается. Следите за репозиторием https://github.com/dotnet/corert, чтобы узнать о работе, которая приведет к этому пути.

CoreRT - подходящее место для поиска этого решения.

Благодарю. Похоже, CoreRT - это именно то, что я искал.

Для других, кто может наткнуться на это, читайте здесь

Я специально хочу эту функцию без предварительной компиляции. Мне не нужен corert - мне нужен такой же опыт jit, отладки и времени выполнения, что и у обычного автономного приложения, - но я также не хочу распределять четыре файла на одну утилиту. Это неудобно для тех, кто хочет пользоваться утилитой. Я просто хочу, чтобы он был упакован и запускался из одного exe. Это заставляет меня выбирать .NET Framework вместо .NET Core для многих утилит.

.NET Framework «жульничает», поскольку у вас уже есть много файлов в ОС.
Вы можете добиться того же с .NET Core, установив .NET Core для всей машины, если вы этого хотите.

Рефакторинг CoreCLR для объединения всех файлов в один (включая собственные + управляемые) - нетривиальная работа, и я не думаю, что этот сценарий так интересен слишком многим клиентам.

Разница в том, что на каждой машине Windows гарантированно будет .NET Framework, но не .NET Core, поэтому, если нет особой причины, по которой развертывание стоит усложнять, я думаю, что в конечном итоге останусь там.
Я предполагаю, что заказчики обычно не пишут отдельные исполняемые утилиты. Возможно, однажды. :-)

если нет особой причины, по которой развертывание стоит усложнять

Есть МНОГИЕ причин предпочесть .NET Core .NET Framework. Производительность, модульность, удобство обслуживания, изоляция и т. Д. И это без учета кроссплатформенности.

Наличие единственной утилиты exe - это в основном косметическая проблема. Нет реальной функциональной разницы (для всех участников), если исполняемый файл представляет собой один файл или одну папку с несколькими файлами в ней.

@mellinoe О, я согласен в отношении проектов в целом, это, безусловно, правда. В небольших утилитах, где это косметическое средство желательно, .NET Framework пока проделала достаточно хорошую работу. Я согласен, что это косметика в том же смысле, что и возможность указать монтажную компанию и сообщение об авторских правах. Но косметика мне не меньше нравится. Очевидно, здесь нет приоритета, это вполне понятно.

Возможно, связано: https://github.com/dotnet/core/issues/600

В основном это не косметика. Представьте, что я хочу распространить приложение, в которое встроено несколько компонентов, например, Idsrv4 или RavenDb + мои собственные материалы. Они зависят от основных битов aspnet. Все это работает нормально, если они зависят от одной и той же версии ядра aspnet. Как только один из них перейдет к следующей версии, он, вероятно, перестанет работать. Если бы OTOH смог объединить каждый компонент в одну .dll, проблема исчезла.

Следует иметь в виду, что существует больше технических проблем, чем просто неработающий ILMerge. Сама среда выполнения в основном разделена на множество файлов, а также есть вспомогательные файлы, такие как хост CLR, текстовый файл зависимостей среды выполнения и другие. Единственная причина, по которой однофайловый исполняемый файл работал в прошлом, заключается в том, что использовалась .NET Framework, глобальная общесистемная установка. Сравнение этих двух сценариев немного несправедливо, потому что .NET Framework действительно не имеет «автономного» варианта.

Все это работает нормально, если они зависят от одной и той же версии ядра aspnet. Как только один из них перейдет к следующей версии, он, вероятно, перестанет работать.

Это не совсем так. Вы можете опубликовать несколько разных приложений для разных версий среды выполнения, а затем объединить их в одно «uber-приложение». Вы просто не можете смешивать их зависимости в одной папке. Даже если вы используете опцию публикации, зависящую от платформы, вы все равно можете смешивать и сопоставлять версии. Я понимаю, что это менее удобно, чем наличие буквально одного файла, и может помешать таким вещам, как встраивание exe в качестве ресурса в PE. Я не уверен, что вы имеете в виду, потому что вам, вероятно, все равно потребуется извлечь файл для его выполнения, что вы все равно можете сделать с каталогом.

Я не имел в виду версию во время выполнения, я знаю, что это не сработает. Я имею в виду, что происходит в моем сценарии, когда каждый компонент зависит от [email protected]. Затем компонент a обновляется до [email protected]. Обычно это нормально, но в этом гипотетическом случае авторы LibXYZ не знают / не заботятся о семантическом управлении версиями. Ильмерге решил эту проблему.

Помимо уместного момента

Я ценю, что инструменты dotnet зарождаются и только что достигли уровня 2.0, но по сравнению с такими альтернативами, как golang, этой функции очень не хватает. Пожалуйста, подумайте о добавлении его в дорожную карту?

Как разработчик библиотеки, я был бы признателен за возвращение ILMerge в Core. 👍

Dotnet.exe - это отдельный файл. NuGet.exe - это один файл. Я считаю, что косметика важна, и один-единственный исполняемый файл говорит о простоте, в отличие от папки со 100 файлами! Было бы здорово найти способ добиться этого с помощью dotnetcore

Я предположил, что это возможно, и после нескольких недель работы пришел опубликовать консольный инструмент CLI в один .exe ... ммммм, кажется, в данный момент я не могу получить только один * .exe ??
Я думал, что в этом смысл автономных основных приложений?

@PRIMETSS

Я думал, что в этом смысл автономных основных приложений?

Суть автономных приложений в том, что они самодостаточны, то есть им не требуется установка .NET Core на целевой машине, потому что само приложение содержит все, что ему нужно для запуска.

Чтобы развернуть такое приложение, вам нужно скопировать весь каталог файлов. Наличие всего одного файла упростило бы развертывание, но это все, это все равно автономное приложение даже без этого.

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

Я регулярно пишу инструменты командной строки на .NET, и использование их в качестве 1 EXE упрощает обновление / развертывание / упаковку. Я всегда упаковываю все .config и другие необходимые файлы в EXE.

Подумайте об этом single-EXE как о мини-контейнере. Здесь применимы почти все преимущества контейнерных развертываний.

Это просто ужасно, мне интересно, почему это было одобрено во время процесса проектирования, хотите распространить ваше приложение одному из ваших клиентов, а затем удачи ему, чтобы найти, что открыть:

Это просто некрасиво и полный беспорядок

время выполнения /
MyProgram.exe
MyLib.dll

Это было бы лучше

Даже Java справляется с этим лучше:

Да, я думал в том же духе, поскольку автономные приложения должны иметь включенные в него файлы времени выполнения (очевидно!) (И у нас нет способа объединить их), тогда я также подумал, что просто разделение папок будет Будьте аккуратнее, и да, я также думаю, что файлы времени выполнения должны храниться в папке времени выполнения, поэтому любой, кто пытается использовать инструмент командной строки, написанный в ядре, по крайней мере найдет его немного более интуитивным в отношении того, что запускать ...

@Scellow @PRIMETSS Я согласен

Как это вообще до сих пор проблема? Спрос на это заоблачный.

да, в эту отдельную папку с добавлением заархивировать это в корзину и иметь два файла, exe и корзину. Легкое распространение.

Еще один +1 для повторного открытия и использования в качестве функции.

Я ожидал, что автономное развертывание будет самодостаточным, и нашел здесь свой путь. Я бы тоже хотел, чтобы это произошло.

Как можно сказать, что это косметическая проблема? (Только разработчики Framework ...)
Никто не думал об инструментах, которые не устанавливаются? (.NET решила dll-hell, а ядро ​​.NET возвращает его)

Я просто хочу, чтобы мой инструмент командной строки был самодостаточным.

Это плохо, очень плохо!

+1

+1 Я только что попытался запустить настраиваемое действие в пакетной службе Azure в кластере без основной среды выполнения .net, и он не может обрабатывать большое количество файлов, создаваемых «автономной» версией.

Total size of resourceFiles cannot be more than 32768 characters

Это не официальное решение, но оно может быть полезно. Я автор warp, инструмента, который позволяет создавать автономные одиночные двоичные приложения: https://github.com/dgiagio/warp

Я думаю, что варп - это в основном то, что все здесь ищут! Это просто возможность иметь один exe-файл, что бы ни было в фоновом режиме, не более того. Подумайте о пакетах NuGet: это один файл .nuget и все; это не что-то более сложное, чем файл, упаковывающий другие файлы.

warp - это хакерское решение, это не то, что мы хотим

Мы хотим:

dotnet publish --self-contained -c Release -r win10-x64

И производят:

App.exe
runtime/

Или лучше, например, GO / Rust и т. Д.

App.exe

Все остальное не нужно

Warp производит App.exe ... Как это взломать? Очевидно, что это не часть фреймворка, но позволяет достичь цели «один исполняемый файл».

Это то, что я имею в виду, это должно быть поведение по умолчанию, без использования стороннего решения (я думаю)

Искажение приносит удовольствие. Спасибо за работу @dgiagio!

+1

Я бы очень хотел увидеть какой-то однофайловый архив, который объединяет исполняемый файл и все зависимости. Необязательно включать собственные - я думаю, что вполне нормально, если в системе должно быть установлено ядро ​​dotnet. Что-то очень похожее на jar-файлы Java. Дар файл?

Что-то вроде:
dotnet publish - автономный
dotnet run - автономный MyApp.dar

Похоже, сейчас есть предложение: https://github.com/dotnet/designs/pull/52/files?short_path=28dba55

Вот проблема с отслеживанием: https://github.com/dotnet/coreclr/issues/20287

Кроме того, у @shanselman есть сообщение в блоге о решении Warp:

https://www.hanselman.com/blog/BrainstormingCreatingASmallSingleSelfconhibitedExecutableOutOfANETCoreApplication.aspx

Я прочитал предложение и увидел следующее:

Это не то, что я имел в виду, это звучит как медленный процесс, в основном просто архивирование всего ...
Я думал, весь код будет объединен в один исполняемый файл / dll? а может я что-то упустил в предложении?

@RUSshy Вы спрашиваете о нативной компиляции всего управляемого кода и связывании всего вместе, чтобы получить один исполняемый файл (как в CoreRT)? Это не цель текущей работы с одним файлом в .Net Core.

Однако есть предлагаемые решения для сокращения времени извлечения диска и запуска (например, загрузка определенных типов файлов непосредственно из пакета , повторное использование извлеченных файлов ). Этапы разработки решения одного файла описаны здесь .

CC: @jeffschwMSFT

Зачем нужно извлекать файлы? Раньше мы избегали этого в .NET с помощью ILMerge.

@ phillip-haydon, как описано здесь , ILMerge и однофайловые решения достигают разных целей.

ILMerge объединяет IL из многих сборок в одну, но в процессе теряет исходную идентичность объединенных сборок. Таким образом, такие вещи, как использование отражения на основе исходных имен сборок, не сработают. Приложения по-прежнему могут использовать ILMerge, если они терпят это изменение.

CoreRT - это что-то еще, AOT-компиляция вашего .NET-кода, она выглядит интересной, но еще не готова (я бы хотел, чтобы MS сосредоточилась на ней и выделяла больше ресурсов .. это именно то, что люди хотят, и почему они перешли на GO )

В любом случае, у меня нет технических знаний, чтобы говорить о деталях, но вариант использования:

Опубликуйте один автономный исполняемый файл, и все, ничего не заархивировано, ничего не извлечено, без накладных расходов, только исполняемый файл

@ swaroop-sridhar у вас есть пример того, как это работает для ядра dotnet в Linux? согласно https://github.com/dotnet/ILMerge/blob/master/ILMerge/ILMerge.csproj#L13, это проект только для окон / моно.

@thefringeninja ILMerge - это инструмент для Windows, я не знаю о каких-либо планах по переносу ILMerge на другие платформы.
Однофайловое решение будет реализовано кроссплатформенным. Это в процессе разработки.

@karelz @mellinoe
Развернуть Развернуть Развернуть!если один или меньше, например, 1-3 файла, это будет лучше для развертывания (Inlcude Publish, Update)!

CoreRT - это AOT
а люди хотят АОТ?
проект (CoreRT) всегда не готов к использованию (его с 2014 года). Наступил 2019 год ( примерно 5 лет )
Какие драгоценные 5 лет для языка праграм!у CoreRT даже нет планов на следующий выпуск !!!пусть люди подождут еще 5 лет?

@ swaroop-sridhar Это прискорбно. ILMerge / ILRepack отлично подходит для разработчиков библиотек, чтобы избежать проблемы алмазной зависимости.

Планируется, что она будет поддерживаться в .NET Core 3.0 - @richlander может
Об этом упоминалось в сообщениях блога .NET Core 3.0 - например, здесь: https://devblogs.microsoft.com/dotnet/net-core-3-and-support-for-windows-desktop-applications/ в
Также прочтите: https://www.hanselman.com/blog/BrainstormingCreatingASmallSingleSelfconhibitedExecutableOutOfANETCoreApplication.aspx

.net не должны нуждаться во всех этих хаках для создания небольшого автономного исполняемого файла ... это должно быть поведение по умолчанию, вас заживо съедает GO, Rust тоже идет, сосредоточьтесь на CoreRT или ILMerge, основные приложения .net уже тоже долго, чтобы начать из-за всех файлов для загрузки, не добавляйте больше подслушанного с помощью zip / unzip, как указано в предложении, это не выход

.net не должны нуждаться во всех этих хаках для создания небольшого автономного исполняемого файла ... это должно быть поведение по умолчанию, вас заживо съедает GO, Rust тоже идет, сосредоточьтесь на CoreRT или ILMerge, основные приложения .net уже тоже долго, чтобы начать из-за всех файлов для загрузки, не добавляйте больше подслушанного с помощью zip / unzip, как указано в предложении, это не выход

Как вам нравится .net не должен быть живым, потому что у ppl есть java.
go, rust или dlang не должны поддерживать цель сборки для одной исполняемой программы, потому что у них есть Fuck Zip / Unzip!

@RUSshy

.net не должны нуждаться во всех этих хаках для создания небольшого автономного исполняемого файла

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

Таким образом, создание компоновщика должным образом, не ставящего под угрозу точность функций, которые мы все зависим и любим в .NET, - сложная проблема. В рамках решения этой проблемы мы экспериментируем с различными подходами. Вы называете это взломами, я называю это непредубежденным и готовым мыслить нестандартно. Но просто слепое превращение .NET в Go / Rust / C ++ - неправильный ответ.

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

Подумала ли команда о создании отдельной версии .net, ориентированной на нативную разработку и ограниченных сред, как это сделали jetbrains с kotlin JVM / kotlin NATIVE?

Как вы сказали, попытка сделать .net подходящим для всех вариантов использования - не самый разумный вариант, поэтому конкретный вариант может быть правильным ответом на эту проблему.

И, черт возьми, эта проблема действительно не существовала до .net core, так как каждая установка Windows уже имела .net framework, поэтому вам нужно было только распространить свои несколько килобайт exe, и что меня раздражает, так это то, что никто, похоже, не думал об этом проблемы при разработке ядра .net, которое было в основном переписанным фреймворком .net .. вот почему я говорю, что эти упомянутые варианты - простые хаки, они здесь, чтобы исправить ошибки дизайна

После прочтения https://github.com/dotnet/designs/blob/master/accepted/single-file/staging.md кажется, что для предложения есть больше шагов, и оно не заканчивается на zip / unzip, так что это не проигранный бой, надеюсь, команда сможет прийти с чем-то более легким, что упоминается в этом документе, хорошо!

Вот почему Windows остается игрушечной ОС.

@kjkrum Что такое?

@cryru это то, что люди говорят, когда не знают, что делают.

@Cryru Такие вещи, как невозможность создать автономный исполняемый файл и

@Cryru Такие вещи, как невозможность создать автономный исполняемый файл и

Согласитесь, это действительно связано с положением программ на C # в операционной системе.
Программы на C # всегда не могли стать первоклассными.Только быть второсортным.

Это решено.
TL; DR: dotnet publish -r win10-x64 /p:PublishSingleFile=true

Детали:
https://docs.microsoft.com/en-us/dotnet/core/whats-new/dotnet-core-3-0#single -file-executables
https://github.com/dotnet/designs/blob/master/accepted/single-file/design.md

Это решено.
TL; DR: dotnet publish -r win10-x64 /p:PublishSingleFile=true

Детали:
https://docs.microsoft.com/en-us/dotnet/core/whats-new/dotnet-core-3-0#single -file-executables
https://github.com/dotnet/designs/blob/master/accepted/single-file/design.md

В какой версии dotnet-core была добавлена ​​эта функция? Я использую 3.0.100-preview5-011568 и получаю следующую ошибку:
error MSB4030: "/p:PublishSingleFile=true" is an invalid value for the "SelfContained" parameter of the "ResolveFrameworkReferences" task. The "SelfContained" parameter is of type "System.Boolean".

ЛЭ: На самом деле он работает, кажется, есть только синтаксическая ошибка в https://github.com/dotnet/designs/blob/master/accepted/single-file/design.md, в которой говорится о публикации с помощью dotnet publish -r win10-x64 --self-contained /p:PublishSingleFile=true и фактически без добавления --self-contained .

Спасибо @mihaimyh. Исправлю опечатку в дизайн-документе.

Я всегда против использования zip / unzip решения для
потому что это вызовет следующую проблему.
Как уменьшить размер файла Single exe!

Фактически, с самого начала следует использовать IL-Merge аналогичными способами.

Не должно быть споров, это пустая трата времени, никто не просил разархивировать / разархивировать все это, но они пришли с этим дизайном и зря потратили свое и наше время

Люди просят один исполняемый файл и AOT, хватит тратить наше время Microsoft

Я явно хочу однофайловый без AOT. Я предпочитаю возможность JIT, чтобы можно было использовать отражение, обобщения и код, сгенерированный во время выполнения.

я думаю, MS не хочет слышать, хорошо

Я всегда против использования zip / unzip решения для
потому что это вызовет следующую проблему.
Как уменьшить размер файла Single exe!

Не уверен, что понимаю, как будто его заархивировали, его уже сжали. Или вы имеете в виду сокращение избыточных зависимостей и, следовательно, уменьшение размера перед сжатием?

Непонимание негатива. Я еще не использовал его, кроме быстрого теста. Но кажется, что единственный исполняемый файл хорошо работает в ситуации, когда приложение развертывается на клиентском компьютере, или как инструмент командной строки. Вот где я считаю эту функцию полезной. В остальном, в Dev или другой среде я не вижу для этого варианта использования, поэтому то, что они сделали, на данный момент отлично работает в качестве решения.

@RUSshy

я думаю, MS не хочет слышать, хорошо

Напротив, они запрашивают и собирают широкий спектр вариантов использования, которые вы можете увидеть в связанных темах. Ваше мнение важно, но не менее важны и мнения других участников сообщества, и вам не следует насмехаться над Microsoft за то, что она их выслушивает.

Основываясь на вашем заявлении, я думаю, вы могли принять меня за Microsoft. Я просто член сообщества, как и вы, который ни в каком качестве не говорит от лица Microsoft.

Я всегда против использования zip / unzip решения для
потому что это вызовет следующую проблему.
Как уменьшить размер файла Single exe!

Не уверен, что понимаю, как будто его заархивировали, его уже сжали. Или вы имеете в виду сокращение избыточных зависимостей и, следовательно, уменьшение размера перед сжатием?

если вы используете WebApi, MVC или ConsoleApp, напишите HelloWorld! ты хорошо знаешь, что я имею в виду.
упакованный файл слишком велик. он содержит слишком много кода, но никогда не будет выполнен.
если способы IL-Merge уменьшат неиспользуемую ветвь кода.

Да, конечно, я сделал консоль HelloWorld, и да, конечно, ее 68K

Несамостоятельный был 67K
Но это C # не сборка. Если мне нужен HelloWorld <1K, зачем использовать C #?
Более крупные приложения используют больше фреймворка, поэтому в какой-то момент его код более настраиваемый, чем фреймворк.
Неужели нас беспокоят несколько 100К? Если так, не используйте фреймворк и не тратьте время на то, чтобы писать все с нуля ??
Что мне здесь не хватает?

Я всегда против использования zip / unzip решения для
потому что это вызовет следующую проблему.
Как уменьшить размер файла Single exe!
если вы используете WebApi, MVC или ConsoleApp, напишите HelloWorld! ты хорошо знаешь, что я имею в виду.
упакованный файл слишком велик. он содержит слишком много кода, но никогда не будет выполнен.
если способы IL-Merge уменьшат неиспользуемую ветвь кода.

@sgf здесь есть две несколько отдельных проблемы:

• Как уменьшить код приложения?
• Как упаковать приложение в один файл?

Для сокращения кода есть еще несколько методов

• Слияние IL: это не для всех приложений, потому что в процессе он теряет идентичность сборки. Это не цель текущей работы с одним исполняемым файлом.
• Обрезка неиспользуемого IL: ILLinker стремится обрезать неиспользуемый IL. Эта функция интегрирована в dotnet SDK (свойство PublishTrimmed ), а в ILLinker разрабатываются дополнительные оптимизации.
• Zip / Unzip: dotnet publish в настоящее время не заархивирует опубликованный отдельный файл, но это можно сделать.

Как упаковать приложение в один файл?
dotnet publish поддерживает публикацию в один файл - опубликованный файл будет такого же размера, как и приложение.

Что касается генерации собственного кода:

• В настоящее время поддержка создания собственного кода осуществляется через готовый к запуску компилятор (свойство PublishReadyToRun ).
• Публикация через компиляцию AOT - это здорово ( CoreRT ), но пока она недоступна. При компиляции AOT размер исполняемого файла также зависит от параметров компиляции: например: включаем ли мы jit для выполнения сгенерированного кода и т. Д.?

Да, конечно, я сделал консоль HelloWorld, и да, конечно, ее 68K

Несамостоятельный был 67K
Но это C # не сборка. Если мне нужен HelloWorld <1K, зачем использовать C #?
Более крупные приложения используют больше фреймворка, поэтому в какой-то момент его код более настраиваемый, чем фреймворк.
Неужели нас беспокоят несколько 100К? Если так, не используйте фреймворк и не тратьте время на то, чтобы писать все с нуля ??
Что мне здесь не хватает?

извините, как показано на ur img, с самодостаточным. Это 68626KB, это примерно 68mb = 68KK, а не только 68K !!!
нам не нужно <1 КБ (с самодостаточным Это невозможно), <3000 КБ в порядке, примите.
Но 68mb больше 30X +
Вы не всегда будете писать программу HelloWorld !!!

Извинения, поздно ночью ошибка с K's
Спасибо за добавленное объяснение / информацию swaroop-sridhar, некоторые новые переключатели там, о которых я не знал.
Просто попробовал с 3.preview 6 со следующими переключателями

dotnet publish -r RID / p: PublishTrimmed = true / p: PublishSingleFile = true
а теперь до 29 000 тыс.

Конечно, не все приложения будут Hello World, но для автономного приложения C # Core, которое также содержит среду выполнения ... Лично я не беспокоюсь. Конечно, я понимаю, что если вы пишете крошечный консольный инструмент, было бы неплохо иметь его 3К. Но зачем вообще для этого использовать C #?
Интересное обсуждение, ребята!

30 МБ LOL, позвоните мне, когда будет что-то вроде 1-3 МБ, время выполнения полно раздутий, проверьте GO, люди мигрируют в волне

https://www.jetbrains.com/lp/devecosystem-2019/

Даже kotlin начинает набирать обороты, а с родным kotlin он посрамляет C #

И Swift переходит в Windows https://forums.swift.org/t/swift-win32-programming/20686

Итак, вот несколько предложений:

• Добавить опцию для удаления отражения
• Добавить опцию для удаления материала JIT
• Лучше оптимизируйте код C #, чтобы не полагаться на JIT

30 МБ LOL, позвоните мне, когда будет что-то вроде 1-3 МБ, время выполнения полно раздутий, проверьте GO, люди мигрируют в волне

https://www.jetbrains.com/lp/devecosystem-2019/

Даже kotlin начинает набирать обороты, а с родным kotlin он посрамляет C #

И Swift переходит в Windows https://forums.swift.org/t/swift-win32-programming/20686

Итак, вот несколько предложений:

• Добавить опцию для удаления отражения
• Добавить опцию для удаления материала JIT
• Лучше оптимизируйте код C #, чтобы не полагаться на JIT

Я считаю это нечестным. .NET не был разработан для создания самых маленьких консольных приложений с одним файлом. Мы используем его для веб-сайтов Asp.Net и API. Таким образом, сам фреймворк включает в себя массу функций в дополнение к тоннам пакетов nuget, которые вы можете включить. Я не могу себе представить, что возникнет проблема, если размер веб-приложения составляет 50 или несколько сотен мегабайт. Основная проблема - скорость, использование памяти и возможность обслуживания в долгосрочной перспективе. Кого волнует размер на сервере.

Если ваше единственное намерение - создать небольшое консольное приложение размером в один мегабайт, почему бы не использовать подходящий инструмент для работы. Вместо того, чтобы жаловаться на то, что приложение с полнофункциональной структурой, упакованное в один файл, имеет размер в несколько десятков мегабайт даже для «Hallo world», почему бы не пойти, например, на Rust?

Microsoft отлично работает с .NET с самого начала и даже больше за последние пару лет, так что спасибо вам за это.

Что ответить на такую ​​бессмыслицу, ложь и неэффективность?

Вы не понимаете, насколько неправильным было направление ядра .net, и только недавно они начали осознавать это, работая над Distribution / IL Merge / AOT.

А теперь перейти на универсал веб-сборки они не могут, потому что среда выполнения .net настолько огромна, что они не могут развертывать файлы приличного размера.

И вы по-прежнему придерживаетесь принципа «Кого волнует размер сервера». Именно такой образ мышления превратил «предполагаемое современное» ядро ​​.net в уже устаревший и неактуальный технический стек.

Microsoft не очень хорошо работает с .net, они потерпели неудачу, потому что хотели порадовать стариков совместимостью .net framework, это была одна из их ошибок.

Извините, если я показался грубым, но иногда вам нужно внести изменения

Извините, если я звучу грубо, но

Вы говорите грубо, и точка. Это, а также ваши увольнения и поспешные выводы не имеют убедительного эффекта.

Извинения, поздно ночью ошибка с K's
Спасибо за добавленное объяснение / информацию swaroop-sridhar, некоторые новые переключатели там, о которых я не знал.
Просто попробовал с 3.preview 6 со следующими переключателями

dotnet publish -r RID / p: PublishTrimmed = true / p: PublishSingleFile = true
а теперь до 29 000 тыс.

Конечно, не все приложения будут Hello World, но для автономного приложения C # Core, которое также содержит среду выполнения ... Лично я не беспокоюсь. Конечно, я понимаю, что если вы пишете крошечный консольный инструмент, было бы неплохо иметь его 3К. Но зачем вообще для этого использовать C #?
Интересное обсуждение, ребята!

разве у современного языка не должно быть небольшого стремления объединить мир?
Вы хотите, чтобы все разработчики, пишущие на C #, вернулись домой для C ++? или подтолкнуть их к Go, Kotlin, Swift?
Доля рынка и дальнейшее разрушение c #?

.Net, потому что не реализует кроссплатформенность, упустил первые 15+ лет большой возможности развития.
Но теперь .net вернулся на правильный путь.

Да, как я уже говорил ранее, я не уверен, почему такой негатив.
.Net Core - это просто фантастика, если вы переходите от Full Framework. И видение объединения .Net Standard + Core я считаю разумным и прогрессивным.

Сравнивать .NET с GO или любым другим языком / фреймворком бессмысленно.
Во всяком случае, я НЕ РАБОТАЮ по этой теме, так как я думаю, что решение, над которым они работают и улучшают для Single .exe, довольно хорошо разрешило мой «вопрос», возникший несколько лет назад ... Достаточно хорошо для меня и удовлетворяет мои непосредственные потребности.

Так что спасибо, ребята и девушки!

ИЗ

Я хочу напомнить всем в этой ветке о Кодексе поведения .

Не соглашаться или иметь другое мнение - это нормально, но, пожалуйста, давайте будем вежливыми и выразим это как техническое обсуждение. Не нужно использовать сильные слова.
Кроме того, нацеливание на идеи и реализации с вашим мнением - это честная игра. ОДНАКО НЕ ДОПУСКАЕТСЯ нападать на ЛЮДЕЙ, стоящих за ними. Пожалуйста, давайте все относиться друг к другу с уважением, давайте выслушивать разные мнения и воздержимся от резких заявлений и оскорбительных комментариев.

Кроме того, я хотел бы попросить всех быть открытыми для других точек зрения и мнений. Прежде чем делать суждения, обычно полезно выслушать другую сторону - часто есть история, объясняющая, почему все так, как есть. Выкрикивать идеи и решения, зная, почему они такие, как правило, более продуктивно.

Спасибо!

Я всегда против использования zip / unzip решения для
потому что это вызовет следующую проблему.
Как уменьшить размер файла Single exe!
если вы используете WebApi, MVC или ConsoleApp, напишите HelloWorld! ты хорошо знаешь, что я имею в виду.
упакованный файл слишком велик. он содержит слишком много кода, но никогда не будет выполнен.
если способы IL-Merge уменьшат неиспользуемую ветвь кода.

@sgf здесь есть две несколько отдельных проблемы:

• Как уменьшить код приложения?
• Как упаковать приложение в один файл?

Для сокращения кода есть еще несколько методов

• Слияние IL: это не для всех приложений, потому что в процессе он теряет идентичность сборки. Это не цель текущей работы с одним исполняемым файлом.
• Обрезка неиспользуемого IL: ILLinker стремится обрезать неиспользуемый IL. Эта функция интегрирована в dotnet SDK (свойство PublishTrimmed ), а в ILLinker разрабатываются дополнительные оптимизации.
• Zip / Unzip: dotnet publish в настоящее время не заархивирует опубликованный отдельный файл, но это можно сделать.

Как упаковать приложение в один файл?
dotnet publish поддерживает публикацию в один файл - опубликованный файл будет такого же размера, как и приложение.

Что касается генерации собственного кода:

• В настоящее время поддержка создания собственного кода осуществляется через готовый к запуску компилятор (свойство PublishReadyToRun ).
• Публикация через компиляцию AOT - это здорово ( CoreRT ), но пока она недоступна. При компиляции AOT размер исполняемого файла также зависит от параметров компиляции: например: включаем ли мы jit для выполнения сгенерированного кода и т. Д.?

При необходимости динамическое слияние родных DLL с одним именем: XXX.exe (UnManaged).
Использование статического анализа для анализа при компиляции файлов nativeDLL (неуправляемых). Связывание на уровне функций.

api-ms-win-core-console-l1-1-0.dll
api-ms-win-core-datetime-l1-1-0.dll
api-ms-win-core-debug-l1-1-0.dll
api-ms-win-core-errorhandling-l1-1-0.dll
api-ms-win-core-file-l1-1-0.dll
api-ms-win-core-file-l1-2-0.dll
api-ms-win-core-file-l2-1-0.dll
api-ms-win-core-handle-l1-1-0.dll
api-ms-win-core-heap-l1-1-0.dll
api-ms-win-core-interlocked-l1-1-0.dll
api-ms-win-core-libraryloader-l1-1-0.dll
api-ms-win-core-localization-l1-2-0.dll
api-ms-win-core-memory-l1-1-0.dll
api-ms-win-core-namedpipe-l1-1-0.dll
api-ms-win-core-processenvironment-l1-1-0.dll
api-ms-win-core-processthreads-l1-1-0.dll
api-ms-win-core-processthreads-l1-1-1.dll
api-ms-win-core-profile-l1-1-0.dll
api-ms-win-core-rtlsupport-l1-1-0.dll
api-ms-win-core-string-l1-1-0.dll
api-ms-win-core-synch-l1-1-0.dll
api-ms-win-core-synch-l1-2-0.dll
api-ms-win-core-sysinfo-l1-1-0.dll
api-ms-win-core-timezone-l1-1-0.dll
api-ms-win-core-util-l1-1-0.dll
api-ms-win-crt-conio-l1-1-0.dll
api-ms-win-crt-convert-l1-1-0.dll
api-ms-win-crt-environment-l1-1-0.dll
api-ms-win-crt-filesystem-l1-1-0.dll
api-ms-win-crt-heap-l1-1-0.dll
api-ms-win-crt-locale-l1-1-0.dll
api-ms-win-crt-math-l1-1-0.dll
api-ms-win-crt-multibyte-l1-1-0.dll
api-ms-win-crt-private-l1-1-0.dll
api-ms-win-crt-process-l1-1-0.dll
api-ms-win-crt-runtime-l1-1-0.dll
api-ms-win-crt-stdio-l1-1-0.dll
api-ms-win-crt-string-l1-1-0.dll
api-ms-win-crt-time-l1-1-0.dll
api-ms-win-crt-utility-l1-1-0.dll
aspnetcorev2_inprocess.dll
clrcompression.dll
clretwrc.dll
clrjit.dll
coreclr.dll
dbgshim.dll
dotnet-aspnet-codegenerator-design.dll
hostfxr.dll
hostpolicy.dll
mscordaccore_amd64_amd64_4.6.27317.07.dll
mscordbi.dll
mscorrc.dll
mscorrc.debug.dll
sni.dll
sos.dll
sos_amd64_amd64_4.6.27317.07.dll
ucrtbase.dll
...etc...

Если хорошо поработать, результат может составить 2-3 Мб. когда я напрямую упаковал их в 7zip, это заняло около 4,85 МБ. Теперь мы получаем XXX.exe.

разработайте аналогичную связь на уровне функций с помощью IL-merge.
Для управляемой DLL снова та же старая уловка.
Наконец, вставьте управляемую DLL как разделы PE.exe (пометьте как раздел .net).

Для отражения, анализ DLL типа отражения. Сохраните метаданные и тип отражения (включая функцию) и все его зависимые от дерева.

Прошу прощения, я не хочу больше тратить время на обсуждение этого вопроса. Мнения не могут быть объединены.
Сначала я ожидал результата. Но теперь мне, вероятно, следует рассмотреть другие языки программирования, чтобы удовлетворить свои потребности (может быть, Dlang, может быть, Go, может быть, Kotlin, может быть, Nim или, может быть, Rust - лучший).

Спасибо за все, что поговорили со мной. извините за мои нытья. из

@sgf Я думаю, что вы сделали несколько хороших

1. Mono уже поддерживает компиляцию AOT с привязкой для уменьшения размера файла. Это одна из причин, почему для реализации среды выполнения браузера .net был выбран mono. https://www.mono-project.com/docs/advanced/aot/, и я предполагаю, что именно поэтому проекты Blazor могут иметь компоновщик.

2. Microsoft заявила, что хочет объединить свои среды выполнения .NET в одну «всемогущую». Вместо того, чтобы иметь моно для одних вещей и .NET Core для других, им нужна единая среда выполнения, которая может работать во всех сценариях. Это де-факто означает, что ему потребуется поддержка AOT и связывания / удаления кода и т. Д. Поэтому я ожидаю, что в ближайшие несколько лет либо среда выполнения .NET Core получит эти функции, либо функции Mono и .NET Core будут объединены в новый Время выполнения.

Если кто знает лучше, сообщите мне.

+ 2 ¢

Я думаю , что проблема, кажется , решения принимаются без большого количества информации. В наши дни, куда бы я ни посмотрел, люди говорят об этом; Для подавляющего большинства людей, развертывающих программы, это стоит на первом месте в списке желаний, и многие переходят от C # к другим языкам с лучшей AOT / возможностью развертывания. Я думаю, что это установленный факт, который становится очевидным, если вы активны в сообществе. Тем не менее, похоже, это нисколько не влияет на решения.

Дело в том, что, кажется, никто точно не знает, насколько это важно. Лично для меня это чрезвычайно важно, поэтому, конечно, я очень предвзят, но у меня сложилось впечатление, что в целом это имеет первостепенное значение, и кажется, что MS просто не уделяет ему должного внимания, оставляя у многих из нас впечатление они принимают единообразные решения, что, в свою очередь, не дает нам уверенности в будущем технологии в целом.

Я согласен с @RUSshy. CoreRT - невероятный проект, который определенно движется в правильном направлении, но в целом кажется, что все усилия сосредоточены на серверных / веб-технологиях. В этом отношении такие вещи, как среда выполнения, jits и большие двоичные файлы, говорят сами за себя. Никто, развертывающий программное обеспечение, не хочет этого.

При этом я лично все еще использую эту технологию, хотя в некоторых областях я не задерживаю дыхание относительно ее будущего.

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

@ Алан-FGR

Но пока кажется, что решения принимаются без учета этого.

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

Я думаю, что MS хорошо осведомлены о недостатках текущей среды выполнения ядра dotnet, и поэтому в будущем они будут стремиться к обеспечению паритета функций с моно-средой выполнения.

Просто посмотрите примечания к выпуску для .net core 3.0.0 preview 6:

Сегодня мы анонсируем .NET Core 3.0 Preview 6. Он включает обновления для компиляции сборок для улучшенного запуска, оптимизацию размера приложений с помощью компоновщика и улучшений EventPipe. Мы также выпустили новые образы Docker для Alpine на ARM64.

Мне кажется, они прекрасно понимают, что размер приложения важен для определенных сценариев - особенно теперь, когда в смеси присутствует Blazor.

@ Alan-FGR Согласен, веб-ориентированность выглядит довольно странно, учитывая, что IIS занимает около 8% рынка и продолжает падать. ASP.NET не имеет значения, и никакое улучшение C # или его стандартных библиотек никогда не изменит этого. C # поддерживается консольными приложениями, службами Windows, мобильными приложениями и играми для ПК. Своим существованием он обязан Unity и Xamarin. Это позор, потому что C # - действительно приятный язык для разработки. Это высокая похвала от давнего разработчика Java, который все еще думает, что Microsoft оставила свою высшую отметку с Windows XP.

При необходимости динамическое слияние родных DLL с одним именем: XXX.exe (UnManaged).
Использование статического анализа для анализа при компиляции файлов nativeDLL (неуправляемых). Связывание на уровне функций.

Я не уверен, что вы имеете в виду под динамическим слиянием, но есть план статически связать нативные компоненты вместе с хостом. См. Этот раздел .

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

Мы обсудили возможность объединения сборок в одну и наличие боковых таблиц метаданных для поддержки динамических функций. Это действительно обеспечивает значительную экономию размера. Но стоимость его реализации довольно высока - из-за новой поддержки метаданных и изменений, необходимых в отладчиках / профилировщиках и т. Д. Для их обработки.

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

Но пока кажется, что решения принимаются без учета этого.

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

Я думаю, что MS хорошо осведомлены о недостатках текущей среды выполнения ядра dotnet, и поэтому в будущем они будут стремиться к обеспечению паритета функций с моно-средой выполнения.

@dazinator Я думаю, что сам факт, что MS почему-то считает Mono достойным решением для чего угодно, говорит о том, что они действительно не знают своих продуктов. Я использовал Mono, и хотя это важная часть технологии и помогала безмерно популяризировать .NET, ей определенно не хватает качества ... Xamarin проделал отличную маркетинговую работу, продвигая свою технологию, но она была основана на чрезмерно многообещающих и недооцененных задачах. доставляют, и кажется, что тот, кто принимает эти решения в MS, просто видел некоторые из их промо-материалов и никогда не использовал эту технологию. С другой стороны, CoreRT - это технология, которая до сих пор показалась мне слишком сложной. На мой взгляд, это другой уровень качества, и все же MS пренебрегает им в пользу какой-то технологии, которая, как я подозреваю, скреплена утиной лентой.

Согласитесь, веб-ориентированность выглядит довольно странно, учитывая, что IIS занимает около 8% рынка и продолжает падать. ASP.NET не имеет значения, и никакое улучшение C # или его стандартных библиотек никогда не изменит этого. C # поддерживается консольными приложениями, службами Windows, мобильными приложениями и играми для ПК.

@kjkrum в том-то и дело. Однако, возможно, для них 8% рынка Интернета все еще намного важнее, чем Windows и мобильные приложения. Хорошие веб-технологии, по крайней мере, помогают продажам серверов Windows, поэтому их интерес к этому вполне очевиден, но сосредоточение на нем такого большого внимания - также очень поверхностная стратегия, и я отказываюсь верить, что именно это движет их решениями. Казалось, что MS идет в правильном направлении с основанием dotnet и множеством многообещающих проектов, но, похоже, они упускают возможность оставить доминирующую технологию.

Я знаю, что это анекдотично, поэтому, вероятно, бессмысленно, но все люди, которых я знаю, которые использовали C # для своих проектов (в основном разработчики игр), перешли на что-то другое из-за ограничений, которые были полностью разрешимы. Они перешли на Rust, D, Go и C ++. Я сам регулярно использую C ++ и изучаю Rust, но я все еще использую C # для некоторых личных проектов, потому что он намного лучше, даже несмотря на то, что развертывание качественного продукта является проблемой.

Своим существованием он обязан Unity и Xamarin.

Да что за благословение и проклятие из-за множества технических проблем. Unity, например, имеет очень плохую репутацию, но, к счастью, это не повлияло на .NET / C #.
Однако XNA, хотя и далека от совершенства, все же имеет невероятно отличную репутацию среди пользователей и разработчиков.

Рад видеть эту землю с .NET Core 3.0 сегодня. Спасибо, народ! 👍

Я не уверен, что это то, что люди хотят, если мы получим простой калькулятор размером 141 МБ exe, тогда функция будет неудачной (и я считаю, что реальная стоимость составляет 141 МБ * 2, так как он будет извлекать материал где-то правильно)

Да, это определенно то, что я хочу. Это все еще меньше, чем обычное автономное развертывание.

Приветствуется более агрессивная обрезка сборки и встряхивание дерева, но это очень полезное начало. Постепенное улучшение - самый разумный способ повысить ценность.

О, это то, что ты хочешь? моя беда, я не знал, что раздутые приложения популярны

Калькулятору не нужен JIT, даже Reflection, но поскольку это то, что вы хотите, я думаю, я ошибаюсь с самого начала, я должен прекратить программировать

@RUSshy Он не более

Удаление JIT и отражения не зависит от того, все ли упаковано в один exe. Т.е. вы можете удалить JIT и отражение без single-exe, и вы можете иметь single-exe без удаления JIT и отражения. Это отдельные работы.

Я не уверен, что это то, что люди хотят, если мы получим простой калькулятор размером 141 МБ exe, тогда функция будет неудачной (и я считаю, что реальная стоимость составляет 141 МБ * 2, так как он будет извлекать материал где-то правильно)

извлеките файлы в C: Users [YourUserName] AppDataLocalTemp.net

Есть ли способ переопределить, где будет распаковываться один exe?
У меня возникла проблема, когда он попытался извлечь в / var / ...., где у пользователя нет прав на запись.

@eiva какая это была ОС? Была ли это AWS lambda?
https://github.com/dotnet/core-setup/issues/7940 отслеживает исправление этой проблемы.

А пока вы можете установить переменную среды DOTNET_BUNDLE_EXTRACT_BASE_DIR чтобы контролировать, куда извлекаются связанные файлы.

@ swaroop-sridhar Спасибо за ответ!
Это centos.7 запускает приложение из «ограниченного» служебного аккаунта.

@ jnm2 Я ценю, что вы любите C #, и я тоже. Но давайте будем честными, это безумие, что у калькулятора 128 мегабайт.

@TechnikEmpire Я считаю необходимым отметить, что

Я лично не буду чувствовать себя полностью удовлетворенным, пока у меня не будет возможности делать древовидные схемы моего собственного кода и библиотек, ссылочных сторонних библиотек и самого .NET. Но это не делает сегодня для меня менее ценной функцию single-exe. Это шаг в одном измерении. Сотрясение деревьев - это самостоятельное измерение, и я надеюсь, что оно привлечет к себе много внимания.