Если вы вдруг пропустили, то .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, где ведется речь о том, что в будущем все станет более автоматическим, возможно вплоть до уровня метода.