Делаем приложение на .NET Core независимым от наличия .NET на компьютере

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

Начиная с .NET Core 2.1 при публикации приложений поддерживается режим развёртывания в виде так называемого «автономного исполняемого файла».

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

Как настроить такую публикацию на примере консольного приложения?

На самом деле процесс настройки такой публикации ничем не отличается от того, что мы привыкли видеть в соответствующем мастере Visual Studio проходя все его окна. Отличие появляется только в самом конце настройки, так как для публикации в режиме «автономного исполняемого файла» требуется изменить значения от одного до трёх параметров (в зависимости от того, что вы хотите получить в итоге) заданные по умолчанию.

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

Для этого выберите профиль и нажмите ссылку «Показать все параметры».

Профиль публикации

В появившемся окне установите для параметра «Режим развёртывания» значение «Автономное».

Параметры публикации

По умолчанию параметр «Целевая среда выполнения» имеет значение «win-x86». Если вы планируете публиковать приложение для другой платформы вам нужно указать соответствующую платформу, как показано на скриншоте ниже.

Выбор среды исполнения

 

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

Для того чтобы сохранить внесённые изменения нажмите кнопку «Сохранить».

После публикации приложения мы увидим в соответствующей папке все необходимые файлы.

Выходные файлы

Для простейшего консольного приложения (стандартный шаблон Visual Studio с «Hello, world!» получилось в общей сложности 225 файлов с общим размером порядка 58 МБ.

Исходный размер выходных файлов

Многовато для «Hello, world!», но такова плата за автономность.

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

Параметры публикации отдельный файл

В этом случае создаётся всего 6 файлов с общим размером чуть больше 52 МБ.

Выходны файлы альтернативный вариант

азмер основного исполняемого файла

 

При этом основная часть приходится на исполняемый файл приложения (в нашем примере это ConsoleApp1.exe)

.Размер основного исполняемого файла

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

Если вы используете для публикации приложений ClickOnce, то настройка несколько упрощается так как в этом случае мастер позволяет задать нужные настройки ещё на этапе создания профиля публикации.

Настройка при создании профиля ClickOnce

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

Очевидно, нет никакого смысла «отвязывать» приложение от .NET при его публикации на сервере IIS (сейчас его всё чаще используют только для проектов на .NET Framework, где такой возможности просто нет). Также подобная инициатива скорее всего будет нецелесообразной и для Docker (в том числе потому, что Microsoft предоставляет официальные образы Docker с поддержкой .NET).

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

К слову, собрав подобным образом standalone сервис (особенно с включённой опцией «Создать отдельный файл») на выходе получается, по сути, тот же самый результат, что и при сборке standalone сервиса на основе Spring Boot. С той лишь разницей, что здесь сервис уже «отвязан» от установки .NET и для этого не потребовалось никаких дополнительных усилий, а с Java такое, к сожалению, не выйдет.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *