Почему. Net Core PublishSingleFile выполняет самораспаковку вместо сборок встраивания ресурсов? - PullRequest
0 голосов
/ 11 апреля 2020

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

  1. ILMerge

    • Действительно объединяет сборки. Сравнимо с созданием одного .csproj и извлечением всего исходного кода.
  2. Fody.Costura

    • Разделяет сборки, но включает только их файлы как ресурсы и изменяет разрешение соответственно.
  3. . Net Core 3+ PublishSingleFile / Warp

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

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

Я думаю, что любой из трех подходов имеет свои преимущества и минусы и ни у кого нет "такого" пути к go.

  1. ILMerge

    • + Похоже, самый естественный вариант "слияния"
    • + Не требует загрузки во время выполнения, если все есть и работает, чем это; как только образ находится в памяти, мы закончим
    • - Загрузка всего за один раз каждый раз может привести к снижению производительности при запуске, что относится к настольным приложениям
    • - Значительные изменения во внутренних компонентах, изменение имен сборок , вероятно, внутренняя часть библиотеки более тесно связана с кодом приложения et c .; это может привести к трудным отладочным ошибкам, в худшем случае, всплывающих в производстве, я думаю. Это просто меняет то, что разработчики могли принять как должное (то есть название своей сборки).
    • - Возможно, не концептуально, но не поддерживает. Net Core => dealbreaker
  2. Fody.Costura

    • + Включает сжатие для зависимостей
    • + Изменяет намного меньше внутренних компонентов, что, вероятно, приводит к менее непредвиденным ситуациям
    • + Вероятно, требуется ОС для загрузки полного образа, но не CLR для одновременной загрузки библиотек, что может улучшить производительность при запуске
    • - требует каждый раз отсоединения зависимостей; может ухудшить производительность процессора, может повысить производительность IO-10
  3. Самораспаковывающийся

    • + Сжатый тоже
    • + После того, как код извлечен и запущен, единственная разница в том, где он находится. Таким образом, разработчики lib могут даже найти свою сборку на диске et c., Что делает наименьшее различие во времени выполнения, я думаю.
    • - Первый запуск может занять некоторое заметное время и довольно интенсивный ввод-вывод, что-то вроде Установка.
    • + Последующие запуски ведут себя как развертывание не в одном файле, и имеют свои преимущества (недостатки) по сравнению с двумя другими.
    • - Поставляется с некоторыми нетривиальными проблемами. Когда обновлять извлеченные файлы? Кто удаляет старые версии извлеченных файлов? Что делать, если диск заполнен /...?
    • - Выполнение больше не является побочным эффектом.
    • - Требуется более чем двукратное дисковое пространство.

В моем личном, очевидно, неисчерпывающем и не научном c опыте, (3) иногда имел некоторые грубые края и показал странное поведение , в то время как (2) работал очень хорошо в годы я использую его (сопоставляя Framework против Core, хотя). Но, вероятно, это либо из-за того, что (3) возникло совсем новое явление, либо из-за моего недопонимания.

Намерение опубликовать этот вопрос состоит в том, чтобы (а) лучше понять это и (б) понять, почему Microsoft выбрала (3). Итак, было бы замечательно

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

Хотя я понимаю, что сложно конкурировать с фреймворком, мне немного грустно, что Costura находится в режиме обслуживания , учитывая, что я думаю, что он имеет преимущества по сравнению с подходом на основе фреймворков, что делает второй вариант жизнеспособным выбором. Таким образом, одна из причин, по которой я задаю этот вопрос, заключается в том, чтобы понять, есть ли какие-либо серьезные преимущества (3) по сравнению с (2), который я пропускаю.

...