4 октября 2016 в 08:54

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, где ведется речь о том, что в будущем все станет более автоматическим, возможно вплоть до уровня метода.
Перевод: SCOTT HANSELMAN
Алексей Соммер @asommer
карма
49,2
рейтинг 25,6
разработка универсальных приложений Windows
Похожие публикации
Самое читаемое Разработка

Комментарии (19)

  • 0
    Спасибо за перевод. Буду рад увидеть еще больше материала по .NET core.
  • 0
    А не подскажете .net Core все так же падает с segfault во время dotnet restore на Ubuntu 14.04 в районе curl запроса на функции X509_verify_cert?
    • 0
      у меня не падает)
      • +1

        Да падает не у всех. Там стечение разных версий курла, ядра и прочего. На эту тему есть https://github.com/dotnet/cli/issues/3681 и https://github.com/dotnet/cli/issues/4109

      • 0

        Просто после всех историй с Windows 10 настоящего параноика должны насторожить любые телодвижения Microsoft в районе openssl

  • 0

    Эти три папочки сколько весят?

    • +1
      Около 45 Мб каждая
      • 0
        Я пробовал делать publish для ASP.NET Core, у меня HelloWorld получился на 400-500 Мб.
        • 0
          У ASP.NET Core доступно больше API. У консольных приложений пока что мало что доступно.
          • 0
            Я пробовал использовать ASP.NET Core + Docker.
            Меня расстроило, что нельзя сделать базовый контейнер с ASP.NET и потом уже делать свои мелкие контейнеры с приложением, т.е. для каждого нового билда с приложением получается контейнер размером в 400-500 Мб.
        • +1
          У меня шаблонное asp.net core web application приложение, после publish в release для ubuntu 14.04, весит 70 мб вместе со всей статикой из wwwroot.
        • 0
          Немного запоздало, но у меня «Hello World» на ASP.NET получился те же 45 Мб
          • 0
            Да, стало намного лучше. Я это делал еще во времена `dnu`.
      • 0

        Ясно, для мелких утилиток не катит...

  • 0
    Я извиняюсь, а где здесь «Разработка под Linux»?
    • +3
      Здесь и разработка под Mac есть. Разработка кроссплатформенных приложений. В частности под *nix
      Кроме того еще и open source.
  • 0
    Я могу включить .NET Core в придачу

    А что насчёт «dotnet compile --native»? Разве оно не создаёт нативный бинарник без запаковки рантайма в него?
    • 0
      Фактически тот exe, который полуается, это обертка для команды «dotnet run».
      Про компиляцию в native у Хансельмана тоже есть артикул Exploring the new .NET «dotnet» Command Line Interface (CLI), но посмотрите на дату — он старенький.
      Если не ошибаюсь, то .NET Native доступен только под Win 10.
      • +1
        Если я не ошибаюсь, то dotnet compile --native вырезали перед релизом и сейчас развивают в рамках CoreRT и .NET Native, причем тоже кроссплатформенно.

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