最近打算做一个公司的代码走查工具，思前想后觉得正好可以当作一个Core的实践机会，于是上官网看了下资料，顺便作了一下笔记方便以后查阅。
注1：这里的Core程序部署指的是.Net Core而非Asp.Net Core。
注2：本人已跟随官方文档更新。
一，.Net Core的部署形式
Core的应用程序部署有两种形式：
1，Framework-dependent deployment（[Core Framework]依赖式部署）(FDD)
2，Self-contained deployment（独立式部署）(SCD)
从名字就看得出来他们的区别，第一种(FDD)是需要部署环境下已经安装.Net Core，而第二种(SCD)在发布时就包含了对应平台的框架。
二，Framework-dependent deployment（[Core Framework]依赖式部署）
来看看如何以FDD的方式部署一个Core程序。
首先建立一个新的Core程序
（此处不会详细说明，如果不会的可以参考 此处 ）
Program.cs如下，很简单的HelloWorld。
using System;
using static System.Console; namespace ConsoleApplication
{
public class Program
{
public static void Main(string[] args)
{
WriteLine("HelloWorld");
}
}
}
在程序所在目录下执行:
dotnet restore
dotnet build(或者dotnet run)
测试通过后输入
dotnet publish -f netcoreapp1.0 -c release
dotnet publish -f netcoreapp1.1 -c release (1.1版本)
来进行发布。
发布之后进入到你的程序目录的 bin/release/netcoreapp1.0(1.1)/publish 下，你会发现多了一些dll，他们会自动取project.json(*.csproj)所在的路径名。
运行命令
dotnet dotnetcore-getstarted.dll(这里要换成你的项目文件夹名)。
可以看到我们的HellorWorld程序已经跑起来了。
三，Self-contained deployment（独立式部署）(SCD)
(Core1.0版本，1.1版本在之后)
程序还是上面的HelloWorld，我们打开 project.json 修改一下配置，添加上 runtimes 节点，并且移除framework下的type节点。
改造之后的文件看上去是这样的。
关于runtime节点：此处填写的"win7-x64"是RIDs( Runtime IDentifiers )，你可以在引用页下面找到自己对应的RID。
然后运行
dotnet build(或者dotnet run)
需要注意的是,build是可以指定编译环境的如：
dotnet build -r win10-x64
如果你不指定，会从project.json中读取目标平台的参数。
编译完成后，它会在你的程序目录下生成如下路径 /bin/debug/netcoreapp1.0/<runtime_identifier> ，生成调试文件。
测试成功后，使用下面的命令发布：
dotnet publish -c release
你也可以指定目标平台，如果没有指定那么它会去project.json里读取。
现在进入到程序目录的 /bin/release/netcoreapp1.0/win7-x64/publish 下查看，你会发现产生的文件了除了exe之外还有一大堆core framework的模块dll。
如下：
在该路径下运行下你的exe：
成功输出了HelloWorld。
(Core1.1版本)
打开*.csproj文件，在 <PropertyGroup> 节点下追加 <RuntimeIdentifiers> 节点如下
使用以下命令来恢复相应的依赖
dotnet restore
然后可以使用发布命令来发布对应平台的发布包
dotnet publish -c Release -r win7-x64
dotnet publish -c Release -r osx.10.11-x64
它会在 .\bin\Release\netcoreapp1.1\<runtime_identifier> 路径下生成相应的程序和所需的Core环境。
四，对比
文件体积
很明显，由于SCD自带了core所以大小查了很多，在FDD下的程序只有8K,而后者有45MB。
对Core依赖性
FDD下的程序需要目标平台已经安装了core，而SCD不需要。
对目标环境的控制
由于SCD自带了Core所以能很好地控制宿主环境，防止由于目标平台的Core差异导致的一些意外。
对第三方引用库的支持
两者都能很好地支持，但都存在一个需要注意的地方，第三方库的目标平台需要与当前程序的一致。
五，总结
官方的推荐是使用FDD，这样的方式能使程序更小更简洁，也是可移植的（portable ），在多数情况下，FDD是优先选择。
SCD适用于一些网络相对封闭的场景比如医院或者企业内部网络，这时候自带Core进行产品发布是一个不错的选项。
不过其实在Docker盛行的这个年代，SCD让我觉得有些鸡肋。
题外话：早就觉得project.json文件跟以往的风格太不相称了，终于在Core1.1里又换回了熟悉的.csproj，顺带干掉了.xproj，真是大快人心。
有兴趣的同学可以点击 这里 参考原文。