[Перевод] Self-contained дистрибуция .NET Core приложений
Если вы вдруг пропустили, то .NET теперь open source, а .NET Core это бесплатный, open source, кроссплатформенный фреймворк, который вы можете скачать и запустить за время <10 минут. Вы можете получить его на Mac, Windows и на пол-дюжине Unix-ов с сайта dot.net Попробуйте его вместе с бесплатной, кроссплатформенной Visual Studio Code и вы будете писать на C# и F# всегда и везде.
OK, с учётом вышесказанного, есть два способа развертывать .NET Core приложения. Это FDD и SCD. Поскольку ТБА (трехбуквенные акронимы) это глупо, то это Framework-dependent и Self-contained Deployment.
Когда .NET Core устанавливается, то он находится, например, в C:\program files\dotnet на Windows. В директории «Shared» есть куча .NET штук, которые, скажем так, shared т.е. общие. Может быть множество директорий внутри, как вы можете увидеть ниже в моей папке на скриншоте. У вас может быть множество установок .NET Core.
Когда вы устанавливаете свое приложение и его зависимости, НО НЕ .NET Core само, то вы зависите от .NET Core, которое уже установлено на целевой машине. Это прекрасно для Web Apps или для систем с большим количеством приложений, но что если я захочу написать приложение и дать его вам в качестве zip или на usb флешке и я просто хочу чтобы оно работало. Я могу включить .NET Core в придачу, тогда из всего это и получится Self Contained Deployment.
Я сделаю мое «Hello World» приложение по размеру больше, чем оно было бы, используя общесистемную установку, но я буду знать, что оно будет Просто Работать потому что оно полностью самостоятельное.
Если я разверну мое приложение вместе с .NET Core, то важно помнить, что я буду ответственен за сервис .NET Core и поддержку его в актуальном обновленном состоянии. Также мне нужно выбрать целевые платформы заранее. Если я хочу, чтобы оно запускалось на Mac, Windows и Linux И просто работало, то мне нужно включить эти целевые платформы и построить пакеты для них. Это все интуитивно понятно, но хорошо и знать наверняка.
Для примера, я возьму мое небольшое приложение (я использую простое «dotnet new» приложение) и модифицирую project.json в текстовом редакторе.
Мое приложение это .NETCore.App, но оно не будет использовать платформу .NET Core, которая установлена. Она будет использовать локальную версию так что я удалю «type=«platform» из зависимостей. Вот что останется:
"frameworks": {
"netcoreapp1.0": {
"dependencies": {
"Microsoft.NETCore.App": {
"version": "1.0.1"
}
}
}
}
Далее я добавлю runtimes секцию, чтобы указать какие из runtime я хочу задать. Список всех Runtime IDE находится здесь
"runtimes": {
"win10-x64": {},
"osx.10.10-x64": {},
"ubuntu.14.04-x64": {}
}
Примечание переводчика (на всякий случай): эта секция добавляется перед последней скобкой
После запуска команды «dotnet restore» вам захочется построить проект для каждого из runtime таким образом:
dotnet build -r win10-x64
dotnet build -r osx.10.10-x64
dotnet build -r ubuntu.14.04-x64
И после этого опубликовать релиз после того как вы протестировали и т.п.
dotnet publish -c release -r win10-x64
dotnet publish -c release -r osx.10.10-x64
dotnet publish -c release -r ubuntu.14.04-x64
После того, как это сделано, я получу мое портативное приложение в n папках, готовое для разворачивания на любой системе, на какой мне захочется.
Вы можете увидеть в директории Win10 приложение «MYAPPLICATION.exe» (мое называется scd.exe) которое может быть запущено сразу, а не с помощью этих штук, вроде «dotnet run», которые используют разработчики.
В .NET Core Docs есть уйма хорошей документации, по поводу того как настроить и определить точно, что будет развернуто с вашим self-contained приложением. Вы можете также обратить внимание на статью trimming to .NET Core, где ведется речь о том, что в будущем все станет более автоматическим, возможно вплоть до уровня метода.
